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