前言

UML(統一塑模語言；Unified Modeling Language)是一種用於塑模的標準語言。軟體系統發展人員使用UML以建造模型，將系統具象化、系統結構及行為規格化、建構系統、以及記錄發展系統過程中之各項決策，建構這些模型的過程就稱為塑模。軟體開發過程中必須將需求、分析、設計、實作、佈署等各項工作流程的構想與結果予以呈現，這就是軟體系統之塑模。

UML已經是在物件導向軟體發展中，一個呈現多種設計方式的標準。UML提供不同的示意圖型態支援從需求詳述到實作的發展過程。這樣的模組，可藉由不同示意圖來呈現，並從不同見解或是不同抽象化階段來察看一個系統。因此，相同系統的多種UML模組，不是獨立被詳述，而是有極度的重疊性，在許多方式上彼此皆依賴著對方。例如，一個模組的改變可能會影響到其他模組的改變，而且一個模組中的一大部分可能能夠在其他模組中被綜合化表現出來。

本文重點在於闡述UML塑模的流程與轉換，至於每種塑模圖的繪製方式與標準，則不在本文範疇中。

塑模工具

主要的塑模工具當然就是UML塑模圖，UML提供了九種不同型態的圖：類別圖(class diagram；CLD)、循序圖(sequence diagram；SED)、合作圖(collaboration diagram；CBD)、狀態圖(state-char diagram；SCD)、活動圖(activity diagram；ACD)、物件圖(object diagram；OBD)、佈署圖(deployment diagram；DED)、使用個案圖(use case diagram；UCD)。

要操作這些圖形進行系統塑模，可以透過一些case tool軟體去實作，例如: Rational Rose、Power Designer等工具。

塑模轉換

模組之間的塑模是互相重疊與依賴，並且可以相互轉換，如圖一所述。

關於從來源圖到目標圖的資訊傳遞，操作上有不同的特徵。分類成四種：

一、完全轉換(full transformations)
二、強轉換(strong transformations)
三、支援轉換(supported transformations)
四、弱轉換(weak transformations)

這些類型主要是因為不同類型圖之間關係強度而提供，關係愈弱就需要使用者愈多互動，使得這項操作發揮作用。

在完全轉換裡，目標圖中幾乎包含和來源圖一樣的資訊。這類的轉換可能只有發生在語意相近的圖對之間。例如：SED←→CBD 和 SCD←→ACD。只有不重要的視覺資訊會遺失，像某些在合作圖中的連結不能對應到訊息的交換。的確，循序圖和合作圖在UML的中繼模式上是沒有不一樣的。

循序圖和合作圖主要共享同樣的語義資訊。當循序圖強調在互動訊息傳遞的順序時，合作圖則把更多的焦點放在互動物件的表面配置，轉換過程不會產生有意義的新資訊。

因為狀態圖和活動圖的關係，UML中繼模式主要描述活動圖為一個狀態圖中繼模式的特別化(specialization)。因為一個狀態圖的集合轉成活動圖是很直接的。其它方向也可藉映對活動圖的元素到比較一般性的狀態圖的元素來定義。但這兩圖幾乎使用在不同目的：SCD是為了狀態的模組化，而ACD是為了程序的模組化。這樣的差異將在UML2.0中反應出來。

一個強轉換可以被定義在那些有豐富語義關係的圖之間。目標圖包含了大部分的資訊而且圖跟人為了系統模式的同一部分用手畫出來的圖是相差不多的。先前說的循序圖可以使用者個案、支援強轉換操作的工程流程，直到程式碼的產生為基礎來建構。

在使用個案圖和這些型態圖之間直接轉換是可被預期的有趣；至於提到的這些型態圖則通常被使用來塑造使用個案的行為：活動圖，合作圖，和循序圖。但在使用個案圖中只有一點點的資訊是有用的。這可視為在UML中的一個瑕疪(D'Souza and Wills, 1999, Sect. 4.3)。

一個支援轉換被定義成是在中繼模式程級下沒有共享大部分資訊的兩圖之間的轉換。例如，在這樣的案例下，設計師藉由使用UML的延展機制來提供額外的資訊。這轉換產生了一個圖有大部分的資訊，但卻由額外的資訊來支撐；沒有這樣的支撐時就會變弱。

一個這樣的例子是：CLD → CMD。他假定設計師已指派適當的標準tagged value("location")到類別，用來指示這些元件包含此類別。然後，它就有可能自動地產生一個元件圖，在這裡類別們就瓦解成元件。這個轉換可進一步地藉由引用探索式來改善，使得這些因為某個介面集合而相互連結的不同類別群組能夠清楚辨識，而且使用這些群組來當作建構元件的額外標準。這個方法在抽象化類別和辨識元件是有用的。同樣的技術可以使用來產生從類別圖中產生佈署圖。另一個不同的例子是從SCD ' CLD。這個也可視為是強轉換，但也有另一個方式來定義他：狀態圖的類別基礎實作(class-based implementation of statechart diagrams)。在這樣的方法下，基本的狀態機器藉由使用者定義的轉換規則集合來物件化(objectified)，可能也得遵守了一個正確的設計樣式(design pattern)(e.g.,the State pattern by Gamma, Helm,Johnson,and Vlissides, 1995,305-313)。這樣的案例下，這額外的資訊包含了這些轉換的慣用手法(transformation conventions)。這類的轉換和強轉換跟支援轉換在性質上稍微不同，主要是因為他不是以來源跟目標的中繼模式之間的中繼模式為基礎，而只是在某種實作上的不同。這就某種意義來說，這個操作類似程式碼產生。

在弱轉換時，目標圖只包含了一小部分的資訊，但不過可以當作圖的樣版(diagram template)，使用來當作建構一個新的圖的進入點。例如：CLD→SED。這個弱轉換將在類別圖中的每一類別以來建立一個有著參與者的循序圖，但並沒有事件。這個循序圖將被視為是一個prefilled form，用來描述在這個特定子系統下類別實例(instances)之間的互動，並以類別圖呈現。

塑模流程與範例說明

闡述了塑模轉換之後，接著透過一個簡單的範例，無人化商店-自動販賣機，說明塑模之流程，中間有許多的細節，可直接使用case tool進行第三節闡述的塑模轉換。塑模流程如下:

一、需求塑模－建構使用個案圖

販賣機系統的作業與功能需求描述表達如下：

1.消費者來到自動販賣機前面，瀏覽商品資訊消費者欲知詳細商品資訊，可進一步了解商品細部說明(PS: 必需鏈結相關的型錄藍圖/資料詞彙)。

2.消費者可購買一種商品或多種商品，數量以五瓶為限(每項商品的預設值皆為一瓶)。

3.消費者可對商品進行數量或商品之修改。

4.消費者選定購買商品後，自動販賣機會自動進行庫存檢查並計算總金額，列出所購買之清單(註：必需鏈結相關的購買藍圖/資料詞彙)。

5.消費者進行購買清單之確認。

6.消費者使用現金付款的機制：使用現金，系統確認消費者在45秒內投入金額，完成付款。

7.消費者使用手機付款的機制：系統感應手機定確認手機身分，系統紀錄購買應付的金額，傳回手機，消費者完成付款動作消費者領取購買商品，系統自動盤點商品存貨(註：必需鏈結相關的補貨藍圖/資料詞彙)。

然後找出行為者，並且描述使用個案，例如:



並且找出使用個案間的關係，繪製使用個案圖:



二、需求塑模－建構活動圖

以「選購商品」為例，依據該使用個案的一系列事件描述或描述性綱目，分析有哪些活動與參與之實體等。結果得知共有瀏覽商品、顯示明細、選取商品、設定數量、檢查存貨、計算總金額、顯示購買資訊及確認購買，且有行為者客戶之參與。

找出活動間之轉換、執行程序、介面(資料輸入/資料輸出、欄位)。分析如下:

1.首先消費者可以選擇是否瀏覽商品的詳細明細，系統必須呈現產品編號、名稱、口味、單價、容量、冷、熱、熱量、目前存量，讓使用者能夠快速瀏覽商品並了解所需商品資訊。

2.而後使用者可以自由選擇所需產品，並且設定商品數量，假使不設定數量即為預設值1瓶。

3.設定數量後系統會自行進行存量檢查，如此形成迴圈直到完成選購為止。

4.選購完成後進行總金額計算，然後顯示訂單資訊給消費者。

5.最後進行選購清單的確認。



三、物件資料結構塑模-類別圖

以「自動販賣機系統」之中的選購商品及修改商品為例，先以進行物件靜態塑模，繪製類別圖，而類別圖的繪製主要是根據需求塑模之產出，例如使用個案圖、藍圖…等找出類別與類別間之關係。

選購商品使用個案中的客戶類別所涉及的一系列事件來分析此類別的操作，其結果如下：

事件1. 客戶 + 瀏覽 + 商品資訊

事件3. 客戶+ 選擇 + 商品

事件4. 客戶+ 設定 + 商品數量

事件5. 系統 + 檢查 + 存貨

事件6. 系統 + 計算 + 總金額

事件7. 系統 + 顯示 + 購買資訊

事件8. 客戶+ 確認 + 交易

操作的定義來看，它用以表達物件的行為，可能是系統的使用者所下的指令，或是物件與物件之間的互動。

選購商品使用個案中有購買清單、商品兩類別且兩者之間為多對多關係，另外有一個「數量」的關聯類別。



四、物件互動行為塑模

循序圖之建構可先由類別圖或使用個案圖中，確認類別之物件、物件間傳遞之訊息及操作等，再進一步繪製循序圖。

確認物件間之訊息與操作:







五、使用者介面塑模

主要是以使用個案與活動圖搭配藍圖與資料詞彙進行使用者需求塑模。

介面架構圖(PAC)模式是常見的介面架構表達工具。PAC架構圖將使用者介面細分成許多個子介面，每一個子介面可視為一個物件，每一個物件主要由三個部份所組成：表達(Presentaion)、摘述(Abstraction)及控制(Control)。



完成了使用者介面需求塑模後，再依每一個活動圖上活動之輸出與輸入註記設計介面及依活動之執行順序建構出該系統完整的介面架構圖。

六、MDA轉換程序

在case tool的輔助下，進行Model Driven之轉換，包括資料塑模與template code等。

總結

UML是一個系統塑模良好的工具，任何方法論都可以藉由UML的輔助得以實現，不論是正向工程或反向工程，都可以透過UML的表達，獲得良好的系統開發、詮釋、改善與維護。

參考文獻

http://www.iiiedu.org.tw/knowledge/knowledge20031231_2.htm

物件導向系統分析與設計─結合MDA與UML, 吳仁和, 貝塔/智勝, 2005-02-01.

Transformation between UML diagrams, Petri Selonen; Kai Koskimies; Markku Sakkinen, Journal of Database Management; Jul-Sep 2003; 14, 3

Airaksinen J., Koskimies K., Koskinen J., Peltonen J., Selonen P., Siikarla M., & Systa T. (2002). xUMLi: Towards a Tool-independent UML Processing Platform. In: K. Osterbye (Ed.), Proceedings of NWPER 2002, Copenhagen, Denmark: IT University of Copenhagen.

Rational Software Corporation (2002, October), Rational Rose Pmdiiet Family, Available online : http://www.rational.coffi/products/rose


Reggio, J.L. Sourrouille, & Z. Huzar (Eds.), "UML" 2002 Workshop on Consistency Problems in UML-based Software Development. (Research Report 2002:06) (pp. 75-90). Ronneby, Sweden: Blekinge Institute of Technology.


UML2.0技術手冊--UML 2.0 in a Nutshell, Dan Pilone / Neil Pitman, 蔡學鏞, 歐萊禮, 2005-01-24.