采用用例，第1部分: 理解用例類型和工件 |  |
|
用例技術(shù)是一種越來越流行的捕獲需求和驅(qū)動系統(tǒng)開發(fā)的方法。這種技術(shù)的新采用者面臨的挑戰(zhàn)是如何將此技術(shù)引入到一個組織，以及如何確定用例何時完成。通常，他們必須在實際的項目壓力之下面對這些挑戰(zhàn)。本文的目標就是概述這些原理，幫助他們戰(zhàn)勝這些挑戰(zhàn)。在第1部分，我們將分析不同的用例和工件類型，并簡要討論如何將用例技術(shù)引入到一個不熟悉它們的團隊。 在本系列中，我們將通過一個假定的案例研究來進行我們的具體討論，在這個案例中，一個積極熱心的分析師和她的CATLYST項目團隊的其他成員使用用例開始了一段新的旅程。你們中那些讀過 Rational Edge 的 2003 年 1 月期中“一個新的RUP經(jīng)理的真實故事”的人，將會認出我們的虛擬團隊的扮演者。第2部分將會跟蹤這個項目的執(zhí)行，并突出這些原理是如何應(yīng)用的。 Smith，是一個經(jīng)驗豐富的項目經(jīng)理，他剛剛成功地交付了項目REALITY-J，正坐在他的小臥室中，這時，一名高級團隊成員，Harriet，輕輕地敲了敲他門口的鋼門。Harriet已經(jīng)被分到另一個項目作分析師，并且在收集項目需求方面需要得到幫助，特別是在使用用例方面。了解到Smith有使用用例的實踐經(jīng)驗，她想到找他尋求建議。 “我們正打算開始一個叫CATALYST的新項目。”她解釋道。“它的目標為一個國際連鎖酒店提供增值服務(wù)，并解決他們的記賬問題。我們的團隊在用例技術(shù)方面參差不齊。你能給我一些有關(guān)如何進行的提示嗎？” “你的團隊有一個主設(shè)計師嗎？”Smith問。 你說的主設(shè)計師是指的什么呢？“Harriet 回答道。 ”如果你的團隊成員在有關(guān)如何引導(dǎo)需求管理過程上有不同的想法，并且有不同的文檔化和組織需求的方式，那么誰來進行最后的發(fā)言呢？“Smith問道。 ”我不知道，我認為我不是一個主分析師。我在REALITY-J的時侯，我只是看到了所應(yīng)用的用例，但是你寫了大多數(shù)用例。我只是你的用例的一個用戶。目前在我們的團隊中，我們已經(jīng)有了三個工作成員：Roland，Helen和我自己。我們在項目開始時都承擔(dān)了分析師角色，然后接下來是團隊領(lǐng)導(dǎo)角色。Roland說他有一些使用用例的經(jīng)驗。Helen沒有使用用例的經(jīng)驗，但她正在積極地閱讀這個主題，我也是這樣。Simon是我們的項目經(jīng)理。我想，如果我們之中要有一些差異的話，他將是做決定的一個人。” Harriet回答道。 “Simon要積極地參與到需求采集－－確定用例，概述它們，等等－－中嗎？” Smith問道。 “我認為不是這樣。他可能會非常忙于項目的其它方面，并且對用例也相當(dāng)陌生。我們大概要做這些需求，并且他可能是提出項目進度表的人，等等。” Harriet說道。 “那么，Simon不會有時間做一個主分析師的工作，” Smith說道。 “這是一個問題。如果你的團隊沒有一個主分析師，每個人都處于風(fēng)險中。你的團隊必須做的第一件事就是確定一個主分析師。” Smith 告誡說。他指出IBM Rational統(tǒng)一過程，® 或 RUP，®在涉及到需求采集過程的兩個角色之間進行了一個明確的區(qū)分，并且給Harriet展示了RUP中的以下描述：
”簡而言之，系統(tǒng)分析師擁有大的景象，而需求說明者工作在詳細內(nèi)容上。“ Smith 解釋道，指出 Harriet 的項目既沒有一個系統(tǒng)分析師（如RUP所定義的），也沒有一個主設(shè)計師（如他所定義的）。她的團隊需要一個負責(zé)人，不僅要協(xié)調(diào)團隊，而且要通過明確描述需求指南來確保一致性。否則，一個需求說明者可能錯誤地認為另一個人正在編寫一個特定區(qū)域的需求文檔，至關(guān)重要的需求區(qū)域就可能從縫隙中漏掉。Smith強調(diào)的主分析師，在連接隔閡和確保需求完整性方面扮演了一個關(guān)鍵性的角色。
Smith向Helen笑了笑，Helen已經(jīng)進到了他的小房間，從旁聽到了這個討論。 Smith知道Harriet是一個完美主義者，喜歡事情都清楚地說到最小的細節(jié)，他想幫助她在開始管理需求時采用一種平衡的觀點。“她必須避免為了自己的興趣而集中于文檔上，相反，要堅持聚焦在理解問題和獲得有關(guān)如何解決問題的多數(shù)人意見上。”他自己這樣認為。因此下一步，他畫出了三個重疊橢圓，并標記出一些區(qū)域，表示顧客需要什么，哪些將被捕獲為需求，以及將最終被交付的系統(tǒng)（參見圖1）。 圖1：有效捕獲需求  "這三個橢圓表示了你需要跟蹤項目進度的框架。"Smith 說道，并在下面繼續(xù)解釋了每一個橢圓。
“決不要忽略看到這個事實，即需求不只是到結(jié)束的一個手段。最終目標是要有一個滿足涉眾的需求和目標的有益的運轉(zhuǎn)系統(tǒng)。” Smith告訴Harriet道。 然后他增加了一些字母到需求橢圓中的每個區(qū)域，如圖1所示。 “好吧，讓我們試一些小測驗。在這些標記字母部分的哪一塊發(fā)生了活動？”Smith問道。 "很明確，是A部分。"Harriet 回復(fù)道。 “是的，A是被識別的涉眾需求集，需求是根據(jù)它們進行編寫的，并且它們表示了已經(jīng)被構(gòu)建和驗證的系統(tǒng)部分。” Smith 贊同道。 “我認為行動在D部分也發(fā)生了。” Helen 提出。 “正是！如果一個系統(tǒng)滿足了涉眾目標，你是否已經(jīng)寫下了需求就無關(guān)緊要了。在一些非常少見的實例中，當(dāng)每個人都對項目目標有一個非常強的理解時，就已經(jīng)不需要描述需求了－－或者需求規(guī)格說明可以是最小程度的。” 這實際上是讓Harriet思考。“你是說，在某些實例中，我們可以忘掉需求？” "當(dāng)然不是！但是記住我說需求是到達目標的方法，這是一個有用的系統(tǒng)。" Smith 說道。“需求的主要目的是連接涉眾和我們的想法之間的差距，特別是在我們不理解或不同意的區(qū)域。” “我還不確定我是否了解了。這意味著我們應(yīng)當(dāng)有更多的會議和更少的文檔嗎？” Harriet 問道。 “你應(yīng)當(dāng)保持會議以取得一致意見，并使用文檔來明了已經(jīng)同意了什么以及還有哪些未解決。” Smith 回答道。
“那么需求的整體思想是保持涉眾和我們之間的連續(xù)的一致。用例技術(shù)如何在這里得到應(yīng)用呢？” Helen 問道。 “確定業(yè)務(wù)角色，業(yè)務(wù)工作人員以及業(yè)務(wù)用例，還有系統(tǒng)角色和用例，有助于我們闡明系統(tǒng)的目標和范圍，以及其滿足業(yè)務(wù)目標的任務(wù)。用例規(guī)格說明幫助我們闡明角色和系統(tǒng)之間的交互關(guān)系。”Smith 回答道。 “根據(jù)‘系統(tǒng)應(yīng)...’格式敘述的傳統(tǒng)需求表示方法的關(guān)鍵問題是這些敘述不直接轉(zhuǎn)化為驗收測試；這要求一個額外的思考過程。用例通過連接跨越此間隙。“ 他強調(diào)說。他繼續(xù)解釋，用例的事件流描述了主角的請求和系統(tǒng)的動作（例如顯示處理結(jié)果或修改一個系統(tǒng)狀態(tài)），工作在測試過程中時，這對明確描述測試步驟和驗證點是有用的。在早期階段使用系統(tǒng)驗收標準作為抽取和記錄需求的一個基礎(chǔ)，會給團隊成員大量的控制。
”我們的系統(tǒng)有不同種類的需求：用戶界面，業(yè)務(wù)過程，基礎(chǔ)結(jié)構(gòu)需求，數(shù)據(jù)需求，以及接口需求。我們?nèi)绾卧谟美胁蹲竭@些需求呢？” Smith進行了回答，描述了捕捉除了用例之外的各種不同種類需求的許多關(guān)鍵工件 2 ，如圖2所示。 圖2： 需求工件概要
“我如何知道我應(yīng)當(dāng)使用這些工件的哪一個？”Harriet問道。 “好，像毛主席所說的：‘不管黑貓或白貓－－只要抓到老鼠就沒有差別。’只要這種技術(shù)能做這件事情，它就是好的。” Smith 回答道。 “我理解你的意思是什么，盡管我認為這是后來的鄧小平所說的話。” Harriet 說。“但是我仍然需要一些一般的指南。” “讓我們通過看一下用例的不同類型來開始吧。” Smith 回答道，并且繼續(xù)列出了如表1所示的用例類型。 表1：用例類型 “這是真正有用的。” Harriet說道。“我需要不同的用例規(guī)格說明模版來創(chuàng)建不同的工件嗎？" “你可以對所有的工件使用相同的基本用例規(guī)格說明模版，如果你用適當(dāng)?shù)母郊用枋霰緛硌a充它的話。” Smith 回答道。“例如，你可以附加相應(yīng)的用戶體驗情節(jié)串連圖板，參與實體的類圖，相關(guān)業(yè)務(wù)規(guī)則等等，作為你的用例規(guī)格的附加描述。這不意味著每個用例規(guī)格說明都需要一個完全的附加描述集；只包括那些會促進理解的附加描述。” “那么，對你的列表中的用例類型要求哪些工件呢？” Harriet 問道。 “我真的想忍住不作推薦－－以免你們把它們視為上帝的永恒之語。” Smith 說道。“這實際上取決于項目環(huán)境。然而，還是有一些明顯的。例如，數(shù)據(jù)維護用例可以很好地通過領(lǐng)域建模來描述，還可能有用戶體驗建模。我發(fā)現(xiàn)領(lǐng)域建模適合于數(shù)據(jù)分析用例。因為它們是以數(shù)據(jù)為中心的。請求批準用例可以用業(yè)務(wù)用例規(guī)格來補充，如果它們不是瑣細的話。在許多情況下，支付用例需要相當(dāng)多的業(yè)務(wù)規(guī)則。忠實用例是令人感興趣的，因為它們將自己插入到了已有用例中。” “我不能完全回答你的問題。” Smith 繼續(xù)道。“用例類型更像是用例模式－－設(shè)計模式－－但是是在用例級別。你將在你的項目中碰到不同的用例種類，因此盡早地從每個種類中選出一個代表性的用例，用它進行工作。這會幫助你決定需要什么樣的書寫風(fēng)格和什么樣的附加信息。如果你喜歡的話，我可以幫助你確定在項目開始時的用例模式。”
“我如何知道我何時已經(jīng)完成了我的用例？” Harriet問道。 “你必須應(yīng)用一些參考框架來評價用例模型，例如業(yè)務(wù)要求，業(yè)務(wù)領(lǐng)域，等等。然而，直到項目完全結(jié)束之后，你的用例才會真正完成，因為你對系統(tǒng)的理解－－以及你的最終用戶的理解會隨著時間的過去而被改進和發(fā)展。這就是為什么你必須增量地和迭代地進行工作。” Smith 回答道。“起先，你會想要集中在每個用例對于要進行的開發(fā)是否足夠詳細。” “是的，但是我如何知道我已經(jīng)有了足夠的細節(jié)？” Harriet 問道。 Smith 通過列出一些標準進行了回答：
“喔！看起來有很多工作！” Harriet 喊道。 “我沒有說詳細說明需求是容易的，但是就像我先前所說的，需求是到目標－－一個有用的和工作的系統(tǒng)－－的一種方式。” Smith說道。“使用一個表（參見表2）來決定哪個工件對你的項目最有意義。然后，決定你需要用例的多少細節(jié)，并使用相同的表來跟蹤在采集你所需要信息方面的進度。在表中的每一個單元，指出你是否已經(jīng)收集了工件的內(nèi)容和已與用戶進行了驗證。” 表2：跟蹤需求采集過程
“這要學(xué)習(xí)那么多東西！” Helen 喊道。 “我同意。我的團隊和用戶代表不熟悉用例，挑選和選擇技術(shù)將不太容易。” Harriet 接著說。“我認為我們在培訓(xùn)上也要用大量時間。” “你們說得對，這是一件復(fù)雜的事情。讓我看一下你們可以如何應(yīng)對。” Smith 說。他建議采用如圖3所示的三階段的方法，并繼續(xù)解釋每個階段。
圖3：將需求技術(shù)引入到一個項目
大多數(shù)項目團隊在使用需求技術(shù)，特別是在用例方面有具有不同程度經(jīng)驗的成員，因此主導(dǎo)一個研討會來建立你計劃使用的需求技術(shù)的共同理解是明智的。分析師和最終用戶代表都應(yīng)當(dāng)參與，因為他們都將參與到文檔化需求的編寫和評審中。 主持人可以是來自團隊內(nèi)的或是團隊外的，只要他或她是知識淵博的人，其專業(yè)技能是大家都知道的，并且受人尊重的。主持人在當(dāng)前項目的環(huán)境中討論需求技術(shù)是重要的；否則，討論將過于抽象。預(yù)先提供一些項目信息，即使他或她不是團隊的一名成員。
在按照技術(shù)研討會之后，項目團隊應(yīng)對挑選不同的用例類型（參見表1），然后在一個微小迭代中細化、實現(xiàn)和測試它們，這個迭代要努力解決風(fēng)險。當(dāng)項目的大多數(shù)成員都對用例沒有什么經(jīng)驗時，這是非常重要的。通過走過這個微小迭代，項目團隊將獲得重要技能的第一手經(jīng)驗：
微小迭代的目標是快速地按比例增加團隊的能力。如果有些團隊成員在獲得這些技能方面有困難，就有必要延長主持人的涉入或重新調(diào)整團隊角色結(jié)構(gòu)。 因為目標是培訓(xùn)技能和幫助團隊從一個瀑布模型轉(zhuǎn)換到一個迭代模型，因此微小迭代的場景應(yīng)當(dāng)簡單，以使團隊可以快速地從需求移到設(shè)計，然后進行編碼和測試。這個小規(guī)模試驗項目將幫助團隊立即如何執(zhí)行一個迭代和使用合適的工件。
研討會和微小迭代應(yīng)當(dāng)覆蓋各種用例類型：數(shù)據(jù)集中，工作流集中，數(shù)據(jù)維護，報告，等等。這將幫助團隊成員試驗不同的編寫風(fēng)格和需求模式。在微小迭代結(jié)束時，團隊應(yīng)當(dāng)回顧需求是如何被組織和文檔化的，并識別要改進的區(qū)域。這可能要求引入更高級的技術(shù)，通過用例符號： «include» 和 «extend» 來結(jié)構(gòu)化需求，等等。 在微小迭代的最后，團隊將獲得使用用例的動手經(jīng)驗，并且他們也將會對項目需求有一個好的理解。高級技術(shù)將幫助他們按照一種最大化用例可理解性的方式來結(jié)構(gòu)化他們的需求，并在用例編寫方面減少重復(fù)。主持人應(yīng)當(dāng)推薦要使用哪種技術(shù)，并提供有關(guān)如何進行的必要指導(dǎo)。 在第2部分，我們將再次訪問CATALYST項目團隊，看一下當(dāng)他們開始將用例用于工作時發(fā)生了什么。
1來自 Rational Unified Process，v2002。 2有關(guān)捕獲業(yè)務(wù)需求的更多信息，參見Rational Edge的2002年11月期中的"Effective Business Modeling with UML: Describing Business Use Cases and Realizations"：http://www.ibm.com/developerworks/rational/rationaledge/
| ||||||||||||||||||||||||||||||||||||||||||||||
