图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
|
