Enterprise-Architect-UML指南.docx

Enterprise Architect UML指南/resources/tutorial/uml-tutorial.html1. 应用UML进行数据库建模1.1 介绍当需要为软件系统系统提供一种可靠，灵活而又高效的对象持久化方法时，当今的设计师和架构师们面临着众多的选择。从技术的层面上，这个选择往往介于完全面向对象，对象关系混合，完全关系化和建立在公开或专有文件格式上的常规解决方案之间（如：XML，OLE的结构化存储）。从提供者的层面上，Oracle， IBM， Microsoft， POET 和其它的公司提供了相似，但是彼此间往往不相容的解决方案。本文仅论述这些选择中的一种，即在完全关系数据库上层面向对象的类模型进行分层。这并不表明它是唯一、最好而又简单的解决方案，但是从实用的角度看，它是最常用的一种类型，却也是最容易被用错的一种。我们先快速浏览两个设计领域的模型，并试图把它们连接起来：第一，介绍用UML表达面向对象的类模型；第二，关系数据库模型。对每一个领域我们只涉及影响到我们任务的主要功能。然后我们将关注从类模型到数据库模型映射的技术和问题，包括对象持久性，对象行为，对象和对象标识之间的关系。我们将总结对UML数据profile的回顾（Rational Software 推荐）。一些面向对象设计，UML和关系数据库建模的相似性也会被提及。类模型是UML用来表达软件系统逻辑结构的主要工件。 它用来记录数据需求和模型领域内对象的行为。本文不讨论创建和详细描述该模型的技术，我们将假设已经存在一个设计好的类模型，它需要映射到关系数据库上。类模型类在UML中是一个基本的逻辑实体。它定义了一个结构单元的数据和行为。一个类是一个模板或运行时创建实例和对象的模型。当开发一个逻辑模型，如UML中的结构层次，我们将明确地把它们当作类来处理。当面对动态图时，如顺序图和协作图，我们也要处理类的实例和对象，以及它们运行时的内部动作。数据隐藏和封装原则是基于作用域效果。类有它的内部数据元素。访问这些数据元素需要通过类对外的行为或接口。遵循这个原则会生成更易于维护的代码。行为行为使用了类定义的操作，在类模型中被记录。操作是可以外部可见的（public），对子类可见的（protected）和隐藏的（private）。通过结合隐藏数据和公共访问接口，隐藏或保护数据的操作，类的设计人员可以建立极易维护的结构单元，这些结构单元是支持而不是阻碍变化的。关系和特性关联是两个类之间的一种关系。关系一侧的类知道和在某种程度上使用或操控另一侧的类。这种关联可以是功能上的（为我做某事）也可以是结构上的（是什么）。在本文中更多的是侧重结构上的关系。如：一个“Address”类可以关联一个“Person”类，将这种关系映射到数据空间需要多加注意。聚合是关联的一种形式，表示一个类多个对象的集合在另一个类中。复合是一种更强的聚合形式，说明一个对象实际上由其它对象构成。对于关联关系来说，它意味着一个复杂的类属性，将该属性映射到关系模型时需要更详细的考虑。当一个类表示为生成许多对象实例的模板或模型时，对象需要在运行时有识别自己的方式，这样被关联对象可以对正确的对象实例施加作用。在编程语言中，如C，对象指针可能会传递，并使所指对象可以访问一个独一无二的对象实例。通常尽管一个对象会被销毁，但是在需要时，又象上一次有效实例期间那样被重建。所以，这些对象需要一个存储机制来保留它们的内部状态和关联，并在需要时恢复所需状态。继承给类模型提供一种方式，该方式提取通用行为到泛化的类中，使这个泛化类稍后可以做为在一般主题上诸多变异的原形。继承是一种管理重用和复杂性程度的方式。如我们将看到的，关系模型并没有与继承关系的直接对应项，这给数据模型建立者建立一个从对象模型到关系框架造成了困难。从一个运行时的对象到另外一个对象的导航是建立在完全引用的基础之上。一个对象有多种形式的连接（指针或唯一的对象标识），用这些连接可以定位和重建所需的对象。关系模型关系数据模型已经使用多年，提供的性能和灵活性一直行之有效。它本质上是基于集合的（setbased），并且用表做为它的基本单元，表由一个或多个列组成，每一个列包含一个数据元素。表和列：一个关系表是一个或多个列的集合，每个列在表结构中有一个唯一名称，并且被定义成一个特定基本数据类型，如：数字、文本、二元数据。表定义是一个模板，表的“行”从这个模板中被创建，行可能做为一个表实例的实例。关系模型仅仅提供一个公共数据访问的模型。所有数据向外对任何一个过程开放，以便于被更新，查询和操控。信息隐蔽（information hiding）是未知的。行为与表相关联的行为通常是基于所应用实体的业务或逻辑规则。约束以多个形式应用到“列”，如：独特性需求、对应其它表和列的关系完整性约束，允许的值和数据类型。触发器提供了关联到一个实体的许多附加行为。通常在数据被插入、删除和更新前后，强制执行数据的完整性检查。数据库存储过程提供了一种通过专有语言扩展来延伸数据库功能的方式，这些扩展通常用来构造功能性单元（脚本）。这些功能不会直接映射到这些实体，也不会与它们有逻辑关系。通过关系数据集的导航是基于“行”遍历和表连接实现。SQL是用来从表集选择“行”和放置实例的一种主要的语言。关系和识别表的主键为识别行提供一个特定值。这里有两种我们关注的主键：首先是意义键（meaning key），它由数据列构成，这些数据列在业务领域有意义。其次是一个抽象的唯一标识符，如计数器值，它没有商业意义，但是可以唯一地标识一个行。我们将先讨论抽象唯一标识符，然后再阐述意义键。一个表可以包含映射到另一个表主键的“列”。表间的关系定义了一个外键，说明了在这两个表之间的结构关系或关联。小节从以上的概述，我们可以看出对象模型是建立在离散实体基础上，这些实体既有状态（属性和数据），也有行为，一般仅通过类的公共接口来访问封装数据。关系模型同等地显露所有数据，有限支持利用触发器从行为到数据元素的关联。依靠使用唯一对象标识符，可以从一个对象移动到另一个对象，这使得我们可以在对象模型中导航，并建立对象关系（类似于网络数据模型）。在关系模型中，通过使用检索标准，SQL合并和过滤结果集，你可以查找找所需的行。标识符在对象模型中既可以是实时引用，也可以是持久的唯一标识符（称作OID）。在关系领域里，主键定义了数据集在整个数据空间中的唯一性。对象模型中有丰富的关系集合：继承，聚合，关联，复合，依赖，以及其它。在关系模型中，可以仅使用外键来指明一种关系。我们已经对感兴趣的两个领域进行了介绍并比较了每一个领域的几个重要功能，然后将简单了解UML中关系数据模型的标注。1.2 UML数据模型Profile（特性描述）数据模型Profile是Enterprise Architect的UML扩展来支持关系数据库建模。它包括一些定制扩展，如：表，数据库图表，表键，触发器和约束。它是一种在UML中对关系数据库建模的技术。表和列 表在UML数据Profile中是带Table构造型的类，它在右上角显示一个表的符号。数据库中的列用Table类的属性来建模。例如：上面图型显示与客户表关联的属性。在此示例中，对象ID被定义为表的主键，还有两个列：“Name”和“Address”。注意上图例子中列的数据类型是按照原DBMS的数据类型定义的。行为 到目前为止，我们仅定义了表的逻辑（静态）结构。此外，我们将描述与列关联的行为，包括：索引，键，触发器，过程等等。行为表示为带构造型的操作。下图显示我们讨论的表，它有一个主键约束和索引，均被定义为带构造型的操作。注意：“OID”列上的PK标签定义了逻辑主键，而构造型操作“PK idx_customer00”定义了与主键实现相关联的约束和行为（即主键的行为）。对上例进行增加，我们现在可以定义附加行为，如：触发器，约束，存储过程。见下图：这个例子描述了下列行为:一个主键约束（PK）;一个外键约束（FK）;一个索引约束（Index）;一个触发器（Trigger）;一个唯一性约束（Unique）;一个存储过程（Proc）一个有效性检查（Check）.使用上面提供的标注，我们可以在DBMS层次上，对复杂的数据结构和行为建模。另外，UML还提供表达逻辑实体间关系的标注。关系UML数据建模profile定义了两个表间任意一种依赖关系。它表示为一构造型的关联并包括一组主键和外键。数据profile仍然需要一种关系一直参与到父类和子类之间，父类定义一个主键，子类实现一个建立于全部或部分父类主键基础上的外键。这种关系将被区分为：“定义的”（如果该子类外键包含所有父类主键元素）和“非定义的”（如果只包括部分主键元素）。这个关系可以包括基数性约束，以及采用成对的相关主键与外键来建模，并命名为关联角色。下图描述了使用UML对这种关系的建模。物理模型UML也提供一些机制来表示数据库的整体物理结构，它的内容和部署位置。我们用构造型组件来表示一个物理数据库。见下图：一个组件表示了一个离散，可部署的实体。在物理模型中，组件可以映射到一个物理硬件（UML的节点）。对于数据库内的关系模式，我们用带Schema构造型的包来表示。一个表可以放置到Schema中来建立它在数据库中的范围和位置。1.3 从类模型到关系模型的映射我们已经描述了所关注的两个领域和它们使用的标注，现在将我们的注意力转移到如何映射，及如何从一个领域转换到另一个领域。以下采用的策略和表达顺序是建议性的，而不是必须的。采用何种步骤和过程要根据个人的需要和环境而定。1. 类的建模首先我们假设从一个已经创建的类模型构建一个新的关系数据库模式。显然这是一个最容易的方向，这是因为模型一直在我们的控制之下，并且我们能根据类模型来优化这关系模型。在现实环境下，你可能需要在原有数据模型之上对类模型分层，这是更难的一种情况，具有挑战性。在这里，我们只关注第一种情况。至少类模型会记录元素的关联，继承和聚合关系。2. 标识持久对象建立类模型后，我们需要将类模型的元素分成需要持久性和不需要持久性两类。例如，如果我们采用“模型视图控制”的设计模式来设计我们的应用程序，那么只在模型部分的类将需要持久状态。3. 假设每一个持久类映射到一个关系表这是一个大的假设，但是它对大多数情况有用（现在先把继承的问题放一边）。在一个最简单模型中，一个来自逻辑模型的类映射到关系表的全部或一部分。这个映射的逻辑扩展是一个单独的对象（或类的实例）映射到表中单独的“行”。4. 选择一个继承策略.继承可能是从面向对象模型转换到关系模型过程中最容易出现问题的关系和逻辑结构。关系领域本质上是平面的，每一个实体自身完成，而对象模型常常是一个具有深度的，设计完善的类层次结构。这样深度的类模型可以有多层的继承属性和行为，运行时生成最后全功能的对象:每一个类层次结构有一个单独对应的表，这个表包含所有元素的继承属性因此，这个表是该层次结构中每个类的联合。例如，人，父母，孩子和孙子可能形成一个单独的类层次结构，并且每个类中的元素都会出现在相同的关系表中;类层次结构中的每一个类有一个对应的表，该表有仅能被该类访问的属性（包括继承属性）。例如，如果“孩子”仅仅从“人”继承而来，表将仅包含“人”和“孩子”的元素;类层次结构中的每个类的自有属性对应一个表。例如，“孩子”将映射到一个仅带孩子属性的单个表对每一种方法，我们有对应的案例。但是我们推荐第三种方法，因为它最简单，最容易维护和最不容易出错。第一种方法提供了运行时最佳的性能。第二种方法是第一种与第三种的折衷。第一种方法展开层次结构，在一个表里放置所有的属性，这样方便类层次结构中对类的更新和提取，但是不易于验证和维护。与“行”关联的业务规则是难以实现的，因为表中的每一行都可能被实例化为层次结构中的对象。“列”之间的依赖关系可能变得相当复杂。此外，对层次结构中任何一个类的更新将可能影响层次结构中其它每个类，如表中的列被添加，删除和修改。第二种方法是一种折衷方案，提供了更好的封装和消除空列。可是，对父类的修改可能需要在所有子类的表中进行复制，更糟的是，有两个或多个子类的父类数据可能被冗余地存储在许多表中；如果父类的属性被修改，那么要花相当的时间去查找相关的子表，并更新受影响的行。第三种方法精确地反映了对象模型，它将层次结构中的每一个类映射成一个独立的表。父类或子类的更新是在正确空间的局部范围内进行的。对实体的任何修改被严格限定于单个表内，因此表的维护也就相对简单。缺点是需要在运行时重构结构层次，来精确产生一个子类的状态。一个“Child”的对象可能需要一个“Person”的成员变量用于表示它的父辈。由于这两者都需要加载，两次调用数据库来初始化一个对象。随着类结构层次加深，初始化或更新一个单独对象的数据库调用次数也随之增加。当你映射继承关系到关系模型时，理解上述要点是很重要的，这样你就选择最适合你的方案。5. 为每一个类添加一个唯一的对象标识符在关系和对象的领域里，需要唯一标识一个对象或实体。在对象模型中，非持久对象在运行时通常被直接引用或对象指针来标识。一旦对象被创建，我们可以用它运行时的标识符来引用它。但是，如果我们将对象写入存储空间，那么如何按需要得到完全相同的实例是一个问题。最便捷的方式是定义一个OID（对象标识符），它在关注的命名空间是被确保唯一的。根据需要，这可能发生在类，包或系统的层级上。系统级别OID的一个例子可以是一个使用微软“guidgen”工具创建的GUID（全局唯一标识符），如A1A68E8E-CD92-420b-BDA7-118F847B71EB。类级别的OID可以用简单得数字实现（如：位计数器）。如果一个对象具有对其它对象的引用，它可以采用使用它们的OID的方法。那么，在运行时有效地将引用的对象从存储区加载到模型中。关于上述OID值的重点是它没有超出定义它为标识符的简单含义。它们仅是逻辑指针而没有其它意义。在关系模型中，情况往往是不同的。关系模型中标识正常地用一个主键实现。主键是一个表中的一组“列”，它们合起来可以唯一地标识一个行。例如：名称和地址可以唯一地标识一个“客户”。其它实体，如：“销售员”引用“客户”，它们要实现基于“客户”主键的外键。这个方法存在的问题是：将业务信息（如客户名和地址）嵌入标识符中对我们目标的影响。设想三个或四个表全部具有基于“客户”主键的外键，对于一个需要修改客户主键（如：增加一个用户类型）的系统修改，那么既要修改客户表，也要修改与外键相关的实体，这个工作是十分巨大的。另一方面，如果一个OID被当作主键实现，并为其它表建立外键，那么修改范围仅限于主表，并且修改的影响也因此大大减小。实际上，一个基于业务数据的主键也许会被修改。如：一个客户可以修改地址和名字，既然这样，这个变化需要被正确的传递到所有其它相关的实体，更不用提改变部分主键信息的困难。一个OID总是引用同一个实体，而不管其它信息怎么改变。在上面的例子中，客户可以修改名称和地址，与它相关联的表不需要被修改。当把对象模型映射到关系表时，实现完全OID的标识符比采用业务联系的主键更加便捷。用OID做为主键和外键的方法将为对象提供更好的加载和更新效率，将维护服务减到最少。实际上，一个与业务相联系的主键可以替换为：l 一个唯一性约束或相关列的索引;l 嵌入类行为的业务规则;l 或将上述两种结合起来.再次重申，是使用有意义的键还是使用OID取决于被开发系统的实际需要。6. 映射属性到“列”通常，我们将简单的类数据属性映射到关系表的列。例如，一个文本或数字字段可以分别表示一个人的名字和年龄，这种直接映射不会引起什么问题，只是简单地在数据库服务商的关系模型中选择适当的，与类属性相对应的数据类型。对复杂属性（即属性为其它对象）使用下面详细的步骤来处理关联和聚合关系。7. 映射关联到外键更复杂的类属性（即它们代表其它类）通常建模为关联关系。一个关联是对象间的结构关系。例如，一个人可以居住在一个地址，当这个人被建模，他会有城市，街道，邮编的属性。在对象和关系领域里，我们倾向于把这个信息当作单独的实体来构造:“地址”。在对象领域里，地址代表一个独一无二的物理对象，并可能带有一个唯一OID。在关系领域，一个地址可以是地址表中的一行，该表的主键被用作为其它实体的外键。在这两种模型中，趋向于移动地址信息到独立实体，这有助于避免冗余数据和提高可维护性。所以对于每一个类模型中的关联，要考虑创建一个从子类到父类表的外键。8. 映射聚合和复合聚合和复合关系类似于关联关系，并通过“主键外键”对来映射成表。但是，需要提醒的是：普通聚合（弱聚合）对关系建模，如：一个人住在一个或多个地址，在此例中，超过一个以上的人可能住在相同地址，如果这个人不在这里住了，与他相连的地址仍然存在。这个例子例举了关系术语中称之为“多对多的关系”，并且通常实现为一个独立的表，该表包含了从一个表格的主键到另一个表格主键的映射。弱聚合的第二个例子是：一个实体在那里使用或排除了另一个实体的所有权。例如：一个“人”的实体拥有一组股票，这标明这个人可能与一个“股票”表中的某些股票有关联，也可能没有关系。但是每个股票可以联系一个人，或不与任何人发生关系。如果这个人不在了，这个股票将变为“无主”的，或者被传递给下一个人。在这个关系模型中，可以通过每个股票有一个“所有者”列来实现，这个“所有者”列将存储一个人的标识符（OID）。强聚合形式则有与之关联的完整约束。复合表明一个实体由部件组成，并且这些部件对整体有依赖关系。例如：一个人可以有很多证明文件，如护照，出生证明，驾照等。这个人的实体可以由这样的一组文件组成。如果这个人从系统里被删除，那么证明文件也要被删除，因为这些文件被映射到一个唯一个体。如果我们暂时忽略OID，弱聚合可能使用中间表来实现（对多对多的情况）或者在一个聚合的类或表采用一个外键来实现（一对多的情况）。在多对多关系的情况下，如果父类被删除，中间表中的实体也要被删除。在一对多的情况下，如果父类被删除，外键输入（如“所有者”）必须被清除。在复合的情况下，外键的使用是强制的，约束条件是父类删除后，部件也必须被删除。逻辑上，复合是有一种含义，部件主键形成了全部主键的一部分。例如：一个人的主键由他证明文件组成。尽管实际上是相当冗长的，但逻辑关系上为真。9. 定义关系作用对于每一个关联关系，可能会进一步指明关系每一个端点的角色信息。通常包含主键约束名和外键约束名。图例示了这个概念，这在逻辑上定义两个类之间的关系。另外，可能会在作用名上标明附加约束（即非空）和基数性约束（即.）。10. 模型行为我们现在来讨论另一个难题：是映射部分还是所有的类行为到数据库商提供的功能上，这些功能以触发器，存储过程，唯一性，数据约束和关系完整性的形式出现。一个非持久对象模型通常可以实现一种或多种语言（如Java和+）需要的所有行为。每一个类将用公共的，保护的和私有的方式描述它被赋予的行为和职责。不同数据库商的关系数据库通常包含不同形式的，基于SQL的可编程脚本语言，用来实现对数据的操作。最常用的例子是触发器和存储过程。当我们混合对象和关系模型，要做的决定往往是：是实现类模型中所有的业务逻辑，还是将部分的业务逻辑放在关系DBMS中更常用而有效率的触发器和存储过程中。从完全面向对象的角度看，答案是避免使用触发器和存储过程，并且将所有行为放到类中。这样会使行为局部化，从而提供了一个更清晰的设计，简化了维护，并且提供了在不同DBMS提供商之间更好的移植性。在现实世界，存储过程和触发器的设计目标底线可以是每秒至少执行几百次或几千次之多。如果为了追求模型的清晰，移植性，可维护性和灵活性，那么就将所有的行为放在对象方法中。如果性能是关注的焦点，可以考虑将部分行为交给更有效的DBMS编程语言。注意到将对象模型与存储过程以安全方式集成所花的额外时间，包括远程影响和调试的问题，可能要比简单部署更高性能的硬件更多。如前面所述，UML数据profile提供下列扩展（构造型操作），可用来对DBMS行为建模:l 主键约束（PK）;l 外键约束（FK）;l 索引约束（Index）;l 触发器（Trigger）;l 唯一性约束（Unique）;l 有效性检查（Check）.11. 产生物理模型在中，物理模型描述了物体如何在现实世界里部署：硬件平台，网络连接，软件，操作系统，动态连接库和其它组件。你需要生成一个物理模型来完成这个周期：从一个初始的用例或领域模型，到类模型和数据模型，最后到部署模型。通常对这个模型，你要创建一个或多个节点，这些节点可以存放数据库，并安装DBMS组件。如果数据库被分成多于一个的DBMS实例，你可以分配表的包Schema给单个DBMS组件来指明数据位置。1.4 总结使用UML进行数据库建模，就象你看到的，当从对象领域映射到关系领域时，有很多要注意的问题。UML提供了这两个领域之间的桥梁。UML数据profile也是一种成功地把两个领域集成起来的优秀的扩展语言。2. UML 教程统一建模语言(UML)已经迅速变成建立面向对象软件的事实标准。本教程提供了Enterprise Architect支持的13种UML图的技术概览。UML 2 详细的语义解释请看新的UML 2 教程。首先. 什么是UML?OMG组织规范声明 :统一建模语言(UML)是一种图形化的语言，用于软件密集系统要素的可视化、制定规范、构建对象和编写文档。UML提供了一种标准的方式来描述系统的设计图，既包括概念方面，例如业务过程和系统功能，也包括具体事务，如编程语言语句，数据库图示和可重用的软件组件。这里着重指出的是UML是一种说明性的“语言”，而不是一种方法或程序。UML通常用来定义软件系统与细化、编写、构造系统中的要素，是“写”设计图的语言。UML可以用不同的方式来支持软件开发方法(例如：统一软件开发过程)-但是它本身并不指定某种方法或过程。UML 定义了下列领域的标注和语义:- 用户交互或用例模型 -描述系统和用户之间的界定和交互。在某些方面对应于一个需求模型。- 交互或通信模型 -描述系统中的对象彼此之间如何进行交互以完成工作。- 状态或动态模型 -状态图表描述随着时间变化，类所呈现的状态和条件。活动图则描述系统即将执行的工作流程。- 逻辑或类模型 - 描述构成系统的类和对象。- 物理组件模型 - 描述构成系统的软件(有时也包含硬件)。- 物理部署模型 - 描述物理架构与物理架构中组件的部署。UML 也定义了一些扩展机制，以扩展UML符合特别需要(例如：业务过程建模的扩展)。第二部分 教程 展开论述如何使用UML定义和建立真实系统。2.1 用例模型用例模型描述的是新系统规划的功能。它表示用户（人或机器）和系统之间交互的离散单元。该交互是一个有意义的独立单元，如：创建账户，浏览帐户信息。每一个用例描述建立在规划系统中的功能，它可以包含另一个用例功能或用自己的行为扩展另一个用例。一个用例描述通常包括：l 描述用例的常规注释和说明l 需求 - 用例必须提供给最终用户正式的需求。如：能更新订单。它们都对应构造方法中建立的功能规范，并建立用例执行动作和给系统提供值的约定。l 约束 - 用例运行所遵循的正式规则和限制，它们定义了什么能做，什么不能做。包括：n 预置条件是用例运行以前就已经发生了。如：创建订单 必须发生在修改订单之前。n 后置条件是用例完成后必须为真，如：订单修改和一致性检查。n 常量在用例的整个运行过程中始终为真，如：一个订单一直有客户号。l 情形 用例执行时各步骤正式有序的描述，或用例实例化过程中事件发生的流程。它包含多种情形来应付特殊环境和可选择的处理方式。它们通常由文本建立和对应于顺序图的文本表达。l 情形图 - 描绘工作流的顺序图;类似于情形，但是图形化描述。l 附加属性，如实施阶段，版本号，复杂性程度，构造型和状态。执行者用例通常与执行者关联，执行者可以是人或机器实体，用于系统交互来执行有意义的工作从而帮助他们完成目标。执行者参与的用例定义了它们在系统中总体的作用和动作的范围。包含和扩展用例间的关系一个用例可以包含另一个用例功能做为它自身正常运行的一部分。通常假设在用例运行时被包括的用例每次都会被调用。例如：在修改选定订单前，列出一份客户订单表，每次修改订单用例执行时，列出订单用例被调用执行。一个用例可以被一个或多个其它用例包含。通过将通用的行为提炼成可以多次重复使用的用例，有助于降低功能重复级别。通常，在特别情况下，一个用例可以扩展另一个用例的行为。例如：如果一个用户在修改一个特别类型的客户订单之前，该用户必须得到某种更高级别的许可，然后“获得许可”用例将有选择地扩展常规的“修改订单”用例。顺序图顺序图提供随时间变化，对象交互的图形化描述。通常用来表现一个用户或执行者，对象和组件，以及它们在用例执行过程中之间的交互。一个顺序图典型地表示一个单独的用例情形或事件流。顺序图可以出色的显示文档使用情形，既可以记录早期分析的所需对象，也可以在稍后的设计阶段验证对象。它显示一个对象到另一个对象的消息流，这些消息流对应着一个类和对象支持的方法和事件。下面顺序图例示了左侧的用户或执行者初始化事件和消息流，它们对应于用例情形。在最终模型中，对象间传递的消息变成类的操作。执行图用例是对所构造系统将有功能的正式描述。与用例关联的执行图用来设计元素（如：组件和类）和实现用例在新系统中的功能。这为系统设计者，客户和团队，这些实际建立系统的人，提供了高级别可跟踪能力。组件和类连接的用例列表说明了必须被组件执行的最少功能。上图说明用例Login实现需求1.01 Log On to the website。也显示组件Business Logic和ASP Pages组件实现部分或全部Login功能。进一步细化可显示Login界面(一个网页)来实现Login用例。这些执行和实现连接定义了从正式需求，到用例，直至组件和界面的可跟踪能力。2.2 动态模型动态模型用于对系统的行为随时间变化而进行的建模和描述。它支持活动图，状态图，顺序图，以及包含业务过程建模的扩展功能。顺序图顺序图用来显示用户，对象，界面和实体之间的交互。它提供了随时间变化，消息在对象间传递的时序图。这些图经常被放于模型用例内来图示用例情形：用户如何与系统交互，内部如何完成任务。通常这些对象用特殊构造型按钮表示，如下图的例子。对象Login Screen使用用户接口User interface图标.对象SecurityManager使用控制器Controller图标。 users使用实体Entity图标。活动图活动图用来显示系统中不同的工作流是如何构造的，它们如何开始，以及它们从开始到结束所可能采用的判断方式。他们也图示某些活动执行中，并行处理可能发生在那里。状态图（state charts）状态图用来详细描述系统中，对象经历的状态转移和变化。它们显示一个对象如何从一个状态到另一个状态，以及控制这种变化的规则，通常有一个开始和结束状态。过程模型过程模型是UML活动图的扩展，用于业务过程建模 - 该图显示这个过程的目标，过程的输入，输出，事件和所包含的信息。2.3 业务过程建模2.3.1 介绍比起业务分析与建模来，UML在过去与软件工程和系统设计的联系更加紧密。并且，UML2.X标准提供了丰富的行为模型，这对于过程、活动、及对每一个业务都重要的人与信息等的建模非常有用。除标准的UML规范外，还有两个备受关注的UML扩展，它们进一步强化了对业务过程和相关结构的建模。第一个是业务过程建模标注，它已经广受欢迎，并迅速成为业务过程建模与设计的新标准。第二个是 Eriksson-Penker Profile，虽然不那么流行，但在可视化、业务过程间通信、以及企业（组织）内部的信息流方面，仍然是独一无二的。本文将对这两种扩展提供深入介绍，阐述如何在Enterprise Architect 中使用它们以及他们所用的通用模型结构。2.3.2 业务过程建模标注（BPMN）BPMN 定义了一种业务过程图（BPD），该图是基于一种专门绘制流程图技术，用于业务过程的图形化建模。无论是创建业务过程草图的业务分析师，还是负责实现这个过程的技术开发人员，或者管理、监督业务过程的相关人员，所有的业务人员都容易理解这种标柱。一个BPMN 模型是由一组简单图构成，每一个图又包含一组图形元素。 流程元素1. 活动（Activity）：一个活动是业务过程中执行的一个作业，用圆角矩形表示。2. 事件（Event）：一个事件是在业务过程的流程中发生的，并影响业务过程中活动的执行顺序与执行时间的事情。事件用带有不同边界的小圆表示，以区别初始事件（细实线）、中间事件（双实线）和终止事件（粗实线）。在图形内部显示图标以便于区分触发器和事件结果。3. 关口（Gateway）：关口用来控制顺序流如何在过程内进行合并和分岔。关口可用来表示判断点，可以表示一个或多个路径在此处不能通过。关口也可以表示一条路径在此分岔。4. 顺序流：顺序流用来表示活动在业务过程中的执行顺序。顺序流用有实箭头的线表示。5. 消息流：一个消息流用来表示两个实体之间的消息流向。实体用池来表示，消息用虚线在源端连接浅颜色的圆并在目标端连接箭头。6. 关联：关联是用流对象将信息与制品联系起来。关联采用虚线表示并在目标端有或者没有箭头，根据需要而定。 泳道 (分割)1. 泳池：表示一个业务过程中的参与者。一个参与者可能是业务实体或者角色。泳池表示了对业务过程的一种划分。2. 泳道：是泳池的再划分，用于组织和分类泳池内的活动。 过程要素1. 数据对象：一个数据对象对一个业务过程没有直接的影响，但提供信息给相关的过程。数据对象用一个上角折叠的矩形来表示。2. 组：组提供了对过程内的元素进行分组的非正式手段，用虚线的矩形表示。3. 注解：注解提供一种机制使得BPMN的模型建立者为BPMN模型的用户提供附加信息。它是用一个开口的矩形表示，注解文字写入其中。 BPMN 示例例 1:上面的图展示了BPMN的几个主要功能。特别是将一任务过程进行层次分解成较小的任务。以及能表示循环结构和外部事件干扰正常过程流程。上行活动和下行活动是连接触发的中间事件，换句话说，是页面间承上启下的连接器。对每个供应商重复执行 是一循环活动，它对每一个供应商重复执行所包含的三个活动，或者直到时间限制已到。固定在活动下边沿的终止事件是一时间事件触发器。例 2:上面的图表示一个业务过程由一个事件开启，在本例中，一个消息触发器产生一个事件，该事件通知业务过程活动组处于活动状态。该图也显示一个由时间事件控制的循环，并显示一个决策关口（在本例中是“异或” 决策关口）控制什么时候循环该结束。例 3:该图例示使用泳池来表达过程间的交互以及使用消息流连接器来表示消息在泳池间进行传递的方法2.3.3 Eriksson-Penker 业务建模 Profile本节介绍业务过程模型所使用的术语与图标。并简要介绍一些基本UML建模语言概念以及如何在EA的业务过程建模中如何使用它们。一个业务过程：1. 有一个目标2. 有指定的输入3. 有指定的输出4. 使用资源5. 有按某种顺序进行的一组活动6. 可能影响多个组织单元 ，造成横向组织影响7. 为客户创造某种价值，客户可能是内部的，也可能是外部的。 过程模型一个业务过程是一个活动的集合，用于为特定的客户或市场产生指定的输出。与产品所强调的“过程是什么”不同，业务过程强调作业在组织内部是如何进行的。指定在不同时间和地点的作业活动顺序，带有一个开始和一个结束，并清楚地定义输入和输出：一个动作结构。始于对象信息供应链。供应链是指连接到过程的信息或对象在处理阶段没有被使用完。例如，订单模板可能重复使用，并提供特定样式的新订单。作为这个活动的一部分，这个模板不会更改和被消耗光。l 始于对象资源的供应链： 一个输入供应链是指所连接的对象或资源将在处理过程中被消耗。例如，当消费者的订单在被处理后，它们将标记为完成并签字，并且每个资源仅使用一次。l 终于对象目标的目标链： 一个目标链是指连接到业务过程的对象描述业务过程的目标。目标是执行活动的业务宗旨。l 对象流连接对象输出l 始于事件的对象流：一个对象流连接是指在一个业务过程一些对象被传递。它强调对在实体之间或过程之间所传递信息的控制。 目标一个业务过程有一些定义完备的目标。这也是组织制定业务过程的原因所在。并且这些目标的制定代表组织的整体利益和满足组织的业务需要。业务过程始于过程的目标链：一个目标链是指连接到业务过程的对象用于描述该过程的目标。目标是执行活动的宗旨。 信息业务过程使用信息执行和完成它们的活动。信息不象资源，在过程中是不可消费的，它被用来做过程转换。信息或许来自外部，或许来自客户，或来自内部组织，甚至是其它过程所产生。连接到业务过程的信息项：一个供应链是指连接到过程的信息和对象在处理阶段不会被使用完。例如，订单模板可能一用再用，一提供某种特定类型的新订单。作为该活动的一部分，模板是不会改变或耗尽的。 输出典型地，一个业务过程将产生一个或多个多业务有价值的输出，输出可能供内部使用，也可能是为了满足外部需求。输出可能是物理对象（如一份报告或者发票），可是一种从原始资源到安排的转换，也可能是一个全体的业务处理结果，如完成处理一份订单请求。一个业务过程的输出可能是下一个业务过程的输入，或者作为请求项或触发项来触发新活动。 资源资源是一个业务过程的输入，并且不像信息，在业务过程处理中要被消耗。例如：火车每天运行服务和实况记录，服务资源将随着处理记录火车运行时刻的不断进行而被用完。连接到业务过程的资源：一个输入连接是指所连接的对象或资源在处理过程中被消耗。例如：当消费者的订单在被处理后，它们将标记为完成并签字，并且每个资源（订单）仅使用一次。2.4 逻辑模型逻辑模型是组成设计和分析领域的对象和类的静态视图。通常一个域模型是业务对象和实体的松散、高层视图。而类模型则是更严格，注重设计的模型。这里主要讨论有关类模型的部分。2.4.1 类模型类是一个标准的UML构造，用来描述模式：该模型在运行时生成对象。一个类是一个规范，对象是类的实例。类可以从其他的类继承而来(他们可以继承它们父类所有的行为和说明，并加入它们自己的新功能) 可以有其他类作为属性，并授权给其他类和实现抽象接口。类模型是面向对象开发与设计的核心- 它既表达系统的持久状态，也表达系统的行为。类可以封装状态(属性)和提供服务来控制这个状态(行为)。好的面向对象设计将限制直接访问类属性，并提供方法以访问的方式来控制属性。这数据隐藏和服务外露的方法确保了数据只能在一个空间内，按照指定规则更新。对于大型系统而言，直接访问多处数据元素所需的代码维护负担是极其巨大的。类表示如下:注意：类有三个不同的区域: 1. 类名 (还可以包含构造型)2. 类的属性区 (内部数据元素)3. 行为 - 私有的和公共的属性和方法可以标注如下： - 私有的，说明对类外部的调用者是不可见的。- 保护类型的，只对子类是可见的- 公共的，对所有都是可见的 类的继承显示如下：该例中的抽象类，是一个有两个子类的父类，每个子类继承基类，并用自身的行为加以扩展。类模型可以由相关行为和状态的包来集合，见下图例示。2.5 组件模型组件模型图示了建立系统的软件组件。它可以由类模型建立起来，既可从新系统的蓝图开始，也可从其他项目或第三方销售商引入。组件模型是较小软件块的高层级聚合，它提供了一个基于黑匣子的积木式来构造软件。组件标注一个组件有点类似于一个ActiveX控件。既可以是一个用户接口控件，也可以是一个业务规则服务器 。组件表示见下图：组件图组件图显示软件组件之间的关系，如它们的依赖关系，通信，位置和其它条件。接口组件可以对外提供接口，接口是组件向其它组件和类提供服务的可见入口点，并使之可以适用于其它的组件和类。组件通常由很多内部的类和类的包组成。甚至也可以从一个更小组件的集合组装而成。组件和节点部署图图示了系统进入生产或测试环节的物理部署。它显示组件被放置何处，何种服务器，设备和硬件。也可以显示网络连接，局域网带宽等等。需求组件可能有附加的需求来说明合同义务。即在模型中他们提供什么服务。需求可以帮助说明软件元素的功能行为。限制组件可能有附加的约束来说明他们运行的环境。前置条件指明组件在执行功能前必须为真。后置条件说明组件完成某些工作后，什么将必须为真。不变量说明组件生命过程中什么必须保持一直为真。情形情形是一个对象动作随时间变化的文本/程序化的描述，它描述了一个组件的工作方式。可能创建多重情形来描述基本途径（一个完整的运行)以及异常情况，错误和其它条件。跟踪能力你可以利用实现连接显示可跟踪能力。一个组件可能实现其它的模型元素（如：用例）也可能被其它的元素实现（如：类的包）。通过建立来自和去往组件的实现连接，你可能得到模型元素间的依赖关系的映射，和从初始需求到最终实现的可跟踪能力。示例下例显示了组件如何被连接起来，并提供了一个系统建立的概念和逻辑视图。这个例子着重描述了一个在线书店的服务器和安全元素。它包括网络服务器，防火墙，动态网页等。服务器组件这个图例示了在线书店主服务器侧组件的布局，这些组件把建立客户和购买事项组织在一起以提供所需功能。安全组件安全组件图显示如何对软件采取保护措施，如授权许可，浏览器，网络服务器，和其它模型元素协同工作向在建系统提供安全防护。2.6 物理模型这个物理/部署模型提供了一个描述组件在系统基础设施中部署的详细模型，它提供了有关网络能力，服务器规范，硬件需求和其它系统部署相关的详细信息。部署视图PM01: 物理模型物理模型显示了系统组件如何与在那里被部署。它是一个明确的系统布局图。部署图显示进入生产或测试环节后，系统的物理部署。即显示组件安置在那里，何种服务器，机器和硬件。也显示网络连接，局域网带宽等等。节点用来描绘任何服务器，工作站，或其它主机硬件，它们被用来在生产环境下部署组件。可以指明节点间的连接和指定节点的构造型（如TCP/IP）及需求。节点也可能有功能特性，最低硬件要求，操作系统级别，说明文件等等。下面对话框例示了节点设置的共同属性：2.7 如何使用UML我们已经在第一部分建立了这样一种认识，即UML是一种用于制定软件系统构成要素和交互方式标准的语言。UML涉及6大主要方面- 从用例模型、动态和逻辑模型到最终的物理部署模型，以及允许给模型添加特别标注的扩展机制。那么，如何使用UML呢?一般地，UML作为软件开发过程的一部分，在具体的CASE工具支持下，用来定义所开发系统的需求，交互和元素。开发过程的确切性质则取决所采用的开发方法。一个典型的开发过程大致如下： 1. 建立一个业务过程模型。业务过程模型被用来定义发生在企业或组织内部的高级业务活动和业务过程，并且是建立用例模型的基础。一般来说业务过程模型比一个软件系统所能实现的更多（比如：业务模型包括人力和其他过程）。 2. 映射用例模型到业务过程模型以精确定义你要提供的功能，并且是站在业务用户角度考虑的。每增加一个用例时，将创建一个从适当的业务过程到该用例的可跟踪链接（如：一个实现链接）。这个映射清楚地表达新系统将提供什么样的功能来满足业务过程中所描述的业务需求。这种映射也确保系统中每个用例都是有用的。 3. 完善用例-包括需求，约束、复杂程度、注释及情形。这些信息清楚地描述用例做什么，如何做以及执行时的相关约束。这个过程要保证用例始终满足业务过程的需求，包括每个用例的系统测试定义，该定义为该用例定义了接收标准。也包括了一些用户可接受的测试脚本：这些脚本定义了用户将如何进行测试和测试接收的标准。 4. 有了业务过程模型的输入与输出和用例的详细信息，就可以开始构建领域模型（高级业务对象）、顺序图、协作图和用户接口模型。这些图描述新系统中的要素以及这些要素之间的相互作用和用户执行用例时所需各种情形的接口。 5. 在领域模型、用户接口模型和情形图的基础上，开始建立对象类模型。这是制定系统中对象的明确规范：数据、属性、行为和操作。使用继承机制，可将领域对象抽象为类层次结构。处理各种情形的消息一般被映射到类的操作。如果使用一个现存的框架或设计模式，则可能导入现存模型的元素到新系统中。为每一个类定义单元测试、集成测试和系统测试。测试目的：1）类的功能是否如所定义的，2）类与其它类及组件的交互是否如期望的。 6. 当开发类模型时，可能需要将它分解成包和组件。一个组件代表一个可使用的软件块，它是一个类或者多个类的数据和行为的结合，并严格定义一个对外提供服务的接口。所以，从类模型的角度看，构造组件模型就是定义类的逻辑包。对于每一个组件，需要定义集成测试，以证实组件的接口满足规范要求，即与其它软件元素的关系。 7. 在完成上述工作的同时，需要获取一些额外的需求并整理成文档。例如：非功能性需求，性能需求，安全需求，义务需求，发布计划等。将这些需求在模型内部进行整合并随模型的进展而更新。 8. 部署模型定义系统的物理架构。这个工作可以提前开始以便于掌握系统的物理结构特性-使用什么样的硬件、操作系统、网络规模