286.軟件體系結構研究展望

 

軟件體系結構研究新方向

21世紀軟件技術展望
1.開放源代碼
下一世紀的操做系統將繼承如今好的操做系統的主要優勢，變成開放的和進化的。在操做系統開放以後，系統軟件產業將主要集中在軟件環境平臺和工具的研究開發上。可視化編程環境與工具、辦公套件、家庭套件、學習套件等將會有很大的空間。

21世紀軟件技術展望
2.跨平臺
使得一次寫好的應用軟件在各類不一樣硬件系統上均可以運行、使得已經設計好的程序模塊被有效地重複利用。
目前跨平臺這一設想尚未徹底有效地被實現，相信21世紀第一個10年必定能夠完成。固然，如何解決非Java語言軟件的跨平臺問題仍然是一個難題。

21世紀軟件技術展望
3.軟件工業化
隨着軟構件的規範化和實用化，計算機軟件生產的工業化程度會慢慢提升，軟件發展的速度也會慢慢加快。估計到21世紀的第一個10年結束的時候，軟件的工業化程度應該達到20世紀90年代中期計算機硬件的工業化程度。

21世紀軟件技術展望
四、友好界面
多媒體技術、語音識別與合成技術、手寫體文字的識別、天然語言理解與機器翻譯技術、圖像處理與圖形學技術、用戶圖形界面技術、人工智能技術等等都是解決軟件系統友好性的關鍵技術。

21世紀軟件技術展望
5.基於網絡的應用軟件
利用了WEB瀏覽技術、多媒體技術和網絡信息管理系統等綜合技術而構成的網絡應用軟件（例如電子商務）將是從此軟件業發展的最大舞臺。

綱要
21世紀軟件技術展望
軟件體系結構研究新方向

軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

IEEE 1471標準
1.基本原則
每一個系統具備一個體繫結構，但一個體繫結構不是一個系統；
體系結構與體系結構描述不是同一件事；
體系結構標準、描述、及開發過程能夠不一樣，而且能夠單獨地進行研究；
體系結構描述自己是多看法的；
把一個對象的整體概念從其詳述中分離開是撰寫體系結構標準的一個有效方法。

IEEE 1471標準
2.體系結構定義
體如今各組成部分、它們相互關係及與環境的關係、和指導設計和演變的原理之中的一個系統的基本結構。

IEEE 1471標準
3.組成部分
對關鍵術語的定義，如體系結構描述、結構性視圖與體系結構性視點；
對體系結構與體系結構描述在概念上的分離促進了描述體系結構標準（與藍圖標準相相似）和構築系統標準（與建築規範或城市規劃法規相相似）的創建；
用於描述一個系統體系結構的內容要求。
IEEE 1471標準
4.體系結構描述要求
一個體繫結構描述必須規定系統的用戶，肯定他們體系結構的要點；
一個體繫結構描述必須被編入一個或多個系統的體系結構視圖中 ；
一個體繫結構描述必須爲制定關鍵的結構性決策提供基本原則 。
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

基於體系結構的軟件開發方法
ACPP
——以體系結構爲中心的軟件項目計劃
ABDP
——基於軟件體系結構的開發過程
ABC
——基於體系結構、面向構件的軟件開發方法

體系結構的軟件開發方法
體系結構的軟件開發方法
體系結構的軟件開發方法
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

基於體系結構的軟件組裝
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

基於體系結構的軟件測試方法
體系結構形式化驗證
多組態軟件體系結構測試

基於體系結構的軟件測試方法

基於有窮狀態進程的形式化驗證
基於時態邏輯的形式化驗證
基於進程演算的形式化驗證
基於Petri網的形式化驗證

基於體系結構的軟件測試方法
基於體系結構的軟件測試方法
參與交互的構件是否能達到系統的目標
系統的完備性和效率
系統擴展的潛能
構件接口的一致性
構件之間鏈接的機制
構件行爲的順序
臨界資源的爭奪

軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

面向服務的體系結構SOA
三位一體的職責構成SOA
SOA應用示例
SOA特性
基於標準的互操做性
在SOA當中，接口、通信協議、工做流、協做和發佈都是由一整套國際標準所定義，包括XML, SOAP, WSDL, UDDI, HTTP,CPP, ebXML, bSOA, BPEL, FERA, OWL-S等，從而保證不一樣平臺的系統可以無阻礙的交流
基於發現的動態組裝
在SOA中的系統所須要的服務均經過運行時發現，運行時加載的方式工做
基於策略的動態管理和總控協做
SOA的各個服務的運行都由策略（Policy）進行控制，策略的制定、監測、執行均可在運行時內完成。SOA實行總控式協做，即由一箇中心控制節點負責控制和調度分佈在網絡各處的服務

SOA分類標準
結構（Structure）
應用程序的結構是靜態(S)仍是動態(D)
動態重組能力（Runtime re-composition capability)
能夠在運行時進行重組(R) 不能夠進行重組(N)
容錯能力（Fault Tolerant Capability）
具備容錯的骨幹通信機制(FB)，具備容錯的控制服務(FC)，不具備容錯能力(FN)
軟件工程支持（System Engineering Support）
是否具備系統支持的模型監測、數據收集、部署、代碼自動生成、策略實施、一致性檢查等機制。有用(SY)表示，無用(SN)表示
由此獲得一個四元組
{Structure, Re-composition, Fault-tolerance, System-engineering}
對各類SOA進行分類

SOA類別及其進化
Customer Centric SOA
常規SOA模式
服務提供者向服務代理註冊開發出來的服務，由應用程序構建者來尋找須要的服務
CCSOA模式
在傳統SOA的基礎上，應用程序構建者也能夠發佈應用程序模板，服務提供者能夠根據模板的須要開發新的服務
Customer Centric SOA（續）
Customer Centric SOA（續）
上圖的步驟爲：
應用程序構建者編寫應用程序模版，模板內包含工做流信息、須要服務規格信息等
應用程序模版在服務代理的庫中進行註冊併發布
一個訂閱了應用程序模版庫的服務提供者收到有新模版到達的通知，因而查詢這個新模版
本體和分類技術能夠輔助進行被提供模版和目標模版之間的自動匹配
在查詢中，服務代理返回給服務提供者關於應用程序模版的詳細信息
服務提供者依據模版開發新的服務，並提交到服務代理。服務代理依據模版中的信息對新服務進行校驗和評估
一旦評估經過，服務代理通知應用程序構建者有可用的新服務
應用程序構建者評估和測試新的服務
一旦經過測試，應用程序構建者就將應用程序模版和新服務綁定，生成能夠運行的應用系統

商業SOA平臺
IBM基於WebShpere的SOA Foundation Architecture
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

柔性軟件體系結構
柔性軟件體系結構定義
柔性軟件體系結構的行爲
柔性軟件體系結構的應用領域
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

自適應軟件體系結構
自適應軟件體系結構是根據操做環境的變化而變化的體系結構
外界的變化包括用戶輸入、硬件設備輸入、傳感器信號、以及程序指令等
自適應軟件體系結構須要解決的問題
在什麼條件下系統發生改變
自適應軟件體系結構應具備開放性質仍是封閉性質
須要實現什麼樣的自適應程度
如何演算從而評估變化後帶來的收益是否大於變化自己的成本
變化的頻繁程度如何
自適應變化須要的原始信息有哪些

自適應軟件體系結構
自適應的基本結構
Monitor監控外界的變化
Adapt負責調整系統模型
Control負責將外界變化演算出模型變化，並做出變化決策
移動環境的自適應柔性軟件體系結構
爲什麼移動環境須要動態自適應
移動環境下設備每每須要連續工做，對自身進行改變必須在運行時下進行
移動設備經受的操做環境的改變與固定的計算設備相比要頻繁的多
使用移動設備的用戶的需求也在不斷改變
自適應體系結構示例：Rainbow
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

移動環境應用實例
User Context
來自用戶及環境的改變
System Context
來自系統自己的改變
Adaptation Middleware
負責將外界的變化映射到體系結構模型庫中的備選模型
Architecture Model
儲備的預先設計好的體系結構模型，是改變的基礎
Adaptable Application
實際被應用的可動態改變的系統
爲什麼使用體系結構的方法
基於編程語言的方法
使用條件表達式
使用參數
使用異常
缺點
將軟件行爲和自行應的過程混雜起來
當引入新的適應機制式時須要修改大量代碼，形成擴展性底下
結論
採用移動中間件來具體負責適應行爲
移動中間件
移動中間件特色
足夠輕量使其能夠運行在資源受限的手持設備上
支持異步通信，使移動設備能夠用較短期週期性訪問網絡，用以節省能源
能夠感知環境的變化、例如自身狀態、位置、能夠得到的服務等
移動中間件所做出的推理必須簡單有效，即推理獲得的改變決策必須使系統有較大的收益

移動中間件
中間件能夠爲解決分佈是系統的基本通信和管理問題，使開發者專一於業務流程
在移動環境下，動態服務和位置發現，從而動態的調總體系結構的形態是移動中間件的核心思想
移動中間件實例MADAM
使用MADAM構建的系統
移動中間件的運行方式——可變屬性
綁定屬性實例
綁定屬性實例（續）
移動柔性軟件體系結構的發展
統一的、通用的體系結構模型和環境模型表示方法
如何更好的描述體系結構模型這個變化的基礎
如何更好的描述環境模型這個變化的觸發點
變化決策推理算法的設計範式
如何設計才能使推理算法能夠在資源受限的設備上流暢運行，並保證其結果的有效性
用戶干涉對推理算法的影響
例如調整某些屬性的計算權重
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

自修復系統
自修修復系統的分類
內部修復：修復代碼和常規代碼集成到普通代碼當中
外部修復：修復代碼單獨做爲一個構件存在於系統當中，與普通的代碼互相隔離

自修復系統設計過程
體系結構設計
將系統分爲兩部分
體系結構管理器（AMR）和體系結構模型容器（AMC）
運行時環境（RE）和實際運行系統（RS）

自修復系統設計過程（續）
修復行爲觸發
運行時環境負責監控運行時系統的各個參數，並將數據發送給體系結構管理器
延遲信息
內存消耗
CPU佔用
負載
系統異常
用戶指令
修復行爲
體系結構管理器負責分析收集的數據，並執行和校驗體系結構的從新配置，並將決策的目標體系結構模型映射成運行時環境能夠接受的操做集
運行時環境對運行系統執行實際的修復操做

體系結構管理器結構
Change Analyzer負責將監控的數據轉換成修復策略
Reconfiguration Manager負責將修復策略變換體系結構圖
Verification Manager負責用體系結構約束和體系結構風格對轉換進行校驗
Reconfiguration Manager將修復策略映射爲運行時環境能夠執行的指令輸出
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

支持代碼移動的體系結構
代碼移動
定義：能夠動態改變代碼和代碼所在位置綁定的能力
優勢
在須要傳輸大量數據的狀況下，傳輸執行代碼可能會更爲快捷
使得代碼具備自我決策的能力，在網絡中自行傳輸

支持代碼移動的基本結構
支持代碼移動的運行環境結構
軟件體系結構研究新方向
IEEE 1471標準
基於軟件體系結構的軟件工程
基於體系結構的軟件開發方法
基於體系結構的軟件組裝
基於體系結構的軟件測試方法
面向服務體系結構（Service-Oriented Architecture）
柔性軟件體系結構
自適應的柔性軟件體系結構
移動環境下的軟件體系結構
自修復系統
支持代碼移動的體系結構
動態軟件體系結構的描述

動態軟件體系結構的描述
SA一般是對系統的靜態描述,若是須要改變體系結構則必須從新設計新的SA,這已不能適應如今愈來愈多的須要在運行時刻發生變化的系統的設計需求.則容許系統在執行過程當中修改其體系結構,修改過程一般也被稱爲運行時刻的演化(即在線演化)或動態性。主要的變化體如今如下幾個方面：
動態軟件體系結構的描述
結構:軟件系統爲適應當前的計算環境每每須要調整自身的結構,好比增長或刪除構件、鏈接子,這將致使SA的拓撲結構發生顯式的變化
行爲:因爲用戶需求的變化或者系統自身QoS調節的須要,軟件系統在運行過程當中會改變其行爲,好比因爲安全級別的提升更換加密算法;將http協議改成https協議,行爲的變化每每是由構件或鏈接子的替換和重配置引發的
屬性:已有的ADL大都支持對非功能屬性(non functional properties)的規約和分析,好比對服務響應時間和吞吐量的要求等,在系統運行的過程當中這些要求可能發生改變,而這些變化又會進一步觸發軟件系統結構或行爲的調整.屬性的變化是驅動系統演化的主要緣由
風格:系統由一種體系結構風格演化成「衍生」的另一種風格。例如兩層C/S結構衍生成多層C/S結構，或者衍生成B/S結構
動態體系結構描述的約束
一致性

體系結構規約與系統實現的一致性,運行時刻的修改應及時地反映到規約中,以保證規約不會過期
系統內部狀態的一致性,正在修改的部分不該被其餘用戶或模塊更改
系統行爲的一致性,若「管道-過濾器」風格的結構中增長一個過濾器,則須要保證該過濾器的輸入和輸出與相連的管道的要求一致
體系結構風格的一致性,演化先後體系結構或者保持風格不變,或者演化爲當前風格的「衍生」風格
完整性

系統的演化不能破壞SA規約中的約束
演化先後系統的狀態不會丟失,不然系統將變得不「安全」,甚至不能正確運行.

 

動態體系結構描述的約束（續）
追溯性
傳統的ADL採用逐步精化的方式將一個抽象層次很高的ADL規約逐步精化爲具體的可直接實現的ADL規約，在精化的過程當中經過形式化的驗證保證每一步精化都符合要求,知足可追溯性。
對於動態系統而言，追溯性除了須要知足靜態設和淨化階段被知足，還須要被延伸到運行時刻，以保證系統的任何一次修改都會被驗證，這樣既有利於軟件的維護，也爲軟件的進一步演化提供了可分析的依據。

動態體系結構描述語言D-ADL
將構件行爲進行分類
計算行爲：計算行爲和動態行爲.計算行爲面向系統的商業邏輯,處理業務功能中的數據信息
動態行爲：面向系統的預約義演化邏輯,使系統可以自適應演化,以體系結構元素爲處理對象,如增刪構件、創建新的鏈接等.
基於高階π演算
全部描述行爲均可在高階π演算中找到對應表示
具備強有力的形式化基礎，能夠對軟件體系結構行爲做深刻的推理和規約
對高階π演算進行擴充
對於某些不能使用高階π演算方便表示的概念（間接能夠表示）進行了擴充
提供了構件動態行爲new、attach和detach的語法概念
動態體系結構描述語言D-ADL（續）
動態體系結構描述語言D-ADL（續）
動態體系結構描述語言D-ADL（續）
假設訂購服務器(merchant)發生錯誤而死機或崩潰時,系統須要自動從新啓動一個服務器實例,並將客戶請求導向新的服務器,使服務不致中斷.這種具備自動切換功能的商品訂購系統的體系結構D-ADL描述以下:

compositecomponent TDynamicOrderSystem() {
port {environment: Tenvironment.}
. . .
choreographer {
via environment∧servermessage receive sign.
if sign = 0 then {
detach merchant∧port1 from cmlink∧portl-m1.detach merchant∧port2 from cmlink∧portl-m2.
delete merchant.
new merchant:Tmerchant().
attach merchant∧port1 to cmlink∧portl-m1.attach merchant∧port2 to cmlink∧portl-m2. }
replicate
}
}

動態體系結構描述語言D-ADL（續）
在接收到客戶訂購請求後,商家根據狀況肯定是否可以知足訂購請求的實際過程是訂購服務器向倉儲服務器查詢是否有足夠供貨. 如下代碼體現了系統「求精」的過程，添加了第三個端口Portm3
atomiccomponent Tmerchant() {
port {portm1:Tcaccess. portm2:Tmaccess.portm3:Tinquire}
computation {
choose {
{via portm1∧order receive orderdata. via portm3∧inquire send orderdata.
via portm3∧answer receive result.
if result then
{ unobservable. via portm1∧response send record(true,payment)}
else
{unobservable. via portm1∧response send record(false,0)}
},
{via portm2∧pay receive payment.unobservable.via portm2∧confirm send confirmation}}
replicate }
}
體系結構動態演化系統的設計
反射
反射(reflect)是指計算系統經過與自身狀態和行爲具備因果互聯的系統自述，以描述、推理和操縱自身的能力
能夠將體系結構包含在系統當中做爲元數據，並對外提供訪問接口，以實現對系統的體系結構進行運行時控制
體系結構在線演化的實施
體系結構在線演化的校驗
使用類型系統檢測一致性
將體系結構風格衍生路線設計爲繼承的類型體系，體系結構演化只能沿着繼承路線向子類型前進
將構件接口類型化，在改變構件鏈接關係時要保證新的鏈接的類型一致
使用事務處理機制確保演化不被惡性中斷
每次演化的一些列操做都在一個事務當中進行
演化發生錯誤時所有操做回滾
在分佈式系統當中，事務可保證在線演化操做的在並行訪問的狀況下的正確性
鏈接器的形式化重用
鏈接器的形式化重用
經過重用舊有的、相對簡單的鏈接器來獲得新的、較爲複雜的鏈接器，就能夠得到一種增量式的鏈接器開發方法，從而提升軟件開發的質量和效率
具備形式化基礎（例如使用CSP）使得新的鏈接器定義能夠進行形式化檢測
鏈接器組合元操做
角色（Role）元操做
Substitute:角色的替代。能夠實現用一個角色來充當另外一個已經定義的角色
ConcurrencyMerge:角色的並行合一。能夠實現用一個角色來同時充當多個已經定義的角色，而且它「扮演」的多個角色之間應並行協調
AlternativeMerge:角色的選擇合一。能夠實現用一個角色來完成多個已經定義的角色的功能，而且在每一次完整的交互中該角色只能充當其中的某一個角色

鏈接器組合元操做（續）
Choice:該操做將兩個或者多個粘結進程選擇地組合起來。這種選擇多是上述的不肯定性選擇，也多是肯定的選擇，即選擇權在其所在環境的選擇。若是它所規範的角色在某次完整的交互中想要參與的初始事件僅被某個子粘結進程所容許，那麼組合粘結進程就選擇該子粘結進程去承擔該次交互的協調任務;不然，若是角色想要參與的初始事件爲多個子粘結進程所容許，那麼它就會任意選擇其中的某個子粘結進程去承擔這次交互的協調任務。
鏈接器組合元操做（續）
Interleave:該操做將兩個或者多個粘結進程交錯地組合起來。若是用這種組合獲得的粘結進程去協調和約束某個角色的行爲，那麼該角色不管什麼時候要想參與某一個事件，只需獲得某個子粘結進程的容許便可。固然，若是此時有多個子粘結進程都容許該事件發生，那麼組合粘結進程就會任意選擇其中的某個子粘結進程去承擔容許該事件發生的責任。

鏈接器組合元操做（續）
粘連（Glue）元操做
Parallel:該操做將兩個或者多個粘結進程並行地組合起來。若是用這種組合獲得的粘結進程去規範某個角色行爲，那麼該角色不管什麼時候要想參與某一個事件，都必須獲得各個子粘結進程的共同容許。
Decision:該操做將兩個或者多個粘結進程不肯定性選擇地組合起來。這裏的不肯定性選擇指的是:組合獲得的粘結進程究竟選擇哪個子粘結進程去規範角色的某一次完整的交互行爲，由其自身來決定。
鏈接器組合元操做（續）
Follow:該操做將兩個或者多個粘結進程順序地組合起來。用這種組合獲得的粘結進程依次用其子粘結進程去協調和約束其所規範的角色的行爲，固然，後續的子粘結進程要想承擔這種責任，必須知足前行的子粘結進程可以成功終止。
Interrupt:該操做將兩個或者多個粘結進程順序中斷地組合起來。用這種組合獲得的粘結進程能夠隨着後續子粘結進程初始事件的發生，用後續的子粘結進程去中斷和接替前行的子粘結進程，並得到協調和約束角色的責任。
Lightning:該操做能夠看做是Interrupt的一種特殊情形，它將兩個粘結進程順序中斷地組合起來。但與Interrupt不一樣的是，前行子粘結進程被中斷並不取決於後續子粘結進程初始事件的發生，而是某個被定義的中斷事件。爲了表示這個特殊事件，咱們把它做爲第3個參數引入到Lightning函數中。

鏈接器組合示例
鏈接器組合法性檢測
檢查1:鏈接器的每一個角色都是無死鎖的
這是對鏈接器角色內部相容性的檢測。因爲組合鏈接器的每一個角色是在重用已有鏈接器的角色基礎上獲得的，所以，這種檢查能夠分爲兩種情形:若組合鏈接器的某個角色是經過替換或者選擇合一獲得的，那麼對子鏈接器相應角色的檢查結果仍然適用於組合鏈接器的這一角色；若組合鏈接器的某個角色是經過並行合一獲得的，那麼就必須從新檢查。由於對於一個並行合一的角色進程，可能會出現這樣的問題:在某個時候，雖然它的子角色都各自能參與某些事件，但它卻不能參與任何一個事件。
檢查2:鏈接器是無死鎖的
這種相容性的檢查是對鏈接器總體的檢查。所以，檢查1若是通不過，也會反映到檢查2中。角色規範了充當其實例的組件預期要發生的行爲，而粘結規範的是對這些行爲的協調與約束。角色規範與粘結規範是否會出現矛盾，就須要用檢查2來考察。

本學期課程到此結束

清華大學軟件工程與管理學院