http://www.uml.org.cn/appCase/20004120701.htm
本文介紹了一個(gè)真實(shí)的范例，然后討論了在把用例用來(lái)定義實(shí)時(shí)系統(tǒng)的規(guī)格時(shí)遇到的問(wèn)題，以及相關(guān)的經(jīng)驗(yàn)學(xué)習(xí)。
概述
本文基于我去年為客戶開(kāi)發(fā)一個(gè)實(shí)時(shí)控制系統(tǒng)的工作。
本文的目標(biāo)是：第一，重點(diǎn)描述實(shí)時(shí)系統(tǒng)規(guī)格的確定和用例之間的關(guān)系；第二，描述我們?nèi)绾伍_(kāi)發(fā)用例模型以及應(yīng)用用例給我們帶來(lái)了哪些益處。
要說(shuō)明的第一件事情是為什么我們需要類似這樣的一篇文章，然后我們?cè)僬f(shuō)明用用例來(lái)描述實(shí)時(shí)系統(tǒng)有哪些特殊之處。
在敘述為什么需要本文之后，我將描述一個(gè)具體項(xiàng)目和它的用例模型。我將重點(diǎn)描述用例模型的一些有趣的和有意義的特性，然后看看它們是如何有益于項(xiàng)目的。最后，我將討論一些經(jīng)驗(yàn)學(xué)習(xí)，并給出一些建議。
為什么我們需要這篇文章？
有一種看法認(rèn)為用例只對(duì)你描述高度交互的系統(tǒng)有用，這些系統(tǒng)以IT系統(tǒng)為代表，如銀行系統(tǒng)。例如，在銀行中你可能需要處理一個(gè)抵押應(yīng)用，它會(huì)有大量的用戶交互。對(duì)于實(shí)時(shí)系統(tǒng)來(lái)說(shuō)，并不存在那么多的用戶交互。但是，如果實(shí)時(shí)系統(tǒng)具有有意義的外部可視的行為，用用例描述仍然對(duì)定義它們的規(guī)格是有用的，即使在一些用例中用戶只是選擇一些設(shè)置以及告訴系統(tǒng)完成一些功能。
在為客戶工作了這么多年來(lái)，我發(fā)現(xiàn)用例被廣泛地誤解。盡管有很多與之相關(guān)的書籍、文章和培訓(xùn)課程。可能這些書籍、文章和培訓(xùn)課程都只關(guān)注于問(wèn)題，因此它們提供大量的不同的方法。在這些著作中經(jīng)常提到的一個(gè)例子是自動(dòng)柜員機(jī)(ATM)。類似這樣的例子對(duì)于說(shuō)明一些問(wèn)題是有用的，但在處理很大而且很復(fù)雜的實(shí)際系統(tǒng)時(shí)卻通常沒(méi)有明顯的幫助。在實(shí)時(shí)系統(tǒng)中你將怎樣處理出現(xiàn)的問(wèn)題？有一些實(shí)際的例子可以對(duì)你有所幫助，本文恰恰可以給你提供這樣一個(gè)實(shí)際的例子。
什么是實(shí)時(shí)系統(tǒng)的特點(diǎn)？
實(shí)時(shí)系統(tǒng)就是時(shí)間是最關(guān)鍵因素的系統(tǒng)。如果一個(gè)系統(tǒng)不理會(huì)它的時(shí)間需求，將可能導(dǎo)致生命危險(xiǎn)，例如造成飛機(jī)失事。簡(jiǎn)單來(lái)說(shuō)，對(duì)于這樣的系統(tǒng)，對(duì)于時(shí)間需求處理的失敗將可能導(dǎo)致產(chǎn)品的損害和上百萬(wàn)美元的損失。
實(shí)時(shí)系統(tǒng)也有最小限度的用戶交互，對(duì)于這類系統(tǒng)怎么樣定義它的用例是一件值得考慮的事情。實(shí)時(shí)系統(tǒng)通常都是高度算法化的，用例可能并不是最好的描述算法的文檔方法。典型地，一個(gè)用例將引用在其它地方描述的算法。
如果你的系統(tǒng)具有有效的外部可視行為，那么用例能夠極大地幫助你文檔化你的系統(tǒng)需求。下面我描述的系統(tǒng)就有大量外部可視行為。在IT系統(tǒng)中應(yīng)用用例的規(guī)則在這里仍然適用。
產(chǎn)品傳送系統(tǒng)(PT)項(xiàng)目
用戶是一個(gè)全球最大的鐵礦生產(chǎn)商，它在澳大利亞西北的Headland港擁有一套鐵礦傳送工廠。鐵礦從傳送帶網(wǎng)絡(luò)傳送到火車車廂，然后分類，稱重，保存在倉(cāng)庫(kù)。最后鐵礦從倉(cāng)庫(kù)中運(yùn)出，再通過(guò)傳送帶運(yùn)送到船上。
這個(gè)系統(tǒng)中每個(gè)東西都很大。有的傳送帶有7公里長(zhǎng)，需要15分鐘才能啟動(dòng)。運(yùn)行傳送帶網(wǎng)絡(luò)需要一個(gè)復(fù)雜的控制系統(tǒng)。對(duì)控制系統(tǒng)的一個(gè)需求是減少運(yùn)行系統(tǒng)需要的人數(shù)。另一個(gè)需求是降低對(duì)運(yùn)行系統(tǒng)的人的培訓(xùn)需求。圖1是工廠的航拍圖。
圖1： Hedland港工廠的航拍圖
在左上角有一個(gè)船泊位。你可以看到有鐵路線從右邊連過(guò)去。卸貨場(chǎng)在接近于中間的垂直線附近。在這個(gè)線的頂端是粉碎機(jī)。你可以在北面和南面的院子里看到倉(cāng)庫(kù)。傳送帶運(yùn)行在卸貨場(chǎng)和粉碎機(jī)，以及粉碎機(jī)和倉(cāng)庫(kù)之間。 你可以看到運(yùn)輸機(jī)從倉(cāng)庫(kù)裝上鐵礦，把它運(yùn)到船上。運(yùn)輸機(jī)的容量非常大。在這個(gè)系統(tǒng)中，傳送帶可以在一小時(shí)內(nèi)傳送10000噸的鐵礦！
有一些能夠增加系統(tǒng)復(fù)雜度的需求非常值得關(guān)注。控制系統(tǒng)在避免溢出的情況下要達(dá)到最大的生產(chǎn)能力。出口容量在2004年從每年67M（百萬(wàn)）噸增加到81M噸，到2011年將擴(kuò)大到90M噸。
基本概念：作業(yè)(route)
一個(gè)作業(yè)(route)由一系列傳送帶、定位和反饋設(shè)備組成，這些設(shè)備被選擇和調(diào)配以便把鐵礦從源位置運(yùn)送到目標(biāo)位置。作業(yè)可以是單獨(dú)的，也可以共享設(shè)備以便允許把鐵礦分開(kāi)運(yùn)輸，從一個(gè)源位置運(yùn)送到多個(gè)目標(biāo)位置，或者組合運(yùn)輸，從多個(gè)源位置運(yùn)送到一個(gè)目標(biāo)位置。這些作業(yè)由操作員創(chuàng)建、維護(hù)和刪除。一旦操作員啟動(dòng)作業(yè)，系統(tǒng)就開(kāi)始工作，按照正確的順序啟動(dòng)每個(gè)工作，以及處理一些異常狀態(tài)例如有不合適的產(chǎn)品已經(jīng)在傳送帶上。
為了達(dá)到生產(chǎn)力的需求，控制系統(tǒng)采用激進(jìn)的啟動(dòng)和錯(cuò)誤處理策略。盡管已經(jīng)存在的系統(tǒng)在一個(gè)時(shí)間點(diǎn)一個(gè)作業(yè)只能啟動(dòng)一條傳送帶，當(dāng)它達(dá)到最大速度后，再啟動(dòng)下一條，依此類推。 新的控制系統(tǒng)在一個(gè)作業(yè)中將同時(shí)啟動(dòng)所有的傳送帶－－注意我們的傳送帶的長(zhǎng)度不同，啟動(dòng)時(shí)間和容量也不同。在出現(xiàn)問(wèn)題時(shí)，新的系統(tǒng)試圖盡可能關(guān)閉最少數(shù)量的設(shè)備以避免溢出，因?yàn)閱?dòng)一個(gè)長(zhǎng)的傳送帶需要15分鐘。無(wú)論什么可能情況，設(shè)備都將保持運(yùn)行，直到鐵礦有可能溢出為止。系統(tǒng)需要同時(shí)運(yùn)行作業(yè)，以便礦石能夠傳送到多個(gè)目標(biāo)位置或者把礦石從多個(gè)源位置組合到一個(gè)位置。
設(shè)備失敗的處理是全自動(dòng)的。當(dāng)一個(gè)傳送帶一小時(shí)可以傳送超過(guò)10000噸礦石時(shí)，你可以想象出現(xiàn)問(wèn)題時(shí)不能很快停下傳送帶的后果。這個(gè)結(jié)果并不是你可以用獨(dú)輪車能夠清理干凈的！你將不得不使用一些重型設(shè)備來(lái)清理那些溢出的礦石，而且需要花費(fèi)很長(zhǎng)的時(shí)間。甚至有更壞的結(jié)果，比如一個(gè)錯(cuò)誤導(dǎo)致礦石已經(jīng)倒進(jìn)了船的甲板上。
PT系統(tǒng)的用例模型
本文的工作基于IBM(r) Rational Unified Process(r) (RUP(r))和一本名為“用例建模”的書，這本書由Kurt Bittner和Ian Spence合著。用例是一個(gè)可供選擇的寫需求的方法。在過(guò)去，我們基于一個(gè)詞"shall"來(lái)書寫這些聲明。在幾年前我曾經(jīng)在一個(gè)國(guó)防項(xiàng)目工作，它包括22卷需求文檔，沒(méi)有人能夠真正全部理解它們。確認(rèn)所有的需求描述是正確的和一致的是一件非常困難的事情。用例可以幫助我們處理這類問(wèn)題。用例把需求放在系統(tǒng)提供給用戶和有關(guān)人員的上下文中。 按照順序描述每個(gè)用例以消除上下文的冗余，這些冗余在用傳統(tǒng)的基于"shall"的需求描述方法中是必然包括的。
這里僅僅描述用例模型的一些特點(diǎn)，因?yàn)槿磕Ｐ吞螅蔡珡?fù)雜。用例的規(guī)范非常長(zhǎng)，也非常細(xì)致。
識(shí)別角色(actor)
在整個(gè)操作開(kāi)始前主要工作集中在識(shí)別角色是非常重要的，因?yàn)樗梢源_定系統(tǒng)的邊界，清楚地指示哪些是在系統(tǒng)范圍內(nèi)，哪些在系統(tǒng)范圍外。我們不想開(kāi)發(fā)那些我們沒(méi)有必要付錢的東西。在PT系統(tǒng)中，運(yùn)輸機(jī)是一個(gè)我們需要交互的系統(tǒng)。這里我們只需要知道運(yùn)輸機(jī)干什么工作，并不需要控制它如何工作，我們也不需要修改它。既然我們不控制運(yùn)輸機(jī)，它就在我們的系統(tǒng)范圍之外，作為一個(gè)角色模型存在。我們有Ship-Hatch Loaders, Stackers, Sampling Stations 和Dust Control Systems - 所有這些外部系統(tǒng)都作為角色模型。圖2顯示部分這個(gè)系統(tǒng)的角色。
圖 2: PT系統(tǒng)角色
在圖2中，角色使用UML 包分組。在左邊是角色包。最重要的一個(gè)在左上角。CRO 就是Control Room Operator，中央控制室操作員。其它重要的還有在左下角的RSMT(Root System Maintenance Technician，根系統(tǒng)維護(hù)技術(shù)員)。
其它的包包括所有不同的設(shè)備角色。一些用例提到我們管理的通用設(shè)備，另一些將提到特定的不同類型的設(shè)備。
在圖的下方有一些與我們交互的外部設(shè)備。左邊的一個(gè)是PMAC，一個(gè)已經(jīng)存在的系統(tǒng)用來(lái)處理我們的用戶界面。如果它僅僅是與我們的系統(tǒng)相關(guān)的用戶界面，那么我們不需要把它看作角色，因?yàn)閷?shí)際上角色是CRO。但是它實(shí)際上是我們相關(guān)的角色，因?yàn)槲覀兘o它傳遞信息，并且從它那里收集信息。
電力負(fù)荷管理系統(tǒng)Power Load Management System (PLMS)是值得關(guān)注的。在Headland港，港口工廠有自己的電站。當(dāng)你啟動(dòng)7KM長(zhǎng)的傳送帶，并在上面運(yùn)行數(shù)千噸的礦石是，它需要大量的電力供應(yīng)。因此，傳送帶的啟動(dòng)實(shí)際上是錯(cuò)開(kāi)的，以便降低電站的負(fù)荷。只要你想啟動(dòng)傳送帶，PT系統(tǒng)都將詢問(wèn)電站并得到電站的許可。
確定用例
用例是一種簡(jiǎn)單的可選擇的定義需求的方法。首先，讓我們?cè)俅位仡櫼幌掠美亩x：
用例定義一個(gè)由系統(tǒng)完成的操作序列，它給操作者和相關(guān)人員提供可觀察到的有價(jià)值的結(jié)果。
在識(shí)別IT系統(tǒng)的用例時(shí)，牢記“可觀察到的有價(jià)值的結(jié)果”是非常重要的，這一點(diǎn)在這里仍然適用。我們將看到系統(tǒng)提供給操作者和相關(guān)人員的值。在我們的例子中，中央控制室操作員是一個(gè)角色，但是整個(gè)公司實(shí)際上都可以看到系統(tǒng)把礦石從一個(gè)地方移動(dòng)到另外的地方。“由系統(tǒng)完成的操作序列”聲明了在用例中系統(tǒng)怎么做的描述。這些每個(gè)都是我們系統(tǒng)的需求。最后，用例是一個(gè)完整的有意義的事件流。把“完整的有意義的事件流”和“可觀察到的有價(jià)值的結(jié)果”這兩個(gè)概念組合起來(lái)可以幫助避免識(shí)別出不完整的功能片斷并把它稱為用例。
用例和角色在用例圖中以圖形化的方式描述。圖3顯示了 PT系統(tǒng)的頂層用例圖。你很快就能看到 PT系統(tǒng)的用例分為4組：Operation, Administration, Configuration 和System Startup。
圖 3: 頂層用例圖
PT系統(tǒng)中用例相關(guān)的操作在圖4中顯示:
圖 4: PT系統(tǒng)的用例
PT的主要用例是“傳送產(chǎn)品”。正如這個(gè)用例的名字那樣，你可以看到在這里系統(tǒng)提供給用戶和有關(guān)人員的價(jià)值是把產(chǎn)品從一個(gè)地方運(yùn)送到另一個(gè)地方的能力。這個(gè)軟件也能夠用來(lái)運(yùn)送其它物品，不僅僅是鐵礦。例如它能夠用來(lái)在制藥廠傳送藥片。傳送產(chǎn)品是一個(gè)很大的用例，但它抓住了最根本的因素，即我們的系統(tǒng)存在的原因，即給我們的操作者和相關(guān)人員提供的價(jià)值。
在圖4中我們看到與電源管理系統(tǒng)(PLMS)的交互，請(qǐng)求啟動(dòng)設(shè)備，我們也看到了用例與我們控制的設(shè)備的交互。我們可以顯示每個(gè)設(shè)備角色，但那樣的話，圖就顯得太混亂了。
在圖4中，從CRO到傳送產(chǎn)品的箭頭，表示這個(gè)操作員發(fā)起或者啟動(dòng)這個(gè)用例。用例到設(shè)備和PLMS操作者的箭頭表示這個(gè)用例或者系統(tǒng)與設(shè)備和PLMS交談。從船艙裝載系統(tǒng)(SHLS)的箭頭表示SHLS發(fā)起與系統(tǒng)的交互－－特別地，SHLS可以請(qǐng)求鐵礦流暫時(shí)中斷以便裝載機(jī)移動(dòng)到另一個(gè)艙室。
有關(guān)管理、配置和系統(tǒng)啟動(dòng)的用例在圖5中描述。
圖 5: 有關(guān)管理、配置和啟動(dòng)的用例
在這里我們可以做的一件事情是在對(duì)系統(tǒng)的操作影響最小的情況下更新系統(tǒng)軟件。因此我們有"Perform Software Upgrade" 用例。我們也有"Start System" 用例 -這個(gè)用例經(jīng)常被忘掉。系統(tǒng)有人身安全優(yōu)先的規(guī)則，Start System 用例包括在系統(tǒng)啟動(dòng)時(shí)進(jìn)行的所有安全檢查的規(guī)格說(shuō)明。你一定不想在服務(wù)人員在傳送帶上工作時(shí)偶然地啟動(dòng)它！
Route System Maintenance Technologist (RSMT)是一個(gè)負(fù)責(zé)創(chuàng)建作業(yè)或者預(yù)定義作業(yè)的人，預(yù)定義的作業(yè)稍后由CRO使用。我們可以在系統(tǒng)中添加新的設(shè)備，定義新設(shè)備的種類以及定義系統(tǒng)傳送產(chǎn)品的特點(diǎn)。港口工廠處理來(lái)自不同礦山的不同類型的鐵礦，它們有不同的顆粒大小、不同的礦石成分等級(jí)。我們要非常小心的一件事情是避免把錯(cuò)誤的礦石裝到船上去。
關(guān)于用例圖這里要警告一下：用例圖只是冰山的一角。直到你開(kāi)始寫用例規(guī)格之前不要去重新分解、重組和調(diào)整用例模型。用例的規(guī)格大約95％來(lái)自用例模型。用例圖僅僅給你一個(gè)模型的總體、全面的概要描述。
正如我前面提到的，用例描述“事件流”。圖6顯示不同種類的事件流和它們是如何在用例規(guī)格中描述的。
圖 6:主事件流和分支流
從頂部到底端底藍(lán)色粗線條表示主事件流(Basic Flow)。它表示每件事情都按照正確的方式發(fā)生。有很多種分支流(Alternate Flow)。描述處理設(shè)備故障的分支是一個(gè)很好的分支流的例子。另一個(gè)例子是描述操作員取消了前面請(qǐng)求的動(dòng)作。
這里一個(gè)非常重要的結(jié)構(gòu)是子事件流(Subflow)。子事件流就象子程序調(diào)用。我們?cè)噲D保持主事件流簡(jiǎn)單易讀，沒(méi)有子事件流是很難做到這一點(diǎn)的。例如，我們使用子事件流來(lái)描述我們啟動(dòng)或者安放設(shè)備位置時(shí)發(fā)生的細(xì)節(jié)。這些過(guò)程每個(gè)都相當(dāng)復(fù)雜，如果我們都在主事件流上描述，那么它將變得很長(zhǎng)并且很難理解。
圖7顯示一個(gè)主事件流的片斷：
圖 7: 描述啟動(dòng)一個(gè)作業(yè)的主事件流示例
在第二步，系統(tǒng)檢查作業(yè)是否有效。如果系統(tǒng)確認(rèn)作業(yè)無(wú)效時(shí)會(huì)發(fā)生什么？這在分支流中描述。在用例規(guī)格中我們使用腳注來(lái)指示分支流，腳注文本包括指向相關(guān)文檔章節(jié)的交叉引用。這將減少描述事件流的混亂，使得它更容易讀。在這里我使用 "§" 符號(hào)指示存在一個(gè)分支流。我也用高亮的紅色表示這是項(xiàng)目術(shù)語(yǔ)表－－一份很重要的文檔－－中的定義。
在第3步，系統(tǒng)檢查選擇的作業(yè)的啟動(dòng)策略。"Starting/Positioning Stragegy 2.1"表示交錯(cuò)啟動(dòng)，它需要在啟動(dòng)作業(yè)前所有的設(shè)備都到位。這個(gè)啟動(dòng)策略在分支流中描述。最后系統(tǒng)向PLMS詢問(wèn)是否允許啟動(dòng)作業(yè)。如果不允許時(shí)發(fā)生的事情也在分支流中描述。
在圖8中，我們將看到分支流和子事件流的例子。
圖 8: 分支流和子事件流示例
分支流定義當(dāng)基于某種原因設(shè)備不到位，因而這個(gè)作業(yè)不能啟動(dòng)時(shí)應(yīng)該發(fā)生什么。系統(tǒng)給操作者發(fā)一個(gè)消息，建議在我們實(shí)際啟動(dòng)作業(yè)前把設(shè)備移動(dòng)到相應(yīng)的位置。在這個(gè)點(diǎn)上，用例就結(jié)束了。
子事件流的例子提供我們實(shí)際上如何啟動(dòng)作業(yè)的更詳細(xì)的信息。系統(tǒng)檢查全部作業(yè)設(shè)備是否暢通（傳送帶上沒(méi)有其它物品）。如果正常，系統(tǒng)同時(shí)移動(dòng)所有需要定位的設(shè)備到相應(yīng)的位置，包括作業(yè)自己需要的設(shè)備和要與其它作業(yè)共享的設(shè)備，然后我們交錯(cuò)啟動(dòng)所有的設(shè)備以避免電力過(guò)載。當(dāng)全部設(shè)備都運(yùn)行起來(lái)后，我們告訴操作員作業(yè)已經(jīng)啟動(dòng)，然后用例結(jié)束。第16步的 "a", "b" 和 "c" 也涉及了子事件流。
特殊需求
有很多需求，特別在實(shí)時(shí)系統(tǒng)中，不能歸結(jié)到用例的事件流中。通常它們是非功能需求如性能、可用性等等。那些與給定用例相關(guān)的特殊需求可以歸結(jié)到與用例規(guī)格定義相關(guān)聯(lián)的"特殊需求"一節(jié)中。有時(shí)為了方便，甚至功能需求也可以放到這一節(jié)中。圖9即為一個(gè)示例。
圖 9: 特殊需求
第一個(gè)例子可以作為一個(gè)分支流，但是為了使主事件流基于閱讀，我們可以簡(jiǎn)單地說(shuō)：“系統(tǒng)檢查是否有特殊需求的xyz節(jié)中規(guī)定的不能啟動(dòng)的狀況發(fā)生”。在這個(gè)特定用例中，如果我們?cè)诖a頭傳送帶上還有東西，而傳送帶由于完成了往甲板上卸礦石已經(jīng)停止工作，那么我們將給操作員發(fā)出一個(gè)警告。
第二個(gè)例子是一個(gè)算法的詳細(xì)描述，這個(gè)算法用來(lái)調(diào)整傳送帶的傳輸量和傳送速度。這里，主事件流可以簡(jiǎn)單地描述：“傳輸量和傳送速度按照特殊需求中的uvw節(jié)進(jìn)行調(diào)整。”
結(jié)構(gòu)化用例
用例的結(jié)構(gòu)化是一個(gè)高級(jí)課題。你也可以不使用這項(xiàng)技術(shù)來(lái)完成一個(gè)系統(tǒng)的需求文檔。用例的結(jié)構(gòu)化可以讓你避免冗余信息，保證用例文本只存在一個(gè)單獨(dú)的可維護(hù)的位置。關(guān)于結(jié)構(gòu)化的重要的一點(diǎn)是，你必須避免讓用例模型和用例變得難以理解。
結(jié)構(gòu)化技術(shù)在圖10中顯示。
圖 10: 結(jié)構(gòu)化用例
在圖的左邊，我們有一個(gè)用例，它有一個(gè)主事件流，一個(gè)分支流和一個(gè)子事件流。子事件流和分支流都可以作為單獨(dú)的用例分出來(lái)。分支流變成一個(gè)新的用例，擴(kuò)展了原始的用例。子事件流也變成一個(gè)新的用例，它包含在原始的用例中。一般來(lái)說(shuō)，包含關(guān)系僅僅用于一個(gè)分支流共用于多個(gè)用例的情況。這就是我們?nèi)绾未_保僅僅寫一個(gè)分支流，僅僅有一個(gè)維護(hù)地點(diǎn)的方法。通常，當(dāng)需要在已經(jīng)存在的用例上增加新功能而且你又不想修改原始用例時(shí)，可以創(chuàng)建一個(gè)擴(kuò)展流
把這些結(jié)構(gòu)化技術(shù)用到我們的產(chǎn)品傳送系統(tǒng)后，改變后的用例如圖11所示：
圖 11: 用例模型的修改
這些新的用例稱為“抽象用例”，因?yàn)樗鼈儧](méi)有操作者，你不能直接調(diào)用它們。如果我把這些抽象用例隱藏起來(lái)，你仍然可以相當(dāng)清楚地看到系統(tǒng)的主要功能。
一系列的錯(cuò)誤處理用例都以這樣的聲明開(kāi)始：“當(dāng)系統(tǒng)檢測(cè)到設(shè)備故障”或者“當(dāng)系統(tǒng)檢測(cè)到超載”等。然后用例繼續(xù)描述系統(tǒng)在這些情況的響應(yīng)。
在圖11的頂部，我提煉出了兩個(gè)抽象用例：一個(gè)是啟動(dòng)作業(yè)，另一個(gè)是停止作業(yè)。從技術(shù)角度來(lái)說(shuō)，我在這里破壞了規(guī)則：包含用例應(yīng)當(dāng)被多于一個(gè)的用例共享。我之所以這么做是因?yàn)椋绻以凇皞魉彤a(chǎn)品”用例中寫出所有的內(nèi)容，文檔將超過(guò)300頁(yè)。把它分開(kāi)可以讓很多人同時(shí)在系統(tǒng)的不同部分描述需求。
補(bǔ)充需求
我們有很多補(bǔ)充的需求，它們不適合放在任何用例中。因?yàn)樘囟ǖ男枨笈c具體的用例相關(guān)，這些都是典型的非功能性需求。在你在用例中的需求和補(bǔ)充的需求之間存在一個(gè)平衡。當(dāng)你進(jìn)行實(shí)時(shí)系統(tǒng)工作時(shí)，你可能發(fā)現(xiàn)會(huì)比你進(jìn)行IT系統(tǒng)開(kāi)發(fā)時(shí)有更多的補(bǔ)充需求。這是由于在實(shí)時(shí)系統(tǒng)中有更多的有時(shí)間要求的需求，它們都在補(bǔ)充需求中描述。
下面是放在補(bǔ)充需求中的非功能需求的例子：
- The PT System shall, upon notification of fault requiring upstream interlocks to be set to "False", set Upstream interlocks to False within 0.60 second.
- The PT System annual Availability (refer Glossary) shall exceed 99.954%.
- The PT System Maintenance Procedures shall comply with the Client's maintenance strategy for real-time PLC control systems.
- The PT System shall use the existing PMAC System for the CRO, PCO, and viewer interface.
- The portion of the PT System controlling route interlocking and directly connected to route equipment and interconnected systems shall be PLC based and, in the event of failure of higher level control within the PT System, shall be capable of safely operating any route currently starting, running, or stopping.
功能需求也可以包括在補(bǔ)充需求中。當(dāng)有些功能用用例寫還不如用補(bǔ)充需求描述時(shí)，可以把這些需求放在補(bǔ)充需求中，而不用寫一個(gè)完整地用例規(guī)格定義。下面是一些這樣的例子:
- The System shall advise the Operator if the sum of the source feed setpoints for a route is more than 10% less than the minimum capacity for the route.
- If a feed source has been enabled for a route with a cleanup destination, the System shall:
- Raise an alarm
- Re-raise the alarm every 10 minutes while the condition persists
- If during a ship hatch change, burden is on the wharf conveyor at or within the gross stopping distance of the shiploader, the System shall:
- Raise an alarm
- Issue a message to the operator
- Stop the wharf conveyor
- Issue a request to the SHLS to stop the shiploader boom conveyor
用例的益處
用例有以下益處：
- 給出需求的上下文，清楚顯示為什么需要系統(tǒng)。
- 把需求按照時(shí)間順序排列，使需求比傳統(tǒng)方式更加容易讀，更容易理解。
- 更容易得到客戶的認(rèn)同，因?yàn)樗麄兡芨菀椎亻喿x和理解。
- 可以用作項(xiàng)目計(jì)劃、分析、設(shè)計(jì)、測(cè)試和文檔的基礎(chǔ)。
另一方面，關(guān)于用例有很多不正確的觀點(diǎn)。第一個(gè)是，象當(dāng)前多種書籍和文章中指出的，傳統(tǒng)的書寫需求的方法能夠更嚴(yán)謹(jǐn)和精確。實(shí)際上并不是這樣的，我們?cè)谶@個(gè)項(xiàng)目中也能寫出非常嚴(yán)謹(jǐn)而精確的用例。
另一個(gè)看法是任何沒(méi)有經(jīng)過(guò)專業(yè)培訓(xùn)的人都可以寫用例。寫傳統(tǒng)需求文檔的原則在這里仍然適用。你需要從外部視角來(lái)看系統(tǒng)做什么。你不需要寫出系統(tǒng)是怎樣做的。象傳統(tǒng)的需求一樣，你寫的用例需求也應(yīng)該是可測(cè)試的。新手經(jīng)常繼續(xù)使用老的諸如功能分解的習(xí)慣。有開(kāi)發(fā)背景的人經(jīng)常傾向于從系統(tǒng)內(nèi)部而不是用外部視角描述。
用例貫穿整個(gè)項(xiàng)目
我前面提到，用例在整個(gè)項(xiàng)目中都有用。
項(xiàng)目計(jì)劃
在這里我們沒(méi)有足夠的空間討論分配用例迭代的準(zhǔn)則。只能簡(jiǎn)單說(shuō)，這些準(zhǔn)則基于RUP的風(fēng)險(xiǎn)評(píng)估。下面是分配的迭代：
| 迭代1 |
啟動(dòng)、停止和處理一個(gè)獨(dú)立作業(yè)上的一個(gè)設(shè)備故障。
維護(hù)設(shè)備和作業(yè)。 |
| 迭代2 |
啟動(dòng)、停止和處理覆蓋作業(yè)和作業(yè)組上的設(shè)備故障。
維護(hù)計(jì)劃和約束。
維護(hù)產(chǎn)品。 |
| 迭代3 |
創(chuàng)建產(chǎn)品產(chǎn)品差距。
改變作業(yè)所有權(quán)。
直接命令設(shè)備
刪除作業(yè)。
修改負(fù)載數(shù)據(jù)。 |
用例分析
用例分析是一個(gè)用來(lái)識(shí)別對(duì)象、類、類屬性和類方法的過(guò)程。 由于這個(gè)項(xiàng)目的實(shí)現(xiàn)方法是非面向?qū)ο蟮模覀兪褂靡粋€(gè)映射把面向?qū)ο蟮姆治瞿Ｐ娃D(zhuǎn)換到過(guò)程設(shè)計(jì)模型。圖12顯示對(duì)啟動(dòng)作業(yè)用例進(jìn)行分析的部分結(jié)果：
圖 12: 從啟動(dòng)作業(yè)用例導(dǎo)出的序列圖
測(cè)試計(jì)劃
我極力推薦下面的一篇文章：June 2001 Rational Edge，Jim Heumann，"Generating Test Cases from Use Cases"。在我們的PT系統(tǒng)中使用這種方法識(shí)別測(cè)試用例。圖13顯示啟動(dòng)作業(yè)用例的迭代2的測(cè)試用例。注意在測(cè)試用例和用例需求之間的連接。它可以幫助保證需求都被測(cè)試，以及測(cè)試用例隨著需求變更而更新。
圖 13: 從啟動(dòng)作業(yè)用例導(dǎo)出的測(cè)試用例
經(jīng)驗(yàn)學(xué)習(xí)
1. 集中在外部可視的行為上。這一點(diǎn)怎么強(qiáng)調(diào)都不過(guò)分，這就是我為什么這里再次重復(fù)的原因。在這個(gè)項(xiàng)目中，我經(jīng)常告訴那些需求分析人員，讓他們想象它們是飛翔在港口工廠的用戶，讓他們問(wèn)自己他們想要看見(jiàn)發(fā)生的事情。如果你寫的描述一些事情的需求不可見(jiàn)，那么你將不能對(duì)它進(jìn)行測(cè)試。
2. 不要引入設(shè)計(jì)。這與經(jīng)驗(yàn)1相關(guān)。下面是一個(gè)例子
每個(gè)作業(yè)都擁有一個(gè)使能信號(hào)，這個(gè)信號(hào)來(lái)自于作業(yè)的運(yùn)送源。使能信號(hào)在操作間內(nèi)部驅(qū)動(dòng)作業(yè)運(yùn)送來(lái)源的物理信號(hào)。(用例在這里描述了系統(tǒng)內(nèi)部信號(hào)。)
有很多原因使你不應(yīng)該這么做。首先，它使得測(cè)試很困難，因?yàn)槊枋龅男袨樵谕獠坎豢梢?jiàn)。第二，如果你把設(shè)計(jì)信息放到用例中，你就需要照著這些信息實(shí)現(xiàn)，因?yàn)槟鞘切枨螅虼四悴粌H必須照著它來(lái)進(jìn)行演示說(shuō)明，而且它也限制你的設(shè)計(jì)人員的實(shí)現(xiàn)方式。
3. 不要為內(nèi)部監(jiān)控過(guò)程寫用例。在這個(gè)系統(tǒng)中，由于是實(shí)時(shí)系統(tǒng)，有很多在系統(tǒng)內(nèi)部運(yùn)行的過(guò)程用來(lái)檢查、監(jiān)控和輪詢其它設(shè)備。你不應(yīng)該在你的用例中描述這些，因?yàn)樗窃O(shè)計(jì)，它僅僅是一種可能的實(shí)現(xiàn)方式。
除非過(guò)程與系統(tǒng)的目標(biāo)相關(guān)，例如在建筑監(jiān)控中的“監(jiān)控建筑”用例中，你應(yīng)該把它們寫在補(bǔ)充需求規(guī)格中。例如
- 系統(tǒng)應(yīng)該每200毫秒或者更短的時(shí)間內(nèi)檢查所有設(shè)備的狀態(tài)。
- 系統(tǒng)應(yīng)該在設(shè)備失敗的200毫秒內(nèi)開(kāi)始響應(yīng)。
- 系統(tǒng)應(yīng)該保證產(chǎn)品混合率在設(shè)定值的+/-5%范圍內(nèi)。
在用例的分支流或者擴(kuò)展用例中，都可以描述如果系統(tǒng)檢測(cè)到問(wèn)題時(shí)發(fā)生什么事情。這些需求可以使你設(shè)計(jì)諸如輪詢?cè)O(shè)備或者設(shè)備產(chǎn)生中斷等的過(guò)程，然是它們屬于設(shè)計(jì)應(yīng)該考慮的事情，不屬于需求的范圍。
4. 不要太早"凍結(jié)"用例。在項(xiàng)目中太早凍結(jié)用例將會(huì)導(dǎo)致很多問(wèn)題，因?yàn)樵谀愫湍愕目蛻舾玫乩斫庑枨髸r(shí)，你可以找到機(jī)會(huì)重新組織用例，或者你將引出新的用例，或者你要修改現(xiàn)有的用例。需求變更會(huì)發(fā)生，但這需要在一個(gè)迭代過(guò)程的管理和限制下進(jìn)行，以便進(jìn)行適當(dāng)?shù)挠绊懺u(píng)估，以及合適的預(yù)算和計(jì)劃日程的變更。如果你使用迭代過(guò)程，你至少有在后面的迭代中改正的機(jī)會(huì)。
5. 不要過(guò)于追求完美的用例模型而超出項(xiàng)目計(jì)劃日程。這是經(jīng)驗(yàn)4的必然結(jié)論。你從來(lái)都不可能得到一個(gè)完美的用例模型。在某個(gè)點(diǎn)上，你將不得不停下修補(bǔ)完善用例模型的工作，開(kāi)始實(shí)際的系統(tǒng)開(kāi)發(fā)工作。即使用例模型并不完美，你也可能開(kāi)發(fā)出符合用戶需求的系統(tǒng)。最后，圖14顯示PT用例模型的實(shí)際樣子。
圖 14: 不完善的用例模型
你將看到選擇作業(yè)、啟動(dòng)作業(yè)和停止作業(yè)是主要的用例。這里并沒(méi)有圍繞著傳送產(chǎn)品用例把所有其它用例聯(lián)系在一起，我們不得不在附加需求中描述其它的需求。來(lái)自操作員和相關(guān)者的選擇、啟動(dòng)和停止作業(yè)的需求并沒(méi)有進(jìn)行評(píng)估。用例模型不完善的主要原因在于，需求必須在某個(gè)點(diǎn)凍結(jié)，以便開(kāi)發(fā)者不會(huì)頻繁地面對(duì)不確定的開(kāi)發(fā)目標(biāo)，系統(tǒng)應(yīng)當(dāng)被實(shí)際開(kāi)發(fā)測(cè)試和部署。
6. 不要害怕收集細(xì)節(jié)信息。用例假定容易被每個(gè)人閱讀，但是這并不意味著你在大街上隨便找一個(gè)人，給他一個(gè)描述復(fù)雜系統(tǒng)的用例，就能夠期望他能夠理解。
需要問(wèn)你自己的問(wèn)題是：你的客戶需要多大程度的細(xì)節(jié)？你想給你的開(kāi)發(fā)者多大的范圍？如果你在用例中沒(méi)有給出很多細(xì)節(jié)，你就讓你的開(kāi)發(fā)者自行作出決定。你想這樣做嗎？你的開(kāi)發(fā)者可能有豐富的經(jīng)驗(yàn)而你也很高興這么做。另一方面，如果你正在進(jìn)行實(shí)際的開(kāi)發(fā)，沒(méi)有充分的細(xì)節(jié)不一定是可以接受的。你需要給開(kāi)發(fā)者和測(cè)試者描述以足夠的細(xì)節(jié)信息，說(shuō)明什么對(duì)于客戶是重要的。
如果有大量的細(xì)節(jié)信息，可以考慮把它們放到特殊需求或者附加需求中，或者用活動(dòng)框圖(Activity Diagram)來(lái)補(bǔ)充用例。(參見(jiàn)經(jīng)驗(yàn)9)
7. 不要引入用例間的直接交互。用例不能相互交互。它們可以相互影響，但是只能通過(guò)操作系統(tǒng)狀態(tài)來(lái)影響。
8. 不要把有關(guān)解決資源爭(zhēng)奪問(wèn)題的架構(gòu)決策放到用例中。這一點(diǎn)與第2課有關(guān)，例如，當(dāng)操作員使能一個(gè)作業(yè)的來(lái)源時(shí)，同時(shí)第二個(gè)作業(yè)共享同一個(gè)來(lái)源因此得到一個(gè)來(lái)源不可用的錯(cuò)誤時(shí)，會(huì)發(fā)生什么情況？
這些狀況應(yīng)該在不同的用例中描述。在每個(gè)用例，你只需要簡(jiǎn)單描述在給定環(huán)境下你想要系統(tǒng)做什么。在這個(gè)例子中，系統(tǒng)內(nèi)部如何工作，什么信號(hào)發(fā)到設(shè)備，這些都屬于架構(gòu)或者設(shè)計(jì)問(wèn)題。系統(tǒng)架構(gòu)需要解決這些問(wèn)題，諸如保證信號(hào)在非常接近情況下接收、不同順序接受或者高頻率地接收。
9. 使用活動(dòng)框圖以便使得復(fù)雜的用例能夠易于理解。活動(dòng)框圖可以作為用例的規(guī)格創(chuàng)建。
總結(jié)
在PT系統(tǒng)中使用用例給項(xiàng)目帶來(lái)很大的價(jià)值。只要有外部可見(jiàn)的系統(tǒng)行為，就應(yīng)該使用用例來(lái)定義需求規(guī)格。
對(duì)任何系統(tǒng)來(lái)說(shuō)，在確定用例時(shí)，要集中在系統(tǒng)的目標(biāo)上以及系統(tǒng)給相關(guān)人員提供的價(jià)值。在寫用例時(shí)要維護(hù)一個(gè)系統(tǒng)的外部視圖。
對(duì)于實(shí)時(shí)系統(tǒng)，附加需求在整個(gè)系統(tǒng)需求中占有更大的百分比。