UML中涉及的概念及定义（复习向）

UML中涉及的概念及定义

Lecture 01

• 建模：把不太理解的东西和一些已经较为理解、且十分类似的东西做比较，可以对这些不太理解的东西产生更深刻的理解。目的是沟通、理解系统
• 模型：建模产生的结果，就是模型。模型是对事物的一种抽象、简化。
• 视图（view）：是从某个方面得到的模型 （A view depicts selected aspects of a model.）
• 符号（notation /symbol）：是一些图形和文本规则用来表示视图 （A notation is a set of graphical or textual rules for representing views.）
• 为什么要建模？
  • 建模是为了成功开发复杂的软件项目。
  • 建模的四个目的：
    1. 帮助我们按照需要对系统进行可视化。（visualize）
    2. 允许我们详细说明系统的结构和行为。（specify the structure or behavior of a system）
    3. 给出了一个指导我们构造系统的模板。（a template that guides us in constructing a system）
    4. 对我们所做出的决策进行文档化。（document）
• 建模的四项基本原理
  1. 选择要创建什么模型
  2. 每一种模型可以在不同的精度级别上表示
  3. 最好的模型是与现实相关联的
  4. 单个模型是不充分的, 对每一个重要的系统最好用一组几乎独立的模型去处理

Lecture 02

• UML：Unified Modelling Language （统一建模语言）适用于软件开发全生命周期的各个阶段无关乎具体的实现平台。

• 正向工程/****

  • 正向工程：模型转换为代码
  • ****：代码转化为模型

• UML概念模型

• UML能为我们做什么

  1. 可以做软件需求分析
  2. 可以做软件开发设计
  3. 可以做系统部署设计
  4. 也适用非软件领域的系统建模（主要用于软件密集型系统。）

• “4+1”视图
  

• 对象（object）：拥有数据和行为的一个实体。

• 类（class）：共享相同属性、操作、方法、关系或者行为的一组对象的描述符。

• 继承（inheritance）：一个类获取另一个类的状态和行为，并添加其他状态和行为。

• 多态（polymorphism）：“有多种形式”，可以通过重载（overloading）和重写（overriding）实现。

  • 重写：在子类中重新定义父类的函数。
  • 重载：在同一个类中，出现多个同名的方法（签名不同）。

• 封装（encapsulation）：隐藏对象的实现细节的过程。通信是通过一个“接口”来实现的。

• 接口（interface）：描述类的使用者如何与类交互。

• 抽象（abstract）：为用户提供尽可能少的界面。（有更高的重用性）

Lecture 03 用例模型

• 关系：事物与事物之间不能孤立存在，一个事物总是和另外一个或多个事物之间存在某种联系。
  • 关联关系：两个事物之间是一种组织、结构关系，持续时间是稳定的。（师生）【实线+无箭头】
  • 依赖关系：两个事物之间的关系是短暂的、一方依赖另一方；箭头指向被依赖的一方。（画家与蝴蝶????）【虚线+杈箭头】
  • 继承关系（泛化关系）：一般事物与特殊事物之间的关系。（动物和猫）【实现+空心箭头】
  • 实现关系：接口与具体实现事物之间的关系（插座与发电厂）。【虚线+空心箭头】
• 公共机制
  • 详述：即规格说明、规约（specifications），主要以文字描述为主。
  • 修饰：基本符号之上，再增加的细节，以便表达得更完美。
  • 通用划分：相关概念之间的区分，（类、对象）（接口、实现）。
  • 扩展机制：
    • 构造型
    • 标记值
    • 约束

用例模型

• 用例视图 （usecase view) ：支持对产品外部功能的建模。从软件产品的使用者的角度来描述用户对将要开发的产品的需求。
• 系统边界：立足于当前要解决的问题领域，系统边界描述了系统内部与外部之间交互的集合。随着所处的视点（view）不同而变化。
• 参与者（actor）：代表位于系统之外并和系统进行交互的一类事物（人、物、其他软件子系统等）
  • 软件系统的使用者
  • 直接和软件系统交互的软件系统赖以运行的软/硬件：如操作系统
  • 与软件系统有信息交换的计算机外部设备
• 用例：系统为响应参与者引发的一个事件而执行的一系列的处理/动作，而这些处理应该为参与者产生一种有价值的结果。
• 用例图中的关系：
  • 参与者与用例：关联关系
  • 参与者与参与者：泛化关系
  • 用例与用例：
    • 泛化关系
    • 包含关系《includes》：子用例是一个常用功能块，可以用在多个基用例中，而且基用例必须包含了子用例，基用例才能正常进行。
    • 扩展关系《extended》：子用例是独立的用例，完成一定的功能。基用例在一定条件下，可以引入子用例。

Lecture 05 类与关系

• 类：具有相同属性（或者数据、信息、状态）、相同行为（或者方法、操作）的一组对象的描述符。是真实世界事物的抽象。

  对系统建模时，业务系统中的事物构成了整个业务系统。在UML中，把所有的这些事物都建模为类

• 对象：当这些事物存在于真实世界中时，它们是类的实例，并被称为对象（或者，问题领域的对象）。

• 同一个类的所有对象具有

  • 相同的属性，但属性的取值可以不同
  • 提供相同的操作、有相同的语义

• 类不是孤立存在的，对应的对象将参与一个或多个交互。

• 类的图形表示

  • 长方形，分为四个分隔区，表示四个不同部分
    • 名称naming（类名中的每个词的第一个字母通常要大写）
    • 属性attribute ：描述了类在软件系统中代表的事物所具备的特性。必须为每个属性指定数据类型。
      • 属性的可见性
        • public：+
        • private：-
        • protected：#
        • implementation：~
      • 命名格式：除第一个单词之外的每个单词的第一个字母要大写
    • 操作operation：操一个类所能提供的服务的实现，或者对一个对象所做事情的抽象，并且由这个类的所有对象共享。
      • 图形表示
        • 操作分隔区是可隐藏的
        • 如果操作分隔区未被隐藏 则操作的名字必须列出
        • 名字的后面必须有一对括弧以表示此名字是操作名称
      • 类的操作可以分为两类
        • 操作的结果引起了对象状态的改变，状态的改变也包括相应的动态行为的发生
        • 为服务的请求者提供返回值
    • 责职responsibility：是类的合约或责任（是一个类所承担的义务或协议 ）
      • 一个良好定义的类应该有清晰的职责
      • 一个类只应承担一种职责（$\neq$​=只有一个操作）
  • 在显示时，只有名称是必须的，其余部分均可以隐藏

• 类之间的关系

  • 依赖关系：一种使用关系，说明一个事物使用另一个事物的信息和服务。本身可以有一个名字。
  • 泛化关系：是一般事物（称为超类或父类）和该事物的较为特殊的种类（称为子类）之间的关系。是一种继承关系。
  • 关联关系：是一种结构关系，指明一个事物的对象与另一个事物的对象间的联系。
    • 自身关联 reflexive association
    • 关联关系的修饰：
      • 名称
      • 角色
      • 多重性
      • 聚合/组合：表示部分与整体的关联关系
        • 聚合： “整体”有管理“部分”的特有的职责。【实线+空心菱形】，空菱形与“整体”类相连接。
        • 组合：“整体”拥有“部分”的生命；【实线+实心菱形】，实菱形与“整体”类相连接。
      • 导航性

• 关联类：关联类也是一个类，由类、关联和虚线组成。（（类似于ER图里的关系

• 连接link：关联或关联角色的实例，与对象相关。（而关联与类相关。）即连接是关联的实例。

Lecture 06 公共机制

• 公共机制：是UML中适用于各种建模元素的公共建模方法。在基本建模元素图符的基础上，增加新的标识以表达更多的设计思想。

  • 修饰 adornments
    • 注释（Note）
      • 图形化表示 ：一个折角矩形。注解和被注解的建模元素之间用虚线连接。
      • 一个注解可以为多个建模元素作注解
      • 可以作用于任何UML建模元素（如：类、对象、关系、消息等）
      • 对被注解的建模元素没有任何语义上的影响
      • 它只起到增强模型的可读性的作用，UML对注解的内容不作任何限制
    • 可见性、角色、多重性等，常见于（但不限于）关联中的说明
  • 扩充机制 extensibility mechanisms
    • 构造型（衍型，stereotype)：类似于已有的UML建模元素，但又是对特定的问题领域具有特殊含义的新的建模元素。 （例如：《xxx》）
      • 记名的构造型（named stereotype）
        • 保留了原建模元素的图形表示, 而用构造型名来修饰原建模元素的名字, 以使构造型在图形化表示上区别于原建模元素
        • 名字：可以从UML建议名单中选取、也可以新增加
      • 构造型的图标形式（stereotyped element as icon）
      • 带有图标的记名构造型
    • 标记值 （tagged value）：如果在建模的过程中，出于某种原因需要增加一个新的构成以表达建模元素的某种特性，就可以使用标记值。
      • 标记值的字符串由标记值的名字、取值、及分隔符组成。（例如：tag=value）
      • 标记值的放置没有限制：
        • 标记值字符串用花括弧括({})起来,放置到原建模元素的名字的下方
        • n放置到一个注解内
    • 约束（constraint）：在UML里，约束用来扩充UML建模元素的语义，以便增加新的规则或修改已有的规则。
      • 例如：双向的关联关系及其角色名和多重性描述了类之间的对应关系。
      • 图形化表示：
        • 在UML里，约束被图形化为一个文本串。
        • 此文本串被括在一对花括号内，并被放置在被约束的建模元素。
      • 约束可以附加在表元素、依赖关系，或注释上。
  • 规格说明 specifications
  • 公用划分 common divisions
  • 类和对象的划分、接口和实现的划分
  • 类型和角色的划分(略)

• 类的扩充机制

  • 控制类：代表一类控制或启动交互的对象。 它的行为通常都是针对于一个特定的应用场景中，对象的协同、控制
  • 边界类：代表处于系统边界上，不但和系统内部对象交互，而且又和系统外部的系统参与者交互的一类对象。
  • 实体类：一类被动的对象，它本身不会启动交互，可以参加多个用例的交互，并且存活于任何单独的交互之外。

• 图的分类

  • 结构图：用于观察系统静态部分的图
    • 类图：显示了一组类、接口和协作及其关系。
    • 对象图：显示一组对象及其关系。
    • 构件图：实现组件的内部部件、连接器和端口。当组件被实例化时，它的内部的副本也被实例化。
    • 部署图：显示一组节点及其关系。
    • 组合结构图：显示了类或协作的内部结构。
    • 制品图：显示了一组工件及其与其他工件以及与它们实现的类的关系。
  • 行为图：用于观察系统动态部分的图
    • 用例图：显示了一组用例和参与者(一种特殊的类)及其关系。
    • 顺序图：强调消息的时间顺序的交互图。
    • 通信图（协作图）：是一种交互图，强调发送和接收消息的对象的结构组织。
    • 状态图：显示状态机，由状态、转换、事件和活动组成。
    • 活动图：显示计算中逐步执行的流程。

Lecture 08 交互图

• 实例：抽象概念的具体存在。任何一个实例都可以与一个或多个抽象概念相对应。（许墨是bs骨干也是脑科学教授！）

• 实例Instances和对象objects在很大程度上是可以互换的。

  • 类的实例：一般称为对象。（对象图、状态图，交互图）
  • 用例实例：也称为协作、场景scenario
  • 节点的实例：（部署图）
  • 关联的实例：连接

• 实例的命名：[名称] ：[类型]。实例的类型必须是具体的类目（classfier）（或类）。

  • 具名实例： c1:ClassA
  • 孤体实例（orphan objects ）
    • 省略类型名的对象，如myCustomer 或者c1
  • 匿名实例：只有类型名， 如，:ClassA

• 实例的图形表示

  • 采用和它们的类目相同的图形符号。
  • 不同的是在其名称加有下划线 以及（或者）冒号。

• 交互：对象之间为实现某一功能，必须实施的协作过程、动态行为。

• 交互的建模元素

  • 对象
  • 参与者
  • 消息

• 消息：一个对象以某种方式启动另一个对象的活动

• 消息的形式

  • 调用(call)：启动某个对象的操作。
    • 操作是对象所实现的服务。
    • 对象也可以给自己发送消息。
  • 返回(return)：操作向调用者返回一个值。
  • 发送(send)：向一个对象发送一个信息（同步/异步）。
  • 创建(create)：此消息的发送导致目标对象被创建。
  • 销毁(destroy)：此消息的发送导致目标对象被销毁。

• 对象和角色

  • 参与交互的对象既可以是具体的事物（许墨），又可以是原型化的事物（男主）。

• 交互图：描述了一个交互, 其中包括了一系列的对象及其关系以及通过这些关系在对象之间传递的消息。

• 交互图分为两种：顺序图、通信图。它们在语义上是等价的，可以相互转换。

• 顺序图的构成

  • 参加交互的各对象、参与者、消息
  • 对象生存线：每个对象的底部中心都绘有一个垂直虚线
  • 控制焦点：对象生存线上的“长条矩形”，表示这段时间对象在进行操作。

• 控制焦点：代表一个对象直接地或通过一个子过程间接地执行一个动作的那段时间。

• 结构化控制（又名：Frame、 Fragment），类型如下：

  • 可选执行 （标签: opt)
  • 条件执行 （标签:alt)
  • 并行执行 （标签:par)
  • 循环（迭代）执行 （标签:loop)

• 通信图的构成：

  • 对象
  • 连接
  • 在此连接上传递的消息

Lecture 09 活动图

• 活动图：描述了在一个过程中，顺序的/并行的活动及其之间的关系。
• 活动与动作
  • 一个活动是 一个业务过程中进行的、非原子的执行单元。
  • 活动的执行最终延伸为一些独立动作（Action）的执行，动作是原子的。
  • 每个动作将导致系统状态的改变或消息传送。
• 活动图包括
  • 活动节点：是活动的组织单元，用一个【两头为圆形的方框】来表示。
    • 可以有一个名字
    • 可以是一种伪代码描述
    • 放大一个活动节点，可以看到另一个活动图
    • 活动节点会持续一段时间来完成
  • 动作：一个特别的活动节点，它不能被细分。（在图形表示上，活动节点和动作没有区别。）
  • 流
  • 对象值
  • 注解和约束
• 分支：用一个菱形来表示分支
  • 一个分支可以有一个进入流和多个离去流。
  • 在每个离去流上必须设置一个监护条件。
  • 两个控制路径可以重新合并，无需监护条件。—>合并节点
• 分岔和汇合 （同步棒）
  • 分岔：把一个单独的控制流分成两个或多个并发的控制流。
  • 汇合：两个或多个并发控制流的同步发生，一个汇合可以有两个或多个进入转移和一个输出转移。
• 泳道 Swimlanes ：将一个活动图中的活动分组，每一组表示某个业务组织负责的活动集。每个组被称为一个泳道。
  • 每个活动严格地属于一个泳道
    • 转移可以跨越泳道
    • 同步棒可以跨越泳道

Lecture 10 状态图

• 状态：是对象的生命期中的一个条件或状况。在此期间，对象可以响应事件、执行某活动等。

• 状态机：是一种行为，说明对象在它的生命期中, 响应事件所经历的状态序列 以及它们对每个事件的响应。

  • 简单、独立的行为，或当前的行为并不依赖它们的过去时，不需要用一个状态机建模。

• 状态图：显示了一个状态机，它强调从状态到状态的控制流。

• 状态依赖：对象的当前行为依赖于过去，或者它的行为必须响应异步消息。

• 状态的组成部分

  • 名称（name）：每个单词首字母大写
  • 进入/退出动作(entry/exit action)
  • 内部迁移（internal transition）
  • 子状态 (substate)
  • 延迟事件 (deferred event)

• 事件：是对一个在时间和空间上占有一定位置的、有意义的事情的描述。

• 事件与状态：在状态机的语境中，一个事件是一个激励的发生，它能够触发一个状态迁移。

• 迁移：在状态A，发生事件并满足一定条件，转到状态B。

• 迁移的组成部分：

  • 源状态 source state
  • 事件触发器 event trigger （触发事件名称）
  • 触发条件 guard condition
  • 效应（effect) （或称，迁移动作）
  • 目标状态

• 特殊的迁移

  • 自身迁移 self transition：从状态A迁移到状态A
  • 内部迁移 internal transition：在状态A内部的行为（不执行进入/退出动作）

• 活动 Activity：占用有限时间，并且可以中断的工作。只在一个状态内部出现。

• 动作 Action：瞬时完成，并且不可以中断的工作。

  • 出现在一个状态的内部，与内部迁移相关联。
  • 出现在一个状态的外部，与外部迁移相关联。

• 状态的图形

  • 一般状态：【圆角矩形】
  • 初始状态：实心圆⚫️
  • 结束状态：“牛眼”

• 事件：触发事件名 [ 触发条件 ]/ 迁移动作

  • 这三个部分都是可以省略的，但至少要有一部分。

• 迁移：【叉形箭头实线】，从初始状态指向目标状态。

• 状态图建模注意事项：

  • 不允许孤立的状态存在
  • 不允许只进不出的状态迁移 (“黑洞”)
  • 不允许只出不进的状态迁移 (“奇迹”)
  • 不允许没有事件发生的迁移，或者“迁移” 没有指明具体的事件。

• 	建模对象	动态/静态行为建模
  交互图	共同工作的对象群体的行为	动态
  状态机	单个对象的行为	动态

• 子状态机：

  • 非正交子（顺序）状态：转态不相交，一次只能处于一个子系统。（如游泳和开车）
  • 正交（并发）子状态：在一个语境中，并发地执行两个或多个状态机。（如看书和等人）
  • 分岔：从一个外部状态直接迁移到一个或多个正交状态

Lecture 12 高级类

• 类目：是一种描述行为特征(以操作的形式）和结构特征（以属性的形式）的模型元素, 是UML中更一般的构造块。
• 类目的种类包括：类（最重要）、关联、接口、数据类型、信号、构件、节点、子系统、以及用例
• 类目的简单特征：属性和操作。
• 类目的高级特征：可见性、作用域、多重性、多态性、模版类、标准类等
• ⚠️UML中有一些事物没有实例，如包和泛化关系，就不属于类目。
• 作用域共有两种，即实例作用域和类作用域：
  • 实例作用域(instance)（有时称为 对象作用域）：对于一个特征（feature），类目的每个实例均有它自己的值。
  • 类目作用域(static)：对于类目的所有实例，特征的取值是唯一的。
• 抽象类：没有直接实例的类，是抽象类（一般是基类）。【用斜体字拼写】
• 具体类(concrete class) ：可以被直接实例化的类。
• 叶子类(leaf class)是没有任何导出类的类
  • 图形表示：把{leaf}用花括弧扩起来，放置在类名的下方，表示对类的约束。
• 根类(root)是没有任何基类的类
  • 图形表示： 把关键字{root}, 放置在类名的下方，表示对类的约束。
• 类多重性（multiplicity）：对类的可同时存在的对象的数目加以限制，称为类的多重性。
  • 多重性描述的是一个数目范围，数目范围用一个表达式描述。

Lecture 13 接口 包

• 构件 component：系统的一个物理的可替换的部分，它遵从一组接口的要求，并提供对这些接口的实现。由类、子构件组成的，能够完成相对独立的子功能。
• 接口 interface：为类或构件设定一个外部行为特性的规范，对类或构件的修改不改变这个行为规范，就可以保证其它与之关联的部分、乃至整个系统能正常工作。这样的规范，在UML里被称为 接口(interface) 。
  • 接口为构件指定外部行为特征，从而能够实现软件系统的构件化，即，遵循同一个接口的构件可以互相替换。
• 接口：是一系列操作的集合，它指定了一个类或者一个构件所能提供的服务。接口只能拥有操作，不能拥有属性。
• 供接口（provided interface)：类或构件承诺提供的一组服务。
  重性描述的是一个数目范围，数目范围用一个表达式描述。

Lecture 13 接口 包

• 构件 component：系统的一个物理的可替换的部分，它遵从一组接口的要求，并提供对这些接口的实现。由类、子构件组成的，能够完成相对独立的子功能。
• 接口 interface：为类或构件设定一个外部行为特性的规范，对类或构件的修改不改变这个行为规范，就可以保证其它与之关联的部分、乃至整个系统能正常工作。这样的规范，在UML里被称为 接口(interface) 。
  • 接口为构件指定外部行为特征，从而能够实现软件系统的构件化，即，遵循同一个接口的构件可以互相替换。
• 接口：是一系列操作的集合，它指定了一个类或者一个构件所能提供的服务。接口只能拥有操作，不能拥有属性。
• 供接口（provided interface)：类或构件承诺提供的一组服务。
• 需接口（required interface）：类或构件所需要的来自其他类的服务集合。