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

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

于是,就有了本書。

什么是用例?

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

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

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

1. 用戶打開微波爐的電源;

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

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

4. 用戶設(shè)置加熱時長;

5. 用戶啟動微波爐;

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

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

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

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

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

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

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

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

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

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

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

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

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

非也。

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

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

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

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

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

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

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

本書共分為7章。

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

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

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

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

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

......