軟件體系結構建模的種類
結構模型
這是一個最直觀、最普遍的建模方法。這種方法以體系結構的構件、連接件和其他概念來刻畫結構，併力圖通過結構來反映系統的重要語義內容，包括系統的配置、約束、隱含的假設條件、風格、性質等。
研究結構模型的核心是體系結構描述語言。
框架模型
框架模型與結構模型類似，但它不太側重描述結構的細節而更側重於整體的結構。
框架模型主要以一些特殊的問題爲目標建立只針對和適應該問題的結構。
例如：MVC模型
功能模型
功能模型認爲體系結構是由一組功能構件按層次組成，下層向上層提供服務。
功能模型可以看作是一種特殊的框架模型。
動態模型
動態模型是對結構或框架模型的補充，研究系統的“大顆粒”的行爲性質。
例如，描述系統的重新配置或演化。動態可以指系統總體結構的配置、建立或拆除通信通道或計算的過程。
過程模型
過程模型研究構造系統的步驟和過程。
結構是遵循某些過程腳本的結果。
體系結構的核心模型
- 構件是具有某種功能的軟件單元，有計算元素和存儲兩種。它可分爲原子構件與複合構件。
- 連接器用於構件的連接單元。
如管道，過程調用，事件廣播，SQL連接等 - 構件與連接器是一個封裝的實體，只能通過接口與外界進行交互。構件的接口由一組端口組成，每個端口是具體的一個交互點。而連接器則稱爲角色
“4+1”視圖模型
“4+1”視圖模型從5個不同的視角包括邏輯視圖、進程視圖、物理視圖、開發視圖和場景視圖來描述軟件體系結構。
每一個視圖只關心繫統的一個側面，5個視圖結合在一起才能反映系統的軟件體系結構的全部內容。
邏輯視圖
邏輯視圖主要支持系統的功能需求，即系統提供給最終用戶的服務。在邏輯視圖中，系統分解成一系列的功能抽象，這些抽象主要來自問題領域。這種分解不但可以用來進行功能分析，而且可用作標識在整個系統的各個不同部分的通用機制和設計元素。
在面向對象技術中，通過抽象、封裝和繼承，可以用對象模型來代表邏輯視圖，用類圖來描述邏輯視圖。
表示法
邏輯視圖中使用的風格爲面向對象的風格，邏輯視圖設計中要注意的主要問題是要保持一個單一的、內聚的對象模型貫穿整個系統。
對於規模更大的系統來說，體系結構級中包含數十甚至數百個類 。
開發視圖
開發視圖也稱模塊視圖，主要側重於軟件模塊的組織和管理。
開發視圖要考慮軟件內部的需求，如軟件開發的容易性、軟件的重用和軟件的通用性，要充分考慮由於具體開發工具的不同而帶來的侷限性。
開發視圖通過系統輸入輸出關係的模型圖和子系統圖來描述。
在開發視圖中，最好採用4-6層子系統，而且每個子系統僅僅能與同層或更低層的子系統通訊，這樣可以使每個層次的接口既完備又精練，避免了各個模塊之間很複雜的依賴關係。
設計時要充分考慮，對於各個層次，層次越低，通用性越強，這樣，可以保證應用程序的需求發生改變時，所做的改動最小。開發視圖所用的風格通常是層次結構風格。
表示法
進程視圖
進程視圖側重於系統的運行特性，主要關注一些非功能性的需求。
進程視圖強調併發性、分佈性、系統集成性和容錯能力，以及從邏輯視圖中的主要抽象如何適合進程結構。它也定義邏輯視圖中的各個類的操作具體是在哪一個線程中被執行的。
進程視圖可以描述成多層抽象，每個級別分別關注不同的方面。在最高層抽象中，進程結構可以看作是構成一個執行單元的一組任務。它可看成一系列獨立的，通過邏輯網絡相互通信的程序。它們是分佈的，通過總線或局域網、廣域網等硬件資源連接起來。
表示法
物理視圖
物理視圖主要考慮如何把軟件映射到硬件上，它通常要考慮到系統性能、規模、可靠性等。解決系統拓撲結構、系統安裝、通訊等問題。
當軟件運行於不同的節點上時，各視圖中的構件都直接或間接地對應於系統的不同節點上。因此，從軟件到節點的映射要有較高的靈活性，當環境改變時，對系統其他視圖的影響最小。
表示法
場景
場景可以看作是那些重要系統活動的抽象，它使四個視圖有機聯繫起來，從某種意義上說場景是最重要的需求抽象。在開發體系結構時，它可以幫助設計者找到體系結構的構件和它們之間的作用關係。同時，也可以用場景來分析一個特定的視圖，或描述不同視圖構件間是如何相互作用的。
場景可以用文本表示，也可以用圖形表示。
總結
邏輯視圖和開發視圖描述系統的靜態結構，而進程視圖和物理視圖描述系統的動態結構。
對於不同的軟件系統來說，側重的角度也有所不同。例如，對於管理信息系統來說，比較側重於從邏輯視圖和開發視圖來描述系統，而對於實時控制系統來說，則比較注重於從進程視圖和物理視圖來描述系統。
建模工具和符號的選擇：沒有統一規定。
