#
| 云計算技術簡介 |
云計算技術概述，大數據時代來臨，Google云計算技術，Amazon云計算技術，微軟云計算技術等。 |
| 初始Hadoop |
Hadoop的起源、解決的問題、
以及它的特點、應用場景和發展趨勢，企業應用情況，為什么使用，及其生態系統介紹。 |
Hadoop
單節點偽分布式安裝 |
Hadoop
1.0 版本 安裝環境搭建 |
Hadoop
架構 |
Hadoop
整體架構設計及重要的概念 |
Hadoop
HDFS 體系結構 |
1：HDFS
架構設計目標，設計思想，
2：特點，基本概念，容錯性。
3：HDFS
界面介紹
4：HDFS
服務 |
Hadoop
HDFS 命令行 |
Hadoop
HDFS Shell 基本操作 |
HDFS
Java API 使用 |
1：基于Eclipse開發環境搭建
2：Java
API示范 ：比如建立文件，刪除，移動復制等 |
Hadoop
MapReduce 架構 原理 |
1：MapReduce 架構詳解
2：MapReduce
流程
3：MapReduce
特點
4：MapReduce
容錯性
5：MapReduce
服務 |
Hadoop
MapReduce api |
1：Mapper
2：Reducer
3：Driver |
Hadoop
MapReduce 編程實踐 wordcount |
1：WordCount
程序編寫，演示
2：運行MR
Job 示例 |
高級MR
編程 |
1：RecordReader
2：Partitioner
3：Combiner |
Hadoop
MapReduce IO |
1：數據完整性校驗
2：壓縮，包括：LZO、GZIP、Snappy
3：序列化
4：基于文件的數據結構，包括：SequenceFile、MapFile |
| 調優 |
調優經驗分享 |
課程中的HBase部分：
掌握HBase基本原理，應用場景，掌握基本的編程技巧
| 章節課程 |
內容描述 |
| 初始HBase |
1：NoSql
數據庫簡介.
2：HBase
簡介及與傳統關系數據庫的對比。
3：HBase
應用場景，企業應用情況，為什么使用。
4：HBase
特點 |
HBase
環境搭建 |
HBase
環境搭建 |
HBase
體系結構 |
1：HBase架構
2：HMaster、RegionServer、 Regoin 等概念 |
HBase
數據模型 |
1：表
2：Rowkey
3：Column
Families |
HBase
Shell 命令行 |
1：啟動HBase
Shell
2：建立表
3：訪問數據（添加，刪除，查詢）
4：練習 |
HBase
api 簡單編程介紹 |
1：基于Eclipse開發環境搭建
2：基本操作（建表，查詢數據，刪除）
3：高級操作
（使用過濾器）
4：練習 |
HBase
row-key 設計及Scheme 設計 |
經驗分享，設計原則 |
HBase
coprocessor等高級特性介紹 |
1：coprocessor特性分析，使用場景；
2：HBase
優化簡單原則 |
課程中的Hive部分：
掌握Hive基本原理，應用場景，掌握基本的編程技巧
| 章節課程 |
內容描述 |
| 初始Hive |
1：Hive簡介
2：為什么使用Hive
3：Hive
應用場景，企業應用情況 |
Hive
環境搭建 |
Hive
偽分布式環境搭建 |
Hive
體系結構 |
1：Hive主要的組件
2：用戶接口
3：概念 |
Hive
QL |
1：Hive
類Sql
2：DDL
3：DML
4：Select
與連接查詢 |
Hive
Java API |
1：搭建
Hive JDBC 開發環境
2：Hive
JDBC 開發流程 |
Hive
用戶自定義函數簡單介紹 |
UDF和UADF |
課程中的分布式協調系統Zookeeper部分：
掌握Zookeeper基本原理，應用場景，掌握基本的編程技巧
| 章節課程 |
內容描述 |
| 初始Zookeeper |
1：什么是ZooKeeper
2：ZooKeeper特性 |
Zookeeper
體系結構 |
1：ZooKeeper體系結構
2：ZooKeeper存儲結構 |
Zookeeper
選舉與鎖機制 |
1：Zookeeper
選舉機制
2：Zookeeper
選舉算法
3：Zookeeper
鎖機制 |
ZooKeeper
CRUD API |
1：Create
2：Read
3：Update
4：Delete |
| Zookeeper
應用場景 |
Zookeeper
應用場景 |
最近公司要上一個新項目。可能要整合以前的一些系統。現在考慮是用esb企業總線進行管理。初步定的是wso2。基于apache synapse。
1.一般的esb流程是什么樣子的？
是不是主系統發生soap請求。esb接收并且轉換成jms然后子系統監聽jms。最后得到數據。
還是。jms僅僅是內部轉換。soap請求在esb轉成jms后。加入隊列。然后再轉成soap調用子系統？
2.使用jms的考慮是jms對隊列的信息進行持久化。防止比如子系統突然掛掉了。消息丟失。
但是有個問題。是esb自動監聽jms的隊列的話。會導致直接消費了。而數據沒有存在隊列中。還是會出現消息丟失的問題。
這個應該怎么解決。
3.esb進行協議之間的轉換。每種方式都需要些一個轉換方式么？有沒有什么通用的。或者是自動轉換的。比如soap和jms的互相轉換。不是協議切換。是內容轉換。
4.如果大家有討論esb的群。或者有高手愿意指點一下。謝謝了。
------------------------------------------------------------------
1，一般ESB的流程，
先是整理需連接的系統，需要連接的系統功能(一般管它叫服務)，確定服務的依賴關系，支持的協議(文件，WebService, RPC,...),調用的方式(同步/異步)
然后使用ESB提供的那些協議組件，一點點串起來就行。串的方式可以參考EIP (www.eaipatterns.com)
你說的兩種異步方式的話都可以，
如果是同步的，也可以直接soap -> soap, 不用JMS。 一般用JMS是為了實現異步通訊
2，JMS，至少我接觸的ActiveMQ， 是可以支持事務的，發生異常，可以不消費信息
3，協議轉換是為了配合你那些需要整合的系統，如果都是SOAP，也就不需要轉了。
消息內容轉換(格式，內容)，一般ESB都提供各種工具的。
------------------------------------------------------------------
1、如果你要做同步轉異步，可以在esb上做成ws轉jms，然后起到一個緩沖的作用。
最后可以再同步的返回給調用方。
你也可以修改調用方為jms方式，這樣就是徹底的異步了，在esb端可以jms轉ws，調用業務服務方的ws。
2、esb都支持事務的，jms中如果不確認消息的話，不會從持久存儲去delete掉的。
一般的esb。也可以做成是esb消費掉消息，然后存入esb自己內置的jms provider中，這樣你再消費的話，也是可靠的。還可以做成補償機制的，即esb中如何消息處理失敗，把消費放回去原來的queue或是一個中間的臨時queue，稍后做recover。
3、從esb的不同transport進去的數據，在esb的中介層處理時，其實消息格式都是一致的、通用的。也就是說常見的ws或jms轉換在一般的esb里處理都很簡單。如果稍微復雜點，也很容易擴展transformer（比如通過xslt做xml格式轉換）來實現數據內容和格式的轉換。
在一個開發團隊中，產品經理、設計、開發、市場以及運營通力合作才能讓一個產品走向成功。
而在產品從稚嫩到成熟的這個過程中，產品經理至始至終都有著自己的職責。而通過對這部分的職責的認識就有助于在產品開發過程中更好的為自己定位，讓工作更有效率的完成。
在不久前有這么一個段子：
產品經理有30%的時間到處溜達，打開所有網上正在內測、封測、公測、正式發布的SNS、微博、問答、客戶端產品；20%的時間在QQ、MSN、微博上扯談、求碼；30%的時間永無休止的立項、用研、交互評審、UI評審、測試、發布、運營會議；20%的時間寫BRD、PRD、MRD、DEMO、運營方案。
雖然在這個段子里我們看到的是一個輕松詼諧的產品經理介紹。不過在實際工作中，一個產品經理的在整個產品的生命周期中有著需要嚴謹履行的職責。
一：產品概念階段
1：在公司內外尋找產品創意。組織進行論證和充實。
2：組織所轄產品線的市場細分選擇，并制定產品線初始業務/路標計劃（需求規格/RoadMap）。
3：根據市場變化進行定期和不定期的計劃調整工作。
4：參與產品戰略和產品平臺規劃工作。
二：產品需求階段
1：組織所轄產品的需求采集。
2：組織收集/分析宏觀環境，技術趨勢，競爭對手，內外部客戶的信息。
4：組織對于產品相關的各種戰略，計劃，策略的審計工作。
5：研究市場動態，提交市場研究報告，選擇細分市場，確定產品定位。
6：收集各個部門第產品初始業務/路標的意見。
三：產品設計階段
1：組織完成從產品創意到產品設計，形成完整的產品業務需求。
2：組織對產品設計的測試工作。
3：提交完成的產品業務需求，協調相關資源。
4：提交產品開發任務書，獲得授權，督導產品開發工作。
四：產品開發階段
1：監督產品開發計劃，產品業務需求的完成情況。
2：組織產品的市場調研工作，收集產品信息，根據需要調整產品業務需求和產品開發計劃。
3：組織或者參與研發開發階段評審。
4：協調資源對產品開發過程中的中間交付件進行測試。
5：指導產品開發過程。
五：產品測試階段
1：組織產品的測試工作。
2：制定產品的上市計劃，為產品上市做培訓，文檔等前期準備工作。
六：產品發布階段
1：負責產品的市場發布工作。
2：指導并監督產品的運營和銷售工作。
3：協同財務/市場部門監控產品的盈利情況，提出新的營銷策略。
4：根據市場反饋，提出產品的改進意見/監督執行。
一、什么是架構
架構就是系統的結構，是一種機制。
架構就是系統的結構。你建立架構來解釋將來系統的結構和這種結構如何支撐業務需求和非功能需求。你可以定義這種結構作為一種機制，系統如何用來解決一些普遍問題。這個機制有能力以統一的方式支持業務需求。例如，持久化機制必須被系統統一使用，這意味著，任何時候系統如果要做持久化，必須以同樣的方式。將持久化機制定義后，你就提供了一種默認的所有設計人員必須遵循的方式。這些架構體制，如持久化、分布式、通訊、交易管理和安全就是你建立系統的基礎，而且必須得建立的。
什么是建立架構呢？就是你建立的符合系統中規定的非功能需求的基礎。例如，系統中說明對用戶的反應時間不能超過3秒，你建立的軟件基礎就必須符合這個需求。這同時也意味著你已經給設計人員一個允許他們設計和編碼來建立系統時而不必擔心這些非功能需求。一個關于架構中比較真實的問題是：架構的建立什么時候停止，設計流程什么時候開始？對于每個系統沒有最終答案。這個架構和設計的問題可以被總結起來和控制。架構定義了將會建立什么，設計了你怎樣建立系統的外框。一個或少數人關注全景來控制架構的流程，其他多數人關注如何實現全景是設計所要控制的。架構師設計架構，設計團隊在這個架構中用它來達成系統的全部目標。因此，如果你正在為有經驗的設計人員建立架構，你就不必象為缺少經驗的設計人員那樣提供盡可能詳盡的文檔。
當你在建立架構來沒跟系統的非功能需求時你通常不會有無限制的資金來購買硬件、軟件和開發資源，因此你必須使系統能在有限的預算中很好的運行。例如，當你只有一臺電腦來支撐內部用戶時，你怎樣建立可拓展的系統來滿足互聯網時代？沒有資金來購買軟件產品時，你怎樣建立架構？這些就是架構師們建立系統架構時面對的問題的例子。你會面臨很多困難的選擇，和做很多取舍來解決這類問題。由于你作了取舍，很重要的是取舍你必須用文檔說明，使得開發人員能夠理解為什么要作這個取舍，這樣你就不會收到來自開發人員的問題了。如果你決定使用ORACLE在系統中，你就必須用文檔注明為什么要選擇ORACLE而不選其他數據庫。你建立架構時的取舍關注非功能需求。大多數系統沒有足夠的資金來滿足所有的非功能性需求。作為架構師，你就必須平衡非功能需求和預算之間的矛盾。如果要做24*7的高可用光是購買硬件花掉了你全部的預算，那就是說沒有多余的錢來購買應用服務器來維護非功能需求了，你就必須調整你的軟件架構了。調整依賴于你正在建立架構的系統和與投資人的關系。
二、架構師角色
架構師必須具有以下特點。
架構師必須是一個全面的，成熟的，有經驗的，受過教育的，學習迅速的，一個領導者，很好的溝通，和在必須時候作出困難的決定。全面的是指，架構師必須具有業務和問題領域的工作知識。他們能夠通過經驗和教育獲取這些知識。另外架構師也必須具有廣闊的技術知識。一個好的架構師能夠評估所有可能的方案不管使用何種技術。
架構師要做些什么？架構師與資深開發人員有什么不同？這些都是一些常問的問題。設計師考慮一個用戶按下一個按鈕時將會發生什么，架構師則考慮成行千上萬的用戶按下一個按鈕時將會發生什么。架構師要減輕和系統相關的風險。技術風險可能是未知的、未證明的或未測試的。風險來自非功能需求，有時也可能來自業務需求。不管哪種風險，都很容易地盡早地在建立架構階段指出這個風險。
架構師必須領導開發團隊保證設計師的開發人員根據這個架構一構建系統。關于取舍必須作出困難的決定，作為領導者，就是作決定的人。為了領導項目團隊，架構師必須是一個好的溝通者，包括讀和寫。通常是通過虛擬模型和群組討論。如果架構師不能很好的溝通，設計師和開發人員也許不能正確地構建系統。
這個適合大數據量的分布式的企業環境。
Lily以NoSQL技術為主題，是建立在云計算上的內容倉庫(content repository)。
它是基于Apache的
HBase(存儲)和
Solr(索引/搜索)，并提供了大型內容集合存儲與檢索的解決方案。
可運用在門戶網站，內容管理系統，及時搜索，檔案應用，文案管理，等等。
從ITEYE上看到的，郁悶的是找不到發貼人了
從 ITeye論壇最新討論
1.Web - Application Developer
Must to have:
熟悉Java 開發，有3-4年Java Web開發經驗
熟悉常用J2EE規范，JSP， Servlet，JDBC
熟悉SQL，能熟練寫常用SQL script，了解常用的SQL性能優化
熟悉常用的開源框架，Spring，Spring MVC or Struts2, OR-Maping (Hibernate, iBatis, JPA)
Nice to have:
熟悉Web Service，Hessian 等常用的遠程交互協議
熟悉Ajax等Web 2.0技術, JavaScript框架 （jQuery/Dojo）
熟悉常用的設計模式，能識別代碼中的設計模式
熟悉Junit testNG 等單元測試框架
熟悉WAS, Tomcat, JBoss等應用服務器
熟悉SVN, CVS等代碼管理工具
有使用Maven，Ant的經驗
有電商經驗者優先
--------------------------------------------------------
2. Web - Application Developer: e-Commerce
熟悉Java 開發, 3-4年工作經驗，熟悉jquery, EXTJS，能對頁面進行調試，了解各種調試工具，如：firebug，firecookies，yslow，pagespeed
對jquery plugin有一定研究，最好自己開發過插件，有自己開發js框架經驗
對開源框架有深入研究，比如SSH（Spring，Struts，Hibernate等）
熟悉設計模式
熟悉FreeMarker（開發過宏者優先）, Jstl(開發過tag lib者優先）等頁面展示技術
熟悉UML，有一定的業務建模和數據建模經驗。
熟悉面向對象的開發。
熟悉html，CSS。
熟悉主流應用服務器和數據庫。
有大型互聯網前端開發經驗優先
-------------------------------------------------------------
3.Web - Sr. IT specialist - Andriod
五年以上開發經驗
精通Android Framework, 3年以上Android開發和Android系統定制經驗
精通三大組件（Activity/Service/Broadcast Receiver）及其應用，理解常用組件API及各項特性
精通Android UI體系并能熟練完成各個分辨率下的排版及動畫
了解Android底層, 能獨立解決各類機型和ROM的適配
熟練掌握Java基礎開發
對常用協議及服務器端開發有所了解更佳
熟悉對多媒體和流媒體的處理
有交互式用戶體驗經驗
有互聯網或電子商務終端產品經驗優先
--------------------------------------------------------------
4.Application Architect - eCommerce
熟悉java開發，7年以上java開發經驗，5年以上java web開發經驗
至少2年電子商務行業相關開發經驗
2-3年WCS 經驗 或 精通 FileNet
樂于研究技術，對新技術有較強的敏感，了電子商務行業最新技術，框架，工具
精通UML建模，有較強的撰寫架構設計文檔能力，能熟練使用設計模式進行架構設計
熟悉常用的開源框架，Spring，Spring MVC, Struts2 , Ibatis
熟悉Websphere application server，jboss， tomcat等應用服務器的使用和配置
有帶團隊的經驗，有一定的組織領導能力
-------------------------------------------------------------------------
5.Application Developer - QT/C++
五年以上開發經驗
精通C++，三年以上C++開發經驗
精通Windows底層協議和Windows API（主要是Windows XP和Windows 7）
熟練掌握QT開發工具，具備兩年以上經驗，熟悉Linux
熟練掌握數據結構和常用算法
具備較強的系統分析能力
具備跨平臺系統級開發經驗者優先（Windows/Linux/Mac/Android）
有互聯網或電子商務終端產品經驗優先
-------------------------------------------------------------------------
6. Technical Team Leader - QT/C++
8年以上開發經驗
精通C++，三年以上C++開發經驗
精通Windows底層協議和Windows API（主要是Windows XP和Windows 7）
熟練掌握QT開發工具，具備兩年以上經驗，熟悉Linux
熟練掌握數據結構和常用算法
----------------------------------------------------------------------------
7.Application Developer - Power Builder
5年以上工作經驗，包括3年以上的PowerBuilder開發經驗
熟悉Java開發，熟悉POS業務者優先
有零售行業經驗者優先
------------------------------------------------------------------------------
8.Technical Team Leader - Power Builder
8年以上工作經驗，包括5年以上的PowerBuilder開發經驗
精通J2EE開發，熟悉POS業務
必須具備3年以上零售行業經驗
--------------------------------------END--------------------------------------
以上職位IBM目前正在熱招，請有意者與我聯系。
作者: 無聊人士
基于公開密鑰的加密過程 比如有兩個用戶Alice和Bob，Alice想把一段明文通過雙鑰加密的技術發送給Bob，Bob有一對公鑰和私鑰，那么加密解密的過程如下：
Bob將他的公開密鑰傳送給Alice。
Alice用Bob的公開密鑰加密她的消息，然后傳送給Bob。
Bob用他的私人密鑰解密Alice的消息。
Alice使用Bob的公鑰進行加密，Bob用自己的私鑰進行解密。
基于公開密鑰的認證過程 身份認證和加密就不同了，主要用戶鑒別用戶的真偽。這里我們只要能夠鑒別一個用戶的私鑰是正確的，就可以鑒別這個用戶的真偽。
還是Alice和Bob這兩個用戶，Alice想讓Bob知道自己是真實的Alice，而不是假冒的，因此Alice只要使用公鑰密碼學對文件簽名發送給Bob，Bob使用Alice的公鑰對文件進行解密，如果可以解密成功，則證明Alice的私鑰是正確的，因而就完成了對Alice的身份鑒別。整個身份認證的過程如下：
Alice用她的私人密鑰對文件加密，從而對文件簽名。
Alice將簽名的文件傳送給Bob。
Bob用Alice的公鑰解密文件，從而驗證簽名。
Alice使用自己的私鑰加密，Bob用Alice的公鑰進行解密。
根證書 根證書是CA認證中心給自己頒發的證書,是信任鏈的起始點。安裝根證書意味著對這個CA認證中心的信任。
總結 根據非對稱密碼學的原理，每個證書持有人都有一對公鑰和私鑰，這兩把密鑰可以互為加解密。公鑰是公開的，不需要保密，而私鑰是由證書持人自己持有，并且必 須妥善保管和注意保密。
數字證書則是由證書認證機構（CA）對證書申請者真實身份驗證之后，用CA的根證書對申請人的一些基本信息以及申請人的公鑰進行簽名（相當于加蓋發證書機 構的公章）后形成的一個數字文件。CA完成簽發證書后，會將證書發布在CA的證書庫（目錄服務器）中，任何人都可以查詢和下載，因此數字證書和公鑰一樣是 公開的。
可以這樣說，數字證書就是經過CA認證過的公鑰，而私鑰一般情況都是由證書持有者在自己本地生成的，由證書持有者自己負責保管。具體使用時，簽名操作是發 送方用私鑰進行簽名，接受方用發送方證書來驗證簽名；加密操作則是用接受方的證書進行加密，接受方用自己的私鑰進行解密。
轉載自：http://hi.baidu.com/parryblog/blog/item/2d1ae59a72b043bcc9eaf4a0.html
本篇開始之前先扯點閑話，商業應用系統開發經歷了三個階段：
第一個階段以計算為中心，分析設計圍繞程序的運行效率，算法優劣，存貯優化來進行。90年代的大學課程講的都是這些。
第二階段以數據為中心，分析設計圍繞數據流進行，以數據流程來模擬業務流程。這也就是所謂的面向過程的分析模式。
第三階段以人為中心，分析設計圍繞人的業務需求，使用要求，感受要求進行。這也就是現在的面象對象分析模式。
使用OO方法建立商業模型必須先定義涉眾。商業系統無論多復雜，無論什么行業，其本質無非是人，事，物，規則。人是一切的中心，人做事，做事產生物，規則限制人事物。人驅動系統，事體現過程，物記錄結果，規則則是控制。無論OO也好，UML也好，復雜的表面下其實只是一個簡單的規則，系統分析員弄明白有什么人，什么人做什么事，什么事產生什么物，中間有什么規則，再把人，事，物之間的關系定義出來，商業建模也就基本完成了。這時候可以說，系統分析員已經完全了解了用戶需求，可以進入系統建模階段了。
書歸正傳，上篇筆者歸納了一些典型的涉眾類型及他們的普遍期望。接下來，就是要將他們這些期望定義出來。這個過程，就是業務用例獲取的過程。筆者可以跟大家分享的經驗是通過以下步驟進行，這些步驟并非唯一正確，對于經驗不多的系統分析員來說，這些步驟很有指導意義。
筆者做了一個建模實例，有需要有讀者請到筆者的BLOG資源中心下載，實例以上一篇所述網上圖書館需求為藍本建立了業務用例模型，之后的概念模型、系統模型則抽取了其中的借閱過程作為例子。不記得了可以后頭找找。
建模第一步，從涉眾中找出用戶。并定義這些用戶之間的關系。在ROSE中，應該使用business actor 類型。參考上一篇的需求描述，下載實例
第二步，找出每個用戶要做的事，即業務用例，在ROSE中應使用Business use case類型。請參考《用例的類型與粒度》一文以幫助確定用例的粒度。筆者強烈建議為每一個business actor繪制一個業務用例圖，這能很好的體現以人為中心的分析模式，并且不容易漏掉business actor需要做的事。至于以參與者為中心的視圖容易漏掉某個業務用例的參與者的擔心，可以在第四步中得到消除。下載實例
第三步，利用業務場景圖幫助分析業務流程，在ROSE中，這個階段最好使用活動圖Activity diagram。在這個階段，業務場景圖非常重要，在繪制過程中，系統分析員必須采用第一步中定義的用戶名字作為泳道名，使用第二步中定義的業務用例名作為活動名來繪制。必須這么做的原因是，如果你無法把利用已經定義出來的 business actor 和 business use case完備的描繪業務流程，那么一定是前面的定義出問題了，你需要回頭審視是否 business actor 和 business use case定義不完善或錯誤。如果不是所有的business actor 和 business use case 都被用到，要么應該檢查業務流程調研時漏了什么，要么應該檢查是否定義了一些無用的business actor 和 business use case 。同時，繪制業務場景圖也非常有助于選擇合適的用例粒度并保持所有的用例都是同一粒度。下載實例
第四步，繪制用例場景圖。與業務場景圖不同的是，用例場景圖只針對一個用例繪制該用例的執行過程。筆者仍然強烈推薦使用activity diagram。在用例場景圖的繪制中，必須使用第一步中定義的業務用戶作為泳道。必須這么做的原因是，它能幫助你發現在定義業務用例圖時的錯誤，比如是否漏掉了某個業務用例的潛在使用者。不是每個業務用例都需要繪制場景圖，只有兩三個步驟的業務用例是不必一定繪制業務用例圖的，但仍然需要在業務用例規約文檔中寫明。下載實例
第五步，從第三步或第四步中繪制的活動圖中找到每一步活動將使用到的或產生的結果。這是找到物的過程。找到后，應當建立這些物之間的關系。在ROSE中，這稱為業務實體模型。應該使用business entity 類型。下載實例
第六步，在上述過程中，隨時補充詞匯表Glossary。將此過程中的所有業務詞匯，專業詞匯等一切在建模過程中使用到的需要解釋的名詞。這份文檔將成為模型建立人與讀者就模型達成一致理解的重要保證。
第七步，根據上一篇中提到的業主，老板等涉眾的期望審視建立好的模型，確定業務范圍，決定哪些業務用例在系統建設范圍內。那些不打算納入建設范圍內的業務用例有兩種情況，一種是該業務用例是被調用一方，那么應該把它改為 boundary 類型，意味著將來它是一個外部接口。另一種是該業務用例主動調用系統內業務用例，那么應該將它改為business actor類型。與普通business actor不同的是，由業務用例轉換而成的business actor不是人，而通常是一個外部系統進程，因此應該在被調用的系統內業務用例與它之間增加一個boundary元素，意味著我們的系統將為這樣一個外部進程提供一個接口。嚴格來說，那些需要納入建設范圍的business use case 應當對應的生成一個 business use case realization， 以后的設計工作將歸納到這些實現用例中。但筆者覺得這一步并非很關鍵的，實際中本人也經常省略這一步，而將協作圖，象活動圖，類交互圖等直接在business usecase下說明。不過本實例中筆者還是按照正規方法來建模的。下載實例
需要說明的是，上述的步驟并非一次性完成的，在每一個步驟中都可能導致對以前步驟的調整。即使建模已經完成，當遇到變化或發現新問題時，上述步驟應當從頭到尾再執行一次。這也是RUP倡導的迭代開發模式。
經過以上的步驟，我們已經建立了一個完整的業務模型。但這決不是建模工作的全部，以上過程只說明了建立一個完整業務模型的過程，不能說這樣就建立了一個很好的業務模型。因為上述的過程中并沒有提及業務分析過程。分析過程全憑系統分析員的經驗，對OO的理解和對行業業務的把握能力，對原始業務模型進行歸納，整理，抽象，重構，以建立一個更高效，合理，擴展性更強的模型。這個過程無法以步驟說明。或許以后筆者會專門針對模型分析寫點東西。另外除了模型，還至少需要寫業務架構文檔、用例規約和補充用例規約三種文檔。因為模型雖然可以較好的體現業務架構，但很不好表達業務規則和非業務需求，這些需要在文檔中說明。例如用例的前置條件和后置條件就是一種業務規則。讀者可以在RUP文檔中找到這些文檔的模板。