5系統建模
一、 上下文建模（活動圖）
在系統描述的早期階段，應該首先界定系統的邊界，與系統信息持有者一起明確系統應具備什么樣的功能以及系統環境提供了什么。系統邊界一旦去頂，接下來的部分分析活動就是定義系統上下文和系統與環境之間的依賴關系，在這個活動中，第一步是建立一個簡單的體系結構模型。
5.1 系統上下文
5.2 過程模型（活動圖）
二、 交互模型（時序圖）
交互：用戶交互，與用戶輸入輸出有關；有可能是正在開發的系統與其他系統之間的或是系統各部分之間的交互。為用戶交互建模主要是因為它有助於我們識別用戶需求。為系統間的交互建模應將重點放在可能產生的交流問題上。為系統各部分之間的交互建模有助於我們分析所提出的系統結構能否實現系統所需的功能及其可靠性。
- 用例建模，該方法主要用來為系統與外部參與者（用戶或其他系統）之間的交互建模。
- 時序圖，該方法用來為系統各部分之間的交互建模盡管也包括一些外部因素。
圖5.3 時序圖
時序圖說明：
涉及的對象和參與者列在圖表頂端，向下垂直一條虛線。
交互用帶注釋的箭頭表示：
同步是實心箭頭，
異步空心箭頭，
返回是虛線箭頭。
虛線上的矩形表示對象的生命線（比如對象實例運行所需時間）
Fragment:選擇符號，表示有多種流程選擇
三、 結構模型（類圖）
類圖、泛化、聚合
5.4 結構模型
四、 行為模型
數據驅動建模（數據流圖）
UML不支持數據流圖。原因是DFD關注的是系統功能而不識別系統對象。然而，因為數據驅動系統在業務中太常用了，所有UML2.0引入了與數據流圖類似的活動圖。在UML中也用時序圖表示系統處理序列。
事件驅動建模（狀態圖）
狀態圖表示系統狀態和引起狀態改變的事件。狀態圖不表示系統中的數據流，但可能包括在每一狀態在每一狀態中所執行運算的附加信息。