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