http://www.uml.org.cn/UMLSearch/2StepOOAD3Tier.htm

图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) 分析与设计各个流程。现在就先来分析「出口托收」流程吧﹗请看图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