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