軟件體系結構: 將系統的總體結構（包括構件及其連接關系）與各個構件的內部細節相分離。

建模就是在編碼之前對軟件應用的設計。在系統實現之前，對模型進行構造和分析，并用于指導后繼的實現過程

封裝：把客觀事物封裝成抽象的類，并且類可以把自己的數據和方法只讓可信或必要的類或者對象操作，對不可信的或不必要的類或對象進行信息隱藏。

繼承：讓某個類型的對象獲得另一個類型的對象的屬性和方法。它可以使用現有類的所有功能，并在無需重新編寫原來的類的情況下對這些功能進行擴展。

多態：類實例的相同方法在不同情形有不同表現形式。多態機制使具有不同內部結構的對象可以共享相同的外部接口。

統一建模語言（UML）：為面向對象模型的描述提供了一種標準化的圖形語言和表示法。

軟件體系結構可以在不同的細節層次上進行描述。

在較高的細節層次上，體系結構可以描述軟件系統是如何分解為子系統的。

在較低的細節層次上，體系結構可以描述子系統是如何分解為模塊或構件的。

這些不同層次上的體系結構強調的都是子系統/構件的外部視圖，即子系統/構件所提供和需要的接口以及與其他子系統/構件的連接關系。

也稱為高層設計，滿足功能性的同時重點考慮系統的質量屬性（性能、安全性、可維護性等）。

CIM: Computation Independent Model（系統的與計算無關的視圖）詳細描述需求,但是隱藏實現細節和系統實現

PIM: Platform Independent Model（平臺無關模型）

PIM是一種在采用特定平臺的決策做出之前描述軟件體系結構的精確模型。

PSM: Platform Specific Model（平臺相關模型）

PSM是映射到特定平臺上的一種精確的軟件體系結構模型。

用例圖，一個參與者( actor）發起一個用例(use case )。用例定義了參與者與系統之間的一組交互序列。

在用例圖中，參與者用一個人形圖標表示，系統則用一個方框來表示，一個用例表示為方框中的一個橢圓。通信關聯( communication association)將參與者與他們參與的用例進行連接。用例之間的關系通過包含( include）關系和擴展( extend)關系進行定義。

類和對象，類( class)和對象( object)在UML表示法中被描繪成方框。表示類的方框總是包含類名，并且可選擇性地列出類的屬性( attribute）和操作( operation )。當同時描述以上三者時，方框的頂部區域放置類名，中部區域放置屬性，底部區域放置操作。

為了區分類（類型）和對象（該類型的一個實例)，對象名稱需要帶有下劃線。

類圖，在類圖中，類用方框描繪，類之間的靜態（永久）關系被描繪成連接方框之間的連線。

UML表示法支持以下三種類之間的主要關系類型:關聯( association)、整體/部分關系( whole/part relationship)和泛化/特化

第四種關系，即依賴關系( dependency relationship )，經常被用來表示包之間是如何進行關聯的。

關聯( association)：兩個或多個類之間的一個靜態的、結構化的關系。它用兩個類框之間的連線表示，一個關聯具有一個名字，并且可選擇性地具有一個黑色小箭頭來表示關聯名稱的閱讀方向，每個連接類的關聯線的末端標明關聯的多重性。此外，可以用棍狀箭頭描繪導航的方向。

聚合和組合層次是整體/部分的關系。組合關系( 用黑色菱形表示)是一個比聚合關系(用空心菱形表示)更強的整體/部分關系的形式。

泛化/特化層次是一種繼承關系。泛化被描繪為一個連接子類( subclass）到父類( superclass)的具有箭頭的連線，箭頭與表示父類的方框連接。

可見性指類中的一個元素是否在類外可見。

公有可見性( public visibility)使用 + 號，表示一個元素在類的外部是可見的。

私有可見性( private visibility)使用 - 號，表示一個元素只在定義它的類的內部是可見的，對于其他類是隱藏的。

受保護可見性( protected visibility)使用 # 號，表示一個元素在定義它的類及其所有子類中是可見的。

交互圖，通信圖和順序圖是UML的兩種主要類型的交互圖，它們用來描繪對象間是如何進行交互的。對象用長方形方框表示，對象的名字不需要使用下劃線標繪。

通信圖描繪了交互對象的組織結構。其中,對象用方框表示，連接方框的線代表了對象間的交互。與這些線相鄰的帶有標簽的箭頭表示了對象間消息傳遞的名字和方向。同時，對象間傳遞消息的順序被進行了編號。其中，星號(*）表示一個可選的迭代,即一條消息被發送了多于一次。一個可選的條件( condition)，[conditon]表示一條消息在滿足特定條件的情況下才會被發送。

順序圖是另一種說明對象間交互方式的圖，順序圖將對象交互通過時間序列的方式進行描繪。順序圖具有兩個維度，其中參與交互的對象被描繪在水平方向，而垂直方向代表時間維度。從每一個對象框出發都有一條被稱為生命線( lifeline ）的垂直虛線。

狀態轉換圖被稱為狀態機圖。本書使用狀態圖這一更為通用的術語。在UML表示法中，圓角框表示狀態，連接圓角框的弧線表示轉換。狀態圖的初始狀態（ initial state )用一個始于小黑圓圈的弧線表示。終結狀態（ finalstate)是可選的，它被描繪為嵌套在大白圈中的小黑圓圈，有時也被稱為靶心( bull’s-eye )。

弧線上，使用事件[條件]/動作(Event[Condition]/Action )進行標記。事件（ event )引起了狀態的轉換，當事件發生時，為了發生轉換，可選的布爾條件( condition)必須為真?？蛇x的動作( action)作為轉換的結果被執行。一個狀態可具有以下任意的動作:

●進入動作( entry action )，它在進人狀態的時候執行；

●退出動作（ exit action )，它在退出狀態的時候執行。

包是一組建模元素的組合，例如代表一個系統或一個子系統。用一個文件夾圖標表示包，即在一個大長方形的角上依附一個小長方形。包也可能被嵌套在其他包里面。依賴和泛化/特化是包之間可能具有的關系。包可用于容納類、對象或者用例。

主動對象可用于描繪一個并發對象( concurrent object)、進程( process )、線程（( thread)或任務( task )。可以用一個左右兩邊帶有兩根垂直線的方框表示一個主動對象。

主動對象擁有自己的控制線程，并且能與其他對象并發執行。

與此相反，被動對象不具有控制線程。被動對象只在其他對象（主動或被動)調用其方法時才會執行。

部署圖以物理結點和結點間物理連接的方式（例如網絡連接）展示了一個系統的物理配置。一個結點使用一個立方體表示，連接則用這些立方體之間的連接線表示。本質上，部署圖是以系統結點為關注點的一種類圖。

UML擴展機制
構造型: <>
標記值 : {標記=值}

約束 : {expression}

拋棄型原型有助于解決瀑布模型的第一個問題，演化式原型則有助于解決第二個問題。

一個拋棄型原型能夠在一個初步的需求規約被制定之后就被開發出來。

演化式原型方法是增量開發的一種形式，在增量開發中，原型從幾個中間步驟的可運行系統逐步演化為可交付系統。

螺旋模型是一個風險驅動的過程模型，最初由Boehm ( 1988）開發用來解決軟件生存周期早期過程模型中存在的已知問題，涵蓋其他生存周期模型，例如瀑布模型、增量開發模型以及拋棄型原型模型。

軟件確認的目標是要確保軟件開發團隊“構建了正確的系統”，也就是說，確保系統符合用戶的需求。

軟件驗證的目標是要確保軟件開發團隊“正確地構建系統”，也就是說，確保軟件系統在每一個階段中的構造與前一個階段所定義的規約相符合。

軟件質量保證是指一系列確保軟件產品質量的活動。軟件驗證和確認是軟件質量保證的重要目標。

軟件生存周期的活動

需求分析和規約

體系結構設計

詳細設計

編碼

軟件測試

單元測試

集成測試

系統測試

驗收測試

對象：

①現實世界中物理的或概念的實體,它提供了對現實世界的理解。

②面向對象的應用由對象組成。

③對象包含數據及作用于數據之上的過程（操作、方法）

④對象有唯一的標識。

⑤一個對象是一個類的實例。

類：具有相同特征的對象的集合

屬性：

操作：

接口：

操作的規約(即操作的名字和參數)

繼承

1.一種抽象機制
2.對那些在某些方面相似但不完全相同的對象建模
?共同特征 ?唯一特性
3.在不同類中分享和復用代碼的機制
?超類/基類/父類
?派生類/子類
4.將父類進行修改從而形成子類的過程稱為特化
5.子類還可以被進一步特化，形成泛化/特化層次結構
6.類繼承實現了一種擴展機制

主動對象（第二次）

1.又稱為：并發對象/并發過程/并發任務/線程
2.擁有自己的控制線程并能獨立于其他對象而執行
3.每個主動對象處理一個順序執行的線程
4.主動對象中不允許并發操作，整個系統的并發是通過多個主動對象的并行執行來實現
5.主動對象可以異步執行，通常獨立但也可相互通信同步

被動對象
1.沒有控制線程
2.被主動對象調用其操作
3.可以調用其它被動對象的操作
4.其操作一旦被主動對象調用，就會在主動對象所控制的線程中執行

順序應用是一個順序的程序，它由一組被動對象組成并且僅有一個控制線程。

并發應用中，通常有幾個并發對象，每一個對象都擁有屬于它自己的控制線程（多個）。

軟件體系結構：核心：定義構件及其連接的方式，將系統的整體結構與單個構件的內部實現細節進行分離。

構件接口既要描述它所提供的操作，又要描述它所需要的操作

對象接口一般僅需描述對象所提供的操作

軟件質量屬性，（20章詳解）：

維護、修改、測試、追蹤、擴展、復用、性能、可用、安全。

增量軟件構建包含了該子集中類的詳細設計、編碼和單元測試。

在增量軟件集成期間，要執行每個軟件增量的集成測試。

需求建模

1.用例建模（陳述功能需求）
?系統的功能需求采用用例和參與者來描述
?用例定義了一個或多個參與者與系統之間的交互序列
?用例描述是一個行為視圖；用例間的關系給出了一個結構視圖
2.陳述非功能性需求

分析建模

1.靜態建模

? 上下文類圖

? 類圖E-R圖

2.對象的組織

• 決定參加每個用例的對象。（哪些對象參加用例）
• 給出對象的組織準則，以幫助確定系統中的軟件對象:哪些是實體對象、邊界對象、控制對象以及應用邏輯對象。

3.動態交互建模

• 實現用例來顯示參與每個用例的對象之間的交互。
• 開發通信圖或序列圖來顯示對象如何相互通信來執行用例。

4.動態狀態機建模

• 對狀態相關的對象進行建模——狀態圖。

設計建模（主要考慮問題的解決方案）

將分析模型映射為并發設計模型

需求建模包括需求分析和需求規約。

需求分析：分析需求和分析現存系統

軟件需求描述了系統必須為用戶提供的功能。

需求規約：需求分析師和用戶達成共識的文檔。

功能性需求描述了為了達到系統的目的系統必須能夠提供的功能。

非功能性需求有時也被稱作質量屬性，是指系統必須滿足的服務質量目標。

用例定義了一個或多個參與者和系統之間的交互序列。

用例建模是一種描述系統的功能性需求的方法。

參與者描繪了一個與系統交互的外部用戶(即在系統之外)。在用例模型中，參與者是與系統交互的唯一外部實體；換句話說，參與者是在系統之外的，不是系統的一部分。

參與者一般由人類用戶扮演

有些系統中，有可能有其他類型的參與者作為人類參與者的補充或替代，如，與本系統通過接口連接的外部系統、設備或計時器。

主要參與者-啟動用例。因此，用例始于來自主要參與者的輸人，系統必須響應主要參與者。

其他參與者稱為次要參與者，可以參與到用例中。一個用例中的主要參與者可以是另一個用例中的次要參與者。

至少有一個參與者必須從用例中獲得價值;通常，這就是主要參與者。

人類參與者通常使用多種（標準/非標準）IO設備與系統進行物理交互。所有這些情況中，人是參與者，IO設備不是參與者。因此，參與者是終端用戶。

用例的主序列描述了參與者和系統之間最常見的交互序列。

用例中的每個序列稱作場景。一個用例通常描述了多個場景:一個主序列（主場景）和多個可替換序列（替代場景）。

包含關系
1.用來標識多個用例中共同的交互序列
2.反映了多個用例之間共同的功能
3.抽取出的共同交互序列形成一個新用例，稱為包含用例，原來的用例稱為基用例
4.包含用例通常是抽象的，不能獨立執行
5.基用例包含并執行包含用例

擴展關系
1.有些用例的交互序列中有太多可替換的、備選或異常的分支
2.可以將這些分支序列分離成單獨的用例
3.這些新用例擴展了原來的用例，稱為擴展用例，原來的用例稱為基用例
4.可以根據條件，確定基用例以不同方式進行擴展
5.基用例不依賴于擴展用例
6.擴展用例依賴于基用例并在基用例中引起它執行的條件為真時才執行。

擴展點

1.用來規定基用例中能被增加擴展的位置
?2.擴展用例在擴展點上擴展基用例
?3.可以在擴展點上定義多個擴展用例，根據條件調用其中一個用例
?4.擴展條件是在基用例運行時設定和更改的

擴展關系通過擴展點名稱和選擇條件來標識。

活動圖是一種描述控制流和活動中序列的UML圖。

活動圖可用來表示用例的順序步驟,包括主序列和所有的可替換序列

靜態模型展示的是問題的靜態結構視圖，它不隨時間的變化而變化。

靜態模型涉及：
1.類

? 2.類的屬性

? 3.類之間的關系以及約束（操作）
? 4.識別軟件外部類及上下文類圖
? 5.對象和類的組織

關聯定義了兩個或多個類之間的關系，指明了類之間的一種靜態的、結構化的關系

關聯的多重性規定了一個類的多少個實例能與另一個類的單個實例建立關聯

組合也是實例之間的關系。因此，部分對象的創建、存在和消亡都是和整體一起的。部分對象只能屬于一個整體。

組合類經常涉及整體和部分之間的物理關系。（硬件，ATM機）

聚合一般用于對概念類（非物理類）建模。（學院的組成）

在組合和聚合里**,屬性都從整體向部分傳播**。

約束規定了必須為真的條件或限制

上下文建模顯式地標識了什么是在系統內的，什么是在系統外的。

上下文建模可以在整個系統（硬件和軟件）的級別上完成，或者在軟件系統（僅軟件）的級別上完成。

系統（硬件和軟件）上下文類圖

1.在考慮軟件系統上下文類圖之前建模
2.只有人類參與者和外部系統在系統邊界之外
3**.I/O設備是系統硬件的一部分，屬于系統內部**類

軟件系統（軟件）上下文類圖

1.I/O設備屬于系統外部類

外部類分類

通過標準輸入/輸出設備（鍵盤、顯示器和鼠標）和軟件系統交互的外部用戶描述為外部用戶<>

將非標準輸入/輸出設備建模為外部設備類

軟件系統上下文類圖中標準的關聯名稱是:輸入到，輸出到，和…通信，和…交互，向…發信號

參與者是一個比外部類更抽象的概念
1.非標輸入/輸出設備參與者->外部輸入/輸出設備類
2.外部系統參與者->外部系統類
3.計時器參與者->外部計時器類
4.人類參與者
a.通過標準輸入/輸出設備與系統交互，建模為人類參與者的名稱的類（人類建立成人類參與者，標準建立成外部用戶類）
b.通過非標準輸入/輸出設備與系統交互，建模為人類參與者通過外部輸入/輸出設備類與系統交互

? (人類建立成人類參與者，設備建立成外部輸入/輸出設備類)

實體類是概念性的數據密集型類——它們的主要目的是存儲數據并提供對這些數據的訪問。

問題域靜態建模階段，重點仍是定義實體類、它們的屬性和它們間的關系，操作的定義推遲到在設計建模。

核心：確定軟件系統內部的軟件對象

注意，更重要的是要確定系統中的所有對象，而不是過分關心如何分類少量模棱兩可的情況。

外部計時器類向軟件計時器類發信號。（與控制類的計時器不同）

協調者對象，是做出總體決策的對象，它確定相關對象的協作順序，從而為用例的執行提供總體順序安排

由協調者對象發起的動作只取決于包含在傳入消息中的信息，而不依賴于系統中之前發生的事情（只與輸入有關，與狀態無關）

狀態相關的控制對象,用有限狀態機對它進行定義，用狀態圖來描述,不僅依賴該對象的輸入，還依賴對象的當前狀態

計時器對象,要么自己執行某個動作，要么激活另一個對象來執行期望的動作,計時器對象是一個由外部計時器（如實時時鐘或操作系統時鐘）激活的控制對象

業務邏輯對象,定義了用于處理一個客戶端請求的特定業務的應用邏輯,將可能相互獨立變化的業務規則封裝到分離的業務邏輯對象中.

設計決策：
? 如果業務規則只有通過訪問兩個或更多的實體對象才能執行，就應該有一個分離的業務邏輯對象
? 如果訪問一個實體對象就足以執行業務規則，則可將它作為該對象的一個操作

算法對象,封裝了問題域中使用的算法,必須頻繁與其他對象交互，以便執行算法

服務對象,對其他對象提供服務，常用于面向服務的架構中?？赡?strong>封裝了它需要用來服務客戶端請求的數據，或訪問其他封裝了該數據的實體對象

動態交互建模，描述了被建模系統的控制行為以及系統構件交互的順序安排

通信圖是一種UML交互圖，描述了一組對象是如何通過對象間消息傳遞來實現交互

順序圖(序列圖)，序列圖按時間的順序展現了對象間的交互

對系統進行動態描述時，通信圖和序列圖二選其一

動態交互建模用來幫助分析對象之間是如何交互來實現用例的

動態交互建模分為：
?無狀態動態交互建模
?有狀態動態交互建模

狀態相關的動態交互建模包括了一個由狀態圖控制的狀態相關的通信，而無狀態的動態交互建模則沒有這一特點。

實例形式用來詳細地描述一個特定的場景，把一個可能的對象實例間的交互序列描繪出來。

通用形式則是用來描述參與交互的對象之間所有可能的交互關系，因此會包含循環、分支和條件。

有限狀態機的概念
1.是包含有限個狀態的概念化機器
2.對系統或對象的控制、順序視圖進行建模
3.有限狀態機行為既與當前輸入相關，也與其之前發生的事件相關（輸入+當前狀態）
4.輸入事件引起狀態轉變，下一個狀態依賴于當前狀態和輸入事件
5.有時，狀態轉變會導致輸出動作
6.事件具有原子性且在概念上無持續
7.狀態是一種可識別的、存在于一段時間間隔內的情況，狀態轉變時間常被忽略

有限狀態機的表示法有狀態轉換圖、狀態圖和狀態轉換表。

事件是在某一個時間點發生的事情，事件也被稱為離散事件、離散信號或激勵。

有限狀態機可以對一個完整的系統建模，因此狀態圖可以描述系統

通過使用警戒條件，使狀態轉變具有條件性，事件[條件]

狀態轉變的結果是動作的執行

三類動作定義方式
?狀態轉換中的動作
?進入動作
?退出動作

層次化狀態圖，層次化狀態分解
?引入復合狀態，它可以被分解為多個子狀態
?子狀態相互關聯且有先后順序，稱為順序化狀態分解

? ?當復合狀態被分解為多個子狀態時，必須保留進入和離開該復合狀態的狀態轉換

正交狀態圖
1.是另一種層次化分解方式
2.用來從不同的視角對同一對象狀態進行建模
3.高層次的狀態可分解為兩個或多個正交狀態圖
4.當進入復合狀態時，則同時進入正交的多個狀態圖的某個子狀態
5.可以用于表示并發，但不推薦，最好表示同一對象的不同部分（不是并發的）

狀態相關的動態交互建模能夠處理對象間的交互是與狀態相關的情況。

狀態相關的動態交互建模中的步驟

1.確定邊界對象
2.確定狀態相關的控制對象
3.確定其他軟件對象
4.確定主序列場景中的對象交互
5.確定狀態圖的執行
6.考慮備選序列場景

交互圖上的消息包含一個事件以及伴隨事件的數據

通信圖覆蓋了主序列也覆蓋了所有可替換序列。

軟件架構，一個程序或計算機系統的軟件架構是包含了該系統的軟件元素、這些元素的外部可見的屬性以及這些元素之間關系的結構或一組系統結構

軟件體系結構模式

1.軟件高層設計的框架和模板
2.又稱體系結構風格，是不同軟件應用中重復出現的軟件結構設計方案

基于構件的軟件體系結構

1.軟件由構件組成，每個構件相對獨立且封裝了某些信息
2.構件可以是簡單對象或由其他對象組成的復合對象
3.構件通過接口與其他構件通信
·接口描述了通信所需的所有信息
·接口與實現分離
·接口約定了通信模式

順序式設計（構件是類）
? 構件是沒有控制線程的被動類
? 可以把構件單獨編譯并存儲在構件庫中
? 采用唯一的通信模式：調用/返回

并發或分布式設計
? 構件是主動的（并發的），含有控制線程。
? 可以被部屬到一個分布式環境中的不同結點上
? 并發構件可以通過幾種不同的通信模式通信（通過底層中間件框架實現通信）
? 同步模式
? 異步模式
? 代理模式
? 群組通信模式

結構視圖

1.是一種靜態視圖，不會隨時間發生改變。
2.子系統使用類圖來描述

動態視圖

1.是一種行為視圖，子系統間消息通信
2.使用子系統通信圖來描述

3.是一種泛化的通信圖，描述了子系統間所有可能的交互場景 ，所以沒有消息順序編號

部署視圖

1.描述了軟件架構的物理配置
2.表示子系統如何在一個分布式配置中分配到不同的結點上
3.可以指明子系統的多個實例都可以部署到一個單獨的接點上，但不指定實例的確切數量

軟件體系結構模式

1.集中式控制模式

①僅包含單個控制構件
②控制構件執行一個狀態圖以總控全局并管理整個系統的行為順序
③控制構件從與其交互的構件那里接收事件，并引發一個或多個狀態相關動作
④控制構件通過動作控制系統中的其他構件

2.分布式控制模式

①包含多個控制構件
②每個控制構件執行一個狀態圖以控制系統的特定部分
③控制分布于各個控制構件中
④控制構件通過點對點的通信實現重要事件的通知

3.層次化控制模式

①包含多個控制構件
②每個控制構件執行一個狀態圖以控制系統的特定部分
③存在一個協調者構件，它協調所有控制構件來完成整個系統的控制
④協調者構件提供高層控制：
①直接與各個控制構件通信并決定各個控制構件的動作
②從控制構件接收狀態信息

4.抽象分層模式

①分層可以提高軟件的伸縮性
·在提供服務的較低層次的基礎上添加上層來擴展軟件

? ·移除上層即可收縮軟件
②分層原則
?從軟件構件的功能和角色角度分層
?從部署方法考慮

5.多客戶端/多服務模式

①多對多通信
②服務之間也可能相互通信
③既可以采取順序性通信，也可以采用并發通信

6.多客戶端/單服務模式

①是客戶端/服務器（C/S）架構的最常見模式，因此常直接稱它為C/S模式
②一般采用順序性通信方式

7.多層客戶端/服務架構模式
①擁有同時扮演著客戶端和服務角色的中間層
②中間層可能有多個
③具有服務功能的層可部署在同一個服務器結點上

軟件體系結構通信模式

1.異步消息通信模式（松耦合）

①生產者構件發送一條消息給消費者構件
②返回消息有兩種情況
a.不等待其回復，生產者繼續執行
b.有回復，但收到回復之前還要執行一些其它功能
③消息到達消費者后：
a.消費者直接接收消息
b.若消費者正在處理其他事情，消息會進入等待隊列
④通過先進先出的消息隊列進行異步通信
在分布式環境中，異步消息通信模式可以大大提供系統的靈活性

2.帶回調的異步消息通信模式

①客戶端向服務發送了一條請求后可以繼續工作而不必等待應答
②服務需要在稍后向客戶端發送答復信息（異步應答）
③一個客戶端在同一時間只會向服務發送一條請求消息并收到服務的應答

3.雙向異步消息通信模式

兩個構件之間也可以使用點對點的異步消息通信。

4.廣播消息通信模式
一個主動消息被發送給所有的接收者

5.代理者轉發模式

? 1.提供了客戶端和服務間消息轉發的中介
? 2.每條消息都可以被代理者審查，安全性高
? 3.消息通信量加倍，效率低
? 4.流程：
? ①客戶端向代理者發送一個服務請求
? ②代理者查詢服務的位置并將請求轉發給合適的服務
? ③服務執行請求并將回復發送給代理者
? ④代理者將回復轉發給客戶

6.代理者句柄模式

? 1.減小了消息通信量
? 2.當客戶端和服務間可能存在會話并需要交換多條消息時特別適用
? 3.流程：
? ①客戶端向代理者發送一個服務請求
? ②代理者查詢服務的位置并向客戶端返回一個服務句柄
? ③客戶端使用服務句柄來請求合適的服務
? ④服務執行請求并直接發送回復給客戶端

7.調用/返回模式

? 1.是對象間最簡單的通信形式
? 2.是順序設計的唯一通信形式
? 被動對象類上的操作/方法調用

? 操作被調用時，控制從調用操作傳遞到被調用操作
? 被調用操作執行完后將控制返回調用操作
? 伴隨參數的傳遞

8.協商模式

? 1.軟件主體（agent）之間協商，共同做出決策
? 2.分為客戶主體和服務主體

9.服務發現模式

? 1.之前的模式中，客戶端知道請求的服務而不是位置，稱為白頁代理
? 2.本模式中，客戶端知道請求的服務類型而不是特定的服務——黃頁代理
? 3.先使用黃頁代理，返回給客戶端一個滿足請求要求的所有服務的列表，客戶端從中作出選擇，再使用白頁代理執行服務調用

10.服務注冊模式

? 1.服務向代理者注冊服務信息
? 2.服務名稱、服務描述和提供服務的位置
? 3.服務在第一次加入“代理交易所”時需要注冊
? 4.服務每次位置變化，需重新注冊
? 5.流程：
? ①服務向代理者發送“注冊服務”請求
? ②代理者在服務庫中注冊服務，并向服務發送“注冊確認”

11.訂閱/通知消息通信模式
①使用組播通信方式
②訂閱了某個主題的構件會接收該主題發送給訂閱者的所有消息
③一個構件可以訂閱和取消訂閱一個主題
④發送者不需要知道訂閱者

12.帶回復的同步消息通信模式

? 1.客戶端構件向服務構件發送一條消息并等待服務構件的回復
? 2.消息到達服務構件后：
? a.服務構件接收消息并處理
? b.生成一個回復并將回復發送回客戶端
? 3.當服務構件未收到任何消息,服務構件掛起 (?)
? 4.一般包含多個客戶端和一個服務

13.不帶回復的同步消息通信（緊耦合），

消息生產者給消費者發送完一個消息后會等待消息被消費者接收，一旦消費者接收消息則釋放生產者

軟件體系結構事務模式

1.事務是客戶端對由兩個或更多操作組成的服務的請求，這些操作屬于同一個邏輯功能并必須全部完成或全部不做
2.事務在客戶端生成并發送給服務處理
3.事務的ACID特性
A：原子性，事務不可分割
C：一致性，事務執行完，系統處于一致狀態
I：隔離性，兩個事務間不相互影響
D：持續性，事務結果的持久性

從三個方面編寫軟件架構模式說明文檔
1.上下文,指產生問題的環境
2.問題,指上下文中可能重復出現的問題
3.解決方案,指一種解決問題的可行方法

信息隱藏，設計者需要確定哪些信息應該隱藏在類中，哪些信息應該放在類的接口中

數據抽象類：封裝數據結構

包裝器類：隱藏了訪問存儲在現有系統或遺留系統中的數據的訪問接口，包裝器可以封裝對數據庫的訪問

可復用的狀態機類提供了兩個通用的可復用的操作

processEvent(in event, out action) //當有新事件需要處理時被調用，它查找狀態轉換表來確定此事件的影響，考慮狀態機的當前狀態和必須滿足的條件，新狀態是什么及需執行的動作；接著改變當前狀態，返回需要執行的動作作為輸出參數
currentState(): State //返回狀態機當前狀態

順序性服務的設計
①服務必須先完成上一個服務請求，才能開始處理下一個請求
②順序性服務設計為一個并發對象（控制線程）來響應客戶端的服務請求
③服務通常會有一個消息隊列來存放收到的服務請求

? ④服務協調者收到客戶端消息后，按照消息類型調用相應服務對象所提供的操作
? ⑤消息的參數作為操作的參數
? ⑥服務對象的處理結果經由服務協調者發回客戶端

并發服務設計
①服務功能由多個并發的對象共同完成
②適用于客戶端對于服務的要求很高，使用多個并發對象提供的服務可以提高系統的吞吐量

C/S模式中，數據抽象類更常位于客戶端，數據庫包裝器類一般位于服務器端

關系數據庫表必須有一個主鍵，一般能夠唯一確定表中某一行的屬性選做主鍵，可以是復合主鍵

外鍵是包含在一張表中的另一張表的主鍵，可以幫助從一張表導航到另一張表

面向服務架構(Service oriented Architecture, SOA)是一個由多個自治的服務組成的分布式軟件體系結構

各個服務可以用不同的語言實現，運行在不同的平臺上

服務間的通信和信息交換采用標準協議

對每個服務都有服務描述

服務消費者通過服務代理發現和調用服務（松耦合）

事務是客戶端對由兩個或更多操作組成的服務的請求，這些操作屬于同一個邏輯功能并必須全部完成或全部不做

編制（編舞）(orchestration)：協調多個服務的采用集中式控制的工作流協調邏輯組成。

編排（編曲）(choreography)：分布式協調，用于不同業務組織間的協調

服務一般只有供給接口，而沒有請求接口（除了使用帶回調的異步通信），這樣使服務更獨立，便于復用

供給接口定義了構件必須實現的操作，代表其他構件使用本構件時的要求

請求接口定義了在特定環境下其他構件需為本構件提供的操作，代表了本構件使用其他構件時的要求

一個構件通過一個或多個端口與其他構件交互

端口用供給和請求接口來定義
①一個供給端口支持一個供給接口
②一個請求端口支持一個請求接口
③一個復雜端口同時支持一個供給接口和一個請求接口

構件的供給端口的名稱以字母“P”開頭

構件的請求端口的名稱以字母“R”開頭

連接器將一個構件的請求端口和另一個構件的供給端口連接起來

被連接的兩個端口必須相互兼容

復合構件的端口可以連接到內部構件的端口上，稱為委托連接器，此時兩個端口名相同

實時軟件架構是指必須同時處理多個輸入事件流的并發式架構

通常與狀態相關，具有集中或非集中的控制方式

設計并發對象（并發任務）是設計實時軟件架構的重要工作

設計并發軟件時，將系統分解成一系列并發任務（對象），并定義了任務間的接口及交互

客戶端和服務各自都可以設計成并發軟件架構

實時系統通常被分為硬實時系統和軟實時系統兩類。硬實時系統具有必須滿足的關鍵性時限以防止災難性的系統失效。在軟實時系統中也具有不希望被違反的時限要求，但是的超出時限并不會造成災難性的后果，因而是可以容忍的。

在分析模型中確定對象應該并發執行或者順序執行，從而被設計為主動或被動對象

兩類重要的并發任務，I/O任務 & 內部任務

.I/O任務包括：
①事件驅動
②周期性
③按需驅動

事件驅動I/O任務接收輸入事件（中斷），將它傳給其他對象處理，隨即轉而對之后到來的中斷做出迅速響應，構造型：<>

周期性I/O任務，外部計時器周期性地發送計時器事件，從而觸發周期性I/O任務，構造型：<>，用于需要周期性采樣的被動傳感器（輸入）設備

按需驅動I/O任務，處理不需周期性輪詢的被動I/O設備，按需驅動I/O任務更常用于處理輸出設備，構造型：<>

周期性任務（內部），用來處理周期性執行的活動的任務。構造型：<>，該任務被計時器事件觸發并執行周期性活動，隨后等待下一個計時器事件。

按需驅動任務，它被到達的外部消息或事件所觸發，觸發后任務開始處理所需請求，隨后等待下一個消息或事件，<>、<>。

控制任務，是分析模型中的狀態相關的控制對象在設計模型中的實現，分析模型中的協調者對象也被設計成協調者任務，它也是一種控制任務，構造型：<>。

用戶交互任務，一個用戶交互任務通常與多個標準I/O設備相連，由于操作系統為這些設備提供了標準接口，所以無需開發專用的I/O任務去處理它們，構造型<>,

<>

然后按以下順序應用以上任務組織準則
①I/O任務，從外部的設備I/O對象來分析
②控制任務，分析每個狀態相關控制對象和協調者對象
③周期性任務，分析內部周期性活動
④其他內部任務，由內部事件觸發內部任務，構造為按需驅動任務

事件同步機制，包括：外部事件同步，計時器事件同步，內部事件同步。

任務接口規約（TIS）是類接口規約的擴展

任務行為規約（TBS）描述任務事件的順序邏輯，即任務如何對接收到的消息或輸入事件做出響應

微服務是一種分布式系統解決方案，通過使用細粒度服務，使其協同工作，每個服務有其生命周期

微服務的定義：協同工作的小而自治的服務

微服務的益處

1 技術異構性，可以在不同服務中使用最適合的技術

2 彈性，一個服務失效不會導致級聯故障

3 擴展性，若系統中只有一小部分存在性能問題，只要對需要擴展的服務進行擴展即可

4 簡化部署，各服務獨立部署

5 與組織結構匹配，小型代碼庫使得團隊工作更高效

6 可組合性，根據不同目的，以不同方式重用服務

7 對可替換性的優化，采用微服務可以輕易重寫服務