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

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

于是,就有了本書。

什么是用例?

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

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

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

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

2. 用戶打開爐門,把食物放入微波爐,關好爐門;

3. 用戶設置火力;

4. 用戶設置加熱時長;

5. 用戶啟動微波爐;

6. 微波爐運轉加熱食物,直到超過用戶已設置好的運行時間;

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

8. 用戶關閉微波爐的電源。

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

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

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

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

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

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

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

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

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

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

非也。

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

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

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

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

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

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

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

本書共分為7章。

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

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

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

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

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

......