软考UML
UML
考点归纳
1、类图
类与类之间的关系（依赖,泛化,关联,聚合,组合,实现）及各关系的图形表示法重点、类与类之间的多重度重点
2、用例图
用例图的元素、参与者的确定、用例间的关系（包含、扩展、泛化）、用例的确定
3、顺序图
确定图中的对象、消息名及对象间消息传递的时间顺序
4、活动图
确定图中的各结点的名称及相互关系
5、状态图
确定图中的状态及各状态之间的变换条件
参考：https://blog.csdn.net/dkingyaoyao/article/details/97237290
一、UML概述
UML又称统一建模语言或标准建模语言，是一个支持模型化和软件系统开发的图形化语言，它的作用域不仅支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
建模的意义： 模型是对现实的简化，建模是为了更好地理解系统。
- 模型帮助我们按照实际情况或需求对系统可视化；(掌握不了 文字，画幅画代替) ；
- 模型允许我们详细说明系统的结构、行为；
- 模型给出了一个构造系统的模板；
- 模型对我们作出的决策进行文档化。（先有文档，再有代码）
UML的特点：
- 统一的标准，已经被OMG接受为标准建模语言
- 面向对象，支持面向对象开发
- 可视化，表示能力强
- 独立于开发过程，可以适用于不同软件过程
- 概念明确，表示简洁，结构清晰，容易学习掌握
二、用例图（use case diagram）
描述一组用例、参与者（一种特殊的类）及它们之间的关系。用例模型描述的是外部执行者所理解的系统功能，用于需要分析阶段。
1、用例之间的关系
- (1)包含（include）（是一种依赖关系，加了版型<>）
- 两个以上用例有共同功能，可分解到单独用例，形成包含依赖；
- 箭头方向由基本用例指向被包含用例；
- 执行基本用例时，每次都必须调用被包含的用例（吃饭前洗 手）；
- 被包含用例也可以单独执行
- (2)扩展（extend）（是一种依赖关系，加了版型<>）
- 如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。
- 如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种事情，则可以断定将这个用例分为一个主用例和一个或多个辅用例进行描述可能更加清晰。
2、构建用例模型需要经历三个阶段
识别参与者
合并需求获得用例
细化用例描述
(1)识别参与者(actor)
- 参与者是系统之外与系统进行交互的任何事物，参与者可以是使用系统的用户，可以是其他外部系统、外部设备等外部实体。
- 在UML中采用小人符号来表示参与者。
- 参与者有主要参与者和次要参与者，开发用例的重点是要找到主要参与者。
(2)合并需求获得用例
将参与者都找到之后，接下来就是仔细地检查参与者，为每 一个参与者确定用例。
其中的依据主要来源于已经取得的特征表。首先，将特征分配给相应的参与者，然后进行合并操作，最后绘制成用例图。 要注意区分业务用例和系统用例。
- 业务用例：是描述这个业务的具体工作流的；一次涉众与实现 业务目标的业务之间的交互。业务用例着重于业务操作。
- 系统用例：系统用例的设计范围就是这个计算机系统设计的范 围。它是一个系统参与者，与计算机系统一起实现一个目标。 系统用例着重于要设计的软件系统。
(3)细化用例描述
用例建模的主要工作是书写用例规约（use case specification）， 而不是画图。用例模板为一个给定项目的所有人员定义了用例规 约的结果，其内容至少包括用例名、参与者、目标、前置条件、 事件流（基本事件流、扩展事件流）、后置条件等，其他的还可 以包括非功能需求、用例优先级等。
三、类图（Class Diagram）
描述一组类、接口、协作以及它们之间关系的图，用来显示系统中各个类的静态结构图。
(1)依赖（ dependency）
- 依赖关系是一种使用关系，特定事物的改变有可能会影响到使用该事物的其他事物。大多数情况下，依赖关系体现在某个类 的方法使用另一个类的对象作为参数。
- 在UML中，依赖关系用带箭头的虚线表示，由依赖的一方指向被依赖的一方。
(2)泛化（generalization）
- 一般元素和特殊元素之间的关系。
- 泛化关系是继承关系的反关系，子类从父类中继承，父类是子类的泛化。
(3)关联（accociation）
- 表示两个类之间存在某种语义上的联系。一个人为一家公司工作，一家公司有许多办公室。
- 关联关系是所有关系中语义最弱的。
- 可以分为聚合关系、组合关系。
a . 聚合关系
关联关系的一种特例，是强的关联关系。聚合表示类之间的关系是整体与部分的关系，但整体与部分之间是可分离的，他们可以具有各自的生命周期。
在UML中，使用
表示聚合关系，空心菱形指向的是代 表“整体”的类。
b . 组合关系
也是关联关系的一种特例，这种关系比聚合更强，也称为强聚合； 他同样体现整体与部分间的关系，但此时整体与部分是不可分的， 整体的生命周期结束也就意味着部分的生命周期结束。 在UML中，使用带有实心菱形的实线
表示组合关系。
(4)实现（realization）
- 一个元素完成另外一个元素的操作功能，则二者构成实现关系。
- 如接口类及其实现；接口是操作的集合，只声明了操作方法 （没有实现该方法），而由实现类具体定义实现部分。
四、对象图(Object Diagram)
描述的是参与交互的各个对象在交互过程中某一时刻的状态。对象图可以被看作是类图在某一时刻的实例。
在UML中，对象图使用的是与UML类图相同的符号和关系，因为对象就是类的实例。
五、状态图（state chart diagram）
- 状态图用来描述一个特定对象的所有可能状态及引起状态转移的事件。
- 它由状态、转移、事件和活动组成。
- 状态图给出了对象的动态视图
六、活动图（activity diagram）
将进程或其他计算的结构展示为计算内部一步步的控制流和 数据流。活动图专注于系统的动态视图。
- 活动图侧重从行为的动作来描述
- 状态图侧重从行为的结果来描述
七、顺序图（sequence diagram）
是一种交互图（interaction diagram），交互图展现了一种交互，它由一组对象或角色以及它们之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的 时间次序的交互图。
八、协作图（通信图，UML2.0后的名称）
是一种交互图，强调的是发送和接收消息的对象之间的组织结构。一个协作图显示了一系列的对象和在这些对象之间的 联系以及对象间发送和接收的消息。
九、构件图（component diagram）
- 构件图是用来表示系统中构件与构件之间，类或接口与构件之间的关系图。由源代码文件、二进制代码文件、可执行文件或动态链接库 (DLL) 等构件构成，并通过依赖关系相 连接。
- 构件图用于表示系统的静态设计实现视图。
- 是物理方面进行建模的两种图之一。
十、、部署图（deployment diagram）
- 用来显示系统中软件和硬件的物理架构。
- 从部署图中，可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。
- 是物理方面进行建模的两种图之一。
模型图分为二大类：
- 静态模型（系统结构） 用例图、类图、对象图、构件图、部署图
- 动态模型（系统行为） 状态图、活动图、顺序图、协作图
例：UML图中，对新开发系统的需求进行建模，规划开发什 么功能或测试用例，采用（ C ）最合适。而展示交付系统 的软件组件和硬件之间的关系的图是（ B ）。
A. 类图 B. 对象图 C. 用例图 D.交互图
A. 类图 B. 部署图 C. 组件图 D.网络图
