第8章 业务模型课件

第8章业务模型8.1业务模型概述8.2业务建模的目的及内容8.3业务建模流程和任务8.4业务建模中使用到的UML元素和版型8.5业务建模举例 8.1业务模型概述

业务模型是建立软件系统时所依据的现实世界或者问题域模型，是建立软件系统的基础。业务模型的正确性是保证最终的软件系统能够满足业务需求的前提条件。一般来说，业务模型是完全忠实于现实世界或者问题域的，是现实世界或者问题域中规律的真实体现和反映。系统模型和业务模型之间的关系是依赖关系，如图8.1所示。图8.1软件系统对业务模型的依赖性业务模型和系统模型的区别在于业务模型一般与计算机系统或者实现环境无关，但与分析方法有关。分析方法则与计算机系统及实现方法有关，如数据流、实体关系、对象关系等，所以分析方法是业务模型和系统模型之间的桥梁。

在现代软件工程方法中，建立业务模型的工作显得越来越重要。在传统的软件工程方法中，是在需求分析阶段进行建立业务模型的活动。用来建立业务模型的主要工具是系统业务流程图、数据字典和E-R图。在现代的软件工程中，建立业务模型的工作被划分成一个独立的阶段任务。在RUP中，业务建模是核心工作流中的第一个工作流。使用UML进行业务建模时常用的工具是类图、活动图等工具，它们分别对应着传统软件工程中的E-R图和流程图。根据问题种类的不同，业务模型的内容有所不同。对于某个组织的信息系统来说，其内容一般包括组织目标、组织结构、业务岗位、业务职责、业务用例、业务流程、业务对象等；对于科学问题，其业务模型则应该包含着工程问题的目标及结构等，如大型结构计算问题，其目标是求解大型结构的受力和变形，业务对象包含了钢梁、桁架、连接件等；对于游戏类问题，其业务模型一般为游戏背景、游戏角色人物和游戏情节等。

本章重点以组织信息系统为例，分别就建立业务模型的目的和内容、业务建模流程以及业务建模中使用到的元素进行说明，最后给出一个业务建模实例。 8.2业务建模的目的及内容

8.2.1业务建模的目的

建立组织信息系统业务模型的目的在于：

(1)理解组织的目标，明晰目前存在的问题，标识出潜在的改进措施。

(2)评估组织业务变化的可能性和这种变化的影响范围。

(3)保证客户、用户、开发者和其他相关人员对组织有一致的理解。

(4)导出支持目标组织的软件系统需求。

(5)理解将要部署的软件系统怎样才能适合于组织的需求。组织业务是否需要改变取决于成本、质量、组织预期的上市时间等因素。业务建模要确定组织当前存在的问题，标识需要改进的环节。一个健壮组织的特征就是要能够根据业务的改变而及时进行组织调整，即实现所谓的“业务驱动”。

组织目标是该组织要实现或者要达成的目标。组织结构是实现组织目标的物质基础，它包含部门、岗位设置、业务组成等等。只有静态的组织结构图尚不足以理解业务是如何工作的，还需要使用业务流程等动态视图，因此业务模型应该涵盖组织结构的静态视图和组织中业务流程的动态视图。许多和项目相关的人，如投资者、开发者都需要理解业务。因为这些人有着不同的背景和兴趣，因此他们对业务的观察过程往往具有不同的视角，会得出不同的看法。在业务建模过程中，我们必须要使用通用的符号和简单易理解的方式进行业务建模，必须保证得出的业务模型能够支持不同的描述方式、能够适应不同的观察角度和不同的抽象级别。否则，业务模型的可理解性就会受到影响，而如果业务模型难以被人理解，则业务建模工作也就失去了意义。8.2.2业务建模的内容

在RUP的业务建模过程中，除了建立业务用例(businessusecase)模型和业务分析(businessanalyse)模型之外，还需要建立：

(1)业务愿景(businessvision)：包含业务目标、范围、前景等。

(2)业务体系结构(businessarchitect)：包括组织结构和业务结构。

(3)补充的业务规格说明(businessspecification)：主要的业务规格外的非关键的业务

要求。

(4)业务规则(businessrule)：包含了业务进行的约束和条件。

(5)业务词典(businessdictionary)：包含了业务系统中的主要业务术语及解释。8.3业务建模流程和任务

图8.2RUP中业务建模流程

(1)评估企业状态。该任务的目的是理解问题域，发现潜在的问题。即通过对当前业务过程、业务工具、业务技能、市场环境的分析，评估并描述组织的当前状态，描述为什么需要设计组织目标，标识出业务建模的参与者(BusinessActor)，通过业务建模，达到选择更高效的业务途径的目标。

(2)描述目前企业的业务状态、定义企业的业务体系结构，包括：

①业务体系结构分析：理解影响业务的关键因素，包括业务体系结构、业务模式、关键机制。该任务只对业务重构有用。

②业务操作分析设计：细化关键业务用例的业务操作，使用子系统动作和协作原理，将业务子系统之间的交互关系映射到业务设计模型的操作中实现。

③业务用例分析：对履行用例工作流所涉及的元素进行标识，包括业务系统、业务工人。使用业务分析用例将业务用例中的行为分配到这些元素上。要标识出业务系统和工人的职责、属性和关联关系、标识出业务实体和事件。④捕获公共业务词汇：定义公共业务词汇，用于有关业务的描述，特别是业务用例的描述中。

⑤构造业务体系结构：提出至少一个解决方案(也可能只是概念性的)来满足关键体系结构的需求。

⑥定义业务系统环境：基于业务用例模型，创建一个系统图，用于表示业务系统和业务参与者之间的顶层协作。其中业务参与者应当包括业务系统外部的I/O业务实体。

(3)对业务体系结构进行细化，建立域模型，为定义过程自动化准备，包括：

①细化业务实体：保证业务实体能够提供所需求的功能、性能，标识出触发业务实体的所有业务事件，评估业务实体之间的关系。

②细化业务用例：描述业务用例的工作流，保证业务用例足以支持业务策略，保证客户、用户、风险承担者都能理解业务用例的工作流。

③细化业务工人：描述业务工人的职责，标识业务工人的能力需求，保证业务工人可以履行职责。

④发现业务参与者和业务用例：定义出业务的边界，定义谁或者什么和业务交互，勾画业务流程，创建业务用例模型图，制定针对用例模型图的测量指标。⑤标识业务目标：使用自下而上的方法，标识出业务目标；标识出为实现业务目标所必需的业务计划和管理活动；将业务翻译成业务策略；提供度量和改进业务活动的基础。在此项工作中，要保证长期战略目标和短期运作目标的一致性。

⑥维护业务规则：确定项目中要考虑满足的业务规则，给出业务规则的细节定义。

⑦标识业务用例优先级：定义一组系统关键场景和业务用例，并标识出其优先级。

⑧将业务用例模型结构化：抽取抽象的业务用例，发现抽象的业务参与者(AbstractActor)。8.4业务建模中使用到的UML元素和版型

在采用UML进行业务建模时，经常要用到一些概念、元素和版型来提高建模效率，下面对此进行简要介绍与描述。

8.4.1业务系统(BusinessSystem)

业务系统封装了一组角色和资源，定义了一组职责。通过这些职责，能够实现一个具体目标。在RUP和UML中，通过包的特殊版型<<BusinessSystem>>来表示，其图标如图8.3所示。(版型Stereotype是UML的一种分类扩充机制，可以给元素增加更多的信息。)图8.3业务系统图标8.4.2业务目标(BusinessGoal)

业务目标是业务系统要完成或者达成的任务。在RUP和UML中，通过类的特殊版型<<BusinessGoal>>来表示业务目标。业务目标的图标如图8.4所示。图8.4业务目标图标图8.5业务目标细化举8.4.3业务规则(BusinessRule)

业务规则是指业务活动必须要满足的政策、条件和约束。它是业务模型或者业务需求中的一部分，它可能会涉及到法律或者规则，也可能是为了适应业务架构或者风格的需求。通常描述业务规则有两种方法可以选用：

(1)基于模型描述业务规则：业务规则作为UML模型中类的一种版型约束，如图8.6所示。规则可以使用自然语言声明或者使用更形式化的记号，如ObjectConstraintLanguage(OCL)来描述。这种方法的好处是业务规则和业务模型在一起，缺点是比较分散，难以观察相关联的业务规则，也不容易描述得非常精确。图8.6业务规则图标

(2)基于文档描述业务规则：业务规则在另一个文档中进行描述。优点是适于描述大量的业务规则，如金融产品；缺点是和业务模型的描述风格不一致。

例如使用OCL描述业务规则：团队成员不能超过10人。

contextTeaminv:

self.numberOfMembers<=10;图8.7激发和响应规则如何在模型中描述业务规则呢？可以分成以下几种情况进行描述：

(1)激发和响应规则：约束将被转换成业务流程图中的一个分支。例如在订单管理组织中，有如下规则：当订单被取消时，如果订单还没有发货，则关闭订单。该业务规则被反映到业务流程图中，如图8.7所示。

(2)操作约束规则：约束规则被转换成工作流的前提条件或者后置条件，或者可选路径，或者性能目标。

例如指定计算公式，产品的实价为：productprice*(1+taxpercentage/100)，计算产品实价是任务ShipOrder的一部分；发货给客户：仅当客户有发货地址时(等价于发货地址不能为空)，被转换成流程图的一个分支；客户咨询必须在24小时内得到响应，被转换成业务用例的性能目标。

(3)结构约束规则：该种约束影响业务实体实例之间的关系，可表示成两个业务实体之间的关联关系或者多重性约束。例如：一个订单至少必须包含一个产品，该规则被转换成订单和产品之间的一对多(1对1..*)的关联关系。

(4)推导规则：类似于其他规则，区别在于必须通过几步思考才能到达结论(非直接)。此规则暗含一个方法，被反映在工作流的某个活动状态中，并最终反映在业务工人或者业务实体的一个操作中。

例如，一个客户是好的当且仅当：寄给该客户的未付款发票不能超过30天。该规则对应到工作流中的一个可选的路径，在活动[评估客户]中包含一个方法来对客户进行判断，该方法需要计算未付款发票发出去的时间，并进行判断。因此，这一规则不是一目了然的或者十分显然的，属于“推导规则”，如图8.8所示。

(5)计算规则：类似于导出规则。区别在于该规则所对应的方法更加正式，更像一个算法。与导出规则一样，该方法需要被跟踪到一个工作流的任务(活动)中，最终转换成业务工人或者业务实体的操作。从图8.9中可以看出，计算净价格转换为业务工人客户代表的一个操作。图8.8业务规则中的推导规则图8.9业务规则中的计算规则情况8.4.4业务参与者(BusinessActor)

业务参与者是和业务交互的各种元素，代表着业务环境(区别于业务系统)中和业务有关的、由人或者事物扮演的角色。比如说业务客户、供货商、合作伙伴、潜在客户、上级相关部门、相关的外部信息系统等。业务参与者和业务系统的交互包括启动业务、提出需求、获取结果等等。

业务参与者用于定义系统边界(标识哪些是系统之外的因素，哪些是系统之内的因素)，描述和业务用例的交互过程等，是业务用例模型中的重要元素。在UML中，业务参与者使用对象的<<BusinessActor>>版型来表示，如图8.10所示。图8.10业务参与者8.4.5业务工人(BusinessWorker)

业务工人是指人、软件或者硬件的抽象。它代表着业务用例实现过程中的一个角色。业务工人通过和其他业务工人协作、响应业务事件、维护业务实体等方式来履行职责。

业务参与者和业务工人都是和系统有关的人、物的抽象，它们的区别在于业务参与者是系统之外的和系统有关的各种因素，而业务工人则是属于系统之内的，参与到业务用例实现过程中的因素，如企业采购过程中财务、库房等角色。

在RUP中，使用对象的特殊版型<<BusinessWorker>>表示业务工人，如图8.11所示。图8.11业务规则图标8.4.6业务实体(BusinessEntity)

业务实体是一个被动类，也就是它不会调用自己的方法，而是由其他类调用其方法。一个业务对象可以参与到多个不同业务用例的实现中，通常其生命周期比一个用例中的交互周期更长。在业务建模中，实体表示业务工人访问、检查、维护、产生等操作的对象。例如：订单、入库单、库存、账户等等。业务实体对象为参与不同用例实现的不同业务工人提供了共享的基础。在RUP和UML中，业务实体使用对象的特殊版型<<BusinessObject>>表示，图标如图8.12所示。图8.12业务实体图标8.4.7业务事件(BusinessEvent)

业务事件表示业务活动中的关键事件，由业务参与者、业务工人、业务实体接收。业务事件用于触发业务用例、通知业务状态的变化、在业务用例之间传递信息。业务事件具有如下特性：重要性、随机性、独立性、响应性。在RUP和UML中，业务事件使用对象的特殊版型<<BusinessEvent>>来表示，其图标如图8.13所示。图8.13业务事件的图标表示业务事件的触发方式有如下几种：

(1)由业务参与者触发，表示一个业务用例开始或者结束。如：当供应商交付货物时，一个交付事件指示交付货物业务用例开始。

(2)由业务实体触发，表示状态变化。如：作为招聘员工业务用例的一部分，候选资格业务事件指示一个潜在的雇员被检查通过了。

(3)由业务工人触发，表示业务用例实现中的一个特定点。如：一旦一个火箭被发射了，一个发射业务事件指示跟踪火箭轨迹业务用例开始。

(4)由时间触发。例如：病人出手术室六小时后，一个病人照看业务事件指示护士应该去检查病人。触发事件的类叫做发行者(事件源)；接收业务事件的类称为订阅者(事件处理者)。发行者和业务事件之间有一个版型为<<Send>>的依赖关系。

业务事件也可以关联多个业务实体，如产品。订阅者需要有一个操作，版型为<<BusinessEvent>>，名字和业务事件名字一样，参数则与业务事件的属性一样，如图8.14所示(<<BusinessEvent>>库存低(Stringwarehouse，Productp,IntegerStock))。也可以在业务事件和订阅者之间通过版型为<<Receive>>的依赖关系来导出上述方法签名。图8.14业务事件举例8.4.8业务用例(BusinessUseCase)

1．业务用例的基本概念

图8.15业务用例业务用例定义了一组业务用例实例。每个实例都是一组为获得对业务参与者有影响的结果的业务行为，或者是展示业务是如何响应业务事件以获得一个业务结果。业务用例是从业务系统外部的角度对业务过程的描述，它定义了业务系统的边界。业务用例是面向过程的业务规格描述，它包括了业务与业务参与者之间的交互和关键业务事件。在RUP和UML中，使用用例的特殊版型<<BusinessUseCase>>表示业务用例，参见图8.15。业务用例定义中经常会出现的一些词汇，解释如下：

(1)业务用例实例：是指业务的一次具体的执行过程。业务用例实例是一个具体的工作流或者情景，一个承担某种角色(岗位)的雇员可以在几个不同业务用例实例中做同样的事情。例如：在机场登记柜台，个人登记和团队登记业务用例都同样需要登记人员的服务，都需要访问同样的航班信息，因此这两个业务用例都被设计成使用同样的登记代理业务工人和航班实体。

(2)业务参与者：指参与业务的具体个体，如客户、供应商等。

(3)有价值的结果：据此可以确定业务用例的粒度，不至于太大或者太小。如维护商品信息和修改商品信息是两个不同粒度的用例。

(4)业务有关：只描述和业务有关的行为。

(5)业务行为：业务行为可以由参与者发出请求或触发(调用)，或者在某个时间被触发(调用)。

(6)业务用例命名：业务用例的名字应该是动态的，表示当业务用例履行时发生了什么事情。一般使用动名词短语来命名业务用例，如修改订单。业务用例的名字可以用来从外部观点或者内部观点出发描述业务用例的任务，例如接收订单。但最恰当的命名方法是从业务的主要参与者的观点出发来命名。一旦决定使用一种命名风格，对于业务用例模型中的所有业务用例都应该遵循该命名规则。

(7)目的/目标：可以从内、外两个方面描述业务用例的目标。从外部观点出发，指参与者所需要获取的价值；从内部观点考虑，则是从组织角度定义的该用例应达到的目标。

(8)性能目标：可以从下面几个方面考虑，如执行一个工作流或者部分工作流所花费的大约时间、花费或者成本、质量。例如：产品下线的次品率不能超过2%。

(9)工作流的结构：很多工作流可以进一步分成一些子工作流。有些业务用例有公共的子工作流。如果这些子工作流形成独立的和自然分割的部分，那么将这个子工作流分离出来，形成一个独立的用例会更清楚。这个新的用例或者被包含在原始用例之中，或者作为另一个用例的扩展，或者作为父用例。例如：在机场登记柜台，个人登记和团队登记用例使用同样的步骤来处理个人的行李。因为这个子工作流独立于处理机票，但逻辑上又是有联系的，因此被单独建模成一个用例“处理行李”。图8.16业务工作流活动图实例活动图的特点在于直观，但细节不够清晰，文字描述则比较细致。针对这一工作流，图8.16相应的文字描述如下：

(1)初次接触：该过程由客户和公司之间的初次联系启动。具体方式可以是由客户主动联系公司提出咨询或者请求，公司确定了自身的产品对客户有益，存在合作前景。也可以是通过公司与客户双方联系人作交流，分析是否是新客户，搜集有关本项目的建议信息及客户出价情况。

(2)前期准备工作：该环节具有收集客户请求、进行机会分析两个目的。其中收集客户初步信息、制定销售计划(可选)、进行可行性分析的工作可以迭代进行，也可以并行。应当通过与客户的初步交流，获取产品需求和客户业务需求。并通过机会分析判断项目是否可行。

一个完整的项目需求应当包括技术选择(可能有多个，如果客户想要几种替换方案)、产品参数、功能需求、期限、服务需求、价格需求等。机会分析包括机会风险(产品可用性、竞争性、客户风险)、ROI、机会类型(复杂、简单)、销售可能性、销售规模预测、估计进度。公司要根据这一阶段的工作结果，决定是否继续进行下一步工作。

(3)制定初步方案、撰写项目计划：如果判定项目可行，则要设计项目的初步方案，并指定专人制定项目计划书；如果认为当前了解的信息尚不足以作出项目是否可行的决策，则进一步通过和客户的交流，搜集确实的信息；如果判定项目在当前需求范围不可行，则考虑拒绝接受项目，也可以重新和客户进行协商变更项目需求规格或者提出引进合作伙伴的建议。

(4)制定并提交项目计划：针对本项目制定一个初步计划，其内容包括项目时间进度、可用资源、工程能力分析、开发新产品的可能性、采用第三方产品的可能性等等。

(5)项目报价：以分析方案为依据针对项目提出报价。

(6)搜集其他缺失的信息：收集并汇总客户需要的其他信息。如目前能力、将来的能力、项目必须符合的标准、目前和将来可能需要的服务信息等等。

(7)分析并审定方案：根据所了解到的各种信息，对初步方案进行审核确定。

(8)提交方案：将上述经审核确定的建议方案提供给客户方。

(9)获取客户决策意见：获取客户对方案、计划的最终反馈意见。如果客户持肯定意见，则可继续跟踪，直至签订合同；如果客户作出了否定决策，则中止售前工作。

2.业务用例规格说明(BusinessUseCaseSpecification)模板

业务用例使用过程结构或模板来描述，说明业务功能，这种描述也需要遵循一定的规范和模式。可供业务用例规格说明的模板有许多，但最核心的是必须要能够反映出该用例的本质特点、用例的交互过程、与其他用例或参与者的关系、用例的执行对系统的影响等内容。

下面是一种业务用例规格说明的模板举例：

名称：说明业务用例的名称。

简要描述：简要描述角色设置和业务目的。性能目标：和业务用例有关的性能要求，如“用户投诉需要在七个工作日中得到响应”。

工作流：业务用例所表示的工作流的文本描述。该工作流应该描述给业务参与者带来了什么价值，而不是描述怎么解决这个问题。

分类：核心、支持、管理。

风险：执行或者实现该业务用例的风险，并描述期待业务和已提供业务之间的区别。

可能性：估计改进的潜力。

过程拥有者：负责管理和计划改变。特殊需求：工作流中没有描述的业务用例特性和量化指标。

扩展点：事件流中多个位置，利用extend关系，可以扩展成其他功能。

支持的业务目标：表示该业务用例实现的业务目标。

关系：该用例参与的关系，如通信关联关系、包含和扩展关系。

活动图：描述工作流的图形。

用例图：描述该用例及其关系的图形。

工作流草图：手绘的草图或者情景讨论(storyboardingsession)结果。

如果业务建模仅仅是图示说明一个现存的目标组织，而不是为了改变它，可以不用描述性能目标、风险、可能性、过程拥有者。

3.业务用例结构及业务用例之间的关系

1)业务用例的泛化关系

某些业务用例之间存在着很大的相似性，例如银行挂失包含电话挂失、网上挂失、柜台挂失等，这些用例的实现过程有很大的相似性，此时可以抽取一个抽象的银行挂失用例作为父用例，抽取出所有挂失中公共的操作，在父类操作中有些可能是抽象的，例如输入挂失信息，这对于不同的挂失方法，其实现是不一样的，必须到子用例中才能实现。业务用例的本质是业务类，是一种业务过程类，所以在业务用例之间存在着泛化的关系。业务用例之间的泛化关系如图8.17所示。图8.17业务用例之间的泛化关系

2)业务用例的包含关系图8.18业务用例之间的包含关系

3)业务用例的扩展关系

有时候很难确定一个业务服务是一个还是多个业务实例。以机场登记为例，乘客将票和行李递给登记人员，后者为乘客寻找座位，打印登机牌并处理行李。如果乘客的行李属于正常范围，登记员打印行李单、客户认领凭证、登机牌，用例终止。如果行李超出正常范围如特殊形状或者特殊内容，因此不能正常托运，乘客必须将其拿到特殊行李柜台。如果行李很重，乘客必须为此到售票处缴费，因为登记人员是不收钱的。这里是需要一个业务用例还是三个业务用例呢？该业务包含三种动作类型(相当于三个分支)，但并不是对每个乘客都有价值(大部分的乘客不需要为行李额外缴费)。推荐将联系密切的服务放在一起，这样可以一起评审、修改、测试、写用户手册等。类似的例子有逛商店、浏览商品、购买商品、加入购物车、结账。图8.19业务用例的扩展关系

8.4.9业务用例实现(BusinessUseCaseRealization)

业务用例模型使用业务参与者(客户)和业务用例(业务过程)来描述业务。业务用例模型包含工作流描述，这标识了该业务做什么(what)，而不是怎么做(how)。业务用例怎么做是在业务分析模型中实现的，具体的说，是在业务用例实现中才去描述怎么做的问题。

业务用例实现描述了业务系统、业务工人、业务实体和业务事件是如何协作来完成一个特定的业务用例的。同一个类的实例可以参与到多个业务用例的实现中。

在RUP和UML中，业务用例实现使用用例的特殊版型(BusinessUseCaseRealization)来表现，如图8.20所示。图8.20业务用例实现的图标业务系统是业务部门、业务工人和业务实体的层次结构的封装。业务系统之间的交互可以只在业务系统边界进行，而不去暴露其内部细节。仅在特殊情况下，也可以和某个业务系统中的元素进行交互。

通常使用活动图、类图、顺序图等工具来描述业务用例的实现。活动图是描述业务用例实现的首选方法。可以使用活动图中的泳道(swimlane)来代表业务系统或者业务工人。一个用例实现可以使用多个活动图来描述其工作流。也可以使用交互图来描述业务用例实现中的业务系统、业务工人、业务实体等之间的交互情况。交互图包括顺序图和通信图两种。通信图是UML旧版本中的协作图(CollaborationDiagram)，它们表达同样的信息，但仍有所不同。顺序图表示一个显式的事件序列，在描述复杂情景时，比活动图有优势，它可以一直对应到对象的操作。通信图表示对象之间的连接关系和通信信息。如果分支较少，但业务实体较多，交互图比活动图能更好地显示业务实现的工作流。也可以使用类图描述参与用例实现的业务系统、业务工人、业务实体及其关系。8.4.10业务用例与业务用例实现的区别

在用例驱动业务建模过程中，可以从两个角度描述业务：业务用例和业务用例实现。

业务用例表示业务的外部视图，定义履行该业务必须的操作以及参与者与业务的交互。业务用例的描述不涉及业务实际的内部结构。业务用例也描述业务事件及其业务状态的变化，但不描述状态是如何被建立和维护的，或者业务事件在内部是如何传递的。就这一点而言，有点类似于事件机制，程序员只关心事件什么时候或者在什么情况下产生、如何传递、怎么响应，而不关心其内部是如何产生和维护的。也类似于异常机制。通常人认为用例和用例实现是事物的两个方面：外部和内部。但所谓内、外的概念也是相对的，例如针对程序员和开发环境的用例说明，对于最终用户来说是用例实现。业务用例实现给出业务用例工作过程的内部视图。由相关的业务工人、业务实体及交互组成，定义了业务用例怎样实现(how)，与业务用例规格描述(what)是一致的。

总之，业务用例的两种视图主要是为业务相关的人员设计的，包括为业务用例外部的人员设计的外部视图，为业务用例内部的人员设计的内部视图。

8.5业务建模举例

8.5.1业务目标(