UML期末考试重点
1. 面向对象技术的相关原则：抽象、封装、分解、泛化、多态、分层、复用
2. UML的内涵：
UML — Unified Modeling Language
不是一种程序设计语言，而是一种可视化的建模语言(用于分析设计)
不是工具或知识库的规格说明，而是一种建模语言规格说明，是一种模型表示的标准
不是过程，也不是方法，但允许任何一种过程和方法使用它
3. 构造块(building blocks)：
3.1事物(things)
结构、行为、分组、注释
3.2关系(relationships)
依赖、关联、泛化、实现
（1） 依赖是两个事物间的弱语义关系， 表明两个事物之间存在着一种使用关系， 其中
一个事物（独立事物）发生变化会影响另一个事物（依赖事物）的语义。
（2） 关联是一种强语义联系的结构关系，表明两个事物之间存在着明确的、稳定的语
义联系。
（3） 泛化是一种特殊/一般关系，特殊元素（子元素）的对象可替代一般元素（父元素）
的对象。
（4） 实现是两个事物是之间的一种契约关系，其中的一个事物（箭头指向的事物）描
述了另一个事物必须实现的契约。
3.2图(diagram)
静态(7种)：类图、对象图、构件图、部署图、包图、组合结构图、外廓图
动态(7种)：顺序图、通信图、时间图、交互纵览图、活动图、状态机图、用例图
4. UML概念图：
5. 4+1视图：
用例视图（是被称为参与者的外部用户所能观察到的系统功能的模型图）-面向用户
逻辑视图：面向系统分析 和设计人员
进程视图：面向系统集成人员
实现视图：又叫开发视图，面向编码人员
部署视图：又叫物理视图，面向系统工程师
6. 14种图名字：
7. UML 语法结构采用 UML 元模型来定义；
主要是采用 UML 类图描述各元素的抽象语法，采用约束机制和自然语言（文本）
来描述模型语义
8. UML 的语义结构主要包括：结构语义和行为语义
9. 信息技术具有变革性
10. 活动图（Activity Diagram）:一种行为模型，描述活动或动作之间的流程，强调行为的执行序列和条件
11. 业务模型--》系统模型：
业务用例 系统(子系统)
业务参与者 系统参与者
业务工人 系统参与者
业务工人的操作(活动) 系统用例
业务实体 实体类
12. UML分析设计的阶段：
（ 1） 业务建模：采用软件建模方法分析和理解带开发的业务，描述业务流程；其目标
是认识业务本质，该业务本质是后续用例建模的基础。
（ 2）用例建模： 采用 UML 用例建模技术描述软件需求， 该需求模型将为后续用例分
析提供输入。
（ 3）用例分析： 采用 UML 用例分析技术分析软件需求，建立软件系统的分析模型。
（ 4）架构设计： 在系统的全局范围内，以分析模型为基础，设计系统的架构。
（ 5）构件设计： 根据架构设计的成果，将分析模型细化，设计系统构件的实现细节
（ 6）代码实现： 将系统构件映射到目标语言上。
13. 活动图中的动作节点什么条件下可以执行，有哪些种类的动作节点？
（ 1） 当动作结点所有的对象流和控制流的前提条件都满足时，才创建动作的一次执行。
（ 2） 根据动作执行所涉及的功能不同，可以划分为不同类别的动作，包括基本功能、
行为调用、通信动作和对象处理等不同类型的动作节点
14. 什么是活动分区，一般什么情况下对活动进行分区？
（1） 活动分区用于识别具有相同特性的一组动作，这些动作被放入相同的区间。
（2） 可以使用不同的分区规则进行分区，并没有严格的规范。
（3） 在业务模型或需求中，往往按照组织机构的单位或系统角色进行分区，一个单位
或角色负责分区中所有节点的行为。而在设计模型中，可以按照不同的类（或构件）进行分
区，一个类（或构件）负责执行该分区中所有节点的行为
15. 业务模式建模当前业务现状，而系统模型则描述系统中业务实现模式。业务模型还可以为系统模型提供输入。
16. 远景包含了对待开发系统的目标和约束，代表了项目涉及的所有人之间达成的第一个共识，是项目核心需求的概览。
特点：SMART
具体的（Specific）
可测量的（Measurable）
可实现的（Achievable）
相关的（Relevant）
基于时间的（Time-based）
17. 用例中的三种关系：包含、扩展、泛化
包含：主用例依赖子用例，子用例相对独立
扩展：子用例依赖主用例，主用例相对独立
18 .什么是用例的前置条件和后置条件，它们有什么作用，定义时需要注意什么？
前置条件是指用例在执行之前必须满足的条件，它约束用例开始执行前系统的状态。作
为用例的入口限制， 前置条件阻止参与者触发该用例直到满足所有条件。
后置条件是指用例执行完成之后系统的状态。当用例存在多个事件流时，可能会对应多
个不同的后置条件。利用后置条件，有助于确保涉众理解执行用例后的结果。
在定义前置条件和后置条件时需要注意，只有在用例的使用者将这些条件视为附加价值
的时候才使用，而且它们均要求是系统可以感知的（或者说检测到的）；此外，前置条件还
要求是在用例执行前就可以感知的
19. 什么是涉众，涉众和参与者有何区别和联系？
用例的涉众是指受用例所代表的业务影响的（或者说与当前用例有利益关系的）系统内
外部人员或组织。由普通的人或部门来承担的参与者一般都是涉众。外部系统、时间等不是
涉众，因为它们不是人或者组织，没有利益影响；不过当有外系统参与者时，那些外系统的
用户往往会作为当前用例的涉众存在
从涉众的角度来看，用例实际上是涉众之间所达成的契约， 并以参与者为达成特定目标
和系统交互的方式演绎。把用例比作一台戏，参与者和系统就是这台戏的演员，而涉众则是
观众，戏的好坏由观众来评价
20. 什么是系统参与者，识别参与者的主要要点包括哪些？
系统参与者代表了以某种方式与系统交互的人或事。更直观的说， 参与者是指在系统之
外，透过系统边界与系统进行有意义交互的任何事物。识别参与者的主要要点包括：
（1） 系统外：参与者不是系统的组成部分，处于系统的外部；
（2） 系统边界：参与者透过边界直接与系统交互，参与者的确定代表系统边界的确定；
（3） 系统角色：参与者是一个参与系统交互的角色，与使用系统的人和职务没有关系；
（4）与系统交互：参与者与系统交互的过程是系统所需要处理的，即系统职责；
（5） 任何事物：参与者通常是一个使用系统的人，但有时候也可以是一个外系统或外
部因素、时间等外部事物。
21. 用例文档模板结构：
用例名、简要描述
参与者与涉众
相关用例
前置条件、后置条件
事件流
基本路径
备选路径
补充约束
字段列表、业务规则
非功能需求、设计约束
待解决问题
相关图(用例图、活动图、类图)
22. 分析模型主要包括什么内容？
分析模型是对分析所形成目标制品的总称；具体来说，分析模型包含两个层次的两类模
型。两个层次是指架构分析和用例分析。两类模型是指静态模型和动态模型。
23. 什么是关键抽象，如何识别关键抽象？
关键抽象是一个通常在需求上被揭示的概念，系统必须能够对其处理。它来源于业务，
体现了业务的核心价值，即业务需要处理哪些信息；这些信息所构成的实体即可作为初步的
实体分析类。
关键抽象来自于业务领域，领域专家可以很清楚地提供业务系统的初始关键抽象候选集
合，在此基础上，再结合业务对象模型、需求和词汇表等业务文档资料补充和完善。
23. 架构机制：架构机制是对通用问题的决策、方针和实践。作为系统架构的一部分，架构机制常常集中和定位在系统的非功能需求上
三类架构机制：分析机制（概念）、设计机制（具体）、实现机制（实际）
24. 分析机制用于在分析阶段中向设计人员提供复杂行为的简短表示，从而减少分析的复杂性并提高分析的一致性
25. 什么是用例实现？它和用例之间有何区别和联系？
用例实现是分析（设计） 模型1中一个系统用例的表达式，它通过对象交互的方式描述了构造用例实现是分析最核心的工作分析（设计）模型中指定的用例是如何实现的。
通过用例实现将用例模型中的用例和分析（设计）模型中的类以及交互紧密联系起来，一个用例实现描述了一个用例需要哪些类来实现，两者之间存在实现关系：即“‘用例实现’实现‘用例’ ”
获得实现用例行为所必须的分析类
利用这些分析类来描述其实现逻辑
针对每一个用例实现：
1. 完善用例文档
2. 识别分析类
<
<
<
3. 分析交互
将用例行为分配给类
4. 完成参与类类图
参与用例实现的类的类图
5. 处理用例关系
26. 顺序图：是一种交互图，描述对象之间的动态交互关系，着重体现对象间消息传递的时间顺序
绘制过程：放置对象、描述交互、验证行为
26.1 交互片段：
可选(opt)
该片段只有在守卫条件成立时才执行
选择(alt)
用水平虚线分割成几个分区。每个分区都有守卫条件，当守卫条件为真时执行
循环(loop)
在守卫条件为真的情况下循环执行
并行(par)
几个分区要并行（或并发）执行
26.2 可以将对象之间的信息传递以“//”的方式标记，表明初步进行类的职责分配，该项信息尚未制定完全
26.3 以B-C-E的方式绘制顺序图，并以Control类将控制逻辑隐藏起来
27. VOPC图：参与类类图(VOPC, View Of Participating Classes Class Diagram)
28. 什么是 B-C-E 三层架构？
B-C-E 三层架构是对 MVC 架构的另一种表述，将系统划分为三层，分别处理 3 类业务
逻辑。其中 B 表示边界层，负责处理系统与参与者的交互； C 为控制层，处理系统的控制
逻辑； E 为实体层，负责管理系统使用的信息
29. 什么是多重性，如何理解类间的多重性定义？
多重性表示一个类的对象可能链接到所关联的类的多个对象上，这种“多少”即为关联
角色的多重性，它表示一个整数的范围，通过多重性表达式来指名一组相关对象的可能个数。
需要从关联的另一端来理解多重性的定义，即表明另一端的一个对象可以与本方的多少
个对象相链接
30. 什么是聚合关系，聚合关系与关联关系、泛化关系有何不同？
聚合关系是一种特殊的关联关系，除了拥有关联关系所有的基本特征之外，两个关联的
类还分别代表“整体”和“部分”，意味着整体包含部分。
与普通的关联关系相比，关联两端的类要多一层整体和部分的含义，而普通的关联关系
并没有这层含义。
与泛化关系相比，关联是一种包含或拥有的关系，即整体包含或拥有部分；而泛化则是
“是一种”的一般和特殊的关系，子类是一种特殊的父类
31. 包
包是一种将模型元素分组的机制。
主要作用：组织模型元素、配置管理单元
32. 分包的原则：职责相似、协作关系
33. 包设计原则：
包内聚性原则
复用发布等价原则（REP）
共同复用原则（CRP）
共同封闭原则（CCP）
包耦合性原则
无环依赖原则（ADP）
稳定依赖原则（SDP）
稳定抽象原则（SAP）
34. 包之间的依赖关系是意味着什么，除了普通的依赖，还可以定义哪些关系？
包之间的依赖关系包含两层含义：其一是被依赖包的改变将影响到依赖包；其二则是依
赖包不能够独立的复用，因为它依赖于被依赖包。
除了普通的依赖关系，可以通过构造型进一步扩展不同的依赖关系，如合并、导入和访问
35. 接口(Interface)是类、子系统或构件提供的操作的集合
接口允许用户以公开的方式定义多态，并且和实现没有直接联系
接口支持“即插即用”的结构
36. 在类设计阶段，针对三种分析类的有什么不同的设计策略？
边界类的设计策略：边界类分为用户界面和系统接口，其中系统接口在架构设计时一般
定义为子系统和接口来实现，并通过子系统设计来完成其内部设计流程。而针对用户界面类，
需要研究具体的与用户交互的场景，设计满足要求的最终用户界面。界面类的设计往往依赖
项目可用的用户界面开发工具。 目前大多数界面设计工具都提供了自动创建了实现用户界面
所必需的支持类的能力， 这样类设计期间并不需要太多的考虑。更多地是从界面元素的布局
等人机工程学方面去考虑问题。
实体类的设计策略：由于实体类本身职责的明确性，大多数实体类都可以直接作为初始
的设计类存在。不过由于实体类往往具有持久性架构机制，因此该架构机制应用以及数据库
的一些设计原则也会影响到实体类的设计方案。此外，性能方面的要求也可能要对实体类进
行重构。
控制类的设计策略：控制类的设计首先需要明确该控制类是否有必要存在，有些控制类
只是简单地将边界类的消息转发给实体类，这种不含任何业务逻辑或处理流程的控制类就没
有存在的必要。当决定保留现有的控制类实现用例行为时，需要结合当前的用例实现和设计
质量方面的考虑，针对现有的控制类进行适当的处理，可以从以下两个方面改进控制类：（1）
提供公共控制类；（2）分解复杂的控制类。
37. 什么是操作和属性的可见性，有哪几种可见性？
可见性是指操作或属性可以被外界访问的程度。 UML 规范定义了四种可见性：公有、
私有、保护和包可见性
38. 什么是类的操作，什么是类的方法，它们有何区别和联系？
操作是类的行为特征，它描述了该类对于特定请求做出应答的规范。
方法是操作的具体实现算法，它描述操作如何实现的流程。
操作描述了类对外提供的接口，是类的外在行为。通过定义操作明确了参数和返回值等
接口细节；而方法则是关注操作内部实现算法的设计
39. 什么是类间的组合关系，和聚合关系有何区别和联系？
组合关系是一种特殊的聚合关系，在整体拥有部分同时，部分不能脱离整体而存在；当
整体不存在时，部分也没有存在的意义。从实现的角度来说，聚合表示一种引用关联，即整
体保存部分的引用，部分本身可以相对独立地存在；而组合则表示一种值关联，整体直接拥
有部分的值，并负责部分的创建和删除
40. 什么是类间的依赖关系，哪些情况下定义为依赖关系？
依赖是一种使用关系，表示一个类对象使用另外一个类对象的信息和服务，被使用对象
的变化可能会影响到使用对象。
定义为依赖关系的几种情况：参数引用，局部声明引用和全局引用
41. 模型驱动的开发(MDD, Model-Driven Development)
42. 什么是正向工程，一般可以对哪些 UML 设计模型进行正向工程？
正向工程是指按照软件开发的基本过程，将抽象层次较高的模型转换为相对具体的模型
的过程。可以对一下三类 UML 设计模型进行正向工程，以生成目标代码： （1）从类图生成
框架代码。（2）从交互图（主要指顺序图）生成方法中操作的调用代码。（3）从状态机图生
成状态转换控制代码
