以物件導向方法設計資料倉儲架構之研究 -以業務銷售作業模型為例

全文

(1)以物件導向方法設計資料倉儲架構之研究 -以業務銷售作業模型為例 Object-Oriented Design for Data Warehouse Data Schema -An Data Model on Sales Operation 孫明照. 蘇偉仁. 蕭榮興. 財團法人資訊工業策進會. 財團法人資訊工業策進會. 財團法人資訊工業策進會. 電子商務技術實驗室. 電子商務技術實驗室. 電子商務技術實驗室. Ming Chao Sun. Wei Jen Su. Jung Hsing Hsiao. [email protected]. [email protected]. [email protected]. 摘. 註：本研究由經濟部委託財團法人資訊工業策進. 要. 資訊對於企業而言是項極重要的資產，若能充. 會網路前瞻應用技術發展四年計畫辦理. 分利用現有資訊於分析決策上，將可為企業帶來更. 關鍵詞：物件導向資料倉儲、流程分析方法、統. 大的競爭優勢。而資料倉儲技術便是從多個異質資. 一化程序(Rational Unified Process)。. 料來源，收集並整合成有效之資訊儲存於資料倉儲. 一、前言. 中，如此才能快速地提供企業決策用分析性資訊。. 隨著產業環機境的快速變遷及資訊科技的進. 在資料倉儲的建立方法上，傳統都是建構在關連式. 步，企業為了因應外在不斷改變的環境，在不同. 資料庫之上，以 Table Join 跟事先計算好. 的時期產生了不同的企業資訊系統，使得企業間的. Aggregation 資料的方式來達到快速提供企業分析. 資訊散落在各種異質平台與資料庫上，導致資料整. 性資訊的特點。. 合不易與無法有效率被利用的缺點。而現今屬於知. 然而建構在傳統關連式資料庫的資料倉儲架. 識經濟的時代，企業面臨激烈的國際化競爭，如何. 構，只能適用於所處環境變動幅度較小的企業，當. 運用資訊科技將大量分散的資料轉變成有用的資. 企業必須面對的是國際性的競爭壓力與快速變動. 訊，並經過儲存及分析後輔助企業做出正確的決. 的環境，傳統的關連式資料倉儲缺乏調整彈性的缺. 策，有效掌的握客戶需求，這樣的議題是目前企業. 點便浮現出來。本篇論文將利用物件導向方法來設. 所面臨最重要的挑戰。. 計資料倉儲架構，並以業務銷售作業為例，提出符. 資料倉儲 (Data Warehouse)的技術，便是在蒐. 合 Domain 需求的物件導向資料倉儲架構。並針對. 集分散各個不同平台、不同儲存媒體的資料，將其. 企業常常面臨到解決問題時，決策資訊無法對應至. 整合成一個大型的資料庫，使企業決策者能快速的. 作業流程的困難點，本論文在以物件導向方法建置. 掌握決策資訊，進而做出正確且及時的決策。. 資料倉儲之前，先對企業做流程分析，再將流程分. 傳統設計資料倉儲的方式，大多採用關連式資. 析的結果作為物件導向方法需求分析的輸入資. 料模式(Relational Data Model)，但隨著資料的呈現. 訊，讓本研究的結果物件導向資料倉儲架構能與企. 不再只侷限於結構化的文字模式，非結構化的資料. 業流程緊密結合。. 模式(如影像、聲音、圖片等等)更是隱藏了大量的 1.

(2) 企業知識。為了解決傳統資料倉儲缺乏應變彈性與. 來在學術研究或產業界，IDEF0 經常被使用去規劃. 處理非結構資料的缺點，本研究提出利用物件導向. 複雜的製造系統之運作功能，以及企業的作業流程. 資料模式(Object-Oriented Data Model)來設計資料. 的一個模式化工具。它是現況分析（AS-IS Model）. 倉儲，增加企業對於外部環境的應變能力，與軟體. 的一項工具，具有圖形表示法、從上而下的分解、. 重複使用(Software Reuse)【Jacobson, I., 1998】的. 易了解、易溝通、功能模式及主題明確的特質。其. 機制。. 主要目的在了解問題本身，而非解決問題的方法，. 企業在透過資料倉儲架構獲取資訊的方法. 也就是說決定解決方法之前，須先針對問題本身提. 上，常常面臨到的一個問題，就是發現資訊不正確. 出清晰完整的分析模式，因此本研究採用 IDEF0. 時，系統往往無法立即反應是哪個作業出了問題，. 方法為流程分析之方法。. 造成危機處理的延遲。為了讓主管決策所需要的資 2.2 物件導向方法物件導向方法是一種反覆的程序，主要包括需. 訊，與作業流程能存在緊密的關係，以協助企業應變與預防錯誤的發生，本研究在建立資料倉儲階段. 求分析、系統分析與設計、實施與測試等階段。. 前，先對企業做流程分析，再將流程分析結果，作. Grady Booch 於 1986 年率先發表物件導向的系統. 為物件導向方法的需求分析來源，擷取出企業的主. 開發方法，開啟了物件導向技術在軟體工程上應用. 要流程與關鍵資訊，讓本研究的結果物件導向資料. 的開始。Rumbaugh 於 1995 年提出了物件模式技. 倉儲架構能與企業流程緊密結合。. 術 (Object Model Technique,OMT) 【 James E.,. 二、文獻探討. 1995】，包含了物件模式(Object Model)、動態模式 (Dynamic Model)與功能模式(Functional Model)等. 2.1 流程分析方法流程細部展開（Decomposition）方法與技術. 三種模型。Jacobson 提出使用個案 USE CASE. 簡化了流程管理，並使作業透明化、權責清楚劃. 【Jacobson, 1995】，用來描述使用者與系統如何互. 分、介面連結關係明朗。要如何展開便需要各種方. 動也就是說將每一個使用者視為一個行動者. 法，而流程分析的方法眾多，有 DFD（Data Flow. (Actor)，當行動者引發系統執行某項任務時，會發. Diagram ）、 IDEF （ Integration DEFinition for. 生一連串與系統有關的處理，將這些處理紀錄下來. Function modeling ）【 Mayer, 1998 】、 ARIS. 即成為「使用個案」。Coad&Yourdon 認為物件導. (Architecture of Integrated Information System)整合. 向分析技術主要包括五個主要的分析步驟，分別是. 性資訊系統架構【Scheer, 2000】、Petri Nets 斐氏網. 定義主題、確認物件、確認結構、定義屬性、定義. 系統模式法【Murata, 1989】、CIM-OSA(CIM Open. 服務等【Coad, 1989】。直到 1998 年，Booch、. System Architecture)【Joryze, 1990】、GRAI Method. Rumbaugh、Jacobson 等三位物件導向大師，整合. 【 Chaudhuri, 1996 】、 OOMIS (Object-Oriented modeling. methodology. for. 了各自特色，提出統一化程序(Rational Unified. Manufacturing. Process，RUP)【Rational Corp., 1998】，讓物件導. Information System)製造資訊系統物件導向塑模技. 向軟體工程方法進入了整合的新世紀。. 術等。流程分析方法中由於 IDEF0 方法涵蓋了功能. 2.2.1 統一化程序(Rational Unified Process) 統一化程序是一個軟體發展的方法，而一個軟. 面、行為面、組織面、資訊面四種構面的特性，是. 體發展的方法就是將使用者的需求轉換成軟體系. 一種可以充分表達作業流程特性的模式方法。近年. 統的一系列活動。統一化程序是一個元件導向的方 2.

(3) 法，利用軟體元件來建立系統，透過良好定義的介. 互作用，而系統範圍的定義也經由使用者案例圖的. 面來互相溝通【 Booch, Jacobson, Rumbaugh,. 建立而明朗化。在這個階段的產物有 Use-Case. 1998】，使用元件基礎的系統架構提供了一些軟體. Model（完成整個系統使用者案例的 10%~20%）、. 開發時會面臨到發展問題的解決方案【Kruchten,. 企業案例、危機評估、和專案的規劃。. 1999】：元件的採用增加了系統架構的彈性。模組化將系統分成一些定義清楚的元素，並且容易維護。重複使用的特性可藉由一些標準元件架構的採用而獲得更大的效益。元件提供了一個簡單的組構管理環境。視覺化的塑模工具提供了自動化的元件圖 2-1 統一化程序架構圖資料來源：【Booch, Jacobson, Rumbaugh, 1998】. 發展。統一化程序是以使用者案例為驅動因子. 2.3 資料倉儲資料倉儲的定義是由資料倉儲之父 Inmon,. （ Use-Case Driven ），並以軟體架構為中心（Architecture-Centric），同時也是循環式及漸進式. W.H.所提出【Inmon, W.H., 1992】，在此節中將詳. （ Iterative and Incremental ）的軟體發展程序. 細說明其理論重點。此節共分為兩小節，在第 2.3.1. 【Kruchten, 1999】。它的發展流程分成兩個維度，. 小節中說明資料倉儲的定義，在第 2.3.2 小節中說. 一個是時間，另一個是核心工作流程元件，如圖. 明多維度資料模型。. 2-1 所示。在時間方面，分成了四個生命週期（lifecycle），Inception、Elaboration、Construction、. 2.3.1 資料倉儲的定義資料倉儲的建立的主要目的在於資料除垢. Transition ，每個週期結束都會有一個里程碑. (Data Cleaning)與資料整合(Data Integration)，此正. （milestone），用來評估每個週期結果的正確性。. 為線上分析處理、資料分析與資料挖掘的前置工. 一個生命週期包含了六個流程元件， Business. 作，若不經由資料倉儲，則會造成不同時間點分析. Modeling、Re- quirements、Analysis and Design、. 結果不相同的窘境。何謂資料倉儲呢？資料倉儲之. Implementation、Test、Deployment。四個生命週期. 父 Inmon, W.H.對於建構資料倉儲所下的四個定義. 便是四個循環（cycle），每個循環中都必須經歷六. 【 Inmon, W.H., 1992 】：資料倉儲具有主題性. 種工作流程，以這種循環且漸進式的發展來組合起. (Subject-oriented) 、時變性(Time-variant)、整合性. 兩個維度的相互關係。. (Integrated)與永存性(Non-volatile)四大特色。. 四個生命週期中，Inception 稱為初始階段，. 資料倉儲的出現並非取代傳統關聯式資料庫. 這個階段的主要目的必須建立系統的企業案例. 的地位，而是在其基礎上進行資料的加值處理，其. （Business case），跟確定系統範圍。企業案例包. 運作方式為，先將儲存於企業內、外部的異質資料. 含了成功準則、危機評估、資源需求的評估、和階. 庫進行粹取、轉換、壓縮及載入，並放置在資料倉. 段計劃完成時間。另外，初始使用者案例的建立，. 儲中，並透過線上分析處理機制，能夠快速地對資. 用來記錄使用者需求和系統功能與外部環境之交. 料進行分析、查詢、報表，也可在資料倉儲上進行 3.

(4) 管抱怨資訊不足的狀況。. 資料挖掘等決策分析功能，因此資料倉儲與資料庫. 本研究提出了物件導向資料倉儲架構，透過對. 系統是相輔相成的，並非背道而馳。 2.3.2 多維度資料模型多維度資料模型 (Multidimensional Data. 企業的流程分析，尋找出企業營運的關鍵流程與資訊，再以這些需求為基礎，利用物件導向方法. Model)，主要是由多個維度及衡量值(measures)所. RUP(Rational Unified Process)【Booch, Jacobson,. 構成，其物理意義為分析人員利用哪幾個面向來觀. and Rumbaugh, 1998】進行資料倉儲架構的設計，. 察此衡量值。就維度而言，各維度由多個資料庫中. 如圖 3-1 所示，歸納流程分析所產出的結果，將關. 多個欄位屬性所組成，各維度皆有層級關係，如時. 鍵流程與資訊作為物件導向方法的需求分析輸入. 間維度其層級為年>季>月>日；就衡量值而言，視. 資訊，並於 Use-Case Model 中建立 Use-Case. 研究主題而定，可為銷售量、交易量等。若以多維. Diagram。接著將歸納每個 Use Case 中有哪些類. 度資料庫(Multidimensional Database)而言，則可直. 別，於 Design Model 中建立 Class Diagram，表示. 接實作，但是，若以關聯式資料庫 (Relational. 這些類別的靜態關係，與每個類別所擁有的資訊，. Database)而言，要如何達到多維度的效果呢？其. 而這些資訊來源也將參考流程分析過程中，所產出. 設計方式是以先決定分析的主題，依據此主題來設. 的關鍵資訊，才能完整呈現使用者的資訊需求。最. 計事物表中的衡量值，並依據決策人員欲採用的分. 後，在 Implementation Model 中會將所有類別依照. 析面向，如時間、產品及地點等，根據此來設計維. 功能性與相關性，封裝成不同的元件，並於. 度資料表(Dimension Table)，最後以事物表為中. Component Diagram 中表示物件導向資料倉儲架. 心，以各維度資料表中的主鍵(Primary Key)與事物. 構結果。. 表建立關聯。類似此種多維度模型分為星狀綱要 (Star Schema)、雪花綱要(Snowflake Schema)對星狀綱要而言，其中間是事物表(Fact 資料表)，而周圍則稱為維度表(Dimension 資料表)，此種表達法具有三階正規化的精神，而雪花綱要則是把星狀綱再做進一步的三階正規化。. 三、物件導向資料倉儲設計方法企業的運作瞬息萬變，主管如何掌握企業最新的狀況，來支援正確決策的製定，已是主管所面臨. 四、物件導向資料倉儲模塑過程. 的一大挑戰。如今，隨著商業智慧軟體的成熟發. 依照 RUP 所規範的標準程序，在不同的發展. 展，許多企業可以直接購買現成的商業智慧套裝軟. 階段中將陸續建立六種不同的 Model，而這六種. 體，來滿足主管決策時的報表需求；不過即使如. Model 對應至 UML 表示時，本研究將採用三個觀. 此，商業智慧軟體功能的需求，已不再是主管重要. 點的呈現分析的結果，即為 Use-Case View、Logical. 的訴求了，可以快速且正確的製作出需要的報表，. View 與 Component View，這三種角度包含了 RUP. 才是左右主管決策的關鍵因素。如何確保資料倉儲. 六種 Model 的呈現。. 的 Data Schema 已經涵蓋了所有主管的需求，避免. 4.1 Use-Case View Use-Case View 所要呈現的是業務銷售作業的. 最後連 Cube 都設計好了後，卻接二連三的發生主 4.

(5) 作業流程. 資訊採購訂單數量採購發票數量產能規劃作業預測量銷售訂單數量砍單數量工單數量產能物料限制量外包廠延伸產能測試製具產能物料需求規劃每週預測量採購需求量採購訂單原料料況原料採購週期庫存量銷售訂單數量工單數量工廠作業成品數量半成品數量砍單後產品數量出貨作業客戶付款紀錄出貨單出貨數量採購發票提貨單 Use Case Diagram 呈現了業務銷售作業的使. Use Case Diagram，用來描述企業於業務銷售作業的相關作業與參與作業的人員，本研究 Use Case Diagram 需求的來源，將於流程分析結果中，歸納出業務銷售作業從接單到出貨的相關作業流程與資訊，最後呈現於 Use-Case View，以作為物件導向資料倉儲架構的建立依據。. 圖 4-1 業務作業 IDEF0 流程分析圖以業務銷售作業為例，將歸納流程分析結果，如圖 4-1 所示，提供本研究完成銷售作業所需要的主要流程與資訊，以列表方式歸納出來，如表 4-1. 用案例，如圖 4-1 所示，其中包含了客戶、業務、. 所示，列出所有業務銷售作業的主要流程與資訊，. 產品經理、生管與物控等角色；銷售作業、預測作. 作為 Use Case 的推導參考，與類別中 Attribute 建. 業、客戶需求確認、接單作業與產銷協調會議等使. 立的依據。. 用案例。這些作業活動在流程分析中是屬於業務銷表 4-1 業務銷售作業關鍵流程與資訊作業流程資訊銷售作業產品 Bottom Price BOM 總成本客戶報價預測作業長期預測量短期預測量年度銷售目標客戶需求確認客戶短期需求量產銷協調會議分配量生產產能製造產能原料料況半成品數量接單作業維修料件分配量加單需求量砍單需求量銷售訂單數量. 售作業主要的流程作業，每個作業下都還有許多子作業來描述作業的流程，因此，圖 4-2 是以銷售作業為例，呈現了的主要的使用案例，每個 Use Case 將會依照作業的複雜度，往下設計出相對應的 Use-Case Diagram。. 5.

(6) 預測作業、客戶需求確認、產銷協調會議與接單作業等等，以接單作業為例，接單作業主要在處理業務接到客戶所下的訂單，流程上業務需要在規定的時間內與客戶確認購買發票是否正確，再製作銷售訂單交給生產製造單位，進行產品的生產作業。因此，在這樣的情境下，可以歸納出客戶購買發票、銷售訂單、產品、時間等物件，因為購買發票與銷售訂單所紀錄的內容為產品編號、價格、日期與購買數量，可將其歸納出產品類別與時間類別，其中產品類別具有產品編號、產品價格與產品數量等資訊。 4.2.2 定義類別 Attribute 類別的 Attribute 可以從流程分析中的資訊取. 圖 4-2 業務銷售作業使用案例圖. 得，歸納表 4-1 業務銷售作業的資訊，可獲得產品. 4.2 Logical View Logical View 所要呈現的是業務銷售作業的. Bottom Price、BOM 總成本、客戶報價、長期預測. 類別圖，如圖 4-3 所示，於業務銷售作業中的使用. 量、短期預測量、年度銷售目標、客戶短期需求量、. 案例去思考，需要哪些類別來完成業務銷售作業，. 分配量、半成品數量、維修料件分配量、加單需求. 將存在於使用案例中的類別逐一定義出來，最後再. 量、砍單需求量、銷售訂單數量、採購訂單數量、. 以類別圖來呈現類別間的靜態關係。因此，想要從. 採購發票數量、預測量、砍單數量、工單數量等資. 由上一小節的 Use-Case Diagram 推導出 Class. 訊。以上這些資訊可定義為銷售類別所需要的. Diagram 時，應該經過下列兩個步驟，分別為步驟. Attribute，而其它輔助觀看銷售類別的維度類別. 一：從 Use Case 中定義出類別，與步驟二：從 Use. Attribute 也可以從這些資訊中得到，以產品類別為. Case 中定義出類別的 Attribute，即將來資料倉儲. 例，客戶所下的銷售訂單是針對產品的 Model 編. 的維度資訊。詳述於 4.2.1 定義類別與 4.2.2 定義類. 號，而產品經理分配的各業務員的分配量資訊，是. 別 Attribute 小節。. 針對產品的系列編號分類的，因此，針對產品類別. 4.2.1 定義類別類別是將擁有類似特性的物件抽象化而來. 的 Attribute 而言，可歸納出產品大類、產品中類、產品系列與產品 Model 等四個 Attribute。遵循上述. 的，因此在歸納 Use Case 中有哪些類別之前，必. 做法，從流程分析中的流程與資訊，對應至使用案. 須先了解有哪些物件共同來完成一個 Use Case 的. 例與類別，以銷售作業為例，下面為銷售作業的類. 需求，再將這些物件抽象化成我們所需要的類別。. 別圖。. 以圖 4-2 的業務銷售作業使用案例圖為例，可從行. 圖 4-3 中歸納了 Customer、Employee、PM、. 為者(Actor)與使用案例(Use Case)分別去歸納，行. Sales、Time、Product、Item 與 Sales Fact 等類別，. 為者部分，可以歸納出客戶、業務、產品經理、生. 其中除了 Sales Fact 以外，均繼承於 Dimension 類. 管與物控等人員，而這些人員也就是操作這些使用. 別，PM 與 Sales 繼承於 Employee 類別；Sales Fact. 案例的物件，抽象化後可以得到兩個類別，即客戶. 類別是用來表示業務銷售作業所需呈現的資訊，並. 類別與企業員工類別；使用案例部分有銷售作業、 6.

(7) 透過與其它維度的關係，定義出可由不同維度觀看. 負責呈現報表內容，DimensionList 負責呈現維度. 業務銷售作業資訊的各種情境。其它的類別如. 資訊，他們會接收由 Model Layer 元件所傳遞過來. Customer、Sales、Time 與 Product，是用來表示於. 的結果，將報表呈現於用戶端； Sales Fact 、. 業務銷售作業中所需要分析的各種不同的角度，其. Dimension 與 DataModel 屬於負責處理產生報表的. 中 Product 類別是由 Item 類別所聚合而產生的，因. 元件，其中 Sales Fact 繼承於 ReportWindows，負. 為在業務銷售作業中，產品是由許多原料所組成. 責產生報表想要呈現的資訊內容，Dimension 繼承. 的。. 於 DimensionList，負責產生報表想要呈現的維度. 在整個完整的業務銷售作業中，除了 Sales. 資訊。DataModel 是產生報表的核心機制，負責產. Fact 類別外，還需要加入 Inventory Fact、Shipping. 生查詢報表的查詢句，並轉換成 XML 語法，再透. Fact、Promotion Fact 等類別，以完成的呈現業務. 過 XSL 的套用產生完整的報表資訊，最後將資訊. 銷售作業所需要管理的資訊，在 Dimension 類別方. 傳遞給 Viwer 元件，負責展現報表內容。Controller. 面也會增加 Hub、Warehouse、Shipping Type、Sales. Layer 的元件為 DataAccess，負責與後端資料庫聯. Type、Order Type 與 Promotion 等分析資訊的角. 繫，提供 Model Layer 元件與資料庫端的異動交. 度。在此，本研究只提出與銷售相關的資訊與維度. 易，因此 Sales Fact 與 Dimension 元件在處理過程. 作為範例，說明物件導向資料倉儲架構建立的過. 中，都會與 DataAccess 元件保持互動，以支援. 程。. DataModel 元件完成產生報表的任務。. 圖 4-3 業務銷售作業類別圖 4.3 Component View Component View 將以元件的角度來呈現系統 Implementation 時的架構，本研究採用 MVC(Model、View、Controller)的概念將元件分成三個部分，如圖 4-4 所示， Viewer 是由. 圖 4-4 業務銷售作業元件架構圖. ReportWindows 與 DimensionList 所組成，屬於負責呈現資訊 View Layer 的元件，ReportWindows 7.

(8) 7.. 五、結論. 8.. 資料倉儲對於資訊的整合與應用是很重要的技術，為了能快速且彈性的提供企業分析性資訊，. 9.. 資料倉儲架構的設計方法是個極重要的研究問題，之前絕大多數這方面的研究都著重於關連式資料庫中建立 Start Schema 架構的探討，但隨著物件. 10.. 導向技術在資料庫上的應用日趨成熟，使得在物件 11.. 導向概念下建構資料倉儲的研究也日益受到重視。因此本研究提出以物件導向方法設計資料倉. 12.. 儲，並以業務銷售作業為例，探討從流程分析所得到的結果，如何利用物件導向方法 RUP 來設計資. 13.. 料倉儲的研究。以解決傳統關連式資料模式下，資料倉儲架構缺乏彈性與無法分析非結構資料的問. 14.. 題。. 15.. 在本研究中，我們提出了一個適用於業務銷售作業的物件導向資料倉儲架構，運用了物件可獨立. 16.. 運作與繼承的特點，提供了企業面對外部環境快去變動的趨勢下，所必須因應的彈性調整資料倉儲架構需求，讓企業能迅速的得到分析性資訊，掌握客. 17.. 戶需求。 18.. 參考文獻 1.. 2.. 3.. 4.. 5.. 6.. A.H. Filho, H.A. Prado, S.S. Toscani, “Evolving a Legacy Data Warehouse System to an Object-Oriented Architecture,” International Conference of the Chilean Computer Science Society (SCCC'00) November 16 - 18, 2000 Santiago,Chile, p. 32. Booch, G., Jacobson, I. and Rumbaugh, J. “The Unified Software Development Process,” Addison-Wesley, 1998. Booch, G. et al.: The Unified Modeling Language for Object-Oriented Development, Documentation Set, Version 1.0, Rational Software Corporation, 1997. Chaudhuri, S. and Dayal, U., “An Overview of Data Warehousing and OLAP Technology”, SIGMOD Record, Vol.26, No. 1, 1997. Chen, D. and Doumeingts, G., "The GRAI-GIM reference model, architecture and methodology ", Architectures for Enterprise Integration, 1996. Elmasri, R. and Navathe, S.B., Fundamentals of Database Systems, Addition-Wesley, 2000. 8. Inmon, W.H., Building the Data Warehouse, Addition-Wesley, 1992. Jacobson, I. : Software Reuse – Architecture, Process and Organization for Business Success, Addisn-Wesley, New York, N. Y., 1998. Joryze, H. R. and Verradat, F. B., 1990 , “ CIM-OSA Part 1:total enterprise modeling and function view , ” Int. J. Computer Integrated Manufacturing,Vol.3 Nos.3 and 4,pp.144-156. Kruchten, P.B., “The Rational Unified Process an Introduction,” Addison-Wesley, 1999. Rational Software Corporation, “Rational Unified Process Best Practices for Software Development Teams,” 1998. Rational Software Corporation, “The Ten Essentials of RUP The Essence of an Effective Development Process,” 2000. Rational Software Corporation, “Rational Unified Process for Systems Engineering,” 2000. James E. Rumbaugh: OMT: The Object Model. JOOP 7(8): 21-27 (1995) Jacobson, I. (1995) “The Use-Case Construct in Object-Oriented Software Engineering.” In J. M. Carroll (ed.) Scenario-Based Design. NY: Wiley. Mayer, R. J., Benjamin, P. C., Carawaz, B. E. and Painter, M. K., “A Framework and a Suite of Methods for Business Process Reengineering”, 1998, available at http://www.idef.com/articles/framework/. Murata, T., “Petri Nets: Properties, Analysis and Application,”Proceedings of IEEE, Vol. 77, No. 4, pp. 541-580, 1989. Scheer, A. W., ARIS – Business Process Modelling. Third Edition, Springer-Verlag. Berlin, 2000..

(9)