一 章节知识架构图
二 UML 图
| UML 图 | 描述 |
|---|---|
| 用例图 | 由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图 |
| 类图 | 展现了一组对象、接口、协作和它们之间的关系。类之间的关系有关联、依赖、实现、泛化 |
| 对象图 | 描述一组对象它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照 |
| 构件图 | 描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构 |
| 组合结构图 | 用于画出结构化类的内部内容 |
| 顺序图 (序列图) |
由一组对象或参与者以及它们之间可能发送的消息构成。强调消息的时间次序的交互图。 |
| 通信图 | 强调收发消息的对象或参与者的结构组织。强调的是对象之间的组织结构（关系） |
| 定时图 | 强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺序 |
| 状态图 | 用来描述一个特定的对象所有可能得状态，以及由于各种事件的发生而引起的状态之间的转移和变化 |
| 活动图 | 将进程或其他计算的结构展示为计算内部一步步的控制流和数据流 |
| 部署图 | 软件和硬件组件之间的物理关系以及处理节点的组件分布情况 |
| 制品图 | 描述计算机中一个系统的物理结构通常与部署图一起使用 |
| 包图 | 描述由模型本身分解而成的组织单元，以及它们之间的依赖关系 |
| 交互概览图 | 是活动图和顺序图的混合物 |
2.1 用例图
定义：用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。
用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图，用于需求分析阶段。
包含关系
基用例 ——> 子用例
扩展关系
基用例 <—– 子用例
泛化关系
2.2 类和对象图
2.2.1 类的分类：
（1）实体类：实体类对应系统需求中的每一个实体，它们通常需要保存在永久存储体中，一般使用数据库表或文件来记录，实体类既包括存储和传递数据的类，还包括操作数据的类。实体类来源于需求说明中的名词，如学生、商品等。
（2）控制类：控制类用于体现应用程序的执行逻辑，提供相应的业务操作，将控制类抽象出来可以降低界面和数据库之间的耦合度。控制类用于对一个或几个用例所特有的控制行为进行建模。控制对象（控制类的实例）通常控制其他对象，因此它们的行为具有协调性质。控制类将用例的特有行为进行封装。
（3）接口类（边界类）：边界类用于对外部用户与系统之间的交互对象进行抽象，主要包括界面类，如对话框、窗口、菜单等。
历年真题 - 2.1
在某销售系统中，客户采用扫描二维码进行支付。若采用面向对象方法开发该销售系统，则客户类属于（）类，二维码类属于（）类。
A. 接口 B. 实体 C. 控制 D. 状态
A. 接口 B. 实体 C. 控制 D. 状态
2.2.2 类之间的关系
关联关系
是一种拥有关系，关联提供了不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起。
聚合关系
共享聚集关系通常简称为聚合关系，表示类之间的整体与部分的关系。其含义是“部分”可能同时属于多个“整体”，“部分”与“整体”的生命周期可以不相同。
组合关系
简称为组合关系，它也是表示类之间的整体与部分的关系。与集合关系的区别在于，组合关系中的“部分”只能属于一个“整体”，“部分”与“整体”的生命周期相同，“部分”随着“整体”的创建而创建，也随着“整体”的消亡而消亡。
依赖关系
是一种使用的关系，即一个类的实现需要另一个类的协助，所以要尽量不使用双向的互相依赖。可以简单的理解，就是一个类 A 使用到了另一个类 B。依赖可以由各种原因引起，如，一个类向另一个类发送消息，一个类是另一个类的数据成员、一个类是另一个类的某个操作参数等。
实现关系
实现关系将说明和实现联系起来。一个或多个类可以实现一个接口，而每个类分别实现接口中的操作。
2.3 状态图
2.4 活动图
| 状态图 | 活动图 |
|---|---|
| 用来描述一个特定的对象所有可能得状态，以及由于各种事件的发生而引起的状态之间的转移和变化 | 将进程或其他计算的结构展示为计算内部一步步的控制流和数据流，主要用来描述系统的动态视图 |
| 状态图主要描述行为的结果 | 活动图主要描述行为的动作 |
| 用于对系统的动态方面建模 | 用于对系统的动态方面建模 |
2.5 序列图 （顺序图）
2.6 协作图（通信图）
| 序列图 | 协作图 |
|---|---|
| 序列图主要用来更直观的表现各个对象交互的时间顺序，将体现的重点放在以时间为参照，各个对象发送、接收消息，处理消息，返回消息的时间流程顺序，也称为时序图 | 协作图是一种类图，强调参与交互的各个对象的结构信息和组织 |
共同点：时序图与协作图均显示了对象间的交互。
不同点：时序图强调交互的时间次序，协作图强调交互的空间结构。
2.7 构件图（组件图）
构件图描述了软件的各种构件和他们之间的依赖关系。构件图由源文件代码、二进制代码、可执行文件或动态链接库（DLL）等构件组成，并通过依赖关系相连接。
使用构件图的思想是复用。就像我们盖房子，当房子的大体框架建好之后，剩下的门和窗户家具之类的直接拿来安装上即可，不需要再重新制作，直接拿来复用的思想。这些门和窗户就相当于一个个的构件。
2.8 部署图
用来显示系统中软件和硬件的物理架构。从部署图中，可以了解到软件和硬件组件之间的物理关系以及处理节点的组件分布情况。使用部署图可以显示运行时系统的结构，同时还传达构成应用程序的硬件和软件元素的配置和部署方式。
2.9 包图
包被描述成文件夹，可以用于 UML 任何一种的图上。它是一种维护和描述系统总体结构的模型的重要建模工具，通过对包中各个包以及包之间关系的描述，展示出系统的模块与模块之间的依赖关系。
包图可以描述需求，设计的高阶概况；包图通过合理规划自身功能反应系统的高层架构，在逻辑上将系统进行模块化分解；包图最终是组织源码的方式。
一个包图可以由任何一种 UML 图组成，通常是 UML 用例图或者 UML 类图。包图只是把某些类放在一个包中，因此可以看做是类图的一种。
2.10 其他
| 组合结构图 | 定时图 | 制品图 | 交互概览图 |
|---|---|---|---|
| 描述结构化类（例如，构建或类）的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化类的内部内容 | 也称计时图，定时图也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关系消息的相对顺序 | 描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常与部署图一起使用。制品也给出了它们实现的类和构建。 | 是活动图和顺序图的混合物 |
真题示例 - 2.2
在 UML 图中，（）图用于展示所交付系统中软件和硬件之间的物理关系。
A. 类 B. 组件 C. 通信 D. 部署
真题示例 - 2.3
如图所示的 UML 类图中，Shop 和 Magazine 之间为（）关系，Magazine 和 Page 之间为（）关系。UML 类图通常不用于对（）进行建模。
（1）A. 关联 B. 依赖 C. 组合 D. 继承
（2）A. 关联 B. 依赖 C. 组合 D. 继承
（3）A. 系统的词汇 B. 简单的协作 C. 逻辑数据库模式 D. 对象快照
三 面向对象设计原则
| 原则 | 描述 |
|---|---|
| 单一职责原则 | 设计目的单一的类 |
| 开放-封闭原则 | 对扩展开放，对修改封闭 |
| 里氏替换原则 | 子类可以替换父类 |
| 依赖倒置原则 | 要依赖于抽象，不是具体实践。对接口进行编程，不要对实现编程。 |
| 接口隔离原则 | 使用多个专门的接口比使用单一的总接口好 |
| 组合重用原则 | 尽量使用组合而不是继承达到重用的目的 |
| 迪米特原则 (最少知识) |
一个对象应当对其他对象有尽可能少的了解 |
真题示例 - 3.1
在面向对象设计的原则中，（）原则是指抽象不应该依赖于细节，细节应该依赖于抽象，即应针对接口编程，而不是针对实现编程
A. 开闭 B. 里氏替换 C. 最少知识 D. 依赖倒置
四 设计模式
| 类型 | 描述 | 说明 |
|---|---|---|
| 创建型模式 | 用于创建对象 | 工厂方法模式、抽象工厂模式、单例模式、建造者模式、原型模式。共五种。口诀：单抽元件（建）厂 |
| 结构性模式 | 处理类或对象的组合 | 适配器模式、装饰器模式、代理模式、外观模式、桥接模式、组合模式、享元模式。共七种。口诀：外侨（桥）组员（元）戴（代）配饰 |
| 行为型模式 | 描述类于对象怎样交互、怎样分配职责 | 策略模式、模板方法模式、观察者模式、迭代子模式、责任链模式、命令模式、备忘录模式、状态模式、访问者模式、中介者模式、解释器模式。共十一种。口诀：观摩（模）对（迭）策，责令解放（访），戒（介）忘台（态） |
二十三种设计模式特点如下：
| 目的 | 设计模式 | 简要说明 | 特征 |
|---|---|---|---|
| 创建型 | Abstract Factory 抽象工厂 |
提供一个创建一系列相关或相互依赖对象的接口，而无需指定它们具体的类 | 抽象接口 |
| Builder 建造者 |
将一个复杂的对象的构建与它的表示分离，使得同样的构建过程可以创建不同的表示 | 类与构造分离 | |
| Factory Method 工厂方法 |
定义一个用于创建对象的接口，让子类决定将哪一个类实例化。使一个类的实例化延迟到其子类 | 子类实例化对象 | |
| Prototype 原型 |
用原型实例指定创建对象的种类，并且通过拷贝这个原型来创建新的对象 | 复用、拷贝原型 | |
| Singleton 单例 |
保证一个类仅有一个实例，并提供一个访问它的全局访问点 | 唯一实例 | |
| 结构型 | Adapter 适配器 |
将一个类的接口转换成客户希望的另外一个接口。Adapter 模式使得原本由于接口不兼容而不能一起工作的那些类可以一起工作 | 接口转换、兼容 |
| Bridge 桥接 |
将抽象部分与它的实际部分分离，使它们都可以独立地变化 | 抽象实现分离 | |
| Composite 组合模式 |
将对象组合成树形结构以表示“部分-整体”的层次结构。Composite 使得客户对单个对象和复合对象的使用具有一致性 | 整体-部分 树形结构 |
|
| Decorator 装饰模式 |
动态地给一个对象添加一些额外的职责。就扩展功能而言，Decorator 模式比生成子类方式更为灵活 | 附加职责 | |
| Facade 外观模式 |
为子系统中的一组接口提供一个一致的界面，外观模式通过提供一个高层接口，隔离了外部系统与子系统间复杂的交互过程，使得复杂系统的子系统更易使用 | 对外统一接口 | |
| Flyweight 享元模式 |
运用共享技术有效地支持大量细粒度的对象 | 细粒度复用、共享 | |
| Proxy 代理模式 |
为其他对象提供一种代理以控制对这个对象的访问。代理模式使用代理对象完成用户请求，屏蔽用户对真实对象的访问 | 代理控制 | |
| 行为型 | Chain of Responsibility 责任链模式 |
避免请求发送者与请求接收者耦合在一起，让多个对象都有可能接收请求，将这些对象连接成一条链，并且沿着这条链传递请求，直到有对象处理它为止 | 传递请求、职责、链接 |
| Iterator 迭代器模式 |
提供一种方法顺序访问一个聚合对象中各个元素，而又无需暴露该对象的内部表示 | 顺序访问 | |
| Mediator 中介者模式 |
用一个中介对象来封装一系列的对象交互，中介者使各对象不需要显式地相互引用，从而使其耦合松散，而且可以独立地改变它们之间的交互 | 不直接引用 | |
| Memento 备忘录模式 |
在不破坏封装性的前提下，捕获一个对象的内部状态，并在该对象之外保存这个状态。这样就可以将该对象恢复到原先保存的状态 | 保存、恢复 | |
| Observer 观察者模式 |
观察者模式定义了对象间一种一对多依赖关系，使得每当一个对象改变状态，则所有依赖于它的对象都会得到通知并被自动更新 | 通知、自动更新 | |
| State 状态模式 |
允许一个对象在其内部状态改变时改变它的行为。对象看起来似乎修改了它的类 | 状态变成类 | |
| Strategy 策略模式 |
策略模式定义了一系列算法，并将每一个算法封装起来，而且使它们还可以相互替换。策略模式让算法独立于使用它的客户而独立变化 | 算法替换 | |
| Command 命令模式 |
将一个请求封装成一个对象，从而使得用不同的请求对客户进行参数化；对请求排队或记录请求日志，以及支持可撤销的操作 | 参数化、日志记录 | |
| Interpreter 解释器模式 |
给定一个语言，定义它的文法的一种表示，并定义一个解释器，这个解释器使用该表示来解释语言中的句子 | 文法、解释 | |
| Template Method 模板方法 |
定义一个操作中的算法的骨架，而将一些步骤延迟到子类中。模板方法使得子类可以不改变一个算法的结构即可重定义该算法的某些特定步骤 | 算法结构不变，子类定义步骤 | |
| Visitor 访问者模式 |
表示一个作用于某对象结构中的各元素的操作。它使你可以在不改变各元素的类的前提下定义作用于这些元素的新操作。即对于某个对象或一组对象，不同的访问者，产生的结果不同，执行操作也不同 | 类不变、新操作 |
真题示例 - 4.1
以下设计模式中，（）模式使多个对象都有机会处理请求。将这些对象连成一条链。并沿着这条链传递该请求。直到有一个对象处理为止。从而避免请求的发送者和接收者之间的耦合关系。（）模式提供了一种方法顺序访问一个聚合对象中的各个元素。且不需要暴露该对象的内部表示。这两个模式均为（）。
A. 责任链（Chain of Responsibility） B.解释器（Interpreter） C. 命令（Command） D.迭代器（Iterator）
A. 责任链（Chain of Responsibility） B.解释器（Interpreter） C. 命令（Command） D.迭代器（Iterator）
A. 创建型对象模式 B. 结构型对象模式 C. 行为型对象模式 D. 行为型类模式
真题示例 - 4.2
观察者（Observer）模式适用于（）。
A. 访问一个聚合对象的内容，而无需暴露它的内部表示
B. 减少多个对象或类之间的通信复杂性
C. 将对象的状态恢复到先前的状态
D. 一个多对象依赖关系。当一个对象修改后，依赖他的对象都自动得到通知。
案例分析
【说明】
某图书公司欲开发一个基于 Web 的书籍销售系统，为顾客（Customer）提供在线购买书籍（Books）的功能，同时对公司书籍的库存及销售情况进行管理。系统的主要功能描述如下：
- 首次使用系统时，顾客需要在系统中注册（Register detail）。顾客填写注册信息表要求的信息，包括姓名（name）、收货地址（address）、电子邮箱（email）等，系统将为其生成一个注册码。
- 注册成功的顾客可以登录系统在线购买书籍（Buy books）。购买时可以浏览书籍信息，包括书名（title）、作者（author）、内容间接（introduction）等。如果某种书籍的库存量为 0，那么顾客无法查询到该书籍的信息。顾客选择所需购买的书籍及购买数量（quantities），若购买数量超过库存量，提示库存不足；若购买数量小于库存量，系统将显示验证界面，要求顾客输入注册码。注册码验证正确后，自动生成订单（Order），否则，提示验证错误。如果顾客需要，可以选择打印订单（Printorder）。
- 派送人员（Dispatcher）每天早晨从系统中获取当日的派送列表信息（Produce picklist），按照收货地址派送顾客订购的书籍。
- 用于销售的书籍由公司的采购人员（Buyer）进行采购（Reorderbooks）。采购人员每天从系统中获取库存量低于再次订购量的书籍信息，对这些书籍进行再次购买，以保证充足的库存量。新书籍到货时，采购人员向在线销售目录（Catalog）中添加新的书籍信息（Addbooks）。
- 采购人员根据书籍的销售情况，对销量较低的书籍设置折扣或促销活动（Promote books）。
- 当新书籍到货时，仓库管理员（Warehouseman）接收书籍，更新库存（Update stock）。
现采用面向对象方法开发书籍销售系统，得到如图 3-1 所示的用例图和图 3-2 所示的初始类图（部分）。
【问题 1】（6 分）
根据说明中的描述，给出图 3-1 中 A1-A3 所对应的参与者名称和 U1-U3 处所对应的用例名称。
【问题 2】（6 分）
根据说明中的描述，给出图 3-1 中用例 U3 的用例描述。（用例描述中必须包括基本事件流和所有的备选事件流）
【问题 3】（3 分）
根据说明中的描述，给出图 3-2 中 C1-C3 所对应的类名。
真题答案
| 题号 | 答案 |
|---|---|
| 2.1 | B、A |
| 2.2 | D |
| 2.3 | A、C、D |
| 3.1 | D |
| 4.1 | A、D、C |
| 4.2 | D |
案例分析
【问题 1】
A1：Buyer
A2：Warehouseman
A3：Dispatcher
U1：Register detail
U2：Printorder
U3：Buy books
【问题 2】
【问题 3】
C1：Customer
C2：Order
C3：Books