UML 2.5的14种图术语和解释

UML 2.5的14种图术语和解释

序号	图表UML图	图简要说明
1	用例图	从用户的角度提供系统或业务流程功能的概述。用户“使用”系统的方式是创建用例图的起点。
2	活动图	对系统中任何位置的流进行建模。特别是，描述正常用户交互以及替代和例外的用例中的流程由这些活动图很好地建模。
3	类图	类图表示类，它们的定义和关系 问题空间中的类和实体也是解决方案空间中的详细技术实体。 定义类的属性和操作包含在此类图中。类图中的关系说明了类如何与其他类交互，协作和继承。类还可以表示关系表，用户界面和控制器。
4	序列图	序列图根据对象的时间轴模拟对象之间的交互。对象可以在这些图上具体显示，也可以是属于类的匿名对象。运行时对象之间的消息执行顺序由这些图很好地建模，因此它们的名称为
5	交互概述图	交互概述图 以一般的高级别呈现系统内交互的概述;它还使得能够理解UML图（例如，序列图）如何依赖于彼此并且彼此相关。
6	通信图	通信图显示对象在运行时如何在内存中相互通信（交互）。这些通信图在其目的方面类似于序列图;但是，他们的代表性是不同的。
7	对象图	对象图 在运行时显示内存中的对象及其链接。 因此，这些对象图还有助于在实践中可视化多重性。
8	状态机图	状态机图 显示内存中对象的运行时生命周期。这样的生命周期包括对象的所有状态以及状态改变的条件。
9	组合结构图	组合结构图 在运行时模拟组件或对象行为，显示系统执行期间组件的布局，关系和实例
10	组件图	组件图 从结构上模拟组件及其关系。 这些组件可以包括例如可执行文件，可链接库，Web服务和移动服务。这些图表为系统的架构决策增加了价值。
11	部署图	部署图对系统的硬件节点和处理器的体系结构进行建模，并提供显示软件组件所在节点的机会。
12	包图	包图 表示系统组织的子系统和区域。它还可以模拟包之间的依赖关系，并帮助将业务实体与用户界面，数据库，安全性和管理包分开。
13	时序图	时序图模拟时间的概念以及对象状态随时间变化的方式。此外，这些图可以同时比较多个对象的状态。
14	配置文件图	配置文件图 允许创建可扩展的配置文件，这些配置文件可应用于从配置文件继承的元素。这些图表通过以受控方式扩展标准来增加价值

 

UML图的性质和基础知识UML图的性质理解如下：

◾结构与行为 - 图表的结构方面说明了系统的组织方式，而行为方面则模拟了系统的流程。例如，结构显示了类在类图中如何相互关联。行为显示了用户与系统交互的方式 - 例如，通过用例或活动图。

◾静态与动态 - 静态与动态方面描述了模型的时间依赖性。没有时间或运动概念的图表是静态的，而显示时间变化（甚至是时间快照）的图表被认为是动态的。

前面提到的UML图的性质也不是防水分类。每个图表都展示了UML图的上述特性 - 但是某些特征非常强烈地展现出来，而其他特征在这些图中可能不存在。

UML图的简要回顾以下部分是UML图的简要回顾或“演练”。目的是了解图表的性质，目的和“外观和感觉”。每个子部分还提供了该图的基本示例。如前所述，并非每个图表对软件项目中的每个角色都很重要。在第3章（参见表3.2）中，讨论了每个图表对软件项目中不同角色（如程序员，设计人员或业务分析师）的相对重要性。

 

1.用例图

用例图是高级系统要求的模型。用例图主要用于可视化用例，相应的扇区及其交互。图表本身不是用例，而是演员和一组相关用例的视觉效果。用例的可视化模型有助于理解业务流程并有助于与利益相关者进行沟通。用例图中显示的用例的规范和文档构成了需求建模的关键。

用例图本质上是行为静态的。这是因为它们有助于在问题空间中组织和评估系统的要求。在用例图中看不到需求的行为方面。由于两个用例之间或者actor和用例之间的关系不代表时间的概念，因此用例图被归类为静态图。因此，应注意将用例图视为描述系统的流程或行为。

 

2.活动图

 活动图模拟系统中的流程或流程。因此，它们就像流程图。流的建模可以在业务流程级别，用例内，有时在用例之间完成。

活动要么在详细的技术层面，要么在业务层面。活动图记录了用例，用例或整个业务中的内部行为。更高级别的活动图用作显示各种业务流程如何相关的上下文图。

 

活动图的另一个重要特征是能够显示活动之间的依赖关系。活动图还有助于将活动映射到系统中的相应参与者。此外，由于它们能够显示多个线程（通过分支和连接，如第7章所述），它们还可以展示系统中同时发生的事情。活动图提供的多线程建模功能也有助于对问题空间进行建模。因此，这些图提供了一种优秀的业务流程建模机制。

活动图的性质被认为是行为的。这是因为这些图表显示了活动以及这些活动发生的顺序。但是，活动图不会显示活动何时发生。在这种程度上，活动图是通用的行为流程图。因此，它们不被视为动态图（例如序列图）。

因此，活动图的性质是行为静态的。

例如，考虑图其显示了来自医院领域的简单活动图。患者和系统显示为两个分区（在早期版本的UML中称为泳道，在第7章中详细讨论），其中正在进行一系列活动。活动图显示了患者如何询问医生的可用性以便安排咨询。

 

 

 

3.类图

 类图是SE中最流行的图表之一。类图表示业务中的关键实体以及技术领域。类图本质上是高度结构化和静态的，没有行为内容。类图可以显示业务级类，以及从实现语言派生的技术类（例如，Java或C ++ - ）。除了显示类之外，类图还显示了类之间的关系。类（或实体，因为它们可能在问题空间中调用）的完整描述以及它们彼此之间的关系是静态的。此图中没有显示依赖关系，也没有时间概念。注释和约束（在第10章的UML可扩展性机制中讨论）以有限的方式显示类对类图的依赖性。

下面的图显示了一个简单的类图，其中包括Doctor，Patient，Surgeon和Physician。此外，它显示了医生和患者之间的关联关系，以及显示来自Doctor类的推导的继承关系。关于类图的详细讨论见第8章，第9章和第11章。

类图模型实体（即业务和技术级别的类）及其关系。 这些图中的类包含属性和操作（可以是可见的或隐藏的），关系（继承，关联）和多重性。

 

4.序列图

自从Jacobson将它们作为记录用例内行为的一种手段引入时，序列图一直很流行。在早期的使用中，序列图也称为场景图，因为它们以图形方式表示用例中的场景（或实例）。

由于它们能够显示用户“内部”发生的事情，因此序列图在业务分析师和系统设计人员中都很受欢迎。用例中的每个步骤在序列图上显示为注释或旁白。

序列图表示参与者和系统之间或给定时间块内的协作对象之间的详细交互。但是，序列图中未显示有关交互开始之前发生的事件以及时间块停止后发生的情况的信息。虽然序列图中显示的消息可以具有前置条件和后置条件，但这些条件在图中不是直接可见的。尽管存在这种限制，但图中出现的“时间”远比活动图中的“时间”精确得多。

 

因此，可以显示两条消息之间发生的情况，并确定随着时间的推移会发生什么。因此，序列图在本质上被认为是动态行为的。

下面的图显示了一个简单的序列图，显示了一个演员（Ravi：Patient）如何检查特定医生（Sue：Doctor）的可用性。反过来，Doctor对象必须转到Calendar对象以检查医生的可用性。

序列图显示了对象和系统之间交互的单一场景（通过消息）。 消息序列很重要。

这些图表可能包含演员。 序列图不能显示条件（“if-then-else”）

 

5.交互概述图

交互概述图，顾名思义，提供了系统内发生的交互的高级概述。 由于这些交互最好使用序列（或替代地，通信）图来描绘，因此交互概览图包含对序列图的引用。 交互概览图可以描述“if-then-else”情况。

因此，交互概览图更接近活动图。 交互概览图在本质上被认为是行为静态的。

下图是一个简单的交互概述图，引用了两个用例：ChecksDoctorAvailability和SchedulesConsultation。

6.通讯图

 通信图显示了一组协作对象，它们如何通过消息相关联，以及这些消息的顺序。通信图显示了与序列图中类似的信息，但其显示方式不同。尽管如此，出于所有实际目的，通信图的性质是动态行为 - 与序列图相同并且出于同样的原因。在视觉上，通信图可以被认为是显示对象发送和接收的所有消息的工具。该信息可用于确定运行时对象上的负载。

图2.7显示了一个通信图。演员（Ravi：Patient）检查特定医生（Sue：Doctor）的可用性，如图2.5所示的序列图所示。然后Doctor对象转到Calendar对象，以检查医生是否可以进行咨询。 1：CheckAvailability（）和2：CheckSchedule（）方法具有强制编号（此编号在序列图中是可选的）。由于他们的“技术”感觉，他们在设计中比在分析中使用更多。因此，本书不再讨论通信图。相反，序列图用于进行所有动态行为建模。

对象图对象图在特定时间点显示各种对象的结构及其相互之间的关系。因此，它们本质上是结构性的。但是，因为对象图显示了运行时对象的结构，对特定时间点系统中发生的事情进行建模，所以它们也被视为动态的。然而，这种动态性只是在操作系统时计算机存储器中的“快照”或多个对象之间的一组链接。图表无法显示系统随时间的任何变化。

因此，这些图是“及时暂停” - 显示在主存储器中的对象之间的关系发生的事情，或者作为表达和讨论白板上的多重性的机制。因此，对象图的性质可以归类为动态结构。

图2.8显示了一个对象图，它将名为aDoctor的医生对象与三个Patient实例相关联：John，Mary和Ravi。在图（类图）中，Doctor类与Patient类相关联。对象图准确显示了与医生相关的患者数量。

在图中，医生与John：患者，Mary：患者和Ravi：患者 - 相关联，因为这位特定的医生正在处理三名患者，可能是在一段时间或一天内。如果另一位医生只处理两名患者，那么对象图将显示这两名患者。请注意，对于这两种对象图变体，相应的类图（图2.4）保持不变。

 

 

7.对象图

对象图描述了各种对象（实例）以及它们之间的关系。 关系是记忆中的链接。

作为实例级图，它们非常适合描述类之间的多重性

 

8.状态机图

状态机图属于类的对象可以处于各种状态，整个系统也可以。 状态机图（也称为状态图）指示对象或用例或整个系统可以是的各种状态。 与对象图（显示系统的“实例版本”或“快照”）相比，状态机图显示了对象的所有可能状态。

下面的状态机图显示了对象的各种状态; 它们还显示了对象发生状态变化的事件和保护条件。

通常用相应的类名称来引用它们。

 

 

 

9.组合结构图（Composite Structure Diagram）

 

组合结构图本质上是建筑结构，非常适合背景空间中的建模要求。复合结构图在运行时分解对象或组件，并显示链接到该对象的各种接口和实现，如图2.9所示。这些图显示了运行时方案，其中显示了运行时组件的结构。因此，它们的本质是动态结构 - 类似于对象图。

图2.9显示了一个非常简单的复合结构图，描述了Doctor组件的运行时方案。 Doctor组件与另外两个接口ScheduleForm和Calendar相关。对于需求建模者来说很明显，运行时的Doctor组件依赖于Calendar接口，它用于检查医生的可用性。但是，当涉及到显示信息时，ScheduleForm将依赖于Doctor组件来显示信息。

复合结构图显示了内存中组件和运行时对象的链接和分解。

 

10.

组件图

组件图

组件图本质上是静态结构的。它们在实现时显示系统的结构，但它们不显示系统在运行中的行为。组件图也没有包含时间概念，因此不是动态的。组件图仅显示类和各种其他逻辑工件最终将作为最终可执行文件实现（或编码）的位置。因此，组件图是包含系统代码的最终可执行文件和链接库的图形表示。

图2.11显示了一个包含两个组件的简单组件图：Doctor和Calendar。此外，该图还显示了Doctor对日历的依赖性。

请注意，在技术层面，组件还可以包括COM +对象，Enterprise Java bean可执行文件，链接对象的链接库等。因此，组件成为主要是类的集合的物理表示。组件（如类）也可以驻留在包中，组件也具有接口。

 

 

 

 

11.部署图

 

部署图

部署图本质上是结构性和静态的。与UML中的所有其他图不同，部署图是UML中唯一的“硬件”图。它们显示了处理节点的组织，以实现软件系统的部署。它们还显示在这些节点上执行的组件。作为硬件图，部署图为与硬件相关的决策进行通信提供了宝贵的基础。部署图可以讨论系统的操作要求，包括系统处理速度和容量的能力，节点的位置和安全性，以及跨网络部署可执行文件的方式。

部署图的限制是它们没有足够的符号来表示详细系统体系结构的各种硬件节点。这导致各种工具供应商和开发人员为部署图创建他们自己的符号版本。

因此，在共享和阅读部署图时可能会出现混淆。

显示了一个基本部署图。它显示了医院服务器机器或处理器和两个患者处理器的存在。此外，显示的服务器与打印机有关，打印机是另一个物理设备。更复杂的部署图将包含其他设备，例如局域网（LAN），Internet，云表示，防火墙和数据库服务器。

图。包是UML的逻辑上有凝聚力的工件和图表的集合。

 

12.包图

包代表子系统; 它包含其他UML图的大而有凝聚力的集合。 包图本质上是组织的，显示包及其依赖关系。

 

包图本质包结构图本质上是静态结构的，提供了一种在问题空间中组织需求的极好方法。包主要代表系统（子系统）的大而有凝聚力的部分。从建模角度来看，包图被视为组织图。包是UML的逻辑上有凝聚力的工件和图表的集合。

因此，包装图仅显示系统组织的俯视图 - 鸟瞰图。包图还可能显示包之间的依赖关系。但是，包图中的依赖关系不是强制性的，并且不如包本身那么重要。

由于其组织角色，包图没有与之关联的行为。

上面显示了一个简单的包图，其中staff包依赖于Calendar包。请注意，人员和日历不是类，而是包含与员工和日历相关的详细功能模型的包或子系统。

包代表子系统; 它包含其他UML图的大而有凝聚力的集合。 包图本质上是组织的，显示包及其依赖关系。

 

 

13.时序图

时序图是在UML的后续版本中引入的（从UML 2.0开始）。

它们的价值在于比较对象状态 - 在问题或解决方案空间中。时序图本质上是动态行为，描绘了对象的状态以及状态在精确时间点的变化。这些图来源于工程中用于显示对象状态更改的时序图。虽然通过状态机图实现了类似的目的，但时序图同时显示了多个对象及其相应的状态。

图2.14给出了一个时序图示例，显示了Doctor对象操作和非操作的两种状态。此时序图还显示状态更改发生的确切点以及对象在返回非操作之前保持在操作（开启）状态（在此情况下，由约束{80分钟}显示）的时间长度（关闭） ）状态。时序图不像其他UML图那样受欢迎。

 

时序图显示一个或多个对象及其状态。 时间限制也显示在此图中。 它们有助于在时间点比较多个对象的状态。

 

 

 

14.

配置文件图

UML的底层元模型允许它应用于各种情况。将UML扩展到项目特定应用程序的一种可能方法是配置文件图。概要文件定义可以包括UML元素以及构造型，标记和约束。此类配置文件是为特定于开发的平台（如.NET和J2EE）创建的。还可以为特定项目创建配置文件，例如建模业务流程。

例如，考虑图它显示了从<< meta-class >>继承<< stereotype >>的示例配置文件图。 << meta-class >>包含可以使用配置文件进行专门化的细节。这种专门化可以限制和检查基于给定元类的新类的参数和行为。例如，<< stereotype >>可以将新类限制为单继承（与多继承层次结构相对）。这种限制基于在配置文件图中创建的项目特定“配置文件”的应用。

配置文件图启用UML的扩展，例如构造型的可视化（例如，继承Meta-class的所有特征，如此图所示）