UML入门

课程资源：https://www.icourse163.org/learn/PKU-1003177002

UML概述和相关术语

• UML是一种可视化语言；UML适用于对所有重要的分析、设计和实现决策进行详细描述UML描述的模型可与各种编程语言直接相关联。
• UML是系统分析和设计的工具。
• 面向对象方法主要提供了两类术语：结构化地表达客观事物的术语和表达客观事物之间关系的术语

结构化地表达客观事物的术语

1. 类与对象（class） – 体现数据抽象

   1. 定义与表示
      • 类的表示（三个栏目的矩形框：名称、属性、方法）
      • 类的简化表示（只有包含类名的矩形框）
      • 抽象类的表示（类名斜体字）
        
   2. 类名（类的标识）
      • 类名使用黑体字，首字母大写，居中
      • 类名往往是从正被建模系统的词汇表中提取的简单名词或名词短语。
   3. 属性
      1. 定义与表示
         1. 一个属性往往具有所属的类型，用于描述该特性的实例可以取值的范围。
         2. 一个类可以有多个属性，也可以没有属性。
         3. 类的一个对象对应的属性应有特定的值。
      2. 根据作用范围将属性分为：实例范围的属性、类范围的属性
         1. 实例范围的属性（非static）
         2. 类范围的属性（static）
      3. 定义属性的格式
         • [可见性]属性名[:类型][多重性][=初始值][{性质串}]
         1. 可见性
            1. + 公有的：可供其他类使用
            2. # 受保护的：其子类可以使用
            3. - 私有的：只有本类才可以操作该属性
            4. ~ 包内的：在同一个包中声明的类才能使用
            • 也可以使用关键字public、protected、private和package表示可见性
         2. 属性名：属性的标识串，小写开头，左对齐
         3. 类型：对属性实现类型的规约，与具体实现语言有关。
         4. 多重性：表示属性值的数目
            • 例如：points[2…*]:Point
            • 多重性可以省略，此时多重性是1…1.即属性只有一个值。
            • 如果属性是0…1，就有可能出现空值。
         5. 初始值：用于为新建对象赋予初值。
         6. 性质串：上面5个都是围绕着属性的取值，这个是为了表达属性的性质。
            • 比如：a: integer=1{frozen}表示该属性不可改变。
      4. 属性的声明举例
         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-nBarrJOM-1622289423977)(http://121.196.104.224/data/note/img_UML/1.7.png)]
   4. 操作：对一个类中所有对象要做的事情的抽象。
      1. 定义与表示
         • 一个类可以有多个操作，也可以没有
         • 操作明除了第一个词之外，其他每个词的首字母均要大写
         • 抽象操作（斜体）
      2. 类范围的操作和实例范围的操作
      3. 表达操作的完整语法格式
         • [可见性]操作名[(参数表)][:返回类型][{性质串}]
         1. 参数表
            • 语法格式：[方向]参数名:类型[=默认值]
            1. 方向
               1. in 输入参数
               2. inout 输入参数，可修改
               3. out 输入参数，可修改
               • 注意：out或inout等价于(显式返回参数+in参数)
                 提供out和inout是为了与较老的编程语言相兼容，可用显式返回参数代替。
         2. 返回类型
            • 如果无返回值，就省略
            • 如果返回多个，可以使用表达式列表
            • 可以省略全部参数表和返回类型，但不能指省略其中的一部分。
      4. 操作的多态性
         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-3HSTcNUf-1622289423978)(http://121.196.104.224/data/note/img_UML/1.16.png)]

2. 接口（interface） – 体现功能抽象

   1. 定义
      • 接口是一组操作的集合，其中每个操作描述了类或构件的一个服务。
      • 表明一个类、构件、子系统所要得到的、且与实现无关的行为。
   2. 表示
      • 带有<>关键字且居中，操作分栏给出操作列表，属性分栏为空，其他与类的表示相同。
      • 与接口的三种关系
        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Kta85QfU-1622289423981)(http://121.196.104.224/data/note/img_UML/1.8.png)]
   3. 几点说明
      1. 接口不描述内部结构
      2. 接口没有属性、状态或关联，接口只有操作
         • 形式上等价于一个没有属性、没有方法只有抽象操作的抽象类。
      3. 接口只能被其他类目使用，其本身不能访问其它类目
      4. 接口之间没有关联、泛化、实现和依赖，但可以参与泛化、实现和依赖关系

3. 协作（collaboration） – 体现行为结构抽象

   • 协作是一组类、接口和其他元素的群体共同工作以提供比各组成部分的总和更强的合作行为。
   • 协作是一个交互，涉及交互三要素：交互各方、交互方式以及交互内容。交互各方的共同工作提供了某种协作方式。
   • 表示
     
   • 2点说明
     1. 协作有两个方面
        1. 结构部分
           • 详细说明共同工作以完成该协作的类、接口和其他元素
           • 经常用组合结构图或类图来表示
             [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZZLsbVAK-1622289423985)(http://121.196.104.224/data/note/img_UML/1.10.png)]
        2. 行为部分
           • 详细说明元素间如何交互，经常用交互图来表示。
     2. 由于一个给定的类或对象可以参与多个协作，因此协作表现了系统细化的构成模式。
   • 注意：协作是系统体系结构的概念组块，不能拥有自己的结构元素，而要引用其他地方声明的类、接口、构件、接地那和其他结构元素。

4. 用况（use case） – 体现功能的抽象

   • 对一组动作序列的描述，系统执行这些动作产生一个对特定的参与者有值的、可观察的结果。
   • 表示
     
   • 2点说明
     1. 用况用于模型化系统的行为，是建立系统功能模型的重要术语
        • 一个用况描述了系统的一个完整的功能需求。
     2. 用况是通过协作予以细化的。

5. 主动类（active class） – 体现并发行为抽象

   • 一种至少具有一个进程或线程的类，因此它能启动控制活动。
   • 表示
     
   • 主要特性：主动类对象的行为通常与其他元素的行为是并发的。

6. 构件（component）

   • 构建是系统中逻辑的、可替换的成分，它遵循并提供了一组接口的实现。
   • 表示
     
   • 2点说明
     1. 在一个系统中，共享相同接口的构建可以相互替代，但其中要保持相同的逻辑行为。
     2. 构件可以包含更小的构件。

7. 制品（artifact）

   • 是系统中物理的、可替代的部件，其中包含物理信息（比特）。
   • 表示
     [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7YXsWq88-1622289423990)(http://121.196.104.224/data/note/img_UML/1.14.png)]
   • 2点说明
     1. 一个系统中，可能会存在不同类型的部署制品，例如源代码文件、可执行程序和脚本等。
     2. 制品通常代表对源代码信息或运行时信息的一个物理打包。

8. 节点（node）

   • 运行时存在的物理元素，通常表示一种具有记忆能力和处理能力的计算机资源。
   • 表示
     
   • 1点说明
     1. 一个构件可以驻留在一个节点中，也可以从一个节点迁移到另一个节点。

• 表达客观事物的术语小结
  1. UML给出了8个术语（模型化概念）
     • 类、接口、协作、用况、主动类、构件、制品、节点
  2. 它们是可包含在一个UML模型中的基本模型化元素。
  3. 它们存在一些变体，比如
     1. 类的变体：参与者、信号、实用程序
     2. 主动类的变体：进程和线程
     3. 制品的变体：应用、文档、库、页、表
  4. 在UML中，把以上结构化概念统称为类目（classifier）

表达客观事物之间关系的术语

• UML中提供了4中关系，作为UML模型中的基本关系构造块，表示类目之间的关系。

1. 关联（association）
   1. 定义：关联是类目之间的结构关系，描述了一组具有相同结构、相同语义的链(links)
      • 链是对象之间的连接(connection)
   2. 表示
      
   3. 根据连接类目的数量分类
      1. 二元关联：一个关联只能连接两个类目
      2. n元关联：一个关联连接n个类目
   4. 关联中的7个概念
      1. 关联名（name）：关联的标识
      2. 角色名（role）：一个类参与一个关联的角色标识
      3. 多重性（multiplicity）
         • 类中对象参与一个关联的数目，称为该关联角色的多重性。
         • 关联一端的多重性，说明：对于关联另一端的类的每一个对象，本段的类可能有多个对象出现。
           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-bOXr1Ihd-1622289423993)(http://121.196.104.224/data/note/img_UML/2.2.png)]
      4. 聚合（aggregation）
         • 一种特殊形式的关联，表达一种“整体”/“部分”关系。即一个类表示了一个大的事物，它是由一些小的事物（部分）组成的。
         • 注意：不论是整体类还是部分类，他们在概念上处于同一层次。这是区分是否把一类事物标识为一个类的属性的基本准则。
         • 聚合的表示
           
      5. 组合（composition）
         • 定义：如果整体类的实例和部分类的实例具有相同的生命周期，这样的聚合叫组合。
         • 4点说明
           1. 组合是聚合的一种形式。部分和整体之间具有很强的“属于”关系，即具有一致的生存期。
           2. 组合的末端，多重性显然不能超过1.
           3. 一个组合中，由一个链所连接的对象而构成的任何元组，必须属于同一个整体类的对象。
              什么叫一个链？
           4. 一个组合中，其部分可以包含一些类和关联；根据需要，也可以把他们规约成关联类
         • 组合的表示
           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vGLqjdUf-1622289423995)(http://121.196.104.224/data/note/img_UML/2.4.png)]
      6. 限定符
         • 一个限定符是一个关联的属性或属性表，这些属性的值将对该关联相关的对象集做了一个划分。
         • 限定符的表示
           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-lfGVJUyo-1622289423996)(http://121.196.104.224/data/note/img_UML/2.5.png)]
      7. 关联类
         • 一种模型元素，它有关联和类的特性。一个关联类，可以被看作是一个关联，但还有关联的特性；或被看作是一个类，但是由关联的特性。
         • 关联类的表示
           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kk1BypEj-1622289423997)(http://121.196.104.224/data/note/img_UML/2.6.png)]
2. 泛化（generalization）
   • 泛化是一般性事物（称为超类或父类）和它的较为特殊种类（称为子类）之间的一种关系，有时称为“is-a-kind-of”关系。
   • 4点说明
     1. 子类可继承父类的属性和操作，并可有更多的属性和操作。
     2. 子类可以替换父类的声明。
     3. 若子类的操作的实现覆盖了父类同一个操作的实现，这种情况称为多态性，但两个操作必须具有相同的名字和参数。
     4. 一个类可以有0、1、多个父类。
        • 没有父类且最少有一个子类的类被称为根类或基类；没有子类的类称为叶子类。
        • 如果一个类只有一个父类，则说明它使用了多继承。
        • 注：大多数情况下，用类和接口之间的泛化来表明继承关系。但，其他类目之间也可以创建泛化。
   • 2种表示方法：分离表示法、共享表示法
     [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-etBEhvYA-1622289423999)(http://121.196.104.224/data/note/img_UML/2.7.png)]
3. 实现（realization）
   • 也称为细化
   • 细化是类目之间的一种语义关系，其中一个类目规约了保证另一个类目执行的契约。
   • 下面2个地方或使用细化关系
     1. 接口与实现它们的类和构件之间
     2. 用况与实现它们的协作之间
   • 实现的表示
     
4. 依赖（dependency）
   • 依赖是一种使用关系，用于描述一个事物（如类Window）使用另一事物（如类Event）的信息和服务。
   • 3点说明
     1. 在大多数情况里，使用依赖来描述一个类使用另一个的操作。
     2. 如果被使用的类发生变化，那么另一个类的操作也会受到影响。
     3. 依赖可用于其他事物之间，例如注解之间和包之间。
   • 依赖的表示
     
   • 为进一步表达依赖的语义，UML对依赖进行了分类
     1. 绑定（bind）：表明源的实例化是使用目标给定的实际参数来达到的
        • 例如：可以把模板容器类（目标)和这个类实例(源)之间的关系模型化为绑定。其中绑定涉及到一个映射，即实参到形参的映射。
          绑定没看懂
     2. 导出（derive）：表明可以从目标推导出源。
        • 例如：类Person有属性“生日”和“年龄”，假定属性“生日”是具体的，而“年龄”是抽象的，由于“年龄”可以从“生日”导出，因此可以把这两个属性之间的这一关系模型化为导出。
     3. 允许(permit)
        • 表明目标对源而言是可见的。一般情况下,当许可一个类访问另一个类的私有特征时，往往把这种使用关系模型化为允许。
     4. 实例(instanceof)
        • 表明源的对象是目标的一个实例。
     5. 实例化(instantiate)
        • 表明源的实例是由目标创建的。
     6. 幂类型(powertype)
        • 表明源是目标的幂类型。幂类型是一个类目，其对象都是一个给定父类的子类。
     7. 精化(refine)
        • 表明源比目标更精细。例如在分析时存在一个类A，而在设计时的A所包含的信息要比分析时更多。
     8. 使用(use)
        • 表明源的公共部分的语义依赖无目标的语义.

• 上面四个术语是UML模型中可以包含的基本关系。他们也有一些变体，例如精化、跟踪、包含和扩展等

• UML基本关系的一般用法

  1. 模型化简单依赖
     • 简单的依赖：一个类只是使用另一个类作为它的操作参数。
     • 对此，可以从【含有操作的类】到【被该操作用作参数的类】创建一个依赖关系。如下图
       [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-alrhV9y2-1622289424002)(http://121.196.104.224/data/note/img_UML/2.10.png)]
  2. 模型化单继承
     1. 第一步：对于给定的一组类，发现2个或2个以上类的共同责任、属性和操作。
     2. 第二步：把发现的共同责任、属性和操作放到一个一般类中其中要注意，不要引入过多的层次。
     3. 第三步：画出从每个特殊类到一般类（父类）的泛化关系。
     • 简单继承关系如下图：
       [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-KrKHbsSd-1622289424003)(http://121.196.104.224/data/note/img_UML/2.11.png)]
  3. 模型化结构关系

     1. 第一步：标识关联

        • 若对于每个类，需要导航到另一个类的对象，那么就要在这两个类之间建立一个关联。 —— 这是关联数据驱动观点
        • 若对于每个类的对象需要与另一个类的对象进行交互，并且后一个对象不作为前一个对象的局部变量或操作参数，那么就要在这2个类之间给出一个关联。 —— 这是关联数据驱动观点
          [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZEGHN2kT-1622289424003)(http://121.196.104.224/data/note/img_UML/2.12.png)]

     2. 第二步：对于标识的每个关联，添加语义描述
        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eXUginhV-1622289424004)(http://121.196.104.224/data/note/img_UML/2.13.png)]

     3. 第三步：标识“整体/部分”

        • 如果关联中的一个类与另一端的类相比，前者在结构上或组织上是一个整体，而后者似乎是它们的一部分，那么就要把它们标识为聚合。

        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9pp6zYty-1622289424005)(http://121.196.104.224/data/note/img_UML/2.14.png)]

• 在使用UML对关系建模时，要遵循以下策略

  1. 仅当要建模的关系不是结构关系时，才使用依赖
     什么是结构关系？这条策略意味着什么？
  2. 仅当关系是“is-a-kind-of”关系时，才能使用泛化。
     聚合可否替代多继承？
  3. 一般不要引入循环的泛化关系
  4. 应保持泛化关系的平衡：继承的层次不要太深，也不要太宽。可以寻找可能的中间抽象类，进行泛化关系的平衡

其他术语

除了这两类术语之外，还引入了包和注解

1. 包：为了控制信息组织的复杂性，还引入了用于组织特定对象结构的包

   1. 语义
      • 包是模型元素的一个分组。一个包本身可以被嵌套在其他包中，并且可以含有子包和其他种类的模型元素。
      • 包的三种可见性
        1. + 对其他包可见
        2. - 对其他包不可见
        3. # 对子孙包可见
   2. 表示
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Rz2Tqs7L-1622289424006)(http://121.196.104.224/data/note/img_UML/1.18.png)]
   3. 包之间的关系
      • 两种依赖：访问依赖和引入依赖
      1. 引入依赖(一个包引用其他包)<>
         1. 从源包到目标的引入依赖表示：目标包中有适当可见性的内容被加入到源包的公共命名空间中。即源包对它们的引用不需要一个路径名。
         2. 表示：从源包到目标包的一条带箭头的线段，并标记为<>，如下图
            [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g9pEYbkL-1622289424007)(http://121.196.104.224/data/note/img_UML/1.19.png)]
         3. 引入依赖和包的可见性的含义表示
            [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kJnURGlX-1622289424008)(http://121.196.104.224/data/note/img_UML/1.20.png)]
      2. 访问依赖(一个包访问其他包)<>
         1. 从源包到目标包的访问依赖表示：目标包中具有可见性的内容增加到源包的私有命名空间中。即源包不能将访问依赖获取的内容对外可见。
   4. 对成组的元素建模策略
      1. 浏览特定体系结构视图中（如类图）的建模元素,找出概念或语义上相互接近的元素所定义的组块.把每一个这样的组块围在一个包内.
      2. 对每一个包判别哪些元素要在包外访问,把这些元素标记为公共的，把所有其他元素标记为受保护的或私有的.
      3. 用引入依赖显示地连接建立在其他包之上的包.
      4. 在包的家族中，用泛化关系把特殊包连接到它们的较一般的包.

2. 注解：为了使建造的系统模型容易理解，引入了注解

UML模型表达工具

1. UML为不同抽象层提供了6种可对系统静态部分建模的图形工具
   1. 类图
   2. 构件图
   3. 组合结构图
   4. 对象图
   5. 部署图
   6. 制品图
2. UML为不同抽象层提供了7中可对系统动态部分建模的图形工具
   1. 用况图
   2. 状态图
   3. 活动图
   4. 顺序图
   5. 通信图
   6. 交互概观图
   7. 定时图

静态部分建模工具

• 重点讲解【类图】的使用

类图

• 静态模型表达工具

1. 定义：类图显示了类（及其接口）、类的内部结构以及与其他类的联系，是面向对象分析和设计所得到的最重要的模型。
2. 类图的内容
   1. 通常包含：类；接口；依赖、泛化和关联关系等
   2. 还可以包含注解和约束，以及包或子系统，甚至，可包含一个实例，以便使其可视化。
   • 这些成分，确定了所表达系统的各种形态
   • 比如
     [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-c24BMlPI-1622289424009)(http://121.196.104.224/data/note/img_UML/3.1.png)]
     [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0JlPT02i-1622289424009)(http://121.196.104.224/data/note/img_UML/3.2.png)]
3. 类图的一般用法
   • 类图主要用于对系统的静态视图进行建模（投影），支持表达系统的功能需求，即系统提供给最终用户的服务。
   • 创建类图包括以下3方面工作

     1. 对系统中的概念建模，形成类图中的基本元素

        • 使用UML中的术语“类”，来抽象系统中各个组成部分，包括系统环境。确定每一类的责任，最终形成类图中的模型元素。

     2. 对待建系统中的各种关系建模，形成该系统的初始类图

        • 使用UML中表达关系的术语，例如关联、泛化和依赖等来抽取系统中各个成分之间的关系，形成该系统的初始类图

        1. 当用关联关系建模时，是在对相互同等的两个类建模。给定两个类间的关联，则这两个类以某种方式相互依赖，并且常常从两边都可以导航。
           导航是什么意思|

           1. 对于每一对类，如果需要从一个类的对象到另一个类的对象导航，就要在这两个类之间建立一个关联。
              
           2. 对于每一对类，如果一个类的对象要与另一个类相互交互，而后者不作为前者的过程局部变量或操作参数，就要在这两个类之间建立一个关联。
           3. 如果关联中的一个类与另一端的类相比，前者在结构或者组织上是一个整体，后者看起来像它的部分，则在靠近整体的一端用一个菱形对关联修饰，从而将其标记为聚合。
              
           4. 对于每一个关联，都要说明其多重性（特别当多重性不为*时，其中*是默认的多重性）

        2. 依赖关系是使用关系，常见的依赖关系是两个类之间的连接，其中一个类只是使用另一个类作为它的操作参数。
           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-4WKCEpn8-1622289424012)(http://121.196.104.224/data/note/img_UML/3.5.png)]

        3. 泛化关系是“is-a-kind-of”关系，在对系统的词汇建模中，经常遇到结构或行为上与其他类类似的类，可以提取所有共同的结构特征和行为特征，并把它们提升到较一般的类中，特殊类继承这些特征。

           1. 给定一组类，寻找两个或以上的类的共同责任、属性和操作
           2. 把这些共同的责任、属性和操作提升为较为一般的类
           3. 画出特殊类到它的较一般的父类的泛化关系，用以表示较特殊的类继承较一般的类。

           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oM6IYRVY-1622289424013)(http://121.196.104.224/data/note/img_UML/3.6.png)]

     3. 模型化系统中的协作，给出该系统的最终类图
        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ddi6bZVZ-1622289424014)(http://121.196.104.224/data/note/img_UML/3.7.png)]

动态部分建模工具

• 重点讲解【用况图、顺序图、状态图】的使用

用况图

• 系统行为（功能）的建模工具
• 注：对行为的抽象，一直是人们的一个研究课题
• 用况图是表现一组Use cases、Actors以及它们之间关系的图。

1. 用况图的内容
   1. 通常包含6个抽象：主题（Subject）、用况（Use cases）、参与者（Actor）、依赖、泛化、关联。
      • 以上抽象确定了所表达的系统的各种形态。
   2. USE CASE图还可以包含包，形成一些更大的功能块。
      • 有时为了对一个特定的执行系统进行可视化，也把用况图的实例放到USE CASE图中。
   • 注：为使USE CASE图表达的系统更易理解，包含注解和约束。
2. 用况图的术语
   1. 主题
      1. 定义：由一组用况所描述的一个系统或子系统
         • 其中这些用况描述了该主题的完整行为，
         • 而参与者则表示与该主题进行交互的另一种类。
      2. 表示
         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-pLebCaHX-1622289424015)(http://121.196.104.224/data/note/img_UML/4.1.png)]
   2. USE CASE
      1. 定义（两个视角）
         1. 使用视角：用况表达了参与者使用系统的一种方式
            [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-vR4QzMmU-1622289424016)(http://121.196.104.224/data/note/img_UML/4.2.png)]
         2. 系统设计视角：一个用况规约了系统可以执行的一个动作序列。
            
      2. 两点说明
         1. 功能的体现：以USE CASE规约的系统功能是通过与操作者可见结果的“交互”予以体现的。即一个USE CASE捕获了参与交互的各方关于其行为的约定。
         2. 描述：对一个USE CASE的行为，可以根据具体情况，通过交互（图）、活动（图）和状态机予以描述，或通过前置条件和后置条件予以描述，或通过自然语言予以描述。
      3. 用况对以后开发活动的影响
         1. USE CASE是系统分析和设计阶段的输入之一
            • 是类、对象、操作的源；并作为分析和设计的依据
         2. USE CASE是指定开发计划、测试计划、设计测试用例的依据之一
         3. USE CASE可以划分系统与外部实体的界限，是系统开发的起点。
   3. 参与者
      1. 定义：参与者是一组高内聚的角色，当用户与USE CASE交互时，该用户扮演了这一角色
      2. 3点说明
         1. 一个参与者一般可以表达与系统交互的那些人、硬件或其他系统
         2. 参与者实际上不是软件应用的一部分，而是在应用的环境之中，其实例代表以某种特定方式与系统进行交互
         3. 一个客体对象可以扮演多个参与者，例如一个人既可以是参与者LoanOfficer，又是参与者Customer。即一个参与者代表了客体以方面的角色。
      3. 表示
         
      4. 参与者的关系：可以定义参与者之间的泛化关系
         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-rs5xXYe5-1622289424019)(http://121.196.104.224/data/note/img_UML/4.5.png)]
   4. 关系
      1. 关联：参与关系，即操作者参与一个USE CASE。例如，操作者的实例与USE CASE实例相互通讯。
         • 关联是操作者和USE CASE之间的唯一关系。
      2. 扩展: USE CASEA到USE CASE B的一个扩展关系，指出了UsE CASE B的一个实例可以由A说明的行为予以扩展（根据该扩展所说明的特定条件），并依据该扩展点定义的位置，A说明的行为被插入到B中。
      3. 包含：USE CASE A到USE CASEB的一个包含，指出A的一个实例将包含B说明的行为，即这一行为将包含在A定义的那部分中。
      4. 泛化：USE CASE A到USE CASE B的泛化，指出A是B的特殊情况
      • 注：扩展和包含是依赖的变体。
      • 表示
        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Mw48vETi-1622289424020)(http://121.196.104.224/data/note/img_UML/4.6.png)]
3. 用况图的使用
   1. 对系统语境建模
      对语境建模应遵循的基本策略
      1. 决定哪些行为是系统的一部分，哪些行为是由外部实体执行的，以此标识系统边界，同时定义主题。
      2. 在标识系统的参与者时，应考虑以下问题
         1. 谁需要得到系统的帮助
         2. 谁执行系统的功能
         3. 系统与哪些硬件设备或其他系统交互
         4. 谁执行一些辅助功能进行系统的管理和维护
      3. 将一些相似的参与者组织为一般/特殊结构
      4. 在需要加深理解的地方，为每个参与者提供一个衍型
      5. 最后，将这些参与者放入用况图中，并建立他们与系统用况之间的关联-通信路径。
   2. 对需求建模
      对系统的需求建模应遵循的策略
      1. 通过标识参与者来建立系统的语境
      2. 对于每个参与者考虑他所期望或需要系统提供的行为。并把他们作为用况。
      3. 通过分解用况所表达的公共行为，形成必要的泛化结构；分解异常行为，放入新的用况以延伸较为主要的用况；
      4. 模型化用况图的各种关系
      5. 通过注解和约束给出这些用况的非功能需求
      • 下图显示了对系统的需求建模
        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-kYEqym82-1622289424020)(http://121.196.104.224/data/note/img_UML/4.7.png)]

顺序图

• 系统行为（交互）的建模工具

1. 定义：顺序图是一种交互图，即由一组对象以及这些对象之间的关系（通信）组成，其中还包含这些对象之间被发送的消息。

2. 表示
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-9Aur3jfn-1622289424021)(http://121.196.104.224/data/note/img_UML/5.1.png)]

3. 内容

   1. 交互各方：角色或对象
   2. 交互方式：同步或异步
   3. 交互内容：消息
   4. 像其他图形一样，可以包含注解和约束
   • 从应用的角度来看，交互图是一个交互中各元素（各方、方式和内容）的投影。其中把这些元素的语义应用到交互图中。
   • 3点说明
     1. 对象生命线
        • 用于表示一个对象在特定的时间段中的存在。
        • 对象生命线被表示为垂直的虚线。
     2. 消息
        • 顺序图包含了一些由时间定序的消息。消息被表示为一条箭头线，从一条生命线到另一条生命线
        1. 如果消息是异步的：枝形箭头线表示
        2. 如果消息是同步的（调用），则用实心三角箭头线表示
           • 同步消息的回复用枝形箭头虚线表示。
     3. 顺序图中的控制结构：为了控制交互行为描述的复杂性，更清晰地表达顺序图中的复杂控制
        [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Cn9WUYjf-1622289424022)(http://121.196.104.224/data/note/img_UML/5.2.png)]

4. 控制类型

   1. 选择执行（Optional execution）

      • 标签为opt
      • 仅当进入该操作子（control operator），监护条件为真时，该控制操作子的体才执行
      • 监护条件是一个布尔表达式，可以出现在该体中任意一个生命线顶端的方括号内，并且可以应用那个对象的属性。

   2. 条件执行

      • 标签为alt
      • 该操作子的体通过水平线将其分为一些部分。每个部分表示一个条件分支，并有一个监护条件。
      1. 若一个部分的监护条件为真，那么该部分就被执行。但是，最多一个部分可以被执行。如果多个监护条件为真时，选择哪一部分执行，这是一个非确定性的问题，其执行可以不同。
      2. 如果没有一个监护条件为真，那么控制将绕过该控制操作子而继续。
      3. 一个部分可以有一个特定的监护条件[else];对于这一部分而言，如果没有其它监护条件为真，那么该部分才被执行。

   3. 并发执行

      • 标签为par
      • 一种控制结构类型，其标签为par。该控制操作子的体通过水平线将其分为多个部分。每一部分表示一个并行计算。在大多数情况下，每一部分涉及不同的生命线。
      1. 当进入该控制操作子时，所有部分并发执行。
      2. 在每一部分中的消息的发送/接受是有次序的，但在整个并发部分中的消息次序则完全是任意的。

   4. 迭代执行

      • 标签为loop。
      • 监护条件出现在该体中一个生命线的顶端，只要在每一次迭代之前该监护条件为真，该循环体就反复执行。当该体上面的监护条件为假时，控制绕过该控制操作子。
   • 还存在其他控制操作子，但是以上4中最常使用

状态图

• 系统行为（生存周期）的建模工具

1. 定义

   • 状态图是显示一个状态机的图，其中强调了从一个状态到另一个状态的控制流。
   • 注：一个状态机是一种行为，规约了一个对象在其生存期因响应事件并作出响应而经历的状态。

2. 表示
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-mjUI1UUK-1622289424023)(http://121.196.104.224/data/note/img_UML/5.3.png)]

3. 状态图的内容

   1. 简单状态和组合状态
   2. 事件
   3. 转换
   4. 和其他图形一样，可以包含注解和约束
   • 从使用的角度来看，一个状态图可以包含一个状态机中任意的、所有的特征。
   • 即，状态图基本上是一个状态机中那些元素（分支、结合、动作状态、活动状态、对象、初始状态、最终状态、历史状态等）的一个投影。
   • 状态图中所包含的内容，确定了一个特定的抽象层，该抽象层决定了以状态图所表达的模型之形态。

   1. 状态

      1. 定义

         • 一个状态是类目的一个实例（以后简称对象）在其生存期间的一个条件或情况，该期间该对象满足这一条件，执行某一活动或等待某一消息。

      2. 表示

         • 一个状态表达了一个对象所处的特定阶段，所具有的对外呈现（外征）以及所能提供的服务。

         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-2DwEGs1v-1622289424024)(http://121.196.104.224/data/note/img_UML/5.4.png)]

      3. 状态的分类

         1. 初态
            • 表示状态机默认的开始位置，用实心圆来表示
         2. 终态
            • 表示状态机的执行已完成，用内含一个实心圆的圆来表示
         3. 正常状态
            • 既不是初态又不是终态的状态，称为正常状态。
         • 初态和终态都是伪状态，即只有名字。从初态转移到正常状态可以给出一些特征，例如监护条件和动作。

         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-YINLMJR4-1622289424025)(http://121.196.104.224/data/note/img_UML/5.5.png)]

      4. 状态的规约：命名、进入/退出之效应、状态内部转移、子状态与组合状态、被延迟事件

         1. 名字：状态的标识串，也可以有匿名状态没有状态名。

         2. 进入/退出之效应（effect）

            • 是进入或退出该状态时所执行的动作。为表达进入/退效应，UML给出2种动作标号
            1. entry
               该标号标识在进入该状态时所要执行的、由相应动作表达式所规定的动作，简称进入动作
            2. exit
               该标号标识在退出该状态时所要执行的、由相应动作表达式所规定的动作，简称退出动作
            • 一般情况下：进入/退出之效应不能有参数或监护条件，但位于类状态机顶层的进入效应可以具有参数，以表示在创建一个对象状态机时所要接受的参数。

         3. 状态内部转移

            • 指：没有导致状态改变的内部转移。
            • 一般情况下，在此给出对象在这个状态中所要执行的内部动作或活动列表。
            • 其中表达动作的一般格式为：动作标号/动作表达式
            • 动作标号标识了在该环境下所要调用的动作，而该动作是通过/之后的动作表达式所规约，其中可以使用对象范围内的任何属性和链。若该表达式为空，则可省略斜线分隔符。
            • 为了表达状态内转换中的动作或活动，UML给出了一个专用的动作标号:do，该标号标识正在进行由其相应动作表达式所规定的活动，并且只要对象在一个状态中没有完成由该动作表达式所指定的活动，就一直执行之;当动作表达式指定的活动完成时，可能会产生一个完成事件。
            • 注:动作标号“entry”、“exit”和“do”均不能作为事件名。
            • 在以上的叙述中，使用了两个词:动作(action)和活动(activity)
              1. 活动是指状态机中一种可中断的计算，中断处理后仍可继续;
              2. 动作是指不可中断的原子计算，它可导致状态的改变或导致一个值的返回。
              • 可见，一个活动往往是有多个动作组成的。

         4. 子状态与组合状态

            • 如果在一个状态机中引入另一个状态机，那么被引入的状态机称为子状态机。子状态是被嵌套在另一个状态的状态。相对地，没有子状态的状态称为简单状态；而含有子状态的状态称为组合状态。
            • 子状态机分类：顺序子状态机（非正交）和并发子状态机（正交）

            1. 非正交子状态机

               • 一个非正交状态机最多有一个子初态和一个子终态。

               [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-961vWutr-1622289424026)(http://121.196.104.224/data/note/img_UML/5.6.png)]

               1. 关于转入问题
                  • 从组合状态之外的一个源状态，①可以转移到该组合状态作为其目标状态，②也可以转移到组合状态中的一个子状态，作为其目标状态。
                  1. 第一种情况中，这个被嵌套的子状态机一定有一个初态，以便在进入该组合状态并执行其进入动作后，将控制传送给这一初态。
                  2. 第二种情况中，在执行完该组合状态的进入动作（如有的话）和该子状态的进入动作后，将控制传送给这一子状态。
               2. 关于离开问题
                  • 离开一个组合状态，其源①可以是该组合状态②也可以是该组合状态中的一个子状态。
                  • 无论哪种情况，控制都是:①首先离开被嵌套的状态，即执行被嵌套状态的退出动作(如有的话)；②然后离开该组合状态，即执行该组合状态的退出动作（如有的话）。
                  • 即：如果一个转移,其源是一个组合状态，那么该转移的本质是终止被嵌套状态机的活动。
                  • 当控制到达该组合状态的子终态时，就触发一个活动完成的转移。
               3. 关于离开组合状态之前执行活动相关子状态标识问题
                  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-VoSBJmx8-1622289424026)(http://121.196.104.224/data/note/img_UML/5.7.png)]

            2. 正交子状态机

               • 正交子状态机是组合状态中的一些并发执行的子状态。

               [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-eAsH7HQi-1622289424027)(http://121.196.104.224/data/note/img_UML/5.8.png)]

               1. 关于转入问题：分岔
                  当一个转移到达具有多个正交区域的组合状态时，控制就被分成多个并发流-分岔。正交区域的执行是并行的，相当于存在两个被嵌套的状态机。

               2. 关于离开问题：汇合

                  1. 如果一个正交区域先于另一个到达它的终态时，那么该区域的控制将在该终态等待，直到另一个区域的控制达到自己的终态时，两个区域的控制才汇合成一个控制流-汇合。
                  2. 当一个转移离开这样的组合状态时，控制就汇成一个控制流。
                  3. 如果所有正交区域均达到它们的终态，或存在一个指示离开组合状态的转移，那么就汇成一个流。

                  [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-DDjbAqJn-1622289424028)(http://121.196.104.224/data/note/img_UML/5.9.png)]

         5. 被延迟事件

            • 被延迟事件是那些在一个状态中不予处理的事件列表。往往需要一个队列机制，对这样的事件予以推迟并予排队，以便在该对象的另一状态中予以处理。

   2. 事件

      • 一个事件是对一个【有意义的发生】的规约，该发生有其自己的时空。在状态机的语境下，一个事件是一个激励（stimulus），可引发状态的转换
      • 事件的种类
        1. 内部事件
           • 在系统内对象之间传送的事件。例如：溢出异常
        2. 外部事件
           • 在系统和它的参与者之间传送的事件。例如：按下一个按钮，一个来自传感器的中断。
      • UML提供4种事件相关模型：信号、调用、时间事件和变化事件、发送事件和接收事件

      1. 信号

         • 信号是消息的一个类目，是消息类型。

         • 信号由属性和操作，信号之间可以有泛化

         • UML中，可将信号模型化为具有名字<>衍型类

           • 可以把衍型看成元类型（一种定义其他类型的类型），因为每一个衍型将创建一个相当于UML元模型中新类的等价物。

           

         • 可用依赖衍型<>来表示一个操作发送了一个特定的信号。
           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Szm8pFCB-1622289424029)(http://121.196.104.224/data/note/img_UML/5.11.png)]

         • UML中，可以通过在类的附加栏中对信号命名来为对象可能接受的、有名的信号进行模型化。
           [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-6qqgBRob-1622289424030)(http://121.196.104.224/data/note/img_UML/5.12.png)]

      2. 调用

         • 一个调用事件表示对象接受到一个操作调用的请求
         • 几点说明
           1. 可以使用在类的定义中的操作定义来规约调用事件。
           2. 该事件或触发状态机中的一个状态转换，或调用目标对象的一个方法。
           3. “信号”是一种异步事件，而“调用”一般是同步事件，但可以把“调用”规约为异步调用。
           4. 在UML中，将一个对象可能接受的调用事件模型化为该对象类的一个操作。
              

      3. 时间事件和变化事件

         1. 时间事件：表示推移一段时间的事件
         2. 变化事件：表示一个条件得到满足或表示状态的一个变化

         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-ZRgMZZjT-1622289424032)(http://121.196.104.224/data/note/img_UML/5.14.png)]

      4. 发送事件和接收事件

         1. 发送事件：表示类的一个实例发送一个调用事件或信号事件。
         2. 接受事件：表示类的一个实例接受一个调用事件或信号事件
         • 注意
           1. 如果是一个同步调用事件，那么发送者和接受者都处在该操作执行期间的一个汇聚点上，即发送者的控制流一直被挂起，直到该操作执行完成;
           2. 如果是一个信号事件，那么发送者和接受者并不汇合，即发送者发送出信号后并不等待接受者的响应。
           • 在以上两种情况下，事件可能被丢失（如果没有定义对该事件的响应的话)，事件的丢失可能触发接受者的状态机（如果有的话)或引起一个常规的方法调用。

   3. 状态转换

      1. 定义

         • 一个状态转换是两个状态之间的一种关系
         • 指明在第一个状态中的一个对象将执行一些确定的动作，当规约的事件发生并规约的条件满足时，进入第二个状态。

      2. 状态转换的规约

         1. 源状态:引发该状态转换的那个状态。
         2. 转换触发器:在源状态中由对象识别的事件，并且一旦满足其监护条件，则使状态发生转换。其中,在同一个简单状态图中，如果触发了多个转换，“点火”的是那个优先级最高的转换;如果这多个转换具有相同的优先级，那么就随机地选择并“点火”一个转换。
         3. 监护(guard)条件:一个布尔表达式，当某个转换触发器接受一个事件时，如果该表达式有值为真，则触发一个转换;若有值为假，则不发生状态转换，并且此时如果没有其它可以被触发的转换，那么该事件就要丢失。
         4. 效应(effect) :一种可执行的行为。例如可作用于对象上的一个动作，或间接地作用于其他对象的动作，但这些对象对那个对象是可见的。
         5. 目标状态:转换完成后所处的那个状态。

         [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Ilv0C6hQ-1622289424032)(http://121.196.104.224/data/note/img_UML/5.15.png)]

      3. 状态转移的表达式及其格式

         • 在UML中，把状态转换表示为从源状态出发、并在目标状态上终止的带箭头的实线。
         • 格式：状态触发器[监护条件]/动作表达式
           1. 转换触发器:描述带参数的事件。
              • 格式为:事件名(由逗号分隔的参数表)
           2. 监护条件:通常是一个布尔表达式，其中可以使用事件参数，也可以使用具有这个状态机的对象之属性和链，甚至可在监护条件处直接指定对象可达的某个状态，例如:in State1或not in State2
           3. 动作表达式:给出触发转换时所执行的动作其中可以使用对象属性、操作和链以及触发事件的参数，或在其范围内的其它特征。

4. 状态图的一般用法

   1. ①建立一个系统动态方面的模型，这些动态方面包括任意种类对象、任意系统结构（类、接口、构件和节点）视角下以事件定序的行为。
   2. ②建立一个场景的模型，其主要途径是针对use case给出相应的状态图。

   • 其中，不论是①还是②，通常都是对反应型对象(reactiveobject）的行为进行建模。

   • 反应型对象，或称为事件驱动的对象，其行为特征是响应其外部语境中所出现的事件,并作出相应的反应。

   • 为反应型对象建立一个状态机模型的步骤如下

     1. 选择状态机的语境，即是类、是用况或是子系统。
     2. 选择其实例（例如类的对象）的初始状态和最终状态,并分别给出初始状态和最终状态的前置条件和后置条件，以便指导以后的建模工作。
     3. 标识某一可用的时间段，考虑该实例在此期间内存在的条件，以此判断该实例的其它状态。对此应以该实例的高层状态开始，继之再考虑这些状态的可能的子状态。
     4. 判断该实例在整个生存周期内所有状态的有意义的偏序。
     5. 判断可以触发状态转换的事件。可以逐一从一个合理定序的状态到另一个状态,来模型化其中的事件。
     6. 为这些状态转移填加动作，或为这些状态填加动作。
     7. 使用子状态、分支、合并和历史状态等，考虑简化状态机的方法。
     8. 检查在某一组合事件下所有状态的可达性。
     9. 检查是否存在死状态，即不存在任何组合事件可以使该实例从这一状态转换到任一其它状态。
     10. 跟踪整个状态机，检查是否符合所期望的事件次序和响应。

   • 应用实例: 创建一个控制器状态机的状态图，其中该控制器负责对一些传感器进行监视。

     1. 当创建这种控制器的一个对象时，由于要做一些初始化工作，因此该对象首先进入“初始化”(intializing)状态;
     2. 一旦完成初始化活动后，则自然进入“休眠”(Idle）状态;
     3. 在休眠状态中，按一定时间间隔，接受传感器的alarm事件(具有参数s，表示相关的传感器)，一旦当接收到一个alarm事件，或接受到用户发送的attention信号，控制就从休眠状态转移到“活化”(Active)状态，或转移到“命合”(Command)状态;
     4. 在活化状态中，仅当发生clearing事件或需要发送attention信号时，分别进入休眠状态或命令状态。

     [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-5ZRdvITf-1622289424033)(http://121.196.104.224/data/note/img_UML/5.16.png)]

UML总结

1. 对“自顶向下”的建模人员来讲

   1. 提供了跨越问题空间到目前“运行平台”之间丰富的建模元素．基于给定的术语，可确定不同的抽象层次，支持“概念建模”和“软件建模”。
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-7XFsYOQY-1622289424034)(http://121.196.104.224/data/note/img_UML/6.1.png)]
   2. 提供了相应的模型表达工具
      [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-XtUlzAOo-1622289424035)(http://121.196.104.224/data/note/img_UML/6.2.png)]
   • 即紧紧围绕“面向对象方法是一种【以对象和对象关系】来创建系统模型的系统化软件开发方法学”，给出表达“对象”、“对象关系”的术语，并给出了表达模型的工具，其主要目的是:支持软件开发人员从不同目的（静态、动态）、针对不同粒度（系统、子系统、类目等），从不同抽象层和从不同视角来创建模型,并建立相应的文档
   • 具体地说
     1. 为了支持抽象系统分析和设计中的事物，UML给出了8个基本术语，即:类、接口、协作、用况、主动类、构件、制品、结点，并给出了这些基本术语的一些变体。每个术语都体现着一定的软件设计原理，例如:
        1. 类体现了数据抽象、过程抽象、局部化以及信息隐蔽等原理
           1. 过程抽象
              • 任何一个完成确定功能的操作序列，其使用者都可把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操作完成的。
              • 过程抽象不是OOA的主要抽象形式，因为OO方法不允许超出对象的界限在全系统范围内进行功能的描述。但过程抽象对于在对象范围内组织对象的操作是有用的。
           2. 数据抽象
              • 根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。
              • 数据抽象是OOA的核心原则。它强调把数据（属性）和操作结合为一个不可分的系统单位（即对象），对象的外部只知道它做什么，而不知道它怎么做。
        2. 用况体现了问题分离、功能抽象等原理
        3. 接口体现了功能抽象等。当使用这些术语创建系统模型时，其语义就映射到相应的模型元素。
     2. 为了表达模型元素之间的关系，UML给出了4个术语,即:关联、泛化、细化和依赖，以及它们的一些变体。可以作为UML模型中的元素,用于表达各种事物之间的基本关系。
        • 这些术语都体现了结构抽象原理，特别是泛化概念的使用，可以有效地进行“一般/特殊”结构的抽象，支持设计的复用。并且为了进一步描述这些模型元素的语义，还给出一些特定的概念和表示，例如给出限定符这一概念，是为了增强关联的语义。
     3. 为了组织以上两类模型元素，UML给出了包这一术语，在实际应用中，可以把包作为控制信息复杂性的机制。
     4. 为了使创建的系统（或系统成分）模型清晰、易懂，UML给出了注解这一术语。

2. 对“自底向上”的设计思想交流来讲
   [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-uKZeb0HM-1622289424035)(http://121.196.104.224/data/note/img_UML/6.3.png)]