藍色情懷

UMM(UN/CEFACT Unified Modelling Methodology) 介紹
夏光宣

1.UMM的緣起

 

 雖然在1987年UN/EDIFACT syntax rules即成為ISO 9735的標準，十多年來UN/EDIFACT也持續公佈了將近二百多個訊息標準，截至2000年6月為止，總共公佈了206個標準訊息(含CONTRL、AUTACK與KEYMAN)及40個發展中的訊息；然而UN/EDIFACT並未如當初預期般的普及與影響，中小企業仍然認為EDI成本太高、太複雜，軟體取得不易；另一方面，對企業業務流程及管理流程簡化與合理化的目標，並未臻如理想。

        1994年3月，聯合國歐洲經濟理事會(UN/ECE)所屬WP.4組織(Working Party 4, UN/CEFACT前身)，成立AC.1 Group(Research, Strategic, Advice, and Implementation Planning Group)，研究中小企業未採用EDI的原因，該研究認為原UN/EDIFACT採用Bottom-up方式限制了訊息設計的發展，並且也充分體認到建立業務資訊模式的重要性。在1997年新加坡JRT會議(UN/CEFACT EWG會議前身)決議UN/EDIFACT的策略目標有二，一為傳統EDIFACT，一為OO-EDI。而AC.1的後續研究中顯示出能從物件導向技術與業務資訊建模技術中獲取最大好處的原因乃是所謂Top-down方式。也就是說，從業務流程中建立資訊模式，並從上而下一步一步分解，透過一些邏輯方式，一直到語意層次(Semantic Level)的表達。這樣的分解過程乃是從業務流程到業務交易、業務功能，乃至於業務活動、物件、資料、類別，到最後獲得抽象資料(Abstract Data)或核心業務物件(Core Business Object)。

 

        1998年WP.4改組成UN/CEFACT後，原AC.1工作由TMWG(Techniques and Methodologies WG)工作組接手，TMWG建議採用UML(Unified Modelling Language)為UN/CEFACT建立業務資訊模式之工具，並隨即為UN/CEFACT所採納。然而因為UML並不涉及建立業務資訊模式之發展程序(Process)，TMWG便從1999年起進行UN/CEFACT Modelling Process之研究，也就是UMM(UN/CEFACT Unified Modelling Methodology)；UMM主要見於UN/CEFACT/TMWG/N090-UN/CEFACT Unified Modelling Methodology文件。

2. 何謂UML?

1980年代末期到1990年代初期是物件導向分析與設計(OOA/OOD)方法浪潮的高峰期，物件導向方法論從1986年Booch率先提出後，至今已有五十種以上的方法論出現，比較常見的有Rumbaugh的OMT(Object Modelling Technology)，Booch與Yourdon的OOA/OOD，Jacobson的OOSE(Object-Oriented Software Engineering)，Martin與Odell的OOAD，Shlar與Mellor的OOSA(Object-Oriented System Analysis)，Brock的RDD(Responsibility Driven Design)等，而UML則為這波浪潮的繼任者，它不僅直接統一了Booch、Rumbaugh與Jacobson的方法，而且於1997年11月通過OMG(Object Management Group)標準認證，成為標準模式語言(Modelling Language)。

 

UML的使用範圍乃在於軟體產品發展之標準化，而且可以橫跨整個發展生命週期；雖然UML能支援不同的發展程序，但發展的細部流程則尚未標準化。UML中的U(Unified)代表統一或整合的意思，它統一或整合了下述事項: (1)整合不同的模式語言，(2) 整合不同軟體應用領域，(3) 整合開發階段，(4) 整合內部結構，(5)可以與許多不同的軟體發展程序並存。

 

UML主要包含三種結構: (1)靜態物件結構(Static Object Structure): 同一個時點的橫切面所發生的同步動作，(2)動態行為(Dynamic Behaviour): 靜態物件結構加上時間順序則產生動態的模式。與(3)系統部署(System Deployment): 描述整個控制流程的系統狀況。UML所提供的各種模型(Models)即為提供我們從不同角度描述對系統的觀點(Views)，包含: (1)使用個案觀點(Use Case View): 描述系統功能性的需求，找出使用個案(Use Case)與參與此個案之行動者(Actor)，(2)邏輯觀點(Logical View): 描述達成系統內部功能性作業的細部設計，包含靜態結構與動態行為，(3)實作觀點(Implementation View): 描述系統如何切分成元件，以進行實作，(4)程序觀點(Process View): 描述系統各組成部分整體運作的程序，以及(5)配置觀點(Deployment View): 描述系統硬體或設備之間的連結關係，及軟體程序的配置情形。

 

UML在物件導向分析與設計上提供統一的圖示，主要包含八大圖示，而此八大圖示又以共用元素、各種關係圖示與類別圖為基礎所組合而成。共用元素包含類別(Class)、物件(Object)、使用個案(Use Case)、節點(Node)、狀態(State)、介面(Interface)、封裝(Package)、註解(Notes)、與元件(Component)，如圖一所示。

圖一. UML共用元素

關係圖示則包含從屬(Dependency)、繼承(Inheritance)、關聯(Association)與聚集(Aggregation)，

 

如圖二所示。

圖二. UML關係圖示

 每一個使用個案(橢圓圖示)即有一相對應之循序圖，表示使用個案之時間流程的順序，圖四即為利用自動提款機提款之使用個案的循序圖。

 合 作圖可以顯現出與循序圖相同的資訊，但合作圖更可以看到每一個物件的關係，利用這種關係來撰寫軟體，不但能夠看到同步的，即使在同一時點上牽涉到不同的動 作也可以看到，更可以看到在時間上動作的順序。另外，從合作圖上物件的關係，可以讓軟體品管工程師或系統結構師看到系統的設計是否滿足負載平衡的要求。圖 五即為利用自動提款機提款之合作圖。

 

 類別圖可以顯示出系統內抽象物件(即類別) 間之存在和邏輯觀點上的關係，屬於靜態結構的呈現，圖六為利用自動提款機提款時之類別圖。

 

 狀態圖乃用來表示每一個物件的各種狀態，合作圖是對全部物件做一個宏觀的表示，狀態圖則是對物件的微觀圖示，描述每個物件在其生命週期的各種狀態，圖七為自動提款機帳戶之狀態圖，它包括新開戶(Open)、餘額不足(Overdrawn)與帳戶關閉(Closed)三種狀態。

 

 元件圖為從軟體之實體觀點來表示系統模型，從元件圖可以看出系統中各軟體元件及其關係；在元件圖中有二種元件：可執行軟體元件(Executable Component)與原始程式館(Code Library)。如圖八為自動提款機客戶端軟體之元件圖，ATM.exe為可執行軟體元件，其餘為原始程式軟體元件。而原始程式軟體元件又可分為Body元件(有陰影者)與Header元件(無陰影者)；以C++為例，Body元件對應到該類別(Class)之.CPP檔，Header元件對應到該類別之.H檔。元件圖中之箭號虛線乃代表元件間之依賴關係，也可說是元件間之編譯(Compile)順序；圖九為自動提款機伺服器端軟體之元件圖。

 

 由圖八與圖九可知，此自動提款機系統可被區分為二個子系統：自動提款機客戶端子系統與自動提款機伺服器端子系統；每個子系統可用元件之封裝圖表示，在此，封裝圖即為元件之集合。在UML中，行動者(Actors)、使用個案(Use Cases)、類別(Classes)、與元件(Components)之集合皆可用封裝圖表示，因為當設計一個很大的系統時，使用者並不需要同時看到這麼多細部的模式，此時便可以用封裝圖來表示；圖十為自動提款機系統封裝圖，帶箭頭之虛線乃是指封裝(Package)與封裝(Package)間的依存關係。

 

 配置圖為用來表示各種處理器、週邊設備、網路及軟體元件運轉時之實體配置情形；圖十一為自動提款機系統配置圖，可以看出自動提款機客戶端軟體在不同的地點執行，透過私有網路(Private Network)與自動提款機伺服器端軟體聯結，而自動提款機伺服器端軟體連接有印表機，並且透過區域網路與銀行資料庫伺服器聯結。

 

 循 序圖與合作圖都是描述物件之間互動的關係，循序圖以時間為重點，合作圖以空間為重點；活動圖則是描述互動關係的另一種方法，但是卻以工作為重點，當物件與 其他物件互動時，物件也會在活動的期限之內執行工作，而這些活動與其順序都可被描述在活動圖內。圖十二為以訂單處理為例之活動圖。

圖三. 自動提款機(ATM)使用個案圖

圖四. 利用自動提款機提款之循序圖(以Joe提款20元為例)

圖五. 利用自動提款機提款之合作圖(以Joe提款20元為例)

圖六. 利用自動提款機提款之類別圖

圖七. 自動提款機帳戶之狀態圖

圖八. 自動提款機客戶端軟體之元件圖

圖九. 自動提款機伺服器端軟體之元件圖 圖十. 自動提款機系統封裝圖

圖十一 . 自動提款機系統配置圖

圖十二 . 訂單處理活動圖

3. Unified Process

UML是一種模式語言而不是一種設計方法， UML中並不包括發展程序(Process)，但程序卻是方法中很重要的一部份。三位世界級的物件技術大師Booch、Rumbaugh與 Jacobson，整合了他們的發展程序，於1997年推出物件化程序(Objectory Process)；三位大師又於1998年將Objectory Process改良成為整合程序(Unified Process)，主要是將企業業務模式化(Business Domain Modelling)加入其核心程序工作流(Core Process Work Flow)內。

Unified Process 主要是建立發展程序的基本架構，包含了發展過程中的共通元素，但允許開發者使用適合自己專案技術的其他架構。Unified Process的基本架構包含起始(Inception)、精細規劃設計(Elaboration)、建構(Construction)與移轉(Transition)四個階段，如圖十三所示。這是一個循環式與漸進式(Iterative and Incremental)的發展程序，在每各階段都包含好幾個循環(Iterations)，每個循環都包含完整之生命週期：企業業務模式化(Business Domain Modelling)、業務需求(Requirement)、分析(Analysis)、設計(Design)、實作(Implementation)、測試(Test) 與建置(Deployment)等。

圖十三. Unified Process 發展程序基本架構

4. UMM = UML + Unified Process?

建立業務模式(Business Modelling) 已被UN/CEFACT普遍認可成為未來EWG工作組在電子商業(Electronic Business)標準化之重要工作，而且將用來幫助ITPWG(International Trade Procedure WG)在促進國際貿易流程簡化的工作上。

UMM可謂UN/CEFACT在建立標準業務資訊模式的方法論，此方法建立了一個發展標準業務資訊模式的程序，提供UN/CEFACT各工作組一個正式的建模方式，用來產生電子商業各種標準。UMM主要根據Unified Process Methodology與UN/CEFACT之需求加以改良而成。UMM可用來發展諸如傳統EDI、Simple EDI、OO-EDI、與XML/EDI標準。

雖然一個UML或Unified Process的專案包含軟體的開發、測試與建置、移轉，但UMM僅涉及在建立上述標準所必須的工作，即僅包括起始(Inception)與精細規劃設計 (Elaboration)階段，並不包括建構(Construction)與移轉(Transition)階段，如圖十四所示。

圖十四. UMM發展程序

UMM發展流程工作包含4個 步驟: (1)業務建模(Business Domain Modelling)，(2)電子商業需求分析(e-Business Requirement)，(3)電子商業模式分析(Analysis)，(4)電子商業模式設計(Design)；UMM可用如圖十五之使用個案圖表 示，可知整個標準發展過程包含業務領域專家(Business Domain Expert)、業務流程分析師(Business Process Analyst)、電子商業模式建模專家(Technical Modeller)、與訊息設計師(Message Designer)或軟體發展人員(Software Developer)。

圖十五. UMM(UN/CEFACT Unified Modelling Methodology) 使用個案圖

4.1 業務建模(Business Domain Modelling) 

業務建模之目的乃是以形式化的方式描述在所考量之業務領域內，交易夥伴間作業流程 之結構與動態關係，讓使用者、標準發展者、與軟體提供者，對整個業務與其需求有一共同的了解，其進行的方法主要為諮詢業務領域專家、撰寫描述該業務之文 件，並獲得使用者簽認。其進行可分為下述五步驟:

4.1.1 界定欲建模之業務範圍

包含界定業務領域(Domain)及其範圍(Scope)、業務夥伴及其角色(活動者Actors)，在此領域內所交換之業務資訊(Business Entities/Objects)，與驅動業務交易之主要原因與方式(Requirements)。

4.1.2 分割業務領域

將業務領域區隔成數個獨立的子業務(Use Cases, Packages)。

4.1.3 界定Actors之間之主要活動

界定資訊交換之業務夥伴所代表之成對角色活動者，以他們交換資訊之前後結果描述各種關係(Use Cases)，並定義出各種關係的活動(Activities)。

4.1.4 界定業務流程

經由步驟4.1.1所界定之驅動業務交易之主要原因與方式，組織各個成對角色(Actors)之活動成業務流程(Scenarios)，並且以順序或平行的方式決定該流程所必須完成的活動事項(Activity Diagram, Use Case Scenario Description)。

4.1.5 界定交換業務資訊

對每一個業務夥伴之活動事項，決定其交換之業務資訊(Business Entities/Object Classes, Glossary) ，與這些業務資訊的關係(Class Diagram)。

4.2 電子商業需求分析(e-Business Requirement)

電子商業需求分析的主要目的乃在於在所選取的業務領域與範圍內，獲取在電子商業解決方案中的業務需求，也就是定義出在前述步驟所建立的業務模式中，哪些是與電子商業有關的(Scope)。再進一步分析這些相關的模式，以獲得後續在發展電子商業解決方案時所必須的詳細資料。尤其是前述步驟中所決定之業務資訊(Business Entities/Object Classes)的屬性必須進一步定義與命名，使用案例敘述也必須重新審視、敘述，並加入任何新的角色以重新界定業務夥伴的特性(Actors, Use Cases, Class Diagram, Glossary)。彙整會影響最後電子商業解決方案設計之各種業務需求(Requirement List)，如效率需求等。最後要與業務領域專家重新審視結果並修正，同時也修正前述在業務建模階段所建立之業務模式。

4.3 電子商業模式分析(Analysis)

電子商業模式分析主要在將前述電子商業需求分析結果轉換成物件導向方式之技術規格，以便進行後續之電子商業解決方案模式設計。

重新審視使用案例與業務資訊類別(Business Entities Classes)，以找出是否可以一般化(Generalization)，而可以使用於其他的電子商業解決方案；檢視前述各步驟所建立之各種模式是否滿足需求，並進一步以新的圖形方式詳述各個模式，如以事件循序圖描述業務流程、將各個物件類別的操作方式加入類別圖中等(Use Cases, Sequence Diagrams, Collaboration Diagrams, Entity Classes, Control Classes, Class Diagrams, Patterns)。

4.4 電子商業模式設計(Design)

最後，電子商業模式設計階段則將前述電子商業模式分析結果轉換成相關之EDI訊息(UN/EDIFACT訊息、Simple EDI訊息、XML訊息等) (Message Specifications)，或者另可以當作物件導向設計規格，提供給獨立軟體開發廠商(ISV)以開發軟體(Interface Classes)。而如何將UML Models轉換成EDI訊息，UN/CEFACT EWG/OO-EDI工作分組將與TMWG工作組進行討論以制定轉換規則與指引(Mapping Rules/Guidelines)。

TMWG建議UMM在各個工作步驟所必須交付之UML文件如表一所列 (?表示視情況而定)：

表一. TMWG建議UMM在各個工作步驟所必須交付之UML文件

5. BPAWG 與 EWG 資訊模式發展程序

如圖十六所示，UN/CEFACT BPAWG(Business Process Analysis WG)工作組所建立之基本參考模式將提供給EWG工作組與個別產業工作組，進行發展個別產業領域電子商業資訊模式標準之建立，並將之存入標準資料貯存庫(Repository)內，而BPAWG工作組之基本參考模式亦據此加以修正擴充。

圖十六. BPAWG 與 EWG 業務資訊模式發展程序

6. 結語

UN/CEFACT底下設有BPAWG(Business Processes Analysis WG)ATMWG(Techniques and Methodologies WG)AEWG(EDIFACT WG)AITPWG (International Trade Procedures WG)ACWG(Codes WG)ALWG(Legal WG)等常設工作組C而對BPAWGATMWGAEWGAITPWG而言CUMM Business Information Modelling皆為其主要工作；UN/CEFACT與OASIS(Organization for Advancement of Structured Information Standards)合組成立之ebXML工作組，底下之工作分組(Business Process PT(Project Team)ACore Component PTATechnical Architecture PT等)也大量使用UMM方法，進行XML相關標準之分析設計工作。

電子商務軟體技術之發展從早期之Entity-Relationship Modelling方法A以系統功能模組切割為主之結構化分析與設計C到主從式架構A以瀏覽器為主之Web TechnologyA物件導向分析與設計A進而到目前是以軟體元件技術與應用架構為基礎之網路交易與服務；而未來將會是以知識交換與協同運作協定為基礎之網路應用自動化與個別化為主，UMM與ebXML所揭諸的，正是這樣的知識交換與協同運作模式，今天，我們正站在資訊革命的洪流上，讓我們載此洪流之上，一起向上提昇吧!

7. 參考資料

Ref.1 UN/CEFACT/TMWG/N090 - UN/CEFACT Unified Modelling Methodology.

Ref.2 The Unified Software Development Process. Jacobson, Booch, Rumbaugh - Addison Wesley, 1999 - ISBN 0-201-57169-2.

Ref.3 物件導向分析與設計，楊正甫博士，Unalis, 2000.

Ref.4 Mastering UML with Rational Rose, Sybex, 1999.

Ref.5 UML Distilled: Applying the Standard Object Modelling Language, Martin Fowler and Kendall Scott, Addison Wesley and Unalis, 1998 - ISBN 957-22-2992-3.

Ref.6 UN/CEFACT/ BPAWG/ BP029 - Business Modelling for UN/CEFACT.

(作者現為資策會XML標準制定及銀行公會金融電子化委員會XML標準制定小組顧問)