UML系統分析與設計02－使用案例圖和活動圖表（下）

     在上一篇《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、 輸出

     當這些都處理妥當後，那麼我們的又一個重要的裡程碑即將完成。即，輸出《軟體系統需求分析說明書》，下一講中我們將給出一個說明書的較為典型的格式。