第4章軟件體系結構描述和設計
1．軟件體系結構描述方法的種類：(a)圖形表達工具（特點：簡潔易懂、容易使用、使用廣泛、不規範、不精確。）；(b)模塊內連接語言（採用將一種或幾種傳統程序設計語言的模塊連接起來的模塊內連接語言（MIL）。MIL方式對模塊化的程序設計和分段編譯等程序設計與開發技術確實發揮了很大的作用。但是由於這些語言處理和描述的軟件設計開發層次過於依賴程序設計語言，因此限制了它們處理和描述比程序設計語言元素更為抽象的高層次軟件體系結構元素的能力。）；(c)基於軟件構件的系統描述語言（基於軟構件的系統描述語言將軟件系統描述成一種是由許多以特定形式相互作用的特殊軟件實體構造組成的組織或系統。這種表達和描述方式雖然也是較好的一種以構件為單位的軟件系統描述方法，但是他們所面向和針對的系統元素仍然是一些層次較低的以程序設計為基礎的通信協作軟件實體單元，而且這些語言所描述和表達的系統一般而言都是面向特定應用的特殊系統，這些特性使得基於軟構件的系統描述仍然不是十分適合軟件體系結構的描述和表達。）；(d)軟件體系結構的描述語言（軟件體系結構的描述語言（ADL）是在吸收了傳統程序設計中的語義嚴格精確的特點基礎上，針對軟件體系結構的整體性和抽象性特點，定義和確定適合於軟件體系結構表達與描述的有關抽象元素，因此，ADL是當前軟件開發和設計方法學中一種發展很快的軟件體系結構描述方法。）。
2．ADL（體系結構描述語言）提供了具體的語法與刻畫體系結構的概念框架。ADL使得系統開發者能夠很好地描述他們設計的體系結構，以便與他人交流，能夠用提供的工具對許多實例進行分析。
3．IEEE P1471於2000年9月21日通過IEEE-SA標準委員會評審。IEEE P1471適用於軟件密集的系統，其目標在於：便於體系結構的表達與交流，並通過體系結構要素及其實踐標準化，奠定質量與成本的基礎。
4．基於RUP（Rational United Process）、採用UML模型描述軟件的體系結構，認為體系結構描述的關鍵是定義視點、視圖以及建模元素之間的映射關係。與IEEE P1471相比，該建議標準的體系結構描述方案涉及面比較窄，所注重的層次比較低，因而更具體。由於將體系結構的描述限於UML和RUP，具有一定的侷限性，但該建議標準結合了業界已經廣泛採用的建模語言和開發過程，因而易於推廣，可以有效實現在跨組織之間重用體系結構描述結果。
5．ADL與傳統程序設計語言的比較：(a)構造能力：ADL能夠使用較小的獨立體系結構元素來建造大型軟件系統；
(b)抽象能力：ADL使得軟件體系結構中的構件和連接件描述可以只關注它們的抽象特性，而不管其具體的實現細節；(c)重用能力：ADL使得組成軟件系統的構件、連接件甚至是軟件體系結構都成為軟件系統開發和設計的可重用部件；(d)組合能力：ADL使得其描述的每一系統元素都有其自己的局部結構，這種描述局部結構的特點使得ADL支持軟件系統的動態變化組合；(e)異構能力：ADL允許多個不同的體系結構描述關聯存在；(f)分析和推理能力：ADL允許對其描述的體系結構進行多種不同的性能和功能上的多種推理分析。
ADL與需求語言的區別：後者描述的是問題空間，而前者紮根於解空間。
ADL與建模語言的區別：後者對整體行為的關注要大於對部分的關注，而ADL集中在構件的表示上。
6．ADL的構成要素：(1)構件：一個計算單元或數據存儲；是計算與狀態存在的場所；(2)連接件：用來建立構件間的交互以及支配這些交互規則的體系結構構造模塊；(3)體系結構配置或拓撲：描述體系結構構件與連接件的連接圖。
7．軟件體系結構的設計在需求分析之後，軟件設計之前。描述好體系結構，做好承上啟下的工作很重要。一方面：體系結構描述如何向其他文檔轉移；另一方面：如何利用需求分析成果來直接生成系統的體系結構說明。
8．C2概述：在C2中，連接件負責構件之間消息的傳遞，而構件維持狀態、執行操作並通過兩個名字分別為“top”和“bottom”的端口和其它的構件交換信息。每個接口包含一種可發送的消息和一組可接收的消息。構件之間的消息要麼是請求其它構件執行某個操作的請求消息，要麼是通知其他構件自身執行了某個操作或狀態發生改變的通知消息。構件之間的消息交換不能直接進行，而只能通過連接件來完成。每個構件接口最多隻能和一個連接件相連，而連接件可以和任意數目的構件或連接件相連。請求消息只能向上層傳送而通知消息只能向下層傳送。通知消息的傳遞只對應於構件內部的操作，而和接收消息的構件的需求無關。
9．UML(Unified Modeling Language)是一種用可視化方法對軟件系統進行描述、實施和說明的標準語言。支持用不同實現技術進行的軟件開發全過程。
10．UML包括的九種圖：(a)靜態圖：用例圖、類圖、對象圖、構件圖、部署圖；(b)動態圖：順序圖、協作圖、狀態圖、活動圖。
11．UML的四層元模型體系結構：(a)元-元模型層定義了元模型層的規格說明語言；(b)元模型層為給定的建模語言定義規格說明；(c)模型層用來定義特定軟件系統的模型；(d)用戶對象用來構建給定模型的特定實例。
12．XML(extensible markup language)可擴展標記語言主要是一種數據描述方法。XML的技術主要有三個：Schema、XSL和XLL。
13．體系結構設計的基本原則：(a)抽象；(b)分而治之；(c)封裝和信息隱藏；(d)模塊化；(e)高內聚和低耦合；(f)注意點分離；(g)策略和實現的分離；(h)接口和實現的分離。
14．體系結構設計方法的元模型：(1)第一階段：捕捉需求（客戶：表示那些關心軟件體系結構設計的系統相關人員。包括：客戶、最終用戶、系統開發人員、系統維護人員、銷售人員等。領域知識：表示在解決某一問題中所應用的知識的範圍。需求規格說明：表示規格說明，描述了所要開發的體系結構系統的需求。）；(2)第二階段：提取解決方案的結構（需求規格說明、領域知識。工件：表示某一方法的工件描述。這是指諸如工件類、工件操作、工件屬性等。一般，每種工件都有一套與之相關的試探法，用來標識相關的工件實例。解決方案抽象：定義了體系結構中（子）結構的概念表示。）；(3)第三階段：體系結構規格說明（解決方案抽象、領域知識。體系結構描述：定義了軟件體系結構的規格說明。）。
15．體系結構設計方法的類型：(a)工件驅動（artifact-driven）的方法（缺點：(a)文本形式的系統需求不夠清楚、精確、完整。以它作為導出體系結構抽象的來源作用不夠；(b)子系統的語義過於簡單，難以作為體系結構構件；(c)對子系統的組合支持不足。）；(b)用例驅動（use-case-driven）的方法（缺點：(a)難以適度把握領域模型和商業模型的細節；(b)對於如何選擇與體系結構相關的用例沒有提供系統的支持；(c)用例沒有為體系結構抽象提供堅實的基礎；(d)包的語義過於簡單，難以作為體系結構構件。）；(c)模式驅動（pattern-driven）的方法（缺點：(a)在處理範圍廣泛的體系結構問題時，模式庫可能不夠充分；(b)對模式的選擇僅依靠通用知識和軟件工程師的經驗；(c)模式的應用並不是一個簡單直接的過程，它需要對問題進行全面的分析；(d)對於模式組合沒有提供很好的支持。）；(d)域驅動（domain-driven）的方法（缺點：(a)問題領域分析在導出體系結構抽象方面效果較差；(b)解決方案領域分析不夠充分。）。
16．小結：（1）工件驅動的方法中，體系結構抽象被表示為分組的工件，它們是從需求規格說明導出的；用例驅動的體系結構設計方法從用例模型導出體系結構抽象，用例模型表示了系統預期要實現的功能；模式驅動的體系結構設計方法試圖通過從去定義的模式庫中選擇體系結構模式來開發體系結構；領域驅動的體系結構設計方法從領域模型導出體系結構抽象。（2）每種方法都有不足之處，總的說來，可以總結為如下幾點：(a)在規劃體系結構設計階段所遇到的困難；(b)客戶需求不是體系結構抽象的穩固基礎；(c)難以適度控制領域模型；(d)體系結構抽象的語義能力不足；(e)對組合體系結構抽象的支持不足。
軟件體系結構知識點-複習概要 (共7篇) 上一篇： 下一篇：