【軟件架構】如何成爲一個優秀的軟件模型設計者

    咱們期待本身成爲一個優秀的軟件模型設計者，可是，要怎樣作，又從哪裏開始呢？

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

1. 人遠比技術重要

    你開發軟件是爲了供別人使用，沒有人使用的軟件只是沒有意義的數據集合而已。

    許多在軟件方面頗有成就的行家在他們事業的初期卻表現平平，由於他們那時侯將主要精力都集中在技術上。

    顯然，構件（components），EJB（Enterprise Java Beans）和代理（agent）是頗有趣的東西。可是對於用戶來講，若是你設計的軟件很難使用或者不能知足他們的需求，後臺用再好的技術也於事無補。

    多花點時間到軟件需求和設計一個使用戶能很容易理解的界面上。

2. 理解你要實現的東西

    好的軟件設計人員把大多數時間花費在創建系統模型上，偶爾寫一些源代碼，但那隻不過是爲了驗證設計過程當中所遇到的問題。

    這將使他們的設計方案更加可行。

3. 謙虛是必須的品格

    你不可能知道一切，你甚至要很努力才能得到足夠用的知識。

    軟件開發是一項複雜而艱鉅的工做，由於軟件開發所用到的工具和技術是在不斷更新的。

    並且，一我的也不可能瞭解軟件開發的全部過程。

    在平常生活中你天天接觸到的新鮮事物可能不會太多。可是對於從事軟件開發的人來講，天天能夠學習不少新東西（若是願意的話）。

4. 需求就是需求

    若是你沒有任何需求，你就不要動手開發任何軟件。

    成功的軟件取決於時間（在用戶要求的時間內完成）、預算和是否知足用戶的需求。

    若是你不能確切知道用戶須要的是什麼，或者軟件的需求定義，那麼你的工程註定會失敗。

5. 需求其實不多改變，改變的是你對需求的理解

    Object ToolSmiths公司的Doug Smith常喜歡說：「分析是一門科學，設計是一門藝術」。

    他的意思是說在衆多的「正確」分析模型中只存在一個最「正確」分析模型能夠徹底知足解決某個具體問題的須要（我理解的意思是需求分析須要一絲不苟、精確的完成,而設計的時候反而能夠發揮創造力和想象力）。

    若是需求常常改動，極可能是你沒有做好需求分析，並非需求真的改變了。

    能夠抱怨用戶不能告訴你他們想獲得什麼，可是不要忘記，收集需求信息是你的工做。

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

    若是以爲公司不讓你與用戶充分接觸，那隻能說明公司的管理層並非真正支持你的項目。

    能夠抱怨公司有關軟件工程的管理制度不合理，但你必須瞭解大多同行公司是怎麼作的。

    能夠藉口說大家的競爭對手的成功是由於他們有了一個新的理念，可是爲何你沒先想到呢？

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

6. 常常閱讀

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

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

7. 下降軟件模塊間的耦合度

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

    你能夠經過如下方法下降程序的耦合度：

• 隱藏實現細節
• 強制構件接口定義
• 不使用公用數據結構
• 不讓應用程序直接操做數據庫

    耦合度低的軟件能夠很容易被重用、維護和擴充。

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」中指出，你應該在開發階段的早期就定義軟件模塊之間的接口。

    這有助於你的開發人員全面理解軟件的設計結構並取得一致意見，讓各模塊開發小組相對獨立的工做。

    一旦模塊的接口肯定以後，模塊怎樣實現就不是很重要了。

    從根本上說，若是你不可以定義你的模塊「從外部看上去會是什麼樣子」，你確定也不清楚模塊內要實現什麼。

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

    在軟件開發中沒有捷徑能夠走。

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

    在軟件建模上每節省一週，在未來的編碼階段可能會多花幾周時間，由於在全面思考以前就動手寫程序。

    爲了節省一天的測試時間而漏掉了一個bug，在未來的維護階段，可能須要花幾周甚至幾個月的時間去修復。與其如此，還不如從新安排一下項目計劃。

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

15. 別信賴任何人

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

    大部分產品供應商但願把你緊緊綁在他們的產品上，多是操做系統，數據庫或者某個開發工具。

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

    大部分程序員認爲他們本身比其餘人更優秀，他們可能拋棄你設計的模型而用本身認爲更好的。

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

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

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

    在設計的時候應當先創建一個技術原型， 或者稱爲「端到端」原型。以證實你的設計是可以工做的。

    你應該在開發工做的早期作這些事情，由於，若是軟件的設計方案是不可行的，在編碼實現階段不管採起什麼措施都於事無補。

    技術原型將證實你的設計的可行性，從而，你的設計將更容易得到支持。

17. 應用已知的模式

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

    通常來講，好的模型設計和開發人員，都會避免從新設計已經成熟的並被普遍應用的東西。

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

    用例捕獲的是系統行爲需求，數據模型則描述支持一個系統運行所須要的數據構成。

    你可能會試圖在用例中加入實際數據描述，可是，這對開發者不是很是有用。

    一樣，數據模型對描述軟件需求來講是無用的。

    每一個模型在你建模過程當中有其相應的位置，可是，你須要明白在什麼地方，何時使用它們。

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

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

    當你設計軟件的時候，應該考慮製做類模型，順序圖、狀態圖、協做圖和最終的軟件實際物理模型。

    程序設計人員應該慢慢意識到，僅僅使用一個模型而實現的軟件要麼不可以很好地知足用戶的需求，要麼很難擴展。

20. 教育你的聽衆

    你花了很大力氣創建一個很成熟的系統模型，而你的聽衆卻不能理解它們，甚至更糟－連爲何要先創建模型都不知道。那麼你的工做是毫無心義的。

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

    另外， 你還須要告訴你的用戶一些需求建模的基礎知識。給他們解釋你的用例(uses case)和用戶界面模型，以使他們可以明白你要表達地東西。

    當每一個人都能使用一個通用的設計語言的時候（好比UML），你的團隊才能實現真正的合做。

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

    你給我CAD/CAM工具，請我設計一座橋。

    可是，若是那座橋建成的話，我確定不想當第一個從橋上過的人，由於我對建築一竅不通。

    使用一個很優秀的CASE工具並不能使你成爲一個建模專家，只能使你成爲一個優秀CASE工具的使用者。

    成爲一個優秀的建模專家須要多年的積累，不會是一週針對某個價值幾千美圓工具的培訓。

    一個優秀的CASE工具是很重要，但你必須學習使用它，並可以使用它設計它支持的模型。

22. 理解完整的過程

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

    軟件開發是一個很複雜的過程，《object-oriented software process》說過：除了編程、建模、測試等你擅長工做外，還有不少工做要作。

    好的設計者須要考慮全局。必須從長遠考慮如何使軟件知足用戶須要，如何提供維護和技術支持等。

23. 常作測試，早作測試

    若是測試對你的軟件來講是無所謂的，那麼你的軟件多半也沒什麼必要被開發出來。

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

    在軟件生命週期中，越晚發現的錯誤越難修改，修改爲本越昂貴。儘量早的作測試是很值得的。

24. 把你的工做歸檔

    不值得歸檔的工做每每也不值得作。

    歸檔你的設想，以及根據設想作出的決定；

    歸檔軟件模型中很重要但不很明顯的部分。 

    給每一個模型一些概要描述以使別人很快明白模型所表達的內容。

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

    若是有人說「使用某種開發語言、某個工具或某某技術，咱們就不須要再作需求分析，建模，編碼或測試」。

    不要相信，這隻說明他還缺少經驗。

    拋開技術和人的因素，實際上軟件開發的基本原理自20世紀70年代以來就沒有改變過。

    你必須定義需求，建模，編碼，測試，配置，面對風險，發佈產品，管理工做人員等等。

    軟件建模技術是須要多年的實際工做才能徹底掌握的。好在你能夠今後建議開始，完善本身的軟件開發經驗。

    以雞湯開始，加入本身的蔬菜。而後，開始享受你本身的豐盛晚餐吧。

 

參考文章

    http://www.cnblogs.com/allanbolt/archive/2009/06/26/1511438.html