Java 建模： 子整體軟體開發，第二部分

Java 建模： 子整體軟體開發，第二部分		英文原文

內容： 軟體不可見度 恰當過程的選擇 軟體需求規範 用例 功能特性 使用者劇本 結論 參考資料 關於作者 對本文的評價 相關內容： Java 建模系列所有文章 XP 精粹 Java 專區還包含： 教程 工具和產品 代碼和組件 相關文章 需求收集：工作的恰當過程 Granville Miller（rmiller@togethersoft.com） 顧問和開發人員，TogetherSoft 2001 年 10 月 Granville Miller 繼續他關於子整體軟體開發的討論，並在概念上對需求收集作了概括。 讓我們看看四個最常見的需求收集過程 — 功能特性、使用者劇本、用例和傳統的軟體需求規範 — 怎樣適應靈活的軟體開發過程更廣闊的環境。 請在討論論壇與作者和其他讀者分享您關於本文的想法。 在上一個專欄中，我開始討論子整體軟體開發，它是一種注重對過程進行革新的開發方法。 這是我的信仰，正如我在上個月的宣言中所述，子整體軟體開發有潛力讓開發人員取得非凡的成就。但是，這並不意味著我鼓吹完全排除過程。我看待過程的哲學可以總結如下： 過程太少，非凡的人能做平凡的事； 過程太多，即使是非凡的人也不能做非凡的事。 這個月，我將討論子整體軟體開發和過程的應用。尤其是，我們將談到需求收集 — 任何軟體開發週期的基礎，還將談到子整體方法 — 一種在開發週期中動態實現大量過程和方法的手段 — 如何能夠增強您的需求收集過程。 軟體不可見度問題 新軟體應用程式概念化的痛點因項目的不同而不同。雖然某些項目的需求很直觀 — 或許就像把一項新技術應用於一個著名的領域 — 但其它項目需求可能更複雜。當我們不斷的將軟體技術用於未知領域，為軟體系統建立需求的行為成為一種概念上的革新。這種革新不只是一種個體的複雜的腦力勞動，其難處還在於與更大的開發團體進行交流。 Frederick Brooks 把那些難以概念化和描述的新軟體應用程式的屬性稱為軟體不可見度。雖然其它如硬體之類的領域存在物質表現形式，但軟體領域沒有。我們可以看得見或者評測出軟體應用程式的效果，不過其系統資料表現形式本質上卻是思維的。這就是我們建立並依賴於軟體模型的許多原因之一。模型賦予軟體物理維度使我們得以更好的瞭解和表達它的方向。 任何軟體建模工作的中心是需求收集。實現需求收集過程的選擇依賴於開發項目更大的環境。 這個環境可以在需求收集過程自身中找到，也可以在另一個受到好評的模型中找到。在某些情況下，這個環境甚至可以在可交付使用的過程中找到。通過對我們探討的不同需求可能性的地方進行考察，我們總能夠辨別出系統的需求環境駐留在什麼地方。需求環境是我們與軟體不可見度對抗的領域。 恰當工作過程的選擇 為實現所選擇的需求收集過程極大的影響著軟體開發項目的成功。因為需求收集是開發週期的基礎，一個無效或選擇欠妥的需求分析過程極大的增加了項目失敗的可能性。這種可能性導致我們死守著已知的過程，通常與一個單獨的、受偏愛的軟體開發方法有關。 這裡將探討的需求收集過程抽象自三個一流的軟體開發方法：“Rational 統一過程”（ Rational Unified Process（RUP）），“功能驅動開發”（Feature-Driven Development（FDD））和“極端編程”（ Extreme Programming（XP））。每種方法都提供大量極好的工具以協助需求收集工作。為符合子整體開發方法，我們將更多的著眼於必要的部分 — 與每種方法相關的需求收集過程 — 而不是整個方法自身。 除此之外，我們還會看看是否能夠組織起一個更動態更可變的需求收集過程。繼續討論前，請用一些時間閱讀這篇補充文章“子整體軟體開發的十項準則”，看看子整體方法在理論上如何包含我們已知的東西。 四種最常見的需求收集過程是傳統的軟體收集規範（software requirements specification，SRS）、用例（use cases）、功能特性（features）和使用者劇本（user stories）。在隨後的幾個小節，我們將考慮每個過程，請特別注意需求環境 — 就是說，每個過程提供的用於將價值最大化的恰當情況和每個過程給開發項目帶來的獨特動力。有關以下概括的每個過程的應用的詳細資料，請參閱參考資料。 軟體需求規範 軟體需求規範（SRS）是最古老的需求收集過程之一。其非正式的名稱是“應該陳述”（shall statements），傳統的 SRS 有多種形態，而且，今天眾多領域的承包工程仍然需要用到它。SRS 許多年來一直是處於支配地位的需求收集方法。 SRS 背後的思想是建立一個解決方案空間 — 也就是這樣一個空間，其中開發小組已經設定了目標，但是，實現這些目標的行動的秩序和本質可以非常自由。因此，SRS 通常不試圖指定單個解決方案，而是指定一系列可行的解決方案。然後，開發小組有足夠的靈活性對解決正被建立系統問題的有效方法進行革新。 靈活性對於 SRS 來說，是缺點，也是優點。如果一個軟體開發小組精通他們為之建立系統的這個領域，這個小組就可以便於使用 SRS 最大限度的對這個領域進行革新。但是，在開發小組在他們不熟悉的領域進行日常工作的時代，傳統的 SRS 作為需求收集過程可能有所欠缺。典型使用者試圖處理給定領域中的正常情況時，他們採取的步驟很可能是小組成員不瞭解的。因此，小組成員確定並建立的系統對於使用者社區來說，可能不是最優的。 傳統的 SRS 最適用於已被充分瞭解的領域和非常瞭解自己所處工作領域的開發小組 — 或者領域之外的專業知識能夠很輕鬆就理解的開發環境。SRS 允許幾乎不需任何技術就可以調整解決方案空間以管理系統中的更改。 用例 與傳統 SRS 支援的解決方案空間方法相比，用例描述了使用者與系統互動時執行的動作序列。從某種意義上說，用例基於路線或目的。它傳達一系列使用者在使用系統以解決問題時必須啟動的動作。例如，在一個“錄影帶出租”用例中，我們對使用者與錄影帶出租系統互動時會出現的情況進行了描述。 用例反應我們試圖使用軟體系統以達到目的時可能出現的所有事件。因為大部分軟體系統支援多個目的，大部分用例模型由多個用例組成。例如，“支付逾期費”（Pay Late Fee）用例描述了錄影帶出租系統的使用者遇到要支付逾期費這種情況時會發生的事。 用例中資訊正確的水平是成功建立應用程式的必要條件。它根據環境不同而不同。如果領域的專家參與開發過程，用例就可以只勾畫系統的路線。如果領域專家不參與項目，用例就有必要提供更多資訊。用例是交流需求的最佳過程。但是，就像傳統的 SRS，用例更適合已被很好瞭解的領域。用例可以經受一定程度的更改，但其它過程更能適應更改。 錄影帶出租用例 以下用例用於定義自動的（基於 Web）錄影帶出租方案中客戶最佳的路線。 用例名稱：出租錄影帶 唯一的用例 ID：VS-01 主要參與者：客戶 次要參與者：N/A 簡要描述：這個用例描述了當客戶基於 Web 租借錄影帶時發生的互動行為。 觸發事件：客戶從片名目錄中選擇片名。 前提條件： 客戶必須有一個活動帳戶。 客戶滿足片名目錄附帶的錄影帶分級的年齡要求。 片名目錄隨片名提供。 事件流： 客戶瀏覽片名目錄並選擇一個片名。 如果存在此片名，系統把這片名對應的介質添加到購物車中，介質就處於待租狀態。 客戶完成介質選擇後，他就下定單。若要下定單，就需要讓客戶通過身分識別驗證並保證帳戶有效。 介質費用從使用者帳戶記入借方（系統）。購物車中和訂單相關的介質就轉變成“已出租”。 系統對訂單進行確認。 後續條件： 為這個帳戶建立一個新的訂單。 修改庫存以反應已出租的錄影帶。 系統已將帳戶記入借方（系統），並按錄影帶租金把交易記入貸方（客戶）。 可選的事件流和異常： 片名不存在：客戶必須作出另外的選擇。 因未支付逾期費造成帳戶無效：請參閱“支付逾期費”用例。 因無效信用卡造成帳戶無效：系統提示使用者輸入有效信用卡帳戶。 功能特性 功能特性是系統期望功能的簡要表述。功能特性的格式為： <action> the <result> <by|for|of|to> a(n) <object> 一個樣本功能特性可以是： Forecast the total of quarterly sales. 在每個功能特性保持在最小狀態時，基於功能特性的方法效果最好。一個小組能在兩星期或更少時間內實現的功能特性就是理想的功能特性。 用名為功能集（feature set)的組將功能特性組織起來。功能集包含描述給定目的或領域的功能特性。功能集和它的功能特性僅對需求進行了概述。作為描述需求的機制，功能特性必需和額外的環境相結合。 在“功能驅動開發”方法中，環境被精心設計成介於功能集和一個被稱為“領域中立組件”（domain neutral component）的色彩標記類圖表之間。 領域中立組件是個描述跨領域公用關係的語義模板。領域中立組件由瞬間間隔（moment-interval）、角色（role)、主題（subject）（當事人（party）、地點或事務）以及描述（description）組成。瞬間間隔是那些領域的短時間要素，如處於訂貨執行系統的一個訂單。角色是個使用者，系統和他互動並必須能識別出他。主題是形成領域的要素。描述是一種抽象，它集合了這些對象的元資訊。圖 1 是個錄影帶出租的領域中立組件。 圖 1. 錄影帶出租方案的領域中立組件 作為一種需求收集過程，“功能驅動開發”非常靈活，它有助於在開發週期中更改管理。這一過程讓您在項目進行過程中輕鬆檢查並記錄新的、更改的和已除去功能特性的數目。因為一般來說功能特性小， 更改現存功能特性或添加新功能特性不大可能要求在項目級上大量的返工。功能特性還有助於挑戰軟體不可見度，因為作為跟蹤領域中立組件中的系統實體間互動結果的新功能特性可能被揭示。 功能特性可以用於熟悉給定領域的個體間的需求交流。以這種方式使用，基於功能特性的方法很可能是最節約的需求收集過程。但是，這些功能特性可能太依賴領域專業知識了，這是許多開發小組都沒有的奢侈品。 使用者劇本 使用者劇本是寫在索引卡上的簡短描述， 2 所示。 圖 2. 銷售使用者劇本的要點 使用者劇本包含的資訊往往比功能特性包含的資訊多，儘管這不是必要條件。“極端編程”方法中，使用者劇本要求一個現場的客戶提供部分環境。現場客戶向開發小組描述理想的系統。然後，這個小組一點一點建立系統，給客戶充分的機會定期查看結果。客戶“監督著”這個可交付使用過程，並且在新使用者劇本中提出對系統的修改建議。整個環境由現場客戶的反饋和遞增的過程及交付相結合。 使用者劇本對於處理軟體不可見度風險最高的項目來說，是最佳的方法。像功能特性一樣，它們都足夠小，能被輕鬆更改。 因為它們的環境基於運作的系統和客戶，一經實現或不再有效都會被丟棄。但是，並不是每個項目都可以引入現場客戶，因此使用者劇本並不適用於每個項目。這種方法因其缺少客戶互動而喪失了它的優勢。 結論 本文討論的每種需求收集過程在恰當的環境中都有其優勢所在。但是，正如這篇討論所示，對於每種環境來說，不是每種需求收集過程都是理想的，它們自身甚至還不是必要的完整。子整體軟體開發的中心在於認識到單個過程或活動本質上的不完整，並且儘可能擴大這些用於減少這種不完整的解決方案的範圍。 補充文章“子整體軟體開發的十項最佳準則”討論了模組性。模組性允許兩種目的相同的活動可以互相代替。當用一種需求收集活動代替另一種時，重要的是把需求環境考慮在內。開發週期中途更改活動很可能會引入一組新的動力到項目。如果沒有考慮到環境，這種行動可能會成為災難。但是，仔細的計劃和執行後，引入新活動就能協助建立新的動力，從而促進了項目的成功。 下個月，我們來談 Web 服務基礎架構的建模。隨著我們調查這個軟體開發中新興的領域，我將提供更多具體的技術樣本和上兩個專欄一直在討論的最佳準則，所以，請別離開！ 參考資料 請參與本文的討論論壇。 要瞭解更多有關用例的知識，請參閱由 Frank Armour 和 Granville Miller 撰稿和維護的進階用例建模首頁。 Jeff De Luca 在他的文章“FDD 過程起源”（The original FDD processes）中提供了一個 FDD 起源的最佳介紹。 XP 新手可能需要先通讀 Roy Miller 和 Chris Collins 撰寫的“XP 精粹”（developerWorks，2001 年 3 月）。 Extreme Programming.org，XP 狂熱者大量參考資料的寶庫，其中對 XP 開發過程的使用者劇本角色稍作展開介紹。 以使用者為中心的設計（user-centered design（UCD））是個很像需求收集和反饋過程的使用者劇本，但範圍更廣。找出如何使用便宜、低開銷的“Fly on the wall”方法（developerWorks，2001 年 8 月）以瞭解使用者需要什麼。 在 IBM Ease of Use 首頁，您會找到適合以使用者為中心設計的更多參考資料。 請閱讀 “Java 建模”歸檔檔案的所有 “Java 建模”專欄（包括上個月的子整體軟體開發宣言）。 請在 developerWorks Java 技術專區尋找更多 Java 參考資料。 關於作者 Granville 對於物件導向社區已經有十幾年的經驗了。他是進階用例建模系列的合著者，並在全世界範圍的各種物件導向技術會議中介紹過教程。他的物件導向開發的實踐方法來自於他在多家公司供職的經驗，其中包括從處於創業階段的公司到相當成熟的軟體業巨人在內的各種公司。他目前正在教授有關靈活過程、方法和 Java 技術的研習班、教程和課程，同時還在輔導和協助實現一些有作為的項目。請通過 rmiller@togethersoft.com 與 Granville 聯絡。