顯示具有 UML 標籤的文章。 顯示所有文章
顯示具有 UML 標籤的文章。 顯示所有文章

2009年8月14日 星期五

UML - 活動圖 (Activity Diagram)

在循序圖裡面不容易表達狀況的分支
同一個時點可能會有多種選擇
而不同的選擇應該要接下去發展的情況就有所不同
這時候就要用活動圖來表示這些分支的狀況

一個循序圖有下面幾個元素
元素說明
初始狀態
(Initial state)
活動的起始點,全圖只會有一個,實心圓
最後狀態
(Final state)
活動的終止點,全圖至少一個,實心圓外包一個圓
動作狀態
(Action state)
代表一個動作,左右為弧線,上下為水平線,登入...
決策
(Decision)
代表情況的分歧,菱形
行動流
(Action flow)
動作之間的連續,實線箭頭
可加條件,以中括弧夾住
物件流
(Object flow)
物件之間的傳遞,虛線箭頭,此例圖中無
分叉(Fork)該狀態可以有多種行動,粗黑線段,一進多出
加入(Join)多種狀態都可以有該行動,粗黑線段,多進一出
此例圖中無

活動圖其實和流程圖很像
透過活動圖可以將整個系統的流程表達出來
也可以找出一些在循序圖中無法發現的分歧,避免遺漏

UML - 循序圖 (Sequence Diagram)

在使用案例圖做完後,會發現我們要提供的系統該提供哪些功能
可是系統到底應該做些什麼來達到這些功能呢
這時候就需要循序圖(Sequence Diagram)來幫忙啦

循序圖最大的好處就是可以沿著時間軸
一步一步的將某個使用案例中,系統元件的訊息交換表現出來

一個循序圖至少有下面幾個元素
元素說明
角色
(Class role)
每個物件在系統中所扮演的角色,觀眾、訂票網頁、資料庫
生命線
(Lifeline)
角色存活的時間,角色下延伸的虛線
活動
(Activity)
角色處理一項操作需要的時間,覆蓋虛線的方框
訊息
(Message)
物件之間溝通的訊息,方框間的箭頭符號
* 一般傳輸、呼叫、回傳分別用不同的箭頭表示
* 使用者對介面的溝通常會在訊息前加上"/"以示區別

透過循序圖,開發者可以先構思每個物件該如何交換訊息
而且因為有時間軸的概念,循序圖可以表示一些事件應該發生的先後順序
這是靜態圖和使用案例圖無法達到的

另外,雖然循序圖基本上是對單一使用案例的單一情況
(使用者下的決定或環境狀況)來做描述
不過如果希望將多種可能同時畫在一張循序圖上
也可以在傳遞的訊息前加上[狀況]來表達某種情況下的處理方式
不同狀況的處理方式就可以放進同一張循序圖中了
有興趣的話可以參考Interaction Diagrams
不過基本上這種做法常會讓循序圖的時間軸亂掉
如果沒有把握的話不建議使用

2009年8月10日 星期一

UML的使用流程

因為UML就是一個工具箱,看什麼場合用什麼樣的工具
所以其實並沒有所謂的使用流程
但是對於初學者,還是可以遵照一個簡單的流程
步驟說明
使用者觀點利用使用個案圖,將使用者會直接用到的功能列出
行為觀點利用循序圖,表達每個使用個案的特定流程
利用活動圖,將循序圖泛化成一般活動流程
結構觀點利用類別圖,表達活動及循序圖中所用到的物件類別,包括變數、函式及其間相關性

根據UML的使用時機,UML是在設計階段之後
也就是已經將需求分析等事前準備工作都完成後
要將概念傳達給實作者的步驟
所以這整個塑模的流程,是在已經清楚的知道想要做出的成品時
將成品的概念利用塑模的工具一點點捏塑出來
而當類別圖建好之後,就已經可以開始實作了

UML的使用時機

初學者在使用UML的時候很容易迷失了方向
因為UML提供了太多的觀點而不知從何下手
這時候可以先從系統的開發角度來看
階段說明
設計分析需求,將需求分類,並針對有效的需求做出相應設計
實作針對設計出的模型,將需求實際的功能填入模型
評估根據實作出的成品,審視需求的滿足狀態

而UML的模型套用的地方,就是從設計階段到實作階段時
透過設計者(非工程師)與實作者(工程師)共同瞭解的表示法
有效的將設計的理念傳達出來
在評估階段,也可以透過當初設計者所制定的UML
確認實作者是否將設計者所想的都做了出來

另外,由於上面列的這段流程會是一個循環
從設計出發,實作、分析、修正設計、添加實作、重新分析...
透過螺旋式(Spiral model)的放大,一步步的進化成完成品
所以UML在使用上也會是這樣的進化
並不需要在一開始的時候就訂的非常完整
而是經過不同階段的實作及分析修改設計,漸漸的完善出來的

2009年8月5日 星期三

UML - 使用個案圖 (Use Case Diagram)

在開始對一個系統塑模的時候,通常會先從使用個案圖開始
由非工程角度出發,確定該系統的設計範圍以及使用者會使用到的功能
也就是利用使用者的觀點取得一個視角,例如

一個使用案例圖至少有下面幾個元素
元素說明
動作者(actor)實際操作系統的人或外部系統,觀眾
使用案例(use case)系統提供的功能,動作越明確越好,訂票、取消
系統(system)實際上要開發的系統,訂票系統

由上面的例子可以看出,我們開發的訂票系統,使用對象是觀眾
可以操作的功能則有訂票和取消兩項
使用案例圖有時候還會用一些關聯性來模組化使用案例

關聯性說明
使用(uses)在過程中會使用到其它的使用案例,也稱做包含(include)
擴充(extend)在某條件成立下,會使用到其它的使用案例

如果系統是由多個人共同開發,透過使用案例圖
可以在制定細節前,預先讓開發者對於使用者可以有一致的瞭解
之後在開發的時候才有所依據

--
參考資料
從鳥瞰的觀點看 Use Case Diagram
使用案例圖的UML風格指南
Wikipedia - Use case diagram

2009年8月4日 星期二

UML的圖形種類

在UML2.0里面定義了13種圖(Diagrams)
結構性圖形(Structure Diagrams),系統式的建模
類別圖
(Class Diagram)
將系統中的類別列出,並描述出每個類別包含的屬性方法及類別間的關聯性
元件圖
(Component Diagram)
系統的實作觀點,系統中元件的互動、關連性及介面
複合結構圖(Composite Structure Diagram)系統中元件、類別或是使用案例的細節
部署圖
(Deployment Diagram)
系統的環境觀點,資源元素的組態及其與元件間的互動
物件圖
(Object Diagram)
類別的實作,通常是在某個時間點或某特定情況下的物件及其之間的交互關係
包圖
(Package Diagram)
顯示模型元素是如何包裝起來,以及這些包裝間的相依性
行為式圖形(Behavior Diagrams),事件觸髮式的建模
活動圖
(Activity Diagram)
單一類別對於內部處理作的反應,包含行動流及物件流
狀態機圖
(State Machine diagram)
單一物件的生命週期,顯示其與外界互動所造成的狀態改變
使用個案圖
(Use Case Diagram)
系統的使用者觀點,表示系統可以提供給每類互動者哪些功能
溝通性圖形(Interaction Diagrams),資料流程式的建模
行為圖形的子集合
通信圖
(Communication Diagram)
表示物件的相關性,以及其間的訊息流,也叫做合作圖(Collaboration Diagram)
交互概述圖(Interaction Overview Diagram)概觀系統的控制流,每個活動都可以再被表示成一個交互圖,2.0新增
循序圖
(Sequence Diagram)
顯示在時間序列中,類別訊息交換的順序
時間圖
(Timing Diagram)
物件受互動影響而造成的狀態改變過程(隨時間改變的狀態),2.0新增

在規畫塑模的時候,不一定全部都需要建立出來
依照系統的屬性以及需求,採用不同的面向才有意義

--
參考資料
維基百科 - 統一塑模語言(UML)
Introduction to the Diagrams of UML 2.0

UML概觀

UML可以用各種不同的面向來呈現或觀察一個系統
舉例來說,一台螢幕可以用這些面向來呈現
或許因為面向太多,所以很容易混淆而弄不清楚UML到底在幹嘛
面向呈現
功能呈現影像訊號、轉動改變視角、按鍵調整設定、觸控(選用)
結構背光模組、框架、接頭、按鍵、觸控模組(選用)
狀態開、關、調整畫面

我覺得應該不要把UML當成一種語言,而是一種溝通的工具
用一些大家約定好的記號來表示剛剛所提的這些面向
比如說一個橢圓、或是棒子人、一個方框...都代表特定的含意
在呈現與觀看的雙方都建立好同樣的背景知識後
才有辦法針對系統內可能會發生或已經發生的問題討論

對於大型系統開發尤其重要,越是耗費人力與時間的系統
越容易在過程中有共同開發甚至交接的狀況發生
大型系統耗費在溝通上的時間可能還超過開發的時間
這時候一個共通的溝通工具和已經制定好的模型就異常重要了