拖垮OOAD專案的十大惡習

實作（implementation）是ICONIX方法中的最後一步驟，先回顧一下ICONIX方法簡潔的五大開發步驟：
1.領域建模：撰寫使用案例敘述之前，需要先對領域概念有初步的認識，這樣才能寫出貼切的使用案例敘述，因此需要建構類別圖。

2.使用案例建模：在繪製穩健圖之前，需要描述一群物件合作的原由，所以此時將需要撰寫使用案例敘述。

3.穩健分析：在繪製循序圖之前，需要先透過穩健圖決定有哪些物件將參與使用案例。

4.互動建模：針對每一個使用案例思考及建構循序圖的過程，其實就是在分派責任給物件，同時也就是在決定類別的方法。

5.實作：ICONIX方法最後一個步驟就是編寫出程式碼，而編寫程式碼所需的最關鍵資訊是，類別的屬性、方法以及類別之間的關係，如圖1所示。

圖1：實作


雖說，許多UML工具都有提供自動產出程式碼的功能，可是通常僅能夠產出程式框架，操作中最重要的控制邏輯是沒辦法自動產出的。就以StarUML為例，即便它只是個免費的UML工具，仍然提供自動產出C++、C#和Java的程式碼。

針對圖2的類別圖，StarUML可以自動產出如下的C++程式碼，包括：Member.h、Member.cpp、CreditCard.h、CreditCard.cpp、Order.h、Order.cpp、OrderLine.h、OrderLine.cpp、Item.h和Item.cpp。

圖2：類別圖


最後，我們來看看採用物件導向分析設計技術的專案，如果遇到下列十個狀況時，可得小心了，這很可能是專案垮臺的前奏呢！

拖垮OOAD專案的十大惡習
惡習1 採用物件導向技術開發你最看重的專案。（Bet the farm by doing your most critical project as your first effort that involves object-oriented development.）

惡習2 確定你的專案團隊裡頭，沒有一位成員有採用物件導向開發系統的經驗。（Make sure there's nobody with any OO experience on your project team.）

惡習3 不做單元測試，而是直接做整合測試。（Don't do unit testing on a class-by-class basis. Instead, go directly into integration testing and hope for the best.）

惡習4 資深設計師忙著編寫使用案例敘述，並且派初級人員去設計循序圖。（Keep most of your senior designers busy writing use cases; have your junior people work on the sequence diagrams.）

惡習5 不複審任何的分析模式或設計模式。（Don't bother to review any of your analysis or design models.）

惡習6 讓設計模式與使用案例模式完全分離，反正我們都知道使用案例不會影響程式碼。（Keep your design model completely segregated from your use case model; we all know that use cases don't affect code.）

惡習7 先實作系統中容易的部分，並且將關鍵的部分留待最後逼近截止日時，才實作。（Implement the easy parts of your system first. Leave the critical items for the end, near the deadline. （You can earn lots of overtime pay this way!））

惡習8 帶領一組有20多位VB程式設計師的團隊，給他們C++編譯器和視覺化建模工具，並且讓他們自行其事。（Take a team of 20 or so Visual Basic programmers, hand them a C++ compiler and a visual modeling tool, and leave them to their own devices.）

惡習9 直接編寫程式碼，再透過反向工程自動產出物件模式，反正客戶根本不懂。（Ignore the analysis and design models you've produced, write the code, and reverse-engineer all the code you've written into an as-built object model. Your clients will never know the difference, right?）

惡習10 以為你的視覺化建模工具將自動產出程式碼，所以雇用一堆大專生來編碼。（Assume your visual modeling tool will generate great code for you, and hire a bunch of junior college students （none CS majors） to handle coding.）

原本我將「分析癱瘓」（analysis paralysis）中譯為「分析麻痺」，不過經網友建議，因此從善如流採用「分析癱瘓」。網友在我的UML Blog（www.umltw.com）中留言，建議我採用「分析癱瘓」譯詞，套用他說法是「因為分析過多，導致整個分析流程癱瘓…」，所以採用「分析癱瘓」會比採用「分析麻痺」更貼切。

從使用案例分析推進到循序圖設計，向來是開發流程最容易塞住、難以推進的關卡所在，也是經常會發生分析癱瘓之處。所以，我們除了可以參考原著作者提到的十五條分析癱瘓警訊之外，還可以善用穩健圖來進行初步設計，用以銜接分析與細部設計。

由於，原著作者提到的十五條分析癱瘓警訊分散在各小節中，為了方便你參考使用，所以，此處我們特別重整條列如下：
1. 別讓文法檢驗把你絆住了。

2. 別太早處理個體數目。

3. 直到細部設計階段，再來擔心聚合關係與組合關係。

4. 別嘗試寫使用案例，直到你知道使用者將做什麼，為止。

5. 別花費數週的時間，只是為了建造出精緻完善的使用案例模式。

6. 別浪費時間去擔心，到底該採用包含關係、擴充關係、亦或是使用關係。

7. 別把時間浪費在，冗長且複雜的使用案例樣板上頭。

8. 別試著用穩健圖進行細部設計。

9. 別浪費時間，想把穩健圖做得盡善盡美。

10. 在你對這些物件一無所知之前，別想要為它們配置行為。

11. 在你完成相關的穩健圖之前，別動手繪製循序圖。

12. 別將焦點放在存取方法上，而是該關注真正的方法。

13. 如果物件只有兩個狀態時，千萬別為它繪製狀態圖。

14. 如果你不是真的需要模式，那就別建模。

15. 別因為你懂得狀態圖，就一定要繪製。

總計，原著作者除了條列了十五條分析癱瘓警訊之外，還提出了十項領域建模錯誤、十項撰寫使用案例需避免的錯誤、十個穩健分析的好處、十個繪製循序圖該記得的要點、十種染上了分析癱瘓症的徵兆、十件跟需求有關的重要事項、十個拖垮OOAD專案的惡習。這些由實務經驗累積下來的智慧，真的很值得我們細細品味。

作者簡介：
邱郁惠
研究OOAD、UML、MDA十餘年，經歷過顧問、專案、教學及寫作工作。離職後創辦UML Blog推廣UML，組織《UML互助會》社群定期舉辦軟體技術講座，出版多本UML專業書籍與電子書。目前擁有OCUP/UML三級認證、PMP認證。

書籍簡介
	Use Case Driven Object Modeling With UML: A Practical Approach  作者：Doug Rosenberg and Kendall Scott 頁數：160頁 出版社：Addison-Wesley Professional 出版時間：1999 March