关键字：业务过程重建 UML 电子商务的出现为企业的发展带来新的机遇和挑战，在新的环境下需要对企业的业务过程进行重建。业务过程重建是为了取得突破性改变而对业务过程进行根本性改变的研究与实现过程。它包括四个工程级：业务工程、系统体系结构工程、业务对象组件工程和应用工程。它们分别对应于系统开发中的四个主要活动：业务建模、系统建模、业务对象建模和实现。

面向对象业务过程的体系结构

业务过程重建不同于传统的对工作内容和形式的改进，后者是对已有的东西进行调整并始于此，而业务过程重建不是一个自底向上的连续变化过程。进行业务过程重建时，着眼于未来逆向进行工作，并不受已有方法、人员和组织结构的约束。这一工作往往开始于这样看似不切实际的问题：“如果新建一家公司或机构，我们将如何运作，结果会怎样？”

业务过程重建是一系列工作的集合，一般大型机构进行业务过程重建时要作的努力包括以下工作：重新定义工作岗位、建立新的认知体系、人员培训、修改财务体系、处理生产、订货和供货方式等等。

BOOSTER*PROCESS是用于面向对象业务系统开发和业务过程重建的参考模型。该模型给出的系统开发的基本原则是当今普遍使用的面向对象软件技术和UML设计者推荐的——用例驱动的原则、迭代和增量的方法，以及业务对象系统开发的多层方法。多层方法包括四个主要活动，即业务建模、系统建模、业务对象建模和实现，分别对应BOOSTER*PROCESS多级体系结构中的各级：业务工程、系统体系结构工程、业务对象组件工程和应用工程，如图所示。

业务工程

系统开发生命周期始于业务工程，包括对业务目标、规律、结构、资源、行为和工作流等建模，即进行业务建模。业务建模覆盖了业务需求和目标、业务组织、业务过程、领域方式等。业务工程的核心是对快速发展或已经发生变化的业务需求（包括业务目标、范围、策略等）进行建模以改造已有的业务过程，满足新的业务需求。业务建模可分为四个子活动：分析和需求建模、组织建模、业务过程建模和企业分布式建模。

系统体系结构工程

业务工程之后是系统体系结构工程。体系结构建模的目的是定义强壮、稳定的主框架，在其中可以开发、重用并操作应用和业务对象组件。系统体系结构建模涉及逻辑系统体系结构的设计及用户接口、服务和信息模型的设计。它一般包括系统体系结构建模、用户接口建模、服务建模和信息建模。

业务对象组件工程

业务对象组件工程活动过程中可能会伴随一些应用工程活动。但这二者不一定总是同时出现，有时也会根据需求用业务对象设施（BOF）单独产生组件。BOF的核心是创建能直接表达业务语义的业务对象作为高级结构，这些结构就是BOCA组件，BOCA组件的种类有业务对象、子系统、从属性和设备。它可以用来表达业务和业务系统需求，也可以表示业务对象互操作性主框架的基本功能。在这一阶段，应提交公共的或专用领域的或企业专用的组件，提交活动应是迭代的和增量的。为了使组件适宜于重用，应对其建立文档，增强可读性，使之易于被重用者所理解并使用；组件定义语言（Component Definition Language）是此建档的专用工具。此外，为了提高可重用性，该阶段产生的规格说明应与业务工程阶段产生的业务概念相匹配，包括对业务对象组件的外部设计。

应用工程

在应用工程阶段中，实现各个具体的业务应用，这也是整个业务过程重建的实现阶段。它通过支持业务过程直接服务于业务。该阶段的活动包括面向对象技术中的实现和测试等典型活动，并且往往也是迭代地执行。

如何用UML为业务过程建模

由于UML对系统的静态结构、动态行为和系统内部的交互关系都有较强的表达力，可以使用UML为业务过程重新建模。在不同的四个工程级，可以使用不同的UML图及其内置的扩展机制以及用于业务建模的UML标准旁集（UML Standard Profile）。

在业务工程中使用UML图

由于业务工程的主要目的是捕获业务需求和目标、业务组织、业务过程以及领域方式等，其核心是对业务需求建模，因此，可使用的UML图有用例图、活动图、类图以及合作图。

用例图往往用来捕获业务需求。获得用例的通常方法是与有经验的用户交谈，从而了解他们希望系统具备的功能和提供的服务，用例的集合，即是对整个系统的需求。不要一开始就陷入细节问题，而影响形成系统的整体观念和综合看法。在用例图中，用例和执行者之间的连线表示二者间的某种关联，如“通信”、“使用”、“提供”、“变为”等。为了描述这些关联，可以使用类别模板，当UML预定义的四十多个类别模板不够时，可以对其进行扩展，自定义合适的类别模板来进行表达。用例之间也有关联如使用、依赖、扩展等。为了表达清楚并提高用例图的可读性和可重用性，应将已明确的关联用文字标注清楚。

类图用于捕获信息和业务对象，在描述系统中的类及其相互关系时，它还反映系统中各种对象的类型以及对象间的静态关系，主要有关联、子类型。在这个层次使用类图，描述的应是应用域中的概念，这些概念与实现它们的类通常没有直接的映射关系，这时对接口的描述也应与实现区分开来。在描述关联时，可以为每个关联起个恰当的名字来表明其含义并对它进行标注。由于每个关联有两个角色，角色是由对象扮演的，为了明确对象在关联中的角色，也可以为角色命名。此外，还可以在需要附加说明的关联上添加注释。在描述类时，还应该对已明确的属性进行命名和定义，在业务工程级，对属性的描述不必过细，标明其所属类、名称、类型和存在的约束特征即可。

由于用例图在描述事件的并行性和先后关系上难以提供足够的信息，还可以借用活动图。任何一个企业的业务需求都会涉及到在业务过程中应先执行什么、后执行什么，哪几件事件可以同时发生、并行执行，哪些事件的前提条件是什么等。活动图正好在描述工作流和并行过程方面具有强大的表现力。抽象级较高时，活动图只列出那些需要做的事情以及那些必须遵守的工作顺序。它的并行表达能力对企事业过程中业务活动的建模非常重要，可以方便地表示业务活动中常见的并行过程。这时不必过早地考虑用计算机实现时的细节。在模型中保留对并行行为的描述，对于在实现阶段充分发现那些可以并行的工作非常有利，以便大大提高业务过程中的办事效率。为了进一步描述用例，还可以使用活动图。

在系统体系结构工程中使用UML图

系统体系结构工程的核心活动是为系统的体系结构建模。该建模活动涉及逻辑系统结构的建模、用户接口建模以及工具的识别等，可使用的UML图有组件图、类图、配置图。

在对业务进行建模时，UML的类图适合描述类的聚集、组成、接口。聚集是一种关联，反映部分与整体之间的关系。组成是一种由聚集演变而来的关联，表示一个部分对象只属于一个总体，且通常与总体共存亡。在表示聚集和组成时，可分别在连接两个类的关联旁添加注释作为辅助说明，并将已知的约束条件给出，有助于更好地描述系统的体系结构。为了描述接口，可以为接口起名或用文字描述它的逻辑功能。

为了更清晰地描述系统体系结构中各部分的依赖关系，还可以借助于组件图和配置图的表达能力。组件图说明各种组件间的依赖关系，它可以反映某个组件的改变对其它构件的逻辑影响。借助组件图，可以描绘出在业务工程阶段和这个阶段分别得到的各部分之间的关系，如依赖、调用、返回等。在组件图中，可用不同线型的箭头表示不同的关系，或者为关系添加注释，作为对关系的辅助说明；在描述调用、返回等关系时，还可以把已明确的调用/返回条件添加为约束给出。配置图除了可以描述系统软硬件的配置情况外，还可以描述系统体系结构和逻辑配置。通过配置图，可以清晰地对软硬件关系和系统的分布性进行建模。

在业务对象组件工程中使用UML图

在业务对象组件工程阶段几乎可以使用所有的UML图。用例图可以表示业务对象组件在用例中的情况。用类图描述各类业务对象组件的构成、属性、操作、业务对象组件间的接口和关联。用状态图描述跨越多个用例的业务对象组件的行为，尤其是并发行为。在高抽象级，用活动图描述业务对象组件在业务过程中的执行顺序；在较低的抽象级，则对业务对象组件内部的活动进行建模。此外，为了更好地描述业务对象组件的内部结构和关系，还可使用组件图和配置图，它们可以描述组件之间以及组件与外部之间的关系。用顺序图可以着重体现消息传递的时间顺序和组件间的消息传递的时间顺序。顺序图与合作图往往配合使用。

在应用工程中使用UML图

由于UML适用于系统开发的不同阶段，从需求规格描述到系统完成后的测试，应用工程的主要目的是把前面各工程活动中建立的模型转化为可用的软件模型。几乎所有的UML图都可用于应用工程。在编程构造阶段，如何把分析和设计阶段提出的模型转化为实际代码，就是根据前面得到的UML图。在测试阶段，不同的测试以不同的UML图作为依据，如单元测试时使用类图和类规格说明，集成测试时使用组件图和合作图，系统测试时使用用例图。

随着越来越多的企业面临着业务过程重建，在业务过程重建的过程中，可以把面向对象技术结合到其中。UML是面向对象的可视化建模语言，其强大丰富的表现力可以应用于对业务过程重建建模，但具体使用如何，还需要具体情况具体对待。