【UML實戰智慧第1回】保持簡單，開發團隊才能齊步前進

IKEA創辦人英格瓦．坎普拉（Ingvar Kamprad）常把「簡單是一種美德」這句話掛在嘴邊，他經常訓誡大家，只有平庸的人，才會提出複雜的解決方案。

同樣地，在UML專案現場，保持簡單使用的UML也是一項值得讚許的美德。或許，我們真要借用坎普拉的話來提醒自己：只有平庸的團隊，才會把UML用得既複雜又困難。

因此，在UML專案現場，限制團隊成員使用最少量的UML概念和圖示，訓誡團隊成員採用相同的作業程序，藉由犧牲一些自由與創意，或許可以換取團隊成員以最快速度齊步向前走，強力挺進UML專案現場。

現場的作業程序
在系統分析師的現場作業中，跟UML有關的產出及作業程序主要有三項，分別為：

1.業務流程建模：使用UML的活動圖（Activity Diagram），來表達系統建置之後，所支援的新業務流程。建議的現場作業程序，如圖1所示。

圖1. 業務流程建模的作業程序

2.使用案例模型：使用UML著名的使用案例圖（Use Case Diagram）以及使用案例敘述（Use Case Narrative），來呈現使用者與系統互動以獲取產品或服務的過程。建議的現場作業程序，如圖2所示。

圖2. 使用案例建模的作業程序

3.領域模型：使用UML的類別圖（Class Diagram）來表達問題領域（problem domain）中的重要實體（entity），以及實體的屬性（attribute）、操作（operation）、限制（constraint）、角色（role）和關係（relationship），用來做為系統內部重要的業務核心。建議的現場作業程序，如圖3所示。

圖3. 領域建模的作業程序
現場使用的圖示

目前最新版的UML2有十四款圖，系統分析師只需要從中取用三款圖，分別為：活動圖、使用案例圖和類別圖。但是，即便如此，每一款圖中也都還包含了數十個概念及圖示。

由於，每一個圖示就是一個可以用來溝通的詞彙，所以有必要對這三款UML圖中，可以被團隊拿來使用的圖示，再做進一步的限制，以便縮減團隊成員的學習成本與溝通成本。因此，限制團隊成員只能夠使用表1、表2和表3所明確列出的圖示。

表1. 活動圖圖示

動作（Action）                  

活動終點（ActivityFinal）         

    判斷節點（DecisionNode）

分叉節點（ForkNode） 

起始節點（InitialNode）          

 會合節點（JoinNode）      

合併節點（MergeNode）  

物件節點（ObjectNode）            

活動動線（ActivityEdge）

表2. 使用案例圖圖示

參與者（Actor）

擴充關係（Extend）包含關係（Include）使用案例（UseCase）

表3. 類別圖圖示

類別（Class）

結合關係（Association）

聚合關係（Aggregation）

個體數目（Multiplicity）

除此之外，如果系統分析師有需要引進任何一個圖示時，都需要提報給專案經理，並且開討論會議邀請所有系統分析師共同決議是否採用，同時得對新採用的圖示之定義、使用時機等，有基本的共識。

如此一來，才不會出現系統分析師說著其他成員不甚了解的詞彙，獨自一人喃喃自語的窘境！