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

需求分析是系統(tǒng)設(shè)計(jì)和開發(fā)的基礎(chǔ)，需求分析的好壞會(huì)直接影響后繼設(shè)計(jì)和開發(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àn)的較為松散、粗放，是一種比較切合現(xiàn)實(shí)的描述。

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

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

一、“Somebodydosomething”模式

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

二、用例分析要注意事項(xiàng)1、單一場(chǎng)景，即每一個(gè)用例只為說明一件事，我個(gè)人反對(duì)包羅萬象的“上帝”用例。

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

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

三、分而治之個(gè)個(gè)擊破的思想1、

N階的問題

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

2、

自上而下或自下而上

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

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

3、

邊界和委托

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

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

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

由于VS2023并未提供Boundary功能，而是以subsystem來提供。為了更好的說明問題所以此處提供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í)，我們往往可以考慮使有“委托”的方式來，簡化分析過程。

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

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

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

4、

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

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

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

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

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

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

很多人喜歡把分析后的所有用例用一張圖來顯示，小系統(tǒng)還好說，系統(tǒng)大了就成了張蜘蛛網(wǎng)，凌亂的很，我個(gè)人建議盡量不要“網(wǎng)狀化”用例圖，以便不知從何看起。

2、

層次性表述

以多層的方式來漸漸細(xì)化用例，由大到小、由全局到局部的層層進(jìn)行細(xì)化。這種類似于根與葉子方式，在后繼的子系統(tǒng)分析，子模塊分析也大有幫助。

3、

內(nèi)聚性

假如說層次是是一個(gè)縱向的表現(xiàn)方式，那么內(nèi)聚性就是一個(gè)橫向的表現(xiàn)方式。它一般用來規(guī)劃一些較為完整的場(chǎng)景過程。比如我們的“管理唱片資料”就是一個(gè)較為內(nèi)聚性的表現(xiàn)方式，當(dāng)然內(nèi)聚性的粗細(xì)粒度可結(jié)合具體的項(xiàng)目來定奪。

4、

主次有別

在系統(tǒng)用例圖中，并不一定所有的用例都要所有列入，在說明和解決問題時(shí)，我們其實(shí)大部分用例關(guān)系只需引入重要的用例即可。假如面面俱到就會(huì)出現(xiàn)“網(wǎng)狀化”的現(xiàn)象，使得說明效果還適得其反。

5、

逐步完善

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

[

注意：UML中并沒有說“活動(dòng)圖”是用于對(duì)“用例圖”補(bǔ)充說明，但就我個(gè)人而言我更喜歡這樣來定義它，并在實(shí)踐中進(jìn)行應(yīng)用。]

[

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

四、

ActivityDiagram

（VS2023工具示例圖）

五、活動(dòng)圖1、活動(dòng)圖中的三板斧

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

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

第二板：分支－合并

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

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

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

2、參考示例

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

②：“管理訂單”示例：

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

3、沒有“泳道”

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

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

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

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

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

4、沒有Activity圖

在VS2023中并未直接提供UML中標(biāo)準(zhǔn)的“Activity”圖。

①：按MSDN上對(duì)Activity的解釋如下：

Theflowofworkthatisdepictedbyanactivitydiagram.Toseethepropertiesofanactivity,youmustselectitin

UMLModelExplorer.IsReadOnly

-Iftrue,theactivityshouldnotchangethestateofanyobject.IsSingleExecution

-Iftrue,thereisatmostoneexecutionofthisdiagramatatime.

②：相應(yīng)在視圖中就是這樣，呵呵。

5、困惑的“ActivityParameterNode”

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

我個(gè)人覺得“ActivityParameterNode”的定義與標(biāo)準(zhǔn)UML定義并不相符。（微軟向來都不太尊重標(biāo)準(zhǔn)，實(shí)用就行！）

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

①：Activityparameternodesaredisplayedontheborder.

②：Anactivityparameternodeisanobjectnodeforinputsandoutputstoactivities.

③：示例圖

④:再上一個(gè)VS2023示例圖：

6、回鍋“Artifact”。

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

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

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

然后，在解決方案中選中相應(yīng)的活動(dòng)圖，點(diǎn)擊鼠標(biāo)“左鍵”不放，然后拖動(dòng)到用例圖所在的工作區(qū)中，這時(shí)就會(huì)自動(dòng)創(chuàng)建一個(gè)“Artifact”。

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

②、點(diǎn)評(píng)

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

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

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

六、

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

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

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

2、需求收集

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

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

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

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

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

3、需求分析

①：參考用例

②：真理在哪？

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

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

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

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

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

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

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

（本文只作引導(dǎo)，不一