银行业务模型、技术模型的建立和转化实例.htm

UML软件工程组织面向对象实例文档 内涵GIF 图片和网络文件格式

            case<BR><BR>前面已介绍了系统use case 的导出步骤：&nbsp;<BR><BR>1. 
            会使用到资讯系统的worker，就成为资讯系统的actor。<BR><BR>2. 
            若有些企业actor会用到资讯系统，它们也成为资讯系统的actor。<BR><BR>3. 对每一条企业use case，察看该use 
            case的actor及各worker，若它们会成为系统actor，就为它们个别建立一个系统use 
            case。<BR><BR><BR><BR>从上述图9和图10，可了解到各位worker的任务(task)为：<BR><BR><BR><BR>柜台人员── 
            负责收件<BR><BR>审单人员── 负责审单、议价汇率和解款<BR><BR>结帐人员── 
            负责呈报<BR><BR>出口托收业务主要是由这些workers 和其背后的entity 
            objects互相合作而完成的。所以出口托收流程是由数条小流程所构成的﹐就是﹕收件、审单、解款等。如图11所示：<BR><IMG 
            height=217 src="银行业务模型、技术模型的建立和转化实例.files/image024.gif" width=283 
            border=0><BR>图11、出口托收业务的流程组成<BR><BR><IMG height=395 
            src="银行业务模型、技术模型的建立和转化实例.files/image026.gif" width=277 
            border=0><BR><BR>图12、出口托收导出的系统流程<BR><BR><BR><BR>现在，就来看看这些小流程当中﹐有那些需要藉由资讯系统(IS)的协助﹐例如：柜台人员收件后，会将托收文件存入到电脑系统里。再如审单人员再进行审单、解款等任务时也会从电脑取得有关的托收交易资料。而有些流程并不需要电脑资讯系统(IS)的协助﹐例如：议价汇率、呈报等。如图12所示。<BR><BR>于是﹐可得出IS的use 
            case模式﹐如下图13所示。<BR><BR><BR>图13、出口托收的system use case模式<BR><BR><IMG 
            height=231 src="银行业务模型、技术模型的建立和转化实例.files/image028.gif" width=268 
            border=0><BR><BR><BR><BR>第2阶段OOAD<BR><BR><BR><BR>▲ 
            以OOAD分析系统流程<BR><BR><BR><BR>从图13的系统use case模式，可看到出口托收企业use 
            case所导出的3个主要的系统use case。<BR><BR>请回忆第１阶段的OOAD的过程中﹐是以企业use 
            case为单位﹐循环渐进(iterative &amp; incremental) 
            分析与设计各个流程。于此，第2阶段的OOAD的过程中﹐则是以系统use case为单位﹐循环渐进(iterative &amp; 
            incremental) 分析与设计各个系统流程。<BR><BR>现在就先来分析「收件」系统流程吧﹗如下图14。<BR><IMG 
            height=178 src="银行业务模型、技术模型的建立和转化实例.files/image030.gif" width=254 
            border=0><BR><BR>图14、出口托收的第１个系统use case<BR><BR><BR><BR>如果以UML的use 
            case 模式表示如下：<BR><IMG height=97 
            src="银行业务模型、技术模型的建立和转化实例.files/image032.gif" width=279 
            border=0><BR>图15、「收件」系统use 
            case图<BR><BR><BR><BR>兹对这个小流程做个精要的叙述﹐如下﹕<BR><BR><BR><BR>system use 
            case叙述<BR><BR>柜台人员将出口托收交易资料输入资讯系统﹐系统检查是否为往来客户，并检查国外托收银行的资料﹔检查OK，系统就替该笔托收交易指定唯一的编号，并输出之。<BR><BR><BR><BR>这个文字叙述，说明了「系统」会如何与外界互动：与国外托收银行互相合作，来协助柜台人员为客户做更佳的服务。其中，我们把资讯系统看成黑箱(black 
            box)，而着重于系统与其actor之间的互动。此时可用UML的顺序图(sequence 
            diagram)来表示之，如图16。&nbsp;<BR><BR><IMG height=205 
            src="银行业务模型、技术模型的建立和转化实例.files/image034.gif" width=262 
            border=0><BR>图16、系统与actor的沟通互动<BR><BR><BR><BR>接下来，进行情境设计。首先把「系统」黑箱打开来，找出里面到底有那些主要的元件，如出口托收交易、银行的分行等。<BR><IMG 
            height=221 src="银行业务模型、技术模型的建立和转化实例.files/image036.gif" width=279 
            border=0><BR><BR><BR><BR>图17、打开系统黑箱<BR><BR><BR><BR>于是﹐设计详细的情境(scenario)﹐如下﹕<BR><BR>scenario叙述<BR><BR>柜台人员将出口托收资料输入给资讯系统里的托收交易元件﹐托收交易元件请银行分行元件检查该客户是否为其往来客户，托收交易元件请国外托收银行元件检查其资料的正确性﹔检查OK，托收交易元件就替该笔托收交易指定唯一的编号，并输出给柜台人员。<BR><BR><BR><BR>这叙述资讯系统里的主角（元件）如何互助合作﹐来达成「收件」的服务。此时可拿UML 
            的sequence diagram表达，如图18。<BR><IMG height=284 
            src="银行业务模型、技术模型的建立和转化实例.files/image038.gif" width=468 
            border=0><BR><BR>图18、「收件」流程的Sequence 
            Diagram<BR><BR><BR><BR><BR><BR>▲OOD ──元件设计<BR><BR>根据上述sequence 
            diagram所表达的情境，可看出系统里的3位主角(元件)，各应该担任的工作了。例如，上图18表达了托收交易物件所接到的讯息如下图19。<BR><BR>当托收交易物件接到这些讯息时，就处理之。各以一个长方形表示各处理过程。<BR><BR><IMG 
            height=187 src="银行业务模型、技术模型的建立和转化实例.files/image040.gif" width=237 
            border=0><BR>图19、托收交易的进入讯息<BR><BR>这图19对应到UML类别图(class 
            diagram)如下：<BR><BR><IMG height=145 
            src="银行业务模型、技术模型的建立和转化实例.files/image042.gif" width=176 
            border=0><BR>依样画葫芦，请您也思考有那些讯息传递给银行分行和国外托收银行物件，就能得出它们的类别图了。在逐一考虑之后，总共得到如下的类别图，如下图 
            20所示：<BR><IMG height=320 
            src="银行业务模型、技术模型的建立和转化实例.files/image044.gif" width=278 
            border=0><BR>图20、「收件」的Class 
            Diagram<BR><BR><BR><BR>一般而言，这个阶段的OOD工作也必须厘清类别之间的静态结构关系。但是上述的类别图只表现出类别名称、类别的责任而已，并没有表明类别之间的静态关系(static 
            relationship)。因为本文所介绍的两段式OOAD方式是以「企业Use Case导出系统Use 
            Case」来衔接的，会比较凸显系统的功能面及动态面的讯息传递情形，而比较不凸显类别之间的静态架构。在实务上，一个完美的系统必须均衡地对待静态结构关系与动态讯息传递关系。<BR><BR>不过，在本文里只专注于介绍动态面的衔接程序。至于静态关系的衔接(即从企业模式衔接到系统模式）则请您进一步阅读本期杂志的「实作N-Tier系统的企业物件」专栏。<BR><BR><BR><BR><BR><BR>▲OOD 
            ──细部设计<BR><BR><BR><BR>接下来，就来看看如何落实为Visual 
            Basic(VB)的程式。UML的一个类别图会对应到一个VB 的Class Module定义，如下：<BR><BR><IMG 
            height=278 src="银行业务模型、技术模型的建立和转化实例.files/image046.gif" width=256 
            border=0><BR><BR><BR><BR><BR>依样画葫芦，可继续为银行分行、国外托收银行类别对应到VB的Class 
            Module。于是，总共得到3个Class Module 
            ，如下表1：<BR><BR><BR><BR><BR><BR>表1、类别定义<BR><BR>‘ class 
            module托收交易<BR><BR>‘ Properties<BR><BR>Function 
            收件编号()<BR><BR>......<BR><BR>End 
            Function<BR><BR>Function编号()<BR><BR>......<BR><BR>End 
            Function<BR><BR><BR>‘ class module 银行分行<BR><BR>‘ 
            Properties<BR><BR>Function检查是否来往客户()<BR><BR>......<BR><BR>End 
            Function<BR><BR><BR>‘ class module 
            国外托收银行<BR><BR>’Properties<BR><BR>Function 
            检查国外<BR><BR>银行资料()<BR><BR>......<BR><BR>End 
            Function<BR><BR><BR><BR><BR><BR><BR><BR><BR>上面是以Visual 
            Basic定义各物件的功能，接着也以Visual Basic撰写sequence 
            diagram里的动态讯息传递情形。<BR><BR><IMG height=298 
            src="银行业务模型、技术模型的建立和转化实例.files/image048.gif" width=250 
            border=0><BR><BR><BR>图21、托收交易的汇出讯息<BR><BR>根据上述图18的sequence 
            diagram所表达的情境，可看出系统内的3个元件，各应该担任的工作了。在其进行工作时，也会传递讯息给其它物件，寻求协助及服务。例如图21就是图18里一部份。<BR><BR>图21里，实线箭头表示讯息的传递，而虚线则表示单纯的资料流向。此时的焦点流出的讯息上(即上图的椭圆里)。就将之对应到Class 
            Module内，如下表2：<BR><BR><BR><BR>表2、托收交易类别<BR><BR>‘ class 
            module托收交易&nbsp;<BR><BR>Dim aBranch as New 世华分行<BR><BR>Dim aFBank as 
            New 国外银行<BR><BR><BR><BR>Public Function 收件编号() As 
            String<BR><BR>aBranch.检查是否为来往客户(CustInfo)<BR><BR>aFBank.检查国外银行资料( 
            FBankInfo )<BR><BR>收件编号() = Self.编号()<BR><BR>End 
            Function<BR><BR>Public Function编号() As String<BR><BR>‘generate a 
            unque number<BR><BR>‘return this number<BR><BR>End 
            Function<BR><BR>依样画葫芦，可继续为银行分行、国外托收银行类别的Class 
            Module做更细部的设计。于是，得到详细的Class 
            Module如下：<BR><BR>表3、银行分行和国外托收银行类别<BR><BR>‘ class module 
            银行分行&nbsp;<BR><BR>‘ Properties<BR><BR>Public 
            Function检查是否来往客户(cInfo)<BR><BR>As Boolean<BR><BR>‘依cID值，从SQL Server 
            资料库寻找<BR><BR>‘该客户的资料，核验并传回结果。<BR><BR>End Function<BR><BR><BR><BR>‘ 
            class module 国外托收银行<BR><BR>‘ Properties<BR><BR>Public 
            Function检查国外银行资料(BInfo)<BR><BR>As Boolean<BR><BR>‘依bID值，从SQL Server 
            资料库寻找<BR><BR>‘该银行的资料，核验并传回结果。<BR><BR>End 
            Function<BR><BR><BR><BR><BR>上述的「OOD── 元件设计」部份是属于逻辑设计(logical 
            desugn)，它与OOA部份合起来构成『建立模式』(modeling)阶段。这个阶段使用模式语言(modeling 
            language)，如UML来描述之。<BR><BR>Modeling = OOA + 
            OOD元件设计<BR><BR>上述的「OOD──细部设计」部份与待会儿将介绍的OOP部份合起来构成『实作』(implementation)阶段。这个阶段使用电脑程式语言(programming 
            language)，如Visual Basic 来描述之。<BR><BR>Implementation = OOD细部设计 + 
            OOP<BR><BR>许多人常会忽略OOD细部设计的重要性。事实上，OOD细部设计的工作相当于营建业里的总工程师的工作，非常地重要，他要评核建筑设计图（即model)的可行性，同时也要安排工地施工的分工合作。例如表2及表3的详细类别定义，必须在测试无误之后，才能将各个类别分派给不同的程式师去设计。<BR><BR>也只有在正确无误的详细类别定义下，由不同人所设计的类别才能组装成为完美的应用系统。<BR><BR><BR><BR>▲OOP 
            ── 
            落实为<BR><BR>COM元件<BR><BR><BR><BR>刚才已说过，当表2及表3的详细类别定义，在测试无误之后，就能将各个类别分派给不同的程式师去写更详细的程式码。写好后，再将各程式师所写的类别程式码组装成为完美的应用系统。<BR><BR>收集各程式师所写的类别程式码之后，可以在VB环境里直接编译这些类别程式码，而成为COM物件。必要时也能将之交由MTS管理之。<BR><BR>现在已经完成的一个系统use 
            case了。<BR><BR>循环渐进，完成系统<BR><BR>刚才进行的第2阶段，已做完了一个系统use 
            case──「收件」。接下来，必须循环第2阶段，渐进地分析与设计其它各个系统use 
            case──「审单」、「解款」等，如下图22所示。<BR><BR>如此，就完成了一个企业use 
            case──「出口托收」。接下来，必须循环第1和第2阶段，渐进地分析与设计其它各个企业use 
            case──「出口押汇」、「国外转帐」等。<BR><IMG height=178 
            src="银行业务模型、技术模型的建立和转化实例.files/image050.gif" width=283 
            border=0><BR>图22、循环等于成长<BR><BR><BR><BR>于是，整个资讯系统就像绿意泱然的树木般，一叶一叶地长出，处处洋溢着生命的青春和理想！如下图23所示。n<BR><BR><IMG 
            height=291 src="银行业务模型、技术模型的建立和转化实例.files/image052.gif" width=400 
            border=0><BR><BR><BR><BR><BR>图23、生命的现象──按有机次序(organic 
            order)成长<BR><BR><BR><BR><BR><BR>参考资料<BR><BR>[Tay95] Taylor, D. 
            Business Engineering with Object Technology, John Wiley &amp; Sons, 
            1995.<BR><BR>[Jac97] Jacobson, I., Griss, M. and Jonsson, P., 
            Software Reuse, Addison-Wesley, 1997.<BR><BR>[高焕堂98] 
            高焕堂，「开发企业元件的黄金程序与三层式系统钻石架构」，物件导向杂志，第10期, pp.16-24.</FONT></P>
            <P class=Paragraph 
            style="MARGIN: 6pt 0cm; TEXT-INDENT: 22.7pt; LINE-HEIGHT: 150%; mso-para-margin-top: .5gd; mso-para-margin-right: 0cm; mso-para-margin-bottom: .5gd; mso-para-margin-left: 0cm"><SPAN 
            lang=EN-AU><FONT size=2>摘自umlChina</FONT></SPAN></P>
            <P><FONT 
size=2>　</FONT></P></TD></TR></TBODY></TABLE></TD></TR></TBODY></TABLE></DIV>
<P align=left>　</P>
<P align=left>　</P>
<P align=left>　</P></BODY></HTML>