kapok

內(nèi)容： 概述 為什么我們需要這篇文章？ 什么是實(shí)時系統(tǒng)的特點(diǎn)？ 產(chǎn)品傳送系統(tǒng)(PT)項(xiàng)目 PT系統(tǒng)的用例模型 結(jié)構(gòu)化用例 補(bǔ)充需求 用例的益處 用例貫穿整個項(xiàng)目 經(jīng)驗(yàn)學(xué)習(xí) 總結(jié) 對本文的評價 訂閱: developerWorks 時事通訊 The Rational Edge

Kerry

2004 年 11 月

本文介紹了一個真實(shí)的范例，然后討論了在把用例用來定義實(shí)時系統(tǒng)的規(guī)格時遇到的問題，以及相關(guān)的經(jīng)驗(yàn)學(xué)習(xí)。

概述
本文基于我去年為客戶開發(fā)一個實(shí)時控制系統(tǒng)的工作。

本文的目標(biāo)是：第一，重點(diǎn)描述實(shí)時系統(tǒng)規(guī)格的確定和用例之間的關(guān)系；第二，描述我們?nèi)绾伍_發(fā)用例模型以及應(yīng)用用例給我們帶來了哪些益處。

要說明的第一件事情是為什么我們需要類似這樣的一篇文章，然后我們再說明用用例來描述實(shí)時系統(tǒng)有哪些特殊之處。

在敘述為什么需要本文之后，我將描述一個具體項(xiàng)目和它的用例模型。我將重點(diǎn)描述用例模型的一些有趣的和有意義的特性，然后看看它們是如何有益于項(xiàng)目的。最后，我將討論一些經(jīng)驗(yàn)學(xué)習(xí)，并給出一些建議。

為什么我們需要這篇文章？
有一種看法認(rèn)為用例只對你描述高度交互的系統(tǒng)有用，這些系統(tǒng)以IT系統(tǒng)為代表，如銀行系統(tǒng)。例如，在銀行中你可能需要處理一個抵押應(yīng)用，它會有大量的用戶交互。對于實(shí)時系統(tǒng)來說，并不存在那么多的用戶交互。但是，如果實(shí)時系統(tǒng)具有有意義的外部可視的行為，用用例描述仍然對定義它們的規(guī)格是有用的，即使在一些用例中用戶只是選擇一些設(shè)置以及告訴系統(tǒng)完成一些功能。

在為客戶工作了這么多年來，我發(fā)現(xiàn)用例被廣泛地誤解。盡管有很多與之相關(guān)的書籍、文章和培訓(xùn)課程?？赡苓@些書籍、文章和培訓(xùn)課程都只關(guān)注于問題，因此它們提供大量的不同的方法。在這些著作中經(jīng)常提到的一個例子是自動柜員機(jī)(ATM)。類似這樣的例子對于說明一些問題是有用的，但在處理很大而且很復(fù)雜的實(shí)際系統(tǒng)時卻通常沒有明顯的幫助。在實(shí)時系統(tǒng)中你將怎樣處理出現(xiàn)的問題？有一些實(shí)際的例子可以對你有所幫助，本文恰恰可以給你提供這樣一個實(shí)際的例子。

什么是實(shí)時系統(tǒng)的特點(diǎn)？
實(shí)時系統(tǒng)就是時間是最關(guān)鍵因素的系統(tǒng)。如果一個系統(tǒng)不理會它的時間需求，將可能導(dǎo)致生命危險(xiǎn)，例如造成飛機(jī)失事。簡單來說，對于這樣的系統(tǒng)，對于時間需求處理的失敗將可能導(dǎo)致產(chǎn)品的損害和上百萬美元的損失。

實(shí)時系統(tǒng)也有最小限度的用戶交互，對于這類系統(tǒng)怎么樣定義它的用例是一件值得考慮的事情。實(shí)時系統(tǒng)通常都是高度算法化的，用例可能并不是最好的描述算法的文檔方法。典型地，一個用例將引用在其它地方描述的算法。

如果你的系統(tǒng)具有有效的外部可視行為，那么用例能夠極大地幫助你文檔化你的系統(tǒng)需求。下面我描述的系統(tǒng)就有大量外部可視行為。在IT系統(tǒng)中應(yīng)用用例的規(guī)則在這里仍然適用。

產(chǎn)品傳送系統(tǒng)(PT)項(xiàng)目
用戶是一個全球最大的鐵礦生產(chǎn)商，它在澳大利亞西北的Headland港擁有一套鐵礦傳送工廠。鐵礦從傳送帶網(wǎng)絡(luò)傳送到火車車廂，然后分類，稱重，保存在倉庫。最后鐵礦從倉庫中運(yùn)出，再通過傳送帶運(yùn)送到船上。

這個系統(tǒng)中每個東西都很大。有的傳送帶有7公里長，需要15分鐘才能啟動。運(yùn)行傳送帶網(wǎng)絡(luò)需要一個復(fù)雜的控制系統(tǒng)。對控制系統(tǒng)的一個需求是減少運(yùn)行系統(tǒng)需要的人數(shù)。另一個需求是降低對運(yùn)行系統(tǒng)的人的培訓(xùn)需求。圖1是工廠的航拍圖。

在左上角有一個船泊位。你可以看到有鐵路線從右邊連過去。卸貨場在接近于中間的垂直線附近。在這個線的頂端是粉碎機(jī)。你可以在北面和南面的院子里看到倉庫。傳送帶運(yùn)行在卸貨場和粉碎機(jī)，以及粉碎機(jī)和倉庫之間。 你可以看到運(yùn)輸機(jī)從倉庫裝上鐵礦，把它運(yùn)到船上。運(yùn)輸機(jī)的容量非常大。在這個系統(tǒng)中，傳送帶可以在一小時內(nèi)傳送10000噸的鐵礦！

有一些能夠增加系統(tǒng)復(fù)雜度的需求非常值得關(guān)注?？刂葡到y(tǒng)在避免溢出的情況下要達(dá)到最大的生產(chǎn)能力。出口容量在2004年從每年67M（百萬）噸增加到81M噸，到2011年將擴(kuò)大到90M噸。

基本概念：作業(yè)(route)
一個作業(yè)(route)由一系列傳送帶、定位和反饋設(shè)備組成，這些設(shè)備被選擇和調(diào)配以便把鐵礦從源位置運(yùn)送到目標(biāo)位置。作業(yè)可以是單獨(dú)的，也可以共享設(shè)備以便允許把鐵礦分開運(yùn)輸，從一個源位置運(yùn)送到多個目標(biāo)位置，或者組合運(yùn)輸，從多個源位置運(yùn)送到一個目標(biāo)位置。這些作業(yè)由操作員創(chuàng)建、維護(hù)和刪除。一旦操作員啟動作業(yè)，系統(tǒng)就開始工作，按照正確的順序啟動每個工作，以及處理一些異常狀態(tài)例如有不合適的產(chǎn)品已經(jīng)在傳送帶上。

為了達(dá)到生產(chǎn)力的需求，控制系統(tǒng)采用激進(jìn)的啟動和錯誤處理策略。盡管已經(jīng)存在的系統(tǒng)在一個時間點(diǎn)一個作業(yè)只能啟動一條傳送帶，當(dāng)它達(dá)到最大速度后，再啟動下一條，依此類推。 新的控制系統(tǒng)在一個作業(yè)中將同時啟動所有的傳送帶－－注意我們的傳送帶的長度不同，啟動時間和容量也不同。在出現(xiàn)問題時，新的系統(tǒng)試圖盡可能關(guān)閉最少數(shù)量的設(shè)備以避免溢出，因?yàn)閱右粋€長的傳送帶需要15分鐘。無論什么可能情況，設(shè)備都將保持運(yùn)行，直到鐵礦有可能溢出為止。系統(tǒng)需要同時運(yùn)行作業(yè)，以便礦石能夠傳送到多個目標(biāo)位置或者把礦石從多個源位置組合到一個位置。

設(shè)備失敗的處理是全自動的。當(dāng)一個傳送帶一小時可以傳送超過10000噸礦石時，你可以想象出現(xiàn)問題時不能很快停下傳送帶的后果。這個結(jié)果并不是你可以用獨(dú)輪車能夠清理干凈的！你將不得不使用一些重型設(shè)備來清理那些溢出的礦石，而且需要花費(fèi)很長的時間。甚至有更壞的結(jié)果，比如一個錯誤導(dǎo)致礦石已經(jīng)倒進(jìn)了船的甲板上。

PT系統(tǒng)的用例模型
本文的工作基于IBM(r) Rational Unified Process(r) (RUP(r))和一本名為“用例建?！钡臅?，這本書由Kurt Bittner和Ian Spence合著。用例是一個可供選擇的寫需求的方法。在過去，我們基于一個詞"shall"來書寫這些聲明。在幾年前我曾經(jīng)在一個國防項(xiàng)目工作，它包括22卷需求文檔，沒有人能夠真正全部理解它們。確認(rèn)所有的需求描述是正確的和一致的是一件非常困難的事情。用例可以幫助我們處理這類問題。用例把需求放在系統(tǒng)提供給用戶和有關(guān)人員的上下文中。 按照順序描述每個用例以消除上下文的冗余，這些冗余在用傳統(tǒng)的基于"shall"的需求描述方法中是必然包括的。

這里僅僅描述用例模型的一些特點(diǎn)，因?yàn)槿磕Ｐ吞?，也太?fù)雜。用例的規(guī)范非常長，也非常細(xì)致。

識別角色(actor)
在整個操作開始前主要工作集中在識別角色是非常重要的，因?yàn)樗梢源_定系統(tǒng)的邊界，清楚地指示哪些是在系統(tǒng)范圍內(nèi)，哪些在系統(tǒng)范圍外。我們不想開發(fā)那些我們沒有必要付錢的東西。在PT系統(tǒng)中，運(yùn)輸機(jī)是一個我們需要交互的系統(tǒng)。這里我們只需要知道運(yùn)輸機(jī)干什么工作，并不需要控制它如何工作，我們也不需要修改它。既然我們不控制運(yùn)輸機(jī)，它就在我們的系統(tǒng)范圍之外，作為一個角色模型存在。我們有Ship-Hatch Loaders, Stackers, Sampling Stations 和Dust Control Systems - 所有這些外部系統(tǒng)都作為角色模型。圖2顯示部分這個系統(tǒng)的角色。

在圖2中，角色使用UML 包分組。在左邊是角色包。最重要的一個在左上角。CRO 就是Control Room Operator，中央控制室操作員。其它重要的還有在左下角的RSMT(Root System Maintenance Technician，根系統(tǒng)維護(hù)技術(shù)員)。

其它的包包括所有不同的設(shè)備角色。一些用例提到我們管理的通用設(shè)備，另一些將提到特定的不同類型的設(shè)備。

在圖的下方有一些與我們交互的外部設(shè)備。左邊的一個是PMAC，一個已經(jīng)存在的系統(tǒng)用來處理我們的用戶界面。如果它僅僅是與我們的系統(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)你啟動7KM長的傳送帶，并在上面運(yùn)行數(shù)千噸的礦石是，它需要大量的電力供應(yīng)。因此，傳送帶的啟動實(shí)際上是錯開的，以便降低電站的負(fù)荷。只要你想啟動傳送帶，PT系統(tǒng)都將詢問電站并得到電站的許可。

確定用例
用例是一種簡單的可選擇的定義需求的方法。首先，讓我們再次回顧一下用例的定義：

用例定義一個由系統(tǒng)完成的操作序列，它給操作者和相關(guān)人員提供 可觀察到的有價值的結(jié)果。

在識別IT系統(tǒng)的用例時，牢記“可觀察到的有價值的結(jié)果”是非常重要的，這一點(diǎn)在這里仍然適用。我們將看到系統(tǒng)提供給操作者和相關(guān)人員的值。在我們的例子中，中央控制室操作員是一個角色，但是整個公司實(shí)際上都可以看到系統(tǒng)把礦石從一個地方移動到另外的地方?！坝上到y(tǒng)完成的操作序列”聲明了在用例中系統(tǒng)怎么做的描述。這些每個都是我們系統(tǒng)的需求。最后，用例是一個完整的有意義的事件流。把“完整的有意義的事件流”和“可觀察到的有價值的結(jié)果”這兩個概念組合起來可以幫助避免識別出不完整的功能片斷并把它稱為用例。

用例和角色在用例圖中以圖形化的方式描述。圖3顯示了 PT系統(tǒng)的頂層用例圖。你很快就能看到 PT系統(tǒng)的用例分為4組：Operation, Administration, Configuration 和System Startup。

PT系統(tǒng)中用例相關(guān)的操作在圖4中顯示:

PT的主要用例是“傳送產(chǎn)品”。正如這個用例的名字那樣，你可以看到在這里系統(tǒng)提供給用戶和有關(guān)人員的價值是把產(chǎn)品從一個地方運(yùn)送到另一個地方的能力。這個軟件也能夠用來運(yùn)送其它物品，不僅僅是鐵礦。例如它能夠用來在制藥廠傳送藥片。傳送產(chǎn)品是一個很大的用例，但它抓住了最根本的因素，即我們的系統(tǒng)存在的原因，即給我們的操作者和相關(guān)人員提供的價值。

在圖4中我們看到與電源管理系統(tǒng)(PLMS)的交互，請求啟動設(shè)備，我們也看到了用例與我們控制的設(shè)備的交互。我們可以顯示每個設(shè)備角色，但那樣的話，圖就顯得太混亂了。

在圖4中，從CRO到傳送產(chǎn)品的箭頭，表示這個操作員發(fā)起或者啟動這個用例。用例到設(shè)備和PLMS操作者的箭頭表示這個用例或者系統(tǒng)與設(shè)備和PLMS交談。從船艙裝載系統(tǒng)(SHLS)的箭頭表示SHLS發(fā)起與系統(tǒng)的交互－－特別地，SHLS可以請求鐵礦流暫時中斷以便裝載機(jī)移動到另一個艙室。

有關(guān)管理、配置和系統(tǒng)啟動的用例在圖5中描述。

在這里我們可以做的一件事情是在對系統(tǒng)的操作影響最小的情況下更新系統(tǒng)軟件。因此我們有"Perform Software Upgrade" 用例。我們也有"Start System" 用例 -這個用例經(jīng)常被忘掉。系統(tǒng)有人身安全優(yōu)先的規(guī)則，Start System 用例包括在系統(tǒng)啟動時進(jìn)行的所有安全檢查的規(guī)格說明。你一定不想在服務(wù)人員在傳送帶上工作時偶然地啟動它！

Route System Maintenance Technologist (RSMT)是一個負(fù)責(zé)創(chuàng)建作業(yè)或者預(yù)定義作業(yè)的人，預(yù)定義的作業(yè)稍后由CRO使用。我們可以在系統(tǒng)中添加新的設(shè)備，定義新設(shè)備的種類以及定義系統(tǒng)傳送產(chǎn)品的特點(diǎn)。港口工廠處理來自不同礦山的不同類型的鐵礦，它們有不同的顆粒大小、不同的礦石成分等級。我們要非常小心的一件事情是避免把錯誤的礦石裝到船上去。

關(guān)于用例圖這里要警告一下：用例圖只是冰山的一角。直到你開始寫用例規(guī)格之前不要去重新分解、重組和調(diào)整用例模型。用例的規(guī)格大約95％來自用例模型。用例圖僅僅給你一個模型的總體、全面的概要描述。

正如我前面提到的，用例描述“事件流”。圖6顯示不同種類的事件流和它們是如何在用例規(guī)格中描述的。

從頂部到底端底藍(lán)色粗線條表示主事件流(Basic Flow)。它表示每件事情都按照正確的方式發(fā)生。有很多種分支流(Alternate Flow)。描述處理設(shè)備故障的分支是一個很好的分支流的例子。另一個例子是描述操作員取消了前面請求的動作。

這里一個非常重要的結(jié)構(gòu)是子事件流(Subflow)。子事件流就象子程序調(diào)用。我們試圖保持主事件流簡單易讀，沒有子事件流是很難做到這一點(diǎn)的。例如，我們使用子事件流來描述我們啟動或者安放設(shè)備位置時發(fā)生的細(xì)節(jié)。這些過程每個都相當(dāng)復(fù)雜，如果我們都在主事件流上描述，那么它將變得很長并且很難理解。

圖7顯示一個主事件流的片斷：

在第二步，系統(tǒng)檢查作業(yè)是否有效。如果系統(tǒng)確認(rèn)作業(yè)無效時會發(fā)生什么？這在分支流中描述。在用例規(guī)格中我們使用腳注來指示分支流，腳注文本包括指向相關(guān)文檔章節(jié)的交叉引用。這將減少描述事件流的混亂，使得它更容易讀。在這里我使用 "§" 符號指示存在一個分支流。我也用高亮的紅色表示這是項(xiàng)目術(shù)語表－－一份很重要的文檔－－中的定義。

在第3步，系統(tǒng)檢查選擇的作業(yè)的啟動策略。"Starting/Positioning Stragegy 2.1"表示交錯啟動，它需要在啟動作業(yè)前所有的設(shè)備都到位。這個啟動策略在分支流中描述。最后系統(tǒng)向PLMS詢問是否允許啟動作業(yè)。如果不允許時發(fā)生的事情也在分支流中描述。

在圖8中，我們將看到分支流和子事件流的例子。

分支流定義當(dāng)基于某種原因設(shè)備不到位，因而這個作業(yè)不能啟動時應(yīng)該發(fā)生什么。系統(tǒng)給操作者發(fā)一個消息，建議在我們實(shí)際啟動作業(yè)前把設(shè)備移動到相應(yīng)的位置。在這個點(diǎn)上，用例就結(jié)束了。

子事件流的例子提供我們實(shí)際上如何啟動作業(yè)的更詳細(xì)的信息。系統(tǒng)檢查全部作業(yè)設(shè)備是否暢通（傳送帶上沒有其它物品）。如果正常，系統(tǒng)同時移動所有需要定位的設(shè)備到相應(yīng)的位置，包括作業(yè)自己需要的設(shè)備和要與其它作業(yè)共享的設(shè)備，然后我們交錯啟動所有的設(shè)備以避免電力過載。當(dāng)全部設(shè)備都運(yùn)行起來后，我們告訴操作員作業(yè)已經(jīng)啟動，然后用例結(jié)束。第16步的 "a", "b" 和 "c" 也涉及了子事件流。

特殊需求
有很多需求，特別在實(shí)時系統(tǒng)中，不能歸結(jié)到用例的事件流中。通常它們是非功能需求如性能、可用性等等。那些與給定用例相關(guān)的特殊需求可以歸結(jié)到與用例規(guī)格定義相關(guān)聯(lián)的"特殊需求"一節(jié)中。有時為了方便，甚至功能需求也可以放到這一節(jié)中。圖9即為一個示例。

第一個例子可以作為一個分支流，但是為了使主事件流基于閱讀，我們可以簡單地說：“系統(tǒng)檢查是否有特殊需求的xyz節(jié)中規(guī)定的不能啟動的狀況發(fā)生”。在這個特定用例中，如果我們在碼頭傳送帶上還有東西，而傳送帶由于完成了往甲板上卸礦石已經(jīng)停止工作，那么我們將給操作員發(fā)出一個警告。

第二個例子是一個算法的詳細(xì)描述，這個算法用來調(diào)整傳送帶的傳輸量和傳送速度。這里，主事件流可以簡單地描述：“傳輸量和傳送速度按照特殊需求中的uvw節(jié)進(jìn)行調(diào)整?！?/P>

結(jié)構(gòu)化用例
用例的結(jié)構(gòu)化是一個高級課題。你也可以不使用這項(xiàng)技術(shù)來完成一個系統(tǒng)的需求文檔。用例的結(jié)構(gòu)化可以讓你避免冗余信息，保證用例文本只存在一個單獨(dú)的可維護(hù)的位置。關(guān)于結(jié)構(gòu)化的重要的一點(diǎn)是，你必須避免讓用例模型和用例變得難以理解。

結(jié)構(gòu)化技術(shù)在圖10中顯示。

在圖的左邊，我們有一個用例，它有一個主事件流，一個分支流和一個子事件流。子事件流和分支流都可以作為單獨(dú)的用例分出來。分支流變成一個新的用例，擴(kuò)展了原始的用例。子事件流也變成一個新的用例，它包含在原始的用例中。一般來說，包含關(guān)系僅僅用于一個分支流共用于多個用例的情況。這就是我們?nèi)绾未_保僅僅寫一個分支流，僅僅有一個維護(hù)地點(diǎn)的方法。通常，當(dāng)需要在已經(jīng)存在的用例上增加新功能而且你又不想修改原始用例時，可以創(chuàng)建一個擴(kuò)展流

把這些結(jié)構(gòu)化技術(shù)用到我們的產(chǎn)品傳送系統(tǒng)后，改變后的用例如圖11所示：

這些新的用例稱為“抽象用例”，因?yàn)樗鼈儧]有操作者，你不能直接調(diào)用它們。如果我把這些抽象用例隱藏起來，你仍然可以相當(dāng)清楚地看到系統(tǒng)的主要功能。

一系列的錯誤處理用例都以這樣的聲明開始：“當(dāng)系統(tǒng)檢測到設(shè)備故障”或者“當(dāng)系統(tǒng)檢測到超載”等。然后用例繼續(xù)描述系統(tǒng)在這些情況的響應(yīng)。

在圖11的頂部，我提煉出了兩個抽象用例：一個是啟動作業(yè)，另一個是停止作業(yè)。從技術(shù)角度來說，我在這里破壞了規(guī)則：包含用例應(yīng)當(dāng)被多于一個的用例共享。我之所以這么做是因?yàn)?，如果我在“傳送產(chǎn)品”用例中寫出所有的內(nèi)容，文檔將超過300頁。把它分開可以讓很多人同時在系統(tǒng)的不同部分描述需求。

補(bǔ)充需求
我們有很多補(bǔ)充的需求，它們不適合放在任何用例中。因?yàn)樘囟ǖ男枨笈c具體的用例相關(guān)，這些都是典型的非功能性需求。在你在用例中的需求和補(bǔ)充的需求之間存在一個平衡。當(dāng)你進(jìn)行實(shí)時系統(tǒng)工作時，你可能發(fā)現(xiàn)會比你進(jìn)行IT系統(tǒng)開發(fā)時有更多的補(bǔ)充需求。這是由于在實(shí)時系統(tǒng)中有更多的有時間要求的需求，它們都在補(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ǔ)充需求描述時，可以把這些需求放在補(bǔ)充需求中，而不用寫一個完整地用例規(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)。
• 把需求按照時間順序排列，使需求比傳統(tǒng)方式更加容易讀，更容易理解。
• 更容易得到客戶的認(rèn)同，因?yàn)樗麄兡芨菀椎亻喿x和理解。
• 可以用作項(xiàng)目計(jì)劃、分析、設(shè)計(jì)、測試和文檔的基礎(chǔ)。

另一方面，關(guān)于用例有很多不正確的觀點(diǎn)。第一個是，象當(dāng)前多種書籍和文章中指出的，傳統(tǒng)的書寫需求的方法能夠更嚴(yán)謹(jǐn)和精確。實(shí)際上并不是這樣的，我們在這個項(xiàng)目中也能寫出非常嚴(yán)謹(jǐn)而精確的用例。

另一個看法是任何沒有經(jīng)過專業(yè)培訓(xùn)的人都可以寫用例。寫傳統(tǒng)需求文檔的原則在這里仍然適用。你需要從外部視角來看系統(tǒng)做什么。你不需要寫出系統(tǒng)是怎樣做的。象傳統(tǒng)的需求一樣，你寫的用例需求也應(yīng)該是可測試的。新手經(jīng)常繼續(xù)使用老的諸如功能分解的習(xí)慣。有開發(fā)背景的人經(jīng)常傾向于從系統(tǒng)內(nèi)部而不是用外部視角描述。

用例貫穿整個項(xiàng)目
我前面提到，用例在整個項(xiàng)目中都有用。

項(xiàng)目計(jì)劃
在這里我們沒有足夠的空間討論分配用例迭代的準(zhǔn)則。只能簡單說，這些準(zhǔn)則基于RUP的風(fēng)險(xiǎn)評估。下面是分配的迭代：

用例分析
用例分析是一個用來識別對象、類、類屬性和類方法的過程。 由于這個項(xiàng)目的實(shí)現(xiàn)方法是非面向?qū)ο蟮?，我們使用一個映射把面向?qū)ο蟮姆治瞿Ｐ娃D(zhuǎn)換到過程設(shè)計(jì)模型。圖12顯示對啟動作業(yè)用例進(jìn)行分析的部分結(jié)果：

測試計(jì)劃
我極力推薦下面的一篇文章：June 2001 Rational Edge，Jim Heumann，"Generating Test Cases from Use Cases"。在我們的PT系統(tǒng)中使用這種方法識別測試用例。圖13顯示啟動作業(yè)用例的迭代2的測試用例。注意在測試用例和用例需求之間的連接。它可以幫助保證需求都被測試，以及測試用例隨著需求變更而更新。

經(jīng)驗(yàn)學(xué)習(xí)
1. 集中在外部可視的行為上。這一點(diǎn)怎么強(qiáng)調(diào)都不過分，這就是我為什么這里再次重復(fù)的原因。在這個項(xiàng)目中，我經(jīng)常告訴那些需求分析人員，讓他們想象它們是飛翔在港口工廠的用戶，讓他們問自己他們想要看見發(fā)生的事情。如果你寫的描述一些事情的需求不可見，那么你將不能對它進(jìn)行測試。

2. 不要引入設(shè)計(jì)。這與經(jīng)驗(yàn)1相關(guān)。下面是一個例子

每個作業(yè)都擁有一個使能信號，這個信號來自于作業(yè)的運(yùn)送源。使能信號在操作間內(nèi)部驅(qū)動作業(yè)運(yùn)送來源的物理信號。(用例在這里描述了系統(tǒng)內(nèi)部信號。)

有很多原因使你不應(yīng)該這么做。首先，它使得測試很困難，因?yàn)槊枋龅男袨樵谕獠坎豢梢姟５诙?，如果你把設(shè)計(jì)信息放到用例中，你就需要照著這些信息實(shí)現(xiàn)，因?yàn)槟鞘切枨?，因此你不僅必須照著它來進(jìn)行演示說明，而且它也限制你的設(shè)計(jì)人員的實(shí)現(xiàn)方式。

3. 不要為內(nèi)部監(jiān)控過程寫用例。在這個系統(tǒng)中，由于是實(shí)時系統(tǒng)，有很多在系統(tǒng)內(nèi)部運(yùn)行的過程用來檢查、監(jiān)控和輪詢其它設(shè)備。你不應(yīng)該在你的用例中描述這些，因?yàn)樗窃O(shè)計(jì)，它僅僅是一種可能的實(shí)現(xiàn)方式。

除非過程與系統(tǒng)的目標(biāo)相關(guān)，例如在建筑監(jiān)控中的“監(jiān)控建筑”用例中，你應(yīng)該把它們寫在補(bǔ)充需求規(guī)格中。例如

• 系統(tǒng)應(yīng)該每200毫秒或者更短的時間內(nèi)檢查所有設(shè)備的狀態(tài)。
• 系統(tǒng)應(yīng)該在設(shè)備失敗的200毫秒內(nèi)開始響應(yīng)。
• 系統(tǒng)應(yīng)該保證產(chǎn)品混合率在設(shè)定值的+/-5%范圍內(nèi)。

在用例的分支流或者擴(kuò)展用例中，都可以描述如果系統(tǒng)檢測到問題時發(fā)生什么事情。這些需求可以使你設(shè)計(jì)諸如輪詢設(shè)備或者設(shè)備產(chǎn)生中斷等的過程，然是它們屬于設(shè)計(jì)應(yīng)該考慮的事情，不屬于需求的范圍。

4. 不要太早"凍結(jié)"用例。在項(xiàng)目中太早凍結(jié)用例將會導(dǎo)致很多問題，因?yàn)樵谀愫湍愕目蛻舾玫乩斫庑枨髸r，你可以找到機(jī)會重新組織用例，或者你將引出新的用例，或者你要修改現(xiàn)有的用例。需求變更會發(fā)生，但這需要在一個迭代過程的管理和限制下進(jìn)行，以便進(jìn)行適當(dāng)?shù)挠绊懺u估，以及合適的預(yù)算和計(jì)劃日程的變更。如果你使用迭代過程，你至少有在后面的迭代中改正的機(jī)會。

5. 不要過于追求完美的用例模型而超出項(xiàng)目計(jì)劃日程。這是經(jīng)驗(yàn)4的必然結(jié)論。你從來都不可能得到一個完美的用例模型。在某個點(diǎn)上，你將不得不停下修補(bǔ)完善用例模型的工作，開始實(shí)際的系統(tǒng)開發(fā)工作。即使用例模型并不完美，你也可能開發(fā)出符合用戶需求的系統(tǒng)。最后，圖14顯示PT用例模型的實(shí)際樣子。

你將看到選擇作業(yè)、啟動作業(yè)和停止作業(yè)是主要的用例。這里并沒有圍繞著傳送產(chǎn)品用例把所有其它用例聯(lián)系在一起，我們不得不在附加需求中描述其它的需求。來自操作員和相關(guān)者的選擇、啟動和停止作業(yè)的需求并沒有進(jìn)行評估。用例模型不完善的主要原因在于，需求必須在某個點(diǎn)凍結(jié)，以便開發(fā)者不會頻繁地面對不確定的開發(fā)目標(biāo)，系統(tǒng)應(yīng)當(dāng)被實(shí)際開發(fā)測試和部署。

6. 不要害怕收集細(xì)節(jié)信息。用例假定容易被每個人閱讀，但是這并不意味著你在大街上隨便找一個人，給他一個描述復(fù)雜系統(tǒng)的用例，就能夠期望他能夠理解。

需要問你自己的問題是：你的客戶需要多大程度的細(xì)節(jié)？你想給你的開發(fā)者多大的范圍？如果你在用例中沒有給出很多細(xì)節(jié)，你就讓你的開發(fā)者自行作出決定。你想這樣做嗎？你的開發(fā)者可能有豐富的經(jīng)驗(yàn)而你也很高興這么做。另一方面，如果你正在進(jìn)行實(shí)際的開發(fā)，沒有充分的細(xì)節(jié)不一定是可以接受的。你需要給開發(fā)者和測試者描述以足夠的細(xì)節(jié)信息，說明什么對于客戶是重要的。

如果有大量的細(xì)節(jié)信息，可以考慮把它們放到特殊需求或者附加需求中，或者用活動框圖(Activity Diagram)來補(bǔ)充用例。(參見經(jīng)驗(yàn)9)

7. 不要引入用例間的直接交互。用例不能相互交互。它們可以相互影響，但是只能通過操作系統(tǒng)狀態(tài)來影響。

8. 不要把有關(guān)解決資源爭奪問題的架構(gòu)決策放到用例中。這一點(diǎn)與第2課有關(guān)，例如，當(dāng)操作員使能一個作業(yè)的來源時，同時第二個作業(yè)共享同一個來源因此得到一個來源不可用的錯誤時，會發(fā)生什么情況？

這些狀況應(yīng)該在不同的用例中描述。在每個用例，你只需要簡單描述在給定環(huán)境下你想要系統(tǒng)做什么。在這個例子中，系統(tǒng)內(nèi)部如何工作，什么信號發(fā)到設(shè)備，這些都屬于架構(gòu)或者設(shè)計(jì)問題。系統(tǒng)架構(gòu)需要解決這些問題，諸如保證信號在非常接近情況下接收、不同順序接受或者高頻率地接收。

9. 使用活動框圖以便使得復(fù)雜的用例能夠易于理解?；顒涌驁D可以作為用例的規(guī)格創(chuàng)建。

總結(jié)
在PT系統(tǒng)中使用用例給項(xiàng)目帶來很大的價值。只要有外部可見的系統(tǒng)行為，就應(yīng)該使用用例來定義需求規(guī)格。

對任何系統(tǒng)來說，在確定用例時，要集中在系統(tǒng)的目標(biāo)上以及系統(tǒng)給相關(guān)人員提供的價值。在寫用例時要維護(hù)一個系統(tǒng)的外部視圖。

對于實(shí)時系統(tǒng)，附加需求在整個系統(tǒng)需求中占有更大的百分比。