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