《UML系統(tǒng)分析與設計02用例圖和活動圖Word版》由會員分享，可在線閱讀，更多相關《UML系統(tǒng)分析與設計02用例圖和活動圖Word版（20頁珍藏版）》請在裝配圖網(wǎng)上搜索。

1、傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ 每一個產(chǎn)品的需求是對現(xiàn)實世界特定問題的一種描述，而有些問題描述可能是非常的錯綜復雜，以至在我們對其進行分析時，會覺得無從下手甚至不知所措。 需求分析是系統(tǒng)設計和開發(fā)的基礎，需求分析的好壞會直接影響后繼設計和開發(fā)的質(zhì)量，嚴重時會影響到系統(tǒng)的成敗。UML中的用例圖就是為了方便我們分析與交流產(chǎn)品需求而生，同時也為我們把產(chǎn)品需求轉(zhuǎn)化為系統(tǒng)需求提供方便。 產(chǎn)品需求：一般反映的是現(xiàn)場的具體現(xiàn)象，經(jīng)常是由產(chǎn)品工程師/銷售人員收集或由用戶直接提供，表現(xiàn)的較為松散、粗放，是一種比較切合現(xiàn)實的描述。 系統(tǒng)需求：一般是在對產(chǎn)品需求進行一定的分析后，對其中不能實

2、現(xiàn)或?qū)崿F(xiàn)起來有困難的部分進行了一定的取舍，同時對一些較為籠統(tǒng)的需求進行明確和細化，甚至會對一些需求進行了一定的抽象和重組。 有時也會結(jié)合具體應用加入了一些邏輯的描述（即現(xiàn)實以外的抽象術語），表現(xiàn)的更加切合軟件系統(tǒng)。一般在評審通過后，系統(tǒng)需求會以產(chǎn)品需求規(guī)格說明說的方式提供，并成為系統(tǒng)開發(fā)的范圍依據(jù)。 接下來我將介紹一下本人在用例分析過程中的一些心得和休會。一、“Somebody do something”模式 在我們對需求進行分析時，我們可以本著“Somebody do something”的模式來尋找用例/關鍵用例，當然這里的“somebody”可以泛指人、物或其它系統(tǒng)等。我們可以以“做某件

3、事”作為一個用例，而后成為系統(tǒng)的一項功能，即滿足一點需求。如果能DO完所有的THINGS，那么我們的系統(tǒng)也就成了。二、用例分析要注意事項1、單一場景，即每一個用例只為說明一件事，我個人反對包羅萬象的“上帝”用例。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！2、簡單原則，即每一個用例要通俗易懂，能非常明確、簡潔地說明其某項功能和作用，無任何歧義及多余的想象空間。3、唯一性，即每一件事/場景只能出現(xiàn)一次， 如果其它地方要用到同樣的場景可以采用“引用”的方式進行組合。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！三、分而治之個個擊破的思想1、 N階的問題傳播優(yōu)秀Word版文檔 ，希

4、望對您有幫助，可雙擊去除！ 在對新員工面試時，我一般會問一個“漢諾塔”的問題，在這個過程中我并不看重答案，只在呼解決問題的方法。即遞歸中是如何把“N階的問題轉(zhuǎn)化成N-1階，最后成為1階的問題”的思想。其實需求分析也是一個要把錯綜復雜的N階問題，最后轉(zhuǎn)化成1階問題的過程，這種從N至1的方法不僅在需求分析中能用上，其實在后繼的其他設計中也一樣很有用。2、 自上而下或自下而上 對需求的分析我們是可以采用自上而下或自下而上的進行分析，相信這些大家都有耳聞，在此不做詳述。就我個人而言比較喜歡“自上而下”的分析方法，即由“宏觀”到“微觀”的過程，其實有點像我們?nèi)蝿辗纸庵械腤BS分解方式。對需求中描述的場景

5、和所要解決的問題應用“單一場景”、“簡單原則”和“唯一性”逐一分解，至到合乎要求為止。 拿我們的“MusicStore”項目來說吧，系統(tǒng)無非是“系統(tǒng)出售唱片”（當然這個需求有點簡單），但要滿足這個要求就得提供“管理員提供唱片”和“客戶購買唱片”等功能。以此類推“管理員提供唱片”可能會引發(fā)“管理員創(chuàng)建唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”等新的功能；同樣“客戶購買唱片”可能引發(fā)“客戶添加唱片到購物車”、“客戶移除購物車中的唱片”和“客戶結(jié)帳”等功能。如此反復遞歸，我們最后會發(fā)現(xiàn)好像用戶要的功能我們都能提供且足“單一場景”、“簡單原則”和“唯一性”的要求。如果真是如此，那么我們

6、的分析過程基本也就告一段落，之所以說是告一段落，是因為一些復雜的需求只對其表象進行分析是遠遠不夠的，還得站在更高的全局的視角來進一步審視，可能還得對其進行一定的重組甚至抽象，直到滿足系統(tǒng)的要求，后繼我們將會有相關的例子。3、 邊界和委托 邊界，在需求定義的場景中，有一部分場景他們的工作背景和工作方式都比較類似，且彼此之間有著較為緊密的聯(lián)系，那么這些用例就可以組成一個相對封閉的區(qū)間，這就是用例邊界。 有時候我們也會根據(jù)不同的actor來區(qū)分不同的邊界。 比如：“管理員創(chuàng)建唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”就可以認為是“管理唱片資料”這樣一個邊界。 由于VS2010并未提供

7、Boundary功能，而是以subsystem來提供。為了更好的說明問題所以此處提供2張圖，第二張由EA繪制。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ 有時我們會把同一個邊界內(nèi)具有相對內(nèi)聚性的用例抽象成一個用例。 委拖，在進行用例分析時，當出現(xiàn)有些用例已超出了當前的邊界，但是與邊界內(nèi)的一些用例又有較為緊密的關系時，我們往往可以考慮使有“委托”的方式來，簡化分析過程 。 就拿“客戶結(jié)賬”用例來說吧，它可能會引發(fā)出“系統(tǒng)查詢帳戶余額”、“系統(tǒng)轉(zhuǎn)賬”等一系列新的用例出來。此時我們可能會出現(xiàn)，其實我的目的就是“結(jié)帳”，至于怎么結(jié)帳及結(jié)

8、賬的細節(jié)并不是我在本場景的主要議題，由此可能可以確定“查詢帳戶余額”等已超出本用例的邊界，從而我們可以“委托的方式”委派給“銀聯(lián)系統(tǒng)付款”，從而一筆帶過。 有時候我們可以簡單的認為“服務”就是邊界外的委托。 在分析中我們可以先不關心大象是怎樣放進冰箱的，只關心大象能不能放進冰箱！傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！(此圖來自互聯(lián)網(wǎng))4、 活用“Include”和“Extend”和“Generalization” 在用例會析中，少不了對“include”、“extern”和“Generaliztion”的應用。Include:主要是指包含這些用例，包含并不指子用例就一定會同時發(fā)

9、生。比如：管理管理唱片信息 新增唱片信息 修改唱片信息 刪除唱片信息 導出唱片信息Extend：是指在滿足某一情況時一定會觸發(fā)某個用例?！翱蛻艚Y(jié)帳”在“未登錄”的情況下會 觸發(fā) “登錄”用例。由于未發(fā)現(xiàn)VS2010提供extension points的功能。為了更好的說明問題所以此處提供2張圖，第二張由EA繪制。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！Generaliztion：泛化，在用例視圖中我一般只用在Actor上面使用，在實際的用例中則使用較少。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！五、系統(tǒng)用例圖的“畫法”1、 不要“網(wǎng)狀化” 很多人喜歡把分析后的所有用例

10、用一張圖來顯示，小系統(tǒng)還好說，系統(tǒng)大了就成了張蜘蛛網(wǎng)，凌亂的很，我個人建議盡量不要“網(wǎng)狀化”用例圖，以便不知從何看起。2、 層次性表述 以多層的方式來漸漸細化用例，由大到小、由全局到局部的層層進行細化。這種類似于根與葉子方式，在后繼的子系統(tǒng)分析，子模塊分析也大有幫助。3、 內(nèi)聚性 如果說層次是是一個縱向的表現(xiàn)方式，那么內(nèi)聚性就是一個橫向的表現(xiàn)方式。它一般用來規(guī)劃一些較為完整的場景過程。比如我們的“管理唱片資料”就是一個較為內(nèi)聚性的表現(xiàn)方式，當然內(nèi)聚性的粗細粒度可結(jié)合具體的項目來定奪。4、 主次有別 在系統(tǒng)用例圖中，并不一定所有的用例都要全部列入，在說明和解決問題時，我們其實大部分用例關系只需引

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

12、進行應用。 技巧：UML圖一般會分為靜態(tài)圖和動態(tài)圖。用例圖屬于靜態(tài)圖，而后而所述的“活動圖”屬于動態(tài)圖。在我們對某個問題進行分析和設計時一般都會使用靜態(tài)圖和動態(tài)圖相結(jié)合的方式來進行說明和描述。四、Activity Diagram傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ （VS2010工具示例圖）五、活動圖1、 活動圖中的三板斧 通過上圖我們會發(fā)現(xiàn)，其實Activity Diagram還是有很多元素的，其實在我們的工作中你會發(fā)現(xiàn)在大部分時候我們并不需要對于這“十八般武藝”樣樣精通，其實只需三板斧即可！ 第一板：開始結(jié)束 第二板：分支合并 第三板：分叉聯(lián)結(jié) 當然，要讓這三板斧連貫起來

13、我們還得有節(jié)點“Action”和線“Connector”。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ (上面的命名為我個人習慣，可能有誤)2、 參考示例 ：“創(chuàng)建唱片”示例： ：“管理訂單”示例：傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ ：當然還有很多其它的元素這里并沒有提到，我們將在后繼說明中陸續(xù)講解，我個人認為在當前的分析階斷，重點用“三板斧”來解決。在架構(gòu)設計和概要設計時我們還會用到其它的一些元素。3、 沒有“泳道” “泳道”UML在進行“活動圖”時，一個非常直觀好用的工具，但在VS2010中去并未提供，很遺憾在最新的VS11Bate版中也未提供對“泳道”的支持

14、，感興趣的朋友也只能用替代方案了。方法如下： 從“Sinple Shapes”中拖入一個“Rectangle”,分別設置它的“Line Thickness”為“0.01”、“Color”為“=DarkGray”。 再從“UML Activity Diagram”中手入一個“Object Node”,并設置其屬性“Color”為“Gainsboro”。 以“創(chuàng)建唱片資料”為例，效果如下：傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ （此方案由CSDN論壇中的網(wǎng)友提供，雖非正統(tǒng)，但也不錯）4、 沒有Activity圖 在VS2010中并未直接提供UML中標準的“Activity”圖。 ：

15、按MSDN上對Activity的解釋如下： The flow of work that is depicted by an activity diagram. To see the properties of an activity, you must select it inUML 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 o

16、f this diagram at a time. ：對應在視圖中就是這樣，呵呵。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！5、 困惑的“Activity Parameter Node” 在上一點中，我們說了在VS2010的元素中并沒有正規(guī)的Activity圖，那么“Activity Parameter Node”就顯得“生不縫時”或是“文不對題”了。在實際應用中叫成“Action Parameter Node”是否更合適呢？這與“Input Pin”和“Output Pin”又有何本質(zhì)區(qū)別呢（關于Input Pin和Output Pin在實踐應用將在后繼講解）？ 我個人覺得“Ac

17、tivity Parameter Node”的定義與標準UML定義并不相符。（微軟向來都不太尊重標準，實用就行?。?以下摘自OMGUML2.0 Superstructure Specification對“Activity parameter nodes”的部分說明： ：Activity parameter nodes are displayed on the border. ：An activity parameter node is an object node for inputs and outputs to activities. ：示例圖傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙

18、擊去除！ :再上一個VS2010示例圖：6、 回鍋“Artifact”。傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ “Artifact”并非UML中定義的元素，但在用例圖中是個非常不錯的擴展，他的存在使的基于“用例驅(qū)動”的設計方案變得異常的方便。 、在VS2010中如何建立“Artifact” 首先，我們建立相應的用例圖，同時我們?yōu)椴煌挠美⑾鄳幕顒訄D。如上圖的“創(chuàng)建唱片資料用例圖”和“創(chuàng)建唱片資料活動圖”，在當前工作區(qū)中打開用例圖。 然后，在解決方案中選中相應的活動圖，點擊鼠標“左鍵”不放，然后拖動到用例圖所在的工作區(qū)中，這時就會自動創(chuàng)建一個“Artifact”。 最后，使

19、用“Dependency”關系，使得特定用例和它對應的活動圖進行關聯(lián)，類圖等也可采用同樣方式進行關聯(lián)。 、點評 在此不得不為VS2010叫好，因為有了這個功能，所有復雜的設計都可以與用例進行關聯(lián)，就如剛才的活動圖，同樣可以是以后的類圖，時序圖等。這也是即便有正版的VS2008也不用，改投VS2010的懷抱，因為它可以使的分析和設計如此的方便和靈活?？梢允沟梅治龊驮O計在不斷的迭代中顯示完善。 （是不是真的可以實現(xiàn)“文檔去死”的夢想？）7、 屬性其實在所有的元素都可能還帶有一些特殊屬性以表達更明確的意圖，比如：Action有Body、Language、Localconditions等，Call B

20、ehavior Action有IsSynchronous、Behavior等，大家在使用時可以進行設置，以便表達更精準的意思。六、需求分析演練1、 需求背景傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ 據(jù)CCAV報道：今年CD/DVD高產(chǎn)，可是Music農(nóng)們卻高興不起來，由于銷路不暢，上好的CD/DVC舊在地攤上。為了幫助Music農(nóng)解決銷售問題，當?shù)豘&F積極組織調(diào)研，最終決定與“MusicStore”合作，來提供一個能為Music農(nóng)和購買者建立信息交互的平臺，從而為Music農(nóng)擴大產(chǎn)品銷量、達到讓Music農(nóng)增產(chǎn)能增收的目的. （此需求改編自“果農(nóng)豐收，滯銷，Z&F幫忙”）2、

21、需求收集 經(jīng)過收集，我們決定對“MusicStore”增加以下需求，以便支持唱片的個人交易功能。 ：求購者可以發(fā)布求購信息。 ：求購者可以查詢出售信息。 ：出售者可以查詢求購信息。 ：出售者可以申請一個小店，并在小店中發(fā)布出售信息。（我們只收取少許服務費，你懂的）3、 需求分析 ：參考用例傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ ：真理在哪？ 在上一文中我們說到了通過“somebody do something”的方式尋來找用例，也就是通過主謂賓的方式來發(fā)現(xiàn)事務的本質(zhì)，以防止“定、狀、補”等信息對我們認識事務本質(zhì)的干擾，以便明確系統(tǒng)的真實意圖！ 但是“顏回煮粥”的故事告訴我們“耳

22、聽為虛，眼見也不一定為實！”，即便是事實也要經(jīng)得起推敲！ 而需求分析中的“推敲”就是對需求進行深入分析，接下來我們看看需求分析深入后對“Actor”的影響。 在“：參考用例”中我們原以為可以反映用戶需求，但經(jīng)過調(diào)查，我們發(fā)現(xiàn)某些Music農(nóng)，對島國的某些藍光影視很感興趣（正常渠道無法購得，常以二手“Music” 的方式出現(xiàn)）而這個時候“Music農(nóng)”就不再是出售者，轉(zhuǎn)身成為了購買者。也就是一個人他即可能是求購者，也可能是出售者。如果這樣的話，當我們在處理“用戶登錄”這樣的用例時就會很為難。 經(jīng)過分析，我們可能會認為其實我們并不要求細分“求購者”和“出售者”，而采用了類似“權限”來控制。而用例圖

23、就變成了類似如下：傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ 當然也有人提出了人員派生的方法來實現(xiàn)，類似： 這也是一種常見的方法，但在本次需求中我個人并不十分推薦這樣做，在分析的初期可能有用，但隨著分析的深入，我們會發(fā)現(xiàn)“求購者”和“出售者”在系統(tǒng)中會被逐漸淡化，在最后的程序?qū)崿F(xiàn)中可能跟本就不會出現(xiàn)。剛才我們也提到了“權限控制”的替代方案，最主要的是“派生和承繼”隱含了“多態(tài)”，但在本次需求中要實現(xiàn)這樣的“多態(tài)”有些困難，在此并不深究，后繼會跟進。 （本文只作引導，不一定是最終的正確答案。） ：做個善于發(fā)現(xiàn)的人 常言道，有什么樣的要求，我就給什么樣的設計。所對需求分析的好壞直接關系

24、到產(chǎn)品的最終命運。作為一個負責任的需求分析人員一定要做到多思而后斷，善于從不同的視角來審視、推敲同一樣的需求。洞察用戶的真實意圖，發(fā)現(xiàn)需求背后的故事！ 比如：需求中有“小店”，為什么要“小店”？會不會有“市場”和“商城”？傳播優(yōu)秀Word版文檔 ，希望對您有幫助，可雙擊去除！ ：沒有遠見必有近憂！ 不管是做項目還是做產(chǎn)品，都必定會面臨“沒有遠見必有近憂”問題，這也正是很多公司對需求分析人員要求有一定的行業(yè)知識的重要性，對這一點我也很贊成。 做項目時，用戶可能會隨時想起一些功能要求你實現(xiàn)，也許有些強勢的項目經(jīng)理會以需求規(guī)格說明書中沒有定義而拒絕，但在現(xiàn)實生活動往往沒這么容易。 做產(chǎn)品時更甚，如果

25、沒有考慮好或設計好，對產(chǎn)品的后繼發(fā)展將埋下禍根。 （對需求的深挖掘/Digging Out Concepts，DDD中叫隱喻/Making implicit concepts Explicit，我個人認為是很有必要的。雖然在項目管理理論中并不推薦進行“鍍金”，但是在開發(fā)初期的“多謀善慮”一定是利大于弊。只是在最終的決策中我們可能要根據(jù)項目的不同目標，綜合各方因素進行一定的平衡和取舍，但對某些具有顯著特征的要求，那怕在需求中沒有強烈要求，但在設計時也要留有余地。這也許會被人詬病為“過度設計”，但凡事都是一個度的問題，也很考驗分析和設計人員的能力，因為有些事情是可以預知的，這也是附合產(chǎn)品的遠景規(guī)劃。）4、 輸出 當這些都處理妥當后，那么我們的又一個重要的里程碑即將完成。即，輸出軟件系統(tǒng)需求分析說明書，下一講中我們將給出一個說明書的較為典型的格式。