面向对象的Java与UML课件第-8-章业务建模

《面向对象的Java与UML课件第-8-章业务建模》由会员分享，可在线阅读，更多相关《面向对象的Java与UML课件第-8-章业务建模（47页珍藏版）》请在装配图网上搜索。

1、单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,*,*,第,8,章业务建模,业务环境的重要性,制订业务过程的方法与符号,.,UML,活动模型及在描述业务过程中的应用,业务对象以及一些,UML,类标识符,初步,UML,状态图建模,概述,在本章中我们将详尽地介绍根据业务过程来概述一项业务的方法,项目特征对业务建模的影响,当应用于某个新的业务领域，或是为某位新客户而开发的，那么，详尽的业务分析是非常重要的。,应用于某个已制定的业务领域，并且开发悉这一业务领域，那么，一种不十分严格的业务分析或许更为实用,系统的大小和范围也决定了需要进行业务建模的层次；,由于项目

2、风险和失败的代价相对较小，因此，规模较小的系统开发可以不做或只做少量的业务分析,业务建模,这里所讨论的技术将会用于生成业务模型。,模型将作为系统分析阶段的输入,开发精确的成本效益模型,业务过程建模、成本效益建模和系统分析这三者间的关系,业务过程建模的关键输出是业务过程定义（包括过程图），以及在随后的阶段中用到的业务对象模型。,我们应把,UML,活动图作为描述业务过程的一种方法,业务建模的大概过程,要导出业务过程的全局图，该图给出了需要建模的业务领域的概貌以及展示了我们最终计划在何处引人一个新的,IT,系统。,将应用剧本分析来分析相应的业务过程。,这一过程将捕获业务过程的大量细节，并用特殊方式来

3、组织这些细节。,从剧本中，我们可以得出业务工作流，,这些工作流可以用,UML,活动图来描述。我们还可以得出业务对象模型，该模型标识了业务环境中的一些关键条目。,在实际开发中，许多组织也会忽略这一阶段，或是以有限的方式执行，在后续的开发中导致疏忽，这种疏忽会在测试或部署阶段暴露出来,8.1,理解业务过程的重要性,分析业务环境时，一个常见的问题是“为什么要问所有那些和系统并不直接相关的问题？,关于这个问题有多种回答。最重要的是，理解一个系统需要理解他所运行的环境。不然的话，开发出的系统很可能无法正常工作。许多计算机系统开发的失败正是因为忽略了这一简单的常识。,先业务领域，再系统用途,建立业务过程图

4、,分析人员需要首先做的事情之一是询问“我在哪里？”或者更具体一些：“我在构建一个系统，它适合哪种类型的业务？”现在，我们应当着眼于构建一张“大图”，即某项业务的过程图。这对于商定系统范围是尤为重要的。,过程图不会很具体和精确，它应该是全面,它能迅速获得业务范围和活动的总体印象,过程图是是剧本分析和识别用例,一幅三层的业务过程图,业务过程是对事件的逻辑归类，这些事件被认为是业务的基本元素,尽管随着过程图的建立，一些过程会出现严格的先后次序，然而我们的目的是将整个的业务领域作为一个过程集进行描述，而并不关心过程的次序或单个过程之间的交互作用。,这些过程将在不多于三个层次上被分组。经验表明，过于细致

5、的分类所获得的成果反而较少，并且会陷于过多的细节中。高层的过程是总的过程，涵盖了业务活动的广泛领域，并由更集中的过程组成。,过程图的顶层分解,顶层不应多于,10,个高层过程，这些过程应当跨越全部的业务活动,使得分析集中在对业务关键方面,对于,IcANDO,化学制品，这些活动应为：,过程图顶层分解的说明,在抽象层，这些是公司行为总的划分。这种划分或许过于明显，然而经验表明，这样划分容易取得广泛的一致。对于顶层的分解可能会有实质性的争辩。这里没有“正确答案”，所需要的是一种良好的分解，而并非是完美的分解。,过程图往往要隐藏组织的结构，而仅仪描述组织的功能,信息流的疏忽和时间因素的重要性不能被过分强

6、调。在一个组织做什么这一方面，很少存在争议；但对于如何做，争议却总是存在。,过程图的第二层描述,过程图的第二层分解，使其成为第一层活动更细致的描述,销售活动的分解为：,合同磋商,与谈判以及与顾客签订合同有关的所有活动,订货,与订货有关的所有活动,货物交付,与交货有关的活动,接受退货,与退回不想要的或不满意的货物相关的所有活动,给顾客开发票,与开发票相关的所有活动,接受付款,与接受付款有关的所有活动,过程图的第三层描述,最后，第二层活动可以分解为第三层的分组,“开发票活动”可以分解为,标识已发送的和已接受的货物,给货物定价,申请折扣,打印发票,寄送发票,试图分解第四层的实际经验表明达成一致是非常

7、困难的，并越来越关系到某一业务是如何操作的，而并非该业务做什么,目前为止定义的所有过程层次的过程图,822,业务过程图的应用,能够与业务人员一同构建模型，不考虑计算机系统的操作，实际上是不考虑任何软件设计问题。,容易达成到三层的共识。,以这样一种方式总结某一业务，通常可以打印在一张单独的,A4,纸上，并提供可管理的讨论框架。,过程图阐明了专有名词。,利用从高层次视角了解业务运作的人员，模型可以在,2,至,3,天内构架起来。,尽管这是业务的系统视图，但不需要介绍就能够使任何人都很容易理解。,过程图达成了一致，并且强调了共性方面。,集中在功能方面，可以作为企业流程再造的基础,823,绘制过程图,研

8、讨会方法被证明是成功，方法如下：,需要有一个协调者，他清楚过程图的概念。一组业务管理人员和或专家聚集在一起，在极短时间内安排一系列的研讨会。,每个研讨会持续时间不超过半天，,要集中于模型的一层，或者确定顶层过程，或者确定一到两个顶层过程对应的第二层过程，或者确定一到两个第二层过程对应的第三层过程,823,绘制过程图,研讨会需要严格地限定时间范围（,time boxed,）。协调者要记下过程列表，并且得出单独过程的简要总结。,协调者不应对决定施加影响,8.3,业务剧本分析,剧本是一系列的事件和活动。,方法是将任何过程分解为简单的序列,剧本的多样性,考虑从当地的花店买花这一事件时，可以有非常多的方

9、式来完成该件事一一你可以去花店或是通过电话订购；你可以自己取花，或是让助手去取。花也可以包装成各种不同的形式，可以附有问候标签。你可以用现金、支票或信用卡支付；你既可以拿走这些花，也可以将它们递送出去,搜集具有代表性的，将他们组织起来,沏茶的剧本,1,灌满水壶,2,烧水,3,把茶叶放人茶壶,4,倒人开水,5,等,2,分钟,6,把茶倒入茶杯,7,加奶和糖,并非所有人都这样沏茶。有些人用袋茶在杯子里泡茶，有些人等不到,2,分钟，有些人不加糖。,假如你设计一个沏茶系统那么你应考虑许多剧本。,8.3.2 80/20,原则,银行柜台的大多数交易相当迅速，但是，少数几笔交易花费了职员,4,到,5,倍的精力

10、。,上班的路程大部分都可以顺利通过，但是，少数情况会花费,2,倍的时间，并带来很大损失。,通常，你忘在家里的什么东西会很快想起来，但是，有时东西不在该在的地方会造成慌乱，耽误时间。,主要路线,为适应大多数情况，很可能相当迅速的设计业务过程，或是构建系统,真正需要的是可扩展的构建良好系统的方法,主要路线,通常能确定一条带有几个分支的最常用的路线“快乐之路”,(happy path,）,主要路线是大多数时候使用的路线，如果能识别出它，就可以使过程中的大多数用户感到满意。,降低的复杂性，阻止了“分析瘫痪”,替代路线,一旦知道了系统的主要路线，便可以寻找替代路线。这些是常规的细微变化,主要路线形成了一

11、条有意义的核对单，能够用来寻找替代路线,尽量使得替代路线返回主要路线,835,异常,异常通常是更为严重的替代路线。,替代路线是例行发生的，只是不像主要路线那样频繁,异常更为罕见，需要不同层次的恢复,替代路线允许通过另一路线实现目标，异常以从未实现的目标告终,在网上订购系统中，或许有这样一个例子：某人提交了骗来的信用卡。对这一情况的响应也许是接受详细信息和订单，但不是发货，而是通知警察。,过程分析的基础,1,找出关键活动（用例或业务过程,2,为每项活动定义主要路线,3,使用主要路线寻找替代路线,4,补充替代路线，只要可能就返回到主要路线,5,使用主要路线和替代路线来标识异常,记住这一序列，这就是

12、“分析主要路线”。,使用活动图进行业务建模,将由主要路线和替代路线得到的剧本转化成,UML,活动图来描述业务。,活动是业务过程中的一项任务，是一段有实际意义的工作,打印发票,更改订单,联络客户,许多连在一起的活动形成过程，工作流,转换、事件与决策,工作流从一项活动流向另一项活动,在活动之间用箭头表示,简单转换,事件转换,转换、事件与决策,有时，替代路线由一些条件所决定。为了表示这一点，图中放置了一个决策点，用菱形表示。转换采用哪一条替代路线由写在退出路线旁边方括号内的条件来决定。,转换、事件与决策,状态,状态是一项什么也不发生的活动。,状态用圆角矩形表示,下图给出了支付过程中的一个状态，过程在

13、这一状态等待顾客付款。,有两种专门的状态用于帮助表示过程。开始状态是系统初始化，一幅图中通常只有一个。终结状态表示过程的结束。有时，终结状态多于一个。初始状态用黑色圆点表示，终结状态则用一个圈中套一个小实心圆来表示。,实现获得支付过程的简单活动图,泳 道,活动图的另一个特点是泳道,用来表示活动发生的某些业务领域。泳道是活动图中的一列，其标题代表了不同的业务领域,过程目录,既然有了模型范围，即过程图、过程剧本和活动图，便可将它们组织成过程目录。过程图提供概貌，目录则提供细节。每个与系统开发相关的过程在过程图中都有相应的条目。每个条目都包含下列信息：,主要路线,替代路线,异常,活动图,名词辨识法,

14、业务对象,初步状态图建模,ICANDO,ICANDO,化学制品需要一个新系统来改善其销售过程。特别是他们的业务计划表明了销售与生产之间的整合更为紧密。通过高级订单的专有折扣结构，计划增加直接从生产线发货的数量，以减少运输仓储费用和库存中占用的流动资金。因此，要扩展过程图来包含生产与销售的过程。,过程描述,过程图构建完毕后，就需要做出过程描述。在这里，全面地进行描述意义并不大。但是，对一些特别有意思的过程仍然应当加以考虑。,销售,/,订货,/,预留库存,销售,/,发货,/,调整发货数量,销售,/,订货,/,电子订单,业务剧本,电话销售,主要路线,l.,顾客打电话给呼叫中心。,2.,代理记录顾客号

15、，确认系统中的顾客号。,3.,顾客提供订单详细信息，代理在计算机屏幕上按照顾客订单的格式录人汀单的细芍,4.,顾客提供请求交货日期。,5.,系统使订单生效并确定能否在那一天交货。系统可能提供另一个日期，顾客可以接,拒绝。,6.,代理再次阅读订单细节。,7.,顾客同意。,8.,挂断电话。,业务剧本,电话销售,替代路线,2.1,系统不接受该顾客号。代理与顾客验证号码。如果顾客认为没有错误，接到销售组由他们处理这一问题。,3.1,提供了系统不能识别的产品订单代码，代理反复核对产品目录，确保顾客没有提供错误的代码。若找到正确的号码，则继续处理。若未找到，在最后，要被转接到销售组。,3.2,订单可能超过

16、顾客的信贷限额。代理将征求顾客意见，减少订货。如果客户打算增加信贷限额，电话将转接到销售组。,5.1,系统无法为顾客提供合适的日期。顾客取消汀购。相关记录将发送到销件组来联系顾客，争取拿到订单，比如通过提供特惠折扣的方式。,6.1,顾客注意到订单有错误。代理更正错误，将订单重新读给顾客听。,异常,2.2,系统不可用，代理将顾客的要求记录在纸上，当系统恢复联机时继续过程。,业务工作流,销售,/,发货,/,调整发货数量,主要路线,1.,查看发货车辆上的计量器读数,(,若适当，设为,0),2.,查看接收容器上的计量器读数,(,若适当,.,设为,0),3.,将产品从发货车辆上卸到接收容器内。,4.,查看发货车辆上的计量器读数，计算发货量。,5.,查看接收容器上的计量器读数，计算发货量。,6.,确保两月月卖数相差不到,2%,7.,顾客接货后，让顾客签字。,替代路线,6.1,两个读数相差超过,2%,，则讨量器需要校准。记录读数差，并请顾客签字。,异常,7.1,顾客拒绝签字。司机应与仓库联系，询问处理办法。,业务工作流,业务对象模型,