【正文】 較為困難的。 ◇ 用例驅動（ usecasedriven）的方法 第四章 軟件體系結構描述 軟件體系結構的設計 缺點： （ 3）用例沒有為體系結構抽象提供堅實的基礎。 （ 4）包的語義過于簡單，難以作為體系結構構件。這在圖中被表示為分別從“工件”和“通用知識”引出的指向“ 2：實現(xiàn)”的箭頭線。 用例模型和非形式化的需求規(guī)格說明共同構成了系統(tǒng)的需求規(guī)格說明。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 用例驅動（ usecasedriven）的方法 統(tǒng)一過程使用的是一種用例驅動的體系結構設計方法。以它作為導出體系結構抽象的來源作用不夠。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 體系結構設計方法的元模型 第三階段：體系結構規(guī)格說明。 領域知識：表示在解決某一問題中所應用的知識的范圍。解決方案領域知識還包括如何從這一解決方案領域生產軟件系統(tǒng)。該原理使部件行為和表示的改變特別容易，尤其是那些不影響接口的改變，例如對運行性能的提高。實現(xiàn)部分對部件客戶來說是不可用的。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 體系結構設計的原則 由于獨立于特定的上下文環(huán)境，純實現(xiàn)部件更容易重用和維護，而策略部件通常是與特定應用相關的，需要隨著應用的變化而變化。相互協(xié)作完成某一個特定任務的部件應該和在其他任務中執(zhí)行計算的部分分離開來。緊密的耦合就會使系統(tǒng)變得復雜，因為如果一個模塊和另外的模塊有很密切的關聯(lián)的話，這個模塊就很難理解、調試、維護。模塊化的主要做法，就是在一個系統(tǒng)內引入具有良好定義的分界，依此來處理系統(tǒng)的復雜性。 信息隱蔽對用戶隱藏了部件的實現(xiàn)細節(jié)，用來更好地處理系統(tǒng)的復雜性和減少各部件之間的耦合。例如，自上而下設計將一個任務或部件分成可以獨立設計的更小的部分。行為、過程的抽象使得操作的指派是依據(jù)標識而非地址，由此產生了操作的接口和動態(tài)約束描述。 XML相關的技術有很多，但主要有三個： Schema、 XSL和 XLL。EquipReqts(equip_type)。 i n t e r f a c e I m p o r t a n t M t g A t t e n dL o c P r e f s ( l o c _ t y p e ) 。G e t E x c l S e t ( ) 。 第四章 軟件體系結構描述 軟件體系結構與 UML ◇ 直接使用 UML建模 ◎ 語義約束 由對象約束語言 OCL表示 ， OCL基于一階謂詞邏輯 ，每一個 OCL表達式都處于一些 UML模型元素的背景下 （ 由“ self”引用 ） ， 可使用該元素的屬性和關系作為其項（ term） ， 同時 OCL定義了在集合 （ sets） 、 袋 (bags)等上的公共操作集和遍歷建模元素間關系的構造 ， 因此 ，其它建模元素的屬性也可以作為它的項 。用例是系統(tǒng)提供的功能的描述。 ◇ C2概述 (1) 第四章 軟件體系結構描述 典型軟件體系結構描述語言 ◎ 構件之間的消息交換不能直接進行 ， 而只能通過連接件來完成 。 這種單向的傳遞性 ， 有利于系統(tǒng)的維護和擴展 。 當前常見的一些體系結構描述語言、方法： ACME Wright C2 UniCon Darwin AESOP Rapide Weaves SADL UML Gestalt Demeter FR ControlH amp。 同時檢查語法、說明語義。 ◇ ADL與其他語言的比較 (3) 第四章 軟件體系結構描述 軟件體系結構描述語言 ◇ 典型元素含義比較 第四章 軟件體系結構描述 軟件體系結構描述語言 ◇ 常見的軟件體系結構元素 第四章 軟件體系結構描述 軟件體系結構描述語言 ◇ ADL的構成要素 軟件體系結構的基本構成要素： 構件、連接件、體系結構配置。 ◇ 軟件體系結構的定義 第一章 軟件體系結構概論 體系結構的興起和發(fā)展 ◎ Mary Shaw和 David Garlan （ 1993年） 軟件體系結構是軟件設計過程中的一個 層次 ， 這一層次 超越計算過程中的算法設計和數(shù)據(jù)結構設計 。 （ 4個視點 、 7個體系結構視圖 ） ◎ 與 IEEE P1471相比 ， 該建議標準的體系結構描述方案涉及面比較窄 ， 所注重的層次比較低 ， 因而更具體 。 請參閱 《 軟件體系結構 —— 理論與實踐 》 ，馮沖 江賀 馮靜芳 編著，人民郵電出版社。 ◎ 例如 ， 一種多變配置語言就可以用來在一個較高的抽象層次上對系統(tǒng)的體系結構建模 ， Darwin最初用作設計和構造復雜分布式系統(tǒng)的配置說明語言 ， 因具有動態(tài)特性 ， 也可用來描述動態(tài)體系結構 。 形式化的、規(guī)范化的體系結構描述對于體系結構的設計和理解都是非常重要的。 由于程序設計語言和模塊內連接語言具有嚴格的語義基礎 ， 因此它們能支持對較大的軟件單元進行描述 ， 諸如定義 /使用和扇入 /扇出等操作 。 ◎ 由于 ADL是在吸收了傳統(tǒng)程序設計中的語義嚴格精確的特點基礎上 ， 針對軟件體系結構的整體性和抽象性特點 ， 定義和確定適合于軟件體系結構表達與描述的有關抽象元素 ， 因此 ， ADL是當前軟件開發(fā)和設計方法學中一種發(fā)展很快的軟件體系結構描述方法 ， 目前 ，已經有幾十種常見的 ADL。 ◎ IEEE P1471詳細介紹了一套體系結構描述的概念框架 ， 并給出建立框架的思路 。 基于底層語義的工具為體系結構的表示 、 分析 、 演化 、 細化 、 設計過程等提供支持 。 軟件體系結構 ＝ { 構件，連接件，約束 } 第四章 軟件體系結構描述 軟件體系結構描述語言 ◎ 構造能力： ADL能夠使用較小的獨立體系結構元素來建造大型軟件系統(tǒng)； ◎ 抽象能力： ADL使得軟件體系結構中的構件和連接件描述可以只關注它們的抽象特性 ， 而不管其具體的實現(xiàn)細節(jié)； ◎ 重用能力： ADL使得組成軟件系統(tǒng)的構件 、 連接件甚至是軟件體系結構都成為軟件系統(tǒng)開發(fā)和設計的可重用部件； ◇ ADL與其他語言的比較 (1) 典型的 ADL在充分繼承和吸收傳統(tǒng)程序設計語言的精確性和嚴格性特點的同時，還應具有：構造、抽象、重用、組合、異構、分析和推理等各種能力和特性。 軟件體系結構配置 連接件構件端口 角色1:N1:N1:N體系結構的核心模型 第四章 軟件體系結構描述 軟件體系結構描述語言 ◇ ADL的構成要素 2. 連接件：用來建立構件間的交互以及支配這些交互規(guī)則 的體系結構構造模塊。 第四章 軟件體系結構描述 軟件體系結構描述語言 ◇ ADL的構成要素 軟件體系結構的設計在需求分析之后，軟件設計之前。 ◇ C2背景知識 C2是一種用于用戶界面密集的系統(tǒng)的軟件體系結構風格 。 構件的頂端域定義了構件可以對哪些通知做出響應 ， 以及可以發(fā)出哪些請求；構件的底端域定義了可以向下層發(fā)送哪些通知 ， 以及可以響應下層的哪些請求 。 ◎ 通知消息的傳遞只對應于構件內部的操作 ， 而和接收消息的構件的需求無關 。 如果強調時間和順序，則使用順序圖；如果強調上下級關系，則選擇協(xié)作圖。 通用元素是 UML中的基本構造單位 ， 包括模型元素和視圖元素 ， 模型元素用來構造系統(tǒng) ， 視圖元素用來構成系統(tǒng)的表示成分； ◇ 通用機制：主要描述使 UML保持簡單和概念上一致的機制的語義 。A d d P r e f D a t e s ( ) 。RemoveExclSet()。MainConn第四章 軟件體系結構描述 軟件體系結構與 UML ◇ 直接使用 UML建模 ◎ 細化的類圖 第四章 軟件體系結構描述 軟件體系結構與 UML ◇ 直接使用 UML建模 ◎ 會議安排系統(tǒng)的協(xié)作圖 :Attendee :ImportantAttendee:MainConn:MeetingInitiator:ImportantAttConn:AttConn1:GetPrefSet()10:PrefSet(date_mg)9:PrefSet(date_mg)8:PrefSet(date_mg)7:PrefSet(date_mg)6:PrefSet(date_mg)5:GetPrefSet()3:GetPrefSet()4:GetPrefSet()2:GetPrefSet()11:PrefSet(date_mg)第四章 軟件體系結構描述 軟件體系結構與 UML ◇ 使用 UML擴展機制 自學 第四章 軟件體系結構描述 可擴展標記語言 ◇ XML語言簡介 XML(extensible markup language) 可擴展標記語言 XML結合了 SGML和 HTML的優(yōu)點并消除了其缺點。為了確保各種質量因素，大家都認為正確地對體系結構設計進行抽象很有必要。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 體系結構設計的原則 抽象的一個重要特性就是可替換性。封裝為不同抽象之間提供了明確的界限。信息隱藏也可以通過接口與實現(xiàn)的分離的原理來實現(xiàn)。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 體系結構設計的原則 由此帶來了復雜系統(tǒng)資源管理、維護和應用的邏輯和條理性，增加了應用設計的靈活性。內聚有幾種形式。這樣，對某一角色開放的只是與角色相關的信息和服務，避免了過多暴露所造成對應用設計的負擔和混亂，又保證了組件運行的可靠和安全。 接口部分定義了部件所提供的功能，并規(guī)范了功能的使用方法。就像封裝一樣，接口和實現(xiàn)的分離也是一種用來獲得信息隱藏的技術。 要區(qū)分幾種特殊化的“領域”概念：問題領域知識、商業(yè)領域知識、解決方案領域知識、通用知識，等等。 問題領域知識是指客戶觀點下的與問題有關的知識。 需求規(guī)格說明、領域知識。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 體系結構設計方法的分析 為了獲取對體系結構設計的抽象，人們已經提出了許多方法。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 用例驅動（ usecasedriven）的方法 用例驅動的體系結構設計方法主要從用例導出體系結構抽象。隨時間變化的過程的組織被定義為階段?！吧虡I(yè)模型”描述一個組織的商業(yè)過程。圖中的“ 4：組合”代表定義這些包之間的接口，其結果是“體系結構描述”的概念。這就帶來了如何適度把握這些模型的細節(jié)的問題。用例實現(xiàn)受到工件的啟發(fā)式規(guī)則的支持，還受到軟件工程師的通用知識的支持。包，類似于工件驅動的方法中的子系統(tǒng)，主要也是分組機制，因此其語義也很簡單。 也有研究者在軟件開發(fā)過程中的體系結構分析階段應用設計模式。 第四章 軟件體系結構描述 軟件體系結構的設計 缺點： （ 1）在處理范圍廣泛的體系結構問題時，模式庫可能不夠充分。這一問題的原因在于，體系結構由表示對特定領域的抽象的概念和定義這些概念的組成方式及其相互聯(lián)系的模式組成。 ◇ 模式驅動（ patterndriven）的方法 第四章 軟件體系結構描述 軟件體系結構的設計 缺點： （ 3）模式的應用并不是一個簡單直接的過程，它需要對問題進行全面的分析。 ◇ 模式驅動（ patterndriven）的方法 第四章 軟件體系結構描述 軟件體系結構的設計 缺點： （ 4）對于模式的組合沒有提供很好的支持。 缺點： （ 1）問題領域分析在導出體系結構抽象方面效果較差。 有些解決方案領域分析方法是獨立于軟件體系結構設計的，它們?yōu)榇_認潛在的可重用資源提供了系統(tǒng)的過程。其次是解決方案領域的內聚性可能不夠強，不夠穩(wěn)定，因而難以為體系結構設計提供堅實的基礎。 模式驅動的體系結構設計方法試圖通過從去定義的模式庫中選擇體系結構模式來開發(fā)體系結構。 第四章 軟件體系結構描述 軟件體系結構的設計 ◇ 小結 （ 2）客戶需求不是體系結構抽象的穩(wěn)固基礎 對于要開發(fā)的軟件系統(tǒng)，客戶需求不同于體系結構設想。甚