在上一篇《UML系統分析與設計02－用例圖和活動圖（上）》中，我們主要講解了在需求分析中的用例分析和繪制的方法和技巧，但是用例圖只告訴我們系統要“做什么”，至於“怎么做”卻並沒有很直觀的描述。為了更形象的說明我們的系統是如何一一滿足用戶需求的，並向用戶提供“怎么做”的細節描述，我們將使用“活動圖”來對用例進行補充性說明。
[ 注意：UML中並沒有說“活動圖”是用於對“用例圖”補充說明，但就我個人而言我更喜歡這樣來定義它，並在實踐中進行應用。]
[ 技巧：UML圖一般會分為靜態圖和動態圖。用例圖屬於靜態圖，而后而所述的“活動圖”屬於動態圖。在我們對某個問題進行分析和設計時一般都會使用靜態圖和動態圖相結合的方式來進行說明和描述。]
四、 Activity Diagram
（VS2010工具示例圖）
五、活動圖
1、 活動圖中的三板斧
通過上圖我們會發現，其實Activity Diagram還是有很多元素的，其實在我們的工作中你會發現在大部分時候我們並不需要對於這“十八般武藝”樣樣精通，其實只需三板斧即可！
第一板：開始－結束
第二板：分支－合並
第三板：分叉－聯結
當然，要讓這三板斧連貫起來我們還得有節點“Action”和線“Connector”。
(上面的命名為我個人習慣，可能有誤)
2、 參考示例
①：“創建唱片”示例：
②：“管理訂單”示例：
③：當然還有很多其它的元素這里並沒有提到，我們將在后繼說明中陸續講解，我個人認為在當前的分析階斷，重點用“三板斧”來解決。在架構設計和概要設計時我們還會用到其它的一些元素。
3、 沒有“泳道”
“泳道”UML在進行“活動圖”時，一個非常直觀好用的工具，但在VS2010中去並未提供，很遺憾在最新的VS11Bate版中也未提供對“泳道”的支持，感興趣的朋友也只能用替代方案了。方法如下：
從“Sinple Shapes”中拖入一個“Rectangle”,分別設置它的“Line Thickness”為“0.01”、“Color”為“=DarkGray”。
再從“UML Activity Diagram”中手入一個“Object Node”,並設置其屬性“Color”為“Gainsboro”。
以“創建唱片資料”為例，效果如下：
（此方案由CSDN論壇中的網友提供，雖非正統，但也不錯）
4、 沒有Activity圖
在VS2010中並未直接提供UML中標准的“Activity”圖。
①：按MSDN上對Activity的解釋如下：
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, there is at most one execution of this diagram at a time.
②：對應在視圖中就是這樣，呵呵。
5、 困惑的“Activity Parameter Node”
在上一點中，我們說了在VS2010的元素中並沒有正規的Activity圖，那么“Activity Parameter Node”就顯得“生不縫時”或是“文不對題”了。在實際應用中叫成“Action Parameter Node”是否更合適呢？這與“Input Pin”和“Output Pin”又有何本質區別呢（關於Input Pin和Output Pin在實踐應用將在后繼講解）？
我個人覺得“Activity Parameter Node”的定義與標准UML定義並不相符。（微軟向來都不太尊重標准，實用就行！）
以下摘自OMG《UML2.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.
③：示例圖
④:再上一個VS2010示例圖：
6、 回鍋“Artifact”。
“Artifact”並非UML中定義的元素，但在用例圖中是個非常不錯的擴展，他的存在使的基於“用例驅動”的設計方案變得異常的方便。
①、在VS2010中如何建立“Artifact”
首先，我們建立相應的用例圖，同時我們為不同的用例建立相應的活動圖。如上圖的“創建唱片資料用例圖”和“創建唱片資料活動圖”，在當前工作區中打開用例圖。
然后，在解決方案中選中相應的活動圖，點擊鼠標“左鍵”不放，然后拖動到用例圖所在的工作區中，這時就會自動創建一個“Artifact”。
最后，使用“Dependency”關系，使得特定用例和它對應的活動圖進行關聯，類圖等也可采用同樣方式進行關聯。
②、點評
在此不得不為VS2010叫好，因為有了這個功能，所有復雜的設計都可以與用例進行關聯，就如剛才的活動圖，同樣可以是以后的類圖，時序圖等。這也是即便有正版的VS2008也不用，改投VS2010的懷抱，因為它可以使的分析和設計如此的方便和靈活。可以使得分析和設計在不斷的迭代中顯示完善。
（是不是真的可以實現“文檔去死”的夢想？）
7、 屬性
其實在所有的元素都可能還帶有一些特殊屬性以表達更明確的意圖，比如：Action有Body、Language、Localconditions等，Call Behavior Action有IsSynchronous、Behavior等，大家在使用時可以進行設置，以便表達更精准的意思。
六、 需求分析演練
1、 需求背景
據CCAV報道：今年CD/DVD高產，可是Music農們卻高興不起來，由於銷路不暢，上好的CD/DVC舊在地攤上。為了幫助Music農解決銷售問題，當地Z&F積極組織調研，最終決定與“MusicStore”合作，來提供一個能為Music農和購買者建立信息交互的平台，從而為Music農擴大產品銷量、達到讓Music農增產能增收的目的…..
（此需求改編自“果農豐收，滯銷，Z&F幫忙”）
2、 需求收集
經過收集，我們決定對“MusicStore”增加以下需求，以便支持唱片的個人交易功能。
①：求購者可以發布求購信息。
②：求購者可以查詢出售信息。
③：出售者可以查詢求購信息。
④：出售者可以申請一個小店，並在小店中發布出售信息。（我們只收取少許服務費，你懂的）
3、 需求分析
①：參考用例
②：真理在哪？
在上一文中我們說到了通過“somebody do something”的方式尋來找用例，也就是通過主謂賓的方式來發現事務的本質，以防止“定、狀、補”等信息對我們認識事務本質的干擾，以便明確系統的真實意圖！
但是“顏回煮粥”的故事告訴我們“耳聽為虛，眼見也不一定為實！”，即便是事實也要經得起推敲！
而需求分析中的“推敲”就是對需求進行深入分析，接下來我們看看需求分析深入后對“Actor”的影響。
在“①：參考用例”中我們原以為可以反映用戶需求，但經過調查，我們發現某些Music農，對島國的某些藍光影視很感興趣（正常渠道無法購得，常以二手“Music” 的方式出現）而這個時候“Music農”就不再是出售者，轉身成為了購買者。也就是一個人他即可能是求購者，也可能是出售者。如果這樣的話，當我們在處理“用戶登錄”這樣的用例時就會很為難。
經過分析，我們可能會認為其實我們並不要求細分“求購者”和“出售者”，而采用了類似“權限”來控制。而用例圖就變成了類似如下：
當然也有人提出了人員派生的方法來實現，類似：
這也是一種常見的方法，但在本次需求中我個人並不十分推薦這樣做，在分析的初期可能有用，但隨着分析的深入，我們會發現“求購者”和“出售者”在系統中會被逐漸淡化，在最后的程序實現中可能跟本就不會出現。剛才我們也提到了“權限控制”的替代方案，最主要的是“派生和承繼”隱含了“多態”，但在本次需求中要實現這樣的“多態”有些困難，在此並不深究，后繼會跟進。
（本文只作引導，不一定是最終的正確答案。）
③：做個善於發現的人
常言道，有什么樣的要求，我就給什么樣的設計。所對需求分析的好壞直接關系到產品的最終命運。作為一個負責任的需求分析人員一定要做到多思而后斷，善於從不同的視角來審視、推敲同一樣的需求。洞察用戶的真實意圖，發現需求背后的故事！
比如：需求中有“小店”，為什么要“小店”？會不會有“市場”和“商城”？
④：沒有遠見必有近憂！
不管是做項目還是做產品，都必定會面臨“沒有遠見必有近憂”問題，這也正是很多公司對需求分析人員要求有一定的行業知識的重要性，對這一點我也很贊成。
做項目時，用戶可能會隨時想起一些功能要求你實現，也許有些強勢的項目經理會以《需求規格說明書》中沒有定義而拒絕，但在現實生活動往往沒這么容易。
做產品時更甚，如果沒有考慮好或設計好，對產品的后繼發展將埋下禍根。
（對需求的深挖掘/Digging Out Concepts，DDD中叫隱喻/Making implicit concepts Explicit，我個人認為是很有必要的。雖然在項目管理理論中並不推薦進行“鍍金”，但是在開發初期的“多謀善慮”一定是利大於弊。只是在最終的決策中我們可能要根據項目的不同目標，綜合各方因素進行一定的平衡和取舍，但對某些具有顯著特征的要求，那怕在需求中沒有強烈要求，但在設計時也要留有余地。這也許會被人詬病為“過度設計”，但凡事都是一個度的問題，也很考驗分析和設計人員的能力，因為有些事情是可以預知的，這也是附合產品的遠景規划。）
4、 輸出
當這些都處理妥當后，那么我們的又一個重要的里程碑即將完成。即，輸出《軟件系統需求分析說明書》，下一講中我們將給出一個說明書的較為典型的格式。