為什麼我們對並發(Concurrency)感興趣?
軟件可能需要響應看似隨機的外部事件如果有多個CPU可用,並行執行任務可以提高性能
例如:一個系統的啟動
系統的控制可以通過並發來增強
實現並發:並發機制
為了支持並發性,系統必須提供多個控制線程
常見的並發機制
- 多處理(并行)
◆多個CPU同時執行
- 多任務處理(并發)
◆操作系統通過交錯執行不同任務來模擬單個CPU上的並發性
- 基於應用的解決方案(軟件實現)
◆應用軟件負責在適當的時間在不同的代碼分支之間切換
描述運行時體系結構步驟
分析並發性要求
確定進程和線程
確定流程生命週期
將進程映射到實現
在進程中分配模型元素
並發要求
並發需求由以下因素驅動:
- 系統必須分配的程度。
- 系統事件驅動的程度。
- 關鍵算法的計算強度。
- 環境支持的並行執行的程度
並發需求按照解決衝突的重要性排列。
示例:並發需求
在課程註冊系統中,並發需求來自需求和體系結構:
- 多個用戶必須能夠同時執行他們的工作
- 如果學生在製定課程安排(包括該課程)時課程設置已滿,則必須通知學生
- 基於風險的原型發現,如果沒有創造性地使用中間層處理能力,遺留課程目錄數據庫不能滿足我們的性能需求
關鍵概念:進程(process)和線程(thread)
進程:提供重量級的控制流
- 是獨立的
- 可以分成單獨的線程
線程:提供輕量級的控制流
- 在封閉進程中運行
識別進程和線程
對於系統所需的每個單獨的控制流,創建一個進程或線程
- 可能需要單獨的控制線程來:
◆使用多個CPU和/或節點
◆提高CPU利用率
◆服務時間相關的事件
◆優先活動
◆實現可擴展性(負載分擔)
◆分開軟件領域之間的關注
◆提高系統可用性
◆支持主要子系統
進程建模
進程可以被建模為
- 活動類(類圖)和對象(交互圖)
- 組件(組件圖)定型:<< process >>或<< thread >>
過程關係可以建模為依賴關係
描述運行時體系結構步驟
分析並發性要求
確定進程和線程
確定流程生命週期
將進程映射到實現
在進程中分配模型元素
創建和銷毀進程和線程
單進程架構
進程創建在應用程序啟動時發生
當應用程序結束時會發生進程銷毀
多進程架構
新進程通常是從應用程序啟動時創建的初始進程創建的
每個過程都必須單獨銷毀
將進程映射到實現
進程和線程必須映射到特定的實現結構
注意事項
過程耦合
性能要求
系統進程和線程限制
現有的線程和進程
IPC(電路資源)資源可用性
設計元素分配
給定類或子系統的實例必須在至少一個進程中執行
他們可能在多個進程中執行
設計元素到流程的注意事項
基於:
性能和並發性要求
分發要求和對並行執行的支持
冗餘和可用性要求
要考慮的類/子系統特徵:
自治(Autonomy)
從屬關係(Subordination)
持久化(Persistence)
分配(Distribution)
數據持久
持久數據存儲就是即使在服務器崩潰的情況下仍能存在的數據存儲
美國國家標準與技術研究所(美國國家標準與技術研究院)定義了三種級別的持久數據:
部分持久數據是一種僅允許對最新版本更新的持久數據結構
持久數據是一種保留其舊版本的數據結構;即,以前版本和當前版本都可能被查詢
完全持久數據是一種維護其數據的所有版本並允許對這些版本更新的持久數據結構
大多數業務應用程序至少提供部分持久數據。這種類型的持久性在事務中期或者甚至在請求中期出現系統故障時容易遭破壞,這會導致數據不完整且常常遭毀壞
另一方面,在持久數據實現中,對系統中斷或故障以“回滾(回滾)”回應,數據狀態被回滾到上一個已知的良好配置
持久數據實現在企業體系結構和數據庫管理系統(DBMS)中很常見
完全持久數據實現的非常少見。完全持久數據實現的少數幾個示例有:日誌記錄文件系統,VMS文件系統(如VAX和Mac OS X)以及並發版本控制系統(CVS)
設計元素到流程策略
兩種策略(同時使用)
由內而外
密切合作並且必須以相同的控制線程執行的組元素
不相互作用的單獨元素
重複,直到達到仍然存在的最小進程數
提供所需的分配和有效的資源利用
由外而內
為每個外部刺激定義一個單獨的控制線程
為每個服務定義一個單獨的服務器控制線程
減少可支持的線程數量建模元素到過程的映射
類圖
- 作為進程的活動類
- 從進程到類的組成關係
進程關係
進程關係必須支持設計元素關係
檢查點:描述運行時體系結構
描述並發活動的目的是什麼?
什麼是過程? 什麼是線程?
描述識別過程時的一些注意事項。
描述將類和子系統映射到進程的兩種策略。
你如何建模過程視圖?
使用什麼建模元素和圖表?