OO系統(tǒng)分析員之路--用例分析系列（1）

--什么是用例

我發(fā)現(xiàn)，在OO和UML幾乎一統(tǒng)天下的今天，仍有很多系統(tǒng)分析員對OO和UML一知半解，甚至包括很多已經(jīng)使用了很久UML的系統(tǒng)分析員。

于是打算寫一個系列文章，將多年來的工作經(jīng)驗(yàn)做一個總結(jié)。對初學(xué)者起個啟蒙作用，也希望拋磚引喻，與各路大蝦共同探討，共同提高。這個系列文章將以我對OO和系統(tǒng)分析的理解為主，從UML基礎(chǔ)開始，闡述面向?qū)ο蟮男枨蠓治龇椒ǎ^程，并以RUP為例，闡述如何將OO過程與軟件過程有機(jī)結(jié)合在一起，做一個真正OO應(yīng)用。

好了，今天是第一篇。想得很遠(yuǎn)，真希望我能堅(jiān)持下去，呵呵。

用例是什么？其原始英文是usecase，直譯過來就成了用例。這也是一個比較貼切的叫法了，從字面的直接理解就是使用的例子。另一種比較流行的定義是用例就是與使用者(actor)交互的，并且給使用者提供可觀測的有意義的結(jié)果的一系列活動的集合。

這個定義還是比較費(fèi)解的，筆者在眾多應(yīng)聘者中發(fā)現(xiàn)很多使用用例來做需求的系統(tǒng)分析員，有的已經(jīng)使用了兩年以上，但仍不能把握用例的本質(zhì)，雖然他們號稱精通UML。

最具普遍意義的理解錯誤是認(rèn)為用例就是功能的劃分和描述，認(rèn)為一個用例就是一個功能點(diǎn)。在這種理解下，用例變成了僅僅是較早前需求中功能框圖的翻版，很多人用用例來劃分子系統(tǒng)，功能模塊和功能點(diǎn)。如果這樣，用例根本沒有存在的必要。有意思的是，造成這種理解錯誤的相當(dāng)一部分原因卻是因?yàn)閷?/span>OO思想的理解不夠深入，本質(zhì)上說，把用例當(dāng)成功能點(diǎn)的系統(tǒng)分析員腦子里還是面向過程的那一套思想，雖然他們在使用OO的工具，OO的語言，號稱在做面向?qū)ο蟮拈_發(fā)，但過程的影子還沒有從他們腦子里徹底抹去。

如果用例不是功能的話，它是什么呢？從定義上說，能給使用者提供一個執(zhí)行結(jié)果的活動，不就是功能嗎？我的回答是：錯！功能是計算機(jī)術(shù)語，它是用來描述計算機(jī)的，而非定義需求的術(shù)語。功能實(shí)際描述的是輸入-->計算-->輸出。這讓你想到了什么？DFD圖？這可是典型的面向過程分析模式。因此我說把用例當(dāng)做功能點(diǎn)的分析員實(shí)際在做面向過程的分析。

而用例不是計算機(jī)術(shù)語，UML除了在計算機(jī)行業(yè)中應(yīng)用，它也經(jīng)常被應(yīng)用在其它行業(yè)中。用例是一種需求方法學(xué)，雖然軟件危機(jī)和OO的發(fā)展促成了它的誕生并被完美的融合進(jìn)了OO體系，形成了 UML，但它實(shí)際上并不是軟件行業(yè)的專用品。如果非要從功能的角度解釋，那么用例可以解釋為一系列完成一個特定目標(biāo)的“功能”的組合，針對不同的應(yīng)用場景，這些“功能”體現(xiàn)不同的組合方式。實(shí)際上，把用例解釋為某個參與者(actor)要做的一件事可能更為合適。

這樣的一件事有以下幾個特征：

一、這件事是相對獨(dú)立的。這意味著它不需要與其它用例交互而獨(dú)自完成參與者的目的。也就是說這件事從“功能”上說是完備的。讀者可能會想到，用例之間不是也有關(guān)聯(lián)關(guān)系嗎？比如擴(kuò)展，比如實(shí)現(xiàn)，比如繼承，它看上去并不是獨(dú)立的嘛。關(guān)于這個問題，筆者會在后續(xù)的文章里詳細(xì)說明。這里稍微解釋一下，用例之間的關(guān)系是分析過程的產(chǎn)物，而且這種關(guān)系一般的產(chǎn)生在概念層用例階段和系統(tǒng)層用例階段。對于業(yè)務(wù)用例，這個特征是很明顯的。

二、這件事的執(zhí)行結(jié)果對參與者來說是可觀測的和有意義的。例如，系統(tǒng)會監(jiān)控參與者在系統(tǒng)里的操作，并在參與者刪除數(shù)據(jù)之前備份。雖然它是系統(tǒng)的一個必需組成部分，但它在需求階段卻不應(yīng)該作為用例出現(xiàn)。因?yàn)檫@是一個后臺進(jìn)程，對參與者來說是不可觀測的，它應(yīng)該在系統(tǒng)用例分析階段定義。又比如說，登錄系統(tǒng)是一個有效的用例，但輸入密碼卻不是。這是因?yàn)榈卿浵到y(tǒng)對參與者是有意義的，這樣他可以獲得身份認(rèn)證和授權(quán)，但輸入密碼卻是沒有意義的，輸入完了呢？有什么結(jié)果嗎？

三、這件事必須由一個參與者發(fā)起。不存在沒有參與者的用例，用例不應(yīng)該自動啟動，也不應(yīng)該主動啟動另一個用例。用例總是由一個參與者發(fā)起，并且滿足特征二。例如從ATM 取錢是一個有效的用例，ATM吐鈔卻不是。因?yàn)?/span>ATM是不會無緣無故吐鈔的，否則，我從此天天守在ATM旁，生活無憂矣。

四、這件事必然是以動賓短語形式出現(xiàn)的。即，這件事必須有一個動作和動作的受體。例如，喝水是一個有效的用例，而“喝”和“水”卻不是。雖然生活常識告訴我們，在沒有水的情況下人是不會做出喝這個動作的，水也必然是喝進(jìn)去的，而不是滑進(jìn)去的，但是筆者所見的很多用例中類似“計算”，“統(tǒng)計”，“報表”，“輸出”，“錄入”之類的并不在少數(shù)。

除去以上的特征，筆者覺得用例的含義還要更深些。首先，用例的背后是一種需求方法論。其核心是以參與者為中心（區(qū)別于以計算機(jī)系統(tǒng)為中心），從參與者的角度來描述他要做的日常工作（區(qū)別于以業(yè)務(wù)流程描述的方式），并分析這些日常工作之間是如何交互的（區(qū)別于數(shù)據(jù)流的描述方式）。換句話說，用例分析的首要目標(biāo)不是要弄清楚某項(xiàng)業(yè)務(wù)是如何一步一步完成的，而是要弄清楚有多少參與者？每個參與者都做什么？業(yè)務(wù)流程分析則是后續(xù)的工作了。

其次，用例簡直就是為OO而生的，其思想完美的符合OO。用例分析方法試圖找到問題領(lǐng)域內(nèi)所有相對獨(dú)立的參與者和事件，并把業(yè)務(wù)流程當(dāng)成是這些參與者和事件之間的交互結(jié)果（在UML用活動圖或序列圖來描述）。因此，用例方法被吸納到OO之后，UML得以以完備的形式出現(xiàn)，用例成為了真正的OO核心。在 RUP里，這種核心作用被發(fā)揮到極致，產(chǎn)生了用例驅(qū)動（usecase driven）的軟件過程方法，在RUP里，軟件生產(chǎn)的所有過程和產(chǎn)物都是圍繞著用例形成的。

可以說，用例分析是OO的第一步。如果用例分析本身出了問題，對業(yè)務(wù)架構(gòu)，軟件架構(gòu)的影響是很大的，將大大削弱OO的優(yōu)勢--復(fù)用、擴(kuò)展。筆者認(rèn)為軟件復(fù)用可以分為三個層次，最低層次的復(fù)用是代碼級復(fù)用，這是由OO語言特性提供支持的，例如繼承，聚合，多態(tài)；較高層次的復(fù)用是組件級復(fù)用，這是由設(shè)計模式提供支持的，例如Factory模式, Builder模式；最高層次的復(fù)用則是服務(wù)級復(fù)用，這在很大程度上是由應(yīng)用服務(wù)器和通訊協(xié)議來提供支持的，例如最近炒得火熱的SOA（面向服務(wù)的應(yīng)用）架構(gòu)。用例分析的好壞也許對代碼級和組件級的復(fù)用影響不太大，但對服務(wù)級的復(fù)用影響卻是巨大的。筆者認(rèn)為服務(wù)級復(fù)用是OO的最高境界，而結(jié)構(gòu)良好的用例分析則是達(dá)到這一境界的基礎(chǔ)。

閑話：今天你OO了嗎？

如果你的分析習(xí)慣是在調(diào)研需求時最先弄清楚有多少業(yè)務(wù)流程，先畫出業(yè)務(wù)流程圖，然后順藤摸瓜，找出業(yè)務(wù)流程中每一步驟的參與部門或崗位，弄清楚在這一步參與者所做的事情和填寫表單的結(jié)果，并關(guān)心用戶是如何把這份表單傳給到下一個環(huán)節(jié)的。那么很不幸，你還在做面向過程的事情。

如果你的分析習(xí)慣是在調(diào)研需求時最先弄清楚有多少部門，多少崗位，然后找到每一個崗位的業(yè)務(wù)代表，問他們類似的問題：你平時都做什么？這件事是誰交辦的？做完了你需要通知或傳達(dá)給誰嗎？做這件事情你都需要填寫些什么表格嗎？....那么恭喜你，你已經(jīng)OO啦！

OO系統(tǒng)分析員之路--用例分析系列（2）

--用例的類型與粒度

在正式討論如何獲取用例之前，筆者覺得有兩個問題還是先解釋清楚為好，這對正確獲取用例有很大幫助。這兩個問題也是初學(xué)者最為困惑，也是最難掌握的。一個是各種用例類型之間的區(qū)別和用法，另一個是用例的粒度。

先說說用例類型的問題。

用例類型，有的資料翻譯為版型，英文原文是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建模的人常常在這些類型中迷失，搞不清楚這些類型是什么含義，什么時候該使用什么類型。簡單說，需求分析中的各個階段要描述和分析的目標(biāo)不同，為表達(dá)不同的視角和分析目標(biāo)，需要使用不同的用例類型。筆者的觀點(diǎn)是，用例類型的區(qū)分是為了形式上的統(tǒng)一，但用例類型既然可以自定義，它就是一個很靈活的用法，不必墨守成規(guī)，大可在工作中根據(jù)實(shí)際情況定義適合自己項(xiàng)目特點(diǎn)和軟件過程的用例類型。不過，默認(rèn)的用例類型已經(jīng)幾乎可以滿足需求分析的各個階段，自定義的必要性并不大，并且UML的意義就是使用統(tǒng)一的形式描述需求，因此最好使用默認(rèn)的類型。

說到需求分析階段，那么需求分析都有些什么階段呢？一般來說，需求分析要經(jīng)過業(yè)務(wù)建模，用例分析和系統(tǒng)建模三個階段才能完成需求工作，這三個階段分別做什么筆者會在以后的文章的詳細(xì)闡述，這里為了說明用例類型的含義和使用，先簡單介紹一下。

1、業(yè)務(wù)建模的目標(biāo)是通過用例模型的建立來描述用戶需求，需求規(guī)格說明書通常在這個階段產(chǎn)生。這個階段通常使用業(yè)務(wù)用例和業(yè)務(wù)用例實(shí)現(xiàn)兩種類型；

2、用例分析是系統(tǒng)分析員采用OO方法來分析業(yè)務(wù)用例的過程，這個階段又稱為概念模型階段。這個階段通常使用無類型的用例。用例分析是一個過渡過程，但筆者認(rèn)為其非常重要，業(yè)務(wù)架構(gòu)通常在這個階段產(chǎn)生。

3、系統(tǒng)建模是將用戶的業(yè)務(wù)需求轉(zhuǎn)化為計算機(jī)實(shí)現(xiàn)的過程。這個階段通常使用無類型的用例和用例實(shí)現(xiàn)兩種類型。系統(tǒng)范圍，項(xiàng)目計劃，系統(tǒng)架構(gòu)通常在這個階段形成雛形（在系統(tǒng)分析階段確定）。

所謂business usecase，是用來描述用戶原始需求的，它的含義是站在用戶的角度，使用用戶的業(yè)務(wù)術(shù)語來描述用戶在其業(yè)務(wù)領(lǐng)域所做的事情。業(yè)務(wù)用例命名，描述都必須采用純業(yè)務(wù)語言，而不能出現(xiàn)計算機(jī)術(shù)語。因?yàn)闃I(yè)務(wù)模型是系統(tǒng)分析員與用戶討論需求，達(dá)到一致理解的基礎(chǔ)，必須使用用戶熟悉的，不會有歧義的專業(yè)術(shù)語以避免系統(tǒng)分析員與用戶對同一事件的理解誤差。business usecase realization是達(dá)到需求可追溯要求的一個連接點(diǎn)，是用戶在其業(yè)務(wù)場景中如何做這一件事的載體。

筆者自己在用例分析和系統(tǒng)建模階段不區(qū)分用例類型，都使用無類型的use case，但在這兩個階段，用例的含義還是有所差別的。用例分析階段，用例主要是從 業(yè)務(wù)模擬的概念上，從OO的視角來分解、組合業(yè)務(wù)用例，粗略的建立一個業(yè)務(wù)架構(gòu)。而在系統(tǒng)建模階段，用例主要是從計算機(jī)視角描述需求，規(guī)定開發(fā)范圍，作為項(xiàng)目計劃的依據(jù)，為系統(tǒng)設(shè)計做準(zhǔn)備。usecase realization的含義可從business use case realization推知。

再來說說用例的粒度問題。

粒度是令人迷惑的。比如在ATM取錢的場景中，取錢，讀卡，驗(yàn)證賬號，打印回執(zhí)單等都是可能的用例，顯然，取錢包含了后續(xù)的其它用例，取錢粒度更大一些，其它用例的粒度則要小一些。到底是一個大的用例合適還是分解成多個小用例合適呢？這個問題并沒有一個標(biāo)準(zhǔn)的規(guī)則，筆者可以給大家分享的經(jīng)驗(yàn)是根據(jù)階段不同，使用不同的粒度。在業(yè)務(wù)建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜。即一個用例可以描述一項(xiàng)完整的業(yè)務(wù)流程。這將有助于明確需求范圍。例如取錢，報裝電話，借書等表達(dá)完整業(yè)務(wù)的用例，而不要細(xì)到驗(yàn)證密碼，填寫申請單，查找書目等業(yè)務(wù)中的一個步驟。在用例分析階段，用例的的粒度以每個用例能描述一個完整的事件流為宜。可理解為一個用例描述一項(xiàng)完整業(yè)務(wù)中的一個步驟。需要注意的是，這個階段需要采用OO方法，歸納，抽象業(yè)務(wù)用例中的概念模型。例如，寬帶業(yè)務(wù)需求中有申請報裝，申請遷移地址用例，在用例分析時，可歸納和分解為提供申請資料，受理業(yè)務(wù)，現(xiàn)場安裝等多個業(yè)務(wù)流程中都會使用的概念用例。在系統(tǒng)建模階段，用例視角是針對計算機(jī)的，因此用例的粒度以一個用例能夠描述操作者與計算機(jī)的一次完整交互為宜。例如，填寫申請單，審核申請單，派發(fā)任務(wù)單等。可理解為一個操作界面，或一個頁面流。在RUP中，項(xiàng)目計劃要依據(jù)系統(tǒng)模型編寫，因此另一個可參考的粒度是一個用例的開發(fā)工作量在一周左右為宜。

上述的粒度劃分方法筆者是用相對比較具體化的一些依據(jù)來說明。實(shí)際上，用例粒度的劃分依據(jù)（尤其是業(yè)務(wù)用例）最標(biāo)準(zhǔn)的方法是一個用例的粒度是否合適，是以該用例是否完成了參與者的某個目的為依據(jù)的。這個說法比較籠統(tǒng)，也比較難以掌握。，舉個例子，某人去圖書館，查詢了書目，出示了借書證，圖書管理員查詢了該人以前借閱記錄以確保沒有未歸還的書，最后借到了書。從這段話中能得出多少用例呢？請記住一點(diǎn)，用例分析是以參與者為中心的，因此用例的粒度以能完成參與者目的為依據(jù)。這樣，實(shí)際上適合用例是：借書。只有一個，其它都只是完成這個目的過程--這里討論的用例指的是業(yè)務(wù)用例--這個例子是比較明顯的能夠區(qū)分出參與者完整目的的，在很多情況下可能并沒有那么明顯，甚至?xí)袥_突。讀者可以從自己實(shí)際的情況去找出這種例子。以后的文章中筆者會做一些討論。

但是上述的粒度選擇并不是一個標(biāo)準(zhǔn)，只是在大多數(shù)情況下這樣的粒度選擇是比較合適的。筆者的意思也不是告訴讀者上述哪一種是最好的，而只是把一些常用的比較，劃分方法告訴讀者，期望的是幫助讀者在工作實(shí)踐中自己總結(jié)出一套適合自己的方法來。現(xiàn)實(shí)情況中，一個大型系統(tǒng)和一個很小的系統(tǒng)用例粒度選擇會有較大差異。這種差異是為了適應(yīng)不同的需求范圍。比如， 針對一個50人年的大型項(xiàng)目應(yīng)該選擇更大的粒度，如果用例粒度選擇過小，可能出現(xiàn)上百甚至幾百個業(yè)務(wù)用例，造成的后果是需求因?yàn)檫^于細(xì)碎和太多而無法控制，較少的用例有助于把握需求范圍，不容易遺漏。而針對一個10人月的小項(xiàng)目應(yīng)該選擇小一些的粒度，如果用例粒度選擇過大，可能只有幾個業(yè)務(wù)用例，造成的后果是需求因?yàn)檫^于模糊而容易忽略細(xì)節(jié)。一般來說，一個系統(tǒng)的業(yè)務(wù)用例定義在多于10個，少于50個之間，否則就應(yīng)該考慮一下粒度選擇是否合適了。

不論粒度如何選擇，必須把握的原則是在同一個需求階段，所有用例的粒度應(yīng)該是同一個量級的。這應(yīng)該很好理解，在描述一棟建筑時，我們總是把高度，層數(shù)，單元數(shù)等合在一起介紹，而把下水道位置，插座數(shù)量等合在一起介紹。如果你這樣介紹一棟樓：這棟樓有10層，下水道在廚房東南角，預(yù)留了15個插座，共有5個單元，聽眾一定會覺得云山霧罩，很難在腦子里形成一個清晰的影像。

如果對上面兩個問題讀者還有疑惑，不用著急，在以后的文章中應(yīng)該會逐步加深理解。

預(yù)告：下一篇文章將通過一個例子，闡述獲取用例的一般方法和如何判斷用例的粒度是否合適。

Q&A

--------------------------------------------------------------------------

Q：由 pushboy 發(fā)布
在業(yè)務(wù)建模階段，用例的粒度以每個用例能夠說明一件完整的事情為宜。即一個用例可以描述一項(xiàng)完整的業(yè)務(wù)流程。"
"在系統(tǒng)建模階段，用例視角是針對計算機(jī)的，因此用例的粒度以一個用例能夠描述操作者與計算機(jī)的一次完整交互為宜。"
那么，這樣一個場景 —— 用戶管理，有增刪改查
這里，是把 用戶管理 作為一個用例，還是把增刪改查分別作為用例呢？
他們每一個都是一個完整的業(yè)務(wù)流程和一次完整交互，而且也都是一個actor發(fā)起的動作；怎么來確認(rèn)呢？
我們的前提是一個普通的比如說財務(wù)系統(tǒng)，而不是一個用戶管理系統(tǒng)

A：這個問題很好，用例的粒度總是在這樣左也可右也可之間難以決定。對這個問題來說，我的觀點(diǎn)是業(yè)務(wù)用例應(yīng)當(dāng)用“管理用戶”或“維護(hù)用戶”作為合適的粒度，而增，刪，改，查則在作為系統(tǒng)用例。我的理由是：
增刪改查不能做為一個完整的業(yè)務(wù)來理解。作為一個管理業(yè)務(wù)，數(shù)據(jù)只有先增，才會有改，才會有刪。增刪改查結(jié)合起來才能完成actor的管理目的，只刪或只增加都不是業(yè)務(wù)的全部。是否是一項(xiàng)完整業(yè)務(wù)，要看actor的目標(biāo)，而不是事情是否完整。這個例子中，actor的目標(biāo)是為了增加一個用戶嗎？是為了刪除一個用戶嗎？都不是，而是為了管理用戶，這個目標(biāo)包括了用戶這個實(shí)體的整個生命周期。

再討論深一些，如果業(yè)務(wù)要求對用戶除了增刪改查，還有別的要求，例如權(quán)限升級，用戶在組織機(jī)構(gòu)中復(fù)雜的關(guān)系變更，用戶與外部系統(tǒng)的交互....實(shí)際的情況可能會更多，那么，如果將每個都作為一個業(yè)務(wù)用例，很容易造成一個結(jié)果，這些原本與用戶這個實(shí)體緊密關(guān)聯(lián)，共同組成用戶實(shí)體生命周期的業(yè)務(wù)，被割裂成多個獨(dú)立的業(yè)務(wù)，因?yàn)槎x了多個用例（請參看本人第一篇中的用例特征第一條）。要知道，在RUP中，用例驅(qū)動的含義是，一個用例就是一個分析單元，設(shè)計單元，開發(fā)單元，測試單元甚至部署單元。相信讀者都知道，把緊密關(guān)聯(lián)的業(yè)務(wù)分成多個獨(dú)立部分去實(shí)施是高成本的，高風(fēng)險的。

另外，為什么我要說在系統(tǒng)用例階段要把增，刪，改，查又分出來呢？原因在于，系統(tǒng)用例的目的是為了將actor的業(yè)務(wù)用計算機(jī)模擬出來。我們都知道，一般情況下，增，刪，改，查對一個actor來說是不會同時發(fā)生的，每次actor只會完成其中的一個行為。分開來，有利于詳細(xì)分析模擬這一行為的細(xì)節(jié)而不至于混淆。另一方面，對WEB應(yīng)用來說，針對數(shù)據(jù)的增，刪，改，查等，很容易形成所謂的“模板”，增加用戶用這個模板，增加其它基礎(chǔ)數(shù)據(jù)可能也用同一個模板，無非是操作的數(shù)據(jù)（實(shí)體）不同而已。因此，在很多情況下，這些模板是可以復(fù)用的。對這個例子來說，在系統(tǒng)用例階段，我們可以用“管理用戶” include “增加用戶”來表示這個實(shí)現(xiàn)關(guān)系，同時，讓“增加用戶”，“增加XX數(shù)據(jù)”等等用例來繼承自一個抽象出來的“增加數(shù)據(jù)”用例，這樣，可復(fù)用的模板體現(xiàn)在“增加數(shù)據(jù)”用例上，而具體業(yè)務(wù)，則體現(xiàn)在“增加XX數(shù)據(jù)”上。實(shí)際上，這也是一種OO思想的體現(xiàn)。

只有一個查詢是比較特殊的，查詢一般不一定只局限于一個actor，也不一定局限這個用例，一般都是所謂的綜合查詢，是可能跨用例的。所以根據(jù)實(shí)際情況，查詢可以作為一個業(yè)務(wù)用例出現(xiàn)。

OO系統(tǒng)分析員之路--用例分析系列（3）--業(yè)務(wù)建模之涉眾2008-12-10 15:27從這一篇開始，筆者將借助一個虛擬的實(shí)例來闡述獲取用例的方法，以及如何判斷用例獲取是否完備，粒度選擇是否合適。事實(shí)上，在做這些工作時，我們正在進(jìn)行需求分析的第一個階段，即業(yè)務(wù)建模階段。借助這個例子，筆者同樣會闡述業(yè)務(wù)建模到底應(yīng)該做什么，做到什么地步才能說明業(yè)務(wù)需求已經(jīng)完整，可以稱為一份完整的需求規(guī)格說明書了。 一般來說，只有當(dāng)以下工作都完成，才能說業(yè)務(wù)模型建立完成，它們是：

發(fā)現(xiàn)和定義涉眾

畫定業(yè)務(wù)邊界

獲取用例

繪制用例場景圖

繪制業(yè)務(wù)實(shí)體模型（領(lǐng)域模型）

編制詞匯表

下面筆者開始就一個事例來說明如何完成這些工作，這只是一個虛擬的事例，它的合理性和真實(shí)性請讀者不必追究。

現(xiàn)在我們接到一個項(xiàng)目，是一個網(wǎng)上圖書借閱系統(tǒng)，初步跟客戶接觸，網(wǎng)上圖書館的業(yè)務(wù)負(fù)責(zé)人這樣告訴我：

我們原本是一個傳統(tǒng)的圖書館，傳統(tǒng)的借書方式要求讀者親自來到圖書館，這顯得非常不方便，而且隨著藏書的增加和讀者群的增長，尤其而且大量的讀者到圖書館，使得圖書館的場地不足，工作人員也不夠了。所以想到借助網(wǎng)絡(luò)，讓讀者通過網(wǎng)絡(luò)借/還書，這樣可以省掉大量的場地維護(hù)和工作人員成本支出，同時計算機(jī)可以方便的檢索目錄，讓讀者可以足不出戶借到需要的書。為了把書送到借閱人手里，我們已經(jīng)聯(lián)系了A特快專遞公司和B城市物流公司，初步達(dá)成協(xié)議，由他們往返借閱人和圖書館之間把圖書送出和收回。讀者在網(wǎng)上出示和驗(yàn)證借書卡，找到他們需要的書，提交申請，圖書管理員確認(rèn)后，就會通知物流公司來取書，當(dāng)讀者拿到書之后，物流公司需要把讀者的簽單拿回來以證明讀者已經(jīng)拿到了書。當(dāng)然這個過程中，讀者是需要付費(fèi)的。還書也是基本同樣的過程。

好了，通過這番談話，我們已經(jīng)基本上了解了系統(tǒng)目標(biāo)。一些著急的系統(tǒng)分析員已經(jīng)準(zhǔn)備開始著手詢問借書的流程，借閱人的資格認(rèn)證問題了，甚至有的人已經(jīng)憑借多年的開發(fā)經(jīng)驗(yàn)在腦海中繪制出了一幅網(wǎng)頁，考慮如何實(shí)現(xiàn)這個系統(tǒng)了。

筆者要說的是，請您千萬不要著急往下走。因?yàn)槲覀兊玫降膬H僅是一個由非計算機(jī)專業(yè)人員規(guī)劃出的很粗略的構(gòu)想，其可行性如何都尚未得到證實(shí)，在這樣的基礎(chǔ)下就開始細(xì)化，將來出現(xiàn)反復(fù)甚至失敗的危險是很大的。

在了解了系統(tǒng)目標(biāo)以后，系統(tǒng)分析員最先要做的事情不是去了解業(yè)務(wù)的細(xì)節(jié)，而是去發(fā)現(xiàn)與這個目標(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)是通過以下大類去尋找：

業(yè)主

業(yè)主是系統(tǒng)建設(shè)的出資方，投資者，它不一定是業(yè)務(wù)方。比如可以假設(shè)這個圖書館的網(wǎng)絡(luò)化建設(shè)是由一家國際風(fēng)險投資機(jī)構(gòu)投資的，它本身并不管理圖書館，它只是從資本上擁有這個系統(tǒng)并從借書收入中獲得回報。

了解業(yè)主的期望是必須和重要的，業(yè)主的錢是這個項(xiàng)目存在的原因。若系統(tǒng)建設(shè)不符合業(yè)主的期望，撤回投資，那么再好的愿望也是空的。

一般來說，業(yè)主關(guān)心的是建設(shè)成本，建設(shè)周期以及建成后的效益。雖然這些看上去與系統(tǒng)需求沒什么大的關(guān)系，但是，建設(shè)成本、建設(shè)周期將直接影響到你可以采用的技術(shù)，可以選用的軟件架構(gòu)，可以承受的系統(tǒng)范圍。一個不能達(dá)到業(yè)主成本和周期要求的項(xiàng)目是一個失敗的項(xiàng)目，同樣，一個達(dá)到了業(yè)主成本和周期要求，但卻沒有賺到錢的項(xiàng)目仍然是一個失敗的項(xiàng)目。

業(yè)務(wù)提出者

業(yè)務(wù)提出者是業(yè)務(wù)規(guī)則的制定者，一般是指業(yè)務(wù)方的高層人物，比如CEO，高級經(jīng)理等。他們制定業(yè)務(wù)規(guī)則，圈定業(yè)務(wù)范圍，規(guī)劃業(yè)務(wù)目標(biāo)。他們的期望十分十分的重要，實(shí)際上，系統(tǒng)建設(shè)正是業(yè)務(wù)提出者經(jīng)營和管理意志的體現(xiàn)。他們的期望一般比較原則化和粗略化，但是卻不能違反和誤解，否則系統(tǒng)將有徹底失敗的危險。業(yè)務(wù)提出者一般最關(guān)心系統(tǒng)建設(shè)能夠帶來的社會影響，效率改進(jìn)和成本節(jié)約。換句話說，他們只關(guān)心統(tǒng)計意義而不關(guān)心具體細(xì)節(jié)，但是，如果建設(shè)完成的系統(tǒng)不能給出他們滿意的統(tǒng)計結(jié)果，這必定是一個失敗的項(xiàng)目。在系統(tǒng)建設(shè)過程的溝通中，他們的意志一般是極少妥協(xié)的，系統(tǒng)分析員不必太費(fèi)心去試圖說服他們接受一個與他們意志相左的方案。實(shí)際上，由于他們的期望是非常原則化和粗略的，因此留給了系統(tǒng)建設(shè)者很大的調(diào)整空間和規(guī)避風(fēng)險的余地。

業(yè)務(wù)管理者

業(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ù)管理者的期望相對比較細(xì)節(jié)，是需求調(diào)研過程中最重要的信息來源。系統(tǒng)建設(shè)的好壞與業(yè)務(wù)管理者的關(guān)系最多，也是系統(tǒng)分析員最需要下功夫的。系統(tǒng)分析員必須要把業(yè)務(wù)管理者的思路，想法弄清楚，業(yè)務(wù)建模的結(jié)果也必須與業(yè)務(wù)管理者達(dá)成一致。在系統(tǒng)建設(shè)過程中，業(yè)務(wù)管理者的期望可以有所妥協(xié)，一個經(jīng)驗(yàn)豐富的系統(tǒng)分析員可以給他們灌輸合理的管理方式，提供可替代的管理方法，以規(guī)避導(dǎo)致高技術(shù)風(fēng)險或高成本風(fēng)險的不合理要求。

業(yè)務(wù)執(zhí)行者

業(yè)務(wù)執(zhí)行者是指底層的操作人員，是與將來的計算機(jī)直接交互最多的人員。他們最關(guān)心的內(nèi)容是系統(tǒng)會給他們帶來什么樣的方便，會怎樣的改變他們的工作模式。他們的需求最細(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)研時需要多下功夫的地方。這類人員的期望靈活性最大，也最容易說服和妥協(xié)。同時，他們的期望又往往是不統(tǒng)一的，各種古怪的要求都有。他們的期望必須服從業(yè)務(wù)管理者的期望，因此，系統(tǒng)分析員需要從他們的各種期望中找出普遍意義，解決大部分人的問題，必要時可以依靠業(yè)務(wù)管理者來影響和消除不合理的期望。

第三方

第三方是指與這項(xiàng)業(yè)務(wù)而關(guān)聯(lián)的，但并非業(yè)務(wù)方的其他人或事。比如在這個事例中，借閱人借書時需要交費(fèi)，若交費(fèi)是通過網(wǎng)上銀行支付的，則網(wǎng)上銀行就成為了網(wǎng)上借書系統(tǒng)的一個涉眾。

第三方的期望對系統(tǒng)來說不起決定性意義，但會起到限制作用。最終在系統(tǒng)中，這種期望將體現(xiàn)為標(biāo)準(zhǔn)、協(xié)議和接口。

另一種典型的第三方是項(xiàng)目監(jiān)理，系統(tǒng)分析員也必須弄清楚監(jiān)理的期望。

承建方

承建方，也就是你的老板。老板的期望也是非常重要的。老板關(guān)心的是通過這個項(xiàng)目，能否賺到錢，是否能積累核心競爭力，是否能樹立品牌，是否能開拓市場。老板的期望將很大的影響一個項(xiàng)目的運(yùn)作模式，技術(shù)選擇，架構(gòu)建立和范圍確定。比如，老板試圖通過這個項(xiàng)目打開一個市場，樹立起品牌，不惜成本，那么，系統(tǒng)分析員需要盡可能的深入挖掘潛在業(yè)務(wù)，建立擴(kuò)展能力很強(qiáng)，但成本較高的業(yè)務(wù)架構(gòu)，選擇那些較新，但風(fēng)險較高的技術(shù)。反之，如果老板只想通過這個項(xiàng)目賺更多的錢，系統(tǒng)分析員就需要引導(dǎo)業(yè)務(wù)方壓縮業(yè)務(wù)范圍，選擇風(fēng)險小的成熟技術(shù)，甚至不用考慮業(yè)務(wù)架構(gòu)，考慮系統(tǒng)的可維護(hù)性，而較少考慮系統(tǒng)擴(kuò)展能力。

一個業(yè)主滿意但老板不滿意的項(xiàng)目，恐怕也不是一個成功的項(xiàng)目吧？

相關(guān)的法律法規(guī)

相關(guān)的法律法規(guī)是一個很重要的，但也最容易被忽視的涉眾。這里的法律法規(guī)，既指國家和地方法律法規(guī)，也指行業(yè)規(guī)范和標(biāo)準(zhǔn)。例如，這個借閱系統(tǒng)中要建立借閱人檔案，就必須保障借閱人的隱私權(quán)；要與網(wǎng)上銀行交易，必須遵守信息安全法等。若遇到業(yè)務(wù)方提出違反了法律法規(guī)的要求時，系統(tǒng)分析員要能給他們指出來，說服無果的情況下要在合同里留下免責(zé)條款。否則一不小心惹上官司可是件郁悶的事。

另外，有時必須得遵守一些行業(yè)規(guī)范。例如本事例是網(wǎng)上借閱，網(wǎng)絡(luò)需求決定了需要遵守HTML規(guī)范，才能保證借閱者能正常瀏覽網(wǎng)頁。

用戶

用戶是一個抽象的概念，是指預(yù)期的系統(tǒng)使用者。用戶可能包括上述的任何一種涉眾。用戶涉眾模型建立的意義是，每一個用戶將來都可能是系統(tǒng)中的一個角色，是實(shí)實(shí)在在參與系統(tǒng)的，需要編程實(shí)現(xiàn)。而上述的其它涉眾，則有可能只是在需求階段有用，最終并不與系統(tǒng)發(fā)生交互。在建模過程中，概念模型的建立和系統(tǒng)模型的建立都只從用戶開始分析，而不再理會其它的涉眾。在Rose中建模的時候，也只需要建立用戶的模型，其它涉眾則只需要體現(xiàn)在文檔中即可。

這篇文章只能到此為止了，否則太長的話，讀者該不耐煩了。只好在此分節(jié)。下一節(jié)筆者將一步步將涉眾的期望導(dǎo)出，并得到需求范圍的大致輪廓。

未完待續(xù).......