2009-05-04 作者：coffeewoo 來源：coffeewoo的blog
（5）--用戶、業(yè)務(wù)用例和業(yè)務(wù)場(chǎng)景
寫點(diǎn)什么呢？按照原先的設(shè)想，應(yīng)該開始動(dòng)手寫如何從業(yè)務(wù)用例轉(zhuǎn)化到概念用例和系統(tǒng)用例，不過老實(shí)說這一步需要的是經(jīng)驗(yàn)居多，而很難找出一個(gè)普適的步驟來。先暫時(shí)放一放吧，以后一定會(huì)寫到的。上一篇講到用例分析的一般步驟和方法，也給出了一個(gè)實(shí)例，不過沒有做更進(jìn)一步的說明，所以這一篇，筆者決定先羅嗦羅嗦之前的內(nèi)容，說說業(yè)務(wù)建模中各種圖的用法，以及它們對(duì)需求的貢獻(xiàn)。
在說明實(shí)例之前，再重復(fù)一下的需求，并提醒讀者下載實(shí)例，本文下面只會(huì)從實(shí)例中挑選很少一部分來說明，對(duì)照實(shí)例讀者將能更好的理解。好了，讓我們先回頭看看需求吧，圖書館主任是這么說的：
我們?cè)臼且粋€(gè)傳統(tǒng)的圖書館，傳統(tǒng)的借書方式要求讀者親自來到圖書館，這顯得非常不方便，而且隨著藏書的增加和讀者群的增長(zhǎng)，尤其而且大量的讀者到圖書館，使得圖書館的場(chǎng)地不足，工作人員也不夠了。所以想到借助網(wǎng)絡(luò)，讓讀者通過網(wǎng)絡(luò)借/還書，這樣可以省掉大量的場(chǎng)地維護(hù)和工作人員成本支出，同時(shí)計(jì)算機(jī)可以方便的檢索目錄，讓讀者可以足不出戶借到需要的書。為了把書送到借閱人手里，我們已經(jīng)聯(lián)系了A特快專遞公司和B城市物流公司，初步達(dá)成協(xié)議，由他們往返借閱人和圖書館之間把圖書送出和收回。讀者在網(wǎng)上出示和驗(yàn)證借書卡，找到他們需要的書，提交申請(qǐng)，圖書管理員確認(rèn)后，就會(huì)通知物流公司來取書，當(dāng)讀者拿到書之后，物流公司需要把讀者的簽單拿回來以證明讀者已經(jīng)拿到了書。當(dāng)然這個(gè)過程中，讀者是需要付費(fèi)的。還書也是基本同樣的過程。
還記得上一篇是怎么說的嗎？第一步驟是從涉眾中找出用戶。并定義這些用戶之間的關(guān)系。 這里的用戶是指將與要建設(shè)的系統(tǒng)發(fā)生關(guān)系的那些涉眾。通過下圖表示。這張圖里要繪出所有用戶，以及它們之間的關(guān)系。需要說明的是，這里的用戶指的是業(yè)務(wù)用戶，并非將來系統(tǒng)中的“角色”，雖然將來它們可能就是。這張圖的意義在于，清楚的表明將來的系統(tǒng)是為誰在服務(wù)，他們都是干什么的，有什么特點(diǎn)，有什么關(guān)系。對(duì)用例方法來說，這是最基本的出發(fā)點(diǎn)。用例，是以人為本的。
第二步，找出每個(gè)用戶要做的事，即業(yè)務(wù)用例。業(yè)務(wù)用例來自于系統(tǒng)分析員對(duì)上一步中所有用戶的訪談，總結(jié)和歸納（筆者正在考慮寫一寫系統(tǒng)分析員調(diào)研技巧方面的文章，會(huì)對(duì)訪談技巧，歸納方法有所描述）。筆者建議從每個(gè)用戶的角度以及從每項(xiàng)業(yè)務(wù)的角度來繪制業(yè)務(wù)用例圖，就象下面這樣：
用戶視角：
從用戶視角查看每個(gè)用戶在系統(tǒng)中將參與什么業(yè)務(wù)。這個(gè)視圖的意義在于，調(diào)研對(duì)象一眼就能看出來，這個(gè)模型是否已經(jīng)涵蓋了他所有需要做的事。
業(yè)務(wù)視角：
從業(yè)務(wù)的視角查看每項(xiàng)業(yè)務(wù)是由哪些用例和哪些角色參與完成的。這個(gè)視圖的意義在于，需求研討會(huì)上業(yè)務(wù)專家可以一眼看出這個(gè)模型是否已經(jīng)能夠完整的表達(dá)業(yè)務(wù)。
第三步，針對(duì)每項(xiàng)業(yè)務(wù)視圖，應(yīng)該繪制業(yè)務(wù)場(chǎng)景圖，用活動(dòng)圖詳細(xì)描述這些用戶、用例是如何交互來完成這項(xiàng)業(yè)務(wù)的。就象下面這樣:
借閱圖書業(yè)務(wù)過程:
業(yè)務(wù)場(chǎng)景圖可能不止一個(gè)。同樣一項(xiàng)業(yè)務(wù)，會(huì)有很多種不同的業(yè)務(wù)實(shí)現(xiàn)方式，例如借閱圖書業(yè)務(wù)，就有可能第一次借書，又還書又借書，VIP客戶借書，借書時(shí)借證已經(jīng)到期....等等許多種場(chǎng)景。對(duì)于這些場(chǎng)景來說，每一個(gè)都不能漏掉或省略，至少必須在文檔中體現(xiàn)出來，除非已經(jīng)很明確這個(gè)業(yè)務(wù)場(chǎng)景不包括在系統(tǒng)范圍之內(nèi)。這些業(yè)務(wù)場(chǎng)景圖的意義在于，它已經(jīng)繪制出了一份系統(tǒng)藍(lán)圖，將來的系統(tǒng)建設(shè)很大程度將依據(jù)這些場(chǎng)景圖進(jìn)行。
經(jīng)過上面的三個(gè)步驟，我們得到了用戶、業(yè)務(wù)用例以及業(yè)務(wù)場(chǎng)景。這三項(xiàng)工作成果已經(jīng)形成了基本的需求框架，并圈定了業(yè)務(wù)范圍。就筆者的工作習(xí)慣而言，在得到這三個(gè)成果后，就會(huì)暫停調(diào)研，而通過評(píng)審會(huì)，研討會(huì)等形式充分論證這些成果的正確性和完備性。求得業(yè)務(wù)專家，用戶代表，開發(fā)方，項(xiàng)目經(jīng)理等各方的一致認(rèn)可，將其作為第一份基線。筆者很少在這個(gè)基線形成之前深入細(xì)化需求，因?yàn)樾枨筮^程，或說用例過程是一個(gè)自頂向向下的過程，RUP中的每一個(gè)迭代實(shí)際上仍然是一個(gè)瀑布模型，大家都知道，如果上一步?jīng)]有形成基線就進(jìn)行下一步，對(duì)瀑布模型來說是無法控制的。
好了，這一篇就到此為止，下一篇繼續(xù)討論用例場(chǎng)景，用例文檔等建模過程。
（6）--用例實(shí)現(xiàn)、用例場(chǎng)景和領(lǐng)域模型
上一篇確定了業(yè)務(wù)用例，以及業(yè)務(wù)場(chǎng)景。該場(chǎng)景只描述了業(yè)務(wù)框架，接下來要對(duì)業(yè)務(wù)用例進(jìn)行場(chǎng)景分析。用例場(chǎng)景分析要用到三種視圖，業(yè)務(wù)用例實(shí)現(xiàn)視圖、業(yè)務(wù)用例場(chǎng)景、業(yè)務(wù)實(shí)體模型（領(lǐng)域模型），每個(gè)業(yè)務(wù)用例還應(yīng)當(dāng)寫一份用例文檔，也稱為用例規(guī)約（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，還應(yīng)當(dāng)寫一份補(bǔ)充用例規(guī)約。
上一篇說到我們經(jīng)過初步的業(yè)務(wù)分析，得到了用戶、業(yè)務(wù)用例以及業(yè)務(wù)場(chǎng)景模型。這三項(xiàng)工作成果形成了基本的需求框架，并圈定了業(yè)務(wù)范圍。這時(shí)應(yīng)當(dāng)做一份基線。
當(dāng)然，第一份基線所包括的內(nèi)容是非常粗的，要達(dá)到完整的需求說明還有更多工作要做。這一篇就來說說詳細(xì)的需求過程和產(chǎn)出物，以及這些成果對(duì)需求的貢獻(xiàn)。在開始之前，還是提醒讀者
下載實(shí)例，本文下面只會(huì)從實(shí)例中挑選很少一部分來說明，對(duì)照實(shí)例讀者將能更好的理解。
上一篇確定了業(yè)務(wù)用例，以及業(yè)務(wù)場(chǎng)景。該場(chǎng)景只描述了業(yè)務(wù)框架，接下來要對(duì)業(yè)務(wù)用例進(jìn)行場(chǎng)景分析。用例場(chǎng)景分析要用到三種視圖，業(yè)務(wù)用例實(shí)現(xiàn)視圖、業(yè)務(wù)用例場(chǎng)景、業(yè)務(wù)實(shí)體模型（領(lǐng)域模型），每個(gè)業(yè)務(wù)用例還應(yīng)當(dāng)寫一份用例文檔，也稱為用例規(guī)約（UseCase Specification）。若有非功能性需求，例如性能要求，吞吐量要求等，還應(yīng)當(dāng)寫一份補(bǔ)充用例規(guī)約。用例規(guī)約將在下一篇描述。
首先是業(yè)務(wù)用例實(shí)現(xiàn)視圖。并非所有的業(yè)務(wù)用例都一定要最終在系統(tǒng)中實(shí)現(xiàn)，因此，這個(gè)視圖的含義是表達(dá)由需求范圍到系統(tǒng)范圍的映射關(guān)系。這個(gè)視圖沒什么技巧，也可以省略，不過筆者建議不要省略。需求應(yīng)當(dāng)保持過程的連續(xù)和可追溯性，這是軟件過程可控的重要保證。
業(yè)務(wù)用例實(shí)現(xiàn)視圖：
針對(duì)每個(gè)業(yè)務(wù)用例實(shí)現(xiàn)，應(yīng)當(dāng)對(duì)用例的實(shí)現(xiàn)過程進(jìn)行場(chǎng)景模擬。上一篇是業(yè)務(wù)場(chǎng)景，而用例實(shí)現(xiàn)既然已經(jīng)談到“實(shí)現(xiàn)”，則應(yīng)當(dāng)將計(jì)算機(jī)包括進(jìn)來，從人-機(jī)交互的視角來模擬業(yè)務(wù)場(chǎng)景。這是概念模型的一種，表達(dá)用戶的實(shí)際業(yè)務(wù)在計(jì)算機(jī)環(huán)境下是如何實(shí)現(xiàn)的，給用戶一個(gè)初步印象，告訴他們將來他們將怎樣來做業(yè)務(wù)。請(qǐng)注意，雖然計(jì)算機(jī)已經(jīng)參與需求描述，但是要盡量避免使用計(jì)算機(jī)術(shù)語，因?yàn)檫@時(shí)的文檔仍然屬于需求文檔，是要與用戶交流的，太多的計(jì)算機(jī)術(shù)語會(huì)大大降低用戶對(duì)需求的理解能力。霍金在寫時(shí)間簡(jiǎn)史時(shí)曾經(jīng)說過，在書中加入哪怕一個(gè)數(shù)學(xué)公式，都會(huì)讓書的銷量減半。業(yè)務(wù)用例場(chǎng)景是概念模型的一種，但不是概念模型的全部。概念模型本篇不打算討論，簡(jiǎn)單說一下，概念模型主要包括業(yè)務(wù)架構(gòu)和系統(tǒng)原型。
應(yīng)當(dāng)在業(yè)務(wù)用例實(shí)現(xiàn)里添加活動(dòng)圖用以描述用例場(chǎng)景，下圖為示例，用活動(dòng)圖繪制。如果有多個(gè)場(chǎng)景，則應(yīng)當(dāng)繪制多個(gè)場(chǎng)景圖。
業(yè)務(wù)用例場(chǎng)景(借書過程)：
用例場(chǎng)景有另一個(gè)重要意義，是幫助系統(tǒng)分析員發(fā)現(xiàn)和定義業(yè)務(wù)實(shí)體。業(yè)務(wù)實(shí)體一般來說就是調(diào)研時(shí)用戶所提供的各類表單或報(bào)表，但在很多情況下，并非每一份表單就是一個(gè)業(yè)務(wù)實(shí)體，所有業(yè)務(wù)表單也不一定涵蓋全了所有業(yè)務(wù)實(shí)體。很多系統(tǒng)分析員聲稱業(yè)務(wù)實(shí)體的發(fā)現(xiàn)過程是全憑經(jīng)驗(yàn)的，到底有哪些業(yè)務(wù)實(shí)體，靠經(jīng)驗(yàn)進(jìn)行提取。筆者要說，經(jīng)驗(yàn)固然重要，但經(jīng)驗(yàn)有一個(gè)最大的缺陷---不能重復(fù)和驗(yàn)證。即，這些實(shí)體是怎么從業(yè)務(wù)中提取出來的？它們是怎樣參與業(yè)務(wù)的？這些實(shí)體已經(jīng)足夠支持業(yè)務(wù)了嗎？憑經(jīng)驗(yàn)分析者無法通過文檔將這個(gè)提取過程記錄下來，而腦子里的東西是無法共享和傳承的，越大的團(tuán)隊(duì)，越復(fù)雜的項(xiàng)目，尤其是橫向結(jié)構(gòu)的項(xiàng)目組結(jié)構(gòu)下，這個(gè)缺陷越嚴(yán)重。很多人覺得用UML和RUP描述的需求總是一塊塊分離的，不知道是怎么出來的，覺得很亂，原因就在于此。實(shí)際上，RUP做需求，每一步都是可驗(yàn)證和回溯的。用例實(shí)現(xiàn)視圖是一個(gè)例子，這里也是一個(gè)例子。
讓我們看看上面的業(yè)務(wù)場(chǎng)景視圖，每一個(gè)活動(dòng)都有類似的命名：出示借閱證、查找需要的圖書、放入借書欄.....看出什么來了嗎？每個(gè)活動(dòng)都是一個(gè)動(dòng)作加上一個(gè)動(dòng)作的受體。受體正是我們要尋找的業(yè)務(wù)實(shí)體，這些名詞就是實(shí)體的來源。在需求階段，系統(tǒng)分析員不要去考慮什么抽象，什么模式，別急，那是系統(tǒng)模型做的事情。抽象了，還弄一堆什么Factory模式，Builder模式之類的出來，用戶能看懂嗎？別忘了我們正在做的是需求文檔，是做給用戶看的。
觀察上面的用例場(chǎng)景，分析出現(xiàn)的名詞，我們得到一個(gè)個(gè)業(yè)務(wù)實(shí)體，再根據(jù)場(chǎng)景分析這些業(yè)務(wù)實(shí)體之間的關(guān)系。實(shí)際上就是大家都熟悉的ER模型，但是與數(shù)據(jù)庫(kù)建模的視角還是有所差別的。數(shù)據(jù)庫(kù)ER模型要受到數(shù)據(jù)關(guān)系范式的限制，而業(yè)務(wù)實(shí)體ER模型則不必理會(huì)這種限制。只要與現(xiàn)實(shí)物體符合就OK。好了，羅嗦了一大堆，我們終于得到了我們的成果。
借閱圖書過程業(yè)務(wù)實(shí)體視圖：
上圖中畫那么多虛線連接到業(yè)務(wù)用例實(shí)現(xiàn)是用來表示業(yè)務(wù)實(shí)體與業(yè)務(wù)用例實(shí)現(xiàn)之間的追溯關(guān)系的，這些線雖然麻煩，但是筆者強(qiáng)烈建議不要圖省事。因?yàn)闃I(yè)務(wù)實(shí)體通過它們可以追溯到原始需求，再次重申，軟件過程要可控，需求可追溯是需要時(shí)時(shí)謹(jǐn)記的。當(dāng)然，如果嫌麻煩，您也可以用下面的這種形式，是不是簡(jiǎn)潔得多呢？
經(jīng)過以上的過程，我們得到了什么呢？往下看之前筆者建議您回想一下，總結(jié)一下。
第一、我們通用用例實(shí)現(xiàn)視圖，從業(yè)務(wù)用例中找出了那些我們將在系統(tǒng)中實(shí)現(xiàn)的用例，并且記錄了要在系統(tǒng)中實(shí)現(xiàn)的用例是如何映射到原始需求的。這提供了需求可追溯的驗(yàn)證。
第二、針對(duì)每個(gè)用例實(shí)現(xiàn)，我們引入了計(jì)算機(jī)，將實(shí)際的業(yè)務(wù)從人-機(jī)交互的角度模擬了執(zhí)行過程。不僅得到了一個(gè)業(yè)務(wù)怎樣在計(jì)算機(jī)環(huán)境下執(zhí)行的概念模型，同時(shí)也給用戶描述了他們將怎么和計(jì)算機(jī)交互以達(dá)到他們的目標(biāo)。筆者提醒大家，用例場(chǎng)景非常非常的重要，后續(xù)工作就得靠它們了！！絕對(duì)要認(rèn)真對(duì)待，深入調(diào)研，不可漏掉一個(gè)場(chǎng)景，也不可模糊不清。
第三、通過對(duì)場(chǎng)景的分析，給了我們重要的線索去發(fā)現(xiàn)業(yè)務(wù)實(shí)體。而我們發(fā)現(xiàn)了業(yè)務(wù)實(shí)體之后，又通過用例場(chǎng)景來驗(yàn)證這些實(shí)體是否支持了用例的實(shí)現(xiàn)。
現(xiàn)在請(qǐng)讀者思考一下，如果記不清了，可以翻翻之前的文章。到現(xiàn)在為止，我們的需求是不是一步一步推出來的？從粗到細(xì)，從模糊到清晰，從原始需求到計(jì)算機(jī)的引入，是不是每一步都是可以追溯的呢？每一步的分析結(jié)果是不是都有方法來驗(yàn)證正確性和完備性呢？如果您之前迷惑于需求的各個(gè)階段無法關(guān)聯(lián)，也說不清分析結(jié)果是否是正確的，那么建議您再?gòu)念^看看筆者目前已經(jīng)完成的文章，找出這些線索來，相信您會(huì)對(duì)UML和RUP的理解提高一個(gè)層次的。
這篇文章該結(jié)束了。可是等等，到目前為止，雖然我們已經(jīng)得到了不少產(chǎn)品，或可交付物，或成果，或deliverable...不管叫什么吧，我們已經(jīng)做了很多工作了。不過作為需求來說，好象還缺點(diǎn)什么吧？對(duì)了，我們還缺少業(yè)務(wù)規(guī)則和業(yè)務(wù)實(shí)體的詳細(xì)屬性，這兩個(gè)需求必不可少的內(nèi)容，將在下一篇中討論。敬請(qǐng)期待。
（7）--用例規(guī)約的編寫--業(yè)務(wù)規(guī)則和實(shí)體描述
先說說業(yè)務(wù)規(guī)則。筆者習(xí)慣將業(yè)務(wù)規(guī)則分為三種。
一種是全局規(guī)則，這種規(guī)則一般與所有用例都相關(guān)而不是與特定用例相關(guān)，例如actor要操作用例必須獲得相應(yīng)的授權(quán)，用例的操作與授權(quán)級(jí)別相關(guān)，或者用戶在系統(tǒng)中的所有操作都要被記錄下來等等。這類規(guī)則筆者習(xí)慣于，并且也建議將它們寫到用例的補(bǔ)充規(guī)約里面去，因?yàn)樗鼈円话闩c具體的業(yè)務(wù)功能性要求沒有直接關(guān)系。有時(shí)候，這類規(guī)則也被寫到軟件架構(gòu)文檔中。關(guān)于用例補(bǔ)充規(guī)約以后再討論。
第二種是交互規(guī)則。這種規(guī)則產(chǎn)生于用例場(chǎng)景當(dāng)中，例如當(dāng)提交一份定單時(shí)，哪些數(shù)據(jù)是必須填寫的，用戶身份是否合法。當(dāng)然也包括一般理解上的業(yè)務(wù)流程流轉(zhuǎn)規(guī)則等，例如金額大于一萬元的定單被定為VIP定單進(jìn)入特殊流程等。這類規(guī)則一般要寫到用例規(guī)約中。交互規(guī)則實(shí)際上還有兩個(gè)是比較特殊的，一個(gè)入口條件，也稱為前置條件，即actor滿足什么條件才能啟動(dòng)用例;另一個(gè)是出口條件，也稱為后置條件，即用例結(jié)束后會(huì)產(chǎn)生哪些后果。稍后參看示例。
第三種是內(nèi)稟規(guī)則。所謂內(nèi)稟規(guī)則是指業(yè)務(wù)實(shí)體本身具備的規(guī)則，并且不因?yàn)橥獠康慕换ザ兓囊?guī)則。例如，每張定單至少要有一件商品，同一類商品數(shù)量不能大于5件等。同時(shí)也包括大家所熟悉的數(shù)據(jù)效驗(yàn)規(guī)則，例如身份證號(hào)必須是15或18位，郵編必須是6位等等。這類規(guī)則是業(yè)務(wù)實(shí)體的內(nèi)在規(guī)則，因此應(yīng)該寫到領(lǐng)域模型文檔中，稍后參看示例。
讀者或許對(duì)把規(guī)則這么分類有不同的習(xí)慣和理解，可能會(huì)覺得麻煩。但是筆者這么做有充分的理由。首先，全局規(guī)則與具體用例無關(guān)，它實(shí)際是系統(tǒng)應(yīng)該具備的特性，這些規(guī)則把它分出來目的就是為了讓系統(tǒng)去負(fù)責(zé)這些特性的實(shí)現(xiàn)。讀者可以結(jié)合實(shí)際考慮一下，通常授權(quán)，事務(wù)，備份等特性都是由系統(tǒng)框架去實(shí)現(xiàn)的，具體的功能中并不去實(shí)現(xiàn)它們。如果讀者有過基于某個(gè)框架開發(fā)應(yīng)用的經(jīng)歷的話一定會(huì)認(rèn)同筆者的話。其次，交互規(guī)則是在用例場(chǎng)景當(dāng)中產(chǎn)生的，它們規(guī)定了滿足什么條件后業(yè)務(wù)將如何反應(yīng)。通常，這部分規(guī)則是最復(fù)雜，也最不穩(wěn)定，最容易變化的。大家所說的需求經(jīng)常變更相信絕大部分就來自于此。因此將這些規(guī)則單獨(dú)列出來并給予關(guān)注和管理是很有必要的。同時(shí)這部分規(guī)則通常在系統(tǒng)中以Control類去實(shí)現(xiàn)，MVC模式如此，SOA架構(gòu)中的BPEL也是如此。如果需求無可避免的要變更，那么，將交互規(guī)則單獨(dú)提取出來，并設(shè)計(jì)成為擴(kuò)展性很強(qiáng)的結(jié)構(gòu)就是一種有效的應(yīng)對(duì)手段。第三，內(nèi)稟規(guī)則與外部交互無關(guān)，不論誰，在什么情況下提交定單，必須有至少有一件商品；不論你在哪個(gè)國(guó)家，在什么公路上開車，剎車都是必不可少的。這種內(nèi)在的性質(zhì)讓你想到了什么？面向?qū)ο蟮姆庋b原則對(duì)嗎？這類規(guī)則應(yīng)該實(shí)現(xiàn)到你的實(shí)體類中去，不論你的業(yè)務(wù)實(shí)體是EntityBean,JavaBean,POJO還是COM+，根據(jù)面向?qū)ο蟮姆庋b原則，內(nèi)稟的邏輯一定不要讓它暴露到外部去。
這么分類以后，對(duì)軟件成熟度比較高的組織來說，提供了很好的Level Reference。如果你是架構(gòu)師，應(yīng)該關(guān)注的是全局規(guī)則；如果你是設(shè)計(jì)師，應(yīng)該關(guān)注的是交互規(guī)則；如果你是程序員，應(yīng)該關(guān)注的是內(nèi)稟規(guī)則。
在這里筆者想說點(diǎn)題外話：）。筆者曾經(jīng)看過一篇《架構(gòu)師已死》的文章(很抱歉已經(jīng)記不起出處和作者，如有冒犯之處請(qǐng)海涵)，作者的觀點(diǎn)認(rèn)為架構(gòu)設(shè)計(jì)完成后，通常到最后改得面目全非，既然一開始不可能考慮到所有可能，何不如在開發(fā)過程中持續(xù)總結(jié)，重構(gòu)，最后架構(gòu)會(huì)自然而然出來的，如果這樣，架構(gòu)師有何用處呢？筆者認(rèn)為這個(gè)說法是有一定道理的，不過要看軟件組織架構(gòu)和軟件過程的定義，不可一概而論。《架》一文的作者是XP的fans，對(duì)XP軟件過程來說，本來就不需要架構(gòu)師這個(gè)角色，甚至連設(shè)計(jì)都不需要，開發(fā)，測(cè)試，改進(jìn)，重構(gòu)...，當(dāng)然，從一開始就沒打算按照一個(gè)stable的方法去做，架構(gòu)師也就沒有存在的必要。架構(gòu)師在XP中已死，不過在RUP中還活著：）。軟件界一直對(duì)XP和RUP有著爭(zhēng)論，筆者無意在本文中界入這個(gè)爭(zhēng)執(zhí)，只是話已經(jīng)到此，就順便表達(dá)一下筆者觀點(diǎn)。XP和RUP都是非常優(yōu)秀的軟件方法，只是它們各有各的適應(yīng)范圍。對(duì)于中小型公司和中小型軟件來說，XP是非常有效的管理方法，它能大大降低管理、開發(fā)成本和技術(shù)風(fēng)險(xiǎn)。不過要是對(duì)于大公司和大型項(xiàng)目來說，XP就不適用了，這時(shí)RUP卻非常適合。你能想象洛克希德·馬丁公司用XP的方法來開發(fā)F-35戰(zhàn)斗機(jī)會(huì)是一個(gè)什么情形嗎？沒有人清楚的知道將來的飛機(jī)整體是什么樣，反正先造一架出來，摔了找找原因，改進(jìn)改進(jìn)，重構(gòu)一下，再造一架....再摔了，沒關(guān)系，咱們擁抱變更，再造就是了。呵呵，那XP什么情況下適用呢？如果你是一個(gè)雜貨店的老板，不知道什么樣的商品受歡迎，沒關(guān)系，先各進(jìn)一小批貨，賣上一段時(shí)間，受歡迎的貨品多進(jìn)，不受歡迎的不進(jìn)，跟顧客多交流，顧客喜歡什么商品咱就進(jìn)什么，不斷改進(jìn)，最后一定會(huì)顧客盈門的。這時(shí)如果這個(gè)老板先做商業(yè)分析，客戶關(guān)系分析，消費(fèi)曲線分析....還沒開業(yè)呢，估計(jì)就破產(chǎn)了。另外，RUP和XP也不是非此即彼的關(guān)系，在造F-35的過程中，對(duì)整體飛機(jī)來說，用RUP是適合的，具體到發(fā)動(dòng)機(jī)的提供商，倒是大可XP一把，最終只要提供合格的發(fā)動(dòng)機(jī)就OK了。
題外話說了不少，書歸正傳。業(yè)務(wù)規(guī)則分類以后，就應(yīng)該按分類去調(diào)研了。
全局規(guī)則很難從用戶處調(diào)研得來，通常這方面是用戶的盲點(diǎn)。這主要是由有經(jīng)驗(yàn)的系統(tǒng)分析員，或架構(gòu)師以及客戶方的IT部門(如果有的話)，從業(yè)務(wù)特點(diǎn)、應(yīng)用環(huán)境、行業(yè)規(guī)定、法律規(guī)章等等方面去總結(jié)，再求得客戶方的認(rèn)可。
交互規(guī)則從用例場(chǎng)景而來，每一個(gè)場(chǎng)景，場(chǎng)景中每一個(gè)交互的過程可能都隱含著規(guī)則。這就需要與客戶多討論。請(qǐng)參考本系列文章的第3篇關(guān)于涉眾的討論，交互規(guī)則最主要的來源是業(yè)務(wù)提出者和業(yè)務(wù)管理者，最好不要去找業(yè)務(wù)執(zhí)行者。
內(nèi)稟規(guī)則是針對(duì)業(yè)務(wù)實(shí)體的，因此要對(duì)每個(gè)業(yè)務(wù)實(shí)體的屬性進(jìn)行羅列，并找出它們的規(guī)則。內(nèi)稟規(guī)則最主要的來源是業(yè)務(wù)執(zhí)行者，需求人員應(yīng)該更多的去與他們交流。
現(xiàn)在來談?wù)剺I(yè)務(wù)實(shí)體的屬性。業(yè)務(wù)實(shí)體的屬性在這個(gè)階段應(yīng)該用業(yè)務(wù)術(shù)語來描述，而非計(jì)算機(jī)術(shù)語。調(diào)研范圍是上一篇模型中得到的領(lǐng)域模型中的每一個(gè)實(shí)體，而屬性的原始來源是客戶的各類實(shí)際表單，以及在交流過程中客戶提出的各種要求。如果業(yè)務(wù)實(shí)體有狀態(tài)，并且是比較復(fù)雜的，那么在建模的時(shí)候應(yīng)該有一個(gè)狀態(tài)圖來說明。請(qǐng)參看本系統(tǒng)文章提供的建模實(shí)例中'圖書'業(yè)務(wù)實(shí)體下面的狀態(tài)圖。請(qǐng)讀者注意，在本文后面提供的例子中，業(yè)務(wù)實(shí)體描述看上去象是一張數(shù)據(jù)表，但它絕對(duì)不是數(shù)據(jù)表。它是對(duì)業(yè)務(wù)中實(shí)體屬性的業(yè)務(wù)角度描述。系統(tǒng)分析不是做設(shè)計(jì)，腦子里不要有任何關(guān)于設(shè)計(jì)或?qū)崿F(xiàn)方法的想法，這些想法會(huì)誤導(dǎo)你做出不適合的決定。你的職責(zé)是通過一個(gè)合理的模型完整的將業(yè)務(wù)描述出來，并求得客戶方的認(rèn)可。任何替客戶和架構(gòu)師，設(shè)計(jì)師甚至程序員“著想”的方法其實(shí)都是不恰當(dāng)?shù)摹?div style="height:15px;">
最后本文提供一個(gè)用例規(guī)約的例子，每個(gè)用例都應(yīng)該寫一份用例規(guī)約。本文提供的這個(gè)例子基本上來自RUP提供的模板，不過在實(shí)際工作中筆者做了些修改，供讀者參考。這個(gè)例子的藍(lán)本還是本系統(tǒng)文章一直在使用的網(wǎng)上圖書館的實(shí)例。
點(diǎn)這里下載用例規(guī)約例子，
點(diǎn)這里下載建模實(shí)例。到這里，需求過程差不多也該結(jié)束了。但是我們的確還有一些工作要做。如果讀者所工作的組織是用RUP來做需求的，而客戶方或者監(jiān)理方未必會(huì)對(duì)這種需求文檔表示滿意。他們會(huì)以國(guó)標(biāo)來要求你。同時(shí)，到目前為止，我們產(chǎn)生的成果都是一些分離的圖形和文檔，對(duì)于客戶來說，這的確是不好的文檔結(jié)構(gòu)。難道客戶的采購(gòu)清單里還需要包括Rational Rose，這樣才能閱讀你提供的需求文檔嗎？顯然這是不可能的，所以，給用戶提供的文檔還是以傳統(tǒng)的《需求規(guī)格說明書》為好。下一篇就討論一下如何將我們的分析成本集成到《需求規(guī)格說明書》中。順帶討論一下用例補(bǔ)充規(guī)約和系統(tǒng)原型的產(chǎn)生以及它的作用。敬請(qǐng)期待。 （8）--如何編寫一份完整的UML需求規(guī)格說明書
為了讓我們的需求更完美，這一篇所要做的工作也是必不可少的。這一篇將要討論到的內(nèi)容包括：用例補(bǔ)充規(guī)約，系統(tǒng)原型，以及需求規(guī)格說明書
終于到了快結(jié)束的時(shí)候了，這將是用例分析系列的最后一篇，結(jié)果是得到需求規(guī)格說明書，以結(jié)束需求分析的過程。經(jīng)過前面七篇的工作，我們從最初的業(yè)務(wù)用例獲取入手，獲得了業(yè)務(wù)用例模型，這是我們的業(yè)務(wù)范圍；經(jīng)過分析得到了業(yè)務(wù)場(chǎng)景，這是我們的業(yè)務(wù)藍(lán)圖；經(jīng)過規(guī)劃，得出用例實(shí)現(xiàn)視圖，這是我們的系統(tǒng)范圍；經(jīng)過再次分析，得到了用例實(shí)現(xiàn)以及領(lǐng)域模型，包括用例規(guī)約，業(yè)務(wù)規(guī)則和業(yè)務(wù)數(shù)據(jù)，這是我們的概念模型。僅從需求所需的必要元素來說，我們基本上已經(jīng)完成了需求分析的工作。誠(chéng)如上一篇結(jié)尾所說，為了讓我們的需求更完美，這一篇所要做的工作也是必不可少的。這一篇將要討論到的內(nèi)容包括：用例補(bǔ)充規(guī)約，系統(tǒng)原型，以及需求規(guī)格說明書
先說說用例補(bǔ)充規(guī)約。
之前我們得到的用例規(guī)約是功能性的，它們是針對(duì)Actor完成目標(biāo)業(yè)務(wù)所需的功能性Feature的描述。然而我們所面對(duì)的系統(tǒng)除了功能性的Feature之外，總有一些是與業(yè)務(wù)功能無關(guān)的，這部分需求就是補(bǔ)充規(guī)約要涉及的內(nèi)容。
什么樣的需求與業(yè)務(wù)功能無關(guān)呢？一般來說，就是系統(tǒng)需求，例如可靠性，可用性，擴(kuò)展性，易用性等等。用戶提出，系統(tǒng)必須提供7*24小時(shí)的服務(wù)，它應(yīng)該有一定隨業(yè)務(wù)變化而適應(yīng)的能力，系統(tǒng)的界面應(yīng)當(dāng)簡(jiǎn)單易學(xué)，具備基礎(chǔ)計(jì)算機(jī)知識(shí)的人可以不經(jīng)過培訓(xùn)就能使用它等等。這些需求與具體業(yè)務(wù)要求無關(guān)，哪怕一個(gè)不實(shí)現(xiàn)，系統(tǒng)也能Run起來。但是這些需求又是如此重要，它們是系統(tǒng)達(dá)到用戶期望必不可少的。甚至在用戶看來，某些補(bǔ)充規(guī)約要求比業(yè)務(wù)要求還重要，某個(gè)業(yè)務(wù)要求沒做好，用戶或許能寬容，如果你說系統(tǒng)不能提供7*24小時(shí)的服務(wù)，用戶肯定是不能接受的。這些需求，就是要在補(bǔ)充用例規(guī)約里面說明的內(nèi)容。
筆者自己有個(gè)習(xí)慣，在上一篇也有所提及，就是習(xí)慣于把全局規(guī)則也寫到補(bǔ)充用例規(guī)約里面。比如，用戶提出，所有系統(tǒng)使用者在系統(tǒng)中的任何操作，都要能夠記錄下來；如果數(shù)據(jù)被更改，不論是Modify,Add還是Delete，數(shù)據(jù)都要做一個(gè)備份；響應(yīng)時(shí)間可能超過1分鐘的功能，都要提供進(jìn)度條等等...這些全局規(guī)則在實(shí)際情況中，一般都是由系統(tǒng)框架，或某個(gè)中間件來完成的，它們是系統(tǒng)架構(gòu)的一部分。因此這些需求雖然也是功能性的，但筆者認(rèn)為將它們作為補(bǔ)充需求，與可靠性之類的系統(tǒng)需求一起，由較高層次的設(shè)計(jì)師或者是架構(gòu)師來處理它們更合適。
那么補(bǔ)充用例規(guī)約到底是一個(gè)用例寫一份還是全部集中在到一起呢？RUP提供的模板是一個(gè)用例寫一份，只要它們與該用例相關(guān)。筆者在實(shí)際工作中覺得集中在一份文檔中似乎更合理。一是減輕很多的重復(fù)工作量，二是集中在一起更便于管理和驗(yàn)證。
至于補(bǔ)充規(guī)約的格式就沒那么重要了，只要將用戶提出的，或者用戶未提出，但作為系統(tǒng)建設(shè)者知道系統(tǒng)要很好運(yùn)行就必須去加入的那些特性，都一一寫明白了，就OK了。當(dāng)然，有時(shí)某個(gè)補(bǔ)充要求的確只與一個(gè)特定的用例有關(guān)，例如交納借閱費(fèi)，有一個(gè)可能的補(bǔ)充要求是保障安全性，包括數(shù)據(jù)安全，傳輸安全。其它用例則沒有必要進(jìn)入安全通道。這時(shí)，專門為交納借閱費(fèi)用例寫一個(gè)補(bǔ)充規(guī)約也是合理并且推薦的方式。
再來說說系統(tǒng)原型。所謂系統(tǒng)原型根據(jù)目的不同，也分為好多種，本文無意深入探討，大致說說，并只描述與需求過程相關(guān)的原型。例如，我們可能要使用一個(gè)全新的技術(shù)，為了驗(yàn)證其技術(shù)可行性，可能會(huì)開發(fā)一個(gè)小的原型，以掌握或證明我們能夠使用這種技術(shù)，也證明這項(xiàng)技術(shù)能夠支持后續(xù)的開發(fā)，這是一種驗(yàn)證性原型；我們有一個(gè)初步的想法，但不知往下能走多遠(yuǎn)，這個(gè)想法是否可行，也可以開發(fā)一個(gè)原型，這是一種探索型原型；我們要向別人說明某個(gè)產(chǎn)品，為了形象化，也可以開發(fā)一個(gè)原型，以顯式的向別人展示以加深理解，這是一種輔助原型...目的不同，原型也有多種。另一種分類方法是將原型分為拋棄型的和漸進(jìn)型的，所謂拋棄，就是用完了就扔了，漸進(jìn)型的，則是將來會(huì)在它基礎(chǔ)上逐步完善，乃至形成最終系統(tǒng)。
我們?cè)谧鲂枨髸r(shí)所需的原型主要是輔助性的，將用例場(chǎng)景轉(zhuǎn)化成可操作的原型，如果是做Web系統(tǒng)，則基本上就是靜態(tài)html。第一，它能幫助系統(tǒng)分析員更好的與用戶交流，同時(shí)讓腦子湖涂的用戶明白，哦，原來就是這樣的啊......第二，這個(gè)原型能幫助用戶深化需求，憑空想象用戶很難提出具體而清晰的需求，當(dāng)面對(duì)一個(gè)可以操作的界面時(shí)，往往文思泉涌。第三，這個(gè)原型能幫助系統(tǒng)分析員驗(yàn)證需求分析的結(jié)果，如果將用例場(chǎng)景的文字描述轉(zhuǎn)化成界面以后難以操作，那就得回頭修改用例場(chǎng)景了。
那么需求的系統(tǒng)原型是拋棄型的還是漸進(jìn)型的呢？不一定。有的組織有快速頁面生成工具，能很快的將需求轉(zhuǎn)化成界面，這些界面簡(jiǎn)單，不能滿足開發(fā)要求，需求結(jié)束后往往被拋棄；有的組織為了在需求過程中將用戶Look and Feel的需求也一并收集，會(huì)精心開發(fā)界面原型，這些界面就成為將來的開發(fā)基礎(chǔ)。的確大部分組織是將html開發(fā)完成后，由程序員填入動(dòng)態(tài)代碼而形成ASP,JSP等動(dòng)態(tài)網(wǎng)頁的。
系統(tǒng)原型什么時(shí)候需要呢？雖然本系列文章到最后才來討論它，但筆者的建議是從一開始就要開始原型的制作。很多人抱怨需求難做，用戶講不清又說不明，今天說的跟明天不一樣，抱怨用戶根本不懂計(jì)算機(jī)。有此抱怨是正常的，需求從來就不是容易的，但如果以這為借口而做不出好的需求，那就只能說明你不 是一個(gè)合格的系統(tǒng)分析員了。用戶如果都懂計(jì)算機(jī)，還要你做什么？還好意思拿著"高薪"，號(hào)稱"高新技術(shù)人才"么？把用戶想說又說不出來，或者根本不想說的東西套出來，這就是系統(tǒng)分析員的職責(zé)。原型在這里將起到巨大的幫助作用，一個(gè)圖形化的展示勝過千言萬語，UML的誕生也是這個(gè)原因。在需求的初始階段，界面原型或許還開發(fā)不出來，但是，用Word,Visio,Powpoint畫幾個(gè)簡(jiǎn)單的圖示不困難吧？甚至在草稿紙上手工畫畫界面原型，也會(huì)對(duì)你跟用戶的交流起到巨大的作用。
我們的所有準(zhǔn)備工作都完成了，即將交出工作成果--需求規(guī)格說明書。有的讀者會(huì)奇怪，之前我們做的工作不都是需求說明嗎？怎么又來一個(gè)需求規(guī)格說明書？原因是這樣，我們之前的工作的確都是需求說明，但是，這些需求說明是零散的，組織不好的。就拿筆者給大家提供的實(shí)例來說，讀者在看的時(shí)候感覺如何？沒有章節(jié)，沒有提綱，也看不出作者的組織思路，要看明白一個(gè)需求，要點(diǎn)好幾個(gè)圖，展開好幾層。對(duì)系統(tǒng)分析員來說不是什么問題，但對(duì)用戶而言呢？你能指望他們滿意這樣的文檔而讓你驗(yàn)收通過嗎？另一個(gè)原因是，現(xiàn)在系統(tǒng)建設(shè)一般都會(huì)按照國(guó)標(biāo)來要求文檔提供，例如GB9385-88，尤其請(qǐng)了監(jiān)理的用戶更是如此。因此，寫一份符合國(guó)標(biāo)格式要求的需求文檔是非常有必要的。
不必?fù)?dān)心需求規(guī)格說明書會(huì)給你帶來多大的工作量，其實(shí)所有的元素已經(jīng)具備，需要做的工作不過是將這些元素組織到一起而已。筆者提供一個(gè)簡(jiǎn)單的例子以說明如何將他們組織起來。但這個(gè)例子并不是說明這是一個(gè)標(biāo)準(zhǔn)格式，你應(yīng)當(dāng)根據(jù)組織規(guī)范，用戶要求來組織這些元素。筆者想說明的只是一個(gè)組織文檔的思路和哪些元素是必須的以供參考。
最后需要說明的一點(diǎn)是，在這個(gè)例子里，分了用戶需求和系統(tǒng)需求兩個(gè)部分，這對(duì)應(yīng)著業(yè)務(wù)用例和用例實(shí)現(xiàn)。用戶需求不一定是系統(tǒng)需求，某些用戶需求是不必實(shí)現(xiàn)到系統(tǒng)中的，例如本系列文章示例中的圖遞送過程，缺了它用戶需求就不完整，但實(shí)際上這是一個(gè)人工過程，不需計(jì)算機(jī)的參與；同時(shí)用戶需求也未必全部包含系統(tǒng)需求，例如用戶需求中未提及事務(wù)處理，操作記錄，但作為一個(gè)健壯的系統(tǒng)，這些需求又是必不可少的。
后記...
前后經(jīng)過大半年，關(guān)于系統(tǒng)分析員用例分析的文章到這里就結(jié)束了。期間承蒙網(wǎng)友們的支持與鼓勵(lì)，才走到今天。系統(tǒng)分析和UML是一個(gè)龐大的話題，短短的八篇文章僅能夠揭起冰山一角。實(shí)踐比理論學(xué)習(xí)能更快的成長(zhǎng)。就筆者自己而言，若要論及理論知識(shí)，未必及得上科班出身的系統(tǒng)分析員們。只是實(shí)踐多了，就有些經(jīng)驗(yàn)積累下來，以至能與諸位分享。筆者相信，理論--實(shí)踐--理論，永遠(yuǎn)是一條不二的成長(zhǎng)途徑。只要本系列文章對(duì)大家還有些幫助，就不枉這半年多的筆耕了。
筆者不寄望于能在這短短八篇文章里將所有知識(shí)和經(jīng)驗(yàn)都講到，也不保證有需要的讀者一定能在這里找到答案。但筆者的Blog還在，也還沒有從此收山的打算，只是這一系列文章到了該結(jié)束的時(shí)候了。若讀者有疑問，有指教，都可以在我的BLog里留言，以武會(huì)友就是專門為大家準(zhǔn)備的。筆者保證每條留言都會(huì)回復(fù)的。謝謝大家。
作者coffeewoo 歡迎您訪問文章原始出處 :
http://coffeewoo.itpub.net ，閱讀中有任何問題可以在BLOG上留言或發(fā)郵件到 coffeewoo@263.net，我將盡力為您解答。具有代表性的問題我會(huì)以 Q &A的形式收錄到對(duì)應(yīng)的文章之后。希望本系列文章對(duì)您有幫助。歡迎轉(zhuǎn)載，敬請(qǐng)注明，謝謝 ^_^
