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

第8章业务建模业务环境的重要性制订业务过程的方法与符号.UML活动模型及在描述业务过程中的应用业务对象以及一些UML类标识符初步UML状态图建模第8章业务建模业务环境的重要性1概述在本章中我们将详尽地介绍根据业务过程来概述一项业务的方法概述在本章中我们将详尽地介绍根据业务过程来概述一项业务的方法2项目特征对业务建模的影响当应用于某个新的业务领域，或是为某位新客户而开发的，那么，详尽的业务分析是非常重要的。应用于某个已制定的业务领域，并且开发悉这一业务领域，那么，一种不十分严格的业务分析或许更为实用系统的大小和范围也决定了需要进行业务建模的层次；由于项目风险和失败的代价相对较小，因此，规模较小的系统开发可以不做或只做少量的业务分析项目特征对业务建模的影响当应用于某个新的业务领域，或是为某位3业务建模这里所讨论的技术将会用于生成业务模型。模型将作为系统分析阶段的输入开发精确的成本效益模型业务过程建模、成本效益建模和系统分析这三者间的关系业务过程建模的关键输出是业务过程定义（包括过程图），以及在随后的阶段中用到的业务对象模型。我们应把UML活动图作为描述业务过程的一种方法业务建模这里所讨论的技术将会用于生成业务模型。4面向对象的Java与UML课件第-8-章业务建模5业务建模的大概过程要导出业务过程的全局图，该图给出了需要建模的业务领域的概貌以及展示了我们最终计划在何处引人一个新的IT系统。将应用剧本分析来分析相应的业务过程。这一过程将捕获业务过程的大量细节，并用特殊方式来组织这些细节。从剧本中，我们可以得出业务工作流，这些工作流可以用UML活动图来描述。我们还可以得出业务对象模型，该模型标识了业务环境中的一些关键条目。在实际开发中，许多组织也会忽略这一阶段，或是以有限的方式执行，在后续的开发中导致疏忽，这种疏忽会在测试或部署阶段暴露出来业务建模的大概过程要导出业务过程的全局图，该图给出了需要建模6面向对象的Java与UML课件第-8-章业务建模78.1理解业务过程的重要性分析业务环境时，一个常见的问题是“为什么要问所有那些和系统并不直接相关的问题？关于这个问题有多种回答。最重要的是，理解一个系统需要理解他所运行的环境。不然的话，开发出的系统很可能无法正常工作。许多计算机系统开发的失败正是因为忽略了这一简单的常识。先业务领域，再系统用途8.1理解业务过程的重要性分析业务环境时，一个常见的问题是“8建立业务过程图分析人员需要首先做的事情之一是询问“我在哪里？”或者更具体一些：“我在构建一个系统，它适合哪种类型的业务？”现在，我们应当着眼于构建一张“大图”，即某项业务的过程图。这对于商定系统范围是尤为重要的。过程图不会很具体和精确，它应该是全面它能迅速获得业务范围和活动的总体印象过程图是是剧本分析和识别用例建立业务过程图分析人员需要首先做的事情之一是询问“我在哪里？9一幅三层的业务过程图业务过程是对事件的逻辑归类，这些事件被认为是业务的基本元素尽管随着过程图的建立，一些过程会出现严格的先后次序，然而我们的目的是将整个的业务领域作为一个过程集进行描述，而并不关心过程的次序或单个过程之间的交互作用。这些过程将在不多于三个层次上被分组。经验表明，过于细致的分类所获得的成果反而较少，并且会陷于过多的细节中。高层的过程是总的过程，涵盖了业务活动的广泛领域，并由更集中的过程组成。一幅三层的业务过程图业务过程是对事件的逻辑归类，这些事件被认10过程图的顶层分解顶层不应多于10个高层过程，这些过程应当跨越全部的业务活动——使得分析集中在对业务关键方面对于IcANDO化学制品，这些活动应为：过程图的顶层分解顶层不应多于10个高层过程，这些过程应当11过程图顶层分解的说明在抽象层，这些是公司行为总的划分。这种划分或许过于明显，然而经验表明，这样划分容易取得广泛的一致。对于顶层的分解可能会有实质性的争辩。这里没有“正确答案”，所需要的是一种良好的分解，而并非是完美的分解。过程图往往要隐藏组织的结构，而仅仪描述组织的功能信息流的疏忽和时间因素的重要性不能被过分强调。在一个组织做什么这一方面，很少存在争议；但对于如何做，争议却总是存在。过程图顶层分解的说明在抽象层，这些是公司行为总的划分。这种划12过程图的第二层描述过程图的第二层分解，使其成为第一层活动更细致的描述销售活动的分解为：合同磋商―与谈判以及与顾客签订合同有关的所有活动．订货―与订货有关的所有活动货物交付―与交货有关的活动接受退货―与退回不想要的或不满意的货物相关的所有活动给顾客开发票―与开发票相关的所有活动接受付款―与接受付款有关的所有活动过程图的第二层描述过程图的第二层分解，使其成为第一层活动更细13过程图的第三层描述最后，第二层活动可以分解为第三层的分组“开发票活动”可以分解为标识已发送的和已接受的货物给货物定价申请折扣打印发票寄送发票试图分解第四层的实际经验表明达成一致是非常困难的，并越来越关系到某一业务是如何操作的，而并非该业务做什么过程图的第三层描述最后，第二层活动可以分解为第三层的分组14目前为止定义的所有过程层次的过程图目前为止定义的所有过程层次的过程图15822业务过程图的应用能够与业务人员一同构建模型，不考虑计算机系统的操作，实际上是不考虑任何软件设计问题。容易达成到三层的共识。以这样一种方式总结某一业务，通常可以打印在一张单独的A4纸上，并提供可管理的讨论框架。过程图阐明了专有名词。利用从高层次视角了解业务运作的人员，模型可以在2至3天内构架起来。尽管这是业务的系统视图，但不需要介绍就能够使任何人都很容易理解。过程图达成了一致，并且强调了共性方面。集中在功能方面，可以作为企业流程再造的基础822业务过程图的应用能够与业务人员一同构建模型，不考虑计算16823绘制过程图研讨会方法被证明是成功，方法如下：需要有一个协调者，他清楚过程图的概念。一组业务管理人员和／或专家聚集在一起，在极短时间内安排一系列的研讨会。每个研讨会持续时间不超过半天，要集中于模型的一层，或者确定顶层过程，或者确定一到两个顶层过程对应的第二层过程，或者确定一到两个第二层过程对应的第三层过程823绘制过程图研讨会方法被证明是成功，方法如下：17823绘制过程图研讨会需要严格地限定时间范围（timeboxed）。协调者要记下过程列表，并且得出单独过程的简要总结。协调者不应对决定施加影响823绘制过程图研讨会需要严格地限定时间范围（timeb188.3业务剧本分析剧本是一系列的事件和活动。方法是将任何过程分解为简单的序列剧本的多样性考虑从当地的花店买花这一事件时，可以有非常多的方式来完成该件事一一你可以去花店或是通过电话订购；你可以自己取花，或是让助手去取。花也可以包装成各种不同的形式，可以附有问候标签。你可以用现金、支票或信用卡支付；你既可以拿走这些花，也可以将它们递送出去搜集具有代表性的，将他们组织起来8.3业务剧本分析剧本是一系列的事件和活动。19沏茶的剧本1．灌满水壶2．烧水3．把茶叶放人茶壶4．倒人开水5．等2分钟6．把茶倒入茶杯7．加奶和糖并非所有人都这样沏茶。有些人用袋茶在杯子里泡茶，有些人等不到2分钟，有些人不加糖。假如你设计一个沏茶系统那么你应考虑许多剧本。沏茶的剧本1．灌满水壶208.3.280/20原则银行柜台的大多数交易相当迅速，但是，少数几笔交易花费了职员4到5倍的精力。上班的路程大部分都可以顺利通过，但是，少数情况会花费2倍的时间，并带来很大损失。通常，你忘在家里的什么东西会很快想起来，但是，有时东西不在该在的地方会造成慌乱，耽误时间。8.3.280/20原则银行柜台的大多数交易相当迅速，但21主要路线为适应大多数情况，很可能相当迅速的设计业务过程，或是构建系统真正需要的是可扩展的构建良好系统的方法主要路线为适应大多数情况，很可能相当迅速的设计业务过程，或是22主要路线通常能确定一条带有几个分支的最常用的路线“快乐之路”(happypath）主要路线是大多数时候使用的路线，如果能识别出它，就可以使过程中的大多数用户感到满意。降低的复杂性，阻止了“分析瘫痪”主要路线通常能确定一条带有几个分支的最常用的路线“快乐之路”23替代路线一旦知道了系统的主要路线，便可以寻找替代路线。这些是常规的细微变化主要路线形成了一条有意义的核对单，能够用来寻找替代路线尽量使得替代路线返回主要路线替代路线一旦知道了系统的主要路线，便可以寻找替代路线。这些是24面向对象的Java与UML课件第-8-章业务建模25835异常异常通常是更为严重的替代路线。替代路线是例行发生的，只是不像主要路线那样频繁异常更为罕见，需要不同层次的恢复替代路线允许通过另一路线实现目标，异常以从未实现的目标告终在网上订购系统中，或许有这样一个例子：某人提交了骗来的信用卡。对这一情况的响应也许是接受详细信息和订单，但不是发货，而是通知警察。835异常异常通常是更为严重的替代路线。26过程分析的基础1．找出关键活动（用例或业务过程2．为每项活动定义主要路线3．使用主要路线寻找替代路线4．补充替代路线，只要可能就返回到主要路线5．使用主要路线和替代路线来标识异常记住这一序列，这就是“分析主要路线”。过程分析的基础1．找出关键活动（用例或业务过程27使用活动图进行业务建模将由主要路线和替代路线得到的剧本转化成UML活动图来描述业务。活动是业务过程中的一项任务，是一段有实际意义的工作打印发票更改订单联络客户许多连在一起的活动形成过程，工作流使用活动图进行业务建模将由主要路线和替代路线得到的剧本转化成28转换、事件与决策工作流从一项活动流向另一项活动,在活动之间用箭头表示简单转换事件转换转换、事件与决策工作流从一项活动流向另一项活动,在活动之间29转换、事件与决策有时，替代路线由一些条件所决定。为了表示这一点，图中放置了一个决策点，用菱形表示。转换采用哪一条替代路线由写在退出路线旁边方括号内的条件来决定。转换、事件与决策有时，替代路线由一些条件所决定。为了表示这一30转换、事件与决策转换、事件与决策31状态状态是一项什么也不发生的活动。状态用圆角矩形表示下图给出了支付过程中的一个状态，过程在这一状态等待顾客付款。有两种专门的状态用于帮助表示过程。开始状态是系统初始化，一幅图中通常只有一个。终结状态表示过程的结束。有时，终结状态多于一个。初始状态用黑色圆点表示，终结状态则用一个圈中套一个小实心圆来表示。状态状态是一项什么也不发生的活动。32实现获得支付过程的简单活动图实现获得支付过程的简单活动图33泳道活动图的另一个特点是泳道用来表示活动发生的某些业务领域。泳道是活动图中的一列，其标题代表了不同的业务领域泳道活动图的另一个特点是泳道34面向对象的Java与UML课件第-8-章业务建模35过程目录既然有了模型范围，即过程图、过程剧本和活动图，便可将它们组织成过程目录。过程图提供概貌，目录则提供细节。每个与系统开发相关的过程在过程图中都有相应的条目。每个条目都包含下列信息：主要路线替代路线异常活动图过程目录既然有了模型范围，即过程图、过程剧本和活动图，便可将36名词辨识法业务对象名词辨识法业务对象37初步状态图建模初步状态图建模38ICANDOICANDO化学制品需要一个新系统来改善其销售过程。特别是他们的业务计划表明了销售与生产之间的整合更为紧密。通过高级订单的专有折扣结构，计划增加直接从生产线发货的数量，以减少运输仓储费用和库存中占用的流动资金。因此，要扩展过程图来包含生产与销售的过程。ICANDOICANDO化学制品需要一个新系统来改善其销售39面向对象的Java与UML课件第-8-章业务建模40过程描述过程图构建完毕后，就需要做出过程描述。在这里，全面地进行描述意义并不大。但是，对一些特别有意思的过程仍然应当加以考虑。销售/订货/预留库存销售/发货/调整发货数量销售/订货/电子订单过程描述过程图构建完毕后，就需要做出过程描述。在这里，全面地41业务剧本电话销售主要路线l.顾客打电话给呼叫中心。2.代理记录顾客号，确认系统中的顾客号。3.顾客提供订单详细信息，代理在计算机屏幕上按照顾客订单的格式录人汀单的细芍4.顾客提供请求交货日期。5.系统使订单生效并确定能否在那一天交货。系统可能提供另一个日期，顾客可以接拒绝。6.代理再次阅读订单细节。7.顾客同意。8.挂断电话。业务剧本电话销售42业务剧本电话销售替代路线2.1系统不接受该顾客号。代理与顾客验证号码。如果顾客认为没有错误，接到销售组由他们处理这一问题。3.1提供了系统不能识别的产品订单代码，代理反复核对产品目录，确保顾客没有提供错误的代码。若找到正确的号码，则继续处理。若未找到，在最后，要被转接到销售组。3.2订单可能超过顾客的信贷限额。代理将征求顾客意见，减少订货。如果客户打算增加信贷限额，电话将转接到销售组。5.1系统无法为顾客提供合适的日期。顾客取消汀购。相关记录将发送到销件组来联系顾客，争取拿到订单，比如通过提供特惠折扣的方式。6.1顾客注意到订单有错误。代理更正错误，将订单重新读给顾客听。异常2.2系统不可用，代理将顾客的要求记录在纸上，当系统恢复联机时继续过程。业务剧本电话销售43业务工作流业务工作流44销售/发货/调整发货数量主要路线1.查看发货车辆上的计量器读数(若适当，设为0)2.查看接收容器上的计量器读数(若适当.设为0)3.将产品从发货车辆上卸到接收容器内。4.查看发货车辆上的计量器读数，计算发货量。5.查看接收容器上的计量器读数，计算发货量。6.确保两月月卖数相差不到2%7.顾客接货后，让顾客签字。替代路线6.1两个读数相差超过2%，则讨量器需要校准。记录读数差，并请顾客签字。异常7.1顾客拒绝签字。司机应与仓库联系，询问处理办法。销售/发货/调整发货数量45业务工作流业务工作流46业务对象模型业务对象模型47第8章业务建模业务环境的重要性制订业务过程的方法与符号.UML活动模型及在描述业务过程中的应用业务对象以及一些UML类标识符初步UML状态图建模第8章业务建模业务环境的重要性48概述在本章中我们将详尽地介绍根据业务过程来概述一项业务的方法概述在本章中我们将详尽地介绍根据业务过程来概述一项业务的方法49项目特征对业务建模的影响当应用于某个新的业务领域，或是为某位新客户而开发的，那么，详尽的业务分析是非常重要的。应用于某个已制定的业务领域，并且开发悉这一业务领域，那么，一种不十分严格的业务分析或许更为实用系统的大小和范围也决定了需要进行业务建模的层次；由于项目风险和失败的代价相对较小，因此，规模较小的系统开发可以不做或只做少量的业务分析项目特征对业务建模的影响当应用于某个新的业务领域，或是为某位50业务建模这里所讨论的技术将会用于生成业务模型。模型将作为系统分析阶段的输入开发精确的成本效益模型业务过程建模、成本效益建模和系统分析这三者间的关系业务过程建模的关键输出是业务过程定义（包括过程图），以及在随后的阶段中用到的业务对象模型。我们应把UML活动图作为描述业务过程的一种方法业务建模这里所讨论的技术将会用于生成业务模型。51面向对象的Java与UML课件第-8-章业务建模52业务建模的大概过程要导出业务过程的全局图，该图给出了需要建模的业务领域的概貌以及展示了我们最终计划在何处引人一个新的IT系统。将应用剧本分析来分析相应的业务过程。这一过程将捕获业务过程的大量细节，并用特殊方式来组织这些细节。从剧本中，我们可以得出业务工作流，这些工作流可以用UML活动图来描述。我们还可以得出业务对象模型，该模型标识了业务环境中的一些关键条目。在实际开发中，许多组织也会忽略这一阶段，或是以有限的方式执行，在后续的开发中导致疏忽，这种疏忽会在测试或部署阶段暴露出来业务建模的大概过程要导出业务过程的全局图，该图给出了需要建模53面向对象的Java与UML课件第-8-章业务建模548.1理解业务过程的重要性分析业务环境时，一个常见的问题是“为什么要问所有那些和系统并不直接相关的问题？关于这个问题有多种回答。最重要的是，理解一个系统需要理解他所运行的环境。不然的话，开发出的系统很可能无法正常工作。许多计算机系统开发的失败正是因为忽略了这一简单的常识。先业务领域，再系统用途8.1理解业务过程的重要性分析业务环境时，一个常见的问题是“55建立业务过程图分析人员需要首先做的事情之一是询问“我在哪里？”或者更具体一些：“我在构建一个系统，它适合哪种类型的业务？”现在，我们应当着眼于构建一张“大图”，即某项业务的过程图。这对于商定系统范围是尤为重要的。过程图不会很具体和精确，它应该是全面它能迅速获得业务范围和活动的总体印象过程图是是剧本分析和识别用例建立业务过程图分析人员需要首先做的事情之一是询问“我在哪里？56一幅三层的业务过程图业务过程是对事件的逻辑归类，这些事件被认为是业务的基本元素尽管随着过程图的建立，一些过程会出现严格的先后次序，然而我们的目的是将整个的业务领域作为一个过程集进行描述，而并不关心过程的次序或单个过程之间的交互作用。这些过程将在不多于三个层次上被分组。经验表明，过于细致的分类所获得的成果反而较少，并且会陷于过多的细节中。高层的过程是总的过程，涵盖了业务活动的广泛领域，并由更集中的过程组成。一幅三层的业务过程图业务过程是对事件的逻辑归类，这些事件被认57过程图的顶层分解顶层不应多于10个高层过程，这些过程应当跨越全部的业务活动——使得分析集中在对业务关键方面对于IcANDO化学制品，这些活动应为：过程图的顶层分解顶层不应多于10个高层过程，这些过程应当58过程图顶层分解的说明在抽象层，这些是公司行为总的划分。这种划分或许过于明显，然而经验表明，这样划分容易取得广泛的一致。对于顶层的分解可能会有实质性的争辩。这里没有“正确答案”，所需要的是一种良好的分解，而并非是完美的分解。过程图往往要隐藏组织的结构，而仅仪描述组织的功能信息流的疏忽和时间因素的重要性不能被过分强调。在一个组织做什么这一方面，很少存在争议；但对于如何做，争议却总是存在。过程图顶层分解的说明在抽象层，这些是公司行为总的划分。这种划59过程图的第二层描述过程图的第二层分解，使其成为第一层活动更细致的描述销售活动的分解为：合同磋商―与谈判以及与顾客签订合同有关的所有活动．订货―与订货有关的所有活动货物交付―与交货有关的活动接受退货―与退回不想要的或不满意的货物相关的所有活动给顾客开发票―与开发票相关的所有活动接受付款―与接受付款有关的所有活动过程图的第二层描述过程图的第二层分解，使其成为第一层活动更细60过程图的第三层描述最后，第二层活动可以分解为第三层的分组“开发票活动”可以分解为标识已发送的和已接受的货物给货物定价申请折扣打印发票寄送发票试图分解第四层的实际经验表明达成一致是非常困难的，并越来越关系到某一业务是如何操作的，而并非该业务做什么过程图的第三层描述最后，第二层活动可以分解为第三层的分组61目前为止定义的所有过程层次的过程图目前为止定义的所有过程层次的过程图62822业务过程图的应用能够与业务人员一同构建模型，不考虑计算机系统的操作，实际上是不考虑任何软件设计问题。容易达成到三层的共识。以这样一种方式总结某一业务，通常可以打印在一张单独的A4纸上，并提供可管理的讨论框架。过程图阐明了专有名词。利用从高层次视角了解业务运作的人员，模型可以在2至3天内构架起来。尽管这是业务的系统视图，但不需要介绍就能够使任何人都很容易理解。过程图达成了一致，并且强调了共性方面。集中在功能方面，可以作为企业流程再造的基础822业务过程图的应用能够与业务人员一同构建模型，不考虑计算63823绘制过程图研讨会方法被证明是成功，方法如下：需要有一个协调者，他清楚过程图的概念。一组业务管理人员和／或专家聚集在一起，在极短时间内安排一系列的研讨会。每个研讨会持续时间不超过半天，要集中于模型的一层，或者确定顶层过程，或者确定一到两个顶层过程对应的第二层过程，或者确定一到两个第二层过程对应的第三层过程823绘制过程图研讨会方法被证明是成功，方法如下：64823绘制过程图研讨会需要严格地限定时间范围（timeboxed）。协调者要记下过程列表，并且得出单独过程的简要总结。协调者不应对决定施加影响823绘制过程图研讨会需要严格地限定时间范围（timeb658.3业务剧本分析剧本是一系列的事件和活动。方法是将任何过程分解为简单的序列剧本的多样性考虑从当地的花店买花这一事件时，可以有非常多的方式来完成该件事一一你可以去花店或是通过电话订购；你可以自己取花，或是让助手去取。花也可以包装成各种不同的形式，可以附有问候标签。你可以用现金、支票或信用卡支付；你既可以拿走这些花，也可以将它们递送出去搜集具有代表性的，将他们组织起来8.3业务剧本分析剧本是一系列的事件和活动。66沏茶的剧本1．灌满水壶2．烧水3．把茶叶放人茶壶4．倒人开水5．等2分钟6．把茶倒入茶杯7．加奶和糖并非所有人都这样沏茶。有些人用袋茶在杯子里泡茶，有些人等不到2分钟，有些人不加糖。假如你设计一个沏茶系统那么你应考虑许多剧本。沏茶的剧本1．灌满水壶678.3.280/20原则银行柜台的大多数交易相当迅速，但是，少数几笔交易花费了职员4到5倍的精力。上班的路程大部分都可以顺利通过，但是，少数情况会花费2倍的时间，并带来很大损失。通常，你忘在家里的什么东西会很快想起来，但是，有时东西不在该在的地方会造成慌乱，耽误时间。8.3.280/20原则银行柜台的大多数交易相当迅速，但68主要路线为适应大多数情况，很可能相当迅速的设计业务过程，或是构建系统真正需要的是可扩展的构建良好系统的方法主要路线为适应大多数情况，很可能相当迅速的设计业务过程，或是69主要路线通常能确定一条带有几个分支的最常用的路线“快乐之路”(happypath）主要路线是大多数时候使用的路线，如果能识别出它，就可以使过程中的大多数用户感到满意。降低的复杂性，阻止了“分析瘫痪”主要路线通常能确定一条带有几个分支的最常用的路线“快乐之路”70替代路线一旦知道了系统的主要路线，便可以寻找替代路线。这些是常规的细微变化主要路线形成了一条有意义的核对单，能够用来寻找替代路线尽量使得替代路线返回主要路线替代路线一旦知道了系统的主要路线，便可以寻找替代路线。这些是71面向对象的Java与UML课件第-8-章业务建模72835异常异常通常是更为严重的替代路线。替代路线是例行发生的，只是不像主要路线那样频繁异常更为罕见，需要不同层次的恢复替代路线允许通过另一路线实现目标，异常以从未实现的目标告终在网上订购系统中，或许有这样一个例子：某人提交了骗来的信用卡。对这一情况的响应也许是接受详细信息和订单，但不是发货，而是通知警察。835异常异常通常是更为严重的替代路线。73过程分析的基础1．找出关键活动（用例或业务过程2．为每项活动定义主要路线3．使用主要路线寻找替代路线4．补充替代路线，只要可能就返回到主要路线5．使用主要路线和替代路线来标识异常记住这一序列，这就是“分析主要路线”。过程分析的基础1．找出关键活动（用例或业务过程74使用活动图进行业务建模将由主要路线和替代路线得到的剧本转化成UML活动图来描述业务。活动是业务过程中的一项任务，是一段有实际意义的工作打印发票更改订单联络客户许多连在一起的活动形成过程，工作流使用活动图进行业务建模将由主要路线和替代路线得到的剧本转化成75转换、事件与决策工作流从一项活动流向另一项活动,在活动之间用箭头表示简单转换事件转换转换、事件与决策工作流从一项活动流向另一项活动,在活动之间76转换、事件与决策有时，替代路线由一些条件所决定。为了表示这一点，图中放置了一个决策点，用菱形表示。转换采用哪一条替代路线由写在退出路线旁边方括号内的条件来决定。转换、事件与决策有时，替代路线由一些条件所决定。为了表示这一77转换、事件与决策转换、事件与决策78状态状态是一项什么也不发生的活动。状态用圆角矩形表示下图给出了支付过程中的一个状态，过程在这一状态等待顾客付款。有两种专门的状态用于帮助表示过程。开始状态是系统初始化，一幅图中通常只有一个。终结状态表示过程的结束。有时，终结状态多于一个。初始状态用黑色圆点表示，终结状态则用一个圈中套一个小实心圆来表示。状态状态是一项什么也不发生的活动。79实现获得支付过程的简单活动图实现获得支付过程的简单活动图80泳道活动图的另一个特点是泳道用来表示活动发生的某些业务领域。泳道是活动图中的一列，其标题代表了不同的业务领域泳道活动图的另一个特点是泳道81面向对象的Java与UML课件第-8-章业务建模82过程目录既然有了模型范围，即过程图、过程剧本和活动图，便可将它们组织成过程目录。过程图提供概貌，目录则提供细节。每个与系统开发相关的过程在过程图中都有相应的条目。每个条目都包含下列信息：主要路线替代路线异常活动图过程目录既然有了模型范围，即过程图、过程剧本和活动