在過(guò)去十多年間的全球軟件(包括互聯(lián)網(wǎng)等)開(kāi)發(fā)界,最令人矚目、堪稱現(xiàn)象級(jí)的一場(chǎng)持續(xù)風(fēng)潮大概就屬“敏捷開(kāi)發(fā)熱”了,其中又以Scrum、XP(極限編程,也譯為極端編程)以及Lean(精益)、Kanban(看板)等為代表的敏捷方法與流派最為熱門。時(shí)至今日,可能很多人仍對(duì)當(dāng)年異�；鸨�的Scrum 認(rèn)證熱、人們爭(zhēng)先恐后地追求Scrum Master證書的場(chǎng)景記憶猶新。這場(chǎng)熱熱鬧鬧的敏捷運(yùn)動(dòng)帶來(lái)了各方面有好、有差的許多效應(yīng)。例如,源自XP的用戶故事(User Story)就順著這股浪潮,成為了一項(xiàng)知名度最高、Scrum+XP開(kāi)發(fā)的缺省配置,可謂“No.1”的敏捷需求技術(shù),同時(shí)在坊間也很少或很難聽(tīng)到針對(duì)它的任何批評(píng)意見(jiàn)。

用戶故事的優(yōu)勢(shì)顯然被高估了,其實(shí)際價(jià)值遠(yuǎn)沒(méi)有各種營(yíng)銷、推廣所宣傳的那么大。然而,遠(yuǎn)比用戶故事更為強(qiáng)大和實(shí)用、傳入中國(guó)已近二十年的另一項(xiàng)敏捷需求技術(shù)———用例(Use Case,也譯作“用況”“用案”等)卻被普遍忽視了,這不禁令人感到些許遺憾。

于是,就有了本書。

什么是用例?

簡(jiǎn)單地說(shuō),一個(gè)“用例”就是對(duì)用戶使用某個(gè)系統(tǒng)功能的具體執(zhí)行、交互流程的描述,即一個(gè)比較完整的“使用故事(Use Story)”。不要以為用例是多么高深、難懂的東西。其實(shí),不管是軟件還是硬件,地球上的任何產(chǎn)品、系統(tǒng)(或有使用價(jià)值的東西)都有用例,至少一個(gè)吧。在產(chǎn)品設(shè)計(jì)與需求分析的過(guò)程中,用例的分析與建模常常從畫系統(tǒng)的UML(Unified Modeling Language,統(tǒng)一建模語(yǔ)言)用例圖(Use Case Diagram)開(kāi)始。以下是一個(gè)日常生活中的例子,一個(gè)最簡(jiǎn)單的微波爐系統(tǒng)的用例圖可描繪如下:

圖中的UML橢圓符號(hào)“加熱食物”所標(biāo)記的就是一個(gè)用例。而一個(gè)用例的名稱反映了用戶針對(duì)某個(gè)特定系統(tǒng)或產(chǎn)品的一個(gè)功能目標(biāo),或者系統(tǒng)可為該用戶提供的一項(xiàng)有價(jià)值的服務(wù)。例如,用例“加熱食物”,它代表了微波爐的一項(xiàng)基本功能與服務(wù)———用戶可以利用微波爐來(lái)加熱食物。這既是一個(gè)用戶的目標(biāo)(User Goal),也體現(xiàn)了微波爐作為產(chǎn)品的一項(xiàng)使用價(jià)值。

用例圖主要用來(lái)提取和表示多個(gè)用例及其關(guān)系,那么一個(gè)用例的具體內(nèi)容又是什么呢?例如,用戶應(yīng)該怎么通過(guò)微波爐來(lái)加熱食物? 正確的使用流程和操作方法是怎樣的? 具體有哪些步驟呢? 用比較規(guī)范的用例交互腳本來(lái)描述“加熱食物”,其文本大致是這樣的:

1. 用戶打開(kāi)微波爐的電源;

2. 用戶打開(kāi)爐門,把食物放入微波爐,關(guān)好爐門;

3. 用戶設(shè)置火力;

4. 用戶設(shè)置加熱時(shí)長(zhǎng);

5. 用戶啟動(dòng)微波爐;

6. 微波爐運(yùn)轉(zhuǎn)加熱食物,直到超過(guò)用戶已設(shè)置好的運(yùn)行時(shí)間;

7. 用戶在聽(tīng)到微波爐的提示音、停止運(yùn)轉(zhuǎn)后,打開(kāi)爐門,取出食物,然后關(guān)上爐門;

8. 用戶關(guān)閉微波爐的電源。

您看,這就是用例(的基本流)———一個(gè)用戶如何用微波爐“加熱食物”的使用故事。在微波爐的用戶手冊(cè)上常常也能看到類似的介紹,形式與內(nèi)容非常簡(jiǎn)單,幾乎人人都能讀懂。用例技術(shù)是由來(lái)自瑞典的UML創(chuàng)始人、被稱為“UML 三友”之一的Ivar Jacobson在20世紀(jì)80年代中期發(fā)明的。20世紀(jì)70—80年代Jacobson曾長(zhǎng)期為愛(ài)立信公司工作(參與開(kāi)發(fā)程控交換機(jī)),他于1992年出版的名著《面向?qū)ο筌浖�工程�?OOSE)可謂是用例技術(shù)的奠基之作。1995年以后,用例與UML技術(shù)一起被整合進(jìn)了Rational公司的“統(tǒng)一軟件開(kāi)發(fā)過(guò)程”框架指南RUP(Rational Unified Process)之中。

我第一次接觸用例、UML是在1998年。那時(shí)由于要帶領(lǐng)研發(fā)團(tuán)隊(duì),我正式開(kāi)始學(xué)習(xí)了包括UML建模在內(nèi)的軟件架構(gòu)方法與技術(shù),并在RUP的相關(guān)文檔中看到了用例。說(shuō)實(shí)話,當(dāng)時(shí)我并不太理解一個(gè)個(gè)的軟件需求為什么要寫成用例那樣,用文本模板來(lái)寫,還包括若干步驟和字段,感覺(jué)有點(diǎn)麻煩。

直到2000年以后,當(dāng)我認(rèn)真讀完了繼Jacobson之后另一位用例大師AlistairCockburn的名著《編寫有效用例》之后,才逐漸深刻地體會(huì)到,除了描畫各種UML統(tǒng)一用例方法: UML與敏捷需求實(shí)踐圖形之外,文本用例與模板對(duì)于復(fù)雜軟件和系統(tǒng)需求分析的巨大價(jià)值。

如今自用例誕生,近三十年過(guò)去了,業(yè)界有哪些著名國(guó)際企業(yè)一直或仍在使用用例技術(shù)呢? 大家熟知的主要包括愛(ài)立信、IBM(于2003年收購(gòu)了Rational)、Oracle、Amazon等公司,涉及通信、IT、互聯(lián)網(wǎng)等行業(yè)。除了這些行業(yè)以外,過(guò)去這些年我自己也曾經(jīng)為國(guó)內(nèi)的其他一些行業(yè)(如證券、保險(xiǎn)、外貿(mào)、稅務(wù)等)中的知名企業(yè)或機(jī)構(gòu)講解過(guò)用例技術(shù)。雖然總數(shù)不算多,但用例技術(shù)在許多軟件工程比較成熟的研發(fā)組織中應(yīng)用也并不少見(jiàn)。尤其值得一提的是,兩大IT巨頭這些年主推的企業(yè)級(jí)開(kāi)發(fā)過(guò)程與方法———IBM的RUP與Oracle的OUM(Oracle統(tǒng)一方法)其實(shí)都源自于“UML三友”所引領(lǐng)研發(fā)的UP(統(tǒng)一過(guò)程),而用例驅(qū)動(dòng)開(kāi)發(fā)與可視化(包括UML)建模正是UP方法(家族)的兩個(gè)基本特征。

這些年在日常軟件開(kāi)發(fā)過(guò)程中,坊間常用到的需求技術(shù)除了用例以外,主要還有特性(Feature)、用戶故事等。那么,用例區(qū)別于其他需求技術(shù),有哪些獨(dú)特的優(yōu)點(diǎn)和價(jià)值呢?

用例在本質(zhì)上,是一種主要用自然語(yǔ)言編寫而成的規(guī)范、結(jié)構(gòu)化(模板化)的“需求程序(Requirement Program)”,一個(gè)比較完整的用例通常包含了名稱、前態(tài)、后態(tài)、基本流、擴(kuò)展流等若干項(xiàng)內(nèi)容,主要被用來(lái)描述產(chǎn)品(系統(tǒng)或軟件)的功能需求及其交互流。因此,用例文本通常也可以稱為功能的“用例腳本”或“交互腳本”。在工作與生活中我們常常可以看到許多案例,比如一件產(chǎn)品在使用、功能、交互等方面,其設(shè)計(jì)細(xì)節(jié),往往會(huì)直接影響到它的易用性與用戶體驗(yàn)。如果是一個(gè)復(fù)雜、上規(guī)模的軟件密集型的大中型產(chǎn)品或系統(tǒng),則常常包含了大量的需求或交互細(xì)節(jié),要想及時(shí)、準(zhǔn)確地發(fā)現(xiàn)和處理這些細(xì)節(jié)常常既費(fèi)時(shí)又費(fèi)力�！凹�(xì)節(jié)決定成敗,細(xì)節(jié)是魔鬼”,眾所周知的這些諺語(yǔ)說(shuō)明了簡(jiǎn)單的事實(shí)和道理。

研究UML與用例技術(shù)多年,我的體會(huì)是:與特性、用戶故事等其他需求技術(shù)相比,用例方法與技術(shù)的最大價(jià)值就在于通過(guò)其設(shè)計(jì)科學(xué)、系統(tǒng)、合理、規(guī)范的文本模板與相應(yīng)的分析過(guò)程和技巧,可以幫助產(chǎn)品的設(shè)計(jì)師(或需求分析師等)能夠有條不紊地把各種復(fù)雜、潛藏、難以發(fā)現(xiàn)和理解的需求及交互細(xì)節(jié)逐步挖掘出來(lái),并梳理、表達(dá)清楚,從而盡最大可能不遺漏(甚至可以提前預(yù)見(jiàn)到)那些關(guān)鍵的、對(duì)開(kāi)發(fā)成敗具有重要影響的需求。

不僅如此,用規(guī)范、格式化的用例腳本結(jié)合更加形象、直觀的UML圖形聯(lián)合建模,可以更加積極、有效地應(yīng)對(duì)常見(jiàn)的需求難題(比如管理好各種需求細(xì)節(jié),妥善應(yīng)對(duì)需求變化等),這也是“用例+UML”方法相較于其他需求方法所具有的一項(xiàng)明顯簡(jiǎn)單一句話,用例與UML建模的主要價(jià)值可以概括為:基于其他需求方法所欠缺的———流程化與結(jié)構(gòu)化(需求程序)的書面描述方式(包括文本與圖形建模等),可以更加精準(zhǔn)、有效地發(fā)掘、記載和管理好復(fù)雜的需求與交互細(xì)節(jié),做到化繁為簡(jiǎn)、抓住本質(zhì)。

相信讀完本書并經(jīng)過(guò)一段時(shí)間的實(shí)踐之后,您大概也會(huì)有類似的體會(huì)�？梢哉f(shuō),用例(與UML)建模是自1990年代以來(lái)現(xiàn)代軟件工程中最重要的需求技術(shù)(之一),在驅(qū)動(dòng)并保障各類復(fù)雜產(chǎn)品、系統(tǒng)與軟件的成功開(kāi)發(fā)中發(fā)揮了獨(dú)特的價(jià)值和重要的作用,用例分析作為當(dāng)代軟件與系統(tǒng)需求分析的一項(xiàng)重點(diǎn)(或核心)技術(shù)是當(dāng)之無(wú)愧的。

敏捷方法傳入中國(guó)也快二十年了,然而對(duì)于敏捷需求技術(shù),坊間一直廣泛流傳著許多似是而非的觀點(diǎn)或誤解,例如:用戶故事是敏捷的,用例是不敏捷的;用戶故事比用例更好、更先進(jìn);Scrum 必須用用戶故事,不能用用例。莫非自敏捷運(yùn)動(dòng)興起以來(lái),用例就真的已經(jīng)過(guò)時(shí)、落后了,應(yīng)該被用戶故事所淘汰了嗎?

非也。

前面提到的以實(shí)用用例技術(shù)而聞名的Alistair Cockburn,不但是當(dāng)年組建敏捷聯(lián)盟與簽署《敏捷宣言》的主創(chuàng)成員之一,而且同時(shí)也是敏捷方法水晶(Crystal)流派的創(chuàng)始人,他對(duì)于肯定用例在敏捷開(kāi)發(fā)中的重要價(jià)值以及優(yōu)先采用用例的主張與態(tài)度可以說(shuō)是非常堅(jiān)定和一貫的。而另一位知名的敏捷與極限編程專家Martin Fowler對(duì)“用例與用戶故事之爭(zhēng)”也持有相對(duì)中立的立場(chǎng)。他曾經(jīng)提到,在敏捷開(kāi)發(fā)實(shí)踐中用例與用戶故事兩者既可以結(jié)合一起使用,也可以分開(kāi)單獨(dú)使用(要么只用用例,要么只用用戶故事),不同的團(tuán)隊(duì)可根據(jù)自己的實(shí)際情況進(jìn)行選擇。

事實(shí)上,用戶故事只是一項(xiàng)源于XP的專用技術(shù),而Scrum 作為一個(gè)更加開(kāi)放、簡(jiǎn)約的敏捷、迭代開(kāi)發(fā)框架,其本身幾乎不含任何技術(shù)實(shí)踐,因而對(duì)于采用哪種需求技術(shù)也是持中立的態(tài)度。成功的Scrum 團(tuán)隊(duì)既可以采用用戶故事,也可以采用用例(故事),而具體采用哪種技術(shù)應(yīng)該由每個(gè)團(tuán)隊(duì)在實(shí)踐中因地制宜、按需(價(jià)值最大化、風(fēng)險(xiǎn)最小化)來(lái)配置。

此外,在用例編寫與建模的過(guò)程中,我們可以根據(jù)敏捷開(kāi)發(fā)的實(shí)際需要,采用各種不同的、從簡(jiǎn)單到復(fù)雜的描述形態(tài),例如從用例名稱、用例圖,到用例簡(jiǎn)述,以及UML的活動(dòng)圖、交互圖,乃至更加全面、詳盡的用例腳本等。可見(jiàn),用用例來(lái)描述需求,既可以比用戶故事更簡(jiǎn)單、方便,也可以比用戶故事更復(fù)雜和完善(比如達(dá)到測(cè)試級(jí)的精準(zhǔn)度)。

所以,用例分析是一項(xiàng)靈活、實(shí)用、適用面非常廣的敏捷需求技術(shù),它對(duì)于當(dāng)代軟件工程與下一代敏捷開(kāi)發(fā)(如Agile 2)的價(jià)值與潛力還遠(yuǎn)未被業(yè)界所真正、廣泛地認(rèn)識(shí)到。

經(jīng)過(guò)多年的發(fā)展與演化,目前用例方法與技術(shù)尚存在著幾個(gè)競(jìng)合流派(如Jacobson和Cockburn等),雖然它們大同小異且都出自同一個(gè)源頭,但是在一些具體的技術(shù)細(xì)節(jié)(包括術(shù)語(yǔ)解釋和用法等方面)上仍存在著不少差異;而且,盡管利用UML等標(biāo)準(zhǔn)圖形符號(hào)來(lái)描述用例這部分早已經(jīng)標(biāo)準(zhǔn)化了,但是用例文本模板至今還沒(méi)有出現(xiàn)一個(gè)像UML那樣被業(yè)界廣泛認(rèn)同的國(guó)際標(biāo)準(zhǔn)與正式規(guī)范。

以上這些情況導(dǎo)致坊間長(zhǎng)期一直存在著形態(tài)各異的多種用例模板或格式,給專業(yè)人士閱讀、理解和交流、分享用例腳本與系統(tǒng)需求及其相關(guān)知識(shí)帶來(lái)了不少困擾。因此,在日常需求工作中,如何仔細(xì)甄別各個(gè)流派方法的異同,有效地作出技術(shù)決策與取舍以獲得運(yùn)用用例技術(shù)的最佳收益,成為產(chǎn)品設(shè)計(jì)、需求分析相關(guān)領(lǐng)域的實(shí)踐者們必須面對(duì)的一個(gè)現(xiàn)實(shí)問(wèn)題。

本書根據(jù)筆者自2000年以來(lái)在用例與UML建模、需求分析與敏捷開(kāi)發(fā)方法的培訓(xùn)教學(xué)、咨詢等方面的研究與實(shí)踐經(jīng)驗(yàn),提出并重點(diǎn)介紹了整合用例、用戶故事與特性等當(dāng)代主流需求技術(shù)的統(tǒng)一用例方法(UUCM,a Unified Use Case Method),以揚(yáng)長(zhǎng)避短、兼收并蓄,消除或減少各流派方法之間的不一致性和分歧,更好地促進(jìn)“用例+UML”等分析與建模技術(shù)在下一代敏捷開(kāi)發(fā)中的應(yīng)用。

本書共分為7章。

第1章“產(chǎn)品與需求工程”作為全書的開(kāi)篇,回顧了與產(chǎn)品需求分析相關(guān)的一些基本概念和知識(shí),并簡(jiǎn)要介紹了用例分析在產(chǎn)品、系統(tǒng)或軟件開(kāi)發(fā)與需求工程中的關(guān)鍵位置和重要價(jià)值。

第2章“敏捷需求方法”是對(duì)全書主要內(nèi)容的綜述。首先回顧了敏捷開(kāi)發(fā)的起源,介紹了敏捷體系結(jié)構(gòu),以及以用戶故事為代表的敏捷需求實(shí)踐的現(xiàn)狀;然后,介紹了以用例為代表的成熟功能需求分析方法對(duì)于敏捷產(chǎn)品設(shè)計(jì)與交互設(shè)計(jì)的重要價(jià)值;最后,簡(jiǎn)要介紹了在16字“太極建模口訣”(由外而內(nèi),層次分明;動(dòng)靜結(jié)合,逐步求精)的指導(dǎo)下,基于用例與UML建模的統(tǒng)一用例方法的基本工作流程和步驟。

第3~6章是本書的重點(diǎn)。建議對(duì)用例、UML不太熟悉的讀者先閱讀第3~4章“用例基礎(chǔ)”與“UML 基礎(chǔ)”,以便對(duì)需求分析時(shí)常用到的用例與UML的一些基本概念、元素和技巧等內(nèi)容有一個(gè)大致的了解。

第5章“業(yè)務(wù)分析”,介紹了通過(guò)基于用例與UML建模的業(yè)務(wù)分析方法建立產(chǎn)品的業(yè)務(wù)模型(主要包含“一動(dòng)一靜”業(yè)務(wù)流程與業(yè)務(wù)對(duì)象兩個(gè)子模型)的基本流程、步驟和技巧,重點(diǎn)是如何利用業(yè)務(wù)用例圖提取業(yè)務(wù)流程,以及如何通過(guò)繪制UML活動(dòng)圖和序列圖來(lái)詳細(xì)分析業(yè)務(wù)流程。該章最后還簡(jiǎn)要介紹了用UML類圖建立業(yè)務(wù)對(duì)象模型的基本方法。

第6章“系統(tǒng)需求分析”,詳細(xì)介紹了通過(guò)基于用例與UML建模的系統(tǒng)需求分析方法建立系統(tǒng)需求模型(主要包含“一動(dòng)一靜”用例模型與非功能需求集兩個(gè)部分)的基本流程、步驟和技巧,重點(diǎn)是介紹如何通過(guò)編寫格式規(guī)范、清晰易讀的用例(交互)腳本來(lái)盡量精準(zhǔn)地描述復(fù)雜的系統(tǒng)功能需求及其細(xì)節(jié)。當(dāng)然,對(duì)于一些簡(jiǎn)單的系統(tǒng)功能,也可以不必編寫詳細(xì)的用例腳本,而是通過(guò)畫UML圖(如用例圖、活動(dòng)圖、序列圖)或者編寫特性清單等更加輕量的方式來(lái)表示。

......