第4章軟件體系結構描述和設計1精選ppt本章結構4.1軟件體系結構描述方法4.2軟件體系結構描述框架標準4.3體系結構描述語言4.4典型的軟件體系結構描述語言（C2）4.5軟件體系結構與UML4.6可擴展標記語言4.7基于XML的軟件體系結構描述語言4.8軟件體系結構的設計2精選ppt3精選ppt引言當前對軟件體系結構的描述在很大程度上還停留在非形式化的基礎上，依賴于軟件設計師個人的經驗和技巧。非形式化的描述不易被開發人員理解，不利于分析和開發的進行。形式化的、規范化的體系結構描述對于體系結構的設計和理解都是非常重要的。由非形式化到形式化的過程。4精選ppt

描述方法的種類第四章軟件體系結構描述4.1軟件體系結構描述方法◎圖形表達工具◎模塊內連接語言◎基于軟構件的系統描述語言◎軟件體系結構描述語言

5精選ppt

圖形表達工具第四章軟件體系結構描述4.1軟件體系結構描述方法簡潔易懂容易使用使用廣泛不規范不精確6精選ppt

模塊內連接語言第四章軟件體系結構描述4.1軟件體系結構描述方法◎采用將一種或幾種傳統程序設計語言的模塊連接起來的模塊內連接語言（MIL）。由于程序設計語言和模塊內連接語言具有嚴格的語義基礎，因此它們能支持對較大的軟件單元進行描述，諸如定義/使用和扇入/扇出等操作。例如，Ada語言采用use實現包的重用，Pascal語言采用過程（函數）模塊的交互等。◎MIL方式對模塊化的程序設計和分段編譯等程序設計與開發技術確實發揮了很大的作用。但是由于這些語言處理和描述的軟件設計開發層次過于依賴程序設計語言，因此限制了它們處理和描述比程序設計語言元素更為抽象的高層次軟件體系結構元素的能力。7精選ppt

基于軟構件的系統描述語言第四章軟件體系結構描述4.1軟件體系結構描述方法◎基于軟構件的系統描述語言將軟件系統描述成一種是由許多以特定形式相互作用的特殊軟件實體構造組成的組織或系統。◎例如，一種多變配置語言就可以用來在一個較高的抽象層次上對系統的體系結構建模，Darwin最初用作設計和構造復雜分布式系統的配置說明語言，因具有動態特性，也可用來描述動態體系結構。◎這種表達和描述方式雖然也是較好的一種以構件為單位的軟件系統描述方法，但是他們所面向和針對的系統元素仍然是一些層次較低的以程序設計為基礎的通信協作軟件實體單元，而且這些語言所描述和表達的系統一般而言都是面向特定應用的特殊系統，這些特性使得基于軟構件的系統描述仍然不是十分適合軟件體系結構的描述和表達。8精選ppt

軟件體系結構描述語言第四章軟件體系結構描述4.1軟件體系結構描述方法◎軟件體系結構的第四種描述和表達方法是參照傳統程序設計語言的設計和開發經驗，重新設計、開發和使用針對軟件體系結構特點的專門的軟件體系結構描述語言——ADL。◎由于ADL是在吸收了傳統程序設計中的語義嚴格精確的特點基礎上，針對軟件體系結構的整體性和抽象性特點，定義和確定適合于軟件體系結構表達與描述的有關抽象元素，因此，ADL是當前軟件開發和設計方法學中一種發展很快的軟件體系結構描述方法，目前，已經有幾十種常見的ADL。9精選ppt

軟件體系結構的應用現狀第一章軟件體系結構概論1.4體系結構的應用現狀◎軟件體系結構描述語言

ADL（體系結構描述語言）提供了具體的語法與刻畫體系結構的概念框架。ADL使得系統開發者能夠很好地描述他們設計的體系結構，以便與他人交流，能夠用提供的工具對許多實例進行分析。對于ADL現在也是無統一認識。書上第四章有介紹。請參閱《軟件體系結構——理論與實踐》，馮沖江賀馮靜芳編著，人民郵電出版社。第2章軟件體系結構語言（ADL）10精選ppt

IEEEP1471第四章軟件體系結構描述4.2軟件體系結構描述框架標準◎IEEEP1471于2000年9月21日通過IEEE-SA標準委員會評審。◎IEEEP1471適用于軟件密集的系統，其目標在于：便于體系結構的表達與交流，并通過體系結構要素及其實踐標準化，奠定質量與成本的基礎。◎IEEEP1471詳細介紹了一套體系結構描述的概念框架，并給出建立框架的思路。但如何描述以及具體的描述技術等方面缺乏更進一步的指導。

11精選ppt

Rational第四章軟件體系結構描述4.2軟件體系結構描述框架標準◎Rational起草了可重用的軟件資產規格說明，專門討論了體系結構描述的規格說明，提出了一套易于重用的體系結構描述規范。該建議草案已經提交OMG。◎基于RUP（RationalUnitedProcess）、采用UML模型描述軟件的體系結構，認為體系結構描述的關鍵是定義視點、視圖以及建模元素之間的映射關系。（4個視點、7個體系結構視圖）

◎與IEEEP1471相比，該建議標準的體系結構描述方案涉及面比較窄，所注重的層次比較低，因而更具體。由于將體系結構的描述限于UML和RUP，具有一定的局限性，但該建議標準結合了業界已經廣泛采用的建模語言和開發過程，因而易于推廣，可以有效實現在跨組織之間重用體系結構描述結果。12精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言ADL是在底層語義模型的支持下，為軟件系統的概念體系結構建模提供了具體語法和概念框架。基于底層語義的工具為體系結構的表示、分析、演化、細化、設計過程等提供支持。其三個基本元素是：構件、連接件、體系結構配置。主要的體系結構描述語言有Aesop、MetaH、C2、Rapide、SADL、Unicon和Wright等，盡管它們都描述軟件體系結構，卻有不同的特點。這些ADL強調了體系結構不同的側面，對體系結構的研究和應用起到了重要的作用，但也有負面的影響。每一種ADL都以獨立的形式存在，描述語法不同且互不兼容，同時又有許多共同的特征，這使設計人員很難選擇一種合適的ADL，若設計特定領域的軟件體系結構又需要從頭開始描述。13精選ppt

軟件體系結構的定義第一章軟件體系結構概論1.3體系結構的興起和發展◎MaryShaw和DavidGarlan（1993年）

軟件體系結構是軟件設計過程中的一個層次，這一層次超越計算過程中的算法設計和數據結構設計。體系結構問題包括總體組織和全局控制，通訊協議，同步，數據存取，給設計元素分配特定功能，設計元素的組織、規模和性能，在各設計方案間進行選擇等。軟件體系結構處理算法與數據結構之上關于整體系統結構設計和描述方面的一些問題，如全局組織和全局控制結構、關于通訊、同步與數據存取的協議，設計構件功能定義，物理分布與合成，設計方案的選擇、評估與實現等。軟件體系結構＝{構件，連接件，約束}14精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言◎構造能力：ADL能夠使用較小的獨立體系結構元素來建造大型軟件系統；◎抽象能力：ADL使得軟件體系結構中的構件和連接件描述可以只關注它們的抽象特性，而不管其具體的實現細節；◎重用能力：ADL使得組成軟件系統的構件、連接件甚至是軟件體系結構都成為軟件系統開發和設計的可重用部件；

ADL與其他語言的比較(1)典型的ADL在充分繼承和吸收傳統程序設計語言的精確性和嚴格性特點的同時，還應具有：構造、抽象、重用、組合、異構、分析和推理等各種能力和特性。15精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言◎組合能力：ADL使得其描述的每一系統元素都有其自己的局部結構，這種描述局部結構的特點使得ADL支持軟件系統的動態變化組合；◎異構能力：ADL允許多個不同的體系結構描述關聯存在；◎分析和推理能力：ADL允許對其描述的體系結構進行多種不同的性能和功能上的多種推理分析。

ADL與其他語言的比較(2)16精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言◎ADL與需求語言的區別：后者描述的是問題空間，而前者扎根于解空間。◎ADL與建模語言的區別：后者對整體行為的關注要大于對部分的關注，而ADL集中在構件的表示上。◎ADL與傳統的程序設計語言的構成元素既有許多相同和相似之處，又各自有著很大的不同。

ADL與其他語言的比較(3)17精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言

典型元素含義比較18精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言

常見的軟件體系結構元素19精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言

ADL的構成要素軟件體系結構的基本構成要素：構件、連接件、體系結構配置。1.構件：一個計算單元或數據存儲；是計算與狀態存在的場所。構件包含的多種屬性：接口、類型、語義、約束、演化和非功能屬性等。體系結構的核心模型20精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言

ADL的構成要素2.連接件：用來建立構件間的交互以及支配這些交互規則的體系結構構造模塊。連接件可以不與實現系統中的編譯單元對應。異構連接。連接件包含的屬性：角色。21精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言

ADL的構成要素3.體系結構配置或拓撲：描述體系結構的構件與連接件的連接圖。同時檢查語法、說明語義。多視圖、多場景的體系結構說明方法。在不同層次上描述軟件系統；異構情況下的配置。22精選ppt第四章軟件體系結構描述4.3軟件體系結構描述語言

ADL的構成要素軟件體系結構的設計在需求分析之后，軟件設計之前。描述好體系結構，做好承上啟下的工作很重要。一方面：體系結構描述如何向其他文檔轉移；另一方面：如何利用需求分析成果來直接生成系統的體系結構說明。現在的ADL大多與領域相關。目前還沒有通用的體系結構描述語言。23精選ppt當前常見的一些體系結構描述語言、方法：

ACME

WrightC2UniCon

DarwinAESOP

RapideWeaves

SADL

UMLGestaltDemeterFRControlH&MetaH24精選ppt

C2風格通過連接件綁定在一起的按照一組規則運作的并行構件網絡。C2風格中的系統組織規則如下：◎系統中的構件和連接件都有一個頂部和一個底部；◎構件的頂部應連接到某連接件的底部，構件的底部則應連接到某連接件的頂部，而構件與構件之間的直接連接是不允許的；◎一個連接件可以和任意數目的其它構件和連接件連接；◎當兩個連接件進行直接連接時，必須由其中一個的底部到另一個的頂部。25精選ppt

C2背景知識C2是一種用于用戶界面密集的系統的軟件體系結構風格。在C2風格的體系結構中，連接件在構件之間轉發消息，構件負責維護狀態，進行操作，通過兩個接口（頂端接口和底端接口）和其他構件交換消息。構件之間不能發送消息，必須通過連接件。構件之間的通信只能通過消息傳遞來實現，不允許使用共享內存方式通信。26精選ppt

C2風格的中心原則C2風格的中心原則是有限可視原則，或者說是下層獨立的原則：在C2風格的體系結構中，某一構件只能感知層次高于自己的構件所提供的服務，而不能感知到層次比自己更低的構件的服務。這種單向的傳遞性，有利于系統的維護和擴展。27精選ppt

C2風格的通信規則C2中，所有構件間的通信必須通過消息來實現，這也是構件之間的唯一通信途徑。每個構件都有一個頂端域、一個底端域。構件的頂端域定義了構件可以對哪些通知做出響應，以及可以發出哪些請求；構件的底端域定義了可以向下層發送哪些通知，以及可以響應下層的哪些請求。構件請求通知28精選ppt

C2風格29精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言◎C2和其提供的設計環境（Argo）支持采用基于時間的風格來描述用戶界面系統，并支持使用可替換、可重用的構件開發GUI的體系結構。◎在C2中，連接件負責構件之間消息的傳遞，而構件維持狀態、執行操作并通過兩個名字分別為“top”和“bottom”的端口和其它的構件交換信息。◎每個接口包含一種可發送的消息和一組可接收的消息。構件之間的消息要么是請求其它構件執行某個操作的請求消息，要么是通知其他構件自身執行了某個操作或狀態發生改變的通知消息。

C2概述(1)30精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言◎構件之間的消息交換不能直接進行，而只能通過連接件來完成。每個構件接口最多只能和一個連接件相連，而連接件可以和任意數目的構件或連接件相連。◎請求消息只能向上層傳送而通知消息只能向下層傳送。◎通知消息的傳遞只對應于構件內部的操作，而和接收消息的構件的需求無關。◎C2對構件和連接件的實現語言、實現構件的線程控制、構件的部署以及連接件使用的通訊協議等都不加限制。

C2概述(2)31精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對構件接口的描述32精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對構件的描述interface_requests::={request；}|null；

interface_notifications::={notification；}|null；

request::=message_name(request_parameters)

request_parameters::=[tocomponent_name][parameter_list]

notification::=message_name[parameter_list]component_message_interface::=top_domain_interfacebottom_domain_interface

top_domain_interface::=top_domainisoutinterface_requestsininterface_notifications

bottom_domain_interface::=bottom_domainisoutinterface_notificationsininterface_requests33精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

會議安排系統的C2風格34精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對MeetgingInitiator構件的描述(1)componentMeetingInitiatorisinterfacetop_domainisoutGetPrefSet()；GetExclSet()；GetEquipReqts()；GetLocPrefs()；RemoveExclSet()；RequestWithdrawal(toAttendee)；RequestWithdrawal(toImportantAttendee)；AddPrefDates()；MarkMtg(d:date；l:lov_type)；35精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對MeetgingInitiator構件的描述(2)inPrefSet(p:date_mg)；ExclSet(e:data_mg)；EquipReqts(eq:equip_type)；LocPref(l:loc_type)；behaviorstartupalways_generateGetPrefSet，GetExclSet，GetEquipReqts，GetLocPrefs；received_messagesPrefSetmay_generateRemoveExclSetxorRequestWithdrawalxorMarkMtg；received_messagesExclSetmay_generateAddPrefDatesxorRemoveExclSetxorRequestWithdrawalxorMarkMtg；received_messagesEquipReqtsmay_generateAddPrefDatesxorRemoveExclSetxorRequestWithdrawalxorMarkMtg；received_messagesLocPrefalways_generatenull；endMeetingInitiator；

36精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對Attendee構件的描述(1)componentAttendeeisinterfacebottom_domainisoutPrefSet(p:date_mg)；ExclSet(e:date_mg)；EquipReqts(eq:equip_type)；inGetPrefSet()；GetExclSet()；GetEquipReqts()；RemoveExclSet()；RequestWithdrawal()；AddPrefDates()；MarkMtg(d:date；l:loc_type)；37精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對Attendee構件的描述(2)behaviorreceived_messagesGetPrefSetalways_generatePrefSet；received_messagesAddPrefDatesalways_generatePrefSet；received_messagesGetExclSetalways_generateExclSet；received_messagesGetEqipReqtsalways_generateEqipReqts；received_messagesRemoveExclSetalways_generateExclSet；received_messagesReuestWithdrawalalways_generatenull；received_messagesMarkMtgalways_generatenull；endAttendee；

38精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對ImportantAttendee構件的描述componentImportantAttendeeissubtypeAttendee(inandbeh)interfacebottom_domainisoutLocPrefs(l:loc_type)；ExclSet(e:date_mg)；EquipReqts(eq:equip_type)；inGetLocPrefs()；behaviorreceived_messagesGetLocPrefsalways_generateLocPrefs；endImportantAttendee；

39精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對體系結構的描述architectureMeetingScheduleris

conceptual_componentsAttendee；ImportantAttendee；MeetingInitiator；connectorsconnectorMainConnismessage_filterno_filtering；connectorAttConnismessage_filterno_filtering；connectorImportantAttConnismessage_filterno_filtering；architectural_topologyconnectorAttConnconnectionstop_portsAttendee；bottom_portsMainConn；connectorImportantAttConnconnectionstop_portsImportantAttendee；bottom_portsMainConn；connectorMainConnconnectionstop_portsAttConn；ImportantAttConn；bottom_portsMeetingInitiator；endMeetingScheduler；

40精選ppt第四章軟件體系結構描述4.4典型軟件體系結構描述語言

C2對會議安排系統的描述systemMeetingScheduler_1isarchitectureMeetingSchedulerwithAttendeeinstanceAtt_1，Att_2，Att_3；ImportantAttendeeinstanceImpAtt_1，ImpAtt_2；MeetingInitiatorinstanceMtgInit_1；endMeetingScheduler_1；

41精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

UML簡介◎UML(UnifiedModelingLanguage)是下面這些最好的建模方法中最好部分的集成:

商務流程模型(WorkFlow)

對象建模方法

軟構件建模思想◎UML是一種用可視化方法對軟件系統進行描述、實施和說明的標準語言。◎支持用不同實現技術進行的軟件開發全過程。42精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

UML簡介43精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

UML簡介44精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

UML簡介UseCaseDiagramsUseCaseDiagrams用例圖ScenarioDiagramsScenarioDiagrams協作圖StateDiagramsStateDiagrams構件圖ComponentDiagramsComponentDiagrams部署圖StateDiagramsStateDiagrams對象圖ScenarioDiagramsScenarioDiagrams狀態圖UseCaseDiagramsUseCaseDiagrams順序圖StateDiagramsStateDiagrams類圖活動圖UML45精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

用例圖用于顯示若干角色以及這些角色與系統提供的用例之間的連接關系。用例是系統提供的功能的描述。46精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

類圖表示系統中的類和類與類之間的關系，它是對系統靜態結構的描述。47精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

順序圖用來反映若干個對象之間的動態協作關系，也就是隨著時間的推移，對象之間是如何交互的

48精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

協作圖描述對象間的協作關系，協作圖跟順序圖相似，顯示對象間的動態合作關系。如果強調時間和順序，則使用順序圖；如果強調上下級關系，則選擇協作圖。這兩種圖合稱為交互圖。

49精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

狀態圖描述類的對象所有可能的狀態以及事件發生時狀態的轉移條件。通常，狀態圖是對類圖的補充50精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

活動圖描述滿足用例要求所要進行的活動以及活動間的約束關系，有利于識別并行活動51精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

構件圖描述代碼構件的物理結構及各構件之間的依賴關系52精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

部署圖部署圖定義系統中軟硬件的物理體系結構

53精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模UML的四層元模型體系結構。元-元模型層定義了元模型層的規格說明語言；

元模型層為給定的建模語言定義規格說明；模型層用來定義特定軟件系統的模型；用戶對象用來構建給定模型的特定實例。54精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎語義約束由對象約束語言OCL表示，OCL基于一階謂詞邏輯，每一個OCL表達式都處于一些UML模型元素的背景下（由“self”引用），可使用該元素的屬性和關系作為其項（term），同時OCL定義了在集合（sets）、袋(bags)等上的公共操作集和遍歷建模元素間關系的構造，因此，其它建模元素的屬性也可以作為它的項。55精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎UML中的通用表示（1）字符串：表示有關模型的信息；（2）名字：表示模型元素；（3）標號：不同于編程語言中的標號，是用于表示或說明圖形符號的字符串；（4）特殊字符串：表示某一模型元素的特性；（5）類型表達式：聲明屬性、變量及參數，含義同編程語言中的類型表達式；（6）實體類型：它是UML的擴充機制，運用實體類型可定義新類型的模型元素；（7）語義部分是對UML的準確表示，由三部分組成。56精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎UML語義部分

通用元素：主要描述UML中各元素的語義。通用元素是UML中的基本構造單位，包括模型元素和視圖元素，模型元素用來構造系統，視圖元素用來構成系統的表示成分；

通用機制：主要描述使UML保持簡單和概念上一致的機制的語義。包括定制、標記值、注記、約束、依賴關系、類型-實例、類型-類的對應關系等機制；

通用類型：主要描述UML中各種類型的語義。這些類型包括布爾類型、表達式類型、列表類型、多重性類型、名字類型、坐標類型、字符串類型、時間類型、用戶自定義類型等。三部分不是相互獨立的，而是相互交叉重疊、緊密相連，共同構成了UML的完整語義。57精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎會議安排系統的類圖58精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎會議安排系統類接口

59精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎C2連接件模型60精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎細化的類圖61精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

直接使用UML建模◎會議安排系統的協作圖62精選ppt第四章軟件體系結構描述4.5軟件體系結構與UML

使用UML擴展機制自學63精選ppt第四章軟件體系結構描述4.6可擴展標記語言

XML語言簡介XML(extensiblemarkuplanguage)可擴展標記語言XML結合了SGML和HTML的優點并消除了其缺點。XML是用來描述數據的；用戶可以創建自己需要的標記，當需要時，告訴瀏覽器如何顯示這些標記就可以了。另外，XML標記描述的是文檔的結構和意義，不描述頁面元素的格式化。文檔本身只說明文檔包括什么標記，而不是說明文檔看起來是什么樣的。64精選ppt第四章軟件體系結構描述4.6可擴展標記語言

XML相關技術簡介XML主要是一種數據描述方法。XML相關的技術有很多，但主要有三個：Schema、XSL和XLL。◎DTD與Schema◎CSS和XSL◎Xpath，Xpointer與Xlink◎XML名字空間◎XML查詢語句◎資源描述框架◎DOM、SAX和XML解析器65精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

概述當前，對軟件體系結構設計的共識之一是，體系結構設計應當支持對軟件系統質量的需求（非功能特性的需求）。這是因為，軟件體系結構包括了早期的設計決定，體現了系統的全局結構，對于整個系統的質量有著決定性的影響。為了確保各種質量因素，大家都認為正確地對體系結構設計進行抽象很有必要。但是，正如軟件體系結構的其他概念和方法一樣，對于體系結構設計人們也沒有形成統一的認識。66精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則◎抽象◎分而治之◎封裝和信息隱蔽◎模塊化◎高內聚和低耦合◎關注點分離◎策略和實現的分離◎接口和實現的分離基本原則：67精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則抽象是人們用來處理復雜性問題的基本原理之一。抽象有幾種形式，如數據抽象、對象抽象、實體抽象、行為抽象、過程抽象、虛擬機抽象等。數據、實體的抽象使得軟件操作的對象和參數是針對邏輯結構，而非存儲結構的。行為、過程的抽象使得操作的指派是依據標識而非地址，由此產生了操作的接口和動態約束描述。在處理系統復雜性方面，抽象起到了重要作用。減少部件耦合、接口與實現的分離等，都得益于抽象。1.抽象68精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則抽象的一個重要特性就是可替換性。對象的抽象把具有相同基類的導出類看作是同類，加上過程抽象帶來的在過程名稱下的“偷梁換柱”，因此實現了動態約束，使面向抽象問題而不是實際結構的抽象程序設計得以實現。大量的結構模式和應用問題都是基于這個思想而得到實現的。1.抽象69精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則這條原理是眾所周知的，它來自古時的政治，也來自諸如歸并分類的組合算法。在軟件體系結構中該原理得到大量應用。例如，自上而下設計將一個任務或部件分成可以獨立設計的更小的部分。該原理經常被用來作為實現注意點分離的方法。2.分而治之70精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則封裝是將構成抽象的屬性和行為結合在一起，并區分不同抽象的方法。封裝為不同抽象之間提供了明確的界限。封裝有利于非功能特性實現，例如可變性和可重用性。封裝包括內部構成和操作服務兩個方面。例如，通過對象、模塊設計和訪問接口設計分別提供了這兩種封裝。3.封裝和信息隱蔽71精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則信息隱蔽是軟件工程的最基本和最重要的原理之一。信息隱蔽對用戶隱藏了部件的實現細節，用來更好地處理系統的復雜性和減少各部件之間的耦合。為了更好地應用，用戶不需要知道的細節都應該由部件隱藏起來。封裝原理經常被用來作為實現信息隱藏的方法。信息隱藏也可以通過接口與實現的分離的原理來實現。3.封裝和信息隱蔽72精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則然而，部件應該隱藏什么取決于具體的應用。在一個應用中客戶不需要知道的方面或許在另外一個應用中就需要看到。例如，在一個應用中為了提高運行性能，可能需要對某一部件的內部數據結構進行直接訪問；而在另外一個應用中，可能因為對其性能已經滿意了，就不需要對其數據的直接訪問了。3.封裝和信息隱蔽73精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則模塊化主要關心的是如何將一個軟件系統分解成子系統和部件，其主要任務就是決定怎樣將構成應用的邏輯結構物理地分割成代碼實體。模塊化的主要做法，就是在一個系統內引入具有良好定義的分界，依此來處理系統的復雜性。模塊的作用是為了一個應用的功能和責任的物理容器。模塊化與封裝原理的聯系非常密切。4.模塊化74精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則由此帶來了復雜系統資源管理、維護和應用的邏輯和條理性，增加了應用設計的靈活性。另外它對于系統的運行設計和管理調度也提供了方便，例如，對于動態鏈接庫的選擇應用、程序運行體的覆蓋和交換都是十分有益的。4.模塊化75精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則耦合和內聚最初是作為結構化設計方法的部分原理而提出的。耦合強調模塊之間的特征，而內聚強調模塊內部的特性。耦合是用來衡量一個模塊同另一個模塊的聯系的緊密程度的。緊密的耦合就會使系統變得復雜，因為如果一個模塊和另外的模塊有很密切的關聯的話，這個模塊就很難理解、調試、維護。通過弱耦合部件的設計可以降低系統的復雜性。5.高內聚和低耦合76精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則內聚用來衡量單一模塊內功能和元素間聯系性的程度。內聚有幾種形式。最期望獲得的是功能內聚，它說明一個模塊或是部件內的所有元素都協同來提供具有良好邊界的行為。最差的形式是偶然內聚，這種形式將毫無聯系的抽象放置在同一模塊之中。其他形式的內聚還有：邏輯內聚、時間內聚、過程內聚、通信內聚、順序內聚和不規則內聚。5.高內聚和低耦合77精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則不同和無關聯的責任應該在軟件系統中分離開來，讓它們出現在不同的部件中。相互協作完成某一個特定任務的部件應該和在其他任務中執行計算的部分分離開來。如果一個部件在不同的環境下扮演著不同的角色，在部件中這些角色應該獨立且相互分離。6.關注點分離78精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則例如，在多層體系結構的組件設計中，在多種應用場景中擔任不同角色的同一個組件，需要和可以使用不同的接口定義。這樣，對某一角色開放的只是與角色相關的信息和服務，避免了過多暴露所造成對應用設計的負擔和混亂，又保證了組件運行的可靠和安全。6.關注點分離79精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則軟件系統的部件應該實現策略或處理問題，但不能同時處理兩者。策略部件負責處理上下文相關的決策、信息的語義和解釋的知識、把不相交計算組合形成結果、對參數值進行選擇等問題。實現部件負責全面規范算法的執行，執行中不需要對上下文相關信息進行決策。上下文和解釋是部件外部施加的，它通常由傳給部件的參數提供。7.策略和實現的分離80精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則由于獨立于特定的上下文環境，純實現部件更容易重用和維護，而策略部件通常是與特定應用相關的，需要隨著應用的變化而變化。如果不能將一個軟件體系結構分解成策略和實現的不同部件，至少應該在一個部件內將策略和實現的功能加以分離。7.策略和實現的分離81精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則任何一個部件都應該包含兩個部分，接口和實現。接口部分定義了部件所提供的功能，并規范了功能的使用方法。該接口對部件的客戶是可訪問的。該類型的輸出接口是由函數原型構成的。實現部分包括了實現部件所提供功能的實際代碼。實現部分還可以包含只服務于部件內部操作的另外的函數和數據結構。實現部分對部件客戶來說是不可用的。8.接口和實現的分離82精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計的原則該原理的主要目的是防止部件的客戶接觸到實現的細節，而只為客戶提供部件的接口規范和使用方法。另外，該原理還允許獨立于其他部件的應用而實現一個部件的功能。就像封裝一樣，接口和實現的分離也是一種用來獲得信息隱藏的技術。該原理強調“一個客戶只應該知道它需要知道的東西”。接口和實現的分離也支持可變性。如果部件的接口和實現分離，那么它就更容易在系統中進行改變。這種分離避免了客戶直接受到部件變化的影響。該原理使部件行為和表示的改變特別容易，尤其是那些不影響接口的改變，例如對運行性能的提高。8.接口和實現的分離83精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計方法的元模型元模型是對各種體系結構設計模型的抽象。元模型中有三處用到了領域知識的概念。要區分幾種特殊化的“領域”概念：問題領域知識、商業領域知識、解決方案領域知識、通用知識，等等。84精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計方法的元模型商業領域知識是指商業過程觀點下的與問題有關的知識。包括商業過程方面的知識、用戶調查、市場分析報告等。解決方案領域知識是指提供領域概念的知識。這些領域概念用于解決問題，并獨立于特定需求。解決方案領域知識還包括如何從這一解決方案領域生產軟件系統。通用知識是指軟件工程師的一般背景和經驗。系統/產品知識是指關于一個系統、一個系統族或一個產品的知識。問題領域知識是指客戶觀點下的與問題有關的知識。包括需求規格說明文檔、與客戶面談、客戶發布的原型等。85精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計方法的元模型第一階段：捕捉需求。客戶：表示那些關心軟件體系結構設計的系統相關人員。包括：客戶、最終用戶、系統開發人員、系統維護人員、銷售人員等。領域知識：表示在解決某一問題中所應用的知識的范圍。需求規格說明：表示規格說明，描述了所要開發的體系結構系統的需求。86精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計方法的元模型第二階段：提取解決方案的結構。需求規格說明、領域知識。工件：表示某一方法的工件描述。這是指諸如工件類、工件操作、工件屬性等。一般，每種工件都有一套與之相關的試探法，用來標識相關的工件實例。解決方案抽象：定義了體系結構中（子）結構的概念表示。87精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計方法的元模型第三階段：體系結構規格說明。解決方案抽象、領域知識。體系結構描述：定義了軟件體系結構的規格說明。88精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

體系結構設計方法的分析為了獲取對體系結構設計的抽象，人們已經提出了許多方法。我們把這些體系結構設計方法分類為：工件驅動（artifact-driven）的方法；用例驅動（use-case-driven）的方法；模式驅動（pattern-driven）的方法；域驅動（domain-driven）的方法。89精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

工件驅動（artifact-driven）的方法工件驅動的體系結構設計方法的概念模型特點：從方法的工件描述中提取體系結構描述。90精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

工件驅動（artifact-driven）的方法工件驅動的體系結構設計方法的例子包括廣為流行的面向對象分析和設計方法OMT和OAD。91精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

工件驅動（artifact-driven）的方法缺點：（1）文本形式的系統需求不夠清楚、精確、完整。以它作為導出體系結構抽象的來源作用不夠。（2）子系統的語義過于簡單，難以作為體系結構構件。（3）對子系統的組合支持不足。92精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

用例驅動（use-case-driven）的方法用例驅動的體系結構設計方法主要從用例導出體系結構抽象。目的：作為系統預期功能及其環境的模型，并在客戶和開發者之間起到合約的作用。93精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

用例驅動（use-case-driven）的方法一個用例，是指系統進行的一個活動序列，它為參與者提供一些結果值。參與者通過用例使用系統。參與者和用例共同構成了用例模型。94精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

用例驅動（use-case-driven）的方法統一過程使用的是一種用例驅動的體系結構設計方法。它由核心工作流組成。核心工作流定義了過程的靜態內容，用活動、工人和工件描述了過程。隨時間變化的過程的組織被定義為階段。統一過程由6個核心工作流組成：商業模型、需求、分析、設計、實現和測試。這些核心工作流的結果分別是下列模型：商業和領域模型、用例模型、分析模型、設計模型、實現模型和測試模型。95精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

用例驅動（use-case-driven）的方法在需求工作流中，以用例的形式捕捉客戶的需求，構成用例模型。這一過程在上圖中被定義為“1：描述”。用例模型和非形式化的需求規格說明共同構成了系統的需求規格說明。用例模型的開發得到了“非形式化的規格說明”，“領域模型”，“商業模型”等概念的支持，在設置系統上下文時這些概念是必需的。如前所述，“非形式化的規格說明”表示文本形式的需求規格說明。“商業模型”描述一個組織的商業過程。“領域模型”描述領域上下文中最重要的類。96精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

用例驅動（use-case-driven）的方法從用例模型中可以選擇出對于體系結構有重要意義的用例，并創建“用例實現”，如上圖中“2：實現”所述。用例實現決定了任務在系統內部是怎樣進行的。用例實現受到相關工件的知識和通用知識的支持。這在圖中被表示為分別從“工件”和“通用知識”引出的指向“2：實現”的箭頭線。這一功能的輸出是“分析和設計模型”概念，它表示在用例實現之后標識出的工件。97精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

用例驅動（use-case-driven）的方法然后，分析和設計模型被分組為包，這在圖中表示為“3：分組”。圖中的“4：組合”代表定義這些包之間的接口，其結果是“體系結構描述”的概念。“3：分組”和“4：組合”這兩個功能都受到“通用知識”概念的支持。98精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（1）難以適度把握領域模型和商業模型的細節。（2）對于如何選擇與體系結構相關的用例沒有提供系統的支持。（3）用例沒有為體系結構抽象提供堅實的基礎。（4）包的語義過于簡單，難以作為體系結構構件。

用例驅動（use-case-driven）的方法99精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（1）難以適度把握領域模型和商業模型的細節。該方法在定義用例模型之前進行商業模型和領域模型的定義。這就帶來了如何適度把握這些模型的細節的問題。在了解用例之前，很難回答這一問題，因為用例實際上定義了所要開發的是什么。

用例驅動（use-case-driven）的方法100精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（2）對于如何選擇與體系結構相關的用例沒有提供系統的支持。為了進行體系結構描述，需要選擇與體系結構相關的用例。但在確定哪些用例是“體系結構相關”時，缺乏客觀標準，僅憑一些啟發式規則和軟件工程師的評估。

用例驅動（use-case-driven）的方法101精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（3）用例沒有為體系結構抽象提供堅實的基礎。在選擇出與體系結構相關的用例之后，對它們進行實現。這意味著分析和設計類是從用例中確定的。用例實現受到工件的啟發式規則的支持，還受到軟件工程師的通用知識的支持。工件是從文本形式的需求中得出的，這類似于工件驅動的方法。盡管用例對于理解和表示用戶需求是實用的，但它并不能為導出體系結構設計抽象提供堅實的基礎。用例主要關注的是系統的問題域和外部行為。在用例實現中，解決方案領域和內部系統中的透明或隱藏抽象將難以標識。因此，即使確定了所有的相關用例，從用例模型確定體系結構抽象仍將是較為困難的。

用例驅動（use-case-driven）的方法102精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（4）包的語義過于簡單，難以作為體系結構構件。該方法中，分析和設計模型被分組為包。包，類似于工件驅動的方法中的子系統，主要也是分組機制，因此其語義也很簡單。而且，在把分析和設計類分組成包、以及把包組合為最終的體系結構等方面，該方法提供的支持也很有限，主要依靠軟件工程師的通用知識。這也可能帶來錯誤定義的體系結構邊界及其交互。

用例驅動（use-case-driven）的方法103精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

模式驅動（pattern-driven）的方法體系結構模式關心的是體系結構級別的元素及其交互。體系結構設計模式本身不是軟件體系結構，而是體系結構層次的一種抽象表示。104精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

模式驅動（pattern-driven）的方法軟件工業界已經廣泛接受了軟件設計模式的概念。軟件設計模式的目的在于編制一套可重用的基本原則，用于開發高質量的軟件系統。軟件設計模式常常用在設計階段。也有研究者在軟件開發過程中的體系結構分析階段應用設計模式。體系結構模式類似于設計模式，實際上它就是體系結構風格的另一種名稱。105精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

模式驅動（pattern-driven）的方法體系結構模式描述的概念指的是對體系結構模式的描述。主要由4個概念組成：●意圖：表示使用模式的基本原則；●上下文：表示問題的產生環境；●問題：表示上下文環境中經常出現的問題；●解決方案：是以元素及其關系的抽象描述的形式來表示對問題的解決方案。為了確認模式，就要對各個可用模式的意圖進行掃描。如果發現一個模式的意圖和給出的問題相關，那么就分析它的上下文描述。如果上下文描述仍然能夠和給出的問題相匹配，則處理過程進入“應用”階段。進而用“解決方案”這一子概念來提供所給出問題的解決方案。106精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（1）在處理范圍廣泛的體系結構問題時，模式庫可能不夠充分。（2）對模式的選擇僅依靠通用知識和軟件工程師的經驗。（3）模式的應用并不是一個簡單直接的過程，它需要對問題進行全面的分析。（4）對于模式的組合沒有提供很好的支持。

模式驅動（pattern-driven）的方法107精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（1）在處理范圍廣泛的體系結構問題時，模式庫可能不夠充分。對于模式驅動的體系結構設計方法而言，必要的條件之一是有充足的模式庫可用。當前已經存在眾多的體系結構模式（風格）分類。盡管這些分類為軟件體系結構設計提供了使用的工具，但是它們沒有也無法覆蓋所有范圍內的體系結構開發問題。這一問題的原因在于，體系結構由表示對特定領域的抽象的概念和定義這些概念的組成方式及其相互聯系的模式組成。由于應用領域中的軟件系統千變萬化，所以，也就有無數的體系結構抽象和體系結構模式。

模式驅動（pattern-driven）的方法108精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（2）對模式的選擇僅依靠通用知識和軟件工程師的經驗。為了簡化對模式的選擇和管理，改進對模式的理解，人們通常把具有共同特點的模式分類到相同的組中。不同的體系結構設計方法可能有不同的分類原則。這樣，對于同一問題，可能有多種體系結構模式可供選擇。但是，在如何確定優先次序、如何在不同模式間進行取舍和平衡等問題上，當前的體系結構設計方法并沒有提供明確的支持。這妨礙了查找模式的過程，也進而妨礙了體系結構的確定。

模式驅動（pattern-driven）的方法109精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（3）模式的應用并不是一個簡單直接的過程，它需要對問題進行全面的分析。在選擇了模式之后，模式的應用也并不是一個簡單直接的過程。可以把模式看成是一種模板，它由構件及其相互關系組成，在使用時，必須與問題領域的概念和概念之間的關系相匹配。

模式驅動（pattern-driven）的方法110精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計例如，對于一個給定的問題，選擇使用管道－過濾器模式。在這種模式中，過濾器作為構件，管道作為連接件。過濾器接收輸入數據，進行處理，提供輸出數據；管道在一個過濾器的輸出和另一個過濾器的輸入之間發送數據。在應用這種模式時，存在的問題有：應當把哪些領域概念表示成管道，把哪些領域概念表示成過濾器？它們的結構是怎樣的？等等。當前，對于這一匹配過程并沒有嚴格的方法可循，模式的應用仍然基于軟件工程師的經驗和通用知識。

模式驅動（pattern-driven）的方法111精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計缺點：（4）對于模式的組合沒有提供很好的支持。在開發軟件體系結構時，常常要組合使用多種模式。這些模式通常并不是相互獨立的，而是存在著相互聯系。分別對這些模式進行定義并不能表示出模式之間的相關性。但是，當前并沒有系統的方法或明確的原則說明應當如何組合模式。假設在某問題中，經過問題分析階段之后，我們認為要組合使用分層模式、管道－過濾器模式和倉庫模式。我們應當怎樣組織這3種模式？哪種模式是基本的？它們之間有著怎樣的依賴關系？當前的模式驅動的體系結構設計方法并不能為這些問題提供滿意的答案。

模式驅動（pattern-driven）的方法112精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

域驅動（domain-driven）的方法113精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

域驅動（domain-driven）的方法主要用于產品線體系結構設計和特定領域的軟件體系結構設計。缺點：（1）問題領域分析在導出體系結構抽象方面效果較差。（2）解決方案領域分析不夠充分。114精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

域驅動（domain-driven）的方法缺點：（1）問題領域分析在導出體系結構抽象方面效果較差。一些領域驅動的體系結構設計方法把領域解釋成問題領域。例如，DSSA方法從非形式化的問題聲明開始，并從基于場景的領域模型導出體系結構抽象。類似于用例那樣，場景關注的也是問題領域和系統的外部行為。因此，可以看出，這些從問題領域導出體系結構抽象的方法，如DSSA方法，在導出正確的體系結構抽象的問題上，效果更差。115精選ppt第四章軟件體系結構描述4.8軟件體系結構的設計

域驅動（domain-driven）的方法缺點：（2）解決方案領域分析不夠充分。有些解決方案領域分析方法是獨立于軟件體系結構設計的，它們為確認潛在的可重用資源提供了系統的過程。正如前面描述的，在系統重用研究領域中，這一活動被稱作領域工程。和系統工程、問題領域工程不同，解決方案領域分析所關心的內容超出單個系統的范圍，它關心的是一個系統族或問題領域，以確認該解決方案領域的可重用資源。盡管解決方案領域分析提供了對整個領域建模的潛力，而且這種潛力對于導出領域體系結構是必需的，但是，這并不足以驅動體系結構設計過程。116精選ppt第四章軟件體系結構描述4.8