系統(tǒng)分析與設(shè)計用例圖和活動圖

每一個產(chǎn)品的需求是對現(xiàn)實世界特定問題的一種描述，而有些問題描述也許是非常的錯綜復雜，以至在我們對其進行分析時，會覺得無從下手甚至不知所措。

需求分析是系統(tǒng)設(shè)計和開發(fā)的基礎(chǔ)，需求分析的好壞會直接影響后繼設(shè)計和開發(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)品需求進行一定的分析后，對其中不能實現(xiàn)或?qū)崿F(xiàn)起來有困難的部分進行了一定的取舍，同時對一些較為籠統(tǒng)的需求進行明確和細化，甚至會對一些需求進行了一定的抽象和重組。有時也會結(jié)合具體應用加入了一些邏輯的描述（即現(xiàn)實以外的抽象術(shù)語），表現(xiàn)的更加切合軟件系統(tǒng)。一般在評審通過后，系統(tǒng)需求會以《產(chǎn)品需求規(guī)格說明說》的方式提供，并成為系統(tǒng)開發(fā)的范圍依據(jù)。

接下來我將介紹一下本人在用例分析過程中的一些心得和休會。

一、“Somebodydosomething”模式

在我們對需求進行分析時，我們可以本著“Somebodydosomething”的模式來尋找用例/關(guān)鍵用例，當然這里的“somebody”可以泛指人、物或其它系統(tǒng)等。我們可以以“做某件事”作為一個用例，而后成為系統(tǒng)的一項功能，即滿足一點需求。假如能DO完所有的THINGS，那么我們的系統(tǒng)也就成了。

二、用例分析要注意事項1、單一場景，即每一個用例只為說明一件事，我個人反對包羅萬象的“上帝”用例。

2、簡樸原則，即每一個用例要通俗易懂，能非常明確、簡潔地說明其某項功能和作用，無任何歧義及多余的想象空間。

3、唯一性，即每一件事/場景只能出現(xiàn)一次，假如其它地方要用到同樣的場景可以采用“引用”的方式進行組合。

三、分而治之個個擊破的思想1、

N階的問題

在對新員工面試時，我一般會問一個“漢諾塔”的問題，在這個過程中我并不看重答案，只在呼解決問題的方法。即遞歸中是如何把“N階的問題轉(zhuǎn)化成N-1階，最后成為1階的問題”的思想。其實需求分析也是一個要把錯綜復雜的N階問題，最后轉(zhuǎn)化成1階問題的過程，這種從N至1的方法不僅在需求分析中能用上，其實在后繼的其他設(shè)計中也同樣很有用。

2、

自上而下或自下而上

對需求的分析我們是可以采用自上而下或自下而上的進行分析，相信這些大家都有耳聞，在此不做詳述。就我個人而言比較喜歡“自上而下”的分析方法，即由“宏觀”到“微觀”的過程，其實有點像我們?nèi)蝿?wù)分解中的WBS分解方式。對需求中描述的場景和所要解決的問題應用“單一場景”、“簡樸原則”和“唯一性”逐個分解，至到合乎規(guī)定為止。

拿我們的“MusicStore”項目來說吧，系統(tǒng)無非是“系統(tǒng)出售唱片”（當然這個需求有點簡樸），但要滿足這個規(guī)定就得提供“管理員提供唱片”和“客戶購買唱片”等功能。以此類推“管理員提供唱片”也許會引發(fā)“管理員創(chuàng)建唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”等新的功能；同樣“客戶購買唱片”也許引發(fā)“客戶添加唱片到購物車”、“客戶移除購物車中的唱片”和“客戶結(jié)帳”等功能。如此反復遞歸，我們最后會發(fā)現(xiàn)仿佛用戶要的功能我們都能提供且足“單一場景”、“簡樸原則”和“唯一性”的規(guī)定。假如真是如此，那么我們的分析過程基本也就告一段落，之所以說是告一段落，是由于一些復雜的需求只對其表象進行分析是遠遠不夠的，還得站在更高的全局的視角來進一步審閱，也許還得對其進行一定的重組甚至抽象，直到滿足系統(tǒng)的規(guī)定，后繼我們將會有相關(guān)的例子。

3、

邊界和委托

邊界，在需求定義的場景中，有一部分場景他們的工作背景和工作方式都比較類似，且彼此之間有著較為緊密的聯(lián)系，那么這些用例就可以組成一個相對封閉的區(qū)間，這就是用例邊界。

有時候我們也會根據(jù)不同的actor來區(qū)分不同的邊界。

比如：“管理員創(chuàng)建唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”就可以認為是“管理唱片資料”這樣一個邊界。

由于VS2023并未提供Boundary功能，而是以subsystem來提供。為了更好的說明問題所以此處提供2張圖，第二張由EA繪制。

有時我們會把同一個邊界內(nèi)具有相對內(nèi)聚性的用例抽象成一個用例。

委拖，在進行用例分析時，當出現(xiàn)有些用例已超過了當前的邊界，但是與邊界內(nèi)的一些用例又有較為緊密的關(guān)系時，我們往往可以考慮使有“委托”的方式來，簡化分析過程。

就拿“客戶結(jié)賬”用例來說吧，它也許會引發(fā)出“系統(tǒng)查詢帳戶余額”、“系統(tǒng)轉(zhuǎn)賬”等一系列新的用例出來。此時我們也許會出現(xiàn)，其實我的目的就是“結(jié)帳”，至于怎么結(jié)帳及結(jié)賬的細節(jié)并不是我在本場景的重要議題，由此也許可以擬定“查詢帳戶余額”等已超過本用例的邊界，從而我們可以“委托的方式”委派給“銀聯(lián)系統(tǒng)付款”，從而一筆帶過。

有時候我們可以簡樸的認為“服務(wù)”就是邊界外的委托。

在分析中我們可以先不關(guān)心大象是如何放進冰箱的，只關(guān)心大象能不能放進冰箱！(此圖來自互聯(lián)網(wǎng))

4、

活用“Include”和“Extend”和“Generalization”

在用例會析中，少不了對“include”、“extern”和“Generaliztion”的應用。Include:重要是指包含這些用例，包含并不指子用例就一定會同時發(fā)生。比如：管理管理唱片信息新增唱片信息修改唱片信息刪除唱片信息導出唱片信息

Extend：是指在滿足某一情況時一定會觸發(fā)某個用例?！翱蛻艚Y(jié)帳”在“未登錄”的情況下會觸發(fā)“登錄”用例。由于未發(fā)現(xiàn)VS2023提供extensionpoints的功能。為了更好的說明問題所以此處提供2張圖，第二張由EA繪制。

Generaliztion：泛化，在用例視圖中我一般只用在Actor上面使用，在實際的用例中則使用較少。

五、系統(tǒng)用例圖的“畫法”1、

不要“網(wǎng)狀化”

很多人喜歡把分析后的所有用例用一張圖來顯示，小系統(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)用例圖中，并不一定所有的用例都要所有列入，在說明和解決問題時，我們其實大部分用例關(guān)系只需引入重要的用例即可。假如面面俱到就會出現(xiàn)“網(wǎng)狀化”的現(xiàn)象，使得說明效果還適得其反。

5、

逐步完善

每一個系統(tǒng)用例圖都很難一步到位的進行提供，很多時候都是一個逐步完善的過程，在我參與的一些項目中有一些都是通過了幾輪的迭代之后才基本穩(wěn)定。我們重要講解了在需求分析中的用例分析和繪制的方法和技巧，但是用例圖只告訴我們系統(tǒng)要“做什么”，至于“怎么做”卻并沒有很直觀的描述。為了更形象的說明我們的系統(tǒng)是如何一一滿足用戶需求的，并向用戶提供“怎么做”的細節(jié)描述，我們將使用“活動圖”來對用例進行補充性說明。

[

注意：UML中并沒有說“活動圖”是用于對“用例圖”補充說明，但就我個人而言我更喜歡這樣來定義它，并在實踐中進行應用。]

[

技巧：UML圖一般會分為靜態(tài)圖和動態(tài)圖。用例圖屬于靜態(tài)圖，而后而所述的“活動圖”屬于動態(tài)圖。在我們對某個問題進行分析和設(shè)計時一般都會使用靜態(tài)圖和動態(tài)圖相結(jié)合的方式來進行說明和描述。]

四、

ActivityDiagram

（VS2023工具示例圖）

五、活動圖1、活動圖中的三板斧

通過上圖我們會發(fā)現(xiàn)，其實ActivityDiagram還是有很多元素的，其實在我們的工作中你會發(fā)現(xiàn)在大部分時候我們并不需要對于這“十八般武藝”樣樣精通，其實只需三板斧即可！

第一板：開始－結(jié)束

第二板：分支－合并

第三板：分叉－聯(lián)結(jié)

當然，要讓這三板斧連貫起來我們還得有節(jié)點“Action”和線“Connector”。

(上面的命名為我個人習慣，也許有誤)

2、參考示例

①：“創(chuàng)建唱片”示例：

②：“管理訂單”示例：

③：當然尚有很多其它的元素這里并沒有提到，我們將在后繼說明中陸續(xù)講解，我個人認為在當前的分析階斷，重點用“三板斧”來解決。在架構(gòu)設(shè)計和概要設(shè)計時我們還會用到其它的一些元素。

3、沒有“泳道”

“泳道”UML在進行“活動圖”時，一個非常直觀好用的工具，但在VS2023中去并未提供，很遺憾在最新的VS11Bate版中也未提供對“泳道”的支持，感愛好的朋友也只能用替代方案了。方法如下：

從“SinpleShapes”中拖入一個“Rectangle”,分別設(shè)立它的“LineThickness”為“0.01”、“Color”為“=DarkGray”。

再從“UMLActivityDiagram”中手入一個“ObjectNode”,并設(shè)立其屬性“Color”為“Gainsboro”。

以“創(chuàng)建唱片資料”為例，效果如下：

（此方案由CSDN論壇中的網(wǎng)友提供，雖非正統(tǒng)，但也不錯）

4、沒有Activity圖

在VS2023中并未直接提供UML中標準的“Activity”圖。

①：按MSDN上對Activity的解釋如下：

Theflowofworkthatisdepictedbyanactivitydiagram.Toseethepropertiesofanactivity,youmustselectitin

UMLModelExplorer.IsReadOnly

-Iftrue,theactivityshouldnotchangethestateofanyobject.IsSingleExecution

-Iftrue,thereisatmostoneexecutionofthisdiagramatatime.

②：相應在視圖中就是這樣，呵呵。

5、困惑的“ActivityParameterNode”

在上一點中，我們說了在VS2023的元素中并沒有正規(guī)的Activity圖，那么“ActivityParameterNode”就顯得“生不縫時”或是“文不對題”了。在實際應用中叫成“ActionParameterNode”是否更合適呢？這與“InputPin”和“OutputPin”又有何本質(zhì)區(qū)別呢（關(guān)于InputPin和OutputPin在實踐應用將在后繼講解）？

我個人覺得“ActivityParameterNode”的定義與標準UML定義并不相符。（微軟向來都不太尊重標準，實用就行?。?/p>

以下摘自O(shè)MG《UML2.0SuperstructureSpecification》對“Activityparameternodes”的部分說明：

①：Activityparameternodesaredisplayedontheborder.

②：Anactivityparameternodeisanobjectnodeforinputsandoutputstoactivities.

③：示例圖

④:再上一個VS2023示例圖：

6、回鍋“Artifact”。

“Artifact”并非UML中定義的元素，但在用例圖中是個非常不錯的擴展，他的存在使的基于“用例驅(qū)動”的設(shè)計方案變得異常的方便。

①、在VS2023中如何建立“Artifact”

一方面，我們建立相應的用例圖，同時我們?yōu)椴煌挠美⑾鄳幕顒訄D。如上圖的“創(chuàng)建唱片資料用例圖”和“創(chuàng)建唱片資料活動圖”，在當前工作區(qū)中打開用例圖。

然后，在解決方案中選中相應的活動圖，點擊鼠標“左鍵”不放，然后拖動到用例圖所在的工作區(qū)中，這時就會自動創(chuàng)建一個“Artifact”。

最后，使用“Dependency”關(guān)系，使得特定用例和它相應的活動圖進行關(guān)聯(lián)，類圖等也可采用同樣方式進行關(guān)聯(lián)。

②、點評

在此不得不為VS2023叫好，由于有了這個功能，所有復雜的設(shè)計都可以與用例進行關(guān)聯(lián)，就如剛才的活動圖，同樣可以是以后的類圖，時序圖等。這也是即便有正版的VS2023也不用，改投VS2023的懷抱，由于它可以使的分析和設(shè)計如此的方便和靈活?？梢允沟梅治龊驮O(shè)計在不斷的迭代中顯示完善。

（是不是真的可以實現(xiàn)“文檔去死”的夢想？）

7、屬性其實在所有的元素都也許還帶有一些特殊屬性以表達更明確的意圖，比如：Action有Body、Language、Localconditions等，CallBehaviorAction有IsSynchronous、Behavior等，大家在使用時可以進行設(shè)立，以便表達更精確的意思。

六、

需求分析演練1、需求背景

據(jù)CCAV報道：今年CD/DVD高產(chǎn)，可是Music農(nóng)們卻快樂不起來，由于銷路不暢，上好的CD/DVC舊在地攤上。為了幫助Music農(nóng)解決銷售問題，本地Z&F積極組織調(diào)研，最終決定與“MusicStore”合作，來提供一個能為Music農(nóng)和購買者建立信息交互的平臺，從而為Music農(nóng)擴大產(chǎn)品銷量、達成讓Music農(nóng)增產(chǎn)能增收的目的…..

（此需求改編自“果農(nóng)豐收，滯銷，Z&F幫忙”）

2、需求收集

通過收集，我們決定對“MusicStore”增長以下需求，以便支持唱片的個人交易功能。

①：求購者可以發(fā)布求購信息。

②：求購者可以查詢出售信息。

③：出售者可以查詢求購信息。

④：出售者可以申請一個小店，并在小店中發(fā)布出售信息。（我們只收取少許服務(wù)費，你懂的）

3、需求分析

①：參考用例

②：真理在哪？

在上一文中我們說到了通過“somebodydosomething”的方式尋來找用例，也就是通過主謂賓的方式來發(fā)現(xiàn)事務(wù)的本質(zhì)，以防止“定、狀、補”等信息對我們結(jié)識事務(wù)本質(zhì)的干擾，以便明確系統(tǒng)的真實意圖！

但是“顏回煮粥”的故事告訴我們“耳聽為虛，眼見也不一定為實！”，即便是事實也要經(jīng)得起推敲！

而需求分析中的“推敲”就是對需求進行進一步分析，接下來我們看看需求分析進一步后對“Actor”的影響。

在“①：參考用例”中我們原認為可以反映用戶需求，但通過調(diào)查，我們發(fā)現(xiàn)某些Music農(nóng)，對島國的某些藍光影視很感愛好（正常渠道無法購得，常以二手“Music”的方式出現(xiàn)）而這個時候“Music農(nóng)”就不再是出售者，轉(zhuǎn)身成為了購買者。也就是一個人他即也許是求購者，也也許是出售者。假如這樣的話，當我們在解決“用戶登錄”這樣的用例時就會很為難。

通過度析，我們也許會認為其實我們并不規(guī)定細分“求購者”和“出售者”，而采用了類似“權(quán)限”來控制。而用例圖就變成了類似如下：

當然也有人提出了人員派生的方法來實現(xiàn)，類似：

這也是一種常見的方法，但在本次需求中我個人并不十分推薦這樣做，在分析的初期也許有用，但隨著分析的進一步，我們會發(fā)現(xiàn)“求購者”和“出售者”在系統(tǒng)中會被逐漸淡化，在最后的程序?qū)崿F(xiàn)中也許跟本就不會出現(xiàn)。剛才我們也提到了“權(quán)限控制”的替代方案，最重要的是“派生和承繼”隱含了“多態(tài)”，但在本次需求中要實現(xiàn)這樣的“多態(tài)”有些困難，在此并不深究，后繼會跟進。

（本文只作引導，不一