UML建模

 

业务过程建模

介绍

比起业务分析与建模来，UML在过去与软件工程和系统设计的联系更加紧密。并且，UML2.X标准提供了丰富的行为模型，这对于过程、活动、及对每一个业务都重要的人与信息等的建模非常有用。

除标准的UML规范外，还有两个备受关注的UML扩展，它们进一步强化了对业务过程和相关结构的建模。第一个是业务过程建模标注，它已经广受欢迎，并迅速成为业务过程建模与设计的新标准。第二个是 Eriksson-Penker Profile，虽然不那么流行，但在可视化、业务过程间通信、以及企业（组织）内部的信息流方面，仍然是独一无二的。

本文将对这两种扩展提供深入介绍，阐述如何在Enterprise Architect 中使用它们以及他们所用的通用模型结构。

业务过程建模标注（BPMN）

BPMN 定义了一种业务过程图（BPD），该图是基于一种专门绘制流程图技术，用于业务过程的图形化建模。无论是创建业务过程草图的业务分析师，还是负责实现这个过程的技术开发人员，或者管理、监督业务过程的相关人员，所有的业务人员都容易理解这种标柱。

一个BPMN 模型是由一组简单图构成，每一个图又包含一组图形元素。

流程元素

1. 活动（Activity）：一个活动是业务过程中执行的一个作业，用圆角矩形表示。
2. 事件（Event）：一个事件是在业务过程的流程中发生的，并影响业务过程中活动的执行顺序与执行时间的事情。事件用带有不同边界的小圆表示，以区别初始事件（细实线）、中间事件（双实线）和终止事件（粗实线）。在图形内部显示图标以便于区分触发器和事件结果。
3. 关口（Gateway）：关口用来控制顺序流如何在过程内进行合并和分岔。关口可用来表示判断点，可以表示一个或多个路径在此处不能通过。关口也可以表示一条路径在此分岔。

1. 顺序流：顺序流用来表示活动在业务过程中的执行顺序。顺序流用有实箭头的线表示。
2. 消息流：一个消息流用来表示两个实体之间的消息流向。实体用池来表示，消息用虚线在源端连接浅颜色的圆并在目标端连接箭头。
3. 关联：关联是用流对象将信息与制品联系起来。关联采用虚线表示并在目标端有或者没有箭头，根据需要而定。

泳道 (分割)

1. 泳池：表示一个业务过程中的参与者。一个参与者可能是业务实体或者角色。泳池表示了对业务过程的一种划分。
2. 泳道：是泳池的再划分，用于组织和分类泳池内的活动。

过程要素

1. 数据对象：一个数据对象对一个业务过程没有直接的影响，但提供信息给相关的过程。数据对象用一个上角折叠的矩形来表示。
2. 组：组提供了对过程内的元素进行分组的非正式手段，用虚线的矩形表示。
3. 注解：注解提供一种机制使得BPMN的模型建立者为BPMN模型的用户提供附加信息。它是用一个开口的矩形表示，注解文字写入其中。

BPMN 示例

例 1:

上面的图展示了BPMN的几个主要功能。特别是将一任务过程进行层次分解成较小的任务。以及能表示循环结构和外部事件干扰正常过程流程。

"上行活动"和"下行活动"是连接触发的中间事件，换句话说，是页面间承上启下的连接器。

"对每个供应商重复执行" 是一循环活动，它对每一个供应商重复执行所包含的三个活动，或者直到时间限制已到。固定在活动下边沿的终止事件是一时间事件触发器。

例 2:

上面的图表示一个业务过程由一个事件开启，在本例中，一个消息触发器产生一个事件，该事件通知业务过程活动组处于活动状态。该图也显示一个由时间事件控制的循环，并显示一个决策关口（在本例中是“异或” 决策关口）控制什么时候循环该结束。

例 3:

该图例示使用泳池来表达过程间的交互以及使用消息流连接器来表示消息在泳池间进行传递的方法

Eriksson-Penker 业务建模 Profile

本节介绍业务过程模型所使用的术语与图标。并简要介绍一些基本UML建模语言概念以及如何在EA的业务过程建模中如何使用它们。

一个业务过程： 有一个目标

1. 有指定的输入
2. 有指定的输出
3. 使用资源
4. 有按某种顺序进行的一组活动
5. 可能影响多个组织单元 ，造成横向组织影响
6. 为客户创造某种价值，客户可能是内部的，也可能是外部的。

过程模型

一个业务过程是一个活动的集合，用于为特定的客户或市场产生指定的输出。与产品所强调的“过程是什么”不同，业务过程强调作业在组织内部是如何进行的。指定在不同时间和地点的作业活动顺序，带有一个开始和一个结束，并清楚地定义输入和输出：一个动作结构。

始于对象信息供应链。供应链是指连接到过程的信息或对象在处理阶段没有被使用完。例如，订单模板可能重复使用，并提供特定样式的新订单。作为这个活动的一部分，这个模板不会更改和被消耗光。

• 始于对象资源的供应链： 一个输入供应链是指所连接的对象或资源将在处理过程中被消耗。例如，当消费者的订单在被处理后，它们将标记为完成并签字，并且每个资源仅使用一次。
• 终于对象目标的目标链： 一个目标链是指连接到业务过程的对象描述业务过程的目标。目标是执行活动的业务宗旨。
• 对象流连接对象输出
• 始于事件的对象流：一个对象流连接是指在一个业务过程一些对象被传递。它强调对在实体之间或过程之间所传递信息的控制。

 

目标

一个业务过程有一些定义完备的目标。这也是组织制定业务过程的原因所在。并且这些目标的制定代表组织的整体利益和满足组织的业务需要。

业务过程始于过程的目标链：一个目标链是指连接到业务过程的对象用于描述该过程的目标。目标是执行活动的宗旨。

信息

业务过程使用信息执行和完成它们的活动。信息不象资源，在过程中是不可消费的，它被用来做过程转换。信息或许来自外部，或许来自客户，或来自内部组织，甚至是其它过程所产生。

连接到业务过程的信息项：一个供应链是指连接到过程的信息和对象在处理阶段不会被使用完。例如，订单模板可能一用再用，一提供某种特定类型的新订单。作为该活动的一部分，模板是不会改变或耗尽的。

输出

典型地，一个业务过程将产生一个或多个多业务有价值的输出，输出可能供内部使用，也可能是为了满足外部需求。输出可能是物理对象（如一份报告或者发票），可是一种从原始资源到安排的转换，也可能是一个全体的业务处理结果，如完成处理一份订单请求。

一个业务过程的输出可能是下一个业务过程的输入，或者作为请求项或触发项来触发新活动。

 

动态模型

动态模型用于对系统的行为随时间变化而进行的建模和描述。它支持活动图，状态图，顺序图，以及包含业务过程建模的扩展功能。

顺序图
顺序图用来显示用户，对象，界面和实体之间的交互。它提供了随时间变化，消息在对象间传递的时序图。这些图经常被放于模型用例内来图示用例情形：用户如何与系统交互，内部如何完成任务。通常这些对象用特殊构造型按钮表示，如下图的例子。对象"Login Screen"使用用户接口"User interface"图标.对象"SecurityManager"使用控制器"Controller"图标。" users"使用实体"Entity"图标。

活动图
活动图用来显示系统中不同的工作流是如何构造的，它们如何开始，以及它们从开始到结束所可能采用的判断方式。他们也图示某些活动执行中，并行处理可能发生在那里。

状态图（state charts）
状态图用来详细描述系统中，对象经历的状态转移和变化。它们显示一个对象如何从一个状态到另一个状态，以及控制这种变化的规则，通常有一个开始和结束状态。

过程模型
过程模型是UML活动图的扩展，用于业务过程建模 - 该图显示这个过程的目标，过程的输入，输出，事件和所包含的信息。

 

逻辑模型
逻辑模型是组成设计和分析领域的对象和类的静态视图。通常一个域模型是业务对象和实体的松散、高层视图。而类模型则是更严格，注重设计的模型。这里主要讨论有关类模型的部分。

类模型
类是一个标准的UML构造，用来描述模式：该模型在运行时生成对象。一个类是一个规范，对象是类的实例。类可以从其他的类继承而来(他们可以继承它们父类所有的行为和说明，并加入它们自己的新功能) 可以有其他类作为属性，并授权给其他类和实现抽象接口。

类模型是面向对象开发与设计的核心- 它既表达系统的持久状态，也表达系统的行为。类可以封装状态(属性)和提供服务来控制这个状态(行为)。好的面向对象设计将限制直接访问类属性，并提供方法以访问的方式来控制属性。这数据隐藏和服务外露的方法确保了数据只能在一个空间内，按照指定规则更新。对于大型系统而言，直接访问多处数据元素所需的代码维护负担是极其巨大的。

类表示如下:

注意：类有三个不同的区域:

1.	类名 (还可以包含构造型)
2.	类的属性区 (内部数据元素)
3.	行为 - 私有的和公共的

属性和方法可以标注如下：

-	私有的，说明对类外部的调用者是不可见的。
-	保护类型的，只对子类是可见的
-	公共的，对所有都是可见的

类的继承显示如下：该例中的抽象类，是一个有两个子类的父类，每个子类继承基类，并用自身的行为加以扩展。

类模型可以由相关行为和状态的包来集合，见下图例示。

 

 

物理模型

这个物理/部署模型提供了一个描述组件在系统基础设施中部署的详细模型，它提供了有关网络能力，服务器规范，硬件需求和其它系统部署相关的详细信息。

部署视图

PM01: 物理模型
物理模型显示了系统组件"如何"与"在那里"被部署。它是一个明确的系统布局图。部署图显示进入生产或测试环节后，系统的物理部署。即显示组件安置在那里，何种服务器，机器和硬件。也显示网络连接，局域网带宽等等。

节点用来描绘任何服务器，工作站，或其它主机硬件，它们被用来在生产环境下部署组件。可以指明节点间的连接和指定节点的构造型（如TCP/IP）及需求。节点也可能有功能特性，最低硬件要求，操作系统级别，说明文件等等。下面对话框例示了节点设置的共同属性：

 

用例模型

用例模型描述的是新系统规划的功能。它表示用户（人或机器）和系统之间交互的离散单元。该交互是一个有意义的独立单元，如：创建账户，浏览帐户信息。

每一个用例描述建立在规划系统中的功能，它可以包含另一个用例功能或用自己的行为扩展另一个用例。

一个用例描述通常包括：

• 描述用例的常规注释和说明
• 需求 - 用例必须提供给最终用户正式的需求。如：<ability to update order>"能更新订单"。它们都对应构造方法中建立的功能规范，并建立用例执行动作和给系统提供值的约定。
• 约束 - 用例运行所遵循的正式规则和限制，它们定义了什么能做，什么不能做。包括：
  • 预置条件是用例运行以前就已经发生了。如："创建订单" <create order>必须发生在"修改订单"<modify order>之前。
  • 后置条件是用例完成后必须为真，如："订单修改和一致性检查"。
  • 常量在用例的整个运行过程中始终为真，如：一个订单一直有客户号。
• 情形 – 用例执行时各步骤正式有序的描述，或用例实例化过程中事件发生的流程。它包含多种情形来应付特殊环境和可选择的处理方式。它们通常由文本建立和对应于顺序图的文本表达。
• 情形图 - 描绘工作流的顺序图;类似于情形，但是图形化描述。
• 附加属性，如实施阶段，版本号，复杂性程度，构造型和状态。

执行者

用例通常与执行者关联，执行者可以是人或机器实体，用于系统交互来执行有意义的工作从而帮助他们完成目标。执行者参与的用例定义了它们在系统中总体的作用和动作的范围。

包含和扩展用例间的关系

一个用例可以包含另一个用例功能做为它自身正常运行的一部分。通常假设在用例运行时被包括的用例每次都会被调用。例如：在修改选定订单前，列出一份客户订单表，每次<modify order>"修改订单"用例执行时，<list orders>"列出订单"用例被调用执行。

一个用例可以被一个或多个其它用例包含。通过将通用的行为提炼成可以多次重复使用的用例，有助于降低功能重复级别。

通常，在特别情况下，一个用例可以扩展另一个用例的行为。例如：如果一个用户在修改一个特别类型的客户订单之前，该用户必须得到某种更高级别的许可，然后“获得许可”<Get Approval>用例将有选择地扩展常规的“修改订单”<Modify Order>用例。

顺序图

顺序图提供随时间变化，对象交互的图形化描述。通常用来表现一个用户或执行者，对象和组件，以及它们在用例执行过程中之间的交互。一个顺序图典型地表示一个单独的用例情形或事件流。

顺序图可以出色的显示文档使用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段验证对象。它显示一个对象到另一个对象的消息流，这些消息流对应着一个类和对象支持的方法和事件。

下面顺序图例示了左侧的用户或执行者初始化事件和消息流，它们对应于用例情形。在最终模型中，对象间传递的消息变成类的操作。

执行图

用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素（如：组件和类）和实现用例在新系统中的功能。这为系统设计者，客户和团队，这些实际建立系统的人，提供了高级别可跟踪能力。组件和类连接的用例列表说明了必须被组件执行的最少功能。

上图说明用例"Login"实现需求"1.01 Log On to the website"。也显示组件"Business Logic"和"ASP Pages"组件实现部分或全部"Login"功能。进一步细化可显示"Login"界面(一个网页)来实现"Login"用例。这些执行和实现连接定义了从正式需求，到用例，直至组件和界面的可跟踪能力。