IDEF 方法論－簡介與網站
CALS 之模型分析方法 --
IDEF , ARIS 與 OOA/OOD
中崗科技 王嘉玲
0. 概論
|
CALS 專案的發展往往是多元而繁複的，就如同所有的大型軟體開發工程一般，專案前期的分析規劃與設計，往往是決定專案成敗的關鍵。在 CALS 的各種應用中，企業程序再造 (Business Process Reengineering, BPR) 也就成為不可或缺的一環。 |
|
另外，CALS 的特性在於資訊的交換，電腦系統也走向分散式 (distributed) 架構，因此軟體元件 (software component) 的使用，已是不可避免的驅勢，這點從 OLE (Object Line and Embedded) 以及 CORBA (Common Object Request Broker Architecture) 的應用愈來愈廣泛就可看出。在CALS 的規劃中，物件導向設計與分析 (OOA/OOD)，可以預見將愈來愈重要。本文也將大致介紹目前 OOA/OOD 發展的概況。 |
0.1 企業流程再造 (Business Process Reengineer, BPR)
| 現今企業的特是：雖然電腦化，但所儲存的資料, 重複性高﹔商場上瞬息萬變，所以各部門的處理程序，必需經常因應更改；各種電腦技術不斷演變，也使的企業中存在各種異質的資訊系統環境；而且人工作業與電腦所支援的系統之間的交易處理也是經常變動的。常此以往，所導致的結果是：作業時間長、成本高、彈性低，無法因應多變的市場；作業流程未透明化，工作群組之間無法取的共識。因此，為了不被市場淘汰，許多企業被迫重整現有的組織程序，而”企業流程再造”(Business Process Reengineer) 也就成為目前 IT 界的流行的字眼。 |
| 質精兼具整合 (Lean and Integrated)，則是一個有效率的作業組織的關鍵需求。再造的目標是即時回應 (just in time)，減少作業時間，降低成本，並增加作業的彈性。資訊的處理必須能因應這樣的重建工程。重建工程的首要工作，就是分析出現有的作業流程，再從中找出可改進的部份。無數的公司曾經嘗試這麼做。 然而, 想要從企業再造計劃中獲得好處的唯一可能，就是所發展的處理模型 (models)，必須讓實際運作的各個階層了解。因此建立模型 (modeling) 也就成為 BPR 中一項不可或缺的工作。 |
0.2 建立模型 (Modeling)
| 無論是要試著了解或是修改一個現有的系統，或是從頭建立一個新系統，改造成功最大的障礙，就在於無法分析或是溝通企業內無數的交互往來影響的程序。對談式的語言，如國語或英語，常常是模稜兩可，不夠明確有效率;而正式定義的語言 (如電腦系統的程式語言)，對大部份熟悉功能或業務的專家而言，又不是容易了解的。所以我們需要的是一種結構化的交談語言，去除掉其中的不明確性，增加溝通與瞭解的效能。建立模型 (modeling) 就是一種互相瞭解與溝通的有效技巧，而且已經使用了數個世紀。
但為了正確的描述系統，建立模型必須從不同的觀點切入。例如，在程序模型 (process model) 中，多餘的細節就被刪除，系統的複雜度降低，更易於理解。在資料模型 (data model) 中，就專注於資料個體的屬性與關係的設計。一個房子在建築施工之前，一定是先有建築先畫好整個工程的藍圖 (blueprint)。藍圖是實體建築的邏輯 (logical) 與觀念 (conceptual)的呈現。同樣的，以軟體系統的複雜度，必須以工程的方式來處理建構的程序。首先，最重要的就是建立模型，也就是軟體系統的藍圖。無論是 IDEF，ARIS 或 OOA/OOD，或是其他的方法論，都是希望能夠以不同的觀點，來清楚描繪出系統，讓工作群組中的所有成員取得共識，使未來能夠在一致的認知下，完成系統的構建，同時也留下詳細明確的文件，供日後維護、人員訓練等之用。企業內的資訊作業程序，不僅只是 IT 人員的技術，而是提昇為全企業的一項資產。 |
1. IDEF 方法論 (IDEF methods)
1.1起源
| 在 1970 末期，美國空軍 (U.S. Air Force) 推出了 ICAM (Integrated Computer Aided Manufacturing, 整合性電腦輔助製造) 計畫，目的在於應用電腦技術，改進製造的產能。在計畫發展的過程當中，計畫人員了解到，冗長，文字敘述的語言，對於製作文件或是驗證一個程序的可行性上而言，實在不是一種有效率的表達方式。而長篇大論的程序操作手冊的實用性更是低，因為，表達不夠明確；很難去檢視確認邏輯的正確性；很難維護，且成本很高；無法清楚的展現系統中各種替代的選擇。
因此，ICAM 計畫人員先採用了部份 SADT (Structured Analysis & Design Technique) 的方法來描述系統。 SADT 是在 1960 與 1970 年代， Douglas T. Ross 所發展的一種新的建立模型的技術，之後又陸續加入其他的方法論，從不同的觀點建立模型。最後，這項計劃的副產品，就是四種以圖形為基礎的建立模型的語言，也就是 IDEF (Icam DEFinition) Methods。他們分別是：
|
1.2 近期的發展
| IDEF 家族不斷的應用演進，在 1985 年， IDEF1 擴充更名為 IDEF 1X。此後，IDEF 方法就廣汎的被使用於政府與私人企業，用來記錄、分析與改進各式各樣的企業程序。
在1990 初期， IDEF Users Group 與美國國家標準與技術學會 (National Institutes for Standards and Technology, NIST) 合作，建立了 IDEF0 與 IDEF1X 的標準，並在 1993 年公告為美國政府的處理標準文件 – FIPS (Federal Information Processing Specification)。目前 IDEF 是多種國際組織所接收的標準，如北大西洋公約組織 (North Atlantic Treaty Organization, NATO)，國際貨幣基金 (International Monetary Fund, IMF) 等。IEEE (Institute of Electrical and Electronics Engineers) 也將 IDEF 與其他商用標準整合至規格需求中。國際標準組織(International Organization of Standards, ISO)也計畫將 IDEF 納入標準中。 IDEF 家族方法論不斷的增強、演進，後來有 IDEF4，是物件導向設計方法。IDEF5 到 IDEF14 也分別被定義，試著從更多的觀點來描述複雜的軟體工程，但目前還不具有任何深度。雖然其中某幾項已經有相當的學術研究成果，但是未來的發展前途未卜。表一列出各 IDEF 方法，建立模型的觀點，供大家參考。而本文將僅就已經成熟且廣為接受的 IDEF 0, IDEF 1X, IDEF 3 分別介紹。 |
| IDEF0 | Function Modeling |
| IDEF1 | Information Modeling |
| IDEF1X | Data Modeling |
| IDEF2 | Simulation Model Design |
| IDEF3 | Process Description Capture |
| IDEF4 | Object-Oriented Design |
| IDEF5 | Ontology Description Capture |
| IDEF6 | Design Rational Capture |
| IDEF8 | User Interface Modeling |
| IDEF9 | Scenario-Driven IS Design |
| IDEF10 | Implementation Architecture Modeling |
| IDEF11 | Information Artifact Modeling |
| IDEF12 | Organization Modeling |
| IDEF13 | Three Schema Mapping Design |
| IDEF14 | Network Design |
表 1. IDEF 系列方法論
1.3 IDEF0：程序模型 (process model)
| IDEF0 Model
以圖形或自然語言的方式，來表現作業活動間的互動，以及產生輸出所需要的資源。 |
| 建立 IDEF0 模型，可以記錄企業”目前”到底做些什麼? (AS-IS)。從 AS-IS 模型中，可以進一步讓組織能夠判別並更正沒有輸出、太複雜、高成本、時程過長以及多餘的程序。最後定義出企業”應該”做的事 (TO-BE)。 |
|
|
| 品質控制與改善的基本要件，就是需要不斷的檢視與修正企業中的活動，看看每一項活動是不是”有效” – 做的是對的事情，以及是不是”有效率” – 以對的方法做事。以 IDEF0 做為程序模型，正是在幫助系統開發者檢驗活動的有效方法。 |
| IDEF0
一種具有完備的文件，且已經標準化，以圖形為基礎的程序建模語言。由下列組成:
|
| 圖形結構：幫助分析者提出對的問題，例如：“每一項活動的輸出是什麼？”“這些輸出的價值何在？”，“目前的系統是如何支援這個程序？”等等。
說明文字：讓分析者可以能夠一致而完整的說明所有的程序。 可重複使用的方法：在 IDEF0 中，專案中的每一個人都使用同一套描述企業需求的標準方法。需求支援的設計品質增加。 使用 IDEF0 有下列的好處： 1, 有效而正確的擷取與傳達程序的方法：在 IDEF0 中，活動的名稱，所參考的資源，組成，輸入/輸出資料等都清楚得描述。 2, 提昇使用與解讀的一致性: 專案中的人員因此而有共識。 |
IDEF0 的組成元件
組成元件分成兩個部份: 圖形結構 (Graphic Structures) 與說明文字(Annotative Text)。一、圖形結構:
活動方塊 (Activity Boxes)，箭頭(Arrows)，圖 (Diagrams) 與框架 (Frame)
| 活動 (Activity)
已命名的程序、功能或工作，發生於某一段期間，並產生可辨識的結果。 |
| 在 IDEF0 中，活動以方塊表示，每一個活動必需命名並定義，命名的方式是以”動詞” 加上”名詞”。任一個活動必需要有產出。
相關的有： I = 輸入 (Inputs) : 程序所改變或消耗的資源輸入回答 “what” 的問題 (一項活動產出所需的輸出時，需要什麼?)。如果輸入的是”所觸發的事件” (event trigger)，則輸入也回答了”何時” (when) 的問題。(程序是從何時開始?) C = 控制 (Controls): 程序操作的限制 (必須的) O = 輸出 (Outputs) : 程序所產出的結果輸出回答 “what” 與 “why” 的問題。活動究竟產生了什麼? 而輸出是活動存在的原因，因此回答了 “why” 的問題。 M = 機制 (Mechanisms): 執行、或使得活動開始運作的人、事、物等，但不會消耗掉的。 機制所回答的是“who”與“how”的問題(誰執行這個程序?) 機制定義幫助程序的系統 (例如: 機器)，以及系統是如何支援這個程序。 此外，作業基礎成本 (Activity Based Costing) 的資訊可回答“how much”與“how long”的問題。 |
圖表 (Diagrams)
1) 上下連接圖 (Context Diagram)：定義功能以及其在企業中的關係顯示系統模型的概觀
|
|
| 2) 分解圖 (Decomposition Diagram)：顯示上層圖表的明細描繪出相鄰的活動，一起構成較大活動的細節。 |
|
|
| 3) 節點樹狀圖 (Node Tree Diagram)：描繪工作中每一層次的節點，每一條線表示分解 (decomposition) 的關係。節點樹狀圖提供所有程序的一個概觀，不會因為 ICOMs 的細節而顯的混亂。 |
| 圖表外框 (Diagram Frame)
IDEF0 的外框提供組件 (kit) 以及標題(title) 資料，包括使用處 (Use At)，作者名稱 (Author Name)，新建與修訂日期 (Creation and Revision Dates)，狀態 (status)，讀者與日期 (Reader and Date)，上下關連 (Context)，節點編號 (Node Number)，標題 (Title) 與編號 (Number, C-Number) 等等。 二、說明文字: 一般資訊 (general information) 與詳細資訊 (detail information) 在圖表之外，有許多說明與定義，可以進一步闡述圖表的意義。可分為兩部份，一般資訊與細部資訊。一般資訊說明整個圖表的屬性，而不屬於某一特定活動。包括: 目的 (purpose)：扼要陳述模型存在的原因。 目的說明建立模型的意圖或是溝通的目標，進一步識別模型建立的原因 (例如是為了功能規格或是設製的設計等等)。工作群組參考模型的目的可以讓大家有專注的焦點，以面走偏了方向。例如，在 “AS-IS” 模型中，可以訂下這樣的目的“ 判別與定義目前的問題，並且分析潛在問題。” “TO-BE” 模型則是: “對新的作業方式下定義並取得共識，記錄新增的參與人員與其責任。” 觀點 (Viewpoint): 扼要陳述模型的觀點。 觀點主要是依據模型的主要的使用對象而言，例如是從功能的擁有者 (function owner) 或是領域的專家 (domain expert) 的眼光去看這個模型。所以相同的作業，由不同的觀點來看，就會有不同的動詞。譬如說，從商家的觀點，活動是“賣”一包餅乾；從客戶的觀點，就成為”買”一包餅乾。功能模型必須盡量只是在反應一種觀點，如此才能維持整個模型的一致性。雖然在理想情況下，一個模型最好只包括一個觀點，但在真實世界可能不見得如此。 在建立模型之初，必須決定此模型究竟是以誰的觀點而言。是經理、客戶、品保人員、資訊人員、財務主管、一般職員、還是老闆等等。 範圍 (Scope) : 以文字敘述的方式定義模型在功能上的廣度與深度。 詳細資訊：在 IDEF0 中可以用文字的方式進一步定義額外的資訊，例如程序中所做的假設、計劃的發起人、推動者、期間、改善的建議等等。 |
以下就是以錄影帶租售店為例，所做出的第一層與第二層的 IDEF0 圖表的部份。其中的圖1-6，也表現出外框的資訊。
1.4 IDEF1X 資料模型 (IDEF data model)
IDEF1X 是依據早期 Chen, Codd 的關聯式理論，演變而來。IDEF1X 提供一種結構化的表示方式，說明支援企業作業所需要的資訊以及企業規則。
使用 IDEF1X 這種圖形的方式表達資訊架構的好處是，提昇資訊成為共同的資產可以在企業內共享。另外，它也是提供專業人員與技術人員之間，溝通的橋樑，讓工作群組中的所有成員建立共識，進而建立穩固的資料基礎。
IDEF1X 的組成元件
IDEF1X 主要元件可分為兩部份說明，第一部份包括實體(Entity)、屬性(Attribute)與鍵值 (Key)；另一部份則是關係 (relationship)。
| 實體(Entity)
企業中所存在的資料，例如人、地點、事件或觀念等。 |
實體是具有相同性質的個體的集合，可以對應到資料庫系統的 Table。在 IDEF1X 中通常會對實體下一定義 (Definition) 以便說明實體適用的範圍。
在 IDEF1X 中的實體有兩種，獨立 (Independent) 與相依 ( Dependent) 分別與直角與圓角的方塊表示。
|
|
| 屬性(Attribute)
實體所維護的資料的個別特性。 |
屬性可以說是實體的細部定義。屬性會在實體的方塊中一行一行的列出。屬性可分為兩種，具有鍵值的 (Key) ，會列於實體中的線之上，以及一般屬性 (Non-Key)，列在直線之下。
| 關係(Reationship)
實體之間的邏輯式連接，表達企業規則或限制。 |
關係會將兩個實體以線條連接，實線表示具有辨別性 (Identifying) 的關係，也就是說，父層的主鍵(primary key) 會因為關係的成立，而移轉成為子實體的主鍵。虛線則表示不具有辨別性 (Identifying) 的關係，父層實體的主鍵是移轉到子實體的一般屬性中。IDEF1X 的關係也可表達主從的個數，如一對一，一對多，或一對四等。
另外，實體間階層式的關係，也就是兩個以上的實體若具有共通的屬性，可以將之放在上層實體中，所使用的符號，請參考圖 1-8 中的實體 “Payment” 與 “Check” 以及 “Credit Card” 的關係。這是表示無論是 “Check” 與 “Credit Card” 都具有 “Payment” 的屬性。
下圖是一個 IDEF1X 的範例，延續之前的例子，這張圖描繪出錄影帶租售店可能的資料模型。
圖1-8錄影帶租售店的 IDEF1X 資料模型
1.5 IDEF3 工作流程 (IDEF3 Work Flow)
相對於 IDEF0 是用來建立企業功能模型， IDEF3 工作流程方法論 (work flow methodology) 則是以有順序性的事件來擷取與描述企業的程序。此種彈性的本質讓您建構的模型，不僅只是作業程序，還包含人對此程序的觀察與意見。其它建模技術所不允許的不確定性，在此可以表現出來。
IDEF3 的發展，是因為需要擷取活動以及活動所使用或產生的物件之間的限制—在標準的專案管理模型中所未表現的資訊。
使用 IDEF3 工作流程模型，可以減低為了訓練而需產生的說明，並且可將其重複使用於其他用途上。而只要使用領域專家所提供的系統說明，工作流程的分析者便可以快速的建立程序的圖表、邏輯以及相關性。
工作流程圖可以用來搜集企業中的政策與程序的資訊，無論是已經公佈或尚未公佈的。而這些資訊，可以供應給其他的模型或專案參考，例如系統分析、系統設計、IDEF0 以及模擬系統或專家系統的發展等等。
IDEF3 的符號元件
除了模型中的物件、資源、系統與作業功能之外，工作流程方法讓您可以設定程序的時間順序。程序方塊、交點以及鏈結都是程序流程所支援的特性。
每一個程序會使用腳本 (scenario)，也就是以說故事的方法來描述程序中的事件、動作與決策，以及其中執行、參與或新增、更改或刪除的物件。另外，還要含括說明性的資訊，如事實，程序的限制、決策與物件等。
工作流程的分析的首要工作，就是先識別出所要研究的腳本，並加以命名。命名的是一個重要的步驟，因為它界定了系統或子系統研究的範圍。腳本中所列出的程序與物件，則提供組織化與範圍認定的機制，這些都是定義系統所不能缺少的。
在找出所有的程序之後，便可以開始發展系統的程序流程圖 (process flow diagram)。圖表中的程序是用方塊表示，並具有標題與編號。每一個方塊表示一個事件、決定、動作或程序，通稱為工作單元 (Unit of Work, UOW)。連接方塊的箭頭 (稱為鏈結)，則指出 UOWs 之間的順序與限制。
內有 X, O, 或 & 符號的小方格則是接點 (junction)，表示在作業流程中，一條路徑分為多個路徑 (替代的事件、動作或是程序) 的時點，或是結合多條路徑回到一個的鏈結。接點說明了條件的發生，如 “AND” (&)，”OR” (O)， 以及 “exclusive OR” (X)，並記錄程序中流程邏輯。
在工作流程圖中，還包括指示物 (referents)，他們是沒有編號的方塊，用來標示工作流程中的其他資訊的細節或是相關的 IDEF0 模型。
下圖是一個 IDEF3 的範例，延續之前的例子，這張圖描繪出錄影帶租售店接受付款的工作流程。
IDEF3 中的另一種圖表是物件狀態轉換網路圖 (Object State Transition Network, OSTN)。OSTN 以物件為中心觀點，貫穿流程中的所有可能的狀態轉變。例如在上例中，可以錄影帶的狀態，繪出以下的 OSTN。
2. ARIS
整合性資訊系統架構 (ARchitecture of integrated Information Systems, ARIS) 是由 IDS 公司的 August-Wilhelm Schee 教授所提出的。其設計理念，是希望提出一個整合性的概念，此概念是經由對企業處理程序做一全盤的分析後所取得的。在這樣的架構下所發展的模型，目的是把描述企業程序的所有基本觀念，通通納入。因此，可以想見，這樣的模型一定非常的複雜。為了減少複雜度，必須依不同的觀點來切割這個複雜的模型。就如同 IDEF 一樣，在一種觀點下，無數的交互關係將先被省去，只專注的範圍內的事物。之後，各種觀點的模型在整合成一個完整的分析，而不會有任何的重複。
圖 2-1 ARIS 架構圖
依照這樣的設計理念， ARIS 將整個資訊系統以四個觀點來分析，分別是中心的控制 (Control)、資料 (Data)、功能 (function) 以及組織 (organization)。在每個觀點之下又細分為需求定義(Requirement Definition)、 設計規格 (Design Specification) 與設置說明 (Implementation Description)。
Scheer 教授所領導的 IDS-Scheer 公司依據這樣的架構，設計的軟體工具，稱為 ARIS-Toolset。這套工具整個設計的主軸以 Control View 中的事件導向程序鏈結圖 (extended Event-driven Process Chain Diagram, eEPC ) 為主，其中定義的資料、功能、組織等，再延伸到其他觀點中，選取不同的模型方法，做更細部的定義，也就是說所有圖表中的物件是互通的。
ARIS-Toolset 提供了多達七十幾種的方法論以及一百多種物件，以供使用者以不同的觀點分析複雜的系統。例如：Function View，主要的是 Function tree，另外有 Y diagram, Target diagram, SAP applicationns diagram 等。
Organization View，主要的是 Organizational Chart, 另外有 OAS variant，Cost type diagram 等。
Data，主要的是 eERM (extend Entity Relational Model), 另外有 Technical terms model, IEF data model, Information carrier diagram, SAP SERM, SeDaM Model 等。
Control View，主要的是 eEPC, 另外有 Analyzer rule diagram, Task chain diagram, business controls diagram, Data value decompositon, Dynamic model, Event Diagram, FA diagram, Functional allocation diagram , Class Diagram, Object 等數十種。
ARIS – House of Business Engineering (ARIS-HoBE)
在 ARIS 的基礎下，為了進一步設計企業工程的完整生命週期, IDS 公司進一步提出 ARIS – House of Business Engineering 的架構，支援企業程序的模型建造、評估、控制與執行。ARIS-HoBE 請參考圖 2-2，圍繞著 ARIS 的四個階段分別是程序設計 (Process Design)、程序管理 (Process Management)、程序工作流程 (Process Workflow) 與程序應用程式 (Process Application)。IDS 公司在各階段，也分別推出對應的工具。限於篇幅，不一一詳述，有興趣者可以到文末所列的網站參觀。但其中值得一提的是，在這樣的架構下，IDS 以過去的顧問經驗，建立了許多特定產業或程序的參考模型 (reference model)，例如：
特定產業 (Industry-Specific Reference Models)，包括：
- Mechanical Engineering
- Paper Industry
- Consumer Goods Industry
- Plant Engineering
特定程序模型 (Procedural Models)，包括：
- Process Oriented Implementation of SAP R/3
- Business Process Engineering
- ISO 9000 Certification
- ARIS Workflow Implementation
- Benchmarking
圖 2-2 ARIS-House of Business Engineering
3.物件導向分析與設計 (OOA/OOD)
主從式 (client-server) 的軟體架構已經主導了相當長的一段期間。這種架構不是 “fat clients” 就是 “fat servers”。所謂的 “fat clients” 是指將企業規則 (business rules) 是建立於使用者介面上； “fat servers” 則是建立在資料庫中。由於有大量的資料牽涉在邏輯規則中，使得這些系統很難維護，通常程式也不好寫。另外，這種將企業規則包括其中的處理方法，也使得企業規則無法讓各種應用程式共用。
三階式 (three-tier) 的方法則是由使用者介面，企業規則與資料三個服務模型所組成。也就是說在使用者介面與資料庫的兩層架構之外，多了應用程式伺服器 (application server) ，而企業規則就放在其中。這種架構比起二階式架構，好處是：
- 對任何一個層次所做的改變，對應用程式結構中的其他階層而言，所受到的影響達到最小。
- 更具可調性 (scalable)。所有的階層可以在共同存在一部主機上，若考慮執行效率上的需求，也可以分別存在於不同的主機上。
- 藉由使用共通的程式庫，促進整個企業，使用相同的企業規則。
而這種有彈性的處理方法，也帶來了新的挑戰：
- 系統發展者對於應用程式的切割，有了更多的選擇。
- 可重複使用的企業物件必須更清楚的識別，並且力求精緻。
- 對於每個元件所使用的物件以及元件如何在網路上分配，都必須決定。
- 應用程式必須不斷因應企業需求的改變。
- 必須以群組合作的方式完成這些系統。
- 以軟體元件為基礎 (component-based) 的發展方式，已經改變過去專案開發的本質。
高度的可調變性的軟體開發方式，相對的也增加了複雜度。即使是一個小的系統，往往也牽涉到若干個軟體元件。因此如何管理其中的複雜性，成了開發上的重要步驟。系統的分析設計也就愈顯得重要。一個建全的架構，才能確保發展過程的流暢一致，並且確保在需求改變的時候，程式也能輕易的隨之調整。
目前，在三階架構中，無論是前端的 GUI (如 Visual Basic、 Power Builder，Delphi、或是 API) ，中段的應用程式伺服器 (OLE，CORBA)，甚至是後端的資料庫 (Oracle、Informix 等的 Universal Server)，都是採用物件導向的設計方式，因此 OOA/D 幾乎已是不可避免的。
物件導向的技術發展十多年來，各家學者所提出的分析方法不計其數，雖然各有擅長，但始終缺乏一個完整而統一的標準。這或多或少也阻礙了物件導向技術的接受度。最近，OOA/D 終於有了統合。
1996 年，OOA/D 的知名工具廠商 Rational Software，提出了 UML (Unified Modeling Language)。UML是以 Grady Booch 的 Booch Method，Ivar Jacobson 的 Use Case， 以及 Jim Rumbaugh 的 OMT 的方法為基礎，再參考其他的方法論設計者，軟體供應商以及使用者的意見後所制定的。目前以成為業界公認的標準 (de facto standard)。許多 OOA/D 的分析工具，也在原來的架構上，再支援 UML。Rational 目前已正式將 UML 向 OMG (Object Management Group) 提出申請，預期在不久的將來，就可由 OMG 認可公佈為真正的標準。
目前，UML 提供的應用程式建模語言包括：
-
- 使用 Use Cases 建立企業程序模型
- 建立類別 (Class) 與物件 (Object) 模型
- 建立元件 (Component) 模型
- 建立分散式 (Distribution) 與應用 (Deployment) 模型
各類模型所使用的圖表包括：
- General-Purpose Concepts
- Use-Case Diagram
- Class Diagram
- State-Transition Diagram
- Scenario Diagram
- Component Diagram
- Deployment Diagram
篇幅所限，在此無法一一介紹各種圖表的設計理念，僅列出 General-Purpose Concepts 、 Use-Case Diagram 以及基本的 Class Diagram 供大家參考，有興趣者，請參考文末所列的網站，有詳細的資料說明。
圖 3-1 UML 中 General-Purpose Concepts 與 Use Case Diagram
圖 3-2 UML 中 Class Diagram
4. 結論
IDEF 與 ARIS 與 OOA/D 不過是數百種已經存在的方法論中的幾種。從它們的發展與沿革，可以看出個別在分析方法上所具的代表性。就 IDEF 與 ARIS 而言， ARIS 的範圍是比較廣的，它甚至能將 IDEF 或 OOA/D 的方法納如其中 (事實上，在 ARIS-Toolset 已經有 IDEF0)。但是 IDEF 的工具廠商，也都在其基本的 IDEF 工具外，尋求各種合作的對象 (例如專案管理工具、模擬工具等)，希望擴大版圖，提出一個完整的解決方案。而 OOA/D 則是比較適用於與物件導向應用程式 (如 OO 的 GUI 工具或 OO 程式語言，如 C++, Ada，或 OLE, CORBA 的設計) 的整合，在企業程序工程上，顯得較弱 (基本上是使用 Use Case)。
基本上，這三者都是很好的方法論，也各有擅長，很難絕對的說那個比較好，那個比較差。我們寧願相信彼此是可以互補不足的。事實上，相關的工具廠商，也大多有策略結盟，讓不同的模型，在可能的情況下，有相當的對應與鏈結。而 CALS 的發展者，不妨從其中找出最適合的方法論與工具，作為模型建造的依據。
5. 相關網站
IDEF 的相關網站
ARIS 的相關網站
OOA/D 的相關網站