拥抱敏捷的用例分析方法
引言
??? 用例分析方法的傳播與UML和RUP的關(guān)系密不可分。筆者當(dāng)年學(xué)習(xí)用例分析最主要的并不是根據(jù)那兩本UML經(jīng)典書《UML用戶指南》、《UML參考手冊》，而是根據(jù)RUP更多一些。2003年前后，UML貌似是當(dāng)時的熱點，但可惜的是，歷經(jīng)了近10年，UML的使用并沒有像當(dāng)初預(yù)期的那樣流行。而RUP的聲音在最近幾年也是漸漸沉寂。原先的用例分析方法是RUP中與其他工作聯(lián)系最緊密的一個環(huán)節(jié)，RUP中的4+1視圖是以用例視圖為中心的，用例分析的不少具體做法是為了RUP后續(xù)工作服務(wù)的，看起來用例分析方法就是RUP中不可分割的一部分，所以用例分析方法貌似隨著UML和RUP也在沉寂。? 隨著敏捷軟件開發(fā)的傳播，用戶故事（User story）也隨之傳播，大有取代用例分析方法之勢，或者說已經(jīng)取代了。但是用例分析方法的優(yōu)勢也許被埋沒了。本文試圖介紹一種擁抱敏捷的用例分析方法，把用例分析方法從RUP中分離出來，能夠為敏捷開發(fā)所用。
用例分析的職責(zé)
??????? 一個小人 和一個橢圓連根線組成了用例分析最基本的單元，簡單理解用例的話，其實并不復(fù)雜。但如果用例分析的目的是下面這些：
·???????? 找出用例中的執(zhí)行流程、事件的各個類。
·???????? 通過實現(xiàn)用例，把用例的行為指定到具體的類。
·???????? 找出類的責(zé)任、屬性和他們相互的關(guān)系。
·???????? 規(guī)范地確定系統(tǒng)中各用例的職責(zé)。
·???????? 在用例設(shè)計的時候，把業(yè)務(wù)概念抽象成類、對象、關(guān)系、組件、接口等等，這些都與目標(biāo)系統(tǒng)直接對應(yīng)。
??? ?????以上目的也許已經(jīng)嚇退一半以上的初學(xué)者。這樣目的的用例分析承擔(dān)了過多的職責(zé)，對用戶來說是不能理解用例之后的類的，對開發(fā)者來說，這些個要求未免也高了點。所以用例分析應(yīng)當(dāng)回歸到需求分析層面，能夠把用戶需求交代清楚，已經(jīng)是天下難事，就不必承擔(dān)什么類的識別這樣的額外任務(wù)了。
???????? 單一職責(zé)是OO當(dāng)中的概念，引申到用例分析，它的職責(zé)定位在了解用戶的需要，那么就應(yīng)當(dāng)把這個職責(zé)作為它的唯一職責(zé)。在用例分析時，不必考慮具體實現(xiàn)的類，專注于把用戶需要表達(dá)出來。
?
?
?????
從SRS看用例和用戶故事
???? SRS是software requirement specification的縮寫，中文譯為軟件需求規(guī)格書。SRS在當(dāng)年曾經(jīng)進入了ISO標(biāo)準(zhǔn)，在中國進入了國家標(biāo)準(zhǔn)，出現(xiàn)在大量的軟件工程教材當(dāng)中。根據(jù)SRS的要求，有不少SRS的文檔模板。SRS在整體上給出了要求，但在具體需求方面并沒有給出表示方法，因而大量的實踐是各種格式的文字，每家組織提供的SRS在大樣子上是相似的，但在具體需求方面表達(dá)方式各異。
???? 用例方法給出了用例規(guī)約的寫法，展現(xiàn)了具體需求，用例規(guī)約對于細(xì)節(jié)的展現(xiàn)能力是很棒的；用戶故事同樣對具體需求給出了寫法。在這點上后來的這兩個方法就要比SRS考慮得更加周到。
???? 在傳統(tǒng)軟件開發(fā)當(dāng)中，SRS要求是完備的、充分的，能夠指導(dǎo)后續(xù)設(shè)計開發(fā)。SRS雖然也能處理后續(xù)需求變更，但變更處理耗時耗力，很不靈活，很不敏捷。而用例分析所帶來的文檔在這方面是與SRS有相同的感覺，雖然RUP也強調(diào)迭代，精化，但還是要求用例規(guī)約能夠完備，詳細(xì)。不少組織在采用用例分析方法時，往往是從SRS轉(zhuǎn)到用例分析，看到了用例分析對于需求細(xì)節(jié)絕佳的展現(xiàn)能力，認(rèn)為這是用例分析較之于SRS的優(yōu)勢，不可避免的把完備、詳細(xì)的要求帶到了用例分析當(dāng)中。根據(jù)敏捷宣言以及現(xiàn)在對需求凍結(jié)實踐的總結(jié)回顧，現(xiàn)在已經(jīng)清楚的知道：需求變更是不可阻擋的，前期完備詳細(xì)的需求未必能指導(dǎo)后期開發(fā)，甚至可能成為負(fù)累。
???? 而用戶故事就是來自于敏捷開發(fā)的，天生注重響應(yīng)變化和可運行。所以可以看到，用戶故事既能展現(xiàn)具體需求，又不要求完備充分，講究剛剛好的表達(dá)，鼓勵擁抱變化。
???? 用例分析也可以追求剛剛好的需求表達(dá)，不必像SRS一樣要求完備和詳細(xì)。
條目化管理的需求
???? 常見的SRS可能是一份數(shù)十頁甚至上千頁的文檔，用例分析形成的文檔一般是UML工具生成的文件。而用戶故事形成的文檔天生是條目化管理的。同時擁有具有如下的優(yōu)點：
1， 逐條表達(dá)，可以逐條修改，如果有工具支持，可以讓多個人同時修改；
2， 方便跟蹤，如果是在白板上，可以方便的移動；
3， 方便檢索 ；
4， 如果有工具支持，能夠記錄變更的所有歷史。
???? 而UML工具生成的文件相比于用戶故事就顯得不方便。如果用例也能夠條目化管理，就也能獲得以上的好處。雖然現(xiàn)在沒有現(xiàn)成的工具同時支持用例圖和用例的條目化管理，但組合兩樣工具就能方便的獲得。具體方法是利用條目化管理工具（比如Mantis，VSTS，JIRA，ClearQuest等，紙片+白板也是工具之一）記錄用例，字段設(shè)置參照用例規(guī)約的要求，但注意這些字段大都允許為空，并加設(shè)狀態(tài)字段，常用的狀態(tài)字段有“新建”、“采納”、“活動”、“完成”。利用UML工具來繪制用例圖和用例相關(guān)的其他圖（比如活動圖，泳道圖），用例圖是幫助理解需求的絕佳工具，但不是所有的用例都要在用例圖上出現(xiàn)的，只需要把需要的用例繪制在用例圖上，如果用例之間關(guān)系并不復(fù)雜，不用畫用例圖也是完全可能的。在兩個工具之間協(xié)作用例，唯一需要注意的是要保證用例命名的一致性。
?
承載的信息
???????? Mike Cohn推薦的用戶故事的基本格式如下。
????????????? As a <type_of_user> I want <some_goal> so that <some_reason>.
在實際使用時，更多見的是
????????????? 作為[什么類型用戶]，我想要 [做什么]，這樣就可以[達(dá)到什么目標(biāo)]
????? 就這句話而言，對用例了解的朋友就能想到一個小人連著一個橢圓，小人就是這個用戶，用例的名稱就是“做什么”，而用例規(guī)約中的目的就是“達(dá)到什么目標(biāo)”。
??????? 用戶故事能夠擴充，可以加上場景描述，可以加上測試確認(rèn)條件等等。這些對于用例來說，不是難事。用例規(guī)約可以提供足夠的空間來記錄任何描述，有不少現(xiàn)成的方法來使用基本流和備選流來描述場景。如果工具支持，可以直接將測試確認(rèn)條件寫成于用例關(guān)聯(lián)的測試用例。
?????? 所以，用戶故事所能承載的信息并不比用例多，利用用例完全能夠承載用戶故事所含有的信息。如果把用戶故事轉(zhuǎn)換到用例，可以做到信息無損。
??????
用例分析的優(yōu)勢
????????? 用例除了能夠承載以上提到的信息之外，還有用例圖，能夠清晰的表達(dá)多個角色和多個用例之間的關(guān)系。比如下圖所示，用例圖能夠帶來更為清晰的業(yè)務(wù)理解。
?
???? 用例分析對后續(xù)的工作更有指導(dǎo)作用，雖然前文指出放棄用例分析對后續(xù)設(shè)計的指導(dǎo)目的，只需專注于需求，但仍然給后續(xù)的設(shè)計編碼有更清晰的指導(dǎo)，對于已經(jīng)了解RUP和OOAD的朋友來說，處理用例更是輕車熟路。
???? 當(dāng)對用例規(guī)約的各個字段（基本流、備選流、前置條件、后置條件、特殊需要、擴展點等等）提出強制要求時，往往把這些看成是繁瑣的、麻煩的；但如果是根據(jù)需要可選的，那么也就可以看到“用例分析方法擁有豐富的細(xì)節(jié)表現(xiàn)力”。
總結(jié)
??????? 經(jīng)過以上的分析修改，用例分析不再是為RUP服務(wù)的一個環(huán)節(jié)，只專注于表達(dá)用戶需要，不再承擔(dān)原來Rational 4+1視圖中所意味的繁重職責(zé)。不再為了分析得到某個類而糾結(jié)于對應(yīng)的用例規(guī)約應(yīng)當(dāng)如何寫。
??????? 用例分析的文檔也不再求全責(zé)備，而是根據(jù)剛剛好的原則，像用戶故事一樣，用戶沒有說到的地方可以留空，不再強求用戶一定要說清楚。根據(jù)已經(jīng)獲得的用戶需要來更早的獲得可運行的軟件。
?????? 用例不再位于某個UML文件中的某個角落，而是在一個可以方便檢索、修改的條目化管理系統(tǒng)中（包括白板+紙片）。
?????? 所以，對于已經(jīng)采用用例分析的組織，沒有必要改成用戶故事，對用例方法進行像前文所訴的適應(yīng)性修改，就能獲得敏捷開發(fā)的好處，也能保留用例分析的優(yōu)勢。
????? 對于已經(jīng)采用用戶故事的組織，不妨看看用例分析方法，用例分析方法擁有豐富的細(xì)節(jié)表現(xiàn)力，能清晰的展現(xiàn)業(yè)務(wù)邏輯過程全景，對關(guān)鍵流程不妨采用泳道圖，對復(fù)雜業(yè)務(wù)全景不妨采用用例圖。
?
?
總結(jié)
以上是生活随笔為你收集整理的拥抱敏捷的用例分析方法的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： Just enough（刚刚好）的软件开
- 下一篇： CMM/CMMI的20年和敏捷十年