需求的實踐(3)—客戶定向,而不是程序定向

1、需求的實踐（3）客戶定向，而不是程序定向Customer Oriented，而不是Program Oriented 林星 ()2001 年 10 月軟件開發(fā)人員總是在困惑為什么軟件分明是按照需求做出來的，可是客戶為什么仍然不滿意。客戶總是在困惑為什么軟件和自己想要的差距會那么大。這究竟是怎么回事？如何才能把開發(fā)人員和客戶之間的溝壑填平？本文作為這個關(guān)于需求的軟件工程專欄的第三篇，將向您介紹這個把客戶和開發(fā)人員聯(lián)系在一起的工具UML（統(tǒng)一建模語言，Unified Modeling Language）。一個軟件系統(tǒng)的開發(fā)過程說到底就是由客戶提出需求，再由開發(fā)人員將之翻

2、譯成機(jī)器能夠理解的語言，構(gòu)建成系統(tǒng)，交付給客戶使用。在客戶看到軟件的時候，客戶通常會說一句話：哦，那正是我所說的，但那不是我想要的。即使是開發(fā)人員異常的盡責(zé)，花費(fèi)大量的時間了解客戶需求，依然避免不了出現(xiàn)上述的客戶抱怨。更何況開發(fā)人員通常都想當(dāng)然的認(rèn)為自己已經(jīng)了解了需求，并喜歡按照自己的想法給軟件加入一些新特性（feature）。在這樣的情況下，用戶的真正的需求就更加得不到保障了。出現(xiàn)了什么問題？因為大部分的軟件開發(fā)工作都是Program Oriented，而不是Customer Oriented。開發(fā)人員認(rèn)為自己已經(jīng)了解了客戶的需求；客戶表達(dá)不出或是表達(dá)不全自己的需求；開發(fā)人員抱怨客戶經(jīng)常修改

3、需求；客戶不明白軟件開發(fā)為什么有如此多的限制。所有這些，都是Program Oriented的軟件開發(fā)模式避免不了的弊病。歸根結(jié)底，這些問題都是由于客戶和開發(fā)人員的立場不同而導(dǎo)致的。所以呢，在客戶和開發(fā)人員之間，缺少一種東西來把他們聯(lián)系在一起。因此，眾多的方法學(xué)，都把這個問題視為重中之重。1. UMLUML（統(tǒng)一建模語言，Unified Modeling Language）是一種面向?qū)ο蟮慕ＵZ言。在軟件工業(yè)化方面做出了杰出的貢獻(xiàn)。被OMG（Object Management Group）采納為業(yè)界標(biāo)準(zhǔn)。UML就是解決上面這個問題的一個相當(dāng)有代表性的例子。UML的實質(zhì)，就是一種溝通方法，就象是

4、英語能夠解決把世界各地的人交流的問題一樣。2. UML起源公認(rèn)的面向?qū)ο蠼ＵZ言出現(xiàn)于70年代中期。1989年到1994年是建模語言的戰(zhàn)國時期，其數(shù)量從不到十種增加到了五十多種。雖然有利于學(xué)術(shù)的發(fā)展，但是對于最終用戶來說，了解眾多的建模語言是一件非常沒有必要的事。在建模語言的戰(zhàn)國時期出現(xiàn)了三個強(qiáng)者：Grady Booch，James Rumbaugh和Ivar Jacobson（人稱The Three Amigos），以及他們的方法：Booch 1993、OOSE和OMT-2。Booch是面向?qū)ο蠓椒ㄗ钤绲某珜?dǎo)者之一，他提出了面向?qū)ο筌浖こ痰母拍睢ooch 1993比較適合于系統(tǒng)的設(shè)計和構(gòu)

5、造；Rumbaugh提出了面向?qū)ο蟮慕＜夹g(shù)（OMT）方法，采用了面向?qū)ο蟮母拍?，并引入各種獨(dú)立于語言的表示符。這種方法用對象模型、動態(tài)模型、功能模型和用例模型。 OMT-2特別適用于分析和描述以數(shù)據(jù)為中心的信息系統(tǒng)；Jacobson于1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，但用例貫穿于整個開發(fā)過程，包括對系統(tǒng)的測試和驗證。OOSE比較適合支持商業(yè)工程和需求分析。天下大勢，分久必合。Grady Booch，James Rumbaugh和Ivar Jacobson三個人的方法各有所長，而用戶

6、有希望能夠有一種標(biāo)準(zhǔn)出現(xiàn)，結(jié)束混亂的百家爭鳴的現(xiàn)狀。1994年10月，Grady Booch和Jim Rumbaugh開始致力于這一工作。他們首先將Booch9 3和OMT-2 統(tǒng)一起來，并于1995年10月發(fā)布了第一個公開版本，稱之為統(tǒng)一方法UM 0.8（Un ified Method）。1995年秋，OOSE 的創(chuàng)始人Ivar Jacobson加盟到這一工作。經(jīng)過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了兩個新的版本，即UML 0.9和UML 0.91，并將UM重新命名為UML（Unified Modeling Language）。19

7、96年，一些機(jī)構(gòu)將UML作為其商業(yè)策略已日趨明顯。UML的開發(fā)者得到了來自公眾的正面反應(yīng)，并倡議成立了UML成員協(xié)會，以完善、加強(qiáng)和促進(jìn)UML的定義工作。當(dāng)時的成員有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。這一機(jī)構(gòu)對UML 1.0（1997年1月）及UML 1.1（1997年11月17日）的定義和發(fā)布起了重要的促進(jìn)作用。UML是集合了眾家之長的建模語言，從誕生的那一天開始，就經(jīng)過了不斷的驗證和修改，它著重強(qiáng)調(diào)的是一種標(biāo)

8、準(zhǔn)的建模思想，但它并不是一種標(biāo)準(zhǔn)建模過程，對于不同的軟件企業(yè)來說，建模的過程是不同的。UML并沒有特定的平臺，與具體的實現(xiàn)無關(guān)。它是一種圖形化的面向?qū)ο蠼ＵZ言。UML通過不同的圖形表示來捕捉系統(tǒng)靜態(tài)結(jié)構(gòu)和動態(tài)行為的信息，建立起對象模型。不同的圖形是從不同的角度來看待系統(tǒng)。由于UML的獨(dú)立性，所以它可以通過專用的工具轉(zhuǎn)化成具體的編程語言，或是從編程語言代碼轉(zhuǎn)回UML，這叫做逆向工程。3. UML是什么UML的概念包括了UML語義（Semantics）和UML表示符（Notation）兩個部分，UML語義定義了結(jié)構(gòu)（Structural）模型和行為（Behavioral）模型。結(jié)構(gòu)模型（又稱為靜

9、態(tài)模型）強(qiáng)調(diào)系統(tǒng)的對象結(jié)構(gòu)，如對象的類（Classes）、接口（Interfaces）、屬性（Attributes）和關(guān)系（Relations）；行為模型（動態(tài)模型）關(guān)注的是系統(tǒng)對象的行為動作，如對象的方法（Methods）、交互（Interactions）、協(xié)作（Collaborations）和狀態(tài)（State Histories）。以此為基礎(chǔ)，UML為UML表示符提供了完整的語義定義。UML的表示符包括了下面的幾種主要的圖：類圖（Class Diagram），用例圖（Use Case Diagram），順序圖（Sequence Diagram），協(xié)作圖（Collaboration Diag

10、ram），狀態(tài)圖（State Diagram），活動圖（Activity Diagram），部署圖（Deployment Diagram）語義由于我們的討論重點并不是UML語言，我們只是簡單的介紹UML的實際應(yīng)用，如果大家對UML有興趣，可以參看UML1.3白皮書。4. 用例圖和用例用例圖（Use Case Diagram）是UML中最簡單也是最復(fù)雜的一種圖。說它簡單，是因為采用了面向?qū)ο蟮乃枷?，又是基于用戶視角的，繪制非常容易，簡單的圖形表示讓人一看就懂。說它復(fù)雜是因為用例圖往往不容易控制，要么過于復(fù)雜，要么過于簡單。一個系統(tǒng)的用例圖太泛不行，太精不行，太多不行，太少也不行。用例的控制可以算

11、是一門藝術(shù)。突然想起當(dāng)年我剛剛接觸UML的時候，對用例不屑一顧，認(rèn)為是UML中最無用的一種圖，現(xiàn)在每每想到不禁感慨自己的愚蠢。Use case diagrams show actors and use cases together with their relationships.OMG-UML V1.3用例圖表示了角色和用例以及它們之間的關(guān)系。A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class

12、 as manifested by sequences of messages exchanged among the system and one or more outside interactors (called actors) together with actions performed by the system. OMG-UML V1.3用例描述了系統(tǒng)，子系統(tǒng)和類的一致的功能集合，表現(xiàn)為系統(tǒng)和一個或多個外部交互者（角色）的消息交互動作序列。有點復(fù)雜是嗎，就是角色（用戶或外部系統(tǒng)）和系統(tǒng)（要設(shè)計的系統(tǒng)）的一個交互，為了實現(xiàn)一個目的（Goal），這個目的的描述通常是一個謂詞短語，例

13、如，開立信用證，給客戶回單等。用例圖則圖形化的表示了這種關(guān)系。一個具體的用例圖可能是這樣的：5. 用例和需求，用例和過程可以說，之前說的所有的東西都是為了能夠?qū)С鲇美谛枨笾械淖饔?。用例是從用戶的角度看待系統(tǒng)，而不是基于程序員的角度。這樣的話，用例驅(qū)動的系統(tǒng)能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統(tǒng)開發(fā)鏈中完整的體現(xiàn)。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。從前，系統(tǒng)開發(fā)者總是通過情節(jié)來獲取需求，是問用戶希望系統(tǒng)為他做什么。在可愛的Jacobson發(fā)明了用例的概念之后，需求獲取就變成問用戶要利用系統(tǒng)做什么。這是立場不同導(dǎo)致的結(jié)果。用戶通常并不關(guān)心系統(tǒng)是如何實現(xiàn)的（也有少

14、數(shù)可愛的技術(shù)狂是例外）。對他們來說，更重要的是要達(dá)到他的目的。相反的，大部分的程序員的工作習(xí)慣就是考慮計算機(jī)應(yīng)該如何實現(xiàn)用戶的要求。所幸的是，用例方法能夠調(diào)和雙方的矛盾，因為雖然用例是來源于用戶，服務(wù)于用戶，但是它同樣可以用于開發(fā)的流程。當(dāng)系統(tǒng)的開發(fā)過程都是基于用例的，用用例獲取需求，用用例設(shè)計，用用例編碼，用用例測試的時候。這個開發(fā)過程就是用例驅(qū)動的。在具體的需求過程中，有大的用例（業(yè)務(wù)用例），也有小的用例。主要是由于用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現(xiàn)有關(guān)或是內(nèi)部的一些信息。它很容易就被用戶（也包括開發(fā)者）所理解（簡單的謂詞短語）。如果用例不足以表達(dá)足夠的信息來支持系統(tǒng)

15、的開發(fā)，就有必要把用例黑盒打開，審視其內(nèi)部的結(jié)構(gòu)，找出黑盒內(nèi)部的Actor和Use Case。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統(tǒng)可以被清晰的了解為止。用例是重要的，用例圖只是用例的表達(dá)方式，其實用例的表達(dá)不僅僅是用例圖，還有很多方式，我們在下面會具體講到。6. 使用用例的誤區(qū)上面曾經(jīng)花了一些篇幅來說明用例的簡單和復(fù)雜的關(guān)系。在很多介紹UML的書中都會首先介紹用例圖，并會用一些近乎完美的例子來說明用例圖?？墒窃趯嶋H的使用過程中，都會有很多實際的問題。我咨詢過很多使用UML的朋友，發(fā)現(xiàn)或多或少都存在問題。用例的發(fā)明者Ivar Jacobson 曾經(jīng)說過，Ericsso

16、n花掉了上千萬元去研究建立Use Case模式的過程(process) 現(xiàn)在他任職的Rational公司也花掉不少錢研究開發(fā)過程的問題。大師花了數(shù)十年心血建立起來的理論體系并不是那么容易的。用例決不僅僅是定義Actor、Use Case、Association那么簡單。用例需要在很多的細(xì)節(jié)方面都做足功夫。我曾經(jīng)看過一個軟件企業(yè)推行Use Case圖，但是在花費(fèi)心血畫出了幾十張項目的用例圖后，設(shè)計編碼階段卻回到了從前的開發(fā)流程。用例的使用絕不僅僅是畫用例圖，用例也不是軟件團(tuán)體一步登天的捷徑。用例貴在思想，在軟件團(tuán)體中引入用例并能夠和團(tuán)體很好的融合，是一個漸進(jìn)的過程。因為在軟件工程領(lǐng)域應(yīng)用用例思想

17、涉及到的內(nèi)容方方面面。即使是用例圖的編號也是大有講究。對于一個沒有OO實踐經(jīng)驗的軟件團(tuán)體，從事這樣的作業(yè)，需要大量的工作，可以說是百業(yè)待舉。如果沒有長期的積累和探索，何來用例和軟件團(tuán)體的融合呢？7. 用例的觀點為什么說用例是有效的呢？在軟件開發(fā)的過程中，大部分問題的產(chǎn)生都是由于溝通的不暢。設(shè)計者和用戶溝通不暢，設(shè)計者和實現(xiàn)者的溝通不暢。軟件開發(fā)就是踢足球。教練、前鋒、中場、后衛(wèi)各顧各的，相互之間形成斷層，怎么能贏球呢？上面提到的一些應(yīng)用OO用例思想失敗的例子也表明，如果開發(fā)團(tuán)隊有人排斥用例思想的話，項目是不會成功的。用過Rose的人都知道，在Rose的界面中，有四種視圖（View）：用例視圖（

18、Use Case View），邏輯視圖（Logical View），組件視圖（Component View），部署視圖（Deployment View）。這個思路源于Kruchten大師提出來的41的觀點模式。其描述了系統(tǒng)開發(fā)工作的參與者使用者(end users) 、程序員(programmers) 、系統(tǒng)整合師(system integrators)、以及系統(tǒng)工程師(system engineers)等5 種人員心中所關(guān)切的焦點與看法。為了能夠把4種人不同的觀點統(tǒng)一起來，Kruchten大師提出了一個情節(jié)（Scenarios）觀點（這個詞翻譯的不好，如果有誰有更好的翻譯，請更正）。這個觀點

19、其實就是用例觀點（Use Case View）。在用例觀點的統(tǒng)一下，保證這四種觀點能夠相互協(xié)作，共同營造一種良好的開發(fā)氛圍，實現(xiàn)軟件項目的成功。那么，應(yīng)該如何營造一種和諧的氣氛呢？還記得在介紹UML語言的時候我們談過UML中的幾種圖嗎。這幾種圖都不是孤立的。在畫出一份用例圖后，通常都會用順序圖和狀態(tài)圖來規(guī)定用例圖的規(guī)格，這些都是Rose中的用例視圖。在用例圖中，我們可以分析出基本的類，并將類組織成包，并將其分配到系統(tǒng)的三層結(jié)構(gòu)中，這是Rose中的邏輯視圖。在寫出基本類之后，我們還可以將類組織成組件（針對特定的架構(gòu)，如J2EE或COM），這是Rose中的組件視圖。把組件部署實現(xiàn)，就是Rose中的

20、部署視圖所關(guān)心的。（需要指出的是，Rose中的視圖與Kruchten大師的4+1觀點有些許出入，Rose中的組件視圖相當(dāng)于Kruchten大師的Development觀點和Process觀點。）（注：這里的View對應(yīng)的有兩種說法：視圖和觀點。視圖是比較正式的說法，但是我覺得在通常得用語中，大多采用觀點的說法。所以這里的觀點和視圖表述的是同一個意思。）這里談到用例的觀點主要是要讓大家了解為什么會有用例的產(chǎn)生，以及在軟件開發(fā)中不同的人看待問題有不同的角度。8. 用例的不足用例的出現(xiàn)雖然能夠解決很大一部分問題，但是它并不是萬能的。The first is the matter of how dif

21、ficult it is to get a UML-like design into a state that it can be handed over to programmers. The problem with a UML-like design is that it can look very good on paper, yet be seriously flawed when you actually have to program the thing。（Fowler 2001）首先是把像UML那樣的設(shè)計圖交給程序員來實現(xiàn)是一件極為困難的事情。問題的關(guān)鍵在于那種設(shè)計看上去不錯，

22、可你打算編程來實現(xiàn)它的時候就出現(xiàn)了問題。不但是分析員和程序員之間的溝通存在問題，客戶和分析員之間的隔閡更大?？蛻魧τ谟美挠^點仍然不能夠接受，這仍然需要開發(fā)人員作出不懈的努力來調(diào)和這一矛盾。由于軟件工程最早提出是根據(jù)建筑方面的理論，所以很自然的就會把軟件工程和土木工程做一個比較。在土木工程中，設(shè)計圖和模型制定出來來需要嚴(yán)格的執(zhí)行?？墒牵篢he models that civil engineers use are based on many years of practice that are enshrined in engineering codes. Furthermore the ke

23、y issues, such as the way forces play in the design, are amenable to mathematical analysis. The only checking we can do of UML-like diagrams is peer review. （Fowler 2001）土木工程師使用的模型建立在多年實踐的基礎(chǔ)上，它們用土木工程的專用語言來描述。而且主要的問題在于，通常這種設(shè)計需要符合數(shù)學(xué)原理。而我們對UML之類的圖表唯一能做的就是同級檢查。看到問題所在了吧。單純的憑借沒有完善理論支撐的設(shè)計圖就輕率的決定這個軟件的設(shè)計是及其危

24、險的。不止一次的經(jīng)驗告訴我，一開始寫出的用例在項目結(jié)束時一看往往會嚇一大跳：設(shè)計和實現(xiàn)已經(jīng)完全脫節(jié)了。其中主要的代溝有兩個：客戶和開發(fā)人員之間，分析員和程序員之間。我們這里的重點在于客戶和開發(fā)人員之間的需求部分。需求的問題單單由UML語言來解決是不現(xiàn)實的，且不說國外的軟件環(huán)境那么好的情況下，客戶對于UML仍然不理解。國內(nèi)的情況要糟糕的多，大多數(shù)的客戶并沒有計算機(jī)方面的基礎(chǔ)知識，對于他們來說，只有一點：花錢買東西，天經(jīng)地義。在這樣的觀點下，軟件的開發(fā)過程就很難得到客戶的支持。所以這也是國內(nèi)ERP項目鮮有成功范例的一個重要原因。這時候，討論的問題已經(jīng)不是局限在技術(shù)層面了，主要的焦點已經(jīng)轉(zhuǎn)移到了管理

25、、營銷、談判技巧等方面了。UML的成功也是需要這個大前提在的。McConnell建議在一個大的項目中，編碼和單元測試的開銷占整個項目開銷的15%。而其中有很大一部分的時間都會花在BPA（企業(yè)流程分析）和BPR（企業(yè)流程再造）上面。因為有很多企業(yè)在實施電子化之前管理都不規(guī)范，以人治為主。對于軟件而言，不論其中的設(shè)計多么的成功，如果沒有各個環(huán)節(jié)輸入的準(zhǔn)確來保證，那結(jié)果是可想而知的。我的一個朋友開發(fā)過一套連鎖店管理的軟件，可是系統(tǒng)運(yùn)行以來，會計帳從未平過。其中主要的問題就是各個結(jié)點的輸入不規(guī)范。這種問題已經(jīng)不是計算機(jī)能夠解決的了。說到這里，有一個笑話，有一個特定行業(yè)的企業(yè)要開發(fā)一個管理軟件，于是我就給企業(yè)的負(fù)責(zé)人分析他的流程，突然他很驚訝的看著我：你是我們這個行業(yè)的嗎，怎么比我還熟。其實，我只是以邏輯的觀點來分析他們