系統約定：用UML描述工作流管理

系統約定：用UML描述工作流管理  UML模型

關鍵字：UML 統一建模語言（UML）為描述面向對象系統定義了一系列的標準符號。使用UML增強了領域專家、工作流專家、軟件設計者和其他不同背景的專家之間的交流聯系。UML可以在普遍的場合使用，對工作流系統的用戶而言很直觀。除了這些，UML符號具有準確的語義，也就是說可視化的工作流描述可以作為軟件規約。本文側重討論了如何使用UML來描述工作流管理系統，如何跟蹤從業務流程到面向對象軟件設計的描述信息，如何用UML可交互工件來結構化項目知識庫。

　　在本文中，我們先來討論工作流產品的軟件設計者和用戶對一種通用語言的需要，然后再來介紹如何使用統一建模語言（UML）描述一般的工作流概念，最后希望和搭建一起探討如何把面向對象軟件規約與工作流系統的描述聯系起來。

　　下面我們先來描述一個企業在實現新工作流管理系統時的通常情形：

　　顧問與用戶一起描述一個軟件解決方案所支持的企業業務流程。開發隊伍獲得顧問的描述，但是他們很難理解業務術語，發現其中描述了太多的信息以至于難以用來實現此系統。開發者從技術觀點來撰寫系統規約，當把這個系統規約呈現在用戶面前時，由于過于專業，以至于用戶難以理解。然而為了進行下一步的工作，雙方被迫接受了這個系統規約。

　　這種方式很容易導致系統無法達到用戶的需求。用戶、顧問和開發者通常都不是用同樣的語言，這樣的交流問題導致難以保證業務流程所有部分很好溝通，并轉換為技術性的軟件規約。另外，因為使用此系統的實際用戶很難全部理解技術性的系統規約，使軟件系統變得難以使用。

　　其挑戰性在于能用一種既準確又友好的方法來為業務流程和業務系統建模。用來描述業務流程的每一個符號對用戶來說很直觀，并有確定的語義，因此開發者可以用它作為一般的描述，甚至用來精確的描述軟件系統規約。

　　UML有著豐富和復雜的符號來描述軟件系統。這些符號也許太豐富以至于不直觀、不友好。然而，恰當地用UML來描述工作流管理系統有兩大好處。首先，UML是軟件界公認的符號標準；第二，UML也可用在不需要實現細節的一般場合。在顯示的UML圖與那些領域專家已經在使用的圖在直觀上很相近，另外，它們的語義有精確的定義。如有必要，可出于軟件設計的目的給同樣的圖增加詳細的實現細節。

　　業務系統的描述由流程和靜態結構的描述組成。流程最直觀的模型就是一個活動或任務的序列，按照順序完成以到達某個目標。因此，UML的序列圖和活動圖很適用于友好、準確、詳細地描述業務流程，如組織圖之類的靜態結構，沒有實現細節，可以用UML的靜態結構圖描述。圖形化的實現細節往往會誤導那些不精通UML的人。例如，導航箭頭經常錯誤地表示方向，最好是僅用UML表示選項的某一特定子集。例如，把元素互相嵌套來表示組裝比用實心菱形表示關聯要好。用文字來描述各種屬性，而不用UML符號，例如《refine》就比帶三角形的虛線好理解得多。

　　工作流概念映射到UML概念

　　這里介紹了用UML來描述工作流概念的例子。這僅僅提供了一個一般的指導，如何把工作流概念映像成UML，詳細的細節很容易從UML的語義和符號指南[7]得到。工作流管理系統的每個結構都能用合適構造型的UML符號來描述。


圖1 用UML表示業務對象、業務流程、團隊角色

　　圖1顯示了用UML描述業務流程、業務對象、團隊角色。業務對象在UML中用類和對象表示。類描述沒有特性（identity）的業務對象，如發票(invoice)；對象描述有特性的業務對象，比如編號為VM4/55的發票(VM 4/55: invoice)。業務流程1用用例和用例實例來描述，用例根據目標、職責、前置條件和后置條件來描述；用例對象是具體的事件序列。工作流是自動化的業務流程，用帶有構造型 <<workflow>> 的用例或用例實例描述。在UML中用類和對象描述團隊角色（team roles），用類來描述團隊角色的類型，對象描述擔任該角色的具體工人（worker）。所有的符號可以用相應的構造型來修飾，如 <<business object>>、<<business process>>和<<team role>> 。每一個構造型都可以用文字或一個特定的圖標表示。

　　假設業務流程是在業務系統中的業務對象、角色和其他的實例之間協作完成的。請參看詳細介紹“跟蹤業務流程到軟件設計”。

原文轉自：http://www.anti-gravitydesign.com