（1）--什么是用例
我發(fā)現(xiàn)，在OO和UML幾乎一統(tǒng)天下的今天，仍有很多系統(tǒng)分析員對(duì)OO和UML一知半解，甚至包括很多已經(jīng)使用了很久UML的系統(tǒng)分析員。
于是打算寫(xiě)一個(gè)系列文章，將多年來(lái)的工作經(jīng)驗(yàn)做一個(gè)總結(jié)。對(duì)初學(xué)者起個(gè)啟蒙作用，也希望拋磚引喻，與各路大蝦共同探討，共同提高。
這個(gè)系列文章將以我對(duì)OO和系統(tǒng)分析的理解為主，從UML基礎(chǔ)開(kāi)始，闡述面向?qū)ο蟮男枨蠓治龇椒ǎ^(guò)程，并以RUP為例，闡述如何將OO過(guò)程與軟件過(guò)程有機(jī)結(jié)合在一起，做一個(gè)真正OO應(yīng)用。
好了，今天是第一篇。想得很遠(yuǎn)，真希望我能堅(jiān)持下去，呵呵
用例是什么？其原始英文是usecase，直譯過(guò)來(lái)就成了用例。這也是一個(gè)比較貼切的叫法了，從字面的直接理解就是使用的例子。另一種比較流行的定義是用例就是與使用者(actor)交互的，并且給使用者提供可觀測(cè)的有意義的結(jié)果的一系列活動(dòng)的集合。
這個(gè)定義還是比較費(fèi)解的，筆者在眾多應(yīng)聘者中發(fā)現(xiàn)很多使用用例來(lái)做需求的系統(tǒng)分析員，有的已經(jīng)使用了兩年以上，但仍不能把握用例的本質(zhì)，雖然他們號(hào)稱精通UML。
最具普遍意義的理解錯(cuò)誤是認(rèn)為用例就是功能的劃分和描述，認(rèn)為一個(gè)用例就是一個(gè)功能點(diǎn)。在這種理解下，用例變成了僅僅是較早前需求中功能框圖的翻版，很多人用用例來(lái)劃分子系統(tǒng)，功能模塊和功能點(diǎn)。如果這樣，用例根本沒(méi)有存在的必要。有意思的是，造成這種理解錯(cuò)誤的相當(dāng)一部分原因卻是因?yàn)閷?duì)OO思想的理解不夠深入，本質(zhì)上說(shuō)，把用例當(dāng)成功能點(diǎn)的系統(tǒng)分析員腦子里還是面向過(guò)程的那一套思想，雖然他們?cè)谑褂肙O的工具，OO的語(yǔ)言，號(hào)稱在做面向?qū)ο蟮拈_(kāi)發(fā)，但過(guò)程的影子還沒(méi)有從他們腦子里徹底抹去。
如果用例不是功能的話，它是什么呢？從定義上說(shuō)，能給使用者提供一個(gè)執(zhí)行結(jié)果的活動(dòng)，不就是功能嗎？我的回答是：錯(cuò)！功能是計(jì)算機(jī)術(shù)語(yǔ)，它是用來(lái)描述計(jì)算機(jī)的，而非定義需求的術(shù)語(yǔ)。功能實(shí)際描述的是輸入-->計(jì)算-->輸出。這讓你想到了什么？DFD圖？這可是典型的面向過(guò)程分析模式。因此我說(shuō)把用例當(dāng)做功能點(diǎn)的分析員實(shí)際在做面向過(guò)程的分析。
而用例則不是計(jì)算機(jī)術(shù)語(yǔ)，UML除了在計(jì)算機(jī)行業(yè)中應(yīng)用，它也經(jīng)常被應(yīng)用在其它行業(yè)中。用例是一種需求方法學(xué)，雖然軟件危機(jī)和OO的發(fā)展促成了它的誕生并被完美的融合進(jìn)了OO體系，形成了 UML，但它實(shí)際上并不是軟件行業(yè)的專用品。如果非要從功能的角度解釋，那么用例可以解釋為一系列完成一個(gè)特定目標(biāo)的“功能”的組合，針對(duì)不同的應(yīng)用場(chǎng)景，這些“功能”體現(xiàn)不同的組合方式。實(shí)際上，把用例解釋為某個(gè)參與者(actor)要做的一件事可能更為合適。這樣的一件事有以下幾個(gè)特征：
一、這件事是相對(duì)獨(dú)立的。這意味著它不需要與其它用例交互而獨(dú)自完成參與者的目的。也就是說(shuō)這件事從“功能”上說(shuō)是完備的。讀者可能會(huì)想到，用例之間不是也有關(guān)聯(lián)關(guān)系嗎？比如擴(kuò)展，比如實(shí)現(xiàn)，比如繼承，它看上去并不是獨(dú)立的嘛。關(guān)于這個(gè)問(wèn)題，筆者會(huì)在后續(xù)的文章里詳細(xì)說(shuō)明。這里稍微解釋一下，用例之間的關(guān)系是分析過(guò)程的產(chǎn)物，而且這種關(guān)系一般的產(chǎn)生在概念層用例階段和系統(tǒng)層用例階段。對(duì)于業(yè)務(wù)用例，這個(gè)特征是很明顯的。
二、這件事的執(zhí)行結(jié)果對(duì)參與者來(lái)說(shuō)是可觀測(cè)的和有意義的。例如，系統(tǒng)會(huì)監(jiān)控參與者在系統(tǒng)里的操作，并在參與者刪除數(shù)據(jù)之前備份。雖然它是系統(tǒng)的一個(gè)必需組成部分，但它在需求階段卻不應(yīng)該作為用例出現(xiàn)。因?yàn)檫@是一個(gè)后臺(tái)進(jìn)程，對(duì)參與者來(lái)說(shuō)是不可觀測(cè)的，它應(yīng)該在系統(tǒng)用例分析階段定義。又比如說(shuō)，登錄系統(tǒng)是一個(gè)有效的用例，但輸入密碼卻不是。這是因?yàn)榈卿浵到y(tǒng)對(duì)參與者是有意義的，這樣他可以獲得身份認(rèn)證和授權(quán)，但輸入密碼卻是沒(méi)有意義的，輸入完了呢？有什么結(jié)果嗎？
三、這件事必須由一個(gè)參與者發(fā)起。不存在沒(méi)有參與者的用例，用例不應(yīng)該自動(dòng)啟動(dòng)，也不應(yīng)該主動(dòng)啟動(dòng)另一個(gè)用例。用例總是由一個(gè)參與者發(fā)起，并且滿足特征二。例如從ATM 取錢(qián)是一個(gè)有效的用例，ATM吐鈔卻不是。因?yàn)锳TM是不會(huì)無(wú)緣無(wú)故吐鈔的，否則，我從此天天守在ATM旁，生活無(wú)憂矣。
四、這件事必然是以動(dòng)賓短語(yǔ)形式出現(xiàn)的。即，這件事必須有一個(gè)動(dòng)作和動(dòng)作的受體。例如，喝水是一個(gè)有效的用例，而“喝”和“水”卻不是。雖然生活常識(shí)告訴我們，在沒(méi)有水的情況下人是不會(huì)做出喝這個(gè)動(dòng)作的，水也必然是喝進(jìn)去的，而不是滑進(jìn)去的，但是筆者所見(jiàn)的很多用例中類似“計(jì)算”，“統(tǒng)計(jì)”，“報(bào)表”，“輸出”，“錄入”之類的并不在少數(shù)。
除去以上的特征，筆者覺(jué)得用例的含義還要更深些。首先，用例的背后是一種需求方法論。其核心是以參與者為中心（區(qū)別于以計(jì)算機(jī)系統(tǒng)為中心），從參與者的角度來(lái)描述他要做的日常工作（區(qū)別于以業(yè)務(wù)流程描述的方式），并分析這些日常工作之間是如何交互的（區(qū)別于數(shù)據(jù)流的描述方式）。換句話說(shuō)，用例分析的首要目標(biāo)不是要弄清楚某項(xiàng)業(yè)務(wù)是如何一步一步完成的，而是要弄清楚有多少參與者？每個(gè)參與者都做什么？業(yè)務(wù)流程分析則是后續(xù)的工作了。其次，用例簡(jiǎn)直就是為OO而生的，其思想完美的符合OO。用例分析方法試圖找到問(wèn)題領(lǐng)域內(nèi)所有相對(duì)獨(dú)立的參與者和事件，并把業(yè)務(wù)流程當(dāng)成是這些參與者和事件之間的交互結(jié)果（在UML用活動(dòng)圖或序列圖來(lái)描述）。因此，用例方法被吸納到OO之后，UML得以以完備的形式出現(xiàn)，用例成為了真正的OO核心。在 RUP里，這種核心作用被發(fā)揮到極致，產(chǎn)生了用例驅(qū)動(dòng)（usecase driven）的軟件過(guò)程方法，在RUP里，軟件生產(chǎn)的所有過(guò)程和產(chǎn)物都是圍繞著用例形成的。
可以說(shuō)，用例分析是OO的第一步。如果用例分析本身出了問(wèn)題，對(duì)業(yè)務(wù)架構(gòu)，軟件架構(gòu)的影響是很大的，將大大削弱OO的優(yōu)勢(shì)--復(fù)用、擴(kuò)展。筆者認(rèn)為軟件復(fù)用可以分為三個(gè)層次，最低層次的復(fù)用是代碼級(jí)復(fù)用，這是由OO語(yǔ)言特性提供支持的，例如繼承，聚合，多態(tài)；較高層次的復(fù)用是組件級(jí)復(fù)用，這是由設(shè)計(jì)模式提供支持的，例如Factory模式, Builder模式；最高層次的復(fù)用則是服務(wù)級(jí)復(fù)用，這在很大程度上是由應(yīng)用服務(wù)器和通訊協(xié)議來(lái)提供支持的，例如最近炒得火熱的SOA（面向服務(wù)的應(yīng)用）架構(gòu)。用例分析的好壞也許對(duì)代碼級(jí)和組件級(jí)的復(fù)用影響不太大，但對(duì)服務(wù)級(jí)的復(fù)用影響卻是巨大的。筆者認(rèn)為服務(wù)級(jí)復(fù)用是OO的最高境界，而結(jié)構(gòu)良好的用例分析則是達(dá)到這一境界的基礎(chǔ)。
閑話：
今天你OO了嗎？
如果你的分析習(xí)慣是在調(diào)研需求時(shí)最先弄清楚有多少業(yè)務(wù)流程，先畫(huà)出業(yè)務(wù)流程圖，然后順藤摸瓜，找出業(yè)務(wù)流程中每一步驟的參與部門(mén)或崗位，弄清楚在這一步參與者所做的事情和填寫(xiě)表單的結(jié)果，并關(guān)心用戶是如何把這份表單傳給到下一個(gè)環(huán)節(jié)的。那么很不幸，你還在做面向過(guò)程的事情。
如果你的分析習(xí)慣是在調(diào)研需求時(shí)最先弄清楚有多少部門(mén)，多少崗位，然后找到每一個(gè)崗位的業(yè)務(wù)代表，問(wèn)他們類似的問(wèn)題：你平時(shí)都做什么？這件事是誰(shuí)交辦的？做完了你需要通知或傳達(dá)給誰(shuí)嗎？做這件事情你都需要填寫(xiě)些什么表格嗎？....那么恭喜你，你已經(jīng)OO啦！
（2）--用例的類型與粒度
在正式討論如何獲取用例之前，筆者覺(jué)得有兩個(gè)問(wèn)題還是先解釋清楚為好，這對(duì)正確獲取用例有很大幫助。這兩個(gè)問(wèn)題也是初學(xué)者最為困惑，也是最難掌握的。一個(gè)是各種用例類型之間的區(qū)別和用法，另一個(gè)是用例的粒度。
先說(shuō)說(shuō)用例類型的問(wèn)題。
用例類型，有的資料翻譯為版型，英文原文是stereotype。在Rose中默認(rèn)的類型有business usecase , business usecase realization和use case realization三種。相應(yīng)的，就是指
業(yè)務(wù)用例：
業(yè)務(wù)用例實(shí)現(xiàn)：
用例實(shí)現(xiàn)：
若不指定類型，則它就是通常意義上的use case ：
Rose中定義了上述默認(rèn)類型，但是也可以自定義用例類型。初學(xué)用UML建模的人常常在這些類型中迷失，搞不清楚這些類型是什么含義，什么時(shí)候該使用什么類型。簡(jiǎn)單說(shuō)，需求分析中的各個(gè)階段要描述和分析的目標(biāo)不同，為表達(dá)不同的視角和分析目標(biāo)，需要使用不同的用例類型。筆者的觀點(diǎn)是，用例類型的區(qū)分是為了形式上的統(tǒng)一，但用例類型既然可以自定義，它就是一個(gè)很靈活的用法，不必墨守成規(guī)，大可在工作中根據(jù)實(shí)際情況定義適合自己項(xiàng)目特點(diǎn)和軟件過(guò)程的用例類型。不過(guò)，默認(rèn)的用例類型已經(jīng)幾乎可以滿足需求分析的各個(gè)階段，自定義的必要性并不大，并且UML的意義就是使用統(tǒng)一的形式描述需求，因此最好使用默認(rèn)的類型。
說(shuō)到需求分析階段，那么需求分析都有些什么階段呢？一般來(lái)說(shuō)，需求分析要經(jīng)過(guò)業(yè)務(wù)建模，用例分析和系統(tǒng)建模三個(gè)階段才能完成需求工作，這三個(gè)階段分別做什么筆者會(huì)在以后的文章的詳細(xì)闡述，這里為了說(shuō)明用例類型的含義和使用，先簡(jiǎn)單介紹一下。
1、業(yè)務(wù)建模的目標(biāo)是通過(guò)用例模型的建立來(lái)描述用戶需求，需求規(guī)格說(shuō)明書(shū)通常在這個(gè)階段產(chǎn)生。這個(gè)階段通常使用業(yè)務(wù)用例和業(yè)務(wù)用例實(shí)現(xiàn)兩種類型；
2、用例分析是系統(tǒng)分析員采用OO方法來(lái)分析業(yè)務(wù)用例的過(guò)程，這個(gè)階段又稱為概念模型階段。這個(gè)階段通常使用無(wú)類型的用例。用例分析是一個(gè)過(guò)渡過(guò)程，但筆者認(rèn)為其非常重要，業(yè)務(wù)架構(gòu)通常在這個(gè)階段產(chǎn)生。
3、系統(tǒng)建模是將用戶的業(yè)務(wù)需求轉(zhuǎn)化為計(jì)算機(jī)實(shí)現(xiàn)的過(guò)程。這個(gè)階段通常使用無(wú)類型的用例和用例實(shí)現(xiàn)兩種類型。系統(tǒng)范圍，項(xiàng)目計(jì)劃，系統(tǒng)架構(gòu)通常在這個(gè)階段形成雛形（在系統(tǒng)分析階段確定）。
所謂business usecase，是用來(lái)描述用戶原始需求的，它的含義是站在用戶的角度，使用用戶的業(yè)務(wù)術(shù)語(yǔ)來(lái)描述用戶在其業(yè)務(wù)領(lǐng)域所做的事情。業(yè)務(wù)用例命名，描述都必須采用純業(yè)務(wù)語(yǔ)言，而不能出現(xiàn)計(jì)算機(jī)術(shù)語(yǔ)。因?yàn)闃I(yè)務(wù)模型是系統(tǒng)分析員與用戶討論需求，達(dá)到一致理解的基礎(chǔ)，必須使用用戶熟悉的，不會(huì)有歧義的專業(yè)術(shù)語(yǔ)以避免系統(tǒng)分析員與用戶對(duì)同一事件的理解誤差。business usecase realization是達(dá)到需求可追溯要求的一個(gè)連接點(diǎn)，是用戶在其業(yè)務(wù)場(chǎng)景中如何做這一件事的載體。
筆者自己在用例分析和系統(tǒng)建模階段不區(qū)分用例類型，都使用無(wú)類型的use case，但在這兩個(gè)階段，用例的含義還是有所差別的。用例分析階段，用例主要是從 業(yè)務(wù)模擬的概念上，從OO的視角來(lái)分解、組合業(yè)務(wù)用例，粗略的建立一個(gè)業(yè)務(wù)架構(gòu)。而在系統(tǒng)建模階段，用例主要是從計(jì)算機(jī)視角描述需求，規(guī)定開(kāi)發(fā)范圍，作為項(xiàng)目計(jì)劃的依據(jù)，為系統(tǒng)設(shè)計(jì)做準(zhǔn)備。usecase realization的含義可從business use case realization推知。
再來(lái)說(shuō)說(shuō)用例的粒度問(wèn)題。
粒度是令人迷惑的。比如在ATM取錢(qián)的場(chǎng)景中，取錢(qián)，讀卡，驗(yàn)證賬號(hào)，打印回執(zhí)單等都是可能的用例，顯然，取錢(qián)包含了后續(xù)的其它用例，取錢(qián)粒度更大一些，其它用例的粒度則要小一些。到底是一個(gè)大的用例合適還是分解成多個(gè)小用例合適呢？這個(gè)問(wèn)題并沒(méi)有一個(gè)標(biāo)準(zhǔn)的規(guī)則，筆者可以給大家分享的經(jīng)驗(yàn)是根據(jù)階段不同，使用不同的粒度。在業(yè)務(wù)建模階段，用例的粒度以每個(gè)用例能夠說(shuō)明一件完整的事情為宜。即一個(gè)用例可以描述一項(xiàng)完整的業(yè)務(wù)流程。這將有助于明確需求范圍。例如取錢(qián)，報(bào)裝電話，借書(shū)等表達(dá)完整業(yè)務(wù)的用例，而不要細(xì)到驗(yàn)證密碼，填寫(xiě)申請(qǐng)單，查找書(shū)目等業(yè)務(wù)中的一個(gè)步驟。在用例分析階段，用例的的粒度以每個(gè)用例能描述一個(gè)完整的事件流為宜。可理解為一個(gè)用例描述一項(xiàng)完整業(yè)務(wù)中的一個(gè)步驟。需要注意的是，這個(gè)階段需要采用OO方法，歸納，抽象業(yè)務(wù)用例中的概念模型。例如，寬帶業(yè)務(wù)需求中有申請(qǐng)報(bào)裝，申請(qǐng)遷移地址用例，在用例分析時(shí)，可歸納和分解為提供申請(qǐng)資料，受理業(yè)務(wù)，現(xiàn)場(chǎng)安裝等多個(gè)業(yè)務(wù)流程中都會(huì)使用的概念用例。在系統(tǒng)建模階段，用例視角是針對(duì)計(jì)算機(jī)的，因此用例的粒度以一個(gè)用例能夠描述操作者與計(jì)算機(jī)的一次完整交互為宜。例如，填寫(xiě)申請(qǐng)單，審核申請(qǐng)單，派發(fā)任務(wù)單等。可理解為一個(gè)操作界面，或一個(gè)頁(yè)面流。在RUP中，項(xiàng)目計(jì)劃要依據(jù)系統(tǒng)模型編寫(xiě)，因此另一個(gè)可參考的粒度是一個(gè)用例的開(kāi)發(fā)工作量在一周左右為宜。
上述的粒度劃分方法筆者是用相對(duì)比較具體化的一些依據(jù)來(lái)說(shuō)明。實(shí)際上，用例粒度的劃分依據(jù)（尤其是業(yè)務(wù)用例）最標(biāo)準(zhǔn)的方法是一個(gè)用例的粒度是否合適，是以該用例是否完成了參與者的某個(gè)目的為依據(jù)的。這個(gè)說(shuō)法比較籠統(tǒng)，也比較難以掌握。，舉個(gè)例子，某人去圖書(shū)館，查詢了書(shū)目，出示了借書(shū)證，圖書(shū)管理員查詢了該人以前借閱記錄以確保沒(méi)有未歸還的書(shū)，最后借到了書(shū)。從這段話中能得出多少用例呢？請(qǐng)記住一點(diǎn)，用例分析是以參與者為中心的，因此用例的粒度以能完成參與者目的為依據(jù)。這樣，實(shí)際上適合用例是：借書(shū)。只有一個(gè)，其它都只是完成這個(gè)目的過(guò)程--這里討論的用例指的是業(yè)務(wù)用例--這個(gè)例子是比較明顯的能夠區(qū)分出參與者完整目的的，在很多情況下可能并沒(méi)有那么明顯，甚至?xí)袥_突。讀者可以從自己實(shí)際的情況去找出這種例子。以后的文章中筆者會(huì)做一些討論。
但是上述的粒度選擇并不是一個(gè)標(biāo)準(zhǔn)，只是在大多數(shù)情況下這樣的粒度選擇是比較合適的。筆者的意思也不是告訴讀者上述哪一種是最好的，而只是把一些常用的比較，劃分方法告訴讀者，期望的是幫助讀者在工作實(shí)踐中自己總結(jié)出一套適合自己的方法來(lái)?，F(xiàn)實(shí)情況中，一個(gè)大型系統(tǒng)和一個(gè)很小的系統(tǒng)用例粒度選擇會(huì)有較大差異。這種差異是為了適應(yīng)不同的需求范圍。比如， 針對(duì)一個(gè)50人年的大型項(xiàng)目應(yīng)該選擇更大的粒度，如果用例粒度選擇過(guò)小，可能出現(xiàn)上百甚至幾百個(gè)業(yè)務(wù)用例，造成的后果是需求因?yàn)檫^(guò)于細(xì)碎和太多而無(wú)法控制，較少的用例有助于把握需求范圍，不容易遺漏。而針對(duì)一個(gè)10人月的小項(xiàng)目應(yīng)該選擇小一些的粒度，如果用例粒度選擇過(guò)大，可能只有幾個(gè)業(yè)務(wù)用例，造成的后果是需求因?yàn)檫^(guò)于模糊而容易忽略細(xì)節(jié)。一般來(lái)說(shuō)，一個(gè)系統(tǒng)的業(yè)務(wù)用例定義在多于10個(gè)，少于50個(gè)之間，否則就應(yīng)該考慮一下粒度選擇是否合適了。
不論粒度如何選擇，必須把握的原則是在同一個(gè)需求階段，所有用例的粒度應(yīng)該是同一個(gè)量級(jí)的。這應(yīng)該很好理解，在描述一棟建筑時(shí)，我們總是把高度，層數(shù)，單元數(shù)等合在一起介紹，而把下水道位置，插座數(shù)量等合在一起介紹。如果你這樣介紹一棟樓：這棟樓有10層，下水道在廚房東南角，預(yù)留了15個(gè)插座，共有5個(gè)單元，聽(tīng)眾一定會(huì)覺(jué)得云山霧罩，很難在腦子里形成一個(gè)清晰的影像。
如果對(duì)上面兩個(gè)問(wèn)題讀者還有疑惑，不用著急，在以后的文章中應(yīng)該會(huì)逐步加深理解。
預(yù)告：下一篇文章將通過(guò)一個(gè)例子，闡述獲取用例的一般方法和如何判斷用例的粒度是否合適。
Q&A
--------------------------------------------------------------------------
Q：由 pushboy 發(fā)布
在業(yè)務(wù)建模階段，用例的粒度以每個(gè)用例能夠說(shuō)明一件完整的事情為宜。即一個(gè)用例可以描述一項(xiàng)完整的業(yè)務(wù)流程。"
"在系統(tǒng)建模階段，用例視角是針對(duì)計(jì)算機(jī)的，因此用例的粒度以一個(gè)用例能夠描述操作者與計(jì)算機(jī)的一次完整交互為宜。"
那么，這樣一個(gè)場(chǎng)景 —— 用戶管理，有增刪改查
這里，是把 用戶管理 作為一個(gè)用例，還是把增刪改查分別作為用例呢？
他們每一個(gè)都是一個(gè)完整的業(yè)務(wù)流程和一次完整交互，而且也都是一個(gè)actor發(fā)起的動(dòng)作；怎么來(lái)確認(rèn)呢？
我們的前提是一個(gè)普通的比如說(shuō)財(cái)務(wù)系統(tǒng)，而不是一個(gè)用戶管理系統(tǒng)
A：這個(gè)問(wèn)題很好，用例的粒度總是在這樣左也可右也可之間難以決定。對(duì)這個(gè)問(wèn)題來(lái)說(shuō)，我的觀點(diǎn)是業(yè)務(wù)用例應(yīng)當(dāng)用“管理用戶”或“維護(hù)用戶”作為合適的粒度，而增，刪，改，查則在作為系統(tǒng)用例。我的理由是：
增刪改查不能做為一個(gè)完整的業(yè)務(wù)來(lái)理解。作為一個(gè)管理業(yè)務(wù)，數(shù)據(jù)只有先增，才會(huì)有改，才會(huì)有刪。增刪改查結(jié)合起來(lái)才能完成actor的管理目的，只刪或只增加都不是業(yè)務(wù)的全部。是否是一項(xiàng)完整業(yè)務(wù)，要看actor的目標(biāo)，而不是事情是否完整。這個(gè)例子中，actor的目標(biāo)是為了增加一個(gè)用戶嗎？是為了刪除一個(gè)用戶嗎？都不是，而是為了管理用戶，這個(gè)目標(biāo)包括了用戶這個(gè)實(shí)體的整個(gè)生命周期。
再討論深一些，如果業(yè)務(wù)要求對(duì)用戶除了增刪改查，還有別的要求，例如權(quán)限升級(jí)，用戶在組織機(jī)構(gòu)中復(fù)雜的關(guān)系變更，用戶與外部系統(tǒng)的交互....實(shí)際的情況可能會(huì)更多，那么，如果將每個(gè)都作為一個(gè)業(yè)務(wù)用例，很容易造成一個(gè)結(jié)果，這些原本與用戶這個(gè)實(shí)體緊密關(guān)聯(lián)，共同組成用戶實(shí)體生命周期的業(yè)務(wù)，被割裂成多個(gè)獨(dú)立的業(yè)務(wù)，因?yàn)槎x了多個(gè)用例（請(qǐng)參看本人第一篇中的用例特征第一條）。要知道，在RUP中，用例驅(qū)動(dòng)的含義是，一個(gè)用例就是一個(gè)分析單元，設(shè)計(jì)單元，開(kāi)發(fā)單元，測(cè)試單元甚至部署單元。相信讀者都知道，把緊密關(guān)聯(lián)的業(yè)務(wù)分成多個(gè)獨(dú)立部分去實(shí)施是高成本的，高風(fēng)險(xiǎn)的。
另外，為什么我要說(shuō)在系統(tǒng)用例階段要把增，刪，改，查又分出來(lái)呢？原因在于，系統(tǒng)用例的目的是為了將actor的業(yè)務(wù)用計(jì)算機(jī)模擬出來(lái)。我們都知道，一般情況下，增，刪，改，查對(duì)一個(gè)actor來(lái)說(shuō)是不會(huì)同時(shí)發(fā)生的，每次actor只會(huì)完成其中的一個(gè)行為。分開(kāi)來(lái)，有利于詳細(xì)分析模擬這一行為的細(xì)節(jié)而不至于混淆。另一方面，對(duì)WEB應(yīng)用來(lái)說(shuō)，針對(duì)數(shù)據(jù)的增，刪，改，查等，很容易形成所謂的“模板”，增加用戶用這個(gè)模板，增加其它基礎(chǔ)數(shù)據(jù)可能也用同一個(gè)模板，無(wú)非是操作的數(shù)據(jù)（實(shí)體）不同而已。因此，在很多情況下，這些模板是可以復(fù)用的。對(duì)這個(gè)例子來(lái)說(shuō)，在系統(tǒng)用例階段，我們可以用“管理用戶” include “增加用戶”來(lái)表示這個(gè)實(shí)現(xiàn)關(guān)系，同時(shí)，讓“增加用戶”，“增加X(jué)X數(shù)據(jù)”等等用例來(lái)繼承自一個(gè)抽象出來(lái)的“增加數(shù)據(jù)”用例，這樣，可復(fù)用的模板體現(xiàn)在“增加數(shù)據(jù)”用例上，而具體業(yè)務(wù)，則體現(xiàn)在“增加X(jué)X數(shù)據(jù)”上。實(shí)際上，這也是一種OO思想的體現(xiàn)。
只有一個(gè)查詢是比較特殊的，查詢一般不一定只局限于一個(gè)actor，也不一定局限這個(gè)用例，一般都是所謂的綜合查詢，是可能跨用例的。所以根據(jù)實(shí)際情況，查詢可以作為一個(gè)業(yè)務(wù)用例出現(xiàn)。
（3）--業(yè)務(wù)建模之涉眾
從這一篇開(kāi)始，筆者將借助一個(gè)虛擬的實(shí)例來(lái)闡述獲取用例的方法，以及如何判斷用例獲取是否完備，粒度選擇是否合適。事實(shí)上，在做這些工作時(shí)，我們正在進(jìn)行需求分析的第一個(gè)階段，即業(yè)務(wù)建模階段。借助這個(gè)例子，筆者同樣會(huì)闡述業(yè)務(wù)建模到底應(yīng)該做什么，做到什么地步才能說(shuō)明業(yè)務(wù)需求已經(jīng)完整，可以稱為一份完整的需求規(guī)格說(shuō)明書(shū)了。
一般來(lái)說(shuō)，只有當(dāng)以下工作都完成，才能說(shuō)業(yè)務(wù)模型建立完成，它們是：
- 發(fā)現(xiàn)和定義涉眾
- 畫(huà)定業(yè)務(wù)邊界
- 獲取用例
- 繪制用例場(chǎng)景圖
- 繪制業(yè)務(wù)實(shí)體模型（領(lǐng)域模型）
- 編制詞匯表
下面筆者開(kāi)始就一個(gè)事例來(lái)說(shuō)明如何完成這些工作，這只是一個(gè)虛擬的事例，它的合理性和真實(shí)性請(qǐng)讀者不必追究。
現(xiàn)在我們接到一個(gè)項(xiàng)目，是一個(gè)網(wǎng)上圖書(shū)借閱系統(tǒng)，初步跟客戶接觸，網(wǎng)上圖書(shū)館的業(yè)務(wù)負(fù)責(zé)人這樣告訴我：
我們?cè)臼且粋€(gè)傳統(tǒng)的圖書(shū)館，傳統(tǒng)的借書(shū)方式要求讀者親自來(lái)到圖書(shū)館，這顯得非常不方便，而且隨著藏書(shū)的增加和讀者群的增長(zhǎng)，尤其而且大量的讀者到圖書(shū)館，使得圖書(shū)館的場(chǎng)地不足，工作人員也不夠了。所以想到借助網(wǎng)絡(luò)，讓讀者通過(guò)網(wǎng)絡(luò)借/還書(shū)，這樣可以省掉大量的場(chǎng)地維護(hù)和工作人員成本支出，同時(shí)計(jì)算機(jī)可以方便的檢索目錄，讓讀者可以足不出戶借到需要的書(shū)。為了把書(shū)送到借閱人手里，我們已經(jīng)聯(lián)系了A特快專遞公司和B城市物流公司，初步達(dá)成協(xié)議，由他們往返借閱人和圖書(shū)館之間把圖書(shū)送出和收回。讀者在網(wǎng)上出示和驗(yàn)證借書(shū)卡，找到他們需要的書(shū)，提交申請(qǐng)，圖書(shū)管理員確認(rèn)后，就會(huì)通知物流公司來(lái)取書(shū)，當(dāng)讀者拿到書(shū)之后，物流公司需要把讀者的簽單拿回來(lái)以證明讀者已經(jīng)拿到了書(shū)。當(dāng)然這個(gè)過(guò)程中，讀者是需要付費(fèi)的。還書(shū)也是基本同樣的過(guò)程。
好了，通過(guò)這番談話，我們已經(jīng)基本上了解了系統(tǒng)目標(biāo)。一些著急的系統(tǒng)分析員已經(jīng)準(zhǔn)備開(kāi)始著手詢問(wèn)借書(shū)的流程，借閱人的資格認(rèn)證問(wèn)題了，甚至有的人已經(jīng)憑借多年的開(kāi)發(fā)經(jīng)驗(yàn)在腦海中繪制出了一幅網(wǎng)頁(yè)，考慮如何實(shí)現(xiàn)這個(gè)系統(tǒng)了。
筆者要說(shuō)的是，請(qǐng)您千萬(wàn)不要著急往下走。因?yàn)槲覀兊玫降膬H僅是一個(gè)由非計(jì)算機(jī)專業(yè)人員規(guī)劃出的很粗略的構(gòu)想，其可行性如何都尚未得到證實(shí)，在這樣的基礎(chǔ)下就開(kāi)始細(xì)化，將來(lái)出現(xiàn)反復(fù)甚至失敗的危險(xiǎn)是很大的。
在了解了系統(tǒng)目標(biāo)以后，系統(tǒng)分析員最先要做的事情不是去了解業(yè)務(wù)的細(xì)節(jié)，而是去發(fā)現(xiàn)與這個(gè)目標(biāo)相關(guān)的人和物。英文把這種人和物稱為Stakeholder，在Rose中，這類模型的類型被定義為Business Actor 。有的資料翻譯為干系人，筆者則更喜歡涉眾這種翻譯方法。這就談到了業(yè)務(wù)建模的第一步：發(fā)現(xiàn)和定義涉眾。
什么是涉眾？涉眾是與要建設(shè)的業(yè)務(wù)系統(tǒng)相關(guān)的一切人和事。首先要明確的一點(diǎn)是，涉眾不等于用戶，通常意思的user是指系統(tǒng)的使用者，這僅是涉眾中的一部分。如何理解與業(yè)務(wù)系統(tǒng)相關(guān)的一切人和事？筆者可以給大家分享的經(jīng)驗(yàn)是通過(guò)以下大類去尋找：
業(yè)主是系統(tǒng)建設(shè)的出資方，投資者，它不一定是業(yè)務(wù)方。比如可以假設(shè)這個(gè)圖書(shū)館的網(wǎng)絡(luò)化建設(shè)是由一家國(guó)際風(fēng)險(xiǎn)投資機(jī)構(gòu)投資的，它本身并不管理圖書(shū)館，它只是從資本上擁有這個(gè)系統(tǒng)并從借書(shū)收入中獲得回報(bào)。
了解業(yè)主的期望是必須和重要的，業(yè)主的錢(qián)是這個(gè)項(xiàng)目存在的原因。若系統(tǒng)建設(shè)不符合業(yè)主的期望，撤回投資，那么再好的愿望也是空的。
一般來(lái)說(shuō)，業(yè)主關(guān)心的是建設(shè)成本，建設(shè)周期以及建成后的效益。雖然這些看上去與系統(tǒng)需求沒(méi)什么大的關(guān)系，但是，建設(shè)成本、建設(shè)周期將直接影響到你可以采用的技術(shù)，可以選用的軟件架構(gòu)，可以承受的系統(tǒng)范圍。一個(gè)不能達(dá)到業(yè)主成本和周期要求的項(xiàng)目是一個(gè)失敗的項(xiàng)目，同樣，一個(gè)達(dá)到了業(yè)主成本和周期要求，但卻沒(méi)有賺到錢(qián)的項(xiàng)目仍然是一個(gè)失敗的項(xiàng)目。
業(yè)務(wù)提出者是業(yè)務(wù)規(guī)則的制定者，一般是指業(yè)務(wù)方的高層人物，比如CEO，高級(jí)經(jīng)理等。他們制定業(yè)務(wù)規(guī)則，圈定業(yè)務(wù)范圍，規(guī)劃業(yè)務(wù)目標(biāo)。他們的期望十分十分的重要，實(shí)際上，系統(tǒng)建設(shè)正是業(yè)務(wù)提出者經(jīng)營(yíng)和管理意志的體現(xiàn)。他們的期望一般比較原則化和粗略化，但是卻不能違反和誤解，否則系統(tǒng)將有徹底失敗的危險(xiǎn)。業(yè)務(wù)提出者一般最關(guān)心系統(tǒng)建設(shè)能夠帶來(lái)的社會(huì)影響，效率改進(jìn)和成本節(jié)約。換句話說(shuō)，他們只關(guān)心統(tǒng)計(jì)意義而不關(guān)心具體細(xì)節(jié)，但是，如果建設(shè)完成的系統(tǒng)不能給出他們滿意的統(tǒng)計(jì)結(jié)果，這必定是一個(gè)失敗的項(xiàng)目。在系統(tǒng)建設(shè)過(guò)程的溝通中，他們的意志一般是極少妥協(xié)的，系統(tǒng)分析員不必太費(fèi)心去試圖說(shuō)服他們接受一個(gè)與他們意志相左的方案。實(shí)際上，由于他們的期望是非常原則化和粗略的，因此留給了系統(tǒng)建設(shè)者很大的調(diào)整空間和規(guī)避風(fēng)險(xiǎn)的余地。
業(yè)務(wù)管理者是指實(shí)際管理和監(jiān)督業(yè)務(wù)執(zhí)行的人員，一般是指中層干部，起到將業(yè)務(wù)提出者的意志付諸實(shí)施，并監(jiān)督底層員工工作的作用。他們的期望也很重要，一般也是系統(tǒng)的主要用戶之一。他們關(guān)心系統(tǒng)將如何實(shí)現(xiàn)他們的管理職能，如何能方便的得知業(yè)務(wù)執(zhí)行的結(jié)果，他們?nèi)绾螌⒅噶钕逻_(dá)，以及如何得到反饋。業(yè)務(wù)管理者的期望相對(duì)比較細(xì)節(jié)，是需求調(diào)研過(guò)程中最重要的信息來(lái)源。系統(tǒng)建設(shè)的好壞與業(yè)務(wù)管理者的關(guān)系最多，也是系統(tǒng)分析員最需要下功夫的。系統(tǒng)分析員必須要把業(yè)務(wù)管理者的思路，想法弄清楚，業(yè)務(wù)建模的結(jié)果也必須與業(yè)務(wù)管理者達(dá)成一致。在系統(tǒng)建設(shè)過(guò)程中，業(yè)務(wù)管理者的期望可以有所妥協(xié)，一個(gè)經(jīng)驗(yàn)豐富的系統(tǒng)分析員可以給他們灌輸合理的管理方式，提供可替代的管理方法，以規(guī)避導(dǎo)致高技術(shù)風(fēng)險(xiǎn)或高成本風(fēng)險(xiǎn)的不合理要求。
業(yè)務(wù)執(zhí)行者是指底層的操作人員，是與將來(lái)的計(jì)算機(jī)直接交互最多的人員。他們最關(guān)心的內(nèi)容是系統(tǒng)會(huì)給他們帶來(lái)什么樣的方便，會(huì)怎樣的改變他們的工作模式。他們的需求最細(xì)節(jié)，系統(tǒng)的可用性，友好性，運(yùn)行效率與他們關(guān)系最多。系統(tǒng)界面風(fēng)格，操作方式，數(shù)據(jù)展現(xiàn)方式，錄入方式，業(yè)務(wù)細(xì)節(jié)都需要從他們這里了解。他們將成為系統(tǒng)是否成功的試金石。Look and Feel ，表單細(xì)節(jié)等是系統(tǒng)分析員與他們調(diào)研時(shí)需要多下功夫的地方。這類人員的期望靈活性最大，也最容易說(shuō)服和妥協(xié)。同時(shí)，他們的期望又往往是不統(tǒng)一的，各種古怪的要求都有。他們的期望必須服從業(yè)務(wù)管理者的期望，因此，系統(tǒng)分析員需要從他們的各種期望中找出普遍意義，解決大部分人的問(wèn)題，必要時(shí)可以依靠業(yè)務(wù)管理者來(lái)影響和消除不合理的期望。
第三方是指與這項(xiàng)業(yè)務(wù)而關(guān)聯(lián)的，但并非業(yè)務(wù)方的其他人或事。比如在這個(gè)事例中，借閱人借書(shū)時(shí)需要交費(fèi)，若交費(fèi)是通過(guò)網(wǎng)上銀行支付的，則網(wǎng)上銀行就成為了網(wǎng)上借書(shū)系統(tǒng)的一個(gè)涉眾。
第三方的期望對(duì)系統(tǒng)來(lái)說(shuō)不起決定性意義，但會(huì)起到限制作用。最終在系統(tǒng)中，這種期望將體現(xiàn)為標(biāo)準(zhǔn)、協(xié)議和接口。
另一種典型的第三方是項(xiàng)目監(jiān)理，系統(tǒng)分析員也必須弄清楚監(jiān)理的期望。
承建方，也就是你的老板。老板的期望也是非常重要的。老板關(guān)心的是通過(guò)這個(gè)項(xiàng)目，能否賺到錢(qián)，是否能積累核心競(jìng)爭(zhēng)力，是否能樹(shù)立品牌，是否能開(kāi)拓市場(chǎng)。老板的期望將很大的影響一個(gè)項(xiàng)目的運(yùn)作模式，技術(shù)選擇，架構(gòu)建立和范圍確定。比如，老板試圖通過(guò)這個(gè)項(xiàng)目打開(kāi)一個(gè)市場(chǎng)，樹(shù)立起品牌，不惜成本，那么，系統(tǒng)分析員需要盡可能的深入挖掘潛在業(yè)務(wù)，建立擴(kuò)展能力很強(qiáng)，但成本較高的業(yè)務(wù)架構(gòu)，選擇那些較新，但風(fēng)險(xiǎn)較高的技術(shù)。反之，如果老板只想通過(guò)這個(gè)項(xiàng)目賺更多的錢(qián)，系統(tǒng)分析員就需要引導(dǎo)業(yè)務(wù)方壓縮業(yè)務(wù)范圍，選擇風(fēng)險(xiǎn)小的成熟技術(shù)，甚至不用考慮業(yè)務(wù)架構(gòu)，考慮系統(tǒng)的可維護(hù)性，而較少考慮系統(tǒng)擴(kuò)展能力。
一個(gè)業(yè)主滿意但老板不滿意的項(xiàng)目，恐怕也不是一個(gè)成功的項(xiàng)目吧？
相關(guān)的法律法規(guī)是一個(gè)很重要的，但也最容易被忽視的涉眾。這里的法律法規(guī)，既指國(guó)家和地方法律法規(guī)，也指行業(yè)規(guī)范和標(biāo)準(zhǔn)。例如，這個(gè)借閱系統(tǒng)中要建立借閱人檔案，就必須保障借閱人的隱私權(quán)；要與網(wǎng)上銀行交易，必須遵守信息安全法等。若遇到業(yè)務(wù)方提出違反了法律法規(guī)的要求時(shí)，系統(tǒng)分析員要能給他們指出來(lái)，說(shuō)服無(wú)果的情況下要在合同里留下免責(zé)條款。否則一不小心惹上官司可是件郁悶的事。
另外，有時(shí)必須得遵守一些行業(yè)規(guī)范。例如本事例是網(wǎng)上借閱，網(wǎng)絡(luò)需求決定了需要遵守HTML規(guī)范，才能保證借閱者能正常瀏覽網(wǎng)頁(yè)。
用戶是一個(gè)抽象的概念，是指預(yù)期的系統(tǒng)使用者。用戶可能包括上述的任何一種涉眾。用戶涉眾模型建立的意義是，每一個(gè)用戶將來(lái)都可能是系統(tǒng)中的一個(gè)角色，是實(shí)實(shí)在在參與系統(tǒng)的，需要編程實(shí)現(xiàn)。而上述的其它涉眾，則有可能只是在需求階段有用，最終并不與系統(tǒng)發(fā)生交互。在建模過(guò)程中，概念模型的建立和系統(tǒng)模型的建立都只從用戶開(kāi)始分析，而不再理會(huì)其它的涉眾。在Rose中建模的時(shí)候，也只需要建立用戶的模型，其它涉眾則只需要體現(xiàn)在文檔中即可。
這篇文章只能到此為止了，否則太長(zhǎng)的話，讀者該不耐煩了。只好在此分節(jié)。下一節(jié)筆者將一步步將涉眾的期望導(dǎo)出，并得到需求范圍的大致輪廓。
（4）--業(yè)務(wù)建模一般步驟和方法
使用OO方法建立商業(yè)模型必須先定義涉眾。商業(yè)系統(tǒng)無(wú)論多復(fù)雜，無(wú)論什么行業(yè)，其本質(zhì)無(wú)非是人，事，物，規(guī)則。人是一切的中心，人做事，做事產(chǎn)生物，規(guī)則限制人事物。人驅(qū)動(dòng)系統(tǒng)，事體現(xiàn)過(guò)程，物記錄結(jié)果，規(guī)則則是控制。無(wú)論OO也好，UML也好，復(fù)雜的表面下其實(shí)只是一個(gè)簡(jiǎn)單的規(guī)則，系統(tǒng)分析員弄明白有什么人，什么人做什么事，什么事產(chǎn)生什么物，中間有什么規(guī)則，再把人，事，物之間的關(guān)系定義出來(lái)，商業(yè)建模也就基本完成了。
本篇開(kāi)始之前先扯點(diǎn)閑話，商業(yè)應(yīng)用系統(tǒng)開(kāi)發(fā)經(jīng)歷了三個(gè)階段：
第一個(gè)階段以計(jì)算為中心，分析設(shè)計(jì)圍繞程序的運(yùn)行效率，算法優(yōu)劣，存貯優(yōu)化來(lái)進(jìn)行。90年代的大學(xué)課程講的都是這些。
第二階段以數(shù)據(jù)為中心，分析設(shè)計(jì)圍繞數(shù)據(jù)流進(jìn)行，以數(shù)據(jù)流程來(lái)模擬業(yè)務(wù)流程。這也就是所謂的面向過(guò)程的分析模式。
第三階段以人為中心，分析設(shè)計(jì)圍繞人的業(yè)務(wù)需求，使用要求，感受要求進(jìn)行。這也就是現(xiàn)在的面象對(duì)象分析模式。
使用OO方法建立商業(yè)模型必須先定義涉眾。商業(yè)系統(tǒng)無(wú)論多復(fù)雜，無(wú)論什么行業(yè)，其本質(zhì)無(wú)非是人，事，物，規(guī)則。人是一切的中心，人做事，做事產(chǎn)生物，規(guī)則限制人事物。人驅(qū)動(dòng)系統(tǒng)，事體現(xiàn)過(guò)程，物記錄結(jié)果，規(guī)則則是控制。無(wú)論OO也好，UML也好，復(fù)雜的表面下其實(shí)只是一個(gè)簡(jiǎn)單的規(guī)則，系統(tǒng)分析員弄明白有什么人，什么人做什么事，什么事產(chǎn)生什么物，中間有什么規(guī)則，再把人，事，物之間的關(guān)系定義出來(lái)，商業(yè)建模也就基本完成了。這時(shí)候可以說(shuō)，系統(tǒng)分析員已經(jīng)完全了解了用戶需求，可以進(jìn)入系統(tǒng)建模階段了。
書(shū)歸正傳，上篇筆者歸納了一些典型的涉眾類型及他們的普遍期望。接下來(lái)，就是要將他們這些期望定義出來(lái)。這個(gè)過(guò)程，就是業(yè)務(wù)用例獲取的過(guò)程。筆者可以跟大家分享的經(jīng)驗(yàn)是通過(guò)以下步驟進(jìn)行，這些步驟并非唯一正確，對(duì)于經(jīng)驗(yàn)不多的系統(tǒng)分析員來(lái)說(shuō)，這些步驟很有指導(dǎo)意義。
筆者做了一個(gè)建模實(shí)例，有需要有讀者請(qǐng)到筆者的BLOG資源中心下載，實(shí)例以上一篇所述網(wǎng)上圖書(shū)館需求為藍(lán)本建立了業(yè)務(wù)用例模型，之后的概念模型、系統(tǒng)模型則抽取了其中的借閱過(guò)程作為例子。不記得了可以后頭找找。
建模第一步，從涉眾中找出用戶。并定義這些用戶之間的關(guān)系。在ROSE中，應(yīng)該使用business actor 類型。參考上一篇的需求描述
第二步，找出每個(gè)用戶要做的事，即業(yè)務(wù)用例，在ROSE中應(yīng)使用Business use case類型。請(qǐng)參考《用例的類型與粒度》一文以幫助確定用例的粒度。筆者強(qiáng)烈建議為每一個(gè)business actor繪制一個(gè)業(yè)務(wù)用例圖，這能很好的體現(xiàn)以人為中心的分析模式，并且不容易漏掉business actor需要做的事。至于以參與者為中心的視圖容易漏掉某個(gè)業(yè)務(wù)用例的參與者的擔(dān)心，可以在第四步中得到消除。下載實(shí)例
第三步，利用業(yè)務(wù)場(chǎng)景圖幫助分析業(yè)務(wù)流程，在ROSE中，這個(gè)階段最好使用活動(dòng)圖Activity diagram。在這個(gè)階段，業(yè)務(wù)場(chǎng)景圖非常重要，在繪制過(guò)程中，系統(tǒng)分析員必須采用第一步中定義的用戶名字作為泳道名，使用第二步中定義的業(yè)務(wù)用例名作為活動(dòng)名來(lái)繪制。必須這么做的原因是，如果你無(wú)法把利用已經(jīng)定義出來(lái)的 business actor 和 business use case完備的描繪業(yè)務(wù)流程，那么一定是前面的定義出問(wèn)題了，你需要回頭審視是否 business actor 和 business use case定義不完善或錯(cuò)誤。如果不是所有的business actor 和 business use case 都被用到，要么應(yīng)該檢查業(yè)務(wù)流程調(diào)研時(shí)漏了什么，要么應(yīng)該檢查是否定義了一些無(wú)用的business actor 和 business use case 。同時(shí)，繪制業(yè)務(wù)場(chǎng)景圖也非常有助于選擇合適的用例粒度并保持所有的用例都是同一粒度。
第四步，繪制用例場(chǎng)景圖。與業(yè)務(wù)場(chǎng)景圖不同的是，用例場(chǎng)景圖只針對(duì)一個(gè)用例繪制該用例的執(zhí)行過(guò)程。筆者仍然強(qiáng)烈推薦使用activity diagram。在用例場(chǎng)景圖的繪制中，必須使用第一步中定義的業(yè)務(wù)用戶作為泳道。必須這么做的原因是，它能幫助你發(fā)現(xiàn)在定義業(yè)務(wù)用例圖時(shí)的錯(cuò)誤，比如是否漏掉了某個(gè)業(yè)務(wù)用例的潛在使用者。不是每個(gè)業(yè)務(wù)用例都需要繪制場(chǎng)景圖，只有兩三個(gè)步驟的業(yè)務(wù)用例是不必一定繪制業(yè)務(wù)用例圖的，但仍然需要在業(yè)務(wù)用例規(guī)約文檔中寫(xiě)明。
第五步，從第三步或第四步中繪制的活動(dòng)圖中找到每一步活動(dòng)將使用到的或產(chǎn)生的結(jié)果。這是找到物的過(guò)程。找到后，應(yīng)當(dāng)建立這些物之間的關(guān)系。在ROSE中，這稱為業(yè)務(wù)實(shí)體模型。應(yīng)該使用business entity 類型。
第六步，在上述過(guò)程中，隨時(shí)補(bǔ)充詞匯表Glossary。將此過(guò)程中的所有業(yè)務(wù)詞匯，專業(yè)詞匯等一切在建模過(guò)程中使用到的需要解釋的名詞。這份文檔將成為模型建立人與讀者就模型達(dá)成一致理解的重要保證。
第七步，根據(jù)上一篇中提到的業(yè)主，老板等涉眾的期望審視建立好的模型，確定業(yè)務(wù)范圍，決定哪些業(yè)務(wù)用例在系統(tǒng)建設(shè)范圍內(nèi)。那些不打算納入建設(shè)范圍內(nèi)的業(yè)務(wù)用例有兩種情況，一種是該業(yè)務(wù)用例是被調(diào)用一方，那么應(yīng)該把它改為 boundary 類型，意味著將來(lái)它是一個(gè)外部接口。另一種是該業(yè)務(wù)用例主動(dòng)調(diào)用系統(tǒng)內(nèi)業(yè)務(wù)用例，那么應(yīng)該將它改為business actor類型。與普通business actor不同的是，由業(yè)務(wù)用例轉(zhuǎn)換而成的business actor不是人，而通常是一個(gè)外部系統(tǒng)進(jìn)程，因此應(yīng)該在被調(diào)用的系統(tǒng)內(nèi)業(yè)務(wù)用例與它之間增加一個(gè)boundary元素，意味著我們的系統(tǒng)將為這樣一個(gè)外部進(jìn)程提供一個(gè)接口。嚴(yán)格來(lái)說(shuō)，那些需要納入建設(shè)范圍的business use case 應(yīng)當(dāng)對(duì)應(yīng)的生成一個(gè) business use case realization， 以后的設(shè)計(jì)工作將歸納到這些實(shí)現(xiàn)用例中。但筆者覺(jué)得這一步并非很關(guān)鍵的，實(shí)際中本人也經(jīng)常省略這一步，而將協(xié)作圖，象活動(dòng)圖，類交互圖等直接在business usecase下說(shuō)明。不過(guò)本實(shí)例中筆者還是按照正規(guī)方法來(lái)建模的。
需要說(shuō)明的是，上述的步驟并非一次性完成的，在每一個(gè)步驟中都可能導(dǎo)致對(duì)以前步驟的調(diào)整。即使建模已經(jīng)完成，當(dāng)遇到變化或發(fā)現(xiàn)新問(wèn)題時(shí)，上述步驟應(yīng)當(dāng)從頭到尾再執(zhí)行一次。這也是RUP倡導(dǎo)的迭代開(kāi)發(fā)模式。
經(jīng)過(guò)以上的步驟，我們已經(jīng)建立了一個(gè)完整的業(yè)務(wù)模型。但這決不是建模工作的全部，以上過(guò)程只說(shuō)明了建立一個(gè)完整業(yè)務(wù)模型的過(guò)程，不能說(shuō)這樣就建立了一個(gè)很好的業(yè)務(wù)模型。因?yàn)樯鲜龅倪^(guò)程中并沒(méi)有提及業(yè)務(wù)分析過(guò)程。分析過(guò)程全憑系統(tǒng)分析員的經(jīng)驗(yàn)，對(duì)OO的理解和對(duì)行業(yè)業(yè)務(wù)的把握能力，對(duì)原始業(yè)務(wù)模型進(jìn)行歸納，整理，抽象，重構(gòu)，以建立一個(gè)更高效，合理，擴(kuò)展性更強(qiáng)的模型。這個(gè)過(guò)程無(wú)法以步驟說(shuō)明。或許以后筆者會(huì)專門(mén)針對(duì)模型分析寫(xiě)點(diǎn)東西。另外除了模型，還至少需要寫(xiě)業(yè)務(wù)架構(gòu)文檔、用例規(guī)約和補(bǔ)充用例規(guī)約三種文檔。因?yàn)槟Ｐ碗m然可以較好的體現(xiàn)業(yè)務(wù)架構(gòu)，但很不好表達(dá)業(yè)務(wù)規(guī)則和非業(yè)務(wù)需求，這些需要在文檔中說(shuō)明。例如用例的前置條件和后置條件就是一種業(yè)務(wù)規(guī)則。讀者可以在RUP文檔中找到這些文檔的模板。
預(yù)告：下一篇筆者將講述如何根據(jù)業(yè)務(wù)模型建立系統(tǒng)概念模型。這里先說(shuō)一點(diǎn)，系統(tǒng)概念模型建立最主要依據(jù)的是第三步、第四步、第五步建立的業(yè)務(wù)/用例場(chǎng)景和業(yè)務(wù)實(shí)體模型。這也突顯了場(chǎng)景和實(shí)體模型的重要程度。
|
