UML软件工程组织

两段式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,就成为资讯系统的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开发方式的基本观念。皆下来,为了让您更熟悉这种开发程序,于此就以银行外汇资讯系统为例,逐步说明之。

第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。

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

请回忆第1阶段的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.

摘自umlChina