
3.2.3 业务过程模型
在UML中,最主要的UML扩展就是对业务流程的扩展,提供了业务流程图和模型元素两个层次的扩展。
1.业务流程图(Business Process Diagram)
业务流程图是一种以UML类图为基础定义的扩展,其构成元素涵盖了业务系统的目标、资源、业务过程和业务规则等核心概念,使用业务流程图可以从总体上描述一个业务系统的业务流程,描述一个业务系统中各个构成要素之间的关系。可以说业务流程图是业务模型中最重要的一种模型图。
业务流程图中可以使用的模型元素包括业务系统的目标、各种资源和业务过程,以及相应的业务规则,同时包含描述这些模型元素之间关系的模型元素。
例如,图3-2给出了一张业务流程图示例,图中的图书在线销售(Sell Books On-Line)和顾客订单管理(Manage Customer Order)就是两个业务过程。它们是这张图的核心元素。

图3-2 业务流程示例
其中,用户请求(User Enquiry)和客户订单(Customer Order)是两个业务事件,分别用于触发这两个相应的业务过程。接受客户订单(Take Customer Order)和配送订单(Ship order)分别是这两个业务过程的目标。图中的Web页(Web Pages)、图书目录(Book Catalogue)和运输公司(Shipping Company)分别是这两个业务过程的三个支持对象。库存(Warehouse Inventory)则同时是这两个业务过程的输入对象。订单(Order)和付货单(Delivered Order)则分别是这两个业务过程的输出对象。
整个图在较高的抽象层次上,完整地表达了一个企业的业务流程。
2.业务过程(Business Process)
业务过程(Business Process)是业务流程图中最重要的模型元素,表示特定的业务过程。业务过程通常与一系列资源对象相关联。同时,由于业务过程本身也是一个活动集合,因此也可以使用UML活动图建模业务过程的具体细节。
与UML活动图中的活动一样,一个业务过程通常会被分解成若干个业务活动,其中复杂的业务活动又有可能被分解成若干个相对简单的业务活动,不能分解的则被称为是一个原子的业务步(Process Step)。这意味着业务过程是可分解的,即一个业务过程还可能蕴含着更多的子过程。
图3-3给出了一个嵌套的业务过程的例子。图中展示了一个名为Process1的业务过程,该过程定义了一个由三个步骤构成的业务过程,其中前两个步骤是(Activity1和Activity2)是原子的业务过程,最后一个步骤(Process2)是一个包含了两个原子的业务过程(Activity3和Activity4)的过程。

图3-3 嵌套的业务过程
显然,对业务过程建模可以定义或分析业务系统中的业务活动。按照业务活动在业务过程的作用,可以将业务活动划分成直接、间接和质量保证三种类型。
直接活动是直接参与产品或服务创建的活动,产品或服务是业务过程创造的价值。
间接活动是支持直接活动的活动,包括维护、管理和计划等活动。
质量保证活动是保证其他活动质量的活动,如检查、控制、评价和审查等活动。
对这些业务活动的分类是业务建模工作内容之一。这样的分类也导致了对业务过程的分类,如主营业务、支持业务和质量保证业务。业务过程还可以以其他方式进行分类,如开发、改进或管理过程。
活动图中的接收(Receive)和发送(Send)等动作也可以出现在业务流程图中,分别表示接收和发送业务事件。发送表示生成和发送事件;接收表示正在等待特定事件的发生,以触发特定的业务事件。图3-2中就使用了用户请求(User Enquiry)和顾客订单(Customer Order)这样的接收动作。
3.目标(Goal)
在业务流程图中,除了表示业务过程这样最重要的模型元素之外,比较重要的元素还有业务过程的目标。它们可以被表示为带有《goal》构造型的UML类(或对象)。
目标对象表示特定业务过程的目标,可使用指向目标的并带有《achieve》构造型的依赖与特定过程相连,表示进程试图实现的目标。
图3-2中也包含多个这样的目标元素。与目标相联系的是目标的分解和实现目标需要解决的问题,可以使用业务模型中的目标/问题模型描述。可以使用扩展的UML类图表示目标/问题模型。在图中,使用类来表示目标和问题,使用类之间的依赖表示目标分解和实现目标需要解决的问题,也可以使用模型元素的文档、注释、约束等特性描述模型的各种细节。
4.资源(Resource)
在业务流程图中,同样重要的模型元素是业务资源,它们被表示成带有《business》构造型的UML类(或对象)来表示。
资源可以按照资源类型分成输入对象、输出对象、供应对象和控制对象等多种类型。可以用《physical》《abstract》《people》或《information》等构造型标识这些资源对象的具体类型。
输入对象通常是业务过程消耗或加工的对象。它们使用从输入对象到业务过程的带有构造型《input》的虚线表示输入对象与业务过程之间的关系。与此类似,也可以使用同样方式表示输出对象(过程生成的对象)、供应对象(参与了进程但并没有被加工或消耗的资源对象)以及控制对象(控制或运行业务过程的资源对象)等与业务过程之间的关系。通过对输入对象进行的加工,业务过程可以改变输入对象的位置、外观、内容或所携带的信息。
有时,很难将输入对象与供应对象严格地区分开来,因为在业务过程中,供应对象也可能会改变它的状态。二者本质的区别是:输入对象是关键对象,该对象被加工或消耗以便生成输出对象;供应对象只是业务过程所需要的对象,它参与了业务过程,以便能够执行这种加工或消耗。例如,在制造过程中,原材料是输入对象,业务过程中使用加工设备则是供应对象。
另外,输出对象与输入对象可能具有相同的类型,但具有从过程中产生的附加值。
用于描述资源对象及其相互关系模型叫作资源模型(Resource Model),资源模型也是业务过程模型的辅助模型。它们与业务过程元素之间具有多种不同的关联或依赖关系。这些关系包括输入(Input)、输出(Outout或Outcom e)、支持(Support)、使用(Us e)和控制(Control)等多种类型。
5.业务事件(Business Event)
从系统的角度来说,事件是指系统内部或其环境中发生的某件事情。对于业务系统来说,业务事件则是对系统内业务过程有影响的事件,特定的事件将激活某个特定业务过程。所以,业务事件也可以视为触发或控制业务活动运行的触发器。
业务事件对业务过程的影响可以分成触发、结束或中止业务过程三种。
对于业务过程来说,业务事件的来源并不重要,重要的是业务过程如何响应这些业务事件。很多最重要的业务事件通常都来源于企业的外部过程,如来源于用户的订单、支付、投诉,来源于分销商的交货,或来源于竞争者的产品发布和降价等过程生成的事件。需要分析事件的属性和行为特征时,可以使用类图描述。
业务模型中,使用带有构造型《Business Event》的类(或对象)表示业务事件,并使用泛化描述业务事件的层次。图3-4给出了一个用于描述一组业务事件的类图,图中使用泛化表示了这些业务事件之间的层次关系。

图3-4 业务事件及其层次关系
6.概念建模(Conceptual Modeling)
概念模型定义了业务系统中使用的重要概念及其相互关系。为业务系统建立了一个通用的词汇表。通过概念模型,避免不同的人对这些概念的不同理解和解释。
在概念模型中,用于描述对象的名词术语、概念和现实世界中的对象之间往往是有差距的,建模时应注意它们之间的差别。
例如,汽车这个词汇只是名词术语;当需要考虑如何准确地定义或说明汽车这样一种事物时,考虑的就是如何定义一个概念,可以把它定义成一种与发动机、汽车底盘和车轮相联系的一种交通工具;当需要考虑汽车的结构、性能和行为等方面的特征时,汽车这个词指的可能就是一个类,此时可能要考虑的是汽车的种类,它应该有哪些属性及还要有哪些方法。
与类模型相比较,概念模型应该是一种更高层次的抽象。业务模型中,是将概念模型使用类图表示。
可以使用标准的UML类图来表示概念模型。在这样的概念模型中,可以使用类图模型中的各种元素表示业务系统中的概念和概念之间的各种关系。
使用类图描述某个概念时,可以在类的标准文档属性(如Document或Specifaction属性)中使用文本来描述这些概念,也可以为概念添加必要的属性(Feature)来描述这个概念所具有的某方面的特性,这样就可以为概念提供一个准确的描述。随后,为这些概念定义的名字就可以被描述业务的其他模型或文档引用了。
需要注意的是,一张类图并不一定能描述了所有的概念及其相互关系。事实上,一个完整的概念模型可以被建模在多张类图中。在建模过程中,随时都有可能向模型中加入新的概念和关系。
需要指出的是,概念模型中的类属性和类操作并不像描述软件类的类图中的那么重要。概念模型关注的是准确地捕捉这些概念以及它们之间的相互关系。如果属性和操作有助于刻画这些概念,就可以将它们添加到相应的概念中。
总之,一个完整的业务模型中可以包含多种不同的模型,其核心要素是描述业务系统的目标、过程、资源等概念,以及定义在这些概念上的业务规则。典型的业务模型包括业务过程模型、目标模型、资源结构模型等。实际建模一个业务系统时,可根据需要建立能够满足建模目的的业务模型。