UML学习笔记

UML简介

最开始接触EA的时候，发现无论是看帮助文档，还是看网上的教程，基本上是处于懵逼的状态的，完全看不懂，看着看着才突然意识到，不是不懂EA，是不懂UML，导致完全弄不清楚部件、包之类的概念，继而导致对EA的无法理解。因此，计划从UML开始学起，结合软件工程相关经验，和EA一起学。

UML将事物分为结构事物、行为事物、分组事物、注释事物，如下图所示。

光看这些概念难以理解，如果和平时的软件工程要求的软件设计文档对应起来就更容易理解了：

1. 结构事物：类似于软件的需求分析、部件设计、接口设计，是一组静态的活动；
2. 行为事物：类似于软件的行为决策、流程图，是一组动态的活动；
3. 分组事物：关于这块的理解还没有找到一个合适的类比，可能随着后面理解的深入能完善类比；
4. 注释事物：字面意思。

也有些资料把UML的图分为两类，一类是结构图（可以理解为静态图），一类是行为图（可以理解为动态图），如下图所示：

还有些资料将UML分为三类：结构图、行为图和交互图，其实本质上都差不多。

用例图-需求分析

用例（case）图用来描述系统功能，表示一个系统用例与参与者及其关系的图，主要用于需求分析阶段。用例图基本组成元素：参与者、用例、元素之间的关系。

1. 参与者
   1. 可以理解为系统的外部用户或外部事物，其本身不属于系统的一部分；
   2. 在EA中使用图标表示参与者；
   3. 为系统提供输入的人/事、接收系统输出的人/事、需要接入的第三方系统或设备、支持或维护系统的人/事，以及时间触发的某些事件，都可以被认为是参与者。
2. 用例
   1. 用来表明系统与一个或多个参与者之间信息交换的顺序，也可以表明系统执行的动作；
   2. 简单来说，用例就是某一个参与者在系统中做某件事情从开始到结束一系列活动的集合，以及结束时应该返回的可观测、有意义的结果；
   3. 在EA中使用表示用例。
3. 参与者与用例的关系
   1. 一个用例可以隶属于一个或多个参与者，一个参与者也可以参与一个或多个用例；
   2. 泛化关系：在EA中使用表示泛化关系，将特化的用例与一般化的用例联系起来，可以这么理解：泛化关系的箭头指向，其实是一个比较通用的用例，另一端是一个更为具体的用例；
   3. 包含关系：在EA中使用表示包含关系，指一个用例（基用例）可以包含其他用例具有的行为；箭头指向具有行为；
   4. 扩展关系：在EA中使用表示扩展关系，指一个用例对另一个用例（基用例）行为的增强；箭头指向基用例；
   5. 关联关系：在EA中使用表示关联关系，个人感觉是除了上述几种关系，都可以认为是关联关系；如果使用关联关系，可以设置箭头方向；
   6. ？关系：在EA中使用，待完善。

用例图相当于从用户的视角来描述和建模整个系统，其实就是要求设计人员站在用户的角度进行需求分析。用例图被广泛适用于系统的需求建模阶段，并在系统的整个生命周期中被不断细化。

个人理解，这也是为什么很多EA的网上教程，都是从用例图开始讲解的原因。

一个完整的用例模型，不仅仅要包括用例图，还要有完整的用例描述部分，一般来说，包括如下内容：

1. 用例名称：描述用例的意图或实现的目标，一般为动词或动宾短语。
2. 用例编号：用例的唯一标识符，在其他位置可以使用该标识符来引用用例。
3. 参与者：描述用例的参与者，包括主要参与者和其他参与者。
4. 用例描述：对用例的一段简单的概括描述。
5. 触发器：触发用例执行的一个事件。
6. 前置条件：用例执行前系统状态的约束条件。
7. 基本事件流（典型过程）：用例的常规活动序列，包括参与者发起的动作与系统执行的响应活动。
8. 扩展事件流（替代过程）：记录如果典型过程出现异常或变化时的用例行为，即典型过程以外的其他活动步骤。
9. 结论：描述用例何时结束。
10. 后置条件：用例执行后系统状态的约束条件。
11. 补充约束：用例实现时需要考虑的业务规则、实现约束等

 

构件图-软件架构设计、接口设计

构件（Component）图，有的地方也称为组件图，描述了系统中有哪些组件，以及组件提供的、需要的接口、端口及其关系等，用来展示各个组件之间的依赖关系。

网上关于组件图的描述为“是面向对象系统从物理方面建模时用到的图之一，显示一组构件之间的组织和依赖关系”，个人理解其实是基于自顶向下的设计思路，设计出来的软件架构，说白了就是软件设计中的架构设计和接口设计。

使用构件图的思想是复用，主要包含组件、接口、关系、端口和连接器五大要素。

1. 组件
   1. 一个组件可以理解为一个高聚合的软件软件模块；
   2. 分为packaging component和component，具体是啥区别还不是很清楚；
   3. 在EA中使用表示；
2. 接口
   1. 分为提供接口和请求接口，提供接口为该组件实现的接口，请求接口为该组件需要使用到的其他组件的接口
   2. 接口在EA中使用表示
3. 端口
   1. 端口描述了在构件与它的环境之间以及在构件与其内部构件之间的一个显示的交互点；
   2. 个人对于端口理解有点类似于UDP的port，一个port可以传输多种类型的消息，UML中的一个端口可以包含多个接口；
   3. 在EA中使用表示端口；
   4. 个人认为在实际使用中，只要不影响理解，可以不对端口和接口做严格区分
4. 关系-需要再阅读一些资料进一步了解
   1. EA中组件的关系为5种
   2. 依赖关系：在EA中使用表示依赖关系，

部署图-软件部署设计

 

部署（deployment）图用于显示系统中软件和硬件的物理架构。从部署图中可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。一般在完成软件架构设计后，用部署图画出软、硬件之间的物理拓扑结构，说明系统的使用部署、环境等情况。

部署图由节点和关系两部分组成，也可以包含构件，构建必须在某个节点上。

1. 节点
   1. 这里的节点表示计算资源的通用名称，具体包括结点、设备、执行环境；
   2. 结点在EA中使用表示；
   3. 设备在EA中使用表示；
   4. 执行环境在EA中使用进行表示；
   5. 个人理解：结点类似于计算机、服务器之类的，设备更倾向于嵌入式的硬件环境，执行环境类似于交换机、路由器之类的用于辅助结点、设备连接的节点。
2. 关系
   1. 关联关系
   2. Communication path
   3. 关联类
   4. 泛化关系
   5. 实现
   6. Deployment
   7. Manifest

 组合结构图-软件详细设

组合结构（composite structure）一个“组件”的内部结构，以及他们之间的关系，个人理解为对构件图中“组件”的细化。 

 序列图-软件执行方案/运行流程

序列(sequence)图描述了在用例特定场景中，对象如何与其他对象交互。其实就相当于软件设计说明中的执行方案。

时序图会涉及角色、对象、生命线、控制焦点、元素

有的材料上面称序列图为时序图，个人感觉不太严谨，因为UML有专门的时序（timing）图。 

 活动图-流程图

活动图描述了具体业务用例的实现流程。个人理解就是流程图。

 状态机图-状态控制设计

 描述了对象在它的整个生命周期里，响应不同事件时，执行相关事件的顺序。对于一个控制软件来说，需要专门设计状态机，对应在UML里面就是状态机图。

了解了上述几种图，基本上可以使用EA完成一个软件的设计了，EA的建模流程其实与上述图的介绍流程基本一致。

EA只是一个建模的工具，在UML方面，如visio2016也继承了UML相关的内容，可以直接使用visio画UML图。当然从功能的角度来说，EA肯定比visio更为强大，

从一个嵌入式软件，尤其是控制类软件研发人员的角度来说，重点需要掌握好用例图、构件图、部署图、组合结构图、序列图、活动图、状态机图。

本次学习的部分非常浅显，后续有机会深入学习的时候再进行补充。