之前的學期，我們學習了軟體工程概論和軟體需求分析，而下個學期即將學習軟體體系架構。如課程安排的一樣，如大眾的觀點一致：需求在架構之前。即傳統的思想：在知道了系統的需求，就可以為此系統構建構架。而緊接著，書中使用了經典的「瑞典的瓦薩戰艦」以證明這種觀點的缺乏遠見——不能真正揭示出架構的重要價值。
「瑞典的瓦薩戰艦」講的是乙個違背當時技術水平建造的戰艦，這個戰艦卻在第一次航行時淹水沉沒了。雖然故事發生在400年前，卻很好的說明了架構商業週期的概念：系統需求來自於企業目標，架構來自於系統需求，系統來自於架構。同時，此案例同樣的提示了三方面的內容：一，能夠滿足苛刻需求的成功架構案例分析，以確定當前的技術水平；二，在構建系統之前使用對所用架構進行評估的方法，以減少開發乙個無先例的全新系統所承擔的風險；三，基於架構的增量開發技巧，以及時發現設計缺陷並加以改進。
既然開始了對「架構」的分析，那麼就要清楚架構受什麼的影響。首先，受涉眾的影響，因為太多相關的人會對架構有建議和影響，所以這一點顯而易見。因此，乙個得到各方認可的系統需求在以下達到相應要求：效能、可靠性、可用性、平台相容性、記憶體的利用、網路使用程度、安全性、可修改性、易用性、與其他系統的互操作性及行為。其次，架構還受開發組織、設計師的素質和經驗的影響、也受技術環境的影響。這一點，也同樣很好理解，所謂經濟基礎決定上層建築，對等而言，技術基礎決定最後的系統成果。同樣，如同「作用存在一定有反作用力」，這些因素也會反作用於架構。
然後，我們再來分析「什麼樣的架構算最好？」。怎麼簡介地對那一頁的內容進行概括呢，簡單的說，就是因地制宜！再多的條條框框也是理論，實際來說，還是看實際情況來操作。
接下來，開始認識幾個概念的定義。架構模式是對元素和關係模型以及一組對其使用方式的限制的描述。參考模型是一種考慮資料流的功能劃分。參考架構是對映到軟體元素及元素之間的資料流的參考模型。然而，講了這麼久，我們為什麼要了解架構？為什麼有乙個新的名詞叫做架構呢？架構簡而言之是涉眾進行交流的手段，同樣是早期設計決策的體現，也是可傳遞、可重用的模型。用通俗的話來講，就是，架構源於提出的人，同時受影響於各個方面的因素。
對第三章，說實話，無法具體的來說概念等，只能籠統而言，是案例分析的幾個例項。
軟體構架實踐 閱讀筆記03
寒假生活 讀 軟體構架實踐 7 9章後感 在了解了構架的商業方面 構架檢視和結構 質量屬性等知識，這部分內容旨在構架的設計以及當構架逐漸形成時應該做什麼。軟體架構的設計是指通過一系列的設計活動，獲得滿足系統功能性需求 簡稱fr 並且符合一定非功能性需求 簡稱nfr，與質量屬性有相似涵義 約束的軟體架...
軟體構架實踐閱讀筆記5
把構架作為軟體開發過程基礎的任何組織都需要理解構架在其生命期中的位置。在生命期模型中，構架設計就是從初步的需求分析開始逐步進行迭代，所以在了解系統需求之前，不能開始設計構架，但是剛開始設計構架時並不需要收集太多需求。構架的驅動因素 包括功能 質量和商業需求，為了確定構架驅動因素，需要識別優先順序最高...
軟體構架實踐閱讀筆記2
a 7e架構包括三個結構 模組分解結構 使用結構 程序結構。模組分解結構 對於a 7e這樣的系統發生改動可能是由3個原因造成的 軟體必須與之互動的硬體發生了變化 所要求的系統外部可見行為發生了變化 完全由該項目的軟體設計人員做出的某個決定發生了變化。所以a 7e又可以分為硬體隱藏模組 行為隱藏模組 ...