两段式OOAD开发大型3-tier系统

图1、两段式OOAD

 为了让资讯人员能轻松愉快地开发出令人赞美的软件系统，我们宜采用两段式的OOAD方式。如此，资讯人员的辛酸，将成为昨天的记忆！

所谓两段式OOAD，其第1阶段是：先以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，就成为资讯系统的actior

2.若有些企业actor会用到资讯系统，它们也成为资讯系统的actor

3.对每一条企业use case，察看该used case的actor及各worker，若它们会成为系统actor，就为它们个别建立一个系统use case。意味着：每个企业use case将由数个系统use case来支持；也就是说，每个企业use case可能会导出数个系统use case

4.企业模式里的entity object，代表worker所必须用到的重要事物，这些重要事物常必须长期记录与保管，所以它们也成为资讯系统的entity Object

图2，从企业模式导出系统模式

以上是两段式OOADd基础理念。若应用与Mircosoft NT平台上的3-tier系统开发，其各项工作就如下图3所示，此即是本文所称的两段式

图3、两段式OOAD方式的各阶段任务

简单的实例范例

刚才已介绍里两段式OOAD开发方式的基本观念。接下来，为里让你更熟悉这种开发程序，于此就以银行外汇资讯系统为例，逐步说明之。

第1阶段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
  
  对这图里的流程做个精要的叙述，如下：
  business use case叙述
  客户来银行要求出口托收，银行委托国外银行收款；待国外银行收款后，银行请客户决定结汇汇率，然后解款给顾客，也呈报总管理部和中央银行。
  这个文字叙述，说明了【银行】会如何与外界互动；与国外银行、总管理部和中央银行互相合作，来为客户服务。其中，我们把银行（及企业系统）看成黑箱，而着重于企业与其actor之间的互动。此时可用UML的顺序图（sequence diagram）来表示之，如图8.
  
  图8、银行与actor的沟通互动
  接下来，进行情景设计。首先【银行】黑箱

打开，找出里面到底有哪些主要的元件，如柜台人员、审单人员、结账人员、出口托收交易、以及顾客账户等等。
于是，设计详细的情境（scenario）如下：

business scenarion叙述
客户向银行的柜台人员要求办理出口托收交易，柜台人员请审单人员审核并请求国外银行寄件。审单人员要求结账人员呈报给总管理部。当国外银行收款之后会通知审单人员，审单人员请客户决定汇率，然后解款存入到顾客账户。审单人员要求结账人员呈报给中央银行。

这叙述银行里的元件如何互助合作，来达成出口托收的服务。此时可拿UML的sequence diagram表达 如图9.

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

上图9只表达里参与流程的Woker之间的沟通与合作，其中柜台人员及审单人员会跟这business use case的actor直接沟通互动，我们称之为case worker。而结账人员并不直接跟actor沟通互动，则称之为Internal Worker。

虽然上图并没有表达出这些worker跟其背后的entity Object-----出口托收交易及顾客账户之间的沟通，但是我们也须知道其沟通如下图10.这些entity object也将成为资讯系统里只要的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）为：
  柜台人员-------- 负责收件
  审单人员-------- 负责审单、议价汇率和解款
  结账人员-------- 负责呈报
  出口托收业务主要是由这些worker和其背后的entity objects互相合作而完成的。所以出口托收流程是由数条小流程所构成的，就是：收件、审单、解款等。如图11所示
  
  图11 出口托收业务的流程组成
  

图12 、出口托收导出的系统流程
  现在，就来看看这些小流程当中，由哪些需要籍由资讯系统的协助，例如：柜台人员收件后，会将托收文件存入到电脑系统里。再如审单人员进行审单、解款等任务时也会从电脑取得有关的托收交易资料。而有些流程并不需要电脑资讯系统的协助，例如：议价汇率、呈报等。如图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、 出口托收的第1各系统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