文章目錄
interaction diagram
文中提到了兩種交互圖sequence diagram和communication diagram,前者相對於後者更好(Craig Larman也承認這一點),後者的優勢就是在牆上畫圖的時候可以充分利用整個牆面.
順序圖
常見圖框操作符
- alt
選擇性的片段,用於表示保護信息所表達的互斥條件邏輯- loop
用於表示保護信息爲真的循環片段.也可以寫*loop(n)*以指明循環的次數- opt
當保護信息爲真時執行的可選片段- par
並行執行的片段- region
只能執行一個線程的片段
ref
用於交互圖引用
metaclass
對於靜態方法/類方法的調用需要加上<<metaclass>>
多態
在這裏圖表表達細節和多態屏蔽細節出現了矛盾,結果就是要畫多份圖,如下所示
active object
就是不需要從系統外部觸發,能夠自己觸發的對象,一般運行在另一個線程.通過生命線框圖加雙豎線表示
通信圖
並不是每個交互圖都要由系統操作消息開始,可以由設計者希望表示其交互的任何消息開始
消息
對象間的每個消息都可以使用消息表達式和指明消息方向的小箭頭來表示…可以增加順序編號以表示當前控制線程中消息的次序
實例的創建
任何消息都可以用來創建實例,但是在UML中約定使用名爲create的消息來實現這一目的(有人用new)
編號
不爲第一個消息編號
使用核發編號的方案來表示後續消息的順序和嵌套,其中嵌套消息要使用附加數字.通過在外部消息編號後附加引入消息編號來表示嵌套
注意上面英文標出的執行順序
互斥&循環
靜態方法 & 多態 & 同步異步
這些和順序圖類似
活動圖
- action
他完成某些事物.在其完成時存在一個自動轉換 - partition
表示參與過程的不同參與者 - fork
一個輸入轉換,以及多個輸出的並行轉化或對象流 - join
多個輸入轉換或對象流,一個輸出變換.其輸出直到所有輸入都到達時才發生 - object node
由動作產生或使用的對象 - rake
當某個活動需要在另外一個活動圖中展開時 - decision
條件分支 - merge
與decision相對應合併 - 時間信號
- 接收一個信號
DFD
活動圖準則
活動圖通常對於涉及衆多參與者的非常複雜的業務過程建模具有價值.對於簡單的業務過程,用例文本就夠用了
在進行業務建模過程中,可以利用rake符號和子活動圖
與像一條相關的是,儘量保持同一張圖中所有動作節點的抽象水平一致
state machine diagram
- event
一件值得注意的事情的發生 - state
對象在事件發生之間某時刻所處的情形 - transition
兩個狀態之間的關係.
準則
一般來講,業務信息系統通常還有少數幾個複雜的狀態依賴類,對此,狀態機建模通常用處不大
與此相反,在過程控制,設備控制,協議處理和通信等領域通常有許多的狀態依賴對象
對狀態依賴對象建模
- 對複雜的反應式對象建模
- 軟件控制的物理設備
電話,汽車,微波爐:他們對於事件有複雜,豐富的相應,相應行爲依賴當前狀態 - 事務處理以及相關的業務對象
某個業務對象如何響應事件 - 角色轉換器
某個人從平民轉換爲退伍軍人
- 軟件控制的物理設備
- 協議和合法序列
- 通信協議
- UI頁面
- 用你係統操作
轉換動作與監護
轉換可以有一個條件監護邏輯測試,只有測試通過時,裝換才發生
嵌套狀態
部署圖
node
部署圖中最基本的元素是節點有兩類節點
- 設備節點
具有處理和存儲能力,可執行軟件的物理計算資源- 執行環境節點
在外部節點中運行的軟件計算資源,其自身可以容納和執行其他可執行軟件元素
- OS
- VM
- DB
- 工作流引擎
注意上面的VM是指jvm這樣的vm
communication path
節點之間一般鏈接表示一種通信路徑,上面可以標記協議
artifact
instance
部署圖中通常現實的一組實例的示例…通常在UML中,具體實例的名字帶有下劃線,如果沒有下劃線則代表類,而不是實例
component
當某人使用UML構件圖時,則其建模和設計意圖是爲了強調
- 接口是重要的
- 它是自包容和可替換的模塊