兩段式OOAD開發大型3- tier系統

 
圖1、兩段式OOAD

為了讓資訊人員能輕松愉快地開發出令人贊美的軟體系統，我們宜采用兩段式的OOAD方式。如此，資訊人員的「做得流汗但被人嫌得流涎」辛酸，將成為昨日的記憶！

所謂兩段式OOAD，其第１階段是：先以OOAD技術分析企業的流程，然后第2階段是：以OOAD技術分析資訊系統的流程。

其將企業(business)與其軟體(software)視為一個整體的系統，而企業與軟體便成為該系統的兩個層面(facet)罷了。這樣，資訊系統便能有效地支持企業來創造出更佳的企業流程(business process)，由更好的流程來提供給顧客更滿意的服務。

本文就以簡單的實例來說明整個開發過程。

基本觀念



在1980年代, 北美地區的公司總共投入了超過一兆(trillion)美金，于資訊系統上。但在該期間，企業的服務效率平均只增加1%而已[Tay95]。 商業周刊(Business Week)經過調查與分析之后指出：資訊系統能有效支持企業創造更佳的企業流程(business process)，由更好的流程來提供顧客更貼心的服務。若只針對舊有流程而加以自動化，通常無法顯著提升服務品質！

那么，如何利用資訊系統來改善企業流程呢？最有效的方式是：以相同的思維來組織企業與資訊系統，將企業(business)與背后的軟體(software)視為一個整合的系統，于是企業與軟體只是該系統的兩個層面(facet)而已。舉世著名的軟體專家Taylor[Tay95]稱這種方式為「聚合式工程」(convergent engineering)。Taylor在該書中說到：

‘Convergent engineering, as defined in this book, offers a new opportunity to create more flexible, adaptive business systems by combing business and software engineering into a single, integrated discipline.’ 

(本書所提出的聚合式工程，將企業與軟體工程結合為一致的設計及建構方式，如此能讓我們創造出更具有彈性、更能適應環境變化的企業。)

Taylor又說到：

‘The output of convergent engineering is an object-oriented business model that represents both organization and its supporting software.’

(聚合式工程將產出一個物件導向的模式，此模式既表達企業本身又表達企業背后的軟體系統。)



他說明了這種途徑的好處如下：

l能簡化設計與建造的過程(simplify the engineering process)，畢其功于一役。

l消除企業流程與軟體的鴻溝(eliminates the gaps between business process and supporting software)，兩者皆易于設計與理解。

l更能隨環境而改變(facilitates change)，企業與軟體能同步修正，使兩者皆生生不息。



讓我們再來看看另一位軟體專家 Jacobson[Jac97]的見解吧！ 他說到： 

‘The models developed in a business engineering program are an excellent starting point to define architectures, find reusable components, and develop application systems that add value for the customers.’

（進行企業工程時所產出的模式，可做為定義軟體架構、找出可重復使用的元件、以及開發應用程式來服務顧客等工作的絕佳基礎。） 



進行企業工程而得到的企業模式，能順利地導出軟體系統的模式，兩者的建構理念是一致的。由于企業模式與軟體模式是基于一致的理念，使得企業模式所表達的企業系統，于軟體模式所表達的軟體系統，成為一體的兩面。

Jacobson又說到：



‘The models should be based on objects because then you get a very close mapping between real objects like people, places, and things and objects in the information systems.’

（企業工程產出的模式必須是物件導向的，因而您可將真實世界里的物件如人、地方、及事物等，幾乎能一對一密切對應到資訊系統里的物件。）

所以必須建立企業的物件模式，再順利導出軟體系統的物件模式。在物件模式里，會以Use Case來表達流程，當然也就由企業的use case (business use case) 來導出資訊系統的use case (system use case)。 Jacobson在其書[Jac97]中提出建議：

‘Using object-oriented business engineering as input, it is a straightforward process to identify the information system models.’

（以物件導向的企業工程所產出的模式為基礎，來導出資訊系統的模式，是個極直截了當的途徑。）



他以圖示說明導出的步驟，如下圖2所示。其詳細步驟如下：

1. 會使用到資訊系統的worker，就成為資訊系統的actor。

2. 若有些企業actor會用到資訊系統，它們也成為資訊系統的actor。

3. 對每一條企業use case，察看該use case的actor及各worker，若它們會成為系統actor，就為它們個別建立一個系統use case。意謂著：每一個企業use case將由數個系統use case來支持；也就是說, 每一個企業use case可能會導出數個系統use case。

4. 企業模式里的entity object，代表worker所必須用到的重要事物，這些重要事物常必須長期記錄與保管，所以它們也成為資訊系統的entity object。


圖2、從企業模式導出系統模式[Jac97]

以上是兩段式OOAD的基礎理念。若應用于Microsoft NT平臺上的3-tier系統開發，其各項工作就如下圖3所示，此即是本文所稱的兩段式OOAD開發方式。






圖3、兩段式OOAD方式的各階段任務

簡單的實作范例

剛才已介紹了兩段式OOAD開發方式的基本觀念。皆下來，為了讓您更熟悉這種開發程序，于此就以銀行外匯資訊系統為例，逐步說明之。

第１階段OOAD



▲ 確定系統領域(domain)



外匯服務是一般商業銀行的重要業務。在服務的過程中除了顧客之外﹐常需要跟國外銀行、中央銀行或該銀行總管理部的支援協助﹐才能給予顧客流暢的服務，如圖4。

圖4、Domain──銀行外匯業務



▲ 找出企業流程

──以use case描述之

首先要從客戶來銀行的目的(goal)或期望(expectation)來找出銀行的企業流程�？蛻魰�要求銀行提供各式各樣的外匯服務﹐例如：出口托收、出口押匯、國外轉帳等等。 依據這些目的﹐可找出銀行的主要流程，然后拿UML 的use case模式表示如圖5。


圖5、銀行外匯業務的企業流程



每個use case表達一條企業流程�；�于這個use case模式﹐將循環漸進、逐一分析各個use case所代表的企業流程。當依這個程序而循環漸進時，就像我們周遭的樹木每天都不斷地成長一般。因而能建構出我們對整個外匯業務的愿景(vision)如圖6。




圖6、對銀行外匯資訊系統的愿景



每一條主要的企業流程就相當于一片葉子。當您仔細觀察時，會看到葉子一片一片地長出來，同時已長出的葉子也會繼續長大，這是自然生命的現象。如此，資訊系統也會像樹木一般生生不息。



▲ 以OOAD分析企業流程



剛才已說過，在OOAD的過程中﹐是以流程為單位﹐循環漸進(iterative & incremental) 分析與設計各個流程�，F在就先來分析「出口托收」流程吧﹗請看圖7。

圖7、出口托收流程



茲對這圖里的流程做個精要的敘述﹐如下﹕

business use case敘述

客戶來銀行要求出口托收﹐銀行委托國外銀行收款﹔待國外銀行收款后﹐銀行請客戶決定結匯匯率﹐然后解款給顧客﹐也呈報總管理部和中央銀行。



這個文字敘述，說明了「銀行」會如何與外界互動：與國外銀行、總管理部和中央銀行互相合作，來為客戶服務。其中，我們把銀行(即企業系統）看成黑箱(black box)，而著重于企業與其actor之間的互動。此時可用UML的順序圖(sequence diagram)來表示之，如圖8。 

圖8、銀行與actor的溝通互動



接下來，進行情境設計。首先把「銀行」黑箱打開來，找出里面到底有那些主要的元件，如柜臺人員、審單人員、結帳人員、出口托收交易、以及顧客帳戶等等。






于是﹐設計詳細的情境(scenario)﹐如下﹕



business scenario敘述

客戶向銀行的柜臺人員要求辦理出口托收交易﹐柜臺人員請審單人員審核并請求國外銀行寄件。審單人員要求結帳人員呈報給總管理部。

當國外銀行收款之后會通知審單人員﹐審單人員請客戶決定匯率﹐然后解款存入到顧客帳戶。審單人員要求結帳人員呈報給中央銀行。



這敘述銀行里的元件如何互助合作﹐來達成出口托收的服務。此時可拿UML 的sequence diagram表達如圖9。

圖9、出口托收流程的Sequence Diagram


上圖9只表達了參與流程的worker之間的溝通于合作，其中的柜臺人員及審單人員會跟這business use case的actor直接溝通互動，我們稱之為Case Worker。而結帳人員并不直接跟actor溝通互動，則稱之為Internal Worker。 

雖然上圖并沒有表達出這些worker跟其背后的entity object── 出口托收交易及顧客帳戶之間的溝通，但是我們也須知道其溝通如下圖10。這些entity objects也將成為資訊系統里主要的entity objects。


圖10、出口托收流程的企業模式

▲ 從企業use case導出系統的use case

前面已介紹了系統use case 的導出步驟： 

1. 會使用到資訊系統的worker，就成為資訊系統的actor。

2. 若有些企業actor會用到資訊系統，它們也成為資訊系統的actor。

3. 對每一條企業use case，察看該use case的actor及各worker，若它們會成為系統actor，就為它們個別建立一個系統use case。



從上述圖9和圖10，可了解到各位worker的任務(task)為：



柜臺人員── 負責收件

審單人員── 負責審單、議價匯率和解款

結帳人員── 負責呈報

出口托收業務主要是由這些workers 和其背后的entity objects互相合作而完成的。所以出口托收流程是由數條小流程所構成的﹐就是﹕收件、審單、解款等。如圖11所示：

圖11、出口托收業務的流程組成



圖12、出口托收導出的系統流程



現在，就來看看這些小流程當中﹐有那些需要藉由資訊系統(IS)的協助﹐例如：柜臺人員收件后，會將托收文件存入到電腦系統里。再如審單人員再進行審單、解款等任務時也會從電腦取得有關的托收交易資料。而有些流程并不需要電腦資訊系統(IS)的協助﹐例如：議價匯率、呈報等。如圖12所示。

于是﹐可得出IS的use case模式﹐如下圖13所示。


圖13、出口托收的system use case模式





第2階段OOAD



▲ 以OOAD分析系統流程



從圖13的系統use case模式，可看到出口托收企業use case所導出的3個主要的系統use case。

請回憶第１階段的OOAD的過程中﹐是以企業use case為單位﹐循環漸進(iterative & incremental) 分析與設計各個流程。于此，第2階段的OOAD的過程中﹐則是以系統use case為單位﹐循環漸進(iterative & incremental) 分析與設計各個系統流程。

現在就先來分析「收件」系統流程吧﹗如下圖14。


圖14、出口托收的第１個系統use case



如果以UML的use case 模式表示如下：

圖15、「收件」系統use case圖



茲對這個小流程做個精要的敘述﹐如下﹕



system use case敘述

柜臺人員將出口托收交易資料輸入資訊系統﹐系統檢查是否為往來客戶，并檢查國外托收銀行的資料﹔檢查OK，系統就替該筆托收交易指定唯一的編號，并輸出之。



這個文字敘述，說明了「系統」會如何與外界互動：與國外托收銀行互相合作，來協助柜臺人員為客戶做更佳的服務。其中，我們把資訊系統看成黑箱(black box)，而著重于系統與其actor之間的互動。此時可用UML的順序圖(sequence diagram)來表示之，如圖16。 


圖16、系統與actor的溝通互動



接下來，進行情境設計。首先把「系統」黑箱打開來，找出里面到底有那些主要的元件，如出口托收交易、銀行的分行等。




圖17、打開系統黑箱



于是﹐設計詳細的情境(scenario)﹐如下﹕

scenario敘述

柜臺人員將出口托收資料輸入給資訊系統里的托收交易元件﹐托收交易元件請銀行分行元件檢查該客戶是否為其往來客戶，托收交易元件請國外托收銀行元件檢查其資料的正確性﹔檢查OK，托收交易元件就替該筆托收交易指定唯一的編號，并輸出給柜臺人員。



這敘述資訊系統里的主角（元件）如何互助合作﹐來達成「收件」的服務。此時可拿UML 的sequence diagram表達，如圖18。


圖18、「收件」流程的Sequence Diagram





▲OOD ──元件設計

根據上述sequence diagram所表達的情境，可看出系統里的3位主角(元件)，各應該擔任的工作了。例如，上圖18表達了托收交易物件所接到的訊息如下圖19。

當托收交易物件接到這些訊息時，就處理之。各以一個長方形表示各處理過程。


圖19、托收交易的進入訊息

這圖19對應到UML類別圖(class diagram)如下：


依樣畫葫蘆，請您也思考有那些訊息傳遞給銀行分行和國外托收銀行物件，就能得出它們的類別圖了。在逐一考慮之后，總共得到如下的類別圖，如下圖 20所示：

圖20、「收件」的Class Diagram



一般而言，這個階段的OOD工作也必須厘清類別之間的靜態結構關系。但是上述的類別圖只表現出類別名稱、類別的責任而已，并沒有表明類別之間的靜態關系(static relationship)。因為本文所介紹的兩段式OOAD方式是以「企業Use Case導出系統Use Case」來銜接的，會比較凸顯系統的功能面及動態面的訊息傳遞情形，而比較不凸顯類別之間的靜態架構。在實務上，一個完美的系統必須均衡地對待靜態結構關系與動態訊息傳遞關系。

不過，在本文里只專注于介紹動態面的銜接程序。至于靜態關系的銜接(即從企業模式銜接到系統模式）則請您進一步閱讀本期雜志的「實作N-Tier系統的企業物件」專欄。





▲OOD ──細部設計



接下來，就來看看如何落實為Visual Basic(VB)的程式。UML的一個類別圖會對應到一個VB 的Class Module定義，如下：






依樣畫葫蘆，可繼續為銀行分行、國外托收銀行類別對應到VB的Class Module。于是，總共得到3個Class Module ，如下表1：





表1、類別定義

‘ class module托收交易

‘ Properties

Function 收件編號()

......

End Function

Function編號()

......

End Function


‘ class module 銀行分行

‘ Properties

Function檢查是否來往客戶()

......

End Function


‘ class module 國外托收銀行

’Properties

Function 檢查國外

銀行資料()

......

End Function








上面是以Visual Basic定義各物件的功能，接著也以Visual Basic撰寫sequence diagram里的動態訊息傳遞情形。




圖21、托收交易的匯出訊息

根據上述圖18的sequence diagram所表達的情境，可看出系統內的3個元件，各應該擔任的工作了。在其進行工作時，也會傳遞訊息給其它物件，尋求協助及服務。例如圖21就是圖18里一部份。

圖21里，實線箭頭表示訊息的傳遞，而虛線則表示單純的資料流向。此時的焦點流出的訊息上(即上圖的橢圓里)。就將之對應到Class Module內，如下表2：



表2、托收交易類別

‘ class module托收交易 

Dim aBranch as New 世華分行

Dim aFBank as New 國外銀行



Public Function 收件編號() As String

aBranch.檢查是否為來往客戶(CustInfo)

aFBank.檢查國外銀行資料( FBankInfo )

收件編號() = Self.編號()

End Function

Public Function編號() As String

‘generate a unque number

‘return this number

End Function

依樣畫葫蘆，可繼續為銀行分行、國外托收銀行類別的Class Module做更細部的設計。于是，得到詳細的Class Module如下：

表3、銀行分行和國外托收銀行類別

‘ class module 銀行分行 

‘ Properties

Public Function檢查是否來往客戶(cInfo)

As Boolean

‘依cID值，從SQL Server 資料庫尋找

‘該客戶的資料，核驗并傳回結果。

End Function



‘ class module 國外托收銀行

‘ Properties

Public Function檢查國外銀行資料(BInfo)

As Boolean

‘依bID值，從SQL Server 資料庫尋找

‘該銀行的資料，核驗并傳回結果。

End Function




上述的「OOD── 元件設計」部份是屬于邏輯設計(logical desugn)，它與OOA部份合起來構成『建立模式』(modeling)階段。這個階段使用模式語言(modeling language)，如UML來描述之。

Modeling = OOA + OOD元件設計

上述的「OOD──細部設計」部份與待會兒將介紹的OOP部份合起來構成『實作』(implementation)階段。這個階段使用電腦程式語言(programming language)，如Visual Basic 來描述之。

Implementation = OOD細部設計 + OOP

許多人常會忽略OOD細部設計的重要性。事實上，OOD細部設計的工作相當于營建業里的總工程師的工作，非常地重要，他要評核建筑設計圖（即model)的可行性，同時也要安排工地施工的分工合作。例如表2及表3的詳細類別定義，必須在測試無誤之后，才能將各個類別分派給不同的程式師去設計。

也只有在正確無誤的詳細類別定義下，由不同人所設計的類別才能組裝成為完美的應用系統。



▲OOP ── 落實為

COM元件



剛才已說過，當表2及表3的詳細類別定義，在測試無誤之后，就能將各個類別分派給不同的程式師去寫更詳細的程式碼。寫好后，再將各程式師所寫的類別程式碼組裝成為完美的應用系統。

收集各程式師所寫的類別程式碼之后，可以在VB環境里直接編譯這些類別程式碼，而成為COM物件。必要時也能將之交由MTS管理之。

現在已經完成的一個系統use case了。

循環漸進，完成系統

剛才進行的第2階段，已做完了一個系統use case──「收件」。接下來，必須循環第2階段，漸進地分析與設計其它各個系統use case──「審單」、「解款」等，如下圖22所示。

如此，就完成了一個企業use case──「出口托收」。接下來，必須循環第1和第2階段，漸進地分析與設計其它各個企業use case──「出口押匯」、「國外轉帳」等。

圖22、循環等于成長



于是，整個資訊系統就像綠意泱然的樹木般，一葉一葉地長出，處處洋溢著生命的青春和理想！如下圖23所示。n






圖23、生命的現象──按有機次序(organic order)成長





參考資料

[Tay95] Taylor, D. Business Engineering with Object Technology, John Wiley & Sons, 1995.

[Jac97] Jacobson, I., Griss, M. and Jonsson, P., Software Reuse, Addison-Wesley, 1997.

[高煥堂98] 高煥堂，「開發企業元件的黃金程序與三層式系統鉆石架構」，物件導向雜志，第10期, pp.16-24.

摘自umlChina