用OOA/OOD方法描述企業經營模型

摘　要　
介紹用OOA/OOD的方法進行企業信息系統分析和建模的基本步驟和一般應注意的問題，涉及系統分析和設計階段。

---- 關鍵詞　OOA　OOD　步驟　企業信息系統

---- 企業管理信息數據庫應用系統實際上是基于企業經營模型的計算機信息處理系統，因而分析和構造企業經營模型是企業信息化的早期活動，這種活動必然影響將來的信息化進程和信息系統效益。實質上，在企業信息系統應用中，面向對象的系統分析和設計就是用面向對象的分析和設計語言，用管理工程的邏輯，描述企業的理想的經營模型，并為系統實現提供工程藍圖。

----密切結合現代管理工程技術，對企業進行再工程或企業重構（Business Process Redesign/ Reengineering），是分析階段的重要任務。管理工程技術和信息技術的結合程度，對系統性能、項目的長期效益的影響很大。信息技術人員在分析階段的主要任務則包括描述對象，建立基于類和對象的系統模型。

----本文討論采用面向對象技術描述企業經營模型的基本程序和思路，涉及分析和設計的初始階段，希望在企業信息化工程領域里起拋磚引玉的作用。

一、在企業應用中面向對象系統分析應該達到的目的

----采用OOA/D方法，通常希望建立一套可復用的、易于維護和可擴展的系統結構。企業信息系統應用中，OOA/D實際上是描述企業的經營模型。

----筆者認為OOA/D首先應該滿足能為要求在有限期限內完成的項目提供系統設計指導的目的，其次還應該滿足輔助企業制定遠期發展規劃的需要，且便于系統的升級改造。這是一個說來容易實際上很難的題目，采用OOA/D是較好的解決方案。應該期望，由于面向對象技術的封裝性，能使得由于企業局部的業務信息流程的較小變化而進行模型修改相對容易，使程序員工作局限在較小范圍內，不至于影響整個系統，從而幫助保證系統的魯棒性。由于面向對象技術的繼承性特點，當企業發展或業務流程發生較大改變時，通過對已有的類的繼承和重用，能快速完成信息系統的升級改造。

二、面向對象的系統分析和設計的基本步驟

----1�贝_定問題域和系統責任

----確定系統邊界、問題域和系統責任是系統分析和系統建模的出發點。就企業應用而言，問題域就集中在諸如財務、辦公、質量控制、生產計劃和控制、銷售服務、人力資源管理、材料供應管理等方面。分析階段應該全面、統一分析問題各方面，以便定位和限定即將著手實施的項目的問題域和確定系統責任以及各域之間的信息關系。

----應該注意到一個經常發生的情況：在軟件開發完成后，使用者發現原來提出的需求都滿足了，但他的問題卻沒有得到很好解決。所以，分析問題域一定要以問題為核心，而不是羅列用戶所描述的需求。這里，管理工程學及相關業務知識是極為有用的�？上�，許多企業的信息化工作并沒有業務主管的實質性參與，有的企業沒有信息主管，許多正在進行信息化建設的企業并沒有為項目配備對企業業務很熟悉的、能力較強的管理工程專家組。所以分析員面臨學習多種知識的艱難局面。借鑒相同或相似系統是很有幫助的。

----2�贝_定待分析的對象

----即準備建立類圖的對象層。企業里通常設立了若干崗位、部門，也有若干報表，應仔細研究這些元素。企業應用系統的對象通常包括：人員、組織、原料、資產、事務、表格、文件、產品等對象。開始時應該保證沒有遺漏地列出所有可能的對象，而接下來的篩選過程就要作到嚴密把關，保證沒有留下無用的對象。這樣分兩階段確定對象可以使得各步工作相對簡化。

----一些企業采用發調查表、收集各種業務表格等形式發現對象，我們認為，這樣做是必要的，但應防止面向對象的分析變成“面向表格”。且有些表格其實是一些基本表格信息的演算、匯總結果，比如生產月報就是各車間班組或各品種的批生產記錄的匯總，也即是產品信息、車間信息、計劃信息的演算結果，從面向對象地角度看，這些信息又是企業某些角色的屬性或消息。

----3�睔w納現實對象，抽象為類

----將有相同屬性和服務的對象抽象為同一個類，就得到系統的類的列表。在企業應用中，往往最初發現的對象很多�？梢圆捎脛澐种黝}的方法將同主題的類歸納在一起。主題是一個比類的粒度更大的概念。比如一個辦公事務管理系統，就可以有：文件處理、要事安排、檔案管理、會議安排等主題。在會議安排這個主題里，可以放進諸如會議類、（與會）單位類、職員類，而職員類可能也是在其他主題內，即主題交叉。一般對于較為復雜的系統采用先建立主題圖再填充類的自頂向下方式。包含較多類和對象的主題可以再劃分，即主題嵌套。

----4�痹O計類、建立類層次結構

----當包含類的主題圖基本完成后，主要的精力就集中在列出類屬性、服務、消息等項目上，即設計類圖的特征層。然后分析類圖的結構，包括一般 － 特殊關系和整體 － 部分關系。

----由于多數情況下數據庫平臺是RDB，而RDB和OOD的成果之間的映射關系并不簡明，在對象—關系數據庫技術以及相應的CASE工具真正成熟以前，過于復雜的對象系統設計都會使后面的實現工作難度加大。Dulcian的Dorsey說，目前對象/關系技術仍有許多工作要做。“它是一個復雜的事物——不是孩子玩耍的地方”。他估計還需要5到10年才能使這種數據庫技術適應普通用戶。所以，OOD時應該顧及到實現時的限制，并采用實體主導性而不是屬性主導性的設計策略。

----圖1顯示類的一種表示。屬性和服務項前的＋、＃、－符號分別代表public、protect、private，即可視性，是為滿足封裝性要求而設。類標識前的@符號表示主動對象。這個物資類具有自動根據過低儲量報警功能，和自動請求質檢的功能。采用不同的標準和CASE工具，表示方法有所不同，應該參照所采用的CASE工具的說明。

三、用面向對象技術描述企業模型應該注意的問題

----OOD詳細設計階段應該注意屬性、消息和服務的如下特性和問題：

----1）是類屬性（所有同類對象的共同特征）還是實例屬性？

----2）該屬性對實例是常數性的還是參數性的？在物資類的一個實例中，編碼等是常數，而倉位、儲量等是參數。常數在實例構造時確定，而參數在實例構造時最多可以有缺省值，在系統運行時可以被改變。

----3）服務是主動還是被動的？若業務規則決定對所有預定代碼的物資必須進行質檢，則自動請求質檢服務就也可能是主動服務。而系統如果要求質檢請求經過庫房管理用戶發出，則物資類的“請求質檢”服務就是被動服務了。

----4）是對內還是對外服務？對內服務是對實例本身的屬性的操作，對外服務是對其他實例或系統發出消息或操作其他類實例的屬性。

----5）消息的分析對OOA的企業經營模型有特別意義，因為消息是對象間動態關系的要素，也是信息隱蔽的重要手段。在順序系統中，消息是向其他對象或系統發出的服務請求，在并行系統中消息表述為對象之間在一次交互中所傳遞的信息。在C/S結構的系統中，客戶端向服務器請求數據屬于并行的線程之間的消息，而在單機數據庫系統中的用戶請求數據，則一般是順序執行的線程內的消息。接受消息的對象是什么？請求的是什么服務？消息發送者是否要與接收者同步？消息是定向的還是廣播的？接收消息者如何處理消息？發送者如何對待消息處理的結果？發出消息的條件是什么？消息是在線程之間還是線程內部傳遞？

----6）屬性、服務的性質是公共的、保護的還是私有的？這些特性的設置對封裝性能影響很大，應該考慮全面和一致。應用面向對象的分析、設計方法時還要求考慮類、對象之間的關系和聯系。類和對象間有：整體 － 部分，一般 － 特殊關系，以及實例連接、消息連接等聯系。屬于類圖的結構性設計范疇。我們抽提了某出版社管理系統編排子系統類圖的部分以示意整體－部分和一般－特殊關系（圖4）。

----多元連接使系統分析和設計復雜�？梢圆捎迷黾宇惖姆椒ń鉀Q。 例如出版計劃－ （編輯）－圖書這樣的三元關聯的語意為某編輯在某出版計劃中負責某圖書（圖2），增加圖書項目組成員類，如圖3所示。

----擴充的OOA模型包括use case 和交互圖，它們是在類圖基本完成的基礎上建立的。對企業信息系統應用而言，use case就是一個用戶或一個活動者與系統進行交互的一個過程的描述，是一個用類似自然語言的語言或偽代碼表述的語序，近似于功能模塊描述，包含與系統責任有關的企業經營規則描述的信息化版本。use case所指的一個交互過程應該是原子過程。而活動者就是指系統外與系統交互作用的事物，活動者可能不是類圖中的類、對象。在出版社系統中，"編輯"作為人員不是待實現的對象，而是要和系統進行交互的一種事物�？傊�，活動者是要與系統交互的事物，而其本身不是系統成分，即使可能有與活動者同名的類在類圖中。

----附于類圖的一個重要文檔是詳細說明，它包含了屬性、服務、消息、聯系等成分的準確語意。

---- OOA/D建立企業經營模型只是OOSE的初始環節。當上述文檔完成后，還要進行物理設計、原型設計、獲取反饋、修改設計等。輕視分析、設計和文檔，偏重代碼和實現，是我國企業信息技術人員的共同問題。而要讓企業信息化可持續地發展，必須重視分析和設計以及文檔。