開篇說明

      由于是自己對這些技術的學習總結和心得體會，錯誤之處在所難免，懷著技術交流的心態，現在發表出來，所以希望大家能夠多多指點，這樣能使一部分人受益同時也能糾正我的錯誤觀點，以便和各位共同提高！

軟件架構到底是什么

      軟件架構可以被簡單的描述為，一系列組件之間的組合，交互，繼承的關系。當然這樣的解釋基本上人人都可以接收。不過在我們看來，這樣的說法有點過于抽象。

      軟件架構有這標準的定義，就是參考ANSI/IEEE的標準，軟件架構可以理解為軟件密集型系統中對系統的實現和部署起決定性作用的的系統。

      軟件架構中的關鍵點是應該符合項目干系人的目標，功能上當然細分成功能性的和非功能性的需求。

      軟件架構有一定的特殊性，架構設計必須開發的初期就確定，架構設計作為關鍵決策必須前期確定。

      軟件架構其實主要是要符合項目干系人的目標，如果無法滿足項目干系人的目標，那么這個架構方案就行不通，下圖是ANSI/IEEE標準中定義的系統、架構與項目干系人直接的關系。

     開篇中已經介紹了系統架構的表述工具有UML和Relation Rose，UML基本上已經成為國際的標準。

     UML的類圖：主要是描述類之間的關系。

     用例圖：描述使用場景。

     組件圖：用來描述系統中的可重用部分。并且容易看出組件與二進制文件之間的對應關系。

     通過UML工具，我們能夠更深層次對系統架構進行不同角度的描述。抓住其核心。

     軟件架構的驗證，目前沒有什么好的辦法可以自動驗證軟件架構是否可以達到項目干系人的目標，只有通過多種方式多個級別的測試。

     例如通過單元測試，來驗證單一的功能，集成測試來評估系統的兼容性，驗收測試來驗證用戶的滿意度,程序是否提供必要的功能。

     除了UML建模工具之外，還有IBM比較著名的Relation Rose，這里大概介紹下該工具具有的視圖模式：

系統的架構

      可以這樣說，軟件系統的架構過程中沒有什么系統是不可拆分的，系統的開發方法越敏捷，為開發人員實現架構是預留的空間越大。

      系統架構師將系統分解的過程，其實最終形成的就是一份為開發人員提供的詳細設計說明書。當然詳細設計說明書的內容和格式也取決于開發方法。

架構是什么

       架構大多體現在難以改變或者改變起來代價較大的決定上。但是最終還是需要有人做決定。

       系統分析師分析系統做什么，架構師設計如何去做。

       架構師是需求與詳細說明的紐帶。

       架構師的職責：架構師應該參與到開發的全過程當中。包括分析需求與架構設計、實現、測試、繼承與部署。

      按照ISO的定義架構師的定義如下：負責系統架構的人、團隊或組織。

      微軟則對系統架構是做了如下的劃分：

      1、企業架構師。

      2、基礎架構師。

      3、特定技術架構師。

      4、解決方案架構師。

最后總結軟件開發過程中的一些法則：

      1、為了一個趕不上進度的項目增加人手，只會讓項目更加落后于進度。

      2、程序的復雜性會一直的增加，直到維護人員感覺到力不從心為止。

      3、建筑師與開發人員寫程序不同，如果建筑師按照開發人員的方式開建造，只會成為歷史中的敗筆。

下一篇文章內容預告

    UML的架構設計

    如何通過UML工具來進行建模，通過不同角度的分析，得出核心的設計。