基于UML的需求分析和系統(tǒng)設(shè)計
原文地址：基于UML的需求分析和系統(tǒng)設(shè)計
一、項目開始階段
通過與用戶的訪談，確認(rèn)待開發(fā)系統(tǒng)“要做什么”，從企業(yè)角度研究：
- 是否能做
- 是否能盈利
抓住重點：
- 項目的范圍：找出目前已存在的系統(tǒng)，~是否提供了相關(guān)的集成接口。
- 必要的業(yè)務(wù)流程：初期應(yīng)該捕捉“必要的”業(yè)務(wù)流程，避免對細(xì)節(jié)的研究。
- 項目的技術(shù)限制：包括使用的技術(shù)以及其他系統(tǒng)間的交流接口規(guī)范。
- 項目成功關(guān)鍵因素：了解利益相關(guān)方對整體項目成功與否最關(guān)切的問題是什么，并且評估問題和項目成敗的風(fēng)險是否相關(guān)。
上述四個重點，一開始就決定了項目是否會成功，如果項目開始就落入細(xì)節(jié)性的討論，反而容易造成項目的失敗。
二、需求分析階段
與客戶（領(lǐng)域?qū)＜遥贤?，進(jìn)行需求的收集和分析，標(biāo)準(zhǔn)文書表達(dá)，形成需求規(guī)格說明書，交由設(shè)計人員進(jìn)行后續(xù)的系統(tǒng)設(shè)計工作。
UML的用戶例圖是用于需要收集和表達(dá)的有力工具，但非易事，可能是零散的、沒有系統(tǒng)性的。
因此在分析用戶例前，可先對企業(yè)級的業(yè)務(wù)流程進(jìn)行規(guī)劃和設(shè)計，抓住企業(yè)的本質(zhì)工作流，為后續(xù)進(jìn)行詳細(xì)的需求收集和用例分析做好準(zhǔn)備。
1、業(yè)務(wù)流程設(shè)計
可以通過“企業(yè)級的用例”來完善工作流程規(guī)劃與設(shè)計，不過，大部分領(lǐng)域?qū)＜覍Α坝美钡慕邮芏容^差，因此可用另一個工具進(jìn)行企業(yè)的建模，即Eriksson和Penker所提出的一個活動圖的構(gòu)造型，稱為“Eriksson-Penker業(yè)務(wù)擴展模型”
1）業(yè)務(wù)流程規(guī)劃--Eriksson-Penker業(yè)務(wù)擴展模型
Eriksson-Penker業(yè)務(wù)擴展模型是一種“目標(biāo)導(dǎo)向”的流程分析方式，主要是將與業(yè)務(wù)流程相關(guān)的重要人、事、物以及這個業(yè)務(wù)流程所要實現(xiàn)的目標(biāo)做一個鏈接，描述了企業(yè)重要的人、事、物與流程的關(guān)系。
在項目開始隊階段，需求分析人員可以通過“Eriksson-Penker業(yè)務(wù)擴展模型”找出要開發(fā)系統(tǒng)的重要性，利用“目標(biāo)導(dǎo)向 ”方式，對業(yè)務(wù)流程進(jìn)行適當(dāng)?shù)那懈睢?/p>
2）業(yè)務(wù)流程分析--活動圖
2、需求收集--用例圖
三、系統(tǒng)設(shè)計階段
前一階段的主要產(chǎn)物是用例圖，后續(xù)的設(shè)計與開發(fā)都將以用例驅(qū)動，系統(tǒng)設(shè)計階段的主要工作，便是實現(xiàn)用戶例。
1、實現(xiàn)用例
實現(xiàn)用例的目的在于保證系統(tǒng)的設(shè)計可以滿足用戶的功能性需求，在實現(xiàn)用例過程種，應(yīng)該利用Jacobson所分類的三種分析類：
- 控制對象：
- 實體對象：
- 邊界對象：
1）勾勒用例的控制對象
2）針對控制對象繪制序列圖
3）找出用戶例的實體對象
4）系統(tǒng)設(shè)計階段的開發(fā)流程
2、建立領(lǐng)域模型
上面的實體對象與領(lǐng)域模型的關(guān)系？？？
1）“領(lǐng)域模型”的概念
2）使用類圖表達(dá)領(lǐng)域模型
3）實際安全演示
（1）住出院系統(tǒng)業(yè)務(wù)流程
在項目立項之后，需求分析師與醫(yī)院的領(lǐng)域?qū)＜彝ㄟ^面對面的訪談，整理出了醫(yī)院實際上的住院出院流程，并繪制成活動圖。
（2）住出院系統(tǒng)用例模型
需要分析師基于企業(yè)的業(yè)務(wù)流程圖，與領(lǐng)域?qū)＜彝ㄟ^進(jìn)一步溝通，進(jìn)行需求的收集，最終繪制出用例圖。當(dāng)然下圖中沒有包含用例敘述。
（3）住出院系統(tǒng)領(lǐng)域模型
在得到用例圖之后，便進(jìn)入實現(xiàn)用例的階段，可以通過上一節(jié)所介紹的有三種分類找到問題領(lǐng)域工勤上的重要概念，從而得到領(lǐng)域模型，然后通過類圖來表達(dá)。
比如針對上一節(jié)用例圖中的“登記出院記錄”用例，通過分析可以得到一個控制對象（登記出院記錄BPO）和多個實體對象（病床、病人、醫(yī)生、護(hù)士、病癥等），并繪制成如下的類圖。
（4）包圖
通常領(lǐng)域模型中會包含很多的類，必須對這些類進(jìn)行分類，放置在不同的命名空間中，利用命名空間之間的關(guān)系圖，來限制住不同分類對象之間的訪問，這就是“包圖”的使用場景。
“包圖”是一個高階的視圖，由于所有的類都必須屬于某一個包，因此當(dāng)包之間的關(guān)系被限定時，該包內(nèi)部所有的類，都會受到包圖中設(shè)置的影響。
比如最基本的分類就是按照上面所說的三種分析類，對上面的領(lǐng)域模型，按照這種方式進(jìn)行分類，便可繪制出如下包圖：
3、表達(dá)對象交互
1）序列圖
2）通信圖
3）交互概述圖
4、表達(dá)微觀設(shè)計
1）對象圖
2）狀態(tài)機圖
3）時間圖
總結(jié)和展望
其它UML圖形：
- 總則圖
- 組合結(jié)構(gòu)圖
- 組建圖
- 部署圖
其它資源
建模工具說明
用例圖
用例圖是指由參與者（Actor）、用例（Use Case），邊界以及它們之間的關(guān)系構(gòu)成的用于描述系統(tǒng)功能的視圖。
參與者
參與者不是特指人，是指系統(tǒng)以外的，在使用系統(tǒng)或與系統(tǒng)交互中所扮演的角色。
用例
用例是對包括變量在內(nèi)的一組動作序列的描述，系統(tǒng)執(zhí)行這些動作，并產(chǎn)生傳遞特定參與者的價值的可觀察結(jié)果。用例是參與者想要系統(tǒng)做的事情。
系統(tǒng)邊界
系統(tǒng)邊界是用來表示正在建模系統(tǒng)的邊界，系統(tǒng)邊界在畫圖中用方框來表示。因為系統(tǒng)邊界的作用有時候不是很明顯，所以我個人理解，在畫圖時可省略。
箭頭
箭頭用來表示參與者和系統(tǒng)通過相互發(fā)送信號或消息進(jìn)行交互的關(guān)聯(lián)關(guān)系。箭頭尾部用來表示啟動交互的一方，箭頭頭部用來表示被啟動的一方，其中用例總是要由參與者來啟動。
