第二章  開發流程    UML是從一大推面向物件分析與設計的方法論中所誕生出來的。在某種程度範圍內，這些方法論都會在圖形模型語言中混合某種開發流程，以說明軟體該如何開發下去。 1.反覆式和瀑布式的開發流程       兩者的本質差異在於：我們該如何把專案分解成一些比較小的部分。我們需要把專案加以分解，這樣一來大家就可以隨時掌握問題，並追蹤進度。 瀑布式開發風格是根據開發活動來分解專案的。為了編寫軟體，你需要進行一些特定的開發活動，包括：需求分析、設計、程式設計與測試。如果是一年的時間需要如下分配：

分析階段	設計階段	編碼階段	測試階段
2個月	4個月	3個月	3個月

反覆式開發風格則是根據不同的功能性子集合將專案分解開來。你可以把一年的專案分解成每次長達三個月的反覆。在第一次反覆中，我們會處理約1/4的需求，並且將者1/4的需求走完整個軟體開發的生命週期：分析、設計、編碼和測試。在反覆結束出，我們會喲偶完成1/4所需功能性的系統。接下來，我們會進行第二次反覆，它會在第6個月結束。
你可以採用混合式的解決方案，【McMconnel】一書中描述了一種分期交付式生命週期，它會先以瀑布式開發風格完成分析與高階的設計工作，然後將程式設計序與測試工作分成幾次反覆。以一年的專案為例：它可能會有長達4個月的分析與設計工作，然後以4次長達2個月的反覆來建構出系統。 OO社群長久以來一直偏好反覆式開發方式，而且我們可以放心大膽地說有非常多跟建立UML有關的人，至少都偏好某種形式的反覆式開發關係。 雖然大家都宣稱正在採用反覆式開發方式，不過實際上卻是按照瀑布式的方法在做。常見的特徵有： A、我們現在正在進行一次分析反覆，接下來會有兩次的設計反覆。。。。 B、這次的反覆的程式中有許多程式bug，不過我們最後將會把它們都清除乾淨。 評註：由於反覆式開發希望在反覆結束之後，可以產生具備產品品質、測試、整合過的軟體出來。所以如果反覆結束之後，程式中有許多bug，就不能說反覆結束。另一方面，這點反而像是瀑布式開發流程中編寫程式碼開發階段結束，下一步準備進行測試開發階段。 採用反覆式開發方式時常會用到的一種開發技術就是固定時間長度（time boxing）。它讓每次反覆都有固定長度的時間。如果你發現原本在某次反覆中想要建構的部分無法完全做完的話，那麼你必須決定要在這次反覆中將某些功能延遲處理；而不是將這次反覆的結束日期延後。 如果大家能夠經常性的將系統功能延後處理，那麼等到他們面對大的發行版本、需要對延後日期或功能做出明確抉擇時，就會有較好的經驗來處理它。另一方面，在反覆間延後處理某些功能，可有效幫大家學習如何找到真正的需求優先順序。 對犯法是開發方式來說，最常見的考量之一就是重寫編碼的議題。重寫程式比維護那些設計不好的程式更有效率。下面列出一些實際經驗，它們非常有助於讓重做變得更加有效率。

自動化的迴歸測試（automated resgression tests）	當我們正在改變一些東西時，它有助於我們快速偵測到任何程式的瑕疵：單元測試有一條不錯的經驗法則就是，單元測試的程式程式碼大小大約跟你的產品程式程式碼相當
重構（refactoring）	它是以有紀律方式改變現有軟體的一項開發方式。重構是將一連串小的、保留行為的轉換動作施行到程式程式碼庫的工作方式。
持續整合（continuous integration）	它能讓整個團隊保持同步，以避免痛苦的整合週期。這種做法的核心是已完全自動haunt的建構流程為基礎達到的。

2、預測式和自適應的規劃方式 預測式的解決方案想在專案初期做一些事，以便可以更加了解稍後會發生的事。採用預測式規劃方式時，我們可以把專案區分成兩個時期。在第一個時期，我們會先想出一個計劃，這時候計劃書是比較難預測的。不過，等到第二個時期，因為計劃書已經在實施當中了，所以他就變的比較容易預測。 在軟體專案中，增加它的複雜度的其中一個獨特來源就是我們很難了解軟體系統的需求為何。絕大多數專案都會經歷重大的需求劇烈變動：在專案後期發生需求變動。這些變動會撼動真個預測計劃的基礎。 評註：需求變動是所有軟體開發者心中的疼 另一種流派主張需求劇烈變動是不可避免的事。對許多專案來說，我們幾乎不可能讓需求穩定到可使用預測計劃。一方面是因為單憑想象就要知道軟體能做什麼是一件極度困難的事，另一方面則是因為市場環境會造成不可預測的變動。採用這個想法的流派倡導自適應規劃方式，可預測被他們視為幻影。他們採用規劃方式會將軟體專案中的變動視為一種常態。他們以控制變動的方式讓專案交出它所能做出來的最佳軟體；我們雖然會去掌控專案，不過，卻不認為它是可預測的。 評註：自適應將計劃驅動的流程縮短以為數週為單位的迴圈週期，在每一個週期中，我們根據當前的情況不斷地調整計劃以及計劃的執行過程，同時不斷地產生能夠工作的程式碼，並且不斷地將程式碼部署到應用環境中去。 對比兩種方式，有兩點建議： A、除非你有一份精確、穩定的需求，而且有把握他們不會發生顯著變動，要不然請不要做出一份預測性計劃 B、如果你無法獲得一份精確、穩定的需求，那麼採用自適應的規劃風格。 3、敏捷開發流程 敏捷開發流程本質上具有很強的自適應性。同時他們也是非常具有人員導向的開發流程。敏捷開發解決方案假設專案成功的最重要因素在於專案成員的職業素質，以及在人際關係上他們合作的情況究竟如何。至於他們所使用的開發流程或開發工具嚴格來說都只有次一級的效果。 評註：敏捷開發以使用者的需求進化為核心，採用迭代、循序漸進的方法進行軟體愛你開發。在敏捷開發中，軟體專案在構建初期被切分成多個子專案，各個子專案的成果多經過測試，具備可視、可整合和可執行使用的特徵。從這個定義我們就可以理解上面的那段話了，當一個專案被切換成一個個小專案時，如果某個開發人員負責的專案不夠穩定，就會出現“木桶效應”；如果一旦某幾個成員對專案不能夠完全理解，後期就會花費大量的時間用於整合。 4、Rational統一開發流程   RUP雖然被稱為開發流程，不過事實上他是一個開發流程框架，裡面提供跟開發流程有關的一整組字彙與鬆散的結構    當你在使用RUP時，你要做的第一件事就是選出自己的開發案例：它是你在專案中將會施行的開發流程。開發案例間的變異很大，所以不要奢望你的開發案例看起來會跟其他開發案例很像。 RUP本質都是反覆式開發流程。瀑布式開發風格並不符合RUP的精神。 所有RUP專案必須遵循下面四個開發階段： （1）、初始階段（inception）:它會對專案作出一個最初的評估結果。 （2）、詳述階段（elaboration）:它會找出專案的主要使用案例，並且會在幾次反覆中寫出軟體，以並讓系統的架構成型。在詳述階段結束結束時，你應該對需求有很好的體會，而且回一個大致上成形、可執行的系統，我們將把它當做後續開發工作的源頭。 （3）、構建階段（construction）：它會繼續進行寫軟體的過程，寫出發行出去的功能性。 （4）、移交階段（transition）:裡面會有各式各樣後期、不需要反覆進行的開發活動，可能會包含將軟體配置到資料中心、使用者訓練等等類似的事項。 評註：完成這4個階段稱為一個開發週期，它產生的軟體稱作第一代。除非生命結束，一個現有剷平可以通過重複下一個相同的起始、詳述、構建和移交四階段，各個階段的側重點與第一次不同，從而演進為下一代產品。這個時期我們稱之為演進（evolution）。最後伴隨著產品經過幾個週期的演進，新一代產品不斷被製造出來。 詳細可參考：http://www.ibm.com/developerworks/cn/rational/r-rudp/點選開啟連結 5、裁減開發流程以適合專案需要   軟體開發工作的進行方式會受到許多因素影響。因此我們總需要將開發流程加以裁減，以適合專案的特殊環境需要。 評註：模式——UML可以告訴我們該如何表達出面向物件設計的結果。相反地，從模式所看到的開發流程所得到的結果：它們可用來作為範例的設計結果。 模式不僅僅只包含一個模型而已，裡面也包括了採用這種做法的理由究竟為何。我們通常會說模式代表他對某種設計問題的解決方案。模式中必須清楚地點出問題所在、解釋它解決問題的理由，也會說明什麼環境下，我們可採用或不能採用這個模式。 模式之所以很重要，是因為他們是理解一種語言或模型技術的下一步。 6、在開發流程中使用UML 不論你是不是採用瀑布式解決方案，我們都依然會做分析、設計、編碼與測試等開發活動。你可以在具有一個星期長反覆的反覆式專案中，每個星期施行一次微型的瀑布式開發流程。 需求分析 在需求分析開發活動中，我們會試圖瞭解：針對我們將花費功夫的軟體，它的使用者與顧客究竟想要系統做些什麼事。與其相關的UML現有相關技術： A.使用案例（use case），我們會在裡面描述人們是如何跟系統互動的。 B.由概念性觀點所畫出來的類別圖（class diagram）,它是我們可拿出來建構領域中一組精確字彙的好方法。 c.活動圖（activity diagram），裡面可秀出組織的工作流程，以瞭解軟體跟人類活動間是如何互動的。 D.狀態圖（state diagram）,如果某個概念具有一種有趣的宣告週期時，它就會變得有用，裡面會秀出各種狀態以及改變狀態的事件。 在進行需求分析時，請記住，其中最重要的一件事是跟你的使用者與顧客溝通。 在分析時用UML的最大風險就是：那些領域專家無法完全理解你所畫出的圖。如果瞭解領域的人武大理解這張圖，那麼它所造成的後果比沒有用更糟；因為它會引起大家對開發團隊的不信任感。 設計 當你在進行設計工作時，你可以在圖中加入更多技術細節。一些相關技術包括： A、由軟體觀點所畫出的類別圖，裡面會秀出軟體中的類別，以及他們間是如何相關的。 B、常見情節的時序圖（sequence diagram）。一種很有價值的做法是從使用案例中找出最重要、最有趣的情節，然後用CRC卡（CRC card）或時序圖畫出軟體中會發生什麼情形。 C、用打包圖（package diagram）畫出軟體中大型結構的組織方式。 D、針對有複雜生命歷程的類別，畫出他們的狀態圖 E、用配置圖（deployment diagram）畫出軟體的實體安排情形。 不論是下藍圖或草稿做法，找尋設計上的一些替代方案，這對我們來說都是有意義的事。我們通常最好是在草稿模式下探索這些不同替代方案，因為它可讓我們快速產生這些替代方案，並修改它們。 文件 一旦你寫好軟體之後，你可以用UML來幫你記錄下來什麼東西已經完成。針對這點，我發現UML的圖有助於大家對系統產生一個整體瞭解。寫文件的人需要決定什麼東西重要、什麼不是，不過寫的人通常會比讀此書的人具備更好知識，足以做出這樣的判斷。 7、瞭解前人所遺留的程式 UML可以用一兩種方式來幫你理解一大推不熟悉的程式。體關鍵事物畫出草圖這種做法可當成一種推行的筆記機制，他可以在你學習這些程式時，幫你記下一些重要資訊。