[ZT] 怎樣成為優秀的軟體模型設計者？

作者：Scott Ambler著，樂林峰 譯 本文選自：www.umlchina.com 

我們期待自己成為一個優秀的軟體模型設計者，但是，要怎樣做，又從哪裡開始呢？ 

將下列原則應用到你的軟體工程中，你會獲得立杆見影的成果。 

1. 人遠比技術重要 

你開發軟體是為了供別人使用，沒有人使用的軟體只是沒有意義的資料的集合而已。許多在軟體方面很有成就的行家在他們事業的初期卻表現平平，因為他們那時侯將主要精力都集中在技術上。顯然，構件（components），EJB（Enterprise Java Beans）和代理（agent）是很有趣的東西。但是對於使用者來說，如果你設計的軟體很難使用或者不能滿足他們的需求，後台用再好的技術也於事無補。多花點時間到軟體需求和設計一個使使用者能很容易理解的介面上。 

2. 理解你要實現的東西 

好的軟體設計人員把大多數時間花費在建立系統模型上，偶爾寫一些原始碼，但那隻不過是為了驗證設計過程中所遇到的問題。這將使他們的設計方案更加可行。 

3. 謙虛是必須的品格 

你不可能知道一切，你甚至要很努力才能獲得足夠用的知識。軟體開發是一項複雜而艱巨的工作，因為軟體開發所用到的工具和技術是在不斷更新的。而且，一個人也不可能瞭解軟體開發的所有過程。在日常生活中你每天接觸到的新鮮事物可能不會太多。但是對於從事軟體 開發的人來說，每天可以學習很多新東西（如果願意的話）。 

4. 需求就是需求 

如果你沒有任何需求，你就不要動手開發任何軟體。成功的軟體取決於時間（在使用者要求的時間內完成）、預算和是否滿足使用者的需求。如果你不能確切知道使用者需要的是什麼，或者軟體的需求定義，那麼你的工程註定會失敗。 

5. 需求其實很少改變，改變的是你對需求的理解 

Object ToolSmiths公司（www.objecttoolsmiths.com）的Doug Smith常喜歡說：“分析是一門科學，設計是一門藝術”。他的意思是說在眾多的“正確”分析模型中只存在一個最“正確”分析模型可以完全滿足解決某個具體問題的需要（我理解的意思是需求分析需要一絲不苟、精確的完成,而設計的時候反而可以發揮創造力和想 象力 - 譯者注）。 

如果需求經常改動，很可能是你沒有作好需求分析，並不是需求真的改變了。 

你可以抱怨使用者不能告訴你他們想得到什麼，但是不要忘記，收集需求資訊是你工作。 

你可以說是新來的開發人員把事情搞得一團糟，但是，你應該確定在工程的第一天就告訴他們應該做什麼和怎樣去做。 

如果你覺得公司不讓你與使用者充分接觸，那隻能說明公司的管理層並不是真正支援你的項目。 

你可以抱怨公司有關軟體工程的管理制度不合理，但你必須瞭解大多同行公司是怎麼做的。 

你可以借口說你們的競爭者的成功是因為他們有了一個新的理念，但是為什麼你沒先想到呢？ 

需求真正改變的情況很少，但是沒有做好需求分析工作的理由卻很多。 

6. 經常閱讀 

在這個每日都在發生變化的產業中，你不可能在已取得的成就上陶醉太久。 

每個月至少讀2、3本專業雜誌或者1本專業書籍。保持不落伍需要付出很多的時間和金錢，但會使你成為一個很有實力的競爭者。 

7. 降低軟體模組間的耦合度 

高耦合度的系統是很難維護的。一處的修改引起另一處甚至更多處的變動。 

你可以通過以下方法降低程式的耦合度：隱藏實現細節，強制構件介面定義，不使用公用資料結構，不讓應用程式直接操作資料庫（我的經驗法則是：當應用程式員在寫SQL代碼的時候，你的程式的耦合度就已經很高了）。 

耦合度低的軟體可以很容易被重用、維護和擴充。 

8. 提高軟體的內聚性 

如果一個軟體的模組只實現一個功能，那麼該模組具有高內聚性。高內聚性的軟體更容易維護和改進。 

判斷一個模組是否有高的內聚性，看一看你是否能夠用一個簡單的句子描述它的功能就行了。如果你用了一段話或者你需要使用類似“和”、“或”等連詞，則說明你需要將該模組細化。 

只有高內聚性的模組才可能被重用。 

9. 考慮軟體的移植性 

移植是軟體開發中一項具體而又實際的工作，不要相信某些軟體工具的廣告宣傳（比如java 的宣傳口號write once run many ? 譯者注）。 

即使僅僅對軟體進行常規升級，也要把這看得和向另一個作業系統或資料庫移植一樣重要。 

記得從16位Windows移植到32位windows的“樂趣”嗎 ？當你使用了某個作業系統的特性，如它的處理序間通訊(IPC)策略，或用某資料庫專有語言寫了預存程序。你的軟體和那個特定的產品結合度就已經很高了。 

好的軟體設計者把那些特有的實現細節打包隱藏起來，所以，當那些特性該變的時候，你的僅僅需要更新那個包就可以了。 

10. 接受變化 

這是一句老話了：唯一不變的只有變化。 

你應該將所有系統將可能發生的變化以及潛在需求記錄下來,以便將來能夠實現（參見“Architecting for Change”，Thinking Objectively, May 1999） 

通過在建模期間考慮這些假設的情況，你就有可能開發出足夠強壯且容易維護的軟體。設計強壯的軟體是你最基本的目標。 

11. 不要低估對軟體規模的需求 

Internet 帶給我們的最大的教訓是你必須在軟體開發的最初階段就考慮軟體規模的可擴充性。 

今天只有100人的部門使用的應用程式，明天可能會被有好幾萬人的組織使用，下月，通過網際網路可能會有幾百萬人使用它。 

在軟體設計的初期，根據在用例模型中定義的必須支援的基本交易處理，確定軟體的準系統。然後，在建造系統的時候再逐步加入比較常用的功能。 

在設計的開始考慮軟體的規模需求，避免在使用者群突然增大的情況下，重寫軟體。 

12. 效能僅僅是很多設計因素之一 

關注軟體設計中的一個重要因素--效能，這好象也是使用者最關心的事情。一個效能不佳的軟體將不可避免被重寫。 

但是你的設計還必須具有可靠性，可用性，便攜性和可擴充性。你應該在工程開始就應該定義並區分好這些因素，以便在工作中恰當使用。效能可以是，也可以不是優先順序最高的因素，我的觀點是，給每個設計因素應有的考慮。 

13. 管理介面 

“UML User Guide”（Grady Booch，Ivar Jacobson和Jim Rumbaugh ,Addison Wesley, 1999）中指出，你應該在開發階段的早期就定義軟體模組之間的介面。 

這有助於你的開發人員全面理解軟體的設計結構並取得一致意見，讓各模組開發小組相對獨立的工作。一旦模組的介面確定之後，模組怎樣實現就不是很重要了。 

從根本上說，如果你不能夠定義你的模組“從外部看上去會是什麼樣子”，你肯定也不清楚模組內要實現什麼。 

14. 走近路需要更長的時間 

在軟體開發中沒有捷徑可以走。 

縮短你的在需求分析上花的時間，結果只能是開發出來的軟體不能滿足使用者的需求，必須被重寫。 

在軟體建模上每節省一周，在將來的編碼階段可能會多花幾周時間，因為你在全面思考之前就動手寫程式。 

你為了節省一天的測試時間而漏掉了一個bug，在將來的維護階段，可能需要花幾周甚至幾個月的時間去修複。與其如此，還不如重新安排一下專案計劃。 

避免走捷徑，只做一次但要做對（do it once by doing it right）。 

15. 別信賴任何人 

產品和服務銷售公司不是你的朋友，你的大部分員工和高層管理員也不是。 

大部分產品供應商希望把你牢牢綁在他們的產品上，可能是作業系統，資料庫或者某個開發工具。 

大部分的顧問和承包商只關心你的錢並不是你的工程（停止向他們付款，看一看他們會在周圍呆多長時間）。 

大部分程式員認為他們自己比其他人更優秀，他們可能拋棄你設計的模型而用自己認為更好的。 

只有良好的溝通才能解決這些問題。 

要明確的是，不要只依靠一家產品或服務提供者，即使你的公司（或組織）已經在建模、文檔和過程等方面向那個公司投入了很多錢。 

16. 證明你的設計在實踐中可行 

在設計的時候應當先建立一個技術原型， 或者稱為“端到端”原型。以證明你的設計是能夠工作的。 

你應該在開發工作的早期做這些事情，因為，如果軟體的設計方案是不可行的，在編碼實現階段無論採取什麼措施都於事無補。技術原型將證明你的設計的可行性，從而，你的設計將更容易獲得支援。 

17. 應用已知的模式 

目前，我們有大量現成的分析和設計模式以及問題的解決方案可以使用。 

一般來說，好的模型設計和開發人員，都會避免重新設計已經成熟的並被廣泛應用的東西。 
http://www.ambysoft.com/processPatternsPage.html 收藏了許多開發模式的資訊。 

18. 研究每個模型的長處和弱點 

目前有很多種類的模型可以使用,如所示。用例捕獲的是系統行為需求，資料模型則描述支援一個系統運行所需要的資料構成。你可能會試圖在用例中加入實際資料描述，但是，這對開發人員不是非常有用。同樣，資料模型對描述軟體需求來說是無用的。每個模型在你建 模過程中有其相應的位置，但是，你需要明白在什麼地方，什麼時候使用它們。 

19. 在現有任務中應用多個模型 

當你收集需求的時候，考慮使用用例模型，使用者介面模型和領域級的類模型。 

當你設計軟體的時候，應該考慮製作類模型，順序圖、狀態圖、共同作業圖表和最終的軟體實際物理模型。 

程式設計人員應該慢慢意識到，僅僅使用一個模型而實現的軟體要麼不能夠很好地滿足使用者的需求，要麼很難擴充。 

20. 教育你的聽眾 

你花了很大力氣建立一個很成熟的系統模型，而你的聽眾卻不能理解它們，甚至更糟－連為什麼要先建立模型都不知道。那麼你的工作是毫無意義的。 

教給你開發人員基本的建模知識；否則，他們會只看看你畫的漂亮圖表，然後繼續編寫不規範的程式。 

另外， 你還需要告訴你的使用者一些需求建模的基礎知識。給他們解釋你的用例(uses case)和使用者介面模型，以使他們能夠明白你要表達地東西。當每個人都能使用一個通用的設計語言的時候（比如UML-譯者注），你的團隊才能實現真正的合作。 

21. 帶工具的傻瓜還是傻瓜 

你給我CAD/CAM工具，請我設計一座橋。但是，如果那座橋建成的話，我肯定不想當第一個從橋上過的人，因為我對建築一竅不通。 

使用一個很優秀的CASE工具並不能使你成為一個建模專家，只能使你成為一個優秀CASE工具的使用者。成為一個優秀的建模專家需要多年的積累，不會是一周針對某個價值幾千美元工具的培訓。一個優秀的CASE工具是很重要，但你必須學習使用它，並能夠使用 它設計它支援的模型。 

22. 理解完整的過程 

好的設計人員應該理解整個軟體過程，儘管他們可能不是精通全部實現細節。 

軟體開發是一個很複雜的過程，還記得《object-oriented software process》第36頁的內容嗎？除了編程、建模、測試等你擅長工作外，還有很多工作要做。 

好的設計者需要考慮全域。必須從長遠考慮如何使軟體滿足使用者需要，如何提供維護和支援人員等。 

23. 常做測試，早做測試 

如果測試對你的軟體來說是無所謂的，那麼你的軟體多半也沒什麼必要被開發出來。 

建立一個技術原型供技術評審使用，以檢驗你的軟體模型。 

在軟體生命週期中，越晚發現的錯誤越難修改，修改成本越昂貴。儘可能早的做測試是很值得的。 

24. 把你的工作歸檔 

不值得歸檔的工作往往也不值得做。歸檔你的設想，以及根據設想做出的決定；歸檔軟體模型中很重要但不很明顯的部分。 給每個模型一些概要描述以使別人很快明白模型所表達的內容。 

25. 技術會變，基本原理不會 

如果有人說“使用某種開發語言、某個工具或某某技術，我們就不需要再做需求分析，建模，編碼或測試”。不要相信，這隻說明他還缺乏經驗。拋開技術和人的因素，實際上軟體開發的基本原理自20世紀70年代以來就沒有改變過。你必須還定義需求，建模，編碼，測 試，配置，面對風險，發布產品，管理工作人員等等。 

軟體建模技術是需要多年的實際工作才能完全掌握的。好在你可以從我的建議開始，完善你們自己的軟體開發經驗。 

以雞湯開始，加入自己的蔬菜。然後，開始享受你自己的豐盛晚餐吧。