UML简介

• Unified Modeling Language：统一建模语言UML。UML2推动了UML规范的成功，并迅速成为可视化软件系统的公认标准。UML也被用于非软件系统的建模，并且在包括金融、军事和工程在内的大多数工业部门中被广泛实现。
• UML分为两个通用集，包括14种类型的基本图：
  • 结构模型图Structural Modeling Diagrams：结构图定义模型的静态体系结构。它们被用来对构成模型的“事物”建模——类、对象、接口和物理组件。此外，它们还用于建模关系和元素之间的依赖。
  • 行为模型图Behavioral Modeling Diagrams：行为图捕获交互的多样性和模型内的瞬时状态，因为它随着时间的推移而“执行”;跟踪系统在真实环境中的行为，观察操作或事件的效果，包括结果。
• 结构模型图：7种
  • 包图Package Diagrams：包图用于将模型划分为逻辑容器或“包”，并在高层次上描述它们之间的交互。
  • 组件图Component Diagrams：组件图用于建模更高级别的或更复杂的结构，通常由一个或多个类构建，并提供定义良好的接口。
  • 类或结构图Class or Structural Diagrams：类或结构图定义了模型的基本构建块：类型、类和用于构建完整模型的一般材料。
  • 部署图Deployment Diagrams：部署图显示了现实世界设置中重要工件的物理配置。
  • 组合结构图Composite Structure Diagrams：复合结构图提供了一种将元素的结构分层并关注内部细节、结构和关系的方法。
  • 对象图Object Diagrams：对象图显示了结构元素的实例在运行时是如何关联和使用的。
  • 概要图Profile Diagrams：概要图提供了一种可视化的方式来定义UML规范的轻量级扩展。UML概要文件经常用于定义一组具有特定领域或特定平台属性和约束的构造，这些属性和约束扩展了底层的UML元素。
• 行为模型图：7种
  • 用例图Use Case Diagrams：用例图用于对用户/系统交互建模。它们以脚本或场景的形式定义行为、需求和约束。
  • 序列图Sequence Diagrams：序列图与通信图密切相关，并显示了使用垂直时间轴在对象之间传递的消息序列。
  • 活动图Activity Diagrams：活动图有广泛的用途，从定义基本的程序流，到捕获任何通用流程中的决策点和操作。
  • 时序图Timing Diagrams：时序图融合了序列图和状态图，以提供随时间变化的对象状态视图，以及修改该状态的消息。
  • 状态机图State Machine Diagrams：状态机图对于理解即时到即时的条件或模型执行时的“运行状态”是必不可少的。
  • 交互概述图Interaction Overview Diagrams：交互概览图融合了活动和序列图，允许交互片段与决策点和流程轻松地结合。
  • 通信图Communication Diagrams：通信图显示协作实例期间运行时对象之间的消息或通信的网络和顺序。

结构模型图

• 包图 Package Diagrams

  包图用于反映包及其元素的组织。当用于表示类元素时，包图提供了命名空间的可视化。包图最常见的用途是组织用例图和类图，尽管包图的使用并不局限于这些UML元素。

  包中包含的元素共享相同的名称空间。因此，特定名称空间中包含的元素必须具有唯一的名称。

  可以构建包来表示物理关系或逻辑关系。当选择在特定的包中包含类时，将具有相同继承层次结构的类分配给相同的包是很有用的。还有一个强有力的论点是，在同一个包中包含通过组合相关的类，以及与它们协作的类。

  包在UML 2.1中表示为文件夹，并包含共享名称空间的元素；包中的所有元素都必须是可识别的，因此具有唯一的名称或类型。包必须显示包名，并且可以选择在额外的分隔中显示包中的元素。

  Package Merge：«merge»合并连接器定义了源包中的元素和目标包中具有相同名称的元素之间的隐式泛化。源元素定义被扩展为包含目标中包含的元素定义。目标元素定义不受影响，源包元素的定义不与目标包中的任何元素匹配。

  Package Import**：«import»导入连接器指出目标包中的元素(在本例中为单个类)在从源包引用时使用非限定名称。源包的命名空间获得对目标类的访问权;目标的名称空间不会受到影响。

  Nesting Connectors：«nesting»嵌套连接器显示源包完全包含在目标包中。

  <<------------------------包图--------------------------->>

• 组件图 Component Diagrams

  组件图说明了组成系统的软件、嵌入式控制器等部件。组件图比类图具有更高的抽象级别——通常一个组件在运行时由一个或多个类(或对象)实现。它们是构建块，因此一个组件最终可以包含系统的大部分。

  上图展示了一些组件及其相互关系。组装连接器将“Product”和“Customer”提供的接口“链接”到“Order”指定的所需接口。依赖关系将客户的关联帐户详细信息映射到所需的接口;“付款”，由“订单”表示。

  组件在实践中类似于包图，因为它们定义边界并用于将元素分组到逻辑结构中。包图和组件图之间的区别在于组件图提供了语义更丰富的分组机制。使用组件图，所有的模型元素都是私有的，而包图只显示公共项。

  组件被表示为带有关键字«component»的矩形分类器;可选地，组件可以显示为一个矩形，在右上角有一个组件图标。

  Assembly Connector：组装连接器将组件所需的接口(Component1)与另一个组件所提供的接口(Component2)连接起来;这允许一个组件提供另一个组件所需的服务。

  <<------------------------组件图--------------------------->>

• 类图 Class Diagrams

  类图显示了任何面向对象系统的构建块。类图描述了模型的静态视图，或者模型的一部分，描述了它所具有的属性和行为，而不是详细描述实现操作的方法。类图在说明类和接口之间的关系时非常有用。泛化、聚合和关联在分别反映继承、组合或使用以及连接方面都很有价值。

  Classes：类是定义对象能够生成的属性和行为的元素。行为由类能够理解的可能消息以及适用于每条消息的操作来描述。类也可能有约束、标记值和构造型的定义。

  Class Notation：类符号。类由矩形表示，矩形显示类的名称，还可选显示操作和属性的名称。分隔用于划分类名、属性和操作。

  Interfaces：接口是实现者同意满足的行为规范;这是一份合同。通过实现接口，类可以保证支持所需的行为，从而允许系统以相同的方式处理不相关的元素——即通过公共接口。

  Tables：虽然表不是基本UML的一部分，但是表是可以用原型完成的事情的一个例子。它的右上角有一个小的表格图标。表属性是构造型的«column»。大多数表都有一个主键，即一个或多个字段，它们组成了一个用于访问表的唯一组合，再加上一个构造型«PK»的主键操作。一些表将有一个或多个外键，即一个或多个字段一起映射到相关表中的一个主键，再加上一个构造型«FK»的外键操作。

  详细介绍请看：https://sparxsystems.com/resources/tutorials/uml2/class-diagram.html

• 部署图 Deployment Diagrams

  部署图为系统的运行时架构建模。它显示了硬件元素(节点)的配置，并显示了软件元素和工件如何映射到那些节点上。

  Node：节点可以是硬件元素，也可以是软件元素。它显示为一个三维的盒子形状。

  Node Instance：节点实例可以在图上显示。实例与节点的区别在于实例的名称有下划线，并且在其基本节点类型之前有冒号。实例在冒号之前可能有名称，也可能没有名称。

  Node Stereotypes：为节点提供了许多标准原型，即«cdrom»，«cd-rom»，«计算机»，«磁盘阵列»，«pc»，«pc客户端»，«pc服务器»，«安全»，«服务器»，«存储»，«unix服务器»，«用户pc»。这将在节点符号的右上角显示适当的图标。

行为模型图

• 用例图 Use Case Diagrams 20230213

  Use Case Model：用例模型。用例模型捕获系统的需求。用例是一种与用户和其他涉众沟通系统打算做什么的方法。

  Actors：演员。用例图显示了系统和系统外部实体之间的交互。这些外部实体被称为参与者。参与者表示角色，可能包括人类用户、外部硬件或其他系统。参与者通常被绘制为一个命名的简笔画，或者是一个带有«actor»关键字的类矩形。

  <<------------------------用例图角色--------------------------->> <<------------------------用例图角色继承--------------------------->>

  Use Cases：用例。用例是一个有意义的工作单元。它提供了对系统外的人或物可观察到的行为的高级视图。用例的符号是一个椭圆。

  <<------------------------用例图用例--------------------------->>

  使用用例的符号是一条带有显示控制方向的可选箭头的连接线。下面的图表明参与者“Customer”使用“Withdraw”用例。

  <<------------------------用例图用例使用--------------------------->>

  «use»连接器可以在每一端有多个值，如下图所示，其中显示客户一次可能只有一个提款会话，但银行可以有任意数量的客户同时进行提款。

  <<------------------------用例图用例数量--------------------------->>

  用例定义：一个典型的用例包括以下部分

  Name and description：名称和描述，用例通常被命名为一个动词短语，并给出一个简短的非正式文本描述。

  Requirements：需求，需求定义了用例必须提供给最终用户的正式功能需求。它们对应于结构化方法中的功能规范。需求是用例将执行某个操作或向系统提供某些价值的契约或承诺。

  Constraints：约束，约束是用例在其下操作的条件或限制，包括前置、后置和不变条件。前提条件指定了在用例继续之前需要满足的条件。后置条件用于记录在用例执行之后必须为真条件中的更改。不变条件指定在整个用例执行过程中为真条件。

  Scenarios：场景，场景是在用例实例执行期间发生的事件流的正式描述。它定义了系统和外部参与者之间的特定事件序列。它通常以文本形式描述，并与序列图的文本表示相对应。

  Including Use Cases：包括用例，用例可能包含另一个用例的功能，作为其正常处理的一部分。通常，假定每次运行基本路径时都将调用任何包含的用例。用例可以包含在一个或多个用例中，通过将公共行为分解为多次重用的用例，帮助减少功能的重复级别。

  Additional information：额外的信息，一个用例可以用来扩展另一个用例的行为;这通常用于特殊情况。

  Extension Points：扩展点，添加扩展用例的点可以通过扩展点来定义。

  System Boundary：系统边界，通常将用例显示为系统内部，而将参与者显示为系统外部。

  <<------------------------用例图系统边界--------------------------->>