EA14种图像以及连线

EA 14种图像以及连线关系
一、结构建模
1.1 类图
类图展示了面向对象系统的构造模块。

描绘了模型或部分模型的静态视图，显示它包含的属性和行为，而不是详细描述操作的功能或完善方法。

类图最常用来表达多个类和接口之间的关系。

泛化（Generalizations），聚合（aggregations）和关联（associations）分别是类之间继承，复合或应用，及连接的表现。

下面的图显示了类之间的聚合关系。

弱聚合（浅色箭头）表现在类 "Account" 使用 "AddressBook"，但是不必要包含它的一个实例。

强聚合（图中的黑色箭头）表示了目标类包含源类，例如，"Contact" 和"ContactGroup"值被包含在 "AddressBook"中。

类（Classes）
类是定义对象所具有的属性和行为的元素。

行为用类能理解的合适消息和适合每条消息的操作来描述。

类中也可能定义约束，标记值，构造型。

类的标柱（Class Notation）
类用矩形表示。

除类的名称外，还可以选择性地显示属性和操作。

分栏分别用来显示类的名称，属性和操作。

在下面图中，类的类名显示在最上面的分栏，它下面的分栏显示详细属性，如："center" 属性显示初始化的值。

最后面的分栏显示操作，如： setWidth，setLength 和 setPosition 以及他们的参数。

属性和操作名前的标注表示了该属性或操作的可见性: 如果使用 "+"号，这个属性或操作是公共的 ; "-" 号则代表这个属性或操作是私有的。

"#"号是这个属性或操作被定义为保护的，" ~" 号代表包的可见性。

接口（Interfaces）
接口是实施者同意满足的行为规范，是一种约定。

实现一个接口，类必需支持其要求的行为，使系统按照同样的方式，即公共的接口，处理不相关的元素。

接口有相似于类的外形风格，含有指定的操作，如下图所示。

如果没有明确的详细操作，也可以画成一个圆环。

当画成圆环的时候，到这个环形标柱的实现连接没有目标箭头。

表（Tables）
表尽管不是基本UML的一部分，仍然是“图型”能完成的实例用。

在右上角画一个表的小图标来表示。

表属性用“图型” ?column?表示。

绝大多数表单有一个主键，是由一个或几个字段组成的一个唯一的字码组合加主键操作来访问表格，主键操作“图型”为?PK?。

一些表有一个或多个外键，使用一个或多个字段加一个外键操作，映射到相关表的主键上去，外键操作“图型”为?FK?。

关联（Associations）
关联表明两个模型元素之间有关系，通常用在一个类中被实现为一个实例变量。

连接符可以包含两端的命名的角色，基数性，方向和约束。

关联是元素之间普通的关系。

如果多于两个元素，也可以使用菱形的关联关系。

当从类图生成代码时，关联末端的对象将变成目标类中实例变量。

见下图示例 "playsFor" 将变成"Player"类中的实例变量。

泛化（Generalizations）
泛化被用来说明继承关系。

连接从特定类元到一般类元。

泛化的含义是源类继承了目标类的特性。

下图的图显示了一个父类泛化一个子类，类“Circle”的一个实例将会有属性 “ x_position”，“ y_position” ，“radius” 和方法 “display()”。

注意：类 "Shape" 是抽象的，类名显示为斜体。

下图显示了与上图相同信息的视图。

聚合（Aggregations）
聚合通常被用来描述由更小的组件所构成的元素。

聚合关系表示为白色菱形箭头指向目标类或父类。

聚合的更强形式 -组合聚合（强聚合） - 显示为黑色菱形箭头，用来组合每次最大化的包含组件。

如果一个组合聚合的父类被删除，通常与他相关的所有部分都会被删除，但是，如果一个部件从组合中去掉，将不用删除整个组合。

组合是可迁，非对称的关系和递归的。

下面的图示：显示了弱聚合和强聚合的不同。

“ address book” 由许多 “contacts” 和 “contact groups”组成。

“contact group” 是一个“contacts”的虚分组; “contact”可以被包含在不止一个 “ contact group”。

如果你删除一个“ address book”，所有的 “contacts” 和 “contact groups” 也将会被删除；如果你删除“ contact group”，没有 “contacts”会被删除。

关联类（Association Classes）
关联类是一个允许关联连接有属性和操作的构造。

下面的示例：显示了远不止简单连接两个类的连接，如给“employee”分配项目。

“ employee”在项目中所起的作用是一个复杂的实体，既有自身的也有不属于“employee” 或 “project” 类的细节。

例如，“ employee”可以同时为几个项目工作，有不同的职务头衔和对应的安全权限。

依赖（Dependencies）
依赖被用来描述模型元素间广泛的依赖关系。

通常在设计过程早期显示两个元素之间存在某种关系，因为是初期而不能确定具体是什么关系，在设计过程末期，该继承关系会被归入已有构造型 (构造型可以是实例化 ?instantiate?，跟踪 ?trace?，导入 ?import?，和其它的关系)，或被替换成一个更明确类型的连接符。

跟踪（Traces）
跟踪关系是一种特殊化的依赖关系。

连接模型元素或跨模型但是具有相同概念的模型元素集。

跟踪被经常用来追踪需求和模型的变化。

由于变化是双向的，这种依赖关系的顺序通常被忽略。

这种关系的属性可以被指定为单向映射，但跟踪是双向的，非正式的和很少可计算的。

实现（Realizations）
是源对象执行或实现目标，实现被用来表达模型的可跟踪性和完整性－业务模型或需求被一个或多个用例实现，用例则被类实现，类被组件实现，等等。

这种实现贯穿于系统设计的映射需求和类等，直至抽象建模水平级。

从而确保整个系统的一张宏图，它也反映系统的所有微小组成，以及约束和定义它的细节。

实现关系用带虚线的实箭头表示。

嵌套（Nestings）
嵌套连接符用来表示源元素嵌套在目标元素中。

下图显示“ inner class”的定义，尽管在EA中，更多地按照着他们在项目层次视图中的位置来显示这种关系。

1.2 对象图
对象图可以认为是类图的特殊情形，是类图元素子集，被用来及时强调在某些点，类的实例间的关系。

这对理解类图很有帮助。

他们在构造上与类图显示没有不同，但是反映出多样性和作用。

类和对象元素
下面的图显示了类元素和对象元素外观上的不同。

注意：类元素包括三个部分，分别是名字栏，属性栏和操作栏；对象元素默认为没有分栏。

名称显示也有不同：对象名称有下划线，并可能显示该对象实例化所用类元的名称。

运行状态
类元元素可以有任意数量的属性和操作。

在对象实例中不会被显示出来。

但可能定义对象的运行状态，显示特殊实例的属性设置值。

类和对象图示例
下图是一个对象图，其中插入了类定义图。

它例示如何用对象图来测试类图中任务多重性的方法。

“car” 类对 “wheel” 类有“1对多” 的多重性，但是如果已经选择用“1对4” 来替代，那样就不会在对象图显示“3个轮子”的汽车。

1.3 复合结构图
复合结构图显示类元内部结构，包括它与系统其他部分的交互点。

也显示各部分的配置与关系，这些部分一起执行类元的行为。

类元素已经在类图部分被详细地阐述，这部分用来说明类表现复合元素的方式，如：暴露接口，包含端口和部件。

部件
部件是代表一组（一个或多个）实例的元素，这组实例的拥有者是一类元实例，例如：如果一个图的实例有一组图形元素，则这些图形元素可以被表示为部件，并可以对他们之间的某种关系建模。

注意：一个部件可以在它的父类被删除之前从父类中被去掉，这样部件就不会被同时删除了。

部件在类或组件内部显示为不加修饰的方框。

端口
端口是类型化的元素，代表一个包含类元实例的外部可视的部分。

端口定义了类元和它的环境之间的交互。

端口显示在包含它的部件，类或组合结构的边缘上。

端口指定了类元提供的服务，以及类元要求环境提供的服务。

端口显示为所属类元边界指定的方框。

接口
接口与类相似，但是有一些限制，所有的接口操作都是公共和抽象的，不提供任何默认的实现。

所有的接口属性都必须是常量。

然而，当一个类从一个单独的超级类继承而来，它可以实现多个接口。

当一个接口在图中单列出来，它既可以显示为类元素的方框，带 ?interface? 关键字和表明它是抽象的斜体名称，也可以显示为圆环。

注意：圆环标注不显示接口操作。

当接口显示为类所有的接口，它们会被当作暴露接口引用。

暴露接口可以定义为是提供的，还是需求的。

提供接口确认包含它的类元提供指定接口元素定义的操作，可通过类和接口间实现的连接来定义。

需求接口说明该类元能与其他类元进行通信，这些类元提供了指定接口元素所定义的操作。

需求接口可通过在类和接口间建立依赖连接来定义。

提供接口显示为“带棒球体”，依附在类元边缘。

需求接口显示为“带棒杯体”，也是依附在类元边缘。

委托
委托连接器用来定义组件外部端口和接口的内部工作方式。

委托连接器表示为带有 ?delegate? 关键字的箭头。

它连接组件的外部约定，表现为它的端口，到组件部件行为的内部实现。

协作
协作定义了一系列共同协作的角色，它们集体展示一个指定的设计功能。

协作图应仅仅显示完成指定任务或功能的角色与属性。

隔离主要角色是用来简化结构和澄清行为，也用于重用。

一个协作通常实现一个模式。

协作元素显示为椭圆。

角色绑定
角色绑定连接器是一条从连接协作到所要完成该任务类元的连线。

它显示为虚线，并在类元端显示作用名。

表现
表现连接器用于连接协作到类元来表示此类元中使用了该协作。

显示为带关键字 ?represents?的虚线箭头。

发生
发生连接器用于连接协作到类元来表示此协作表现了（同原文）该类元；显示为带关键字?occurrence?的虚线箭头。

1.4 组件图
组件图描绘了组成一个软件系统的模块和嵌入控件。

组件图比类图具有更高层次的抽象－通常运行时一个组件被一个或多个类（或对象）实现。

它们象积木那样使得组件能最终构成系统的绝大部分。

上图演示了一些组件和它们的内部关系。

装配连接器（Assembly connectors）“连接”由"Product"和"Customer"的提供接口到由 "Order"指定的需求接口。

一个依赖关系映射了客户相关的帐户信息到“Order”需要的 "Payment"需求接口。

实际上，组件图同包图很相似，它们都有明确的界限，把元素分组到逻辑结构中。

他们之间的不同是：组件图提供了语义更丰富的分组机制，在组件图中，所有的模型元素都是私有的，而包图只显示公有的成员。

表现组件
组件可表示为带关键字 ?component?的矩形类元；也可用右上角有组件图标的矩形表示。

装配连接器
装配连接器在组件 “Component1”的需求接口和另一个组件 “Component2”的提供接口之间建立桥梁; 这个桥梁使得一个组件能提供另一个组件所需要的服务。

带端口组件
使用端口的组件图允许在它的环境指定一个服务和行为，同时这个服务和行为也是组件需要的。

当端口进行双向操作的时候，它可以指定输入和输出。

下图详述了用于在线服务的带端口组件，它有两个提供接口 “order entry”和 “tracking”，也有 “payment” 需求接口。

1.5部署图
部署图部署图是对系统运行时的架构进行建模。

它显示硬件元素（节点）的配置，以及软件元素与工件是如何映射到这些节点上的。

节点
节点既可以是硬件元素，也可以是软件元素。

它显示为一个立方体，如下图所示。

节点实例
图可以显示节点实例，实例与节点的区分是：实例的名称带下划线，冒号放在它的基本节点类型之前。

实例在冒号之前可以有名称，也可以没有名称。

下图显示了一个具名的计算机实例。

节点构造型为节点提供了许多标准的构造型，分别命名为 ?cdrom?， ?cd-rom?， ?computer?， ?disk array?， ?pc?， ?pc client?， ?pc server?， ?secure?， ?server?， ?storage?， ?unix server?， ?user pc?。

并在节点符号的右上角显示适当的图标。

工件工件是软件开发过程中的产品。

包括过程模型（如：用例模型，设计模型等），源文件，执行文件，设计文档，测试报告，构造型，用户手册等等。

工件表示为带有工件名称的矩形，并显示?artifact?关键字和文档符号。

关联在部署图的上下文联系中，关联代表节点间的联系通道。

下图显示了一个网络系统的部署图，描述了网络协议为构造型和关联终端的多重性，
作为容器的节点节点可以包含其他元素，如组件和工件。

下图显示了一个嵌入式系统某个部分的部署图。

描写了一个被主板节点包含的可执行工件。

1.6 包图
包图用来表现包和它所包含元素的组织。

当用来代表类元素时，包图提供了命名空间的可视化。

包图最常用的用途是用来组织用例图和类图，尽管它不局限于这些UML元素。

下面是一个包图的例子。

包中的元素共享相同的命名空间，因此，一个指定命名空间的元素必须有唯一的名称。

包可以用来代表物理或逻辑关系。

选择把类包括在指定的包里，有助于在同一个包里赋予这些类相同继承层次。

通常认为把通过复合相关联的类，以及与它们相协作的类放在同一个包里。

在UML2.4.1 中，包用文件夹来表示，包中的元素共享同一个命名空间，并且必须是可识别的，因此要有唯一的名称或类型。

包必须显示包名，在附属方框部分有选择的显示包内的元素。

包的合并
包之间的合并连接符?merge?定义了源包元素与目标包同名元素之间的泛化关系。

源包元素的定义被扩展来包含目标包元素定义。

当源包元素与目标包内没有同名元素时，目标包元素的定义不受影响。

包的导入
导入连接符 ?import?表明目标包的元素，在该例中是一个类，在源包中被引用要用非限定修饰名。

源包的命名空间获得目标类的接口，目标包的命名空间则不受影响。

嵌套连接符
源包和目标包间的嵌套连接符说明目标包完全包含源包。

1.7 Profile图
UML Profiles提供了一个通用的扩展机制，用于构建UML模型的特定领域。

它们是基于附加的构造型和标记值，将之应用到元素，属性，方法，链接，链接终端及更多。

Profile是这些扩展的集合，同时描述了一些专有的建模问题，促进在该领域的建模构造。

例如，XML的UML profile由大卫卡尔森所定义，(见 “XML应用程序建模与UML”，第310页)，David Carlson描述了一组扩展基本UML模型的元素，提高XSD架构的精确建模。

Enterprise Architect有一个通用的UML Profile机制来加载和使用不同的Profile来工作。

Enterprise Architect的UML Profiles专门使用XML格式的文件, 使用特定格式 - 见下面的实施。

这些XML文件可以被导入到EA在项目浏览器的资源页面。

导入后，您可以拖放配置文件的元素到当前图。

如果指定了一个新的元素，EA将对其附加构造型，标记值和默认值，注释及图元文件。

您也可以拖放属性和操作到已经存在的类，并向他们立即加入专有构造型和标记值等。

为了便于开始, 我们提供以下一些用于下载的profiles，你可以导入到EA。

随着时间的推移，我们将扩大profile范围，可以在每个profile的程度上对每个配置文件的内容和定制。

请记住，你总是可以创建自己的profile来描述建模场景特有的开发环境。

下面提供使用配置文件的更多细节。

在EA中UML profile基本的信息
XSD模式的UML Profile (“XML应用程序建模与UML”,大卫·卡尔森注)
这个profile 定义了一组构造型和标记值来定义XSD架构
XSD模式Profile
业务流程建模的UML Profile
UML Profile for 业务建模从UML1.4规范中的示例配置文件导出
BPProfile.xml
Eriksson-Penker扩展的业务流程建模 (来自“业务建模与UML”，Hans-Erik Eriksson和Magnus Penker 编辑)
改进版本由Cephas Consulting编写, 这个profile是用来定义一组构造型，表达与业务活动，过程，对象和信息流的工作。

EP_Extensions.xml
关联端可以在图中拖动链接元素终端到图中关联关系的终端
删除一个Profile
要删除profile，右击profile删除，然后上下文菜单选项中选择“删除profile”。

请注意，这不会产生负面使用此profile已经定义的元素的影响。

如果用的是profile导入一个构造型是在使用中，也不会被从模型时删除profile删除。

重新加载Profile
重新加载profile, 你先删除上面profile，然后再次导入。

EA的未来版本将包括更新profile的能力。

示例图由Profile元素构建出构造型的显示和标记值：
二、行为建模
2.1 交互概览图
一个交互概览图是活动图的一种形式，它的节点代表交互图。

交互图包含顺序图，通信图，交互概览图和时间图。

大多数交互概览图标注与活动图一样。

例如：起始，结束，判断，合并，分叉和结合节点是完全相同。

并且，交互概览图介绍了两种新的元素：交互发生和交互元素。

交互发生
交互发生引用现有的交互图。

显示为一个引用框，左上角显示 "ref" 。

被引用的图名显示在框的中央。

交互元素
交互元素与交互发生相似之处在于都是在一个矩形框中显示一个现有的交互图。

不同之处在内部显示参考图的内容不同。

将它们放在一起
所有的活动图控件，都可以相同地被使用于交互概览图，如：分叉，结合，合并等等。

它把控制逻辑放入较低一级的图中。

下面的例子就说明了一个典型的销售过程。

子过程是从交互发生抽象而来。

2.2 用例图
用例模型
用例模型用来记录系统的需求，它提供系统与用户及其他参与者的一种通信手段。

执行者
用例图显示了系统和系统外实体之间的交互。

这些实体被引用为执行者。

执行者代表角色，可以包括：用户，外部硬件和其他系统。

执行者往往被画成简笔画小人。

也可以用带?actor?关键字的类矩形表示。

在下图中，执行者可以详细的泛化其他执行者:
用例
用例是有意义的单独工作单元。

它向系统外部的人或事提供一个易于观察的高层次行为视图。

用例的标注符号是一个椭圆。

使用用例的符号是带可选择箭头的连接线，箭头显示控制的方向。

下图说明执行者 "Customer"使用 "Withdraw"用例。

用途连接器（uses connector）可以有选择性的在每一个端点有多重性值，如下图，显示客户一次可能只执行一次取款交易。

但是银行可以同时执行许多取款交易。

用例定义
一个典型的用例包括:
名称和描述
需求
约束
情形
情形图
附加信息。

名称和描述
用例通常用一个动词词组定义，而且有一个简短的文字说明。

需求
需求定义了一个用例必须提供给终端用户的正式功能性需求。

它们符合构造方法建立的功能性规范。

一个需求是用例将执行一个动作或提供多个值给系统的约定或承诺。

约束
一个约束是一个用例运行的条件或限制。

它包括：前置条件，后置条件和不变化条件。

前置条件指明了用例在发生之前需要符合的条件。

后置条件用来说明在用例执行之后一些条件必须为"真"。

不变化条件说明用例整个执行过程中该条件始终为"真"。

情形
情形是用例的实例在执行过程中，事件发生流程的形式描述。

它定义了系统和外部执行者之间的事件指定顺序。

通常用文本方式来表示，并对应顺序图中的文字描述。

包含用例
用例可能包含其他用例的功能来作为它正常处理的一部分。

通常它假设，任何被包含的用例在基本程序运行时每一次都会被调用。

下面例子：用例“卡的确认” 在运行时，被用例“取钱”当作一个子部分。

用例可以被一个或多个用例包含。

通过提炼通用的行为，将它变成可以多次重复使用的用例。

有助于降低功能重复级别。

扩展用例
一个用例可以被用来扩展另一个用例的行为，通常使用在特别情况下。

例如：假设在修改一个特别类型的客户订单之前，用户必须得到某种更高级别的许可，然后 “获得许可”用例将有选择的扩展常规的“修改订单”用例。

扩展点
扩展用例的加入点被定义为扩展点。

系统边界
它用来显示用例在系统内部，执行者在系统的外部。

2.3 活动图
UML中，活动图用来展示活动的顺序。

显示了从起始点到终点的工作流，描述了活动图中存在于事件进程的判断路径。

活动图可以用来详细阐述某些活动执行中发生并行处理的情况。

活动图对业务建模也比较有用，用来详细描述发生在业务活动中的过程。

一个活动图的示例如下所示。

下面描述组成活动图的元素。

活动
活动是行为参数化顺序的规范。

活动被表示为圆角矩形，内含全部的动作，工作流和其他组成活动的元素。

动作
一个动作代表活动中的一个步骤。

动作用圆角矩形表示。

动作约束
动作可以附带约束，下图显示了一个带前置条件和后置条件的动作。

控制流
控制流显示一个动作到下一个动作的流。

表示为带箭头实线
初始节点
一个开始或起始点用大黑圆点表示，如下图。

结束节点
结束节点有两种类型：活动结束节点和流结束节点。

活动结束节点表示为中心带黑点的圆环。

流结束节点表示为内部为叉号的圆环。

这两种不同类型节点的区别为：流结束节点表明单独的控制流的终点。

活动结束终点是活动图内所有控制流的结束。

对象和对象流
对象流是对象和数据转递的通道。

对象显示为矩形。

对象流显示为带箭头的连接器，表明方向和通过的对象。

一个对象流在它的至少一个终端有一个对象。

在上图中，可以采用带输入输出引脚的速记标柱表示。

数据存储显示为带 ?datastore? 关键字的对象。

判断节点和合并节点
判断节点和合并节点是相同标注：菱形。

它们可以被命名。

从判断节点出来的控制流有监护条件，当监护条件满足时，可以对流控制。

下图显示了判断节点和合并节点的使用。

分叉和结合节点
分叉和结合节点有同样的标柱：垂直或水平条（方向取决于工作流从左到右，还是从上到下）。

它们说明了控制的并发线程的起始和终点，下图显示他们的使用示例。

结合节点与合并节点不同之处在于：结合节点同步两个输入量，产生一个单独的输出量。

来自结合节点的输出量要接收到所有的输入量后才能执行。

合并节点直接将控制流传递通过。

如果两个或更多的输入量到达合并节点。

则它的输出流指定的动作会被执行两次或更多次。

扩展域
扩展域是会执行多次的结构活动域。

输入输出扩展节点表示为一组“3厢” ，代表多个选择项。

关键词"iterative"， "parallel" 或 "stream"显示在区域的左上角
异常处理器
异常处理器在活动图中可以建模。

可中断活动区
可中断活动区环绕一组可以中断的动作。

在下面非常简单的例子中：当控制被传递到结束订单 "Close Order" 动作，定单处理"Process Order" 动作会执行直到完成，除非"Cancel Request"取消请求中断被接受，这会将控制传递给"Cancel Order"动作。