📄 银行业务模型、技术模型的建立和转化实例.htm
字号:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<!-- saved from url=(0050)http://www.uml.org.cn/UMLSearch/2StepOOAD3Tier.htm -->
<HTML><HEAD><TITLE>UML软件工程组织</TITLE>
<META http-equiv=Content-Type content="text/html; charset=gb2312">
<META content="MSHTML 6.00.2800.1106" name=GENERATOR>
<META content=FrontPage.Editor.Document name=ProgId></HEAD>
<BODY>
<DIV align=left>
<TABLE height=1 cellSpacing=0 cellPadding=0 width="100%" align=left border=0>
<TBODY>
<TR>
<TD width="27%" height=51><I><FONT face=方正姚体 color=#008000
size=6> </FONT></I><IMG height=57
src="银行业务模型、技术模型的建立和转化实例.files/uml.gif" width=77 border=0></TD>
<TD width="173%" height=51>
<P align=left><B><FONT face="Arial Black" color=#008080
size=6>UML</FONT><FONT color=#008080><FONT face=方正姚体 color=#008080
size=6>软件工程</FONT><FONT face=方正姚体 size=6>组织</FONT></FONT></B></P></TD></TR>
<TR>
<TD width="200%" colSpan=2 height=6></TD></TR>
<TR>
<TD width="200%" colSpan=2 height=1>
<TABLE>
<TBODY>
<TR>
<TD vAlign=top height=21>
<P align=center><SPAN class=atitle><FONT color=#ff0000
size=2>两段式OOAD开发大型3- tier系统</FONT></SPAN> </P></TD></TR>
<TR>
<TD align=right height=20>
<P align=center><FONT size=2>高焕堂 </FONT><FONT
size=2>著<BR></FONT></P></TD></TR>
<TR>
<TD vAlign=top height=1882><BR><IMG height=515
src="银行业务模型、技术模型的建立和转化实例.files/image002.gif" width=560
border=0><BR><BR><BR><FONT
size=2><BR> <BR>图1、两段式OOAD<BR><BR>为了让资讯人员能轻松愉快地开发出令人赞美的软体系统，我们宜采用两段式的OOAD方式。如此，资讯人员的「做得流汗但被人嫌得流涎」辛酸，将成为昨日的记忆！<BR><BR>所谓两段式OOAD，其第１阶段是：先以OOAD技术分析企业的流程，然后第2阶段是：以OOAD技术分析资讯系统的流程。<BR><BR>其将企业(business)与其软体(software)视为一个整体的系统，而企业与软体便成为该系统的两个层面(facet)罢了。这样，资讯系统便能有效地支持企业来创造出更佳的企业流程(business
process)，由更好的流程来提供给顾客更满意的服务。<BR><BR>本文就以简单的实例来说明整个开发过程。<BR><BR>基本观念<BR><BR><BR><BR>在1980年代,
北美地区的公司总共投入了超过一兆(trillion)美金，于资讯系统上。但在该期间，企业的服务效率平均只增加1%而已[Tay95]。
商业周刊(Business Week)经过调查与分析之后指出：资讯系统能有效支持企业创造更佳的企业流程(business
process)，由更好的流程来提供顾客更贴心的服务。若只针对旧有流程而加以自动化，通常无法显著提升服务品质！<BR><BR>那么，如何利用资讯系统来改善企业流程呢？最有效的方式是：以相同的思维来组织企业与资讯系统，将企业(business)与背后的软体(software)视为一个整合的系统，于是企业与软体只是该系统的两个层面(facet)而已。举世著名的软体专家Taylor[Tay95]称这种方式为「聚合式工程」(convergent
engineering)。Taylor在该书中说到：<BR><BR>‘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.’ <BR><BR>(本书所提出的聚合式工程，将企业与软体工程结合为一致的设计及建构方式，如此能让我们创造出更具有弹性、更能适应环境变化的企业。)<BR><BR>Taylor又说到：<BR><BR>‘The
output of convergent engineering is an object-oriented business
model that represents both organization and its supporting
software.’<BR><BR>(聚合式工程将产出一个物件导向的模式，此模式既表达企业本身又表达企业背后的软体系统。)<BR><BR><BR><BR>他说明了这种途径的好处如下：<BR><BR>l能简化设计与建造的过程(simplify
the engineering process)，毕其功于一役。<BR><BR>l消除企业流程与软体的鸿沟(eliminates the
gaps between business process and supporting
software)，两者皆易于设计与理解。<BR><BR>l更能随环境而改变(facilitates
change)，企业与软体能同步修正，使两者皆生生不息。<BR><BR><BR><BR>让我们再来看看另一位软体专家
Jacobson[Jac97]的见解吧！ 他说到： <BR><BR>‘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.’<BR><BR>（进行企业工程时所产出的模式，可做为定义软体架构、找出可重复使用的元件、以及开发应用程式来服务顾客等工作的绝佳基础。） <BR><BR><BR><BR>进行企业工程而得到的企业模式，能顺利地导出软体系统的模式，两者的建构理念是一致的。由于企业模式与软体模式是基于一致的理念，使得企业模式所表达的企业系统，于软体模式所表达的软体系统，成为一体的两面。<BR><BR>Jacobson又说到：<BR><BR><BR><BR>‘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.’<BR><BR>（企业工程产出的模式必须是物件导向的，因而您可将真实世界里的物件如人、地方、及事物等，几乎能一对一密切对应到资讯系统里的物件。）<BR><BR>所以必须建立企业的物件模式，再顺利导出软体系统的物件模式。在物件模式里，会以Use
Case来表达流程，当然也就由企业的use case (business use case) 来导出资讯系统的use case
(system use case)。 Jacobson在其书[Jac97]中提出建议：<BR><BR>‘Using
object-oriented business engineering as input, it is a
straightforward process to identify the information system
models.’<BR><BR>（以物件导向的企业工程所产出的模式为基础，来导出资讯系统的模式，是个极直截了当的途径。）<BR><BR><BR><BR>他以图示说明导出的步骤，如下图2所示。其详细步骤如下：<BR><BR>1.
会使用到资讯系统的worker，就成为资讯系统的actor。<BR><BR>2.
若有些企业actor会用到资讯系统，它们也成为资讯系统的actor。<BR><BR>3. 对每一条企业use case，察看该use
case的actor及各worker，若它们会成为系统actor，就为它们个别建立一个系统use case。意谓着：每一个企业use
case将由数个系统use case来支持；也就是说, 每一个企业use case可能会导出数个系统use
case。<BR><BR>4. 企业模式里的entity
object，代表worker所必须用到的重要事物，这些重要事物常必须长期记录与保管，所以它们也成为资讯系统的entity
object。<BR><BR><IMG height=615
src="银行业务模型、技术模型的建立和转化实例.files/image004.gif" width=565
border=0><BR>图2、从企业模式导出系统模式[Jac97]<BR><BR>以上是两段式OOAD的基础理念。若应用于Microsoft
NT平台上的3-tier系统开发，其各项工作就如下图3所示，此即是本文所称的两段式OOAD开发方式。<BR><BR><IMG
height=493 src="银行业务模型、技术模型的建立和转化实例.files/image006.gif" width=546
border=0><BR><BR><BR><BR><BR>图3、两段式OOAD方式的各阶段任务<BR><BR>简单的实作范例<BR><BR>刚才已介绍了两段式OOAD开发方式的基本观念。皆下来，为了让您更熟悉这种开发程序，于此就以银行外汇资讯系统为例，逐步说明之。<BR><BR>第１阶段OOAD<BR><BR><BR><BR>▲
确定系统领域(domain)<BR><BR><BR><BR>外汇服务是一般商业银行的重要业务。在服务的过程中除了顾客之外﹐常需要跟国外银行、中央银行或该银行总管理部的支援协助﹐才能给予顾客流畅的服务，如图4。</FONT>
<P><FONT size=2><IMG height=198
src="银行业务模型、技术模型的建立和转化实例.files/image008.gif" width=280
border=0><BR><BR>图4、Domain──银行外汇业务<BR><BR><BR><BR>▲
找出企业流程<BR><BR>──以use
case描述之<BR><BR>首先要从客户来银行的目的(goal)或期望(expectation)来找出银行的企业流程。客户会要求银行提供各式各样的外汇服务﹐例如：出口托收、出口押汇、国外转帐等等。
依据这些目的﹐可找出银行的主要流程，然后拿UML 的use case模式表示如图5。<BR><IMG height=204
src="银行业务模型、技术模型的建立和转化实例.files/image010.gif" width=274
border=0><BR><BR>图5、银行外汇业务的企业流程<BR><BR><BR><BR>每个use
case表达一条企业流程。基于这个use case模式﹐将循环渐进、逐一分析各个use
case所代表的企业流程。当依这个程序而循环渐进时，就像我们周遭的树木每天都不断地成长一般。因而能建构出我们对整个外汇业务的愿景(vision)如图6。<BR><BR><IMG
height=288 src="银行业务模型、技术模型的建立和转化实例.files/image012.gif" width=278
border=0><BR><BR><BR>图6、对银行外汇资讯系统的愿景<BR><BR><BR><BR>每一条主要的企业流程就相当于一片叶子。当您仔细观察时，会看到叶子一片一片地长出来，同时已长出的叶子也会继续长大，这是自然生命的现象。如此，资讯系统也会像树木一般生生不息。<BR><BR><BR><BR>▲
以OOAD分析企业流程<BR><BR><BR><BR>刚才已说过，在OOAD的过程中﹐是以流程为单位﹐循环渐进(iterative
& incremental) 分析与设计各个流程。现在就先来分析「出口托收」流程吧﹗请看图7。<BR><IMG
height=133 src="银行业务模型、技术模型的建立和转化实例.files/image014.gif" width=286
border=0><BR>图7、出口托收流程<BR><BR><BR><BR>兹对这图里的流程做个精要的叙述﹐如下﹕<BR><BR>business
use
case叙述<BR><BR>客户来银行要求出口托收﹐银行委托国外银行收款﹔待国外银行收款后﹐银行请客户决定结汇汇率﹐然后解款给顾客﹐也呈报总管理部和中央银行。<BR><BR><BR><BR>这个文字叙述，说明了「银行」会如何与外界互动：与国外银行、总管理部和中央银行互相合作，来为客户服务。其中，我们把银行(即企业系统）看成黑箱(black
box)，而着重于企业与其actor之间的互动。此时可用UML的顺序图(sequence
diagram)来表示之，如图8。 <BR><IMG height=286
src="银行业务模型、技术模型的建立和转化实例.files/image016.gif" width=280
border=0><BR>图8、银行与actor的沟通互动<BR><BR><BR><BR>接下来，进行情境设计。首先把「银行」黑箱打开来，找出里面到底有那些主要的元件，如柜台人员、审单人员、结帐人员、出口托收交易、以及顾客帐户等等。<BR><BR><BR><BR><BR><BR><BR>于是﹐设计详细的情境(scenario)﹐如下﹕<BR><IMG
height=193 src="银行业务模型、技术模型的建立和转化实例.files/image018.gif" width=246
border=0><BR><BR><BR>business
scenario叙述<BR><BR>客户向银行的柜台人员要求办理出口托收交易﹐柜台人员请审单人员审核并请求国外银行寄件。审单人员要求结帐人员呈报给总管理部。<BR><BR>当国外银行收款之后会通知审单人员﹐审单人员请客户决定汇率﹐然后解款存入到顾客帐户。审单人员要求结帐人员呈报给中央银行。<BR><BR><BR><BR>这叙述银行里的元件如何互助合作﹐来达成出口托收的服务。此时可拿UML
的sequence diagram表达如图9。<BR><IMG height=328
src="银行业务模型、技术模型的建立和转化实例.files/image020.gif" width=575
border=0><BR>图9、出口托收流程的Sequence
Diagram<BR><BR><BR>上图9只表达了参与流程的worker之间的沟通于合作，其中的柜台人员及审单人员会跟这business
use case的actor直接沟通互动，我们称之为Case
Worker。而结帐人员并不直接跟actor沟通互动，则称之为Internal
Worker。 <BR><BR>虽然上图并没有表达出这些worker跟其背后的entity object──
出口托收交易及顾客帐户之间的沟通，但是我们也须知道其沟通如下图10。这些entity objects也将成为资讯系统里主要的entity
objects。<BR><BR><IMG height=290
src="银行业务模型、技术模型的建立和转化实例.files/image022.gif" width=541
border=0><BR>图10、出口托收流程的企业模式<BR><BR>▲ 从企业use case导出系统的use
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -