UML系統(tǒng)分析與設(shè)計(jì)02-用例圖和活動(dòng)圖

1、【精品文檔】如有侵權(quán)，請(qǐng)聯(lián)系網(wǎng)站刪除，僅供學(xué)習(xí)與交流UML系統(tǒng)分析與設(shè)計(jì)02-用例圖和活動(dòng)圖.精品文檔.    每一個(gè)產(chǎn)品的需求是對(duì)現(xiàn)實(shí)世界特定問題的一種描述，而有些問題描述可能是非常的錯(cuò)綜復(fù)雜，以至在我們對(duì)其進(jìn)行分析時(shí)，會(huì)覺得無從下手甚至不知所措。    需求分析是系統(tǒng)設(shè)計(jì)和開發(fā)的基礎(chǔ)，需求分析的好壞會(huì)直接影響后繼設(shè)計(jì)和開發(fā)的質(zhì)量，嚴(yán)重時(shí)會(huì)影響到系統(tǒng)的成敗。UML中的用例圖就是為了方便我們分析與交流產(chǎn)品需求而生，同時(shí)也為我們把產(chǎn)品需求轉(zhuǎn)化為系統(tǒng)需求提供方便。        

2、 產(chǎn)品需求：一般反映的是現(xiàn)場(chǎng)的具體現(xiàn)象，經(jīng)常是由產(chǎn)品工程師/銷售人員收集或由用戶直接提供，表現(xiàn)的較為松散、粗放，是一種比較切合現(xiàn)實(shí)的描述。         系統(tǒng)需求：一般是在對(duì)產(chǎn)品需求進(jìn)行一定的分析后，對(duì)其中不能實(shí)現(xiàn)或?qū)崿F(xiàn)起來有困難的部分進(jìn)行了一定的取舍，同時(shí)對(duì)一些較為籠統(tǒng)的需求進(jìn)行明確和細(xì)化，甚至?xí)?duì)一些需求進(jìn)行了一定的抽象和重組。 有時(shí)也會(huì)結(jié)合具體應(yīng)用加入了一些邏輯的描述（即現(xiàn)實(shí)以外的抽象術(shù)語），表現(xiàn)的更加切合軟件系統(tǒng)。一般在評(píng)審?fù)ㄟ^后，系統(tǒng)需求會(huì)以產(chǎn)品需求規(guī)格說明說的方式提供，并成為系統(tǒng)開發(fā)的范圍依據(jù)。

3、60;        接下來我將介紹一下本人在用例分析過程中的一些心得和休會(huì)。一、“Somebody do something”模式         在我們對(duì)需求進(jìn)行分析時(shí)，我們可以本著“Somebody do something”的模式來尋找用例/關(guān)鍵用例，當(dāng)然這里的“somebody”可以泛指人、物或其它系統(tǒng)等。我們可以以“做某件事”作為一個(gè)用例，而后成為系統(tǒng)的一項(xiàng)功能，即滿足一點(diǎn)需求。如果能DO完所有的THINGS，那么我們的系統(tǒng)也就成了。

4、二、用例分析要注意事項(xiàng)1、單一場(chǎng)景，即每一個(gè)用例只為說明一件事，我個(gè)人反對(duì)包羅萬象的“上帝”用例。2、簡(jiǎn)單原則，即每一個(gè)用例要通俗易懂，能非常明確、簡(jiǎn)潔地說明其某項(xiàng)功能和作用，無任何歧義及多余的想象空間。3、唯一性，即每一件事/場(chǎng)景只能出現(xiàn)一次， 如果其它地方要用到同樣的場(chǎng)景可以采用“引用”的方式進(jìn)行組合。三、分而治之個(gè)個(gè)擊破的思想1、  N階的問題    在對(duì)新員工面試時(shí)，我一般會(huì)問一個(gè)“漢諾塔”的問題，在這個(gè)過程中我并不看重答案，只在呼解決問題的方法。即遞歸中是如何把“N階的問題轉(zhuǎn)化成N-1階，最后成為1階的問題”的思想。其實(shí)需求分析也是一個(gè)要把錯(cuò)綜復(fù)雜的N階

5、問題，最后轉(zhuǎn)化成1階問題的過程，這種從N至1的方法不僅在需求分析中能用上，其實(shí)在后繼的其他設(shè)計(jì)中也一樣很有用。2、  自上而下或自下而上    對(duì)需求的分析我們是可以采用自上而下或自下而上的進(jìn)行分析，相信這些大家都有耳聞，在此不做詳述。就我個(gè)人而言比較喜歡“自上而下”的分析方法，即由“宏觀”到“微觀”的過程，其實(shí)有點(diǎn)像我們?nèi)蝿?wù)分解中的WBS分解方式。對(duì)需求中描述的場(chǎng)景和所要解決的問題應(yīng)用“單一場(chǎng)景”、“簡(jiǎn)單原則”和“唯一性”逐一分解，至到合乎要求為止。    拿我們的“MusicStore”項(xiàng)目來說吧，系統(tǒng)無非是“系統(tǒng)出售唱片”（當(dāng)然這個(gè)需求有

6、點(diǎn)簡(jiǎn)單），但要滿足這個(gè)要求就得提供“管理員提供唱片”和“客戶購買唱片”等功能。以此類推“管理員提供唱片”可能會(huì)引發(fā)“管理員創(chuàng)建唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”等新的功能；同樣“客戶購買唱片”可能引發(fā)“客戶添加唱片到購物車”、“客戶移除購物車中的唱片”和“客戶結(jié)帳”等功能。如此反復(fù)遞歸，我們最后會(huì)發(fā)現(xiàn)好像用戶要的功能我們都能提供且足“單一場(chǎng)景”、“簡(jiǎn)單原則”和“唯一性”的要求。如果真是如此，那么我們的分析過程基本也就告一段落，之所以說是告一段落，是因?yàn)橐恍?fù)雜的需求只對(duì)其表象進(jìn)行分析是遠(yuǎn)遠(yuǎn)不夠的，還得站在更高的全局的視角來進(jìn)一步審視，可能還得對(duì)其進(jìn)行一定的重組甚至抽象，

7、直到滿足系統(tǒng)的要求，后繼我們將會(huì)有相關(guān)的例子。3、  邊界和委托    邊界，在需求定義的場(chǎng)景中，有一部分場(chǎng)景他們的工作背景和工作方式都比較類似，且彼此之間有著較為緊密的聯(lián)系，那么這些用例就可以組成一個(gè)相對(duì)封閉的區(qū)間，這就是用例邊界。   有時(shí)候我們也會(huì)根據(jù)不同的actor來區(qū)分不同的邊界。    比如：“管理員創(chuàng)建唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”就可以認(rèn)為是“管理唱片資料”這樣一個(gè)邊界。    由于VS2010并未提供Boundary功能，而是以subsystem來提供。為了更

8、好的說明問題所以此處提供2張圖，第二張由EA繪制。    有時(shí)我們會(huì)把同一個(gè)邊界內(nèi)具有相對(duì)內(nèi)聚性的用例抽象成一個(gè)用例。    委拖，在進(jìn)行用例分析時(shí)，當(dāng)出現(xiàn)有些用例已超出了當(dāng)前的邊界，但是與邊界內(nèi)的一些用例又有較為緊密的關(guān)系時(shí)，我們往往可以考慮使有“委托”的方式來，簡(jiǎn)化分析過程 。    就拿“客戶結(jié)賬”用例來說吧，它可能會(huì)引發(fā)出“系統(tǒng)查詢帳戶余額”、“系統(tǒng)轉(zhuǎn)賬”等一系列新的用例出來。此時(shí)我們可能會(huì)出現(xiàn)，其實(shí)我的目的就是“結(jié)帳”，至于怎么結(jié)帳及結(jié)賬的細(xì)節(jié)并不是我在本場(chǎng)景的主要議題，由此可能可以確定“查詢帳戶余額”等已超出本用例的邊界，

9、從而我們可以“委托的方式”委派給“銀聯(lián)系統(tǒng)付款”，從而一筆帶過。    有時(shí)候我們可以簡(jiǎn)單的認(rèn)為“服務(wù)”就是邊界外的委托。    在分析中我們可以先不關(guān)心大象是怎樣放進(jìn)冰箱的，只關(guān)心大象能不能放進(jìn)冰箱！(此圖來自互聯(lián)網(wǎng))4、  活用“Include”和“Extend”和“Generalization”    在用例會(huì)析中，少不了對(duì)“include”、“extern”和“Generaliztion”的應(yīng)用。Include:主要是指包含這些用例，包含并不指子用例就一定會(huì)同時(shí)發(fā)生。比如：管理管理唱片信息 新增唱片信息 修改唱片信息

10、 刪除唱片信息 導(dǎo)出唱片信息Extend：是指在滿足某一情況時(shí)一定會(huì)觸發(fā)某個(gè)用例?！翱蛻艚Y(jié)帳”在“未登錄”的情況下會(huì) 觸發(fā) “登錄”用例。由于未發(fā)現(xiàn)VS2010提供extension points的功能。為了更好的說明問題所以此處提供2張圖，第二張由EA繪制。Generaliztion：泛化，在用例視圖中我一般只用在Actor上面使用，在實(shí)際的用例中則使用較少。五、系統(tǒng)用例圖的“畫法”1、  不要“網(wǎng)狀化”    很多人喜歡把分析后的所有用例用一張圖來顯示，小系統(tǒng)還好說，系統(tǒng)大了就成了張蜘蛛網(wǎng)，凌亂的很，我個(gè)人建議盡量不要“網(wǎng)狀化”用例圖，以便不知從何看起。2、&

11、#160; 層次性表述    以多層的方式來漸漸細(xì)化用例，由大到小、由全局到局部的層層進(jìn)行細(xì)化。這種類似于根與葉子方式，在后繼的子系統(tǒng)分析，子模塊分析也大有幫助。3、  內(nèi)聚性    如果說層次是是一個(gè)縱向的表現(xiàn)方式，那么內(nèi)聚性就是一個(gè)橫向的表現(xiàn)方式。它一般用來規(guī)劃一些較為完整的場(chǎng)景過程。比如我們的“管理唱片資料”就是一個(gè)較為內(nèi)聚性的表現(xiàn)方式，當(dāng)然內(nèi)聚性的粗細(xì)粒度可結(jié)合具體的項(xiàng)目來定奪。4、  主次有別    在系統(tǒng)用例圖中，并不一定所有的用例都要全部列入，在說明和解決問題時(shí)，我們其實(shí)大部分用例關(guān)系只需引入主要的用

12、例即可。如果面面俱到就會(huì)出現(xiàn)“網(wǎng)狀化”的現(xiàn)象，使得說明效果還適得其反。5、  逐步完善    每一個(gè)系統(tǒng)用例圖都很難一步到位的進(jìn)行提供，很多時(shí)候都是一個(gè)逐步完善的過程，在我參與的一些項(xiàng)目中有一些都是經(jīng)過了幾輪的迭代之后才基本穩(wěn)定。我們主要講解了在需求分析中的用例分析和繪制的方法和技巧，但是用例圖只告訴我們系統(tǒng)要“做什么”，至于“怎么做”卻并沒有很直觀的描述。為了更形象的說明我們的系統(tǒng)是如何一一滿足用戶需求的，并向用戶提供“怎么做”的細(xì)節(jié)描述，我們將使用“活動(dòng)圖”來對(duì)用例進(jìn)行補(bǔ)充性說明。     注意：UML中并沒有說“活動(dòng)圖

13、”是用于對(duì)“用例圖”補(bǔ)充說明，但就我個(gè)人而言我更喜歡這樣來定義它，并在實(shí)踐中進(jìn)行應(yīng)用。     技巧：UML圖一般會(huì)分為靜態(tài)圖和動(dòng)態(tài)圖。用例圖屬于靜態(tài)圖，而后而所述的“活動(dòng)圖”屬于動(dòng)態(tài)圖。在我們對(duì)某個(gè)問題進(jìn)行分析和設(shè)計(jì)時(shí)一般都會(huì)使用靜態(tài)圖和動(dòng)態(tài)圖相結(jié)合的方式來進(jìn)行說明和描述。四、 Activity Diagram     （VS2010工具示例圖）五、活動(dòng)圖1、 活動(dòng)圖中的三板斧     通過上圖我們會(huì)發(fā)現(xiàn)，其實(shí)Activity Diagram還是有很多元素的，其實(shí)在我們的工作中你會(huì)發(fā)現(xiàn)在大部分

14、時(shí)候我們并不需要對(duì)于這“十八般武藝”樣樣精通，其實(shí)只需三板斧即可！     第一板：開始結(jié)束     第二板：分支合并     第三板：分叉聯(lián)結(jié)     當(dāng)然，要讓這三板斧連貫起來我們還得有節(jié)點(diǎn)“Action”和線“Connector”。     (上面的命名為我個(gè)人習(xí)慣，可能有誤)2、 參考示例     ：“創(chuàng)建唱片”示例：     ：“管理訂單”示例：    &#

15、160;：當(dāng)然還有很多其它的元素這里并沒有提到，我們將在后繼說明中陸續(xù)講解，我個(gè)人認(rèn)為在當(dāng)前的分析階斷，重點(diǎn)用“三板斧”來解決。在架構(gòu)設(shè)計(jì)和概要設(shè)計(jì)時(shí)我們還會(huì)用到其它的一些元素。3、 沒有“泳道”     “泳道”UML在進(jìn)行“活動(dòng)圖”時(shí)，一個(gè)非常直觀好用的工具，但在VS2010中去并未提供，很遺憾在最新的VS11Bate版中也未提供對(duì)“泳道”的支持，感興趣的朋友也只能用替代方案了。方法如下：     從“Sinple Shapes”中拖入一個(gè)“Rectangle”,分別設(shè)置它的“Line Thickness”為“0.01”、“Col

16、or”為“=DarkGray”。     再從“UML Activity Diagram”中手入一個(gè)“Object Node”,并設(shè)置其屬性“Color”為“Gainsboro”。     以“創(chuàng)建唱片資料”為例，效果如下：     （此方案由CSDN論壇中的網(wǎng)友提供，雖非正統(tǒng)，但也不錯(cuò)）4、 沒有Activity圖     在VS2010中并未直接提供UML中標(biāo)準(zhǔn)的“Activity”圖。     ：按MSDN上對(duì)Activity的解釋如下：&

17、#160;    The flow of work that is depicted by an activity diagram. To see the properties of an activity, you must select it in UML Model Explorer.· Is Read Only - If true, the activity should not change the state of any object. · Is Single Execution - If true, ther

18、e is at most one execution of this diagram at a time.      ：對(duì)應(yīng)在視圖中就是這樣，呵呵。5、 困惑的“Activity Parameter Node”     在上一點(diǎn)中，我們說了在VS2010的元素中并沒有正規(guī)的Activity圖，那么“Activity Parameter Node”就顯得“生不縫時(shí)”或是“文不對(duì)題”了。在實(shí)際應(yīng)用中叫成“Action Parameter Node”是否更合適呢？這與“Input Pin”和“Output Pin”又有何本質(zhì)區(qū)別呢（關(guān)于In

19、put Pin和Output Pin在實(shí)踐應(yīng)用將在后繼講解）？     我個(gè)人覺得“Activity Parameter Node”的定義與標(biāo)準(zhǔn)UML定義并不相符。（微軟向來都不太尊重標(biāo)準(zhǔn)，實(shí)用就行?。?#160;    以下摘自O(shè)MGUML2.0 Superstructure Specification對(duì)“Activity parameter nodes”的部分說明：     ：Activity parameter nodes are displayed on the border.    &

20、#160;：An activity parameter node is an object node for inputs and outputs to activities.     ：示例圖     :再上一個(gè)VS2010示例圖：6、 回鍋“Artifact”。     “Artifact”并非UML中定義的元素，但在用例圖中是個(gè)非常不錯(cuò)的擴(kuò)展，他的存在使的基于“用例驅(qū)動(dòng)”的設(shè)計(jì)方案變得異常的方便。     、在VS2010中如何建立“Artifact”  &#

21、160;  首先，我們建立相應(yīng)的用例圖，同時(shí)我們?yōu)椴煌挠美⑾鄳?yīng)的活動(dòng)圖。如上圖的“創(chuàng)建唱片資料用例圖”和“創(chuàng)建唱片資料活動(dòng)圖”，在當(dāng)前工作區(qū)中打開用例圖。     然后，在解決方案中選中相應(yīng)的活動(dòng)圖，點(diǎn)擊鼠標(biāo)“左鍵”不放，然后拖動(dòng)到用例圖所在的工作區(qū)中，這時(shí)就會(huì)自動(dòng)創(chuàng)建一個(gè)“Artifact”。     最后，使用“Dependency”關(guān)系，使得特定用例和它對(duì)應(yīng)的活動(dòng)圖進(jìn)行關(guān)聯(lián)，類圖等也可采用同樣方式進(jìn)行關(guān)聯(lián)。     、點(diǎn)評(píng)     在此不得不為VS201

22、0叫好，因?yàn)橛辛诉@個(gè)功能，所有復(fù)雜的設(shè)計(jì)都可以與用例進(jìn)行關(guān)聯(lián)，就如剛才的活動(dòng)圖，同樣可以是以后的類圖，時(shí)序圖等。這也是即便有正版的VS2008也不用，改投VS2010的懷抱，因?yàn)樗梢允沟姆治龊驮O(shè)計(jì)如此的方便和靈活?？梢允沟梅治龊驮O(shè)計(jì)在不斷的迭代中顯示完善。    （是不是真的可以實(shí)現(xiàn)“文檔去死”的夢(mèng)想？）7、 屬性其實(shí)在所有的元素都可能還帶有一些特殊屬性以表達(dá)更明確的意圖，比如：Action有Body、Language、Localconditions等，Call Behavior Action有IsSynchronous、Behavior等，大家在使用時(shí)可以進(jìn)行設(shè)置，以便

23、表達(dá)更精準(zhǔn)的意思。六、 需求分析演練1、 需求背景      據(jù)CCAV報(bào)道：今年CD/DVD高產(chǎn)，可是Music農(nóng)們卻高興不起來，由于銷路不暢，上好的CD/DVC舊在地?cái)偵稀榱藥椭鶰usic農(nóng)解決銷售問題，當(dāng)?shù)豘&F積極組織調(diào)研，最終決定與“MusicStore”合作，來提供一個(gè)能為Music農(nóng)和購買者建立信息交互的平臺(tái)，從而為Music農(nóng)擴(kuò)大產(chǎn)品銷量、達(dá)到讓Music農(nóng)增產(chǎn)能增收的目的.     （此需求改編自“果農(nóng)豐收，滯銷，Z&F幫忙”）2、 需求收集     

24、;經(jīng)過收集，我們決定對(duì)“MusicStore”增加以下需求，以便支持唱片的個(gè)人交易功能。     ：求購者可以發(fā)布求購信息。     ：求購者可以查詢出售信息。     ：出售者可以查詢求購信息。     ：出售者可以申請(qǐng)一個(gè)小店，并在小店中發(fā)布出售信息。（我們只收取少許服務(wù)費(fèi)，你懂的）3、 需求分析     ：參考用例     ：真理在哪？     在上一文中我們說到了通過“someb

25、ody do something”的方式尋來找用例，也就是通過主謂賓的方式來發(fā)現(xiàn)事務(wù)的本質(zhì)，以防止“定、狀、補(bǔ)”等信息對(duì)我們認(rèn)識(shí)事務(wù)本質(zhì)的干擾，以便明確系統(tǒng)的真實(shí)意圖！     但是“顏回煮粥”的故事告訴我們“耳聽為虛，眼見也不一定為實(shí)！”，即便是事實(shí)也要經(jīng)得起推敲！     而需求分析中的“推敲”就是對(duì)需求進(jìn)行深入分析，接下來我們看看需求分析深入后對(duì)“Actor”的影響。     在“：參考用例”中我們?cè)詾榭梢苑从秤脩粜枨?，但?jīng)過調(diào)查，我們發(fā)現(xiàn)某些Music農(nóng)，對(duì)島國的某些藍(lán)光影視很感興趣（正常渠道無

26、法購得，常以二手“Music” 的方式出現(xiàn)）而這個(gè)時(shí)候“Music農(nóng)”就不再是出售者，轉(zhuǎn)身成為了購買者。也就是一個(gè)人他即可能是求購者，也可能是出售者。如果這樣的話，當(dāng)我們?cè)谔幚怼坝脩舻卿洝边@樣的用例時(shí)就會(huì)很為難。     經(jīng)過分析，我們可能會(huì)認(rèn)為其實(shí)我們并不要求細(xì)分“求購者”和“出售者”，而采用了類似“權(quán)限”來控制。而用例圖就變成了類似如下：     當(dāng)然也有人提出了人員派生的方法來實(shí)現(xiàn)，類似：     這也是一種常見的方法，但在本次需求中我個(gè)人并不十分推薦這樣做，在分析的初期可能有用，但隨著分析的深入，我們會(huì)發(fā)現(xiàn)“求購者”和“出售者”在系統(tǒng)中會(huì)被逐漸淡化，在最后的程序?qū)崿F(xiàn)中可能跟本就不會(huì)出現(xiàn)。剛才我們也提到了“權(quán)限控制”的替代方案，最主要的是“派生和承繼”隱含了“多態(tài)”，但在本次需求中要實(shí)現(xiàn)這樣的“多態(tài)”有些困難，在此并不深究，后繼會(huì)跟進(jìn)。     （本文只作引