利用角色扮演和用例卡片進行需求復審

1、利用角色扮演和用例卡片進行需求復審Robert Biddle 著，caorui 譯摘要 本文提出了一種利用角色扮演和索引卡片進行需求復審的方法，該方法能夠更好地指導用例開發(fā)過程。這種方法建立在已經(jīng)成功應用的面向對象設計技術CRC卡片技術之上。它使用索引卡片記錄本質用例，同時利用角色扮演的方法對用例進行開發(fā)和復審。本文詳細說明了這種方法，同時描述了這種方法的應用過程。 關鍵字 FA11 面向對象觀點，F(xiàn)B0301 信息需求判定活動，F(xiàn)C28 面向對象分析   簡介我們已經(jīng)探索出如何完善在面向對象開發(fā)方法的前期階段使用技巧的方法。特別地，我們對如何更好地確定那些捕獲需求并驅動設計的用例進

2、行了研究。為了確認用例集合是否已經(jīng)捕獲需求，需要對它們進行復審，因此我們關注如何有效對用例進行復審。 用例描述了用戶與系統(tǒng)的一系列交互。用例的概念已經(jīng)在開發(fā)過程中得到普遍接受，在軟件開發(fā)中尋找并使用用例已經(jīng)是很尋常的事情。但正如面向對象分析方法的其它方面一樣，要發(fā)揮用例的潛能，需要理解和經(jīng)驗。用例復審過程可以加深新手對用例的理解并增加他們的經(jīng)驗。 據(jù)我們所知，還沒有專用于用例復審的技巧。我們尋求這樣一種方法，它能保證團隊成員的積極參與，提供一些操作性較強的指導，同時這種方法應該對于初學者和系統(tǒng)利益相關者開放。另外，這種技術應該是輕量級、完備而靈活的，以保證團隊成員能夠洞悉目標系統(tǒng)的行為，同時對

3、系統(tǒng)有一致的理解。本文提出一種復審用例的方法，我們認為滿足以上各點要求。該方法基于已經(jīng)獲得成功應用的CRC卡片技術，同時還使用了索引卡片和角色扮演。 本文是按如下方式組織的：下節(jié)提供一些背景知識，討論面向對象開發(fā)中的用例及其作用；同時對我們應改編用于用例的CRC卡片設計技術做了一定的回顧。隨后幾節(jié)對方法本身進行描述，總結經(jīng)驗并解釋本質用例的應用及推斷。最后一節(jié)給出了結論。 背景用例 Ivar Jacobson等（1992）將用例定義為“與系統(tǒng)對話行為相關的一系列事務”。其基本思想是以用例來表達系統(tǒng)與外部世界間的一系列交互甚至系統(tǒng)還沒有構建出來。這種思想具有不可忽視的作用，有幾個原因： 在前期開

4、發(fā)階段，用例可以有助于集中于交互，并借此引出需求或預期系統(tǒng)行為，從而捕捉需求并幫助確定規(guī)范。這種技術是十分有效的，因為可以按照容易喚起回憶或想象的形式描述交互，如同敘述或對話一樣。 在其后的開發(fā)階段，用例仍然很有幫助，因為它側重于交互。在這個階段交互就是系統(tǒng)必須滿足的功能規(guī)范的具體體現(xiàn)。在設計和實現(xiàn)階段，必須確認并建立一種能夠滿足這些規(guī)范的結構。在復審和測試階段，用例可以驅動系統(tǒng)測試行為。 用例以一系列交互為基礎，而系統(tǒng)需要的交互通常遵循一致的結構即在一定程度上面向同一個目標或子目標。這就允許對需求規(guī)范分類，這是十分有益的。這種分類對于開發(fā)過程中的整體管理有很大幫助，因為用例可以通過選擇、分組

5、、過濾、優(yōu)先級排隊等方法來重新組織。 CRC卡片 在尋找更加方便應用用例的方法時，我們從另一種技術中得到了靈感，在面向對象開發(fā)過程的稍后階段需要這種技術。這種技術就是CRC（類職責協(xié)作），它使用卡片和角色扮演的方法，幫助人們將系統(tǒng)設計為一系列協(xié)作的對象（Beck 和Cunningham 1989， Bellin 和Suchman Simone 1997， Wilkinson 1996）。以索引卡片代表每個類，設計組的成員扮演類的角色，以話語的形式模擬系統(tǒng)的行為?？ㄆ嫌涗浟祟惖穆氊熀蛥f(xié)作者。職責是一種概念的抽象，是類應該知道或做的事情。職責概念被當作一種直觀推斷試探法來分配系統(tǒng)中的智能。 最初

6、，寫作CRC卡片只是用于學習設計技術的方法，卡片使得對象的思想更加具體，角色扮演則促進了對對象協(xié)作的認識。但現(xiàn)在CRC卡片已經(jīng)是得到廣泛承認的技術，而不是僅僅面向初學者。Bellin和Suchman Simone（1997）認為CRC卡片技術是一個“元認知”過程，該技術具有可操作性強的本性，這有助于在設計階段思考一些關鍵問題： “團隊中的每個人承擔了一個類的職責，以CRC卡片為腳本，扮演設計的系統(tǒng)。這一方法的價值在于，扮演類并指出類應該做什么這一過程能夠同靈機一動一樣，觸發(fā)相同的響應。把玩這些卡片能夠引發(fā)難以預料的洞察力。角色扮演能夠如此成功是因為它促進了團隊成員積極的參與?！?用例卡片與角色

7、扮演我們已經(jīng)使用過一段時間的CRC卡片技術，并十分贊賞其效果。在尋求改善用例方法的途徑時，我們決定采取類似的方法。其基本想法是使用用例的索引卡片，同時引入角色扮演。 用例描述了與系統(tǒng)的交互，但有不止一種方法可以描述這些交互。我們選擇用戶與系統(tǒng)之間對話的形式。因為對話形式的用例描述能夠構成一部劇本，我們希望這樣能夠有助于角色扮演。劇本有兩個角色，用戶和系統(tǒng)。這樣用例角色扮演可以只有兩個人參與，每人負責劇本的一部分。 我們決定，每張用例卡片只代表單個用例，卡片上要記錄用例的名稱和對話腳本步驟。為了清楚區(qū)別兩個角色，用居中的一條豎線將卡片分為兩個部分，左側寫用戶腳本，右側寫系統(tǒng)腳本，如圖1所示。這種

8、布局正是Wirfs-Brock（1993）采用的兩欄式格式。這種格式對于功能性需求很適用，因為可以很清楚看出如何使用系統(tǒng)以及系統(tǒng)又是如何運作的。 圖1：描述銀行系統(tǒng)本質用例的卡片 通常，用例對于陳述非功能性需求沒有什么幫助。然而，有時非功能性需求確實與特定的用例相關，這時可以在用例卡片的底部或者背面寫下簡短說明。 使用用例卡片及角色扮演的方式主要有助于詳盡闡述用例的“主體”，確定交互的步驟。在此之前，首先應該識別用例。關于用戶與系統(tǒng)交互的各種不同方式的信息等初期工作需要通過背景分析得到。在大型系統(tǒng)開發(fā)中，即使是用例識別的工作也可能需要付出大量的代價而且影響范圍廣泛。我們用各種分析技術識別大量的

9、備選用例，確定它們的優(yōu)先級，然后選擇一些“重點”用例，這些用例代表了最重要的交互，即使是在早期原型中它們也是必需的。 然后，開始在這些重點用例上工作，首先利用卡片和角色扮演詳細闡述它們的步驟。如CRC卡片方法一樣，我們一般推薦3到6個人的小組來做這些工作?？ㄆ瞎ぷ鞯牡谝徊绞菍懴轮攸c、用例的簡短名稱。例如，銀行系統(tǒng)的重點用例可能名為：存款、檢查帳戶余額和取款。 下面選擇一張卡片并寫出對話。選出扮演用戶和系統(tǒng)的人，使用探討的方式進行排練。團隊需要集體工作以決定對話的步驟。當某一想法聽起來很合理時，演員按腳本將之“表演”出來。團隊的其它成員則審查表演，之后再討論，并在必要時進行改進。文檔投影儀的應

10、用越來越廣泛，這樣卡片可以很容易的投影到大屏幕上，供更大的團隊查看。以上過程反復進行，直到整個團隊認為對話已經(jīng)能夠描述用戶與系統(tǒng)交互的方式。有時可以先放下某一用例而去審核另一用例，晚些時候再回頭改善前一個用例。 角色扮演的作用之一就是以探索和迭代的方式進行用例開發(fā)。我們同樣利用角色扮演來進行用例復審。這種復審可以由合作開發(fā)者、項目其它方面的工作人員、系統(tǒng)利益相關者或系統(tǒng)領域專家來進行。 在利用索引卡片和角色扮演確定了用例的主體后，其詳細信息可以記錄在需求文檔或者CASE工具的數(shù)據(jù)庫中。用例可以用于驅動系統(tǒng)設計和復審，在晚些時候用于系統(tǒng)測試和演示。在一些后期活動中，卡片和角色扮演可能還有用途，例

11、如對于某一交互的替代方案進行快速的審查和探討，卡片和角色扮演直接和輕量的自然本性有很大幫助。 經(jīng)驗到目前為止，我們已經(jīng)觀察過許多團隊使用用例卡片和角色扮演技術。我們在與超過20家企業(yè)團隊合作中使用過該技術，典型情況下，這些團隊都包括一些非技術人員，如業(yè)務分析人員或基層經(jīng)理。在教學和指導中我們也介紹了這些方法，特別是在大學的面向對象開發(fā)與軟件工程課程中。這些經(jīng)驗是鼓舞人心的，在工業(yè)領域和教育領域，所有的參與人員都已經(jīng)熟悉了面向對象系統(tǒng)和UML表示的一些基本概念。 我們尋求團隊成員的主動和直接參與，結果很令人滿意。與CRC卡片相同，索引卡片的具體性和角色扮演的行為性結合起來，吸引了團隊成員的注意力

12、，同時也要求積極參與。僅僅這一點就有足夠的價值，因為它確保在確定需求時整個團隊都參與進來了。 與CRC卡片一樣，索引卡片在另一方面也有所幫助，這與卡片的本性有關：它們既可以分散又可以結為一體，同時只需要很少的投資?？ㄆ梢栽谧烂嫔吓帕?、分級，需要的卡片可以抽取出來，在角色扮演時又可以拿著。一張卡片可以很容易被改動或拋棄而不會影響其它卡片，同時可以快速地進行改變。 與卡片相比，角色扮演的優(yōu)勢影響更加深遠。團隊成員，甚至非開發(fā)人員，都能夠很好的理解對話。另外，他們很熟悉表演道具，同時樂于懷疑戲劇依賴的基礎。人們通常都能夠觀看角色扮演并在真正理解的基礎上想象完成的系統(tǒng)的交互。這是快速原型法的一種形式

13、，它允許快速復審和反饋，允許迭代改良。 Bellin and Suchman Simone（1997）指出，CRC的角色扮演方法可以引出出人預料的洞察力，對于用例角色扮演也是這樣的。在CRC的角色扮演中，這種洞察力常常表現(xiàn)于如何在幾個協(xié)作的對象間分配智能。在用例的角色扮演中，這種洞察則與如何更好在系統(tǒng)邊界進行通信有關。 卡片與角色扮演本身并不總是足夠確定用例是否合理。開發(fā)者應該清楚，有很多相關因素影響用例。特別地，開發(fā)者應該研究用例對功能性需求的建模（Armour 和Miller 2001, Rosenberg 和Scott 1999），以及用例得以高效的種種因素（Cockburn 2001）

14、。Wirfs-Brock（1994）討論了用例怎樣很好地模擬“有意義的人機對話”，這與我們的技術有關。角色扮演使人機對話更加生活化，從而易于評價它是否真正有意義。 但是我們必須承認，系統(tǒng)還需要滿足非功能性需求（如響應時間、事務處理速度、信息容量、可靠性等）。由于用例側重于交互，所以在發(fā)現(xiàn)非功能性需求時并不理想。這意味著非功能性需求必須使用其他方法來進行確定。但無論如何，用例構造了一個很好的需求復審起點，并且通常會引起對非功能性需求的討論。 根據(jù)經(jīng)驗，確定需求時的一個關鍵問題就是決定系統(tǒng)的邊界，將應該由系統(tǒng)完成的事與不應該由系統(tǒng)完成的事分開。因為牽涉到系統(tǒng)的人包括分析人員和各種利益相關人員，對于

15、邊界的區(qū)分工作達成一致可能很困難。 在決定系統(tǒng)邊界時，用例卡片和角色扮演方法被證明是非常有效的。我們使用一種與設計階段相似的手段，就是將系統(tǒng)看成“黑箱”。并不說明內部如何工作，但如何使用系統(tǒng)由用例指定。每張用例卡片上的兩欄式對話表清晰地顯示了用戶職責和系統(tǒng)職責，劃分兩個角色的線就是系統(tǒng)的邊界。 在確定系統(tǒng)邊界時，用例角色扮演有多方面的幫助作用。在前期的探索式表演中，很快可以看出團隊成員對系統(tǒng)應該如何工作持有各種不同意見。人們閱讀的是同一份分析文檔，但卻提出不同的解釋，特別常見的是設計人員與業(yè)務分析人員或領域專家出現(xiàn)不同理解。及早發(fā)現(xiàn)和解決這種差異是很重要的，在確定角色扮演的實際交互序列時比較容

16、易暴露這些差異。 探索式角色扮演同樣也能暴露一些對于用戶或系統(tǒng)角色的不合理假設。對于用戶來說，如果用例指定的動作與可能的實際用戶行為不一致，則很容易發(fā)現(xiàn)。對于系統(tǒng)來說，如果無法獲得重要的信息，則指定的行為無法完成。圖3顯示了在角色扮演中能夠發(fā)現(xiàn)異常現(xiàn)象。實際的表演看來比仔細閱讀更容易暴露出這些異常問題。 第一幕 用戶： 我指出我需要做的工作，系統(tǒng)顯示該工作的細節(jié)。 系統(tǒng)： 喂！說明系統(tǒng)做什么是我的事情。 停！這經(jīng)常只是演員的錯誤，但也能揭示關于系統(tǒng)邊界的迷惑。注意負責表演系統(tǒng)的人如何“保護自己的勢力范圍” 第二幕 用戶： 我指定我要做的工作。 系統(tǒng)： 我顯示這項工作的細節(jié)，并說明是否有座位。

17、觀眾： 等一下，還沒有指定座位呢。 停！這說明在用例中有遺失的信息。在此例中，觀眾保證演員誠實的表演。 第三幕： 用戶： 我說明我要做的工作。 系統(tǒng)： 我顯示這項工作的細節(jié)。 用戶： 我指定我要哪一個座位。除非我不想這樣做，如果我這樣做，但沒有座位，我就得不斷的選擇座位，直到找到。要是系統(tǒng)能告訴我哪些座位可用就好了。 停！在這個例子中，用戶已經(jīng)深入到角色中去了，并且發(fā)現(xiàn)了當前版本用例的不足。 第四幕： 用戶： 我說明我要做的工作。 系統(tǒng)： 我顯示這項工作的細節(jié)，并列出可用的座位。 用戶： 我選擇我想要的座位。 系統(tǒng)： 我將這些座位標記為不可用，并將票打印出來，并且嗯，也許我應該先算一算需要多少

18、錢并收了錢后再打印這些票？ 停！ 第五幕：如此等等 圖3：劇院訂票系統(tǒng)用例的角色扮演對話示例，描述角色扮演如何在早期發(fā)現(xiàn)用例中的難點 要解決這些異常，可能需要修改用例的步驟，也可能需要以不同的方式來組織用例。這些變化都需要改動其它用例，甚至可能要新建用例。但重要的一點是，可以在早期發(fā)現(xiàn)并修正問題，而不是在后期開發(fā)才發(fā)現(xiàn)從而付出更大的代價。 角色扮演方法也使開發(fā)隊伍之外的人易于理解用例交互。在給那些事務繁忙的利益相關者演示用例時猶其有用。角色扮演方法快捷、現(xiàn)場感強、易于為人接受。此方法不需要太多投資，能對問題進行討論，對比幾種不同的方案，并可能發(fā)現(xiàn)存在的缺陷。 在尋求對用例角色扮演和系統(tǒng)邊界確認

19、工作的支持時，我們發(fā)現(xiàn)用例圖有很大幫助。我們使用的是UML（Rumbaugh 等 1998, OMG, 2000）用例圖，它以線條小人表示角色（在UML中表示用戶），用橢圓表示用例。我們同樣明確地標出系統(tǒng)邊界，表示為用例周圍的方框，角色與用例之間的線穿越邊界，如圖4所示。在用例圖中表示出系統(tǒng)邊界的約定由Jacobson等人（1992）倡導，雖然它是UML用例圖的一個可選部分，但它并不是UML的典型特性。這樣描述系統(tǒng)邊界的好處在于將系統(tǒng)可視化地表示為一個單元，邊界線與用例卡片上劃分用戶與系統(tǒng)的線是一致的。 圖4：明確表示出系統(tǒng)邊界的用例圖 本質用例盡管卡片與角色扮演可以涵蓋任何用例，事實上，我們

20、主要將它們應用在精選過的用例上，這些用例稱為本質用例。Constantine和Lockwood（1997）發(fā)展了這種精選方法，它是“以使用為中心設計”（Usage-Centered Design）的一部分，是用于開發(fā)用戶界面的過程。他們觀察到一個重要現(xiàn)象： “特別地，常規(guī)用例一般包含太多針對尚需設計的用戶界面的假設，這些假設多數(shù)是隱藏或者暗示的?！?Constantine和Lockwood將本質用例定義為“用例的簡化和泛化形式”。他們使用“本質”這一詞，因為這些用例： “希望通過非技術性的、理想化和抽象化的描述來捕獲問題的本質” 本質用例的抽象與用例沒有直接關聯(lián)，而是更多地與用例的步驟相關。從

21、這一點上講，一個本質用例確實說明了一系列交互，但只是一些抽象步驟的序列。例如，圖5顯示了銀行系統(tǒng)的一個普通用例，該用例詳細指定了對話中的具體步驟，例如“插入卡片并讀磁條”。圖6則是一個與之等價的本質用例，它以一個更抽象的“確認自己的身份”開始。再有，需要注意的是，普通用例對各角色的標識是“用戶行為”和“系統(tǒng)響應”，這無疑強調了實際的具體交互。而本質用例則在用戶部分使用“意圖”，系統(tǒng)部分使用“職責”，這樣更加抽象些，但內容更豐富。 取款用戶動作 系統(tǒng)響應 插入卡    讀取磁卡  提示輸入PIN輸入PIN    校驗PIN  顯示交易菜

22、單按鍵    顯示總額菜單按鍵    提示總額輸入總額    顯示總額按鍵    退卡取卡    吐鈔取鈔  圖5：從自動柜員機取現(xiàn)金的普通用例（引自Constantine和Lockwood.） 取款用戶意圖 系統(tǒng)職責 身份識別    驗證身份  提供選擇選擇    吐鈔取鈔  圖6 從自動柜員機取現(xiàn)金的本質用例（引自Constantine和Lockwood） 在卡片上使用這種形式的用例有很多原因。抽象保證了本質用例的簡潔性，

23、這樣一張卡片就可以容納用例描述。同時，這種抽象可以避免對于無關的實現(xiàn)細節(jié)的不必要爭論，從而加快進度。關注于“意圖”和“職責”的方法具有重大意義。 我們的經(jīng)驗證實本質用例確實有簡明的優(yōu)點，同時還具有更深遠的影響。正如我們希望的，抽象使得用例適于在索引卡片上使用，同時也避免過早陷入實現(xiàn)細節(jié)的討論。 從更深層次上講，將用戶角色表述為“意圖”，而系統(tǒng)角色表述為“職責”的做法具有啟發(fā)的優(yōu)點。二者的結合形成的用例對話能夠更好的反映用戶的真實動機，更好的捕捉系統(tǒng)需求，同時避免不成熟的設計決策。 我們發(fā)現(xiàn)使用本質用例需要做一些調整。調整之一，用例角色扮演本身應該是抽象的，以避免過于具體而與特定的接口細節(jié)相關。

24、按照我們的經(jīng)驗，這并不是問題，盡管發(fā)現(xiàn)團隊有時候考慮用例的一些具體條例有助于檢查他們的理解。 本質用例起源于用戶界面設計。通常的情況下，系統(tǒng)職責僅限于與直接交互相關的職責。暫時并不分析系統(tǒng)行為更深層的職責語義。然而我們發(fā)現(xiàn)，在有利的時候可以將這一部分較深層的職責包含進來。例如，圖5中的用例可能包含維護賬戶余額一致性和審計的職責。 關注對話中系統(tǒng)部分，如記錄其職責，對于系統(tǒng)開發(fā)具有更深遠的意義。確定用例之后，面向對象開發(fā)過程后一步是將系統(tǒng)設計為一系列協(xié)作的類和對象。關注于職責正是確定這些關系的主要方法之一，這也是CRC卡片的主要用途，它在職責驅動的設計方法中得到了更加細致的應用（Wirfs-Br

25、ock 和Wilkerson 1989, Wirfs-Brock 等，1990）。 本質用例將系統(tǒng)的角色記錄為職責的集合。這意味著，當所有的用例都已經(jīng)確定時，我們也就有了整個系統(tǒng)的職責集合。我們可以將系統(tǒng)看作單個對象，而職責則是這個對象的規(guī)范。我們可以設計一系列協(xié)作的對象，如同分解系統(tǒng)對象，并將系統(tǒng)職責恰當?shù)胤峙浣o系統(tǒng)各部分一樣。 CRC之類的職責驅動設計技術已經(jīng)闡述了如何分配職責。但是這些技術都是從領域分析得到對象和類關聯(lián)的職責開始。本質用例交付了正在設計的系統(tǒng)特有的職責集合，從而提供有價值的機會。 從本質上說，系統(tǒng)職責必須與對象集合職責相匹配。這有兩個主要含義：首先，CRC或職責驅動設計方

26、法依據(jù)的職責可以來自本質用例，也可以來自領域分析；其次，我們可以在任何時候檢查對象職責的集合，以確認它們是否真的符合系統(tǒng)需求。不管是快速評價其它備用設計方案，還是考察其它現(xiàn)有的可重用設計資源，如模式、框架或組件，我們都能夠確認這些對象能夠滿足用例規(guī)定的系統(tǒng)職責。前者意味著在設計初始能夠有更好的操作指南。后者意味著設計與需求之間具有更好的可追溯性。 相關工作本節(jié)綜述對我們的方法有影響的公開出版物。 用例方法是面向對象軟件工程（OOSE）引入的一個關鍵概念（Jacobson 等, 1992）。用例有很多種形式，對我們影響最大的是Wirfs-Brock稱為“會話”的那一種（“Wirfs-Brock，

27、1993及1994”）。在實踐中我們采用的是“本質用例”，它是從用戶界面設計中發(fā)展起來的（Constantine 和Lockwood，1999）。Cockburn（2001）提供了與用例相關的論述和方法的綜述。 OOSE建議如何在系統(tǒng)開發(fā)語境中應用用例。用例也是更現(xiàn)代化開發(fā)過程的特征，如Rational（瑞理） 統(tǒng)一方法（Unified Method）（Jacobson，Booch，和Rumbaugh， 1999）。在UML（Jacobson，Booch， and Rumbaugh， 1998）等圖示語言中也處理了用例。影響我們的工作還有，關于如何利用用例對需求建模的研究（Rosenberg

28、和Scott, 1999, 以及Armour 和Miller, 2001），極限編程（Beck，1999）中對“用戶故事”（該概念很象用例，但是寫得很具體）的應用，以及強調開發(fā)者和利益相關者參加復審的重要性。OPEN 技術工具箱（ Henderson-Sellers, Simons, 和 Younessi, 1998）提供了一個詳盡的調查，包括關于用例和CRC卡片的討論和指南。 CRC卡片技術，包括卡片本身和角色扮演，對我們的方法影響很大。CRC最初只是一個教學手段）（Beck 和Cunningham, 1989）。但最近的研究和實踐表明，CRC卡片作為一個通用設計技術有很大好處（Wilkin

29、son, 1996, 以及Bellin 和Suchman-Simone, 1997)）。另外，CRC卡片技術和本質用例都大量使用“職責”做為分析指南。我們對這種啟發(fā)式方法的應用也受到“職責驅動設計”過程的影響。（Wirfs-Brock 和Wilkerson, 1989, Wirfs-Brock, Wilkerson 和Wiener, 1990） 做為一種復審技術，我們的方法也反映了其它軟件質量保證工作的結果。過去需求檢查或者很不正規(guī)，或者僅僅是一次明確而正式的“軟件檢查”（Fagon，1979）的一部分。我們的方法不是完全正式的，但提供了一個有用的整體結構，類似于Yourdon（1989）的“

30、排練”，但強調用例而不是設計或實現(xiàn)。 結論本文提出使用索引卡片和角色扮演進行用例復審的技術，以幫助開發(fā)更好的用例。該技術基于面向對象設計中成熟的CRC卡片技術。在角色扮演中只有兩類角色：用戶和系統(tǒng)，這來自于使用對話格式的形式描述用例，如同本質用例中使用的一樣。 該技術是輕量級的，并不拘泥于形式，這意味著較低的準入門檻，特別是對初學者和利益相關者來說。這一點很重要，因為它能夠保證利益相關者很容易參與到復審過程中來，這無疑能夠保證高質量。 我們發(fā)現(xiàn)該技術對于暴露用例中潛在的缺陷和異常很有效，在確定系統(tǒng)邊界時更是有幫助，因為這種劃分正好與角色劃分相同。另外，利用本質用例方法對于面向對象設計還有其它好

31、處，它可以帶來設計和需求之間更好的可追溯性。 參考文獻Frank Armour and Granville Miller. (2001) Advanced Use Case Modeling: Software Systems, Volume 1. Addison-Wesley. Kent Beck and Ward Cunningham. (1989) A laboratory for teaching object-oriented thinking. In Proc. of OOPSLA-89: ACM Conference on Object-Oriented Programming

32、Systems Languages and Applications, pages 1-6. David Bellin and Susan Suchman-Simone. (1997) The CRC Card Book. Addison-Wesley. Alistair Cockburn. (2001) Writing effective use cases. Addison-Wesley. Larry L. Constantine and Lucy A. D. Lockwood. (1999) Software for Use: A Practical Guide to

33、 the Models and Methods of Usage Centered Design. Addison-Wesley. Michael E. Fagan. (1986) Advances in Software Inspection. IEEE Transactions on Software Engineering, pages 744-751, July. Brian Henderson-Sellers, Anthony Simons, and Houman Younessi. (1998) The OPEN toolbox of techniques, Addison-Wes

34、ley. Ivar Jacobson, Grady Booch, and James Rumbaugh. (1999) The Unified Software Development Process, Addison-Wesley. Ivar Jacobson, Mahnus Christerson, Patrik Jonsson, and Gunnar Overgaard. (1992) Object-Oriented Software Engineering. Addison-Wesley. OMG Object Management Group. (2000) Unified Mode

35、ling Language (UML) 1.3 specification. Doug Rosenberg and Kendall Scott. (1999) Use case driven object modeling with UML: A practical approach. Addison-Wesley. James Rumbaugh, Ivar Jacobson, and Grady Booch. (1998) The Unified Modeling Language Reference Manual. Addison-Wesley. Nancy Wilkinson. (1996) Using CRC Cards - An Informal Approach to OO Development. Cambridge University Press. Rebecca Wirfs-Brock and Brian Wilkerson. (1989) Object-oriented design: A responsibility-driven approach