由於是自己對這些技術的學習總結和心得體會，錯誤之處在所難免，懷著技術交流的心態，現在發表出來，所以希望大家能夠多多指點，這樣能使一部分人受益同時也能糾正我的錯誤觀點，以便和各位共同提高！
軟體架構可以被簡單的描述為，一系列元件之間的組合，互動，繼承的關係。當然這樣的解釋基本上人人都可以接收。不過在我們看來，這樣的說法有點過於抽象。
軟體架構有這標準的定義，就是參考ansi/ieee的標準，軟體架構可以理解為軟體密集型系統中對系統的實現和部署起決定性作用的的系統。
軟體架構中的關鍵點是應該符合專案干係人的目標，功能上當然細分成功能性的和非功能性的需求。
軟體架構有一定的特殊性，架構設計必須開發的初期就確定，架構設計作為關鍵決策必須前期確定。
軟體架構其實主要是要符合專案干係人的目標，如果無法滿足專案干係人的目標，那麼這個架構方案就行不通，下圖是ansi/ieee標準中定義的系統、架構與專案干係人直接的關係。
開篇中已經介紹了系統架構的表述工具有uml和relation rose，uml基本上已經成為國際的標準。
uml的類圖：主要是描述類之間的關係。
用例圖：描述使用場景。
元件圖：用來描述系統中的可重用部分。並且容易看出元件與二進位制檔案之間的對應關係。
通過uml工具，我們能夠更深層次對系統架構進行不同角度的描述。抓住其核心。
軟體架構的驗證，目前沒有什麼好的辦法可以自動驗證軟體架構是否可以達到專案干係人的目標，只有通過多種方式多個級別的測試。
例如通過單元測試，來驗證單一的功能，整合測試來評估系統的相容性，驗收測試來驗證使用者的滿意度,程式是否提供必要的功能。
除了uml建模工具之外，還有ibm比較著名的relation rose，這裡大概介紹下該工具具有的檢視模式：
可以這樣說，軟體系統的架構過程中沒有什麼系統是不可拆分的，系統的開發方法越敏捷，為開發人員實現架構是預留的空間越大。
系統架構師將系統分解的過程，其實最終形成的就是乙份為開發人員提供的詳細設計說明書。當然詳細設計說明書的內容和格式也取決於開發方法。
架構大多體現在難以改變或者改變起來代價較大的決定上。但是最終還是需要有人做決定。
系統分析師分析系統做什麼，架構師設計如何去做。
架構師是需求與詳細說明的紐帶。
架構師的職責：架構師應該參與到開發的全過程當中。包括分析需求與架構設計、實現、測試、繼承與部署。
按照iso的定義架構師的定義如下：負責系統架構的人、團隊或組織。
微軟則對系統架構是做了如下的劃分：
1、企業架構師。
2、基礎架構師。
3、特定技術架構師。
4、解決方案架構師。
1、為了乙個趕不上進度的專案增加人手，只會讓專案更加落後於進度。
2、程式的複雜性會一直的增加，直到維護人員感覺到力不從心為止。
3、建築師與開發人員寫程式不同，如果建築師按照開發人員的方式開建造，只會成為歷史中的敗筆。
系統架構師 基礎到企業應用架構 系列索引
一篇都是自己在系統架構過程中的總結和經驗，每一篇我都會抱著認真的態度去完成，寧缺毋濫的原則。希望本系列看完之後不但能夠幫助看過這個系列的人對系統架 構有深刻的認識，並且能夠掌握系統架構中的必備知識，應用到自己的工作中去，更可以共同提高大家的個人能力。本系列希望能夠拋磚引玉，希望大家能夠多提出寶 貴意...
系統架構師 基礎到企業應用架構 系列索引
系統架構師 基礎到企業應用架構 索引 一篇都是自己在系統架構過程中的總結和經驗，每一篇我都會抱著認真的態度去完成，寧缺毋濫的原則。希望本系列看完之後不但能夠幫助看過這個系列的人對系統架 構有深刻的認識，並且能夠掌握系統架構中的必備知識，應用到自己的工作中去，更可以共同提高大家的個人能力。本系列希望能...
系統架構師 基礎到企業應用架構系列之 介紹篇
軟體中的系統架構，其實是從建築行業中的架構設計參考過來的，但是軟體中的系統架構又有很大的特殊性。特殊性表現在，軟體的架構可以在設計完畢後，專案進行的過程中進行相應的變化，或者可以推到重來，但是建築行業中卻不能這麼做。軟體行業有著很大的變化性。架構總體來說就是實現需求功能的較複雜元件的設計與不能精簡的...