軟件和需求的實踐

軟件開發人員總是在困惑為什么軟件分明是按照需求做出來的，可是客戶為什么仍然不滿意?？蛻艨偸窃诶Щ鬄槭裁窜浖妥约合胍牟罹鄷敲创?。這究竟是怎么回事？如何才能把開發人員和客戶之間的溝壑填平？本文作為這個關于需求的軟件工程專欄的第三篇，將向您介紹這個把客戶和開發人員聯系在一起的工具――UML（統一建模語言，Unified Modeling Language）。 

一個軟件系統的開發過程說到底就是由客戶提出需求，再由開發人員將之翻譯成機器能夠理解的語言，構建成系統，交付給客戶使用。在客戶看到軟件的時候，客戶通常會說一句話："哦，那正是我所說的，但那不是我想要的。"

即使是開發人員異常的盡責，花費大量的時間了解客戶需求，依然避免不了出現上述的客戶抱怨。更何況開發人員通常都想當然的認為自己已經了解了需求，并喜歡按照自己的想法給軟件加入一些新特性（feature）。在這樣的情況下，用戶的"真正"的需求就更加得不到保障了。

出現了什么問題？因為大部分的軟件開發工作都是Program Oriented，而不是Customer Oriented。開發人員認為自己已經了解了客戶的需求；客戶表達不出或是表達不全自己的需求；開發人員抱怨客戶經常修改需求；客戶不明白軟件開發為什么有如此多的限制…。所有這些，都是Program Oriented的軟件開發模式避免不了的弊病。

歸根結底，這些問題都是由于客戶和開發人員的立場不同而導致的。

所以呢，在客戶和開發人員之間，缺少一種東西來把他們聯系在一起。因此，眾多的方法學，都把這個問題視為重中之重。

1. UML
UML（統一建模語言，Unified Modeling Language）是一種面向對象的建模語言。在軟件工業化方面做出了杰出的貢獻。被OMG（Object Management Group）采納為業界標準。

UML就是解決上面這個問題的一個相當有代表性的例子。UML的實質，就是一種溝通方法，就象是英語能夠解決把世界各地的人交流的問題一樣。

2. UML起源
公認的面向對象建模語言出現于70年代中期。1989年到1994年是建模語言的戰國時期，其數量從不到十種增加到了五十多種。雖然有利于學術的發展，但是對于最終用戶來說，了解眾多的建模語言是一件非常沒有必要的事。在建模語言的戰國時期出現了三個強者：Grady Booch，James Rumbaugh和Ivar Jacobson（人稱"The Three Amigos"），以及他們的方法：Booch 1993、OOSE和OMT-2。

Booch是面向對象方法最早的倡導者之一，他提出了面向對象軟件工程的概念。Booch 1993比較適合于系統的設計和構造；Rumbaugh提出了面向對象的建模技術（OMT）方法，采用了面向對象的概念，并引入各種獨立于語言的表示符。這種方法用對象模型、動態模型、功能模型和用例模型。 OMT-2特別適用于分析和描述以數據為中心的信息系統；Jacobson于1994年提出了OOSE方法，其最大特點是面向用例（Use-Case），并在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器，但用例貫穿于整個開發過程，包括對系統的測試和驗證。OOSE比較適合支持商業工程和需求分析。

天下大勢，分久必合。Grady Booch，James Rumbaugh和Ivar Jacobson三個人的方法各有所長，而用戶有希望能夠有一種標準出現，結束混亂的百家爭鳴的現狀。1994年10月，Grady Booch和Jim Rumbaugh開始致力于這一工作。他們首先將Booch9 3和OMT-2 統一起來，并于1995年10月發布了第一個公開版本，稱之為統一方法UM 0.8（Un ified Method）。1995年秋，OOSE 的創始人Ivar Jacobson加盟到這一工作。經過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發布了兩個新的版本，即UML 0.9和UML 0.91，并將UM重新命名為UML（Unified Modeling Language）。1996年，一些機構將UML作為其商業策略已日趨明顯。UML的開發者得到了來自公眾的正面反應，并倡議成立了UML成員協會，以完善、加強和促進UML的定義工作。當時的成員有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Microsoft、Oracle、Rational Software、TI以及Unisys。這一機構對UML 1.0（1997年1月）及UML 1.1（1997年11月17日）的定義和發布起了重要的促進作用。

UML是集合了眾家之長的建模語言，從誕生的那一天開始，就經過了不斷的驗證和修改，它著重強調的是一種標準的建模思想，但它并不是一種標準建模過程，對于不同的軟件企業來說，建模的過程是不同的。UML并沒有特定的平臺，與具體的實現無關。它是一種圖形化的面向對象建模語言。UML通過不同的圖形表示來捕捉系統靜態結構和動態行為的信息，建立起對象模型。不同的圖形是從不同的角度來看待系統。由于UML的獨立性，所以它可以通過專用的工具轉化成具體的編程語言，或是從編程語言代碼轉回UML，這叫做"逆向工程"。

3. UML是什么
UML的概念包括了UML語義（Semantics）和UML表示符（Notation）兩個部分，UML語義定義了結構（Structural）模型和行為（Behavioral）模型。結構模型（又稱為靜態模型）強調系統的對象結構，如對象的類（Classes）、接口（Interfaces）、屬性（Attributes）和關系（Relations）；行為模型（動態模型）關注的是系統對象的行為動作，如對象的方法（Methods）、交互（Interactions）、協作（Collaborations）和狀態（State Histories）。以此為基礎，UML為UML表示符提供了完整的語義定義。UML的表示符包括了下面的幾種主要的圖：類圖（Class Diagram），用例圖（Use Case Diagram），順序圖（Sequence Diagram），協作圖（Collaboration Diagram），狀態圖（State Diagram），活動圖（Activity Diagram），部署圖（Deployment Diagram）語義由于我們的討論重點并不是UML語言，我們只是簡單的介紹UML的實際應用，如果大家對UML有興趣，可以參看《UML1.3白皮書》。

4. 用例圖和用例
用例圖（Use Case Diagram）是UML中最簡單也是最復雜的一種圖。說它簡單，是因為采用了面向對象的思想，又是基于用戶視角的，繪制非常容易，簡單的圖形表示讓人一看就懂。說它復雜是因為用例圖往往不容易控制，要么過于復雜，要么過于簡單。一個系統的用例圖太泛不行，太精不行，太多不行，太少也不行。用例的控制可以算是一門藝術。突然想起當年我剛剛接觸UML的時候，對用例不屑一顧，認為是UML中最無用的一種圖，現在每每想到不禁感慨自己的愚蠢。

Use case diagrams show actors and use cases together with their relationships.『OMG-UML V1.3』

用例圖表示了角色和用例以及它們之間的關系。

A use case is a kind of classifier representing a coherent unit of functionality provided by a system, a subsystem, or a class 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』

用例描述了系統，子系統和類的一致的功能集合，表現為系統和一個或多個外部交互者（角色）的消息交互動作序列。

有點復雜是嗎，就是角色（用戶或外部系統）和系統（要設計的系統）的一個交互，為了實現一個目的（Goal），這個目的的描述通常是一個謂詞短語，例如，開立信用證，給客戶回單等。用例圖則圖形化的表示了這種關系。

一個具體的用例圖可能是這樣的： 


　

5. 用例和需求，用例和過程
可以說，之前說的所有的東西都是為了能夠導出用例在需求中的作用。用例是從用戶的角度看待系統，而不是基于程序員的角度。這樣的話，用例驅動的系統能夠真正做到以用戶為中心，用戶的任何需求都能夠在系統開發鏈中完整的體現。用戶和程序員間通過用例溝通，避免了牛頭馬嘴的尷尬局面。

從前，系統開發者總是通過情節來獲取需求，是問用戶希望系統為他做什么。在可愛的Jacobson發明了用例的概念之后，需求獲取就變成問用戶要利用系統做什么。這是立場不同導致的結果。用戶通常并不關心系統是如何實現的（也有少數可愛的技術狂是例外）。對他們來說，更重要的是要達到他的目的。相反的，大部分的程序員的工作習慣就是考慮計算機應該如何實現用戶的要求。所幸的是，用例方法能夠調和雙方的矛盾，因為雖然用例是來源于用戶，服務于用戶，但是它同樣可以用于開發的流程。當系統的開發過程都是基于用例的，用用例獲取需求，用用例設計，用用例編碼，用用例測試的時候。這個開發過程就是用例驅動的。

在具體的需求過程中，有大的用例（業務用例），也有小的用例。主要是由于用例的范圍決定的。用例像是一個黑盒，它沒有包括任何和實現有關或是內部的一些信息。它很容易就被用戶（也包括開發者）所理解（簡單的謂詞短語）。如果用例不足以表達足夠的信息來支持系統的開發，就有必要把用例黑盒打開，審視其內部的結構，找出黑盒內部的Actor和Use Case。就這樣通過不斷的打開黑盒，分析黑盒，再打開新的黑盒。直到整個系統可以被清晰的了解為止。

用例是重要的，用例圖只是用例的表達方式，其實用例的表達不僅僅是用例圖，還有很多方式，我們在下面會具體講到。

原文轉自：http://www.anti-gravitydesign.com