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

1、    需求分析是系統(tǒng)設(shè)計(jì)和開(kāi)發(fā)的基礎(chǔ)，需求分析的好壞會(huì)直接影響后繼設(shè)計(jì)和開(kāi)發(fā)的質(zhì)量，嚴(yán)重時(shí)會(huì)影響到系統(tǒng)的成敗。UML中的用例圖就是為了方便我們分析與交流產(chǎn)品需求而生，同時(shí)也為我們把產(chǎn)品需求轉(zhuǎn)化為系統(tǒng)需求提供方便。         產(chǎn)品需求：一般反映的是現(xiàn)場(chǎng)的具體現(xiàn)象，經(jīng)常是由產(chǎn)品工程師/銷(xiāo)售人員收集或由用戶(hù)直接提供，表現(xiàn)的較為松散、粗放，是一種比較切合現(xiàn)實(shí)的描述。         系統(tǒng)需求：一般是在對(duì)產(chǎn)品需求進(jìn)行一

2、定的分析后，對(duì)其中不能實(shí)現(xiàn)或?qū)崿F(xiàn)起來(lái)有困難的部分進(jìn)行了一定的取舍，同時(shí)對(duì)一些較為籠統(tǒng)的需求進(jìn)行明確和細(xì)化，甚至?xí)?duì)一些需求進(jìn)行了一定的抽象和重組。有時(shí)也會(huì)結(jié)合具體應(yīng)用加入了一些邏輯的描述（即現(xiàn)實(shí)以外的抽象術(shù)語(yǔ)），表現(xiàn)的更加切合軟件系統(tǒng)。一般在評(píng)審?fù)ㄟ^(guò)后，系統(tǒng)需求會(huì)以產(chǎn)品需求規(guī)格說(shuō)明說(shuō)的方式提供，并成為系統(tǒng)開(kāi)發(fā)的范圍依據(jù)。                       &

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

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

5、題”的思想。其實(shí)需求分析也是一個(gè)要把錯(cuò)綜復(fù)雜的N階問(wèn)題，最后轉(zhuǎn)化成1階問(wèn)題的過(guò)程，這種從N至1的方法不僅在需求分析中能用上，其實(shí)在后繼的其他設(shè)計(jì)中也一樣很有用。 2、  自上而下或自下而上    對(duì)需求的分析我們是可以采用自上而下或自下而上的進(jìn)行分析，相信這些大家都有耳聞，在此不做詳述。就我個(gè)人而言比較喜歡“自上而下”的分析方法，即由“宏觀”到“微觀”的過(guò)程，其實(shí)有點(diǎn)像我們?nèi)蝿?wù)分解中的WBS分解方式。對(duì)需求中描述的場(chǎng)景和所要解決的問(wèn)題應(yīng)用“單一場(chǎng)景”、“簡(jiǎn)單原則”和“唯一性”逐一分解，至到合乎要求為止。     拿我們的“M

6、usicStore”項(xiàng)目來(lái)說(shuō)吧，系統(tǒng)無(wú)非是“系統(tǒng)出售唱片”（當(dāng)然這個(gè)需求有點(diǎn)簡(jiǎn)單），但要滿(mǎn)足這個(gè)要求就得提供“管理員提供唱片”和“客戶(hù)購(gòu)買(mǎi)唱片”等功能。以此類(lèi)推“管理員提供唱片”可能會(huì)引發(fā)“管理員創(chuàng)建唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”等新的功能；同樣“客戶(hù)購(gòu)買(mǎi)唱片”可能引發(fā)“客戶(hù)添加唱片到購(gòu)物車(chē)”、“客戶(hù)移除購(gòu)物車(chē)中的唱片”和“客戶(hù)結(jié)帳”等功能。如此反復(fù)遞歸，我們最后會(huì)發(fā)現(xiàn)好像用戶(hù)要的功能我們都能提供且足“單一場(chǎng)景”、“簡(jiǎn)單原則”和“唯一性”的要求。如果真是如此，那么我們的分析過(guò)程基本也就告一段落，之所以說(shuō)是告一段落，是因?yàn)橐恍?fù)雜的需求只對(duì)其表象進(jìn)行分析是遠(yuǎn)遠(yuǎn)不夠的，

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

8、 由于VS2010并未提供Boundary功能，而是以subsystem來(lái)提供。為了更好的說(shuō)明問(wèn)題所以此處提供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í)，我們往往可以考慮使有“委托”的方式來(lái)，簡(jiǎn)化分析過(guò)程 。    就拿“客戶(hù)結(jié)賬”用例來(lái)說(shuō)吧，它可能會(huì)引發(fā)出“系統(tǒng)查詢(xún)帳戶(hù)余額”、“系統(tǒng)轉(zhuǎn)賬”等一系列新的用例出來(lái)。此時(shí)我

9、們可能會(huì)出現(xiàn)，其實(shí)我的目的就是“結(jié)帳”，至于怎么結(jié)帳及結(jié)賬的細(xì)節(jié)并不是我在本場(chǎng)景的主要議題，由此可能可以確定“查詢(xún)帳戶(hù)余額”等已超出本用例的邊界，從而我們可以“委托的方式”委派給“銀聯(lián)系統(tǒng)付款”，從而一筆帶過(guò)。     有時(shí)候我們可以簡(jiǎn)單的認(rèn)為“服務(wù)”就是邊界外的委托。     在分析中我們可以先不關(guān)心大象是怎樣放進(jìn)冰箱的，只關(guān)心大象能不能放進(jìn)冰箱！(此圖來(lái)自互聯(lián)網(wǎng)) 4、  活用“Include”和“Extend”和“Generalization”    在用例會(huì)析中，少不了對(duì)“include

10、”、“extern”和“Generaliztion”的應(yīng)用。Include:主要是指包含這些用例，包含并不指子用例就一定會(huì)同時(shí)發(fā)生。比如：管理管理唱片信息 新增唱片信息 修改唱片信息 刪除唱片信息 導(dǎo)出唱片信息 Extend：是指在滿(mǎn)足某一情況時(shí)一定會(huì)觸發(fā)某個(gè)用例?！翱蛻?hù)結(jié)帳”在“未登錄”的情況下會(huì) 觸發(fā) “登錄”用例。由于未發(fā)現(xiàn)VS2010提供extension points的功能。為了更好的說(shuō)明問(wèn)題所以此處提供2張圖，第二張由EA繪制。   Generaliztion：泛化，在用例視圖中我一般只用在Actor上面使用，在實(shí)際的用例中則使用較少。

11、60; 五、系統(tǒng)用例圖的“畫(huà)法”1、  不要“網(wǎng)狀化”    很多人喜歡把分析后的所有用例用一張圖來(lái)顯示，小系統(tǒng)還好說(shuō)，系統(tǒng)大了就成了張蜘蛛網(wǎng)，凌亂的很，我個(gè)人建議盡量不要“網(wǎng)狀化”用例圖，以便不知從何看起。 2、  層次性表述    以多層的方式來(lái)漸漸細(xì)化用例，由大到小、由全局到局部的層層進(jìn)行細(xì)化。這種類(lèi)似于根與葉子方式，在后繼的子系統(tǒng)分析，子模塊分析也大有幫助。 3、  內(nèi)聚性    如果說(shuō)層次是是一個(gè)縱向的表現(xiàn)方式，那么內(nèi)聚性就是一個(gè)橫向的表現(xiàn)方式。它一般用來(lái)規(guī)劃一些較

12、為完整的場(chǎng)景過(guò)程。比如我們的“管理唱片資料”就是一個(gè)較為內(nèi)聚性的表現(xiàn)方式，當(dāng)然內(nèi)聚性的粗細(xì)粒度可結(jié)合具體的項(xiàng)目來(lái)定奪。 4、  主次有別    在系統(tǒng)用例圖中，并不一定所有的用例都要全部列入，在說(shuō)明和解決問(wèn)題時(shí)，我們其實(shí)大部分用例關(guān)系只需引入主要的用例即可。如果面面俱到就會(huì)出現(xiàn)“網(wǎng)狀化”的現(xiàn)象，使得說(shuō)明效果還適得其反。 5、  逐步完善    每一個(gè)系統(tǒng)用例圖都很難一步到位的進(jìn)行提供，很多時(shí)候都是一個(gè)逐步完善的過(guò)程，在我參與的一些項(xiàng)目中有一些都是經(jīng)過(guò)了幾輪的迭代之后才基本穩(wěn)定。我們主要講解了在需求分析中的

13、用例分析和繪制的方法和技巧，但是用例圖只告訴我們系統(tǒng)要“做什么”，至于“怎么做”卻并沒(méi)有很直觀的描述。為了更形象的說(shuō)明我們的系統(tǒng)是如何一一滿(mǎn)足用戶(hù)需求的，并向用戶(hù)提供“怎么做”的細(xì)節(jié)描述，我們將使用“活動(dòng)圖”來(lái)對(duì)用例進(jìn)行補(bǔ)充性說(shuō)明。     注意：UML中并沒(méi)有說(shuō)“活動(dòng)圖”是用于對(duì)“用例圖”補(bǔ)充說(shuō)明，但就我個(gè)人而言我更喜歡這樣來(lái)定義它，并在實(shí)踐中進(jìn)行應(yīng)用。     技巧：UML圖一般會(huì)分為靜態(tài)圖和動(dòng)態(tài)圖。用例圖屬于靜態(tài)圖，而后而所述的“活動(dòng)圖”屬于動(dòng)態(tài)圖。在我們對(duì)某個(gè)問(wèn)題進(jìn)行分析和設(shè)計(jì)時(shí)一般都會(huì)使用靜態(tài)圖和動(dòng)態(tài)圖相結(jié)合的方式來(lái)進(jìn)行說(shuō)明

14、和描述。 四、 Activity Diagram      （VS2010工具示例圖） 五、活動(dòng)圖1、 活動(dòng)圖中的三板斧     通過(guò)上圖我們會(huì)發(fā)現(xiàn)，其實(shí)Activity Diagram還是有很多元素的，其實(shí)在我們的工作中你會(huì)發(fā)現(xiàn)在大部分時(shí)候我們并不需要對(duì)于這“十八般武藝”樣樣精通，其實(shí)只需三板斧即可！     第一板：開(kāi)始結(jié)束     第二板：分支合并     第三板：分叉聯(lián)結(jié)   

15、 當(dāng)然，要讓這三板斧連貫起來(lái)我們還得有節(jié)點(diǎn)“Action”和線(xiàn)“Connector”。     (上面的命名為我個(gè)人習(xí)慣，可能有誤) 2、 參考示例     ：“創(chuàng)建唱片”示例：      ：“管理訂單”示例：      ：當(dāng)然還有很多其它的元素這里并沒(méi)有提到，我們將在后繼說(shuō)明中陸續(xù)講解，我個(gè)人認(rèn)為在當(dāng)前的分析階斷，重點(diǎn)用“三板斧”來(lái)解決。在架構(gòu)設(shè)計(jì)和概要設(shè)計(jì)時(shí)我們還會(huì)用到其它的一些元素。 3、 沒(méi)有“泳道”  &#

16、160;  “泳道”UML在進(jìn)行“活動(dòng)圖”時(shí)，一個(gè)非常直觀好用的工具，但在VS2010中去并未提供，很遺憾在最新的VS11Bate版中也未提供對(duì)“泳道”的支持，感興趣的朋友也只能用替代方案了。方法如下：     從“Sinple Shapes”中拖入一個(gè)“Rectangle”,分別設(shè)置它的“Line Thickness”為“0.01”、“Color”為“=DarkGray”。     再?gòu)摹癠ML Activity Diagram”中手入一個(gè)“Object Node”,并設(shè)置其屬性“Color”為“Gainsboro”。&#

17、160;    以“創(chuàng)建唱片資料”為例，效果如下：     （此方案由CSDN論壇中的網(wǎng)友提供，雖非正統(tǒng)，但也不錯(cuò)）  4、 沒(méi)有Activity圖     在VS2010中并未直接提供UML中標(biāo)準(zhǔn)的“Activity”圖。     ：按MSDN上對(duì)Activity的解釋如下：     The flow of work that is depicted by an activity diagram. To see the propert

18、ies 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, there is at most one execution of this diagram at a time.      ：對(duì)應(yīng)在視圖中就是這樣，呵呵。 

19、 5、 困惑的“Activity Parameter Node”     在上一點(diǎn)中，我們說(shuō)了在VS2010的元素中并沒(méi)有正規(guī)的Activity圖，那么“Activity Parameter Node”就顯得“生不縫時(shí)”或是“文不對(duì)題”了。在實(shí)際應(yīng)用中叫成“Action Parameter Node”是否更合適呢？這與“Input Pin”和“Output Pin”又有何本質(zhì)區(qū)別呢（關(guān)于Input Pin和Output Pin在實(shí)踐應(yīng)用將在后繼講解）？     我個(gè)人覺(jué)得“Activity Parameter Node”的定

20、義與標(biāo)準(zhǔn)UML定義并不相符。（微軟向來(lái)都不太尊重標(biāo)準(zhǔn)，實(shí)用就行?。?#160;    以下摘自O(shè)MGUML2.0 Superstructure Specification對(duì)“Activity parameter nodes”的部分說(shuō)明：     ：Activity parameter nodes are displayed on the border.     ：An activity parameter node is an object node for inputs and outputs to activi

21、ties.     ：示例圖      :再上一個(gè)VS2010示例圖：  6、 回鍋“Artifact”。     “Artifact”并非UML中定義的元素，但在用例圖中是個(gè)非常不錯(cuò)的擴(kuò)展，他的存在使的基于“用例驅(qū)動(dòng)”的設(shè)計(jì)方案變得異常的方便。      、在VS2010中如何建立“Artifact”     首先，我們建立相應(yīng)的用例圖，同時(shí)我們?yōu)椴煌挠美⑾鄳?yīng)的活動(dòng)圖。如上圖的“創(chuàng)建唱片資料用例圖”

22、和“創(chuàng)建唱片資料活動(dòng)圖”，在當(dāng)前工作區(qū)中打開(kāi)用例圖。     然后，在解決方案中選中相應(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)，類(lèi)圖等也可采用同樣方式進(jìn)行關(guān)聯(lián)。      、點(diǎn)評(píng)     在此不得不為VS2010叫好，因?yàn)橛辛诉@個(gè)功能，所有復(fù)雜的設(shè)計(jì)都可以與用例進(jìn)行關(guān)聯(lián)，就如剛才的活動(dòng)圖，同樣可以是以后的類(lèi)圖，時(shí)序

23、圖等。這也是即便有正版的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è)置，以便表達(dá)更精準(zhǔn)的意思。  六、 需求分析演練1、 需求背景 

24、;     據(jù)CCAV報(bào)道：今年CD/DVD高產(chǎn)，可是Music農(nóng)們卻高興不起來(lái)，由于銷(xiāo)路不暢，上好的CD/DVC舊在地?cái)偵?。為了幫助Music農(nóng)解決銷(xiāo)售問(wèn)題，當(dāng)?shù)豘&F積極組織調(diào)研，最終決定與“MusicStore”合作，來(lái)提供一個(gè)能為Music農(nóng)和購(gòu)買(mǎi)者建立信息交互的平臺(tái)，從而為Music農(nóng)擴(kuò)大產(chǎn)品銷(xiāo)量、達(dá)到讓Music農(nóng)增產(chǎn)能增收的目的.     （此需求改編自“果農(nóng)豐收，滯銷(xiāo)，Z&F幫忙”） 2、 需求收集     經(jīng)過(guò)收集，我們決定對(duì)“MusicStore”增加以下需求

25、，以便支持唱片的個(gè)人交易功能。     ：求購(gòu)者可以發(fā)布求購(gòu)信息。     ：求購(gòu)者可以查詢(xún)出售信息。     ：出售者可以查詢(xún)求購(gòu)信息。     ：出售者可以申請(qǐng)一個(gè)小店，并在小店中發(fā)布出售信息。（我們只收取少許服務(wù)費(fèi)，你懂的） 3、 需求分析     ：參考用例      ：真理在哪？     在上一文中我們說(shuō)到了通過(guò)“somebody do something”

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

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