需求分析師培訓2

需求分析師培訓Day02Agenda需求分析最佳實踐需求建模最佳實踐用例驅(qū)動的需求過程實踐Agenda需求分析最佳實踐需求建模最佳實踐用例驅(qū)動的需求過程實踐需求分析是需求工程中的核心需求分析回顧所謂分析是指通過對問題域的研究，獲得對該領(lǐng)域特性及存在于其中（需要解決）的問題特性的透徹理解并用文檔說明分析方法：結(jié)構(gòu)化分析法、面向?qū)ο蠓治龇?、面向問題域分析法需求分析與需求捕獲是交替進行的需求分析的結(jié)果將通過建模、規(guī)格說明

書編寫的方式文檔化需求分析最佳實踐1定義系統(tǒng)邊界：評估原始需求，定義將要開發(fā)的系統(tǒng)的邊界；確定哪些是系統(tǒng)需求，哪些是和系統(tǒng)相關(guān)的操作過程的需求，哪些是在系統(tǒng)范圍之外的需求

>主要效益：消除不必要的需求

>引入成本：低>應用成本：低

>實施指南：詢問某項需求是否是基于不完整的或者不可靠的信息做出的？某項需求的實現(xiàn)

是否需要在系統(tǒng)已定義的數(shù)據(jù)庫之外的

信息？某項需求是否和系統(tǒng)的核心功能

相關(guān)？某項需求是否牽涉到系統(tǒng)之外的

功能或者設(shè)備的性能？需求分析最佳實踐2使用校驗表進行需求分析：根據(jù)經(jīng)驗開發(fā)需求問題校驗表，并將其用于需求的系統(tǒng)化分析，每一項需求都應按照校驗表進行分析。

>主要效益：更快、更完整地進行需求分析

>引入成本：低-中>應用成本：低

>實施指南：校驗表不超過10項

草率設(shè)計：該需求包括不成熟設(shè)計或?qū)崿F(xiàn)信息嗎？

組合需求：該需求是單獨的需求還是可以細分為多個需求？

多余需求：該需求只是系統(tǒng)的修飾，還是真正必需？

使用非標準硬件：必須使用非標準的硬件還是軟件？

符合業(yè)務目標：符合在需求文檔開始處定義的業(yè)務目標？

需求多義性：不同人是否可以從不同方式來理解？

需求可實現(xiàn)性：基于當前技術(shù)，該需求可實現(xiàn)嗎？

需求可測試性：是否能夠判斷系統(tǒng)是否符合需求需求分析最佳實踐3使用軟件支持協(xié)商：鼓勵使用電子郵件來交換需求信息并且進行需求協(xié)商；也可以使用BBS、即時通信、群件系統(tǒng)來進行溝通與協(xié)商。

>主要效益：需求問題的更快解決

>引入成本：低-中>應用成本：低-中

>實施指南：電子郵件需指派一個問題管理人員，負責跟蹤問題的提出、傳遞、回應和達成

解決方案；BBS方案需要限制討論的長

度；群件方案需要事行定義好需求管理

項的結(jié)構(gòu)需求分析最佳實踐4對沖突和沖突解決方案做好計劃：任何需求集中都會有沖突、重疊和遺漏問題，應該安排會議討論這些需求并解決分析過程中發(fā)現(xiàn)的問題。

>主要效益：需求問題的更快解決

>引入成本：低>應用成本：低

>實施指南：會議是解決需求沖突最快的方式，應聚焦于解決突出的需求問題；電子信息交

換也是可取的方式之一；會議通常包括

敘述階段、討論階段和決策階段；分析

的結(jié)果要發(fā)給所有與會者需求分析最佳實踐5需求分級：每一項需求都應該標上優(yōu)先級，以反映它們對項目相關(guān)人員的重要性和對整個系統(tǒng)成功與否的重要性。

>主要效益：關(guān)注最重要的需求

>引入成本：低>應用成本：低

>實施指南：在需求捕獲階段就標明優(yōu)先級是最理想的；通常需要進行了初始的分析工作才

可能分配優(yōu)先級；優(yōu)先級的分配要由需

求分析人員和項目相關(guān)人員共同完成；

優(yōu)先級不應太多，如必須的、有用的、

希望的需求分析最佳實踐6使用多維方法進行需求分類：應對需求進行分類以便標記相關(guān)的需求，不必將單個需求只歸到一個類，可以派生出多種分類方法。

>主要效益：有助于發(fā)現(xiàn)需求重疊和沖突

>引入成本：低-中>應用成本：中

>實施指南：可用系統(tǒng)、用戶界面、數(shù)據(jù)庫、通信、安全來進行分類；建議最多有5~6個分

類；決定分類后，應把每個需求都和一

到多個關(guān)鍵詞關(guān)聯(lián)起來；分類完成后，

可以抽取很多組具有相同分類的需求進

行比較和分析需求分析最佳實踐7使用交互矩陣發(fā)現(xiàn)沖突與重疊：交互矩陣的每一行和每一列都代表一項需求，每一個元素都用來表示對應的需求是否沖突、重疊或者獨立

>主要效益：揭示需求重疊和沖突

>引入成本：低>應用成本：中-高

>實施指南：創(chuàng)建交互矩陣最簡單的方法是使用電子表格程序，在首行、首列均標上需求標

識符；然后如果需求沖突填入1、重疊填

入1000，獨立則填0；這樣只需要用求

和的方式來統(tǒng)計出各種數(shù)目；通常需求

不應超過200條需求分析最佳實踐8評估需求風險：對每一項需求或者一系列相關(guān)的需求進行風險分析，指出在實現(xiàn)需求過程中可能會發(fā)生的問題、這些問題發(fā)生的機率及其影響。

>主要效益：標識有問題的需求

>引入成本：中>應用成本：中

>實施指南：應考慮的風險主要有性能風險、安全風險、過程風險、實現(xiàn)技術(shù)風險、數(shù)據(jù)庫

風險、日程風險、外部風險、穩(wěn)定風險Agenda需求分析最佳實踐需求建模最佳實踐用例驅(qū)動的需求過程實踐需求建模是表述需求的關(guān)鍵手段模型是對現(xiàn)實的簡化建模的目的與原則幫助我們按照實際情況或按我們需要的樣式對系統(tǒng)進行可視化；提供一種詳細說明系統(tǒng)的結(jié)構(gòu)或行為的方法；給出一個指導系統(tǒng)構(gòu)造的模板；對我們所做出的決策進行文檔化僅當需要模型時，才構(gòu)建它選擇要創(chuàng)建什么模型對如何動手解決問題和如何形成解決方案有著意義深遠的影響；每一種模型可以在不同的精度級別上表示；最好的模型是與現(xiàn)實相聯(lián)系的；單個模型是不充分的。對每個重要的系統(tǒng)最好用一組幾乎獨立的模型去處理。系統(tǒng)建模最佳實踐1開發(fā)互補的模型：在單個模型中包含所有的系統(tǒng)規(guī)格說明信息是難以實現(xiàn)的，因為這樣的系統(tǒng)將會特別復雜，不可能讀懂，因此應該創(chuàng)建多個系統(tǒng)模型。

>主要效益：揭示規(guī)格說明中的錯誤和不一致

>引入成本：低-中>應用成本：中

>實施指南：通常會開發(fā)數(shù)據(jù)處理模型(DFD)、組合模型(E-R)、分類模型(類圖)、刺激-響應模型(狀態(tài)圖、活動圖)、過程模型等；選擇什么模

型取決于要說明的信息類型、模型的讀

者、模型開發(fā)者的技能、CASE工具系統(tǒng)建模最佳實踐2系統(tǒng)環(huán)境建模：為了理解需求，應該就系統(tǒng)環(huán)境開發(fā)一個或多個模型，應該說明和本系統(tǒng)的接口和其他系統(tǒng)，以使用可能會使用本系統(tǒng)的業(yè)務過程。

>主要效益：記錄必須說明接口的外部系統(tǒng)

>引入成本：低>應用成本：低

>實施指南：環(huán)境模型就是系統(tǒng)的使用語境模型，應包括和本系統(tǒng)直接交互的其他系統(tǒng)、可能和本系統(tǒng)共存并發(fā)生交互的系統(tǒng)、系統(tǒng)所在的業(yè)務

過程。系統(tǒng)建模最佳實踐3系統(tǒng)體系結(jié)構(gòu)建模：每次都應該開發(fā)系統(tǒng)的體系結(jié)構(gòu)模型，用來說明系統(tǒng)是如何分解成子系統(tǒng)，還應解釋子系統(tǒng)之間的通信。

>主要效益：有助于劃分系統(tǒng)需求

>引入成本：低-中>應用成本：低

>實施指南：常用的體系結(jié)構(gòu)模型包括客戶機-服務器系統(tǒng)、分層系統(tǒng)、基于共享庫通信的系統(tǒng)、管道系統(tǒng)系統(tǒng)建模最佳實踐4用標準化方法進行系統(tǒng)建模：標準化方法是一種系統(tǒng)分析和設(shè)計方法，包括定義、開發(fā)和確認系統(tǒng)模型過程中用到的表示法、指南和規(guī)則。

>主要效益：使用標準的方式書寫系統(tǒng)模型

>引入成本：中-高>應用成本：中

>實施指南：包括過程化(結(jié)構(gòu)化)方法、面向?qū)ο蠓椒?，其主要包括一組推薦的系統(tǒng)模型和相應的開發(fā)該模型的表示法、一組建模規(guī)則、一組關(guān)

于創(chuàng)建高質(zhì)量系統(tǒng)模型的指南、一份描

述、一些報告。系統(tǒng)建模最佳實踐5使用數(shù)據(jù)字典：系統(tǒng)建模中使用的名字都應當記錄在數(shù)據(jù)字典中，它是一份由計算機維護的名字列表以及相關(guān)的信息。

>主要效益：避免名字重復使用和誤解

>引入成本：中>應用成本：低

>實施指南：進行數(shù)據(jù)字典的至少應包括模型中實體的名字、名字的別名及變化、實體類型、為何引入模型、針對實體的約束、指向相關(guān)實體的

鏈接；數(shù)據(jù)字典必須由一臺服務器維護，

開發(fā)人員本機要與服務器經(jīng)常實現(xiàn)同步系統(tǒng)建模最佳實踐6記錄項目相關(guān)人員需求和系統(tǒng)模型之間聯(lián)系：記錄項目相關(guān)人員用自然語言描述的需求和說明這個系統(tǒng)的具體模型之間的關(guān)系。

>主要效益：便列發(fā)現(xiàn)受變更影響的需求和模型

>引入成本：低>應用成本：中

UML基礎(chǔ)UML發(fā)展歷程UML特性與發(fā)展現(xiàn)狀UML是一種Language（語言）UML是一種Modeling（建模）LanguageUML是Unified（統(tǒng)一）ModelingLanguage已進入全面應用階段的事實標準應用領(lǐng)域正在逐漸擴展，包括嵌入式系統(tǒng)建模、業(yè)務建模、流程建模等多個領(lǐng)域成為“產(chǎn)生式編程”的重要支持技術(shù)：MDA、

可執(zhí)行UML等為什么使用UML建模UML是一種統(tǒng)一的、標準化的建模語言UML是一種應用面很廣泛的建模語言模型的種類模型的用途業(yè)務模型對業(yè)務過程、工作流、組織的建模需求模型對捕獲的需求進行整理和分析的工具，輔助開發(fā)人員與用戶進行溝通設(shè)計模型包含高層設(shè)計（架構(gòu)模型）和詳細設(shè)計模型，用于統(tǒng)一開發(fā)人員、溝通設(shè)計信息數(shù)據(jù)庫模型設(shè)計數(shù)據(jù)庫的結(jié)構(gòu)、表結(jié)構(gòu)以及與應用系統(tǒng)的交互實現(xiàn)模型用來理清軟件的組成、部署方案，為安裝與維護人員的工作提供指導草圖和藍圖藍圖一般是指采用CASE工具繪制的、正式的、規(guī)范的UML模型草圖則通常是指手工繪制的、規(guī)范度較低的在紙張的UML模型大膽地繪制草圖，盡可能基于草圖進行討論。對于局部的、重要性不高的、共享范圍較小的UML模型，直接將草圖掃描到電腦存檔即可；對于全局的、重要性高的、高度共享的，在草圖的基礎(chǔ)上用CASE工具繪制成為正式的藍圖，并將其納入統(tǒng)一的模型管理中誰應該建模業(yè)務建模：以領(lǐng)域?qū)＜覟橹?，需求分析人員是主力，系統(tǒng)分析員、架構(gòu)師可參與需求模型：以需求分析人員為主，系統(tǒng)分析員是主力，領(lǐng)域?qū)＜姨峁┲笇?，架?gòu)師和資深開發(fā)人員參與設(shè)計模型：高層設(shè)計模型以架構(gòu)師為主，系統(tǒng)分析員從需求方面提供支持，資深開發(fā)人員從技術(shù)實現(xiàn)方面提供支持。詳細設(shè)計模型則以資深開發(fā)人員為主，架構(gòu)師提供指導。實現(xiàn)模型：以資深開發(fā)人員（設(shè)計人員）為主，架構(gòu)師提供總體指導。數(shù)據(jù)庫模型：以數(shù)據(jù)庫開發(fā)人員為主，架構(gòu)師提供指導，資深開發(fā)人員（設(shè)計人員）予以配合。常見認識誤區(qū)UML是一種方法論UML就是一堆圖形UML只能夠應用于面向?qū)ο箝_發(fā)中UML就是Rose里的符號UML的學習周期很長、很復雜UML的組成基本構(gòu)造塊：也就是建模

元素，是模型的主體UML規(guī)則：也就是支配基

本構(gòu)造塊如何放在一起的

規(guī)則公共機制：運用于整個

UML模型中的公共機制、

擴展機制事物構(gòu)造塊事物構(gòu)造塊是對模型中最具有代表性的成分的抽象結(jié)構(gòu)事物：UML中的名詞，它是模型的靜態(tài)部分，描述概念或物理元素。行為事物：UML中的動詞，它是模型中的動態(tài)部分，是一種跨越時間、空間的行為。分組事物：UML中的容器，用來組織模型，使模型更加的結(jié)構(gòu)化。注釋事務：UML中的解釋部分，和代碼中的注釋語句一樣，是用來描述模型的。面向?qū)ο笠暯窍碌氖澜缡紫冉⒎磻F(xiàn)實世界中不同事物的“構(gòu)造塊”，然后確定“構(gòu)造塊”之間的“關(guān)系”，再確定各個構(gòu)造塊的屬性和“行為”。這樣，在軟件系統(tǒng)中就可以模擬現(xiàn)實世界的“構(gòu)造塊”之間的交互與協(xié)作面向?qū)ο筌浖_發(fā)的核心思想就是高內(nèi)聚（封裝）、低耦合（消息驅(qū)動），使用簡潔的接口拼合簡單的部件結(jié)構(gòu)事物類（class）和對象（object）接口（interface）主動類（activeclass）用例（usecase）協(xié)作（collaboration）構(gòu)件（component）節(jié)點（node）類和對象類是對一組具有相同屬性、相同操作、相同關(guān)系和相同語義的對象的抽象UML中類是用一個矩形表示的，它包含三個區(qū)域，最上面是類名、中間是類的屬性、最下面是類的方法對象則是類的一個實例接口接口是描述某個類或構(gòu)件的一個服務操作集主動類主動類實際上是一種特殊的類。引用它的原因，實際上是在開發(fā)中需要有一些類能夠起到

啟動控制活動的作用主動類是指其對象至少擁有一個進

程或線程，能夠啟動控制活動的類用例與協(xié)作用例是著名的大師IvarJacobson首先提出的，現(xiàn)已經(jīng)成為了面向?qū)ο筌浖_發(fā)中一個需求分析的最常用工具用例實例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成特定執(zhí)行者可見的價值結(jié)果。

一個用例定義一組用例實例。協(xié)作定義了一個交互，它是由一組共同工作以提供某協(xié)作行為的角色和其他元素構(gòu)

成的一個群體。對于某個用例的實現(xiàn)就可

以表示為一個協(xié)作構(gòu)件在實際的軟件系統(tǒng)中，有許多要比“類”更大的實體，例如一個COM組件、一個DLL文件、一個JavaBeans、一個執(zhí)行文件等等。為了更好地對在UML模型中對它們進行表示，就引入了構(gòu)件（也譯為組件）構(gòu)件是系統(tǒng)設(shè)計的一個模塊化部分，它隱藏了內(nèi)部的實現(xiàn)，對外提供了一組外部接口。在系統(tǒng)中滿足相同接口的組件可以自由地替換節(jié)點為了能夠有效地對部署的結(jié)構(gòu)進行建模，UML引入了節(jié)點這一概念，它可以用來描述實際的PC機、打印機、服務器等軟件運行的基礎(chǔ)硬件節(jié)點是運行時存在的物理元素，它表示了一種可計算的資源，通常至少有存儲空間和處理能力行為事物交互（interaction）：是在特定語境中，共同完成某個任務的一組對象之間交換的信息集合交互的表示法很簡單，就是一條有向直線，并在上面標有操作名狀態(tài)機（statemachine）：是一個對象或交互在生命周期內(nèi)響應事件所經(jīng)歷的狀態(tài)序列在UML模型中將狀態(tài)畫為一個圓

角矩形，并在矩形內(nèi)寫出狀態(tài)名

稱及其子狀態(tài)分組事物對于一個中大型的軟件系統(tǒng)而言，通常會包含大量的類，因此也就會存在大量的結(jié)構(gòu)事物、行為事物，為了能夠更加有效地對其進行整合，生成或簡或繁、或宏觀或微觀的模型，就需要對其進行分組。在UML中，提供了“包（Package）”來完成這一目標注釋事物結(jié)構(gòu)事物是模型的主要構(gòu)造塊，行為事物則是補充了模型中的動態(tài)部分，分組事物而是用來更好地組織模型，似乎已經(jīng)很完整了。而注釋事物則是用來錦上添花的，它是用來在UML模型上添加適當?shù)慕忉尣糠株P(guān)系構(gòu)造塊—關(guān)聯(lián)關(guān)系關(guān)聯(lián)（Association）表示兩個類之間存在某種語義上的聯(lián)系。關(guān)聯(lián)關(guān)系提供了通信的路徑，它是所有關(guān)系中最通用、語義最弱的。在UML中，使用一條實線來表示關(guān)聯(lián)關(guān)系在關(guān)聯(lián)關(guān)系中有兩種比較特殊的關(guān)系：聚合和組合聚合關(guān)系：聚合（Aggregation）是一種特殊形式的關(guān)聯(lián)。聚合表示類間的關(guān)系是整體與部分的關(guān)系如果發(fā)現(xiàn)“部分”類的存在，是完全依賴于“整體”類的，那么就應該使用“組合”關(guān)系來描述關(guān)系構(gòu)造塊—其他關(guān)系泛化關(guān)系描述了一般事物與該事物中的特殊種類之間的關(guān)系，也就是父類與子類之間的關(guān)系。實現(xiàn)關(guān)系是用來規(guī)定接口和實現(xiàn)接口的類或組件之間的關(guān)系。接口是操作的集合，這些操作用于規(guī)定類或組件的服務。擴展表示將一個構(gòu)造型附加到一個元類上，使得元類的定義中包括這個構(gòu)造型。有兩個元素X、Y，如果修改元素X的定義可能會引起對另一個元素Y的定義的修改，則稱元素Y依賴于元素X。UML規(guī)則命名：也就是為事物、關(guān)系和圖起名字。和任何語言一樣，名字都是一個標識符范圍：與類的作用域相似，包括所有者作用域和目標作用域兩類可見性：可見性規(guī)則標準表示法Rose屬性Rose方法public任一元素，若能訪問包容器，就可以訪問它+

protected只有包容器中的元素或包容器的后代才能夠看到它#

private只有包容器中的元素才能夠看得到它-

package只有聲明在同一個包中的元素才能夠看到該元素~公共機制—規(guī)格描述在圖形表示法的每個部分后面都有一個規(guī)格描述（也稱為詳述），它用來對構(gòu)造塊的語法和語義進行文字敘述。這種構(gòu)思，也就使可視化視圖和文字視圖的分離：公共機制—UML修飾與通用劃分在為了更好的表示這些細節(jié)，UML中還提供了一些修飾符號，例如不同可視性的符號、用斜體字表示抽象類UML通用劃分：

1）類與對象的劃分：類是一種抽象，對象是一個具體的實例

2）接口與實現(xiàn)的分離：接口是一種聲明、是一個契約，也是服務的入口；實現(xiàn)則是負責實施接口提供的契約UML擴展機制構(gòu)造型：在實際的建模過程中，可能會需要定義一些特定于某個領(lǐng)域或某個系統(tǒng)的構(gòu)造塊UML擴展機制標記值：則是用來為事物添加新特性的。標記值的表示方法是用形如“{標記信息}”的字符串約束：是用來增加新的語義或改變已存在規(guī)則的一種機制（自由文本和OCL兩種表示法）。約束的表示法和標記值法類似，都是使用花括號括起來的串來表示，不過它是不能夠放在元素中的，而是放在相關(guān)的元素附近圖名功能備注類圖描述類、類的特性以及類之間的關(guān)系UML1原有對象圖描述一個時間點上系統(tǒng)中各個對象的一個快照UML1非正式圖復合結(jié)構(gòu)圖描述類的運行時刻的分解UML2.0新增構(gòu)件圖描述構(gòu)件的結(jié)構(gòu)與連接UML1原有部署圖描述在各個節(jié)點上的部署UML1原有包圖描述編譯時的層次結(jié)構(gòu)UML中非正式圖用例圖描述用戶與系統(tǒng)如何交互UML1原有活動圖描述過程行為與并行行為UML1原有狀態(tài)機圖描述事件如何改變對象生命周期UML1原有順序圖描述對象之間的交互，重點在強調(diào)順序UML1原有通信圖描述對象之間的交互，重點在于連接UML1中的協(xié)作圖定時圖描述對象之間的交互，重點在于定時UML2.0新增交互概觀圖是一種順序圖與活動圖的混合UML2.0新增UML定義的圖主要領(lǐng)域視圖圖結(jié)構(gòu)靜態(tài)視圖類圖設(shè)計視圖復合結(jié)構(gòu)圖、協(xié)作圖、構(gòu)件圖用例視圖用例圖動態(tài)狀態(tài)視圖狀態(tài)機圖活動視圖活動圖交互視圖順序圖、通信圖物理部署視圖部署圖模型管理模型管理視圖包圖特性描述包圖UML視圖和圖UML圖形分類4+1視圖4+1視圖用例視圖：它是最基本的需求分析模型，是可被最終用戶看到的系統(tǒng)行為的用例組成。常用的模型包括用例圖、交互圖、狀態(tài)圖、活動圖等。設(shè)計視圖：又稱為邏輯視圖，以問題域的語匯組成的類和對象集合，用來描述類、接口、協(xié)作。常用的模型包括類圖、交互圖、狀態(tài)圖、活動圖等。進程視圖：形成系統(tǒng)并發(fā)與同步機制的線程和進程，也就是將可執(zhí)行線程和進程作為活動類的建模，可理解為設(shè)計視圖的一次執(zhí)行實例。它使用的模型與設(shè)計視圖類似，區(qū)別在于更側(cè)重于主動類。4+1視圖實現(xiàn)視圖：對組成基于系統(tǒng)的物理代碼的文件和組件進行建模，即裝配與發(fā)布物理系統(tǒng)的構(gòu)件和文件。常用的模型包括構(gòu)件圖、交互圖、狀態(tài)圖、活動圖。部署視圖：包含了形成系統(tǒng)硬件拓撲結(jié)構(gòu)的節(jié)點，也就是描述組件是如何物理地部署到一組物理的、可計算節(jié)點上的。常用的模型包括部署圖、交互圖、狀態(tài)圖、活動圖。開發(fā)過程類圖基礎(chǔ)理解面向?qū)ο笏枷肜斫饷嫦驅(qū)ο笏枷朊總€對象都扮演了一個角色，并為其它成員提供特定的服務或執(zhí)行特定的行為。在面向?qū)ο笫澜缰?，行為的啟動是通過將“消息”傳遞給對此行為負責的對象來完成的；同時還將伴隨著執(zhí)行要求附上相關(guān)的信息（參數(shù)）；而收到該消息的對象則會執(zhí)行相應的“方法”來實現(xiàn)需求用類和對象表示現(xiàn)實世界，用消息和方法來模擬現(xiàn)實世界的核心思想如何用UML表示一個類名稱：每個類都有一個惟一的名稱，通常采用CamelCase格式表示屬性：是已被命名的類的

特性，它描述該類實例中

包含的信息操作：是類所提供的服務，

它可以由類的任何對象請求以影響其行為屬性名和操作名也通常采用CamelCase格式表示，只不過首字母通常為小寫。

如何閱讀類圖先看清有哪些類，然后看

看類之間存在的關(guān)系，并

結(jié)合多重性來理解類圖的

結(jié)構(gòu)特點以及

各個屬性和方

法的含義讀圖過程讀出類：圖中共有7個類，Order、OrderItem、Customer、Consignee、DeliverOrder、Peddlery、Prodcut讀出關(guān)系：從圖中關(guān)系最復雜（也就是線最密集）的類開始閱讀，本圖中最復雜的就是Order類。

1）OrderItem和Order之間是組合關(guān)系，根據(jù)箭頭的方向可知Order包含了OrderItem。

2）Order類和Customer、Consignee、DeliverOrder是關(guān)聯(lián)關(guān)系。也就是說，一個訂單和客戶、收貨人、送貨單是相關(guān)的。讀圖過程多重性：用來說明關(guān)聯(lián)的兩個類之間的數(shù)量關(guān)系源類及多重性目標類及多重性分析Customer(1)Order(0…n)訂單是屬于某個客戶的，網(wǎng)站的客戶可以有0個或多個訂單Order(1)Consignee(1)每個訂單只能夠有一個收貨人Order(1)OrderItem(1…n)訂單是由訂單項組成的，至少要有一個訂單項，最多可有n個Order(1)DeliverOrder(1…n)一個訂單有一個或多個送貨單說明：系統(tǒng)根據(jù)訂單項的產(chǎn)品所屬的商戶，將其分發(fā)給商戶，拆成了多個送貨單！DeliverOrder(1)OrderItem(1…n)一張送貨單對應訂單中的一到多個訂單項DeliverOrder(1)Consignee(1)每張送貨單都對應著一個收貨人Peddlery(1)DeliverOrder(0…n)每個商戶可以有相關(guān)的0個或多個送貨單OrderItem(1)Product(1)每個訂單項中都包含著唯一的一個產(chǎn)品Peddlery(1)Prodcut(0…n)產(chǎn)品是屬于某個商戶的，可注冊0到多個產(chǎn)品讀圖過程—理解方法和圖Order類，有兩個方法：dispatch()和close()，從名字中可以猜出它們分別實現(xiàn)“分拆訂單生成送貨單”和“完成訂單”。而在DeliveOrder()類中則有一個Close()方法，同理它應該表示“完成送貨”。而在OrderItem中有一個stateChange()方法和deliverState，不難猜出它就是用來改變其“是否交給收貨人”標志位的讀圖過程—理解方法和圖先調(diào)用Order的dispatch()方法，它將根據(jù)其包含的OrderItem中產(chǎn)品信息，來按供應商戶分拆成若干個DeliverOrder。商戶登錄系統(tǒng)后就可以獲取其DeliverOrder，并在執(zhí)行完后調(diào)用close()方法。這時，就將調(diào)用OrderItem的stateChange()方法來改為其狀態(tài)。同時再調(diào)用Order的close()方法，判斷該Order的所有的OrderItem是否都已經(jīng)送到了，如果是就將其真正close()掉

使用了更多建模元素的類圖輔助建模符號導航箭號：類的實例之間只能沿著導航箭頭的方向傳遞，在Order中可以獲取其相應的Consignee，而從Consignee中是無法了解與其相關(guān)的Order的角色名稱：Customer端有一個“+Owner”字符串，這表示Customer扮演的角色是Owner，也能對關(guān)聯(lián)進行命名輔助建模符號導出屬性：是指可以根據(jù)其他值計算出來的特性，這種屬性應在其名稱前加上一個“/”符號。限定符：在Order和OrderItem之間的組合關(guān)系中，OrderItem這端多了個方框，寫著“ProductId”。在UML中稱為限定符，存在限定符的關(guān)聯(lián)稱為受限關(guān)聯(lián)。它用來表示某種限定關(guān)系。在本例中說明：對于一張訂單，每一種產(chǎn)品只能用一個訂單項約束：用來說明規(guī)則，{xor}…職責：在類的屬性欄中添加注釋行表示，或增加了一個新的分欄對象約束語言環(huán)境與約束：每個OCL表達式都必須是針對某個元素的，因此在OCL表達式前必須說明它針對元素（這就稱為環(huán)境）

1）“contextObjectinv：”，其中Object是OCL表達式針對的建模元素名稱；

2）“Object”，其中Object是OCL表達式針對的建模元素名稱。

當聲明了環(huán)境之后，就可以用self來引用它的變量

對象約束語言子集約束：一致性：一個客戶擁有零個或多個合同，發(fā)票是基于某個合同的，而一個客戶將收到零張或多張發(fā)票

Invoice：self.contract.customer=self.customer對象約束語言異或關(guān)系：規(guī)定的取值范圍：

Rectangle：length>0andwidth>0用類圖表示軟件系統(tǒng)模型領(lǐng)域模型是從面向?qū)ο笠暯强创F(xiàn)實世界的結(jié)果，也就是通過類圖描述現(xiàn)實世界中各種事物的關(guān)系。分析模型和領(lǐng)域模型很相近，分析模型主要是針對軟件系統(tǒng)，領(lǐng)域模型則更多偏重對業(yè)務領(lǐng)域的分析設(shè)計模型則是在分析模型的基礎(chǔ)上添加設(shè)計元素的結(jié)果。設(shè)計模型中的類的屬性集更趨完善。用類圖表示數(shù)據(jù)庫邏輯模型從某種意義上說UML中的類圖是E-R圖的超集，E-R圖只針對存儲的數(shù)據(jù)，而類圖則在些基礎(chǔ)上，增加了行為建模的能力。在使用類圖來表示E-R模型時，要注意遵循以下策略將表示E-R模型的類，用UML的標準構(gòu)造型“{persistent}”來表示；展開類的結(jié)構(gòu)性細節(jié)，并加強關(guān)聯(lián)和多重性分析；盡量消除循環(huán)關(guān)聯(lián)、n-元關(guān)聯(lián)交互圖基礎(chǔ)交互的概念一次交互就是指在特定語境中，為了實現(xiàn)某一個目標，而在一組對象之間進行交換的一組消息所表示的行為在大多數(shù)的情況下，消息通常是指啟動一個操作，或發(fā)送一個信號，以及創(chuàng)建或銷毀一個對象由一條有方向的直線，加上名稱、參數(shù)（可選）和順序組成四種交互圖順序圖：強調(diào)消息時間順序。首先把參與交互的對象放在圖的上方，沿X軸方向排列。通常把發(fā)起交互的對象放在左邊，較下級對象依次放在右邊。然后，把這些對象發(fā)送和接收的消息沿Y軸方向按時間順序從上到下放置。讀者提供了控制流隨著時間推移的清晰的可視化軌跡。協(xié)作圖：在UML2.0中稱為通信圖，強調(diào)的是參加交互的對象的組織。首先將參加交互的對象作為圖的頂點，然后用這些對象之間的邊線表示為圖的邊，再使用對象發(fā)送和接收的消息來修飾這些邊。為讀者提供了在協(xié)作對象結(jié)構(gòu)組織的語境中觀察控制流的一個清晰的可視化軌跡四種交互圖定時圖：采用了一種帶數(shù)字刻度的時間軸來精確地描述消息的順序，而不是像順序圖那樣只是指定消息的相對順序。而且它還允許可視化地表示每條生命線的狀態(tài)變化，當需要對實時事件進行定義時，定時圖就可以很好地滿足交互概述圖：是交互圖和活動圖的混合物。你可以把交互概述圖想像為活動圖，只不過其中的活動被換成了一些小型順序圖；也可以把其想像為利用標明控制流的活動圖分解過的順序圖閱讀順序圖順序圖的主要元素對象與角色：最頂上一排矩形框。在交互圖中，參與交互的對象既可以是具體的事物，又可以是原型化的事物。作為具體的事物，一個對象代

表現(xiàn)實世界中的某個東西。例如，aOrder

作為類Order的一個實例，可以代表一個

特定的訂單；而如果作為一個原型化的事

件，則aOrder可以代表類Order的任何一

個實例。生命線與控制焦點：每個對象都有自己的

生命線，對象生命線是一條垂直的虛線，

用來表示一個對象在一段時間內(nèi)存在。順序圖的主要元素消息：用來描述對象之間所進行的通信的，該信息帶有對將要發(fā)生的活動的期望。當傳送一個消息時，它所引起的動用是一個通過對計算過程的抽象而得到的可執(zhí)行語句。消息分為五種：調(diào)用、返回、發(fā)送、創(chuàng)建和銷毀調(diào)用：表示調(diào)用某個對象一個操作

順序圖的主要元素返回：表示被調(diào)用的對象，向調(diào)用者返回一個值發(fā)送：發(fā)送是指向?qū)ο蟀l(fā)送一個信號，和調(diào)用不同，它是一種事件，用來表示個實例間進行通信的異步激發(fā)機制

創(chuàng)建和銷毀：就是創(chuàng)建和銷毀一個對象。順序圖的主要元素順序編號：整個消息的傳遞過程就形成了一個完整的序列，因此通過在每個消息的前面加上一個用冒號隔開的順序號來表示其順序。除了順序編號之外，還可以采用嵌套方案：順序圖的主要元素循環(huán)與分支讀圖小結(jié)在dispatchForm（分發(fā)窗體）中，對于某個已支付的Order進行分發(fā)時，就會調(diào)用該訂單（一個Order類的實例對象aOrder）的dispatch()方法。dispatch()方法將逐個調(diào)用該Order對應的所有OrderItem對象的getPeddleryId()方法還獲取供應商ID（PeddleryId），而OrderItem對象則是通過其所對應的Product對象來的getPeddleryId()方法來獲取供應商ID。讀圖小結(jié)當Order的實例對象aOrder得到返回的PeddleryId后，根據(jù)該值判斷是否已經(jīng)有相對應的DeliverOrder對象，如果沒有就創(chuàng)建它（調(diào)用create(PeddleryId)），然后再將對應的Product添加到這個DeliverOrder對象中。否則就直接添加到相應的DeliverOrder對象中。閱讀協(xié)作(通信)圖協(xié)作圖的主要元素鏈：連接器，是用來表示對象之間的語義連接，一般而言，鏈是關(guān)聯(lián)的一個實例（包括《association》、《self》、《global》、《local》等）。不過在UML2中已經(jīng)開始弱化它們的使用，因此除非必要，無需過多地考慮它們消息編號：消息的編號有兩種，一種是無層次編號，它簡單直觀；另一種是嵌套的編號，它更易于表示消息的包含關(guān)系迭代標記：用*號表示，表示循環(huán)，通常還有迭代表達式，用來說明循環(huán)規(guī)則協(xié)作圖的主要元素監(jiān)護條件：通常是用來表示分支的，也就是表示“如果條件為true，才發(fā)送消息”在通信圖中使用監(jiān)護條件一定要有所限制，通常應只列出主要的監(jiān)護條件，否則會影響其閱讀。如果需要，盡可能還是通過順序圖來表示交互建模的準備工作首先根據(jù)自己的喜好和實際的表現(xiàn)需要來選擇順序圖或通信圖。不過由于它們在語義上是等價的，因此可以繪制出一種，再通過建模工具來自動轉(zhuǎn)換成另一種圖分析模型中的交互圖徹重于分析類的職責分配和交互流程，而設(shè)計模型中的交互圖則徹重于設(shè)計類的引入和實際方法的調(diào)用與流程控制先確定參與交互的對象、對象之間的關(guān)系(通信圖)，然后確定對象間的消息交互流程(用同步調(diào)用、異步消息、返回消息表示)，并利用交互片斷(順序圖)或迭代標記及監(jiān)護條件來表示循環(huán)和分支結(jié)構(gòu)交互建?！猂obustness分析Robustness分析不是UML模型的一部分，它是一個強大的草圖工具，是介于分析和設(shè)計之間的一種有效工具在Robustness分析中，將應用邊界類、控制類和實體類從一個用例中抽取三類對象的方法：Robustness分析—從事件流開始Robustness分析：尋找邊界對象圖書管理員向系統(tǒng)發(fā)出“新增書籍信息”請求——主窗口、“新增書籍信息”按鈕系統(tǒng)要求圖書管理員選擇要新增的書籍是計算機類還是非計算機類——書籍類別列表框。圖書管理員做出選擇后，顯示相應界面，

讓圖書管理員輸入信

息，并自動根據(jù)書號

規(guī)則生成書號——

“新書信息錄入”窗口

及輔助的“提交”按鈕尋找控制對象與實體對象根據(jù)事件流中的步驟5，以及擴展路徑的描述，就可以在原圖上增加相應的控制對象，得到更進一步的Robustness分析圖尋找控制對象與實體對象新添兩個邏輯：一是基本事件流中的步驟2、3要求根據(jù)用戶選擇的類別，自動獲得書號；二是當書名重復性檢查沒有通過（有重名），則應返回要求其重輸

構(gòu)建交互模型轉(zhuǎn)成通信圖交互模型的應用用例建模的目標是從使用者的角度來對系統(tǒng)進行梳理，Robustness分析則是對使用者的使用場景（一個用例的實例）進行的具體的分析，從而理解了系統(tǒng)需要做什么，并找出更多與解決方案相關(guān)的設(shè)計類。但更重要的是完整地捕獲出這些類的行為、責任以及它們之間的交互，而這些正是系統(tǒng)運行的機制。而交互建模，正是要通過尋找對象之間的交互關(guān)系，從而進行“行為分配”。交互模型的類型與演變分析階段的交互模型針對用例圖中的每個用例，并結(jié)合領(lǐng)域模型中的類，尋找分析類，并通過Robustness分析來理清業(yè)務邏輯流程，再用交互模型將其確定下來。同時這個階段，不斷地豐富分析模型，將新找到的類添加到類圖中去在分析階段我們主要關(guān)注于區(qū)分出邊界對象、實體對象和控制對象，暫時不要考慮其具體的實現(xiàn)類對于較復雜的用例而言，我們可以按上述的流程逐漸地進行分析、設(shè)計、實施；但對于比較簡單的用例而言，也是可以直接從用例描述中導出設(shè)計階段交互模型分析階段的交互模型之后引入基礎(chǔ)類：各種庫函數(shù)、框架進行質(zhì)量評審：

1）低耦合

2）高內(nèi)聚

3）效率

4）完整性

5）簡單性優(yōu)化類設(shè)計：設(shè)計模式與重構(gòu)設(shè)計階段的交互模型當在分析模型的基礎(chǔ)上，通過引入基礎(chǔ)類、優(yōu)化類設(shè)計之后，必然會獲得新的類模型（設(shè)計模型），因此就可能需要基于新引入的“設(shè)計類”來更新交互模型，以獲得與實際代碼相吻合的模型是否建立設(shè)計階段的交互模型，也是取決于需要的。通常只有約一半的用例可能需要精化交互模型；如果在一般的MIS應用系統(tǒng)中，這個比例可能會更低交互模型的建模要點創(chuàng)建交互圖時，應該遵循以下策略：給出一個能表達其目的的名稱；通過修改元素的布局，盡量避免交叉線的存在；可以通過注解和顏色作為可視化提示，以突出圖形中的重要特性；盡量少用分支，對于分支很多的場景，可以考慮用活動圖來補充切記“盡可能保持簡單”狀態(tài)圖基礎(chǔ)狀態(tài)及狀態(tài)表示法狀態(tài)是指在對象生命周期中滿足某些條件、執(zhí)行某些活動或等待某些事件的一個條件和狀況一個狀態(tài)通常包括名稱、進入/退出活動、內(nèi)部轉(zhuǎn)換、子狀態(tài)和延遲事件等五個部分組成閱讀簡單狀態(tài)圖最為核心的元素無外乎是兩個：一個是用圓角矩形表示的狀態(tài)（初態(tài)和終態(tài)例外）；另一個則是在狀態(tài)之間的、包含一些文字描述的有向箭頭線，這些箭頭線稱為轉(zhuǎn)換轉(zhuǎn)換的五要素源狀態(tài)：即受轉(zhuǎn)換影響的狀態(tài)目標狀態(tài)：當轉(zhuǎn)換完成后對象的狀態(tài)觸發(fā)事件：用來為轉(zhuǎn)換定義一個事件，包括調(diào)用、改變、信號、時間四類事件監(jiān)護條件：布爾表達式，決定是否激活轉(zhuǎn)換動作：轉(zhuǎn)換激活時的操作讀圖小結(jié)與狀態(tài)off相關(guān)的轉(zhuǎn)換有兩個，其觸發(fā)事件都是turnOn，只不過其監(jiān)護條件不同。如果對象收到事件turnOn，那么將判斷壺中是否有水；如果[沒水]，則仍然處于off狀態(tài)；如果[有水]則轉(zhuǎn)為on狀態(tài)，并執(zhí)行“燒水”動作而與狀態(tài)on相關(guān)的轉(zhuǎn)換也有兩個，如果“水開了”就執(zhí)行turnOff，關(guān)掉開關(guān)；如果燒壞了，就進入了終態(tài)了復雜轉(zhuǎn)換轉(zhuǎn)換類型描述語法外部轉(zhuǎn)換對事件做出響應，引起狀態(tài)變化或自身轉(zhuǎn)換，同時引發(fā)一個特定動作，如果離開或進入狀態(tài)將引發(fā)進入轉(zhuǎn)換、離開轉(zhuǎn)換事件(參數(shù))[監(jiān)護條件]/動作內(nèi)部轉(zhuǎn)換對事件做出響應，并執(zhí)行一個特定的活動，但并不引起狀態(tài)變化或進入轉(zhuǎn)換、離開轉(zhuǎn)換事件(參數(shù))[監(jiān)護條件]/動作進入轉(zhuǎn)換當進入某一狀態(tài)時，執(zhí)行相應活動entry/活動退出轉(zhuǎn)換當離開某一狀態(tài)時，執(zhí)行相應活動exit/活動閱讀帶復雜轉(zhuǎn)換的狀態(tài)圖各種轉(zhuǎn)換的區(qū)別進入和退出轉(zhuǎn)換：當進入一個狀態(tài)時，執(zhí)行某個動作；或當退出某個狀態(tài)時，執(zhí)行什么動作。這時就可以使用進入和退出轉(zhuǎn)換來表示內(nèi)部轉(zhuǎn)換：用來處理一些不離開該狀態(tài)的事件

活動與延遲事件活動：當對象處于一個狀態(tài)時，它一般是空閑的，在等待一個事件的發(fā)生。但是某些時間，你可能希望描述個正在進行的活動。在處于一個狀態(tài)的同時，對象做著某些工作，并一直繼續(xù)到被某個事件中斷。延遲事件：延遲事件是一種特殊的事件，它是指該事件不會觸發(fā)狀態(tài)的轉(zhuǎn)換，當對象處于該狀態(tài)時事件不會丟失，但會被延遲執(zhí)行。例如，當E-mail程序中正在發(fā)送第一封郵件時，用戶下達發(fā)送第二封郵件執(zhí)令就會被延遲，但第一封郵件發(fā)送完成后，這封郵件就會被發(fā)送。這種事件就屬于延遲事件。順序復合狀態(tài)圖并發(fā)復合狀態(tài)圖歷史“一個圓圈中加上字母H”，用來表示歷史狀態(tài)的。它的含義是：當從狀態(tài)“結(jié)賬”和“顯示購物車”返回子狀態(tài)“顯示索引信息”時，將進入的是離開時的歷史狀態(tài)。也就是說，轉(zhuǎn)到購

物車或結(jié)賬區(qū)之后，

再回到“瀏覽目錄”的

頁面時，其中的內(nèi)容

是不變的，仍然保留

原來的信息。狀態(tài)圖應用說明對對象生命周期建模：主要描述對象能夠響應的事件、對這些事件的響以及過去對當前行為的影響對反應型對象建模：這個對象可能處于的穩(wěn)定狀態(tài)、從一個狀態(tài)到另一個狀態(tài)之間的轉(zhuǎn)換所需的觸發(fā)事件，以及每個狀態(tài)改變時發(fā)生的動作狀態(tài)機圖既可以用來表示一個業(yè)務領(lǐng)域的知識，也可以用來描述設(shè)計階段對象的狀態(tài)變遷。

活動圖基礎(chǔ)活動圖概述活動圖是一種表述過程機理、業(yè)務過程以及工作流的技術(shù)。它可以用來對業(yè)務過程、工作流建模，也可以對用例實現(xiàn)甚至是程序?qū)崿F(xiàn)來建模。因此，它的作用和傳統(tǒng)的“流程圖”是有著很深的淵源，也十分的相似。不過它與流程圖的最主要區(qū)別在于，活動圖能夠支持并行的行為在UML的各個版本中，活動圖的改變可謂最大，每次UML標準更新時，都對活動圖進行了修訂。對于UML2.0而言，最大的改變莫過于去除了“活動圖是狀態(tài)圖的一種特例”這一規(guī)定閱讀簡單活動圖活動圖主要元素初始節(jié)點和活動終點：用一個實心圓表示初始節(jié)點，用一個圓圈內(nèi)加一個實心圓來表示活動終點活動節(jié)點：是活動圖中最主要的元素之一，它用來表示一個活動轉(zhuǎn)換：當一個活動結(jié)束時，控制流就會馬上傳遞給下一個活動節(jié)點，在活動圖中稱之為“轉(zhuǎn)換”，用一條帶箭頭的直線來表示活動圖主要元素分支與監(jiān)護條件：分支是用菱形表示的，它有一個進入轉(zhuǎn)換（箭頭從外指向分支符號），

一個或多個離開轉(zhuǎn)換（箭頭從分支符

號指向外）。而每個離開轉(zhuǎn)換上都會

有一個監(jiān)護條件，用來表示滿足什么

條件的時候執(zhí)行該轉(zhuǎn)換。分岔與匯合：帶泳道的活動圖帶對象流的活動圖復雜活動圖輔助活動圖匯合描述：當匯合的所有入流均到點匯合點時，就將執(zhí)行匯合點指向的活動節(jié)點。但是有些時候，你希望對其做一些約束，這時就可以借助匯合描述來完成。匯合描述實際上是一個約束，其格式就是“{約束條件}”。復雜活動圖發(fā)送信號與接收信號復雜活動圖引腳：表示活動節(jié)點的相應參數(shù)擴展區(qū)：活動圖應用說明對工作流建模：用于業(yè)務建模的時候，每一條泳道表示一個職責單位，該圖能夠有效地體現(xiàn)出所有職責單位之間的工作職責，業(yè)務范圍以及之間的交互關(guān)系、信息流程建模時應遵循以下策略：為工作流建立一個焦點，除非你所涉及的系統(tǒng)很小，否則不可能在一張圖中顯示出系統(tǒng)中所有的控制流。選擇對全部工作流中的一部分有高層職責的業(yè)務對象，并為每個重要的業(yè)務對象創(chuàng)建一條泳道。活動圖應用說明識別工作流初始節(jié)點的前置條件和活動終點的后置條件，這可有效地實現(xiàn)對工作流的邊界進行建模。從該工作流的初始節(jié)點開始，說明隨時間發(fā)生的動作和活動，并在活動圖中把它們表示成活動節(jié)點。將復雜的活動或多次出現(xiàn)的活動集合歸到一個活動節(jié)點，并通過輔助活動圖或子活動圖來表示它們。找出連接這些活動節(jié)點的轉(zhuǎn)換，首先從工作流的順序開始，然后考慮分支，接著再考慮分岔和匯合。如果工作流中涉及重要的對象，則也可以將它們加入到活動圖中。若工作流中有多次啟用的，則可采用展開區(qū)表示。活動圖應用說明對操作建模：每一個對象占據(jù)一個泳道，而活動則是該對象的成員方法建模時應遵循以下策略：收集操作所涉及的抽象概念，包括操作的參數(shù)、返回類型、所屬類的屬性以及某些鄰近的類。識別該操作的初始節(jié)點的前置條件和活動終點的后置條件。也要識別在操作執(zhí)行過程中必須保持的信息。從該操作的初始節(jié)點開始，說明隨著時間發(fā)生的活動，并在活動圖中將它們表示為活動節(jié)點。如果需要，使用分支來說明條件語句及循環(huán)語句。僅當這個操作屬于一個主動類時，才在必要時用分岔和匯合來說明并行的控制流程。構(gòu)件圖基礎(chǔ)構(gòu)件的類型實施構(gòu)件：這類構(gòu)件是構(gòu)成一個可執(zhí)行系統(tǒng)必要和充分的構(gòu)件，例如動態(tài)鏈接庫、可執(zhí)行文件，另外還包括如COM+、CORBA及企業(yè)級JavaBeans、動態(tài)Web頁面也屬于實施構(gòu)件的一部分。工作產(chǎn)品構(gòu)件：這類構(gòu)件主要是開發(fā)過程的產(chǎn)物，包括創(chuàng)建實施構(gòu)件的源代碼文件及數(shù)據(jù)文件。這些構(gòu)件并不是直接地參與可執(zhí)行系統(tǒng)，而且用來產(chǎn)生可執(zhí)行系統(tǒng)的中間工作產(chǎn)品。執(zhí)行構(gòu)件：作為一個正在執(zhí)行的系統(tǒng)的結(jié)果而被創(chuàng)建的，例如由DLL實例化形成的COM+對象。構(gòu)件及構(gòu)件接口表示法閱讀基本構(gòu)件圖閱讀嵌套構(gòu)件圖構(gòu)件圖應用說明對可執(zhí)行程序的結(jié)構(gòu)建模

1）首先識別你想建模的構(gòu)件集合

2）考慮集合中各構(gòu)件的不同類型

3）對這個集合中的每個構(gòu)件，分析它們之的關(guān)系構(gòu)件圖應用說明對源代碼建模

1）識別出感興趣的相關(guān)源代碼文件的集合，并把它們建模為構(gòu)件；

2）對于較大的系統(tǒng)，利用包來進行分組；

3）通過約束來表示源代碼的版本

號、作者和最后修改日期等信息；

4）用依賴關(guān)系來表示

這些文件間編譯的依

賴關(guān)系。部署圖基礎(chǔ)閱讀基本部署圖部署圖主要元素節(jié)點：它代表一個運行時的計算資源，例如一臺計算機、一個工作站等其它設(shè)備節(jié)點的概念和構(gòu)件有許多相同之處，例如二者有多名稱，都可以參與依賴、泛化和關(guān)聯(lián)關(guān)系，都可以被嵌套，都可以有實例，都可以參與交互。但它們之間也存在明顯的區(qū)別：構(gòu)件是參與系統(tǒng)執(zhí)行的事物，而節(jié)點是執(zhí)行構(gòu)件的事物；構(gòu)件表示邏輯元素的物理打包，而節(jié)點表示構(gòu)件的物理部署。本圖中建模了四個節(jié)點：B/S客戶端、C/S客戶端、IIS服務器和數(shù)據(jù)庫服務器部署圖主要元素連接：節(jié)點之間最常見的關(guān)系就是關(guān)聯(lián)關(guān)系（用一根實線表示）。為了更好地表示兩個節(jié)點之間的關(guān)系，我們可以通過“約束”來對連接進行描述。

源節(jié)點目標節(jié)點約束含義B/S客戶端IIS服務器{HTTP+Network}網(wǎng)絡(luò)連接，使用HTTP協(xié)議C/S客戶端IIS服務器{HTTP+SOAP+Network}網(wǎng)連接，通過WebService訪問服務IIS服務器數(shù)據(jù)庫服務器{ADO.NET}.NET提供的數(shù)據(jù)庫訪問解決方案部署圖補充元素處理器（《process》）：具有處理能力的節(jié)點，即可以執(zhí)行構(gòu)件。設(shè)備（《device》）：沒有處理能力的節(jié)點，至少是不關(guān)心其處理能力的節(jié)點。例如打印機、IC卡讀寫器，如果我們的系統(tǒng)不考慮它們內(nèi)部的芯片，就可以建模為設(shè)備。節(jié)點屬性和操作：可以為一個節(jié)點提供處理器速度、內(nèi)存容量、網(wǎng)卡數(shù)量等屬性，可以為其提供啟動、關(guān)機等操作

部署圖補充元素自定義構(gòu)造型圖標部署圖應用說明部署圖是一種分兩階段演化的，最初的部署圖是在設(shè)計時，作為確定最終硬件構(gòu)架過程的一部分而創(chuàng)建的，然后逐步地對它進行精化，從而得到一個或多個實例形式的部署圖。設(shè)計階段：焦點聚焦于節(jié)點或節(jié)點實例，以及它們之間的連接實現(xiàn)階段：焦點聚集于將物理構(gòu)件分配給節(jié)點部署圖適用領(lǐng)域如果你開發(fā)的應用系統(tǒng)是一個單機程序，那么部署圖并不能夠給你帶來什么好處嵌入式系統(tǒng)建模：對于嵌入式系統(tǒng)，部署圖可以使硬件工程師和軟件開發(fā)者之間實現(xiàn)更好的交流

客戶機/服務器和分布式系統(tǒng)建模Agenda需求分析最佳實踐需求建模最佳實踐用例驅(qū)動的需求過程實踐現(xiàn)代需求工程最佳實踐用例驅(qū)動的需求實踐：概述需要特性軟件需求問題域解決方案域用例補充規(guī)約關(guān)于用例分析技術(shù)用例分析的創(chuàng)建源于實踐，在IvarJacobson在愛立信公司研發(fā)AXE（電話交換機）時總結(jié)而成的用例的概念確定于1986年，所以它不應該當作一種新技術(shù)（有人認為其是一個正處于臨床實驗階段的新藥）許多人是在學習UML時，接觸到用例，并且產(chǎn)生了一些誤解，誤把用例圖當作了用例分析的全部內(nèi)容用例分析技術(shù)已經(jīng)廣泛地應用于許多軟件開發(fā)組織的實踐，收效甚佳，成為了軟件需求最佳實踐之一用例模型的運用方法增量開發(fā)的用例模型模型的無縫轉(zhuǎn)換用例模型建模要點構(gòu)建結(jié)構(gòu)良好的用例：

1）為系統(tǒng)和部分系統(tǒng)中單個的、可標識和合理的原子行為命名；

2）將公共的行為抽取出來，放到一個被包含用例中，再將它《include》進來；

3）對于變化部分，將其抽取出來，放到一個擴展用例（用《extent》連接）中；

4）清晰地描述事件流，使得讀者能夠輕而易舉地理解構(gòu)建結(jié)構(gòu)良好的用例圖：擺放元素時，應該避免交叉線的出現(xiàn)；對于語義上接近的行為和角色，最好使它們在物理上也更加接近；根據(jù)系統(tǒng)實際情況控制粒度核心元素：參與者定義：在系統(tǒng)之外，透過系統(tǒng)邊界與系統(tǒng)進行有意義交互的任何事物邊界類：顧客邊界是職責邊界，而非物理邊界誰是機票預訂系統(tǒng)的執(zhí)行者它們都可以是執(zhí)行者用戶維護人員時間系統(tǒng)其他系統(tǒng)參與者：總結(jié)參與者是為了完成一個事件而與系統(tǒng)交互的實體參與者不僅可以由人承擔，還可以是其它系統(tǒng)、硬件設(shè)備、甚至是時鐘其它系統(tǒng)：當你的系統(tǒng)需要與其它系統(tǒng)交互時，如在開發(fā)ATM柜員機系統(tǒng)時，銀行后臺系統(tǒng)就是一個參與者硬件設(shè)備：如果你的系統(tǒng)需要與硬件設(shè)備交互時，如在開發(fā)IC卡門禁系統(tǒng)時，IC卡讀寫器就是一個參與者時鐘：當你的系統(tǒng)需要定時觸發(fā)時，時鐘就是一個參與者，如在開發(fā)Foxmail中的“定時自動接

收”功能時，就需要引入時鐘作為參與者核心元素：用例IvarJacobson在RUP中為用例做出了以下定義

用例實例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作將生成特定執(zhí)行者可見的價值結(jié)果。一個用例定義一組用例實例。步驟目標路徑用例：使用場景的抽象場景1：原有客戶育才學校呼入，選擇電話號碼組“全體家長”和“放假通知”音頻文件，設(shè)置日期、時間和其它呼叫標準，然后啟動一個語音外呼任務。場景2：原有客戶精英軟件公司呼入，選擇電話號碼組“全體客戶”和“產(chǎn)品升級通知”音頻文件，設(shè)置日期、時間和其它呼叫標準，然后啟動一個語音外呼任務。場景3：客戶通達核電計劃在核電力設(shè)施發(fā)生緊急情況時，向其經(jīng)理和支持人員打電話。此時，不僅要能夠正確地打到家里，還要正確地判斷出誰能夠接收到這個消息，誰不能夠接收。需求提出后，必須馬上執(zhí)行。啟動外呼任務用例定義：用例描述了執(zhí)行者（參與者）使用系統(tǒng)實現(xiàn)目標的方式，以及系統(tǒng)為其能夠?qū)崿F(xiàn)該目標而提供的幫助。用例描述了系統(tǒng)及其執(zhí)行者結(jié)合起來向至少一個參與者傳遞有價值的東西的方式常見錯誤用例太細（用例應包括事件流，事件流中應有步驟）把步驟當做用例（如登錄輸入用戶名、驗證密碼…）

把系統(tǒng)活動當用例！

特例：新增、刪除、查詢、修改管理

也被戲稱為：CRUD（四輪馬車）誤認為用例的粒度與系統(tǒng)實現(xiàn)的復雜度相關(guān)其實很簡單，一個用例為執(zhí)行者提供一個價值用例要突出涉眾的利益找出用例相關(guān)的涉眾；分析涉眾的利益所在；在用例中充分考慮涉眾的利益。用例分析技術(shù)的組成用例圖：用例描述：前置條件：用戶啟動該應用系統(tǒng)基本路徑：

1）系統(tǒng)顯示登錄界面；

2）用戶輸入用戶名和密碼；

3）系統(tǒng)驗證信息；

…………可選路徑：后置條件：執(zhí)行者，Actor

參與者用例，UseCase參與者：定義了用戶在系統(tǒng)交互過程中所扮演的角色，其可以是一個人，也可以是另一個系統(tǒng)。用例圖實例用例之間的關(guān)系：包含關(guān)系包含關(guān)系用構(gòu)造型《include》表示是指基用例（baseusecase）在它內(nèi)部說明的某一個位置上顯式地合并了另一個用例的行為用例之間的關(guān)系：擴展關(guān)系包含關(guān)系用構(gòu)造型《extend》表示表示基用例在由擴展用例間接說明的一個位置上，隱式地合并了另一個用例的行為用例之間的關(guān)系：泛化關(guān)系用例間的泛化表示子用例繼承了父用例的行為和含義子用例還可以增加或覆蓋父用例的行為；子用例可以出現(xiàn)在父用例出現(xiàn)的任何位置讀圖小結(jié)這張用例圖首先定義了三個基用例：預訂座位、安排座位和處理結(jié)賬客戶通過Internet啟動“預訂座位”用例，在“預訂座位”用例的執(zhí)行過程中，將“檢查座位信息”（被包含用例），如果沒有空閑的座位或滿意的座位，可以選擇進入等候隊列，這樣就將啟動擴展用例“處理等候隊列”?？偱_服務員在客戶到棋牌館時，啟動“安排座位”用例，在執(zhí)行過程中，將啟動被包含用例“檢查座位信息”。當客戶要離開棋牌館時，總臺服務員將啟動“處理結(jié)賬”用例，并且定義了兩種“收款”用例，一個是“處理現(xiàn)金結(jié)賬”，另一個是“處理銀行卡結(jié)賬”，而后一個用例將通過與外部系統(tǒng)“銀聯(lián)POS系統(tǒng)”交互來完成。用例描述：事件流用例描述的是一個系統(tǒng)做什么（what）的信息，并不說明怎么做（how），怎么做是設(shè)計模型的事用例描述：前置條件指在用例啟動時，參與者與系統(tǒng)應置為何狀態(tài)；

1）系統(tǒng)能檢測到；

2）系統(tǒng)在用例開始前能檢測到；

3）應為“可觀測”的前置條件用例描述：前置條件客戶已發(fā)出訂單----錯誤工作人員已登錄系統(tǒng)----正確庫存大于下單數(shù)----錯誤用例描述：后置條件用例結(jié)束時，系統(tǒng)的狀態(tài)

1）系統(tǒng)能檢測到；

2）應為“可觀測”的：

只包含可檢測的條件，

合并影響相同的條件后置條件用例描述：基本事件流基本事件流是對用例中

常規(guī)、預期路徑的描述

（有時被稱為Happy

day場景），這是大多

數(shù)用戶在大部分時間中

所采取的路徑。通常體系了系統(tǒng)的核心

價值?；臼录饔美枋觯簲U展事件流系統(tǒng)還需要進行意外處理擴展事件流事件流編寫要點使用簡單的語法：主語明確，語義易于理解明確寫出“誰控制球”：通常就是指出參與者；從俯視的角度來編寫：指出參與者的動作，以及系統(tǒng)的響應，也就是跳開來；顯示過程向前推移：也就是每一步都有前進的感覺（例如：用戶按下tab鍵就不夠）；顯示執(zhí)行者的意圖而非動作（光有動作，讓人不容易直接從事件流中理會用例）。事件流編寫要點包括“合理的活動集”（帶數(shù)據(jù)的請求、系統(tǒng)確認、更改內(nèi)部、返回結(jié)果）；“確認”而不是“檢查是否”；（如：系統(tǒng)確認用戶密碼正確，而非系統(tǒng)檢查用戶密碼是否正確）可選擇地提及時間限制；習慣用語“用戶讓系統(tǒng)A與系統(tǒng)B交互”；習慣用語“循環(huán)執(zhí)行步驟x到y(tǒng)，直到條件滿足；用例描述模板用例編號[為用例制定一個唯一的編號，通常格式為UCxx]用例名稱[應為一個動詞短語，讓讀者一目了然地知道用例的目標]用例概述[用例的目標，一個概要性的描述]范圍[用例的設(shè)計范圍]主參與者[該用例的主Actor，在此列出名稱，并簡要的描述它]次要參與者[該用例的次要Actor，在此列出名稱，并簡要的描述它]項目相關(guān)人利益說明項目相關(guān)人利益[項目相關(guān)人員名稱][從該用例獲取的利益]…………前置條件[即啟動該用例所應該滿足的條件。]后置條件[即該用例完成之后，將執(zhí)行什么動作。]成功保證[描述當前目標完成后，環(huán)境變化情況。]基本事件流步驟活動1[在這里寫出觸發(fā)事件到目標完成以及清除的步驟。]2……(其中可以包含子事件流，以子事件流編號來表示)擴展事件流1a[1a表示是對1的擴展，其中應說明條件和活動]1b……(其中可以包含子事件流，以子事件流編號來表示)子事件流[對多次重復的事件流可以定義為子事件流，這也是抽取被包含用例的地方。]規(guī)則與約束[對該用例實現(xiàn)時需要考慮的業(yè)務規(guī)則、非功能需求、設(shè)計約束等]用例模型的建立過程分析過程—需求FEAT01.新增書籍信息FEAT02.修改已有的書籍信息FEAT03.書籍信息按計算機類、非計算機類分別建檔FEAT04.錄入新書時能夠自動按規(guī)則生成書號FEAT05.計算機類與非計算機類書籍采用不同的書號規(guī)則FEAT06.錄入新書時如果重名將自動提示FEAT07.按書名、作者、類別、出版社等關(guān)鍵字組合查詢書籍FEAT08.列出所有書籍信息FEAT09.記錄外借情況FEAT10.外借狀態(tài)能夠自動反應在書籍信息中FEAT11.按人、按書查詢外借情況FEAT12.列出所有的外借情況FEAT13.按特定時間段統(tǒng)計購買金額、冊數(shù)FEAT14.所有查詢、列表、統(tǒng)計功能應可以單獨對計算機類或非計算機類進行分析過程—合并特性到用例FEAT01.新增書籍信息FEAT02.修改已有的書籍信息FEAT03.書籍信息按計算機類、非計算機類分別建檔FEAT04.錄入新書時能夠自動按規(guī)則生成書號FEAT05.計算機類與非計算機類書籍采用不同的書號規(guī)則FEAT06.錄入新書時如果重名將自動提示FEAT07.按書名、作者、類別、出版社等關(guān)鍵字組合查詢書籍FEAT08.列出所有書籍信息FEAT09.記錄外借情況FEAT10.外借狀態(tài)能夠自動反應在書籍信息中FEAT11.按人、按書查詢外借情況FEAT12.列出所有的外借情況FEAT13.按特定時間段統(tǒng)計購買金額、冊數(shù)FEAT14.所有查詢、列表、統(tǒng)計功能應可以單獨對計算機類或

非計算機類進行UC01：

新增書籍信息UC02：

修改書籍信息UC01：

新增圖書信息UC03：

查詢書籍信息UC04：

登記外借信息UC05：

查詢外借信息UC06：

統(tǒng)計金額和冊數(shù)繪制用例圖分析過程—編寫用例框架性描述1.用例名稱：新增書籍信息（UC01）2.簡要說明：錄入新購書籍信息，并自動存儲建檔。3.事件流：3.1基本事件流3.2擴展事件流4.非功能需求5.前置條件用戶進入圖書管理系統(tǒng)。6.后置條件完成新書信息的存儲建檔。7.擴展點無8.優(yōu)先級最高（滿意度5，不滿意度5）分析過程—細化用例描述……3.事件流：3.1基本事件流

1）圖書管理員向系統(tǒng)發(fā)出“新增書籍信息”請求；

2）系統(tǒng)要求圖書管理員選擇要新增的書籍是計算機類還是非計算機類；

3）圖書管理員做出選擇后，顯示相應界面，讓圖書管理員輸入信息，并自動根據(jù)書號規(guī)則生成書號；

4）圖書管理員輸入書籍的相關(guān)信息，包括：書名、作者、出版社、ISBN號、開本、頁數(shù)、定價、是否有CDROM；

5）系統(tǒng)確認輸入的信息中書名未有重名；

6）系統(tǒng)將所輸入的信息存儲建檔。3.2擴展事件流

5a）如果輸入的書名有重名現(xiàn)象，則顯示出重名的書籍，并要求圖書管理員選擇修改書名或取消輸入；

5a1）圖書管理員選擇取消輸入，則結(jié)束用例，不做存儲建檔工作；

5a2）圖書管理員選擇修改書名后，轉(zhuǎn)到5）4.非功能需求無特殊要求……用例驅(qū)動需求方法：三次迭代外觀（fa?ade）迭代：提綱和高層描述填充（filled）迭代：拓寬和深化聚焦（focused）迭代：集中和剪枝外觀迭代主要目標：定義用戶的名稱和簡要描述，確定主要參與者和次要參與者主要信息來源：

>用戶

>項目團隊

>行業(yè)專家

>IT經(jīng)理

>用戶經(jīng)理

>數(shù)據(jù)擁有者外觀迭代：主要步驟編寫問題陳述：使命、遠景、價值，前面已述標識并評審現(xiàn)有文檔記錄和情報資源

>待開發(fā)系統(tǒng)的哪些要素以前被取消，被誰取消？

>誰想要構(gòu)建這個系統(tǒng)？誰不想構(gòu)建該系統(tǒng)？

>有沒有可以考慮的軟件包？是什么軟件包？

>上層經(jīng)理可接觸到本項目嗎？哪些上層經(jīng)理可接觸到？

>拋出這個想法有多少時間？想法的前身是什么確定執(zhí)行發(fā)起人的獨特觀點

>要解決的問題是什么？為什么需要一個系統(tǒng)？為什么需要計算機系統(tǒng)？誰會受影響？怎樣受到影響？外觀迭代：主要步驟評審業(yè)務過程定義：對以流程圖、活動圖（下一小節(jié)講述）形式的過程文檔進行評審。標識用戶、用戶組管理人員、項目相關(guān)人員、用戶組所服務的客戶以及數(shù)據(jù)擁有者

組織結(jié)構(gòu)圖！與項目相關(guān)人員面談：還包括其它需求捕獲方法的綜合應用，關(guān)鍵在于全面了解需求細節(jié)列出項目相關(guān)人員清單：

>內(nèi)外部

>角色化

>特征描述外觀迭代：主要步驟找出參與者：誰使用這個系統(tǒng)？誰安裝這個系統(tǒng)？誰啟動這個系統(tǒng)？誰維護這個系統(tǒng)？誰關(guān)閉這個系統(tǒng)？哪些其他的系統(tǒng)使用這個系統(tǒng)？誰從這個系統(tǒng)獲取信息？誰為這個系統(tǒng)提供信息？是否有事情自動在預計的時間發(fā)生（說明有定時器）？如果系統(tǒng)中發(fā)現(xiàn)一個事件，是否需要通知某個外部系統(tǒng)？系統(tǒng)是否需要與外部實體交互以幫助自己完成任務？進行用例調(diào)查

寫出用例概述

>采用用戶術(shù)語進行命名，并使用兩三句話說明其用途

>使用角色名稱，而非用戶職務

>將輸入或輸出信息結(jié)合