第十一章.软件工程（下）

---

第十一章.软件工程

第九节.面向对象设计

面向对象（OAA）的基本概念

对象
在开发的时候，我们会把人物这些现实东西都抽象为对象。像人物的一些特征变成对象当中的一些属性；比如某个人抽象成对象之前，他会有身高、年龄、体重等等数据，这些都是以属性的方式出现；还会有他自己的操作方法，意思就是这个人在这个系统当中能做些什么事情。

类（实体类、边界类、控制类）
类是把对象的共性抽取出来而形成的类。具体来讲，类又分为实体类、边界类和控制类这几个类别。

• 实体类：往往跟数据对应的就是实体类，比方说咱们的系统当中要用到老师的信息，那么教室类就可以充当实体类，实体类它是跟数据相关的。
• 边界类：就是一个系统会有他的边界，这个系统里面会有很多类，其中有一些类是在这个边界上面需要跟外界相连。它往往也不会超出边界的范围，它还是在系统之内，但是它会有职能要跟外界的系统进行交互，这就会成为边界类要有这种特征。
• 控制类：类与类之间是需要衔接和控制，所以会有控制类。它是做衔接部件的。

抽象
没什么好讲的。

封装
什么是封装呢？通俗一点来讲，我们会把相关的数据把它封装在一起，比如说对象就有相应的封装机制，会把这一个对象相关的信息。封装起来的表现是什么呢？我们要去用这个对象，你不能够直接操作对象里面的数据，而需要通过对象的接口进行相关的操作。这就是封装的理念。那具体编写代码的层次，封装的理念就是我们会把有一部分的属性把它定义为私有的，你要操作这部分属性也可以用我们提供给外界的接口也就是公共的一些操作方法，比如说 set、get 方法来操作这个私有变量的情况，你不能够直接用对象.名字去操作这个属性，这就是不允许的。

继承和泛化
继承和泛化其实一回事，只是从不同的角度来看，有父类，有子类，子类会继承父类的相关特性，这是继承。如果说有多个类，他们有共性，我们把共性抽出来，形成了一个上层的类，这个过程称为泛化。通俗一点来讲就是广泛化，因为上面的这一个类它的适用范围肯定会更广一些。

多态
多态最为直观的表现就是 我做同样的操作，但是控制的可能是不同的对象，那么它的操作会有差异会表现出不同的做法。比如说有动物类，底下有鱼猫狗之类的。它们的运动我们用 run()这个函数来表示。那动物这个类里面就已经有 run()函数，在鱼猫狗这些种类里面会具体地把它们如何运动给描述出来。我们知道猫和狗都是走，而鱼是游。如果说我们创建了一个对象集，这些动物都有鱼有猫有狗，我们要控制它的运动。我定义一个变量指针，这个指针类型是鱼能不能够用这个指针来操控狗和猫了，那是不行的。所以这个时候我们往往会定义一个动物类型的指针，这种指针既可以指向猫，也可以指向狗，还可以指向鱼。那表现形式就是指针.run() 就可以控制当前它指向的这个动物运动。在这个过程中如果说指针指向的是鱼，这个 run 表示游，如果说指针指向的是猫和狗，这个run表示走。所以说看上去是完全一样的形式，但是表现出了不同的状态。这就是多态的含义。如果是在Java中，这个指针就是父类对象，指向创建的子类对象。

多态分类
一般将多态分为通用多态和特殊多态。通用多态包括参数多态和包含多态。
参数多态采用参数化模板，通过给出不同的类型参数，使得一个结构有多种类型。
包含多态同样的操作可用于一个类型及其子类型。 (注意是子类型，不是子类。) 包含多态一般需要进行运行时的类型检查。如Pascal中的子界。
特殊多态包括强制多态和过载多态。
强制多态编译程序通过语义操作，把操作对象的类型强行加以变换，以符合函数或操作符的要求。程序设计语言中 基本类型的大多数操作符，在发生不同类型的数据进行混合运算时，编译程序一般都会进行强制多态
过载多态是一种特定的多态，指同一个名（操作符、函数名）在不同上下文中可代表不同的含义。

---

接口
什么是接口了？首先我们给它定性，接口是一种类，但是它是一种特殊的类，特殊在哪里了？这种类只有方法的定义，没有方法的实现，相当于它定义的方法都是空框框。

消息
消息就是进行对象之间进行交互的时候所采用的机制，它走的是异步的方式在传输的。对象之间的通信都是走的消息的模式。

组件
组件就是构建

模式和复用
提出模式的概念本身就是为了复用。后面我们会详细讲到模式，因为有架构模式、设计模式之类的。其实模式就是一种经验的传承。我们解决这类问题以前用到了这种方式，现在我们把它归总起来，进行相关的一些规范化的调整，就形成了一种模式，以后针对这种问题我都用这种模式去解决。这就是模式的基本思路，根据不同的抽象级别又可以分为了架构模式、设计模式，还有惯用法之类的。

---

面向对象开发各阶段划分及任务

面向对象分析阶段：认定对象，组织对象，对象间的相互作用，基于对象的操作。
面向对象设计阶段：识别类及对象、定义属性、定义服务、识别关系、识别包。
面向对象程序设计：程序设计范型、选择一种OOPL。
面向对象测试：算法层、类层、模板层、系统层。

---

OOA 设计原则

面向对象设计原则在设计的过程中非常的实用。另外一方面我们后面会讲到设计模式，其实设计模式就是利用到这些设计原则来解决一些实际问题的解决方案。所以我们在设计模式里面是能够看到这些设计原则的一些影子的。

单一职责原则：设计目的单一的类
目的单一的类就是指的我们做一个类出来，这个类它的目的应该只能解决一个方面的问题，这就符合单一值的原则。为什么要考虑这样子来做呢？是因为如果说一个类它的职责越多，那它和其他类关联的可能性其实是越大的。这就好比我们日常生活中，你在公司里面管的事务，只管一个事务，让你跟你打交道的人会比较少。当你管多个业务线的业务的时候，你和相关的人员去沟通的时候，这个相关人员的群体就会要大得多。所以说我们的类如果说职责比较单一，会降低整个程序的耦合程度。

开放-封闭原则：对扩展开放，对修改封闭
对扩展开放，对修改封闭是什么意思呢？就是我们不要去做程序的修改，要的话就做程序的扩展。因为我们在维护的过程中经常要加一些新的功能，加新功能的第一种方式就是在原有的类的基础上把这个类改得更加强大一些，它支持的东西更多一些。另外一种方法就是我不去改原来的东西，新的功能用新的类去实现。故在开闭原则里面，该原则希望我们用扩展的方式，用新的类来解决问题，而不要去修改原有的东西。为什么呢？因为你在修改程序的时候很容易引入错误，引入错误影响到的不仅仅是新的功能，还会影响到原有的功能，这就带来了一些不安全的因素隐患。所以要执行开闭原则，你不去修改这个问题就可以得以避免。

李氏(Liskov)替换原则：子类可以替换父类
为什么子类可以替换父类呢？因为面向对象体系当中实际上是有着继承关系在里面的。子类继承父类，子类是拥有父类相关的特性，所以子类是可以替换父类去做相关的事情的，因为子类可能比父类还要懂得更多一些，但是父类懂的子类都懂，所以子类可以给父类顶班替班。为什么强调这一点是因为虽然有继承机制在，但是有的时候我们可能子类不见得能够替换父类。什么情况呢？就是当你把子类当中的一些方法做重载做覆盖之后，这个时候子类相同的函数和父类的起到的职能不一样，这个时候子类就不能够替换父类了。所以李氏替换原则希望我们做到的是你不要去盲目的重载去修改父类的方法，这样子会有安全隐患，因为你修改了别人不知道别人只看到他们之间有继承关系，就认为子类可以替换父类，那样子会出错。所以有这个原则就能够避免一些问题，让你设计的时候时刻记得要当子类能够替换父类时，你就不会去做重载这件事情。在我们的开发当中也确实这么去做的。为什么呢？你像接口的这种机制就是这样子引入过来的，子类和父类如果说有重载就会导致一些问题，那如果说这一个父类是一个接口，问题就不再存在了。

依赖倒置原则：要依赖于抽象，而不是具体实现；针对接口编程，不要针对实现编程
该原则要表达的是什么意思呢？意思就是我们在进行设计的时候，那你要去依赖于接口，不要依赖于具体的实现类。依赖于接口有什么好处呢？依赖于接口，它能够让我们的操作很灵活，而且不受太多的制约。举个简单的例子，在硬件领域，比方说我们的计算机，它就是一种针对接口编程而不针对实现编程的。为什么这么讲？我们拆开计算机会发现里面有很多标准接口，比如说 PCI 接口、VGA接口等等这么一系列的接口。那么这些接口是怎么做的吗？主板上面有插槽，显卡或者其他的声卡之类的板卡上面有那种金手指的这个插条。如果说要把两者对接，那就是直接把显卡或者声卡或者网卡插到插槽里面进行对接。这说明两个部件它们要关联结合在一起的时候是用到了接口。而类似的情况在电视机里面他就不会这么去做，部件与部件之间往往是焊接的方式。那这种就属于针对实现编程紧耦合的方式。那么两者是各有千秋的。为什么呢？像计算机的这种体制都是用的接口，那么你要做一些调整和改变就会比较方便，要扩展也比较容易。比如说你要升级显卡，那你把显卡拔下来换一块上去就可以了，而电视机就没这么方便了，那是要通过焊接。那为什么电视机不做成那种可拔插可更换式的呢？因为我们的用户习惯当中电视机是不用做部件的升级的，所以不需要这么去做。而在我们的开发过程中，在开发过程中的话，软件的部件是随时可能升级的。所以如果说你是紧耦合是针对实现编程，那你一个小的部件要做调整，那会很麻烦。但如果针对接口了，这个问题就迎刃而解。

接口隔离原则：使用多个专门的接口比使用单一的总接口要好
为什么这种原则要好呢？这其实就是接口的单一职责的目的。就一个接口我只做一件事情，那就能够把问题简单化，不容易出错，不会因为职责过多而导致一些问题一些疏漏。

组合重用原则：要尽量使用组合，而不是继承关系达到重用目的
为什么尽量不使用继承关系呢？因为继承它是一种紧耦合关系，所以我们要避免去用它继承。为什么继承是紧耦合关系呢？因为父类一变，子类也都要跟着变，这就自然紧耦合。

共同封闭原则：包中的所有类对于同一性质的变化应该是共同封闭的。一个变化若对一个包产生影响，则将对该包产生影响，则将对该包里的所有类产生影响，而对于其他的包不造成任何影响

共同重用原则：一个包里的所有类应该是共同重用的。如果重用了包里的一个类，那么就要重用包中的所有类

迪米特(Demeter)原则(最少知识法则)：一个对象应当对其他对象有尽可能的了解
最少知识法则的基本思路就是一个对象，他要尽可能少的对其他对象有了解。这就跟我们之前讲到的信息隐蔽是一回事，只有你对另外一个对象了解非常之少，你才能够用标准的方式去调用它。如果说你知道的越多，你就越容易绕开规则，直接操作对象里面的属性方法之类的，这不太合适。那么最少支持法则是通过什么来实现的呢？往往就是通过封装，我们把一个对象给封装起来。封装起来之后，对象里面的属性方法可以私有的，私有的属性方法外界是看不到的。

总结
这就是面向对象的一系列原则。其实在面向对象的设计过程中，我们一直要记得这些原则，否则了开发出来的程序往往会存在这样或那样的一些问题，比如说可扩展能力不强，比如说可修改性不强等等这一系列的问题。所以这些原则是要把握好的。在考试的时候，这些原则以选择题的形式出现的比较多。然后往往问到哪些说法是对的，哪些说法是不对的，或者说了给你一个原则，给你一系列描述，问这些描述是否符合原则的这一个基本的思想。所以对这些原则要有一定的认识。

---

OOA - UML

UML是一个非常重要的知识点，考察频度也很高。在这里我们要了解的东西主要是 UML 的一系列的图，这是最核心的。其次是要对这几种关系有一定的了解。好下面我们来逐步展开来进行相关的讲解。

1.UML 是分三个部分——构造块、规则和公共机制。其实规则和公共机制几乎考试就不会涉及到，所以我们不会去讲它。然后构造块又分为事物、关系和图，主要考的是关系和图。所以我们重点讲的就是关系和图。

2.首先来看到图，因为图是 UML 的主体部分。
UML 建模做的是什么呢？ 无非就是用到他提供的这些图工具，把相关的项目的一些情况用这种图来表达和表示 称之为建模。所以这些图是非常重要的，这些图相当于给我们提供了一个工具集。

在UML 2.0 里面的图集总共有14个图，在 UML 1.0 里面有 9 种图。这些图首先是分成两大块，一部分称为结构图，另外一部分称为行为图。也可以讲，一部分是静态图，还有一部分是动态图。
故我们只需要了解了解 哪些图属于静态图，哪些图属于动态图，哪些图是结构图，哪些是行为图，这是第一个梯度要掌握的信息。图中已经标出图的信息。

这里特别值得说明的一点是，用例图是在区分它是动态图还是静态图的时候存在分歧的一种图。我们查阅资料会发现，有些地方把用例图归为行为图，动态图，有些地方又把它归为静态图，结构图。所以在考试的时候，如果说遇到要你分清以下图属于静态图的是哪个，不属于动态图的是哪个？那你首先不要给用例图定性，你先来找其他图，因为其他图都是有明确分类的，把其他图全部明确了之后再来看题目的意思进行分析，这样子就不容易出错。因为在考试的时候把它归为动态还是静态，其实没有完全一致的讲法，大部分时间归成了动态，也有小部分情况把它归成了静态。所以这一点大家要了解清楚，否则你懂了知识，但是不能够得分。

3.对于常见的结构（静态）图的基本情况要有一个了解。

• 类图它所表达的是类和类之间的关系。
• 对象图就是对象与对象之间的关系。
• 包图就是展示包与包之间关系以及包内部的结构。
• 然后像构建图什么之类的都有类似的特性。

在所有的静态图里面唯一一个描述上面会有区别的是部署，因为其他的基本上都是谁和谁之间关系。而部署图所讲述的是软件的构建，应该部署在哪个硬件的节点之上，表达的是这个信息。所以相对来讲所有的结构图都还是比较简单的。

4.对于常见的行为（动态）图的基本情况要有一个了解。行为图也是各有各的特色，各有各的特征。

• 用例图（考得比较多）表达的是系统和外部的交互关系。因为用例图最简单的一个图示，就是一个小人一样的符号，然后会跟系统内部的一些功能有交互。所以说这就是外部的角色或参与者跟系统内部的一种交互关系。
• 顺序图/序列图 一定要强调按时间顺序，否则就无法标识它是哪一种图。
• 通信图/协助图 没有强调时间顺序。
• 定时图（考得比较少）
• 状态图表达的是状态的变迁转移的情况。
• 活动图它跟流程图的结构是一致的。

这是这些比较有代表性的常考的一些动态图基本的情况，其他没有做详细解释的，也就不用去管它了。

对UML的误区
一个就是这个 UML 这么多种图，你能不能够用一个实例把这些图都给他穿起来，然后告诉我们怎么去用它，这本身就有误区。如果一个项目把各种图用起来才算是真正掌握了 UML 用到了 UML 了吗？这种思想也非常极端。为什么呢？UML 就是一个工具箱、一个工具集。那你做什么事情就需要用到不同的工具，没有人会说你必须要把所有工具用在同一个场景里面才叫效果好，没有这种讲法。这就好比我们学了这一个中文汉字之后写文章，是不是要把所有的汉字用上才叫好文章呢，显然不是这样子的，关键是你如何去用它把相关的内容用到恰到好处。

---

OOA 设计模式的概念

在了解设计模式基本概念的时候，我们引入一组模式来进行区别对待和分析。这一组分别是架构模式、设计模式和惯用法，这是从高中低三个复用级别来进行分类的。

• 架构模式它属于软件设计中的高层决策。什么叫高层决策呢？就是从全局来看待问题，分析问题得出的结论。例如 C/S 结构就属于架构模式，还有包括我们之前所讲到的 B/S 、SOA等等这么一系列，它们都属于从整体全局的角度来看的方案。因为所谓模式其实就是以前成功方案的应用和复用。
• 设计模式主要关注软件系统的设计，具体就是局部的设计问题，与具体语言无关。这就类似于了我们在建房子的时候，整体的框架是属于架构模式。但是具体到门、阶梯、斜坡这个时候就是设计模式管的事情，再到一套房子如何去分割之类的，这也是设计模式考虑的问题。即它考虑的层次要比架构模式要低一个层次，往往是在哪个级别用到，是在进行构建的设计的时候会用到设计模式。
• 惯用法是最低层的模式，关注软件系统的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有它自己特定的模式，即语言的惯用法。例如引用-计数就是C++语言中的一种惯用法。从哪里可以看出它的层级比较低呢？从它跟语言相关这一点可以看出来。因为设计模式与语言无关的，比如说工厂方法，那你用 C sharp 语言或者说 Java 语言，其实都是可以做到工厂方法这种模式的，惯用法就不一样了，它跟语言相关，比如说引用计数就是 C++语言中的一种惯用法。

所以我们要区分惯用法和设计模式，主要就是看它与语言是否相关。要区分设计模式与架构模式，主要是看它是从全局走的还是从局部来分析看待问题的，这是设计模式这一块基本的一个概念。

---

OOA 设计模式的分类

ps：常考，23种模式都是重点。

设计模式多种多样，但是总的来讲可以分成三种类别，第一种是创建型模式，第二种是结构型模式，第三种是行为型模式。

1.创建型模式就是指的用于创建对象的模式，它为设计类实例化新对象提供指南。那么我们知道对象的产生其实是用 new 这样的关键字，可以很简单很方便的产生。为什么需要设计模式来掺和这个事情呢？这是因为简单的用 new 的方式来产生对象往往灵活度不够，然后在一些场景之下要费比较大的功夫才能够完成和达到我们需要的效果。所以就诞生了一系列的创建型的模式。比如说工厂方法，工厂方法就是构建的一个工厂，你只要给工厂下发指令，就能够生产出你想需要用到的这一种对象。那这个时候你如果说要不同类型的一些对象，你只要改工厂方法里面的内容就可以了，而不需要去调整原有的业务逻辑这一块的代码。所以就相当于把创建对象这件事情把它脱离出来，这对于我们维护肯定是有好处的。像抽象工厂可以生产按系列生产相应的对象，原型模式，还有单例模式、构建器模式，这些都属于创建型模式。后面我们会逐一的进行讲解。

2.结构型的模式主要是处理类或对象的组合问题，让类或对象形成更大的结构，提供相应的一些指导。结构型模式典型的有适配器模式、桥接模式、组合模式等等，他们各有各的一些特色，比如说适配器模式就可以通过这样的模式进行统一的操作，就可以把原来不统一的东西统一起来。这就跟我们的电源适配器差不多。家用电用到的是 220 伏的交流电，而手机上用到的是 4.7 伏的直流电，笔记本上面用到的往往是 12 伏的直流电，不同的地方用到的电有不同的差别。这个时候我们就要用到电源适配器来做转换工作。所以其实我们平常的所谓的充电器就是适配器。桥接模式、组合模式、装饰模式、外观模式等等都有各自的特点。后面会一一介绍。
主要意图是 将抽象部分与其实现部分分离，使它们都可以独立地变化。

3.行为型模式 包括职责链、命令解释器、迭代器等等。行为型的模式它主要了是用来描述类或者说对象交互的这个情况以及职责的分配的问题是在这一方面有他的一些方案，因为每一种模式都是一种不同的方案。

这是设计模式的分类。这些分类我们要搞清楚哪些是属于创建型，哪些是结构型，哪些是行为型，这就是设计模式要掌握的这些一系列模式当中第一梯度需要掌握的东西。

---

创建型模式

创建型模式抽象了实例化过程,它们帮助一个系统独立于如何创建、组合和表示它的对象。

抽象工厂模式
图中的简要说明什么意思呢？就是抽象工厂它是做一系列产品。比方说我们在创建数据库相关的一些组件的时候，用到抽象工厂的话，那是什么情况呢？我可以指定我现在要创建的这一系列的操作数据的这些对象是用来操作 access 数据库的，那你就指定是由 access 工厂来进行生产。那你生产出来的所有的部件都是适用于 access 的。如果说你指定的工厂是 Oracle 的，那么所有的部件也都是 Oracle 的，就相当于了它只要指定系列名，而不需要去指定具体的类，就能够生产出这一个系列所对应的所需要的类的对象，这是抽象工厂模式。

构建器模式
图中的简要说明什么意思呢？就是指的咱们要构造某一个复杂的对象。那么这一个对象有可能是有多个对象所组合起来的。但是构造不同的最终的这个实例可能需要的部件不太一样。那这个时候我们可以用一个构建器模式把所需要的各个部分给它封装起来。然后对各个部分你可以指定不同的部件，最后形成你所需要的这一个实例。

工厂方法模式
图中的简要说明简单一点来讲，就是我们在用工厂方法来创建的时候，我可以在运行的时候去指定我要创建的具体是哪一个类的对象，所以就使得这一个实例化过程推迟了。

原型模式
原型模式也称为了克隆模型。那么这种方式是通过拷贝原有的这个原型对象来生成一个新的对象。但是咱们觉得新生成一个对象用 new 也很好。为什么要用拷贝现有的对象来生成新的对象呢？因为用 new 的方式来创建一个新的对象，问题就在于它所消耗的资源会比较多。如果说我们只是通过拷贝，由于是拷贝的内存区域，根本不用涉及到里面的逻辑是怎么样的，直接把内存 copy 一份出来。那这样子效率是最高的。这就好比我们在写代码的时候，你把原来的代码 copy 了一份，然后再稍微修改一下，得到我们需要的新的代码，这效率肯定是高一些，比你重新开头写的效率肯定要高得多。这就是原型模式用它主要考虑的是效率问题。

单例模式
单例模式基本思路非常简单，就是它保证一个类只有一个实例，无论你在系统当中哪个位置调用，它都是得到的这一个实例，不过会形成第二个实例，有很多时候咱们需要这样的场景，比方说现在了，在一个浏览器里面可以打开多个网页，其实就是不同的标签页。但是浏览器的主窗口只有一个，在这个里面就用到了单例模式。当你要打开一个新的标签页的时候，他会找到主窗口的句柄，之后在主窗口里面去开启一个新的标签页，这是单例模式基本的思想。
对于系统中的某些类而言，只有一个实例是很重要的。单例模式的意图就是保证一个类仅有一个实例，并提供一个访问它的全局访问点。

---

结构型模式

结构型模式比较多，我们主要会讲到的是常用的一些，而且为了大家方便记忆，对于比较有非常明显特色的一些这个设计模式了，我总结了它的速记关键字。

适配器模式
说明中的做法 就是适配器模式要解决的主要问题。所以给它的关键字是转换接口。在这讲到转换接口的时候，请大家想到电源适配器，比如说在软件领域里面，我们可以用到的对外的接口很多种，每种不同的厂商给我们提供了不同的接口。我们现在要用到这些接口，并且希望用一致的方法应用，那你就可以用适配器模式。

桥接模式
如果说看类图的话，这是一种非常典型的桥的结构。为什么要这么做呢？它往往是这种应用场景，原来了是一棵大的类树，如果说要用继承的方式来走，这棵树了会非常之庞大。然而我们发现了这棵树当中变化点有两个方面，所以就把它拆成两个不同的方面，让它在两个维度上面形成两棵树。然后把它桥接起来。这样子就把继承树相当于进行了拆分简化问题了，这就是桥接。

组合模式
组合模式要表达的是以这种组合数的形式表示了整体和部分的关系，典型代表就是树形目录结构。什么情况呢？比如说这是一个目录底下了可以有目录还可以有文件。其实这里面就折射出来了整体部分，到部分的时候又可以包含其他部分的这样的一种结构。这种结构应用非常广泛，像我们操作系统里面的树形目录结构是一方面的应用。还有比方说在一个公司里面涉及到部门，部门底下又可能有分支机构一层一层下来，或者说总公司底下有部门，有分公司，分公司底下又有部门还有办事处之类的一级一级往下走。所以组合模式应用的也是比较多的。

装饰模式
装饰模式顾名思义它就是一层一层往上面加。所以给它的一个简要说明是动态的给一个对象添加一些额外的职责，它提供了用子类扩展功能的一个灵活的替代，比派生一个子类更加的灵活。所以给他的关键字是附加职责。附加职责如何去附加呢？它会有一个基础的类，之后需要其他的东西又是一层一层往上面叠就可以了。你比如说有一个经典的实例就是讲到的，我们星巴克喝咖啡，那你可以考虑加奶，加糖，还可以加其他的一些东西。在这个过程中实际上就可以用到装饰模式，因为有些人要加糖，有些人要加奶，有些人既要加糖也要加奶，那就可以把这种外面的职责一层一层的给它附加上去。

外观模式
图中的简要说明什么意思呢？假设一个系统可以有多个边界的类，假设这一系列的边界的类，他们有着不同的职能，他们既然是边界类，那么都要跟外界进行联系，这样看上去就比较复杂。同时外界来了解你的时候也会比较复杂，因为它要跟多个这个接口类进行交互，所以相当于有多个窗口对外。这个时候有人就想到一个办法，把这个问题简化，怎么简化呢？就是我还是有这一堆的窗口，但是这些窗口都和一个类进行交互。这就是外观模式，它提供了一个高层的接口，为子系统的一组接口，提供了一个一致的外观。

享元模式
享元模式提供支持大量细粒度对象共享的有效方法。记得这个概念就行了。

代理模式
代理模式就是 为其他的对象提供一种代理以控制这一个对象的访问。

---

行为型模式

职责链模式
简要说明的意思是这样子的，有一个请求者，然后会有多个接收者被连成了一个串，也就是一个链。请求者发送请求给接收者。如果说第一个接受者能够响应，那就直接给你响应了。如果说不能响应，就传递到第二个接收者由第二磅来处理，第二磅还不能处理，那就传到第三磅，第三磅能处理就给他回复。什么时候要用到它呢？比如说我们的财务审批最为小的一档金额，比如说 500 块经费内部门经理能批， 500 块以下的请求他就直接批掉了，副总能够签批的金额是 2000 块以内，所以 2000 块以内了就到副总这个级别就签批了，然后财务总监可以签批 1 万块以内的。意思就是批准经费从最低级的部门经理开始，如果审批不了，就提交到更高一级的人员进行审批。这就是职责链模式，他会传递职责，就是把这种自己处理不了的请求把它传递下去。职责链模式有什么好处呢？就不要这一个申请者请求者来跟多个接收者进行交互，他就只要传送一次接下来的任务了就后面去处理了。

命令模式
对于命令模式最大的一个特点就是命令它不是一个简单的消息了，它已经被封装成一个对象。然后引入了命令模式，可以很方便地进行日志记录，同时可以撤销你之前所进行的命令操作。

解释器模式
其实解释器模式它相当于是在构造一个虚拟机去处理问题，它构造了这么一个解释器来解释相应的语言来进行相关的处理操作。

迭代器模式
其实迭代器模式在我们的开发过程中应用是非常的广泛的，因为我们在开发的过程中经常用到一种类型，它是枚举类型的。那么这种类型我们要给它进行相应的遍历的时候，操作起来非常简单，就是用对象指针.next 就可以访问到这个集合里面的下一个对象。其实这里面就用到了迭代器的模式。

中介者模式
简要说明意思就是本来两者之间可以直接通信，但是现在通过中介模式来进行通信。比方说我们在多个对象之间相当于引入了一个中间件，就起到了这样的一个效果。那如果说有一系列的改变的时候，我们不需要去修改对方，而只需要修改中介器就可以了。比如说 A 和 B 之间进行通信，如果说直接引用，A 有变化，那 B 要跟着变才可以适应。但如果说中间有一个中介器，那我们如果说有一方发生了变化，改中介器就可以了，这是这样的一个情况。所以它最大的特色是不直接引用。

备忘录模式
备忘录其实就是把它记下来，意思就是我们会开辟一个空间，把对象的相关的信息把它存下来。一旦将对象相关信息存下来之后，就可以对对象恢复的操作。

观察者模式
举个例子进行理解。比方说我们平常用到的 Excel 你在 A1 单元格里面填了个1，A2单元格里面填了个1， A3 等于 A1 加A2。那么这个时候 A3 是等于 2 ，一旦我们把 A1 的值改为 10 的时候，A3会自动的变成11，这就有观察者模式的存在。 A3 观察了A1，所以 A1 一旦发生变化，会通知 A3 让它也发生变化，这就是观察者模式。

状态模式
简要说明的意思就是会把各种状态做成相应的类，然后状态的改变就能够改变他当前可以执行的相应的行为。那这个时候咱们就只要做好状态的一个变迁，然后变迁到这种状态下，然后再做什么样的操作呢？它会根据当前的状态的情况，他的行为也就变化了，这种场景也比较多。比方说会员，会员会有不同的级别，它可以享受到不同的折扣。那如果说我们把不同的会员的状态级别定义成类，那么它每一种类它能够做的行为就已经做好了相应的设计。

策略模式
图中的简要说明什么意思呢？比如说我要对一组数进行排序，我可以用到的算法有快速排序冒泡法、归并法等多种排序方法。这个时候我可以通过设置很方便的切换，我用哪一种方法来完成排序。所以涉及到灵活的多种方案的切换的时候，你又可以用到策略模式。

模板方法
了解它的基本概念就可以了，不需要深究。

访问者模式
了解它的基本概念就可以了，不需要深究。

---

第十节.数据流图（DFD）

数据流图也称为 DFD 或者 分层数据流图，这是一种在需求分析阶段用到的一种工具。

数据流图这一个知识点在软考中的情况
在结构化的需求分析当中， DFD 的使用频度非常之高。所以在考试当中，数据流图是一个重点考察的知识点。数据流图的题设计方面的题在每次考试当中都会考到，而且是下午设计题当中的第一个问题，考的分值是 15 分。这种题看似是考察考生的结构化分析的能力，实际也偏实践。但事实上即便你没有相应的项目经验，只要是做过大量的练习，掌握了它基本的规则与技能，这类题是能够拿高分的。因为在考察的时候，数据流图的题考察非常之稳定，每一次考试都会问那几个问题，比方说让大家补充外部的实体，补充数据存储，补充数据流，这是非常典型的一类问题。第二类就是根据父图、子图以及题目给出的描述，让你来查找这一个数据流图有什么样的缺陷，存在什么样的问题。这里面会用到一些方法原则，由于他出题的方式比较稳定，所以这一块是我们要求要掌握好，然后在考试当中拿到一个高分的题。

具体来讲数据流图这一个知识点，我们会讲到这么一些方面的内容。

• 数据流图基本概念：在数据流图里面会涉及到哪些图形符号，这些图形符号代表的含义是什么？
• 数据字典：因为数据字典是配合数据流图而存在的，它可以在数据流图里面起到相应的解释的职能。
• 数据平衡原则：数据平衡原则又分了两个分支，待会详细讲到，它是解题的时候一个非常重要的依据。

---

数据流图基本概念

数据流图中基本元素包括4种。


数据流
在这一个完整的图当中，用户信息就是一个数据流，非法用户信息也是一个数据流，操作请求权限不足信息，这些都是数据流。我们会用这样的一个数据流来反映数据流本身的含义，用名称来反映含义。但我们会发现在图当中仅仅只是展示了用户信息。那用户信息包含什么信息呢？包含用户编号、姓名、性别还是包含用户的编号呢？我们是不知道，这也就是为什么需要数据字典的原因。在数据字典里面，可以对用户信息这一词做良好的诠释来说明用户信息到底包含哪些信息，这就是数据流的问题。

加工
什么是加工呢？比方说图中的 用户管理、操作管理，这些就是加工。当你把它体现在程序里面的时候，它会是一个处理过程或者说函数之类的东西，亦或是说由多个函数和处理过程组成的一个功能模块。它在我们输入了数据流之后，能够把数据进行加工处理，变换，形成新的数据流，这就是加工。加工一般会用圆形或者圆角的矩形来代表。

数据存储
数据存储就是指的我们一个应用系统往往需要把一部分的数据保存起来，下一次处理再去用它。像我们的数据库就是一个典型的数据存储，它配套应用程序来使用的。当然为了能够表达相关的一些细节，我们的数据存储的粒度往往不是以数据库为单位的，是以表为单位的。而措辞在题目里面描述往往是某某记录文件或者说某某记录表之类的，这样的措辞往往就是指的数据存储。数据存储是用双横线或者说半框形的矩形来表示的，也就是一个矩形去掉一条线。

外部实体
外部实体注意它是指软件系统之外的人员或组织，还可以是其他的系统。什么叫软件系统之外的呢？你比如说我们开发一个考勤系统里面有很多职能处理的一些东西，但是操作这个系统的人属于外部实体，再比如 OA 体系里面，其他系统应跟他有交互，这都属于了外部实体。外部实体往往以矩形来表示，这是数据流图的基本的组成的情况。

数据流图基本概念在软考中的情况
之所以来讲这些东西，是因为在考试的时候考得简单的时候，他也会问到以下哪一个元素不属于数据流图的基本元素。还有题目很容易给你把 ER 图和数据流图做混淆处理。比如说数据流图当中有没有联系，我们知道在E-R里面实体是有的，联系也是有的，E-R图就是实体联系图。那么联系在数据流图里面有没有呢？没有，只有在 ER 图里面才提到了有联系用菱形表示。所以这个图示图例以及了元素是归属于哪一种工具哪一种图当中的，我们要求搞清楚。

---

数据流图的分层

数据流图又称为分层数据流图。那么这个分层是如何得名呢？又是如何去分层的呢？下面我们来看一个示意图。

在这一个示意图中，我们会发现分了顶层图、零层图以及底下的这些子图。那么它们之间的关系如何呢？

顶层图中间有一个大椭圆代表的是我们要开发的系统，两边的方框代表的是外部实体，那外部实体跟咱们的系统之间有数据的流转关系，这就形成了数据流图。但是在顶层图中能够表达的信息是非常有限的。为什么呢？它只是把整个系统浓缩为一个节点，它跟外界的交互我们能看清楚，但是这一个系统里面分哪些模块，模块之间有一些什么样的数据的交换我们是看不出来的。所以会考虑把顶层图进行细化。

细化之后形成了0层图。0层图中我们可以看到外部实体以及跟外部实体的联系的数据流是没有任何变化的，而是系统内部进行了细化，原来只是用一个节点代表整个系统，现在会把这一个节点拆分为几个节点，那这几个节点实际上就是系统当中的几个处理职能部件。然后这几个处理职能部件之间会有一定的交互，会有数据流的流转，所以会有数据流的展示。

0层图我们嫌它还不够细，所以会对加工处理进行细化，细化了就展示出当中的1.1，1.2，1.3它们之间的数据的流转情况。对于 2 和 3 这两个加工也是同样的处理机制来进行。

所以分层是从顶到下面逐层进行分解。那么这种分解的思路跟结构化的开发方法是完全匹配的。所以数据流图是作为结构化开发方法里面最为主流的一个工具。 这是分层数据流图的基本含义以及数据流图在绘制过程中它要走的基本的流程步骤，会先有顶层，再逐步细化下来，得到下面层次的基本图例。在绘制这种图的时候要注意 上一层图和下一层图或者说副图与子图要保持平衡。何谓平衡呢？后面我们会详细介绍数据的平衡原则。

---

数据字典

数据字典可以配合数据流图的使用，它对一些数据进行相应的诠释，让我们更加清楚这个数据的组成的情况如何。具体来讲，数据字典里面会包含这么一系列的符号。

举例说明
$$机票=姓名+日期+航班号+起点+终点+费用$$ 代表机票是由这一系列的元素组合而成。
$$终点=[长沙\mid 上海|北京|西安]$$ 代表航班的终点是从这四个城市当中选择其中的一个。

所以其实对于数据字典的了解，我们知道它们是干什么用的，然后再了解这些基本符号所代表的含义就可以了，是不需要去深究的。

---

数据流图平衡原则

平衡原则有两个维度，一个维度是父图与子图之间的平衡，另外一个维度是子图内部的平衡。

父图与子图之间的平衡
顶层图被细化形成0层图，顶层图是父图，0层图是子图。但是在细化的过程中，有部分数据流丢失或遗忘了，我们就可以利用父图与子图之间的平衡的平衡原则找出丢失或遗忘的数据流。下面我们以两个图为实例来看待这个问题。

在图一当中展示的是顶层数据流图。我们可以看到这个图当中数据管理中间件其实就是我们要开发的这一个系统，前端应用、数据管理员、后端数据库是外部实体，外部实体和开发的系统之间有着数据的一些流转。

在解题的时候往往就会问到根据题目给出的信息，要我们来补充0层数据流图所缺失的数据流，亦或是顶层数据流图缺失的数据流，这个时候我们就可以利用到平衡原则。找零层图缺失的部分时，我们先看顶层图在哪些实体和系统之间有哪样的一些数据流，这些数据流有没有在零层图中出现。反过来分析再看零层图里面出现的数据流对应的有没有在顶层图里面出现，当然这类数据流必然是系统和外部实体之间的联系。因为内部的数据流，比如说加工和加工之间的数据流在 0层图里面 有在顶层图里面是体现不出来的。比如说格式检查和权限验证之间有用户信息操作这一块的数据流，在顶层图这种数据流是展示不出来的，因为它是在数据管理中间件的内部。再比方说前端应用向管理的数据管理中间件发出了操作请求，这样子在0层图当中，前端应用应该也会要有一个操作请求，它指向的是数据管原理中间件，当然在0层图中指向的是数据格式检查。为什么两个图不能保持一致呢？因为在零层图里面是把数据管理中间件进行了细化，细化成了它内部的一系列处理职能，包括用户验证呐、用户管理、操作管理、权限管理、连接管理、格式检查权限验证，都是属于数据管理中间件的。所以这仍然表示的是一致的。所以在检查这种数据流匹配的情况，既要检查箭头所指的方向，也要检查箭头方向也不能够出错。所以说在零层图里面是缺失了 处理后的操作结果。通过这种方式我们可以找出缺失的数据流，这就是父图与子图的平衡。

子图类平衡
对于一个数据流图的任意一个加工，它的正常的形态是既有输入也有输出。还有两种不正常的情况。只有输入，没有输出称之为黑洞；只有输出没有输入称之为奇迹。

为什么这两种情况属于不正常的呢？
原因很简单，你加工是为了得到我们需要的信息，相当于把数据加工成信息得到结果。如果说这个加工是没有结果产生的，那必然是错误的，因为它没有起到它的作用。而一个加工只有输出，没有输入称之为奇迹，因为这是不可能的事情，一旦出现这种事情肯定是有问题的。没有给你输入数据，你如何加工出数据来了，加工出信息来。所以说这是不正常的。所以这两类情况一旦在图中出现，我们要意识到这是图本身出现的问题。在查找错误的时候，你要指出这类错误，有的时候甚至于要你补充到底是缺了哪一个数据流起点是什么、终点是什么？数据流名称又是什么？

---

数据流图试题解题技巧

数据流图的答题有两个方面的依据，这两个方面的依据是值得我们特别注意的地方。

详细分析试题说明
一个是详细分析试题的说明，这会成为你解题的一个重要依据。
思考题：数据流图是怎么来的呢？
数据流图作为一种建模的工具，它是这样子来的。首先我们会有需求的分析，需求分析的一系列的成果表现为文字的一些描述。然而文字描述往往是比较抽象，尤其对于非专业的用户而言，你要从繁杂的文字描述里面把逻辑关系理得非常清楚，是一件很困难的事情。所以人们就提出了数据流图,用图例的方式简单直观地展示需求分析的一些成果，甚至于是在需求分析过程之中用来与用户探讨大家的意见是否一致。所以它会比较直观。从这样的描述里面，我们也可以看出，数据流图它的原始依据是一段文字描述，图就是依据文字描述的理解来把图绘制出来。所以在一个题当中，我们要求出哪些数据流是缺失的，哪些数据流有问题有错误，题目的题干部分是重要的依据。因为图就是依据这些文字画出来的。所以我们会发现在解题的时候，实际上我们能够把每一句话都把它对应到图里面来，有着一一对应的关系。如果说你有这种思路去解题，你会发现找出答案会比你天马行空的分析要强得多。

比如对图中的说明进行分析，“数据库的管理员可通过中间件进行用户管理、操作管理和权限管理”从这一句话中分析出数据管理员它会是一个外部实体，为什么它要来操作这个中间件呢？这个中间件就是我们要开发的这一个软件。而与此同时，中间件里面会有什么东西呢？会有用户管理、操作货管理、权限管理这些加工，因为他讲通过中间件来进行什么样的处理，说明中间件就包含这些职能了。然后用户管理维护，用户信息存储在用户表里面，说明用户表它就是一个数据存储。接着看我们会发现后端数据库它也是一个外部实体，而且后端数据库应该跟操作管理这一块是有着相应的联系。所以我们可以尝试用这种思路来详细分析题干的说明部分，这里面蕴含了大量信息，对我们解题是有着直接的影响。所以详细的匹配说明和图形是非常有价值与意义的一个答题技巧。

利用到数据平衡原则
第二个方面是利用到数据平衡的原则来进行判断顶层图里面有哪些数据流，它们的流向如何；在零层图里面能不能够找到对应的数据流，它们的流向和它们的描述是否一致，这是需要去重点检查的部分。因为一旦你重点检查这些内容，就会发现里面可能有方向的错误，有数据流的缺失，这两大依据是解数据流图题的最重要的部分。这是这样的答题技巧，后面我们就会以实例来说明这些答题技巧到底如何应用到我们解题的实践过程中来。

---

数据流图案例分析1

下面我们开始讲解这一个题。讲解之前请大家回忆一下我在讲解题技巧的时候有哪两大解题技巧。第一个就是要详细的阅读题干的说明部分，因为这一些说明部分是整个题目当中图的依据，图就是根据这些描述画出来的。第二点就是要巧妙地去利用平衡的原则来找出相应的错漏之处。

首先看题干的说明部分。某大型的企业数据中心为了集中管理控制用户对数据的访问，并支持大量的连接需求，要建立数据管理中间件。它的功能包括多个方面。相当于我们解题的时候第一遍是大体的看结构好。然后题目指出，图 11-1和 11-2分别展示了顶层数据流图和零层数据流图给出了两个数据流图题目的问题要求。

这类题会给出哪些常见问题呢？
问题 1 和问题 2 是属于写实体名称，数据存储名称属于第一类，第二类就是补充数据流的。那第三类大概一般出现这种问题，两到三分 纯概念类型的问答题作为补充加进来的，有的时候会出现有的时候不会出现。

【问题4】在绘制加工的时候可能会出现什么问题呢？
①这个加工本身就不合格。
②③数据流它就没有平衡。比方说我们之前讲到的黑洞情况和奇迹，就是典型的两种错误。第一种黑洞有入，但是没有出。第二种，奇迹有出，但是没有入。这算成两个问题。
④数据流命名的问题，比如说输入流和输出流一样的，那就让大家难以感觉到他们的差别。或者说输入流经过加工根本就不可能产生这种输出流。
像解决这类问题，我建议大家是先从的问答类型的题着手，因为它跟题干关系不大。然后通过思考回顾概念，能够让你对数据流这一个相关的东西有更清晰的一种理解。

【问题1】通过题目分析，可知该问题就是要找外部实体
外部实体的 E1、E2、E3 要找的时候主要依据来源于哪里呢？题干的说明部分，通过阅读说明部分可以得到线索。

（1）因为数据管理员跟数据管理中间件进行交互，这说明了数据库管理员它是属于开发的系统以外的角色，它可以被认定为是外部实体。但是我们不知道它是哪个外部实体，因为E1、E2都有用户信息。那么我们接着向下来看。因为当你无法判别的时候，可以考虑把其他的外部实体都标识出来，那最终就能够判断出排除法来判断出最终的结果。
（2）（3）中间件验证前端应用提供的用户信息，说明前端应用与中间件也会有交互，而且也涉及到用户信息，若验证不通过，则返回非法用户信息。那么我们可以断定前端应用对应的是E1。
（4）第三个外部实体是后台数据库，这就需要有一定的中间件的这种理解来讲，因为中间件是属于什么样的一个东西呢？它工作于操作系统之上，在应用之下。然后像有数据库，中间件是专门进行数据的一些交换，中间件部分是不包含后台数据库这个部件的。所以后台数据库也是属于这样的一个外部实体，然后从后面的执行操作并将结果返回给中间件。

所以通过这样一系列的分析，我们就可以进行准确的定位了。E1是前端应用，E2是数据管理员，E3 是后端的数据库。

【问题2】找出数据存储（文件）
问题2通过零层图来解决。在找这一个数据存储的时候，大家一定要记得一些关键字，什么关键字了。数据存储一般的描述要么是某某表，要么是某某文件，这是值得注意的。然后你找出这些表，这些文件，知道这些就是数据存储之后就要给他定位。D1，D2，D3哪一个是用户表，哪一个是操作表，哪一个是权限表呢？那就要看描述结合0层图可知，D1是用户表，D2是操作表，D3是权限表。

【问题3】求加工P的名称以及输入输出的流
我们进行判断的时候，会要考虑了在整个图里面，在整个图里面缺失了哪些数据流。然后根据题干的描述内部又缺失了哪些数据流，要做这样的判断。比较容易的判断的是先看对外的数据流缺了什么，缺的很可能就跟 P 相关，很可能跟 P 相关。经过对比，我们会发现缺失 后端数据库$\stackrel{操作结果}{\to }$数据管理中间件，还缺了数据管理中间件$\stackrel{处理后的操作结果}{\to }$前端应用。最后0层图中还缺少两条数据。通过题干分析可知，一条是从D2操作表到权限验证的数据流，另一条是从 D3权限表 到 权限验证的数据流。为什么缺这两条呢？因为在权限验证的时候要用到这两个表当中的相关信息，而目前没有的话是没有办法完成权限的验证，这是这样的一个问题。所以一个问题把它搞懂了，其实一类问题应该也就会解决了。

---

数据流图案例分析2

【问题1】定位E1、E2、E3这三个实体对应的分别是什么？
（1）信用卡的申请。从确认函拒绝函我们可以了解到E1所对应的应该是非信用卡客户。
（2）信用卡激活流程。“CCMS会将激活通知发送给客户”，所以从这里咱们可以看出E2是信用卡客户。
（3）在返回的前面我们可发现如果信用卡申请被银行所接受，银行也很有可能是我们需要找的这一个外部实体之一。因为银行不在这个系统之内，但是跟系统有交互那如果说银行引入进来，它必然会涉及到 信用卡的申请信息以及信用卡申请验证的结果。我们来看一看银行是不是起到了相关的职能。像信用卡是否批示，最终的申请是由谁来审批呢？是看银行是否接受。所以E3应该是银行。

【问题2】需要指出缺少的三条数据流的起点和终点
那解决这个问题依据是什么？其实就是把这一个描述和图结合起来看，逐个地进行分析。
E1到P0，信用卡申请表。E2到P0，激活请求。P0到E2，交易信息。

【问题3】指出两条错误的数据流的名称并予以修正
数据流是错误的原因可能有多种，比方说数据流名称不对、数据流的起点或终点不对，这都是问题。所以我们要逐个进行分析，分析的依据是什么呢？其实也就是进行相应的匹配工作。通过把顶层图和0层图进行比较，然后发现一些问题。
第一个错误的地方应该是 信用卡申请表，起点是E1，终点是P4。第二错误的地方是 激活请求，起点是E2，终点是P3。

【问题4】填充 P1，P2，P3，P4加工的名称
P1是交易信息查询，P2是信用卡客户信息管理，P3是信用卡激活，P4是信用卡申请。
我们只要看进行的几个处理，它涉及到的数据流的名称，从题干说明的文字部分是可以看出来，所以解决这类问题我们会发现是一个萝卜一个坑，每一个信息都能够有一 一对应的关系的。

---

第十一节.数据库设计

数据库设计这一个知识点在软考中的情况
在数据库的基础知识里面，我们主要花很大的篇幅去讲到了这个数据库的规范化这一块哪些内容。在这一个章节当中，我们主要把精力会放在 E-R 模型以及关系模式这一块的设计方面，与基础知识部分的内容侧重是不一样的。与此同时，我们还会讲到对于这类考题解答的一些技巧。因为在考试的时候，每一次考试都固定会有一个题是考数据库设计，这个题里面涉及到的内容主要是E-R型、E-R模型转关系模式以及关系模式的相关的一些知识。所以我们会从这些主题来展开，最后会讲到一些例题，通过例题来说明这类题应该如何思考、如何分析、如何解答。

---

数据库设计过程

需求分析阶段
在需求分析阶段，我们将应用到数据流图、数据字典这些工具，在任一个阶段完成之后会形成需求规格说明书，这就是需求分析。

概念结构设计阶段
所谓概念结构设计，实际上主体的工作就是完成 E-R 模型的建模工作。 E-R 模型它是实体联系模型，也是用户的数据模型，这种模型跟 DBMS 无关，也就是跟具体的数据库管理系统是没有关系的。你完成 E-R 模型的设计是可以把 这个 E-R 模型通过转换，最终得到和该模型匹配的 success 数据库，也可以得到 MySQL 的数据库，也可以得到了 Oracle 的数据库，这都是可以的。这个层次还是跟数据库管理系统没有直接关系。

逻辑结构设计阶段
逻辑结构设计阶段是我们之前所讲到的规范化理论施展他才华的空间。主要的关系模式的一种表现形式就是 前面是关系模式的名称，后面有一个括号，里面写上关系模式里面所包含的一系列的属性。如：学生表，学生(学号、姓名、年龄等等一系列信息)，这就是关系模式。关系模式是逻辑结构设计的产物。关系模式是怎么来的呢？是通过对 E-R 模型进行转换得来的。

物理设计阶段
物理设计阶段就会把数据库管理系统也就是 DBMS 以及硬件操作系统，这些特性都考虑进去，最后形成实实在在的数据库，这是物理设计。

总结
所以整体的数据库设计要经历这些过程，每一个过程有什么特点，有什么产物这些东西是要求要掌握的。比如说概念结构设计阶段，产物是 E-R 模型， E-R 模型又指导逻辑结构设计，有这样的关系在里面，这是整体的数据库设计的过程。

---

E-R模型

实体类联系类型
在E-R模型当中，实体类联系类型包括三种，一对一的联系、一对多的联系、多对多的联系。

1：1的联系
举例说明，比如说 部门和部门经理，一个部门假定只允许有一个部门经理，那么部门和部门经理这个关系就是属于一对一的形式。

1：n的联系
举例说明，比如说 部门和部门的员工，因为一个部门可以有多个员工，所以每一个部门会对应多个员工，而一个员工只能对应一个部门，所以部门和员工这个关系就是属于一对多的形式。

n：m的联系
在这一个超市进行货物流转的过程中，一种货物可以被多个人购买，而一个人又可以买多种货物。那么这种情况就存在着多对多的关系。

---

E-R图向关系模型的转换
转换的基本原则是：实体和联系分别转换成关系，属性则转换成相应关系的属性。

一对一、一对多以及多对多，它有着不同的转换原则。从两个维度进行分析（即两边分析）。
1：1的联系
方法一：将联系单独转换成一个关系模式，联系中的属性为联系本身的属性和两端实体集的主码。而该联系的主码是两个实体集的主码之一，哪个都行。
方法二：将联系与某一端实体集所对应的关系模式合并，则需要在被合并关系中增加属性，其新增的属性为联系本身的属性和与联系相关的另一个实体集的主码。

1：n的联系
方法一：将联系单独转换成一个关系模式，联系中的属性为联系本身的属性和两端实体集的主码。而该联系的主码是n端实体集的主码。
方法二：将联系与n端实体集所对应的关系模式合并，则需要在被合并关系中增加属性，其新增的属性为联系本身的属性和1端实体集的主码。

n：m的联系
联系的属性为两端实体集的主码以及联系本身的属性，联系的主码为两个相连实体码的组合（该码为多属性构成的组合码）。

---

数据库设计答题技巧

这一块的答题技巧主要有两个方面。

详细分析试题的说明
即通过说明找相关的线索来解题。

熟练掌握基础知识
因为数据库设计现在考察的内容也是相当稳定的，无非就是 E-R 模型的补充、E-R模型转关系模式、关系模式补充以及一些其他的概念方面的问题。

数据库设计的题其实也类似于数据流图的题
因为数据流图里面也有一一对应的关系。而数据库当中的 E-R 模型也有类似的关系，因为它也是把文字性的东西转成了图形化，但也只是说E-R模型是数据方面的建模，而数据流图是功能方面的建模仅此而已。

---

数据库案例分析1

【问题1】根据题干分析(1)~(3)的联系的模型
（1）题目中“一个员工只能属于一个部门”，再根据常识可知一个部门可以有多个员工，所以这一空的关系是一对多的。
（2）（3）“预定信息必须仅对应一位客户，但一位客户可以有多条预定信息”。预定的是客房，那么应该是客房和客户之间进行对应，这个题干就是在误导你的，所以一个客户可以预定多个客房，一个客房可以有多个客户预定，因为你不能够说咱们的客房被某个人预定过一次，然后就不能够被其他客户去预定的，对不对？只要时间错开就是允许的。所以应该是一个多对多的关系。

【问题2】要求补充联系，并指明联系的类型是怎么样的
在这一个图当中，我们会发现权限它跟任何其他的实体都没有关联，这是很不正常的情况。一般都会与其他的实体有一定的关联性，所以这种会作为重点考虑对象。那权限具体跟谁会有联系了？那就要看权限它是给谁用的，谁会拥有相应的权限。这里面毋庸置疑应该是员工。因为我们回到题干里面可以看到，其实员工是分管理和服务两种，不同的岗位拥有着不同的权限。所以说权限应该跟员工是相关的，不同的岗位会有不同的权限。那这样子把两者给它关联起来。关联起来之后，这种关联一般是不要求我们写具体的关联的名字的。但是它的这个几对几的关系是要表明的。一个员工拥有一种权限，因为一个员工拥有一种岗位，一个岗位对应一种权限；一种权限对应多个员工；所以是一对多的关系。

【问题3】将E-R模型转成关系模式需要考虑的问题
（4）员工关系模式缺少主码员工号，当然还有所属关系没有单独显示一个关系模式，所以联系的关系模式肯定在员工中，故这一空填员工号和部门号。（5）填写客房号（6）填写身份证号（7）一对多关系模式，联系中应该包含两端的主键，故填写岗位。

【问题4】权限跟员工是多对多关系，联系是一个单独关系模式，也就是问为什么多对多的联系要独立成一个关系模式呢？
这里其实考察的是规范化理论，因为把这两者放进来其实是在做逆规泛化的操作。那么这样子做下去我们会发现操作权限的描述，它会重复的存很多次，这就不可避免的造成了数据的冗余。
那么从优点的角度来看，就是减少了一次连接操作。因为如果说你把权限这一块的信息拆成一个表，那我们要去获取这一个权限操作码的话，是需要进行连接操作的，这往往会比较费时。所以在把这一个表的内容汇总到员工表之后，就减少了连接操作，查询起来速度会要快一些。
但是弊端 就是重复的存储，存在数据的冗余这种情况。

---

数据库案例分析2

【问题1】完善实体联系图
涉及到的实体是 商场、部门、经理和员工。其中员工和经理之间是存在一些联系的，即员工包含经理。所以员工和经理之间是一种特殊化关系，用一个线画一个圈，一般还会加上两条竖线这样子来展示，这就代表经理是一种特殊的员工。一个部门会有多个员工，一个员工属于一个部门，所以员工和部门是一对多的关系。每个商场包含不同的部门，一个部门只能够属于一个商场，所以部门和商场是一对多的关系。部门与经理之间的关系，我们最好也核实一下一个部门是不是能够允许多个经理结果经过核实会发现一个部门的员工中有一名是经理，每个经理只管理一个部门，所以经理和部门是一对一的关系。

【问题2】补充关系模式
（a）商场编号。因为商场跟部门是一对多关系，两者联系是合并到n端(部门)，所以n端需要有商场的主码商场编号；再看另一边部门跟员工形成1：n关系，部门是1端不能跟联系合并；因为经理是员工的子类，所以不用写（b）部门编号。因为员工跟部门是一对多关系，联系需要放在员工的关系模式中（c）员工编号。因为经理是一个实体，所以实体必须要有主键，主键的要求是能够唯一的标识元组的键，所以是员工编号。因为经理属于员工，而员工已经填写了部门编号，所以如果经理关系再填写部门编号就会出现冗余。

主键的要求就是能够唯一的标识元组的键。在部门关系当中，部门编号能够唯一标识元组，所以它是主键。在员工关系当中，员工编号可以唯一标识元组，所以员工编号是员工的组件。在经理关系当中，员工编号能够标识元组，所以也是员工编号。

外键的要求就是其他关系的主键。比如说在部门关系当中的外键就是商场编号，因为商场的主键是商场编号。在员工关系当中的外键就是部门编号。在经理关系当中的外键就是员工编号。外键往往是用来把当前这个关系和别的关系进行关联操作的时候用到的。

【问题3】添加一个实体并更新关系模式
添加的实体就是紧急联系人。因为一个员工只能登记一位紧急联系人，一个紧急联系人可以有多个员工，所以员工跟紧急联系人的关系是一对多的关系。我们要想知道该实体的关系模式，就需要知道紧急联系人的属性。紧急联系人的属性至少包含 员工的编号（一个实体需要有一个主键）、紧急联系人的姓名、紧急联系人的电话。紧急联系人(员工的编号，紧急联系人的姓名，紧急联系人的电话)

---

第十二节.UML建模

UML建模这一个知识点在软考中的情况
UML建模题在考试的时候是稳定的会出一个。但是由于 UML 涉及到的图比较多，所以在考试的时候这种题比前两道题也就是数据流图的题和数据库的题难度要略高一些，因为有变化，同时要掌握的知识面也会要广一些。因为你要掌握多种图的一些基本的信息，所以这类题要把握起来，难度相对来讲会要高一些。但是值得我们注意的是，通过对历年的考试进行严整的分析之后，我们会发现 UML 的考察一般情况都会涵盖用例图、类图这类常见的图，再附加一些其他方面的图。所以我们掌握相关的知识的时候，首先要把用例图、类图搞熟悉，这里面固定的一些考察的题型要知道如何解答，然后再花时间去熟悉其他类型的这一系列图。所以在本章我们会讲到常见的这一系列的 UML 图的基本情况，然后会以实例的方式来说明哪些点是值得我们注意的。这样子大家在练习了几个题之后会发现 UML 的题要把握起来也不是那么的困难，只是说比前面的数据流图题和数据库的设计题难度要略高一些。

UML图有 用例图、类图与对象图、顺序图、活动图、状态图、通信图、构件图。

---

用例图

用例图使用户 与开发人员交流的一种重要的方式，是对用户需求的一种描述。开发人员从用户的角度整体上理解系统的功能。

用例图在软考中的考察方式
在案例分析题这种类型的题当中，所考查到的用例图主要是考两个方面的内容。
第一种考察方式就是题干里面有关于项目的详细描述。在考试的时候会把一个完整用例图当中的某些参与者和某些用例给它抠掉。抠掉之后，让大家根据题干的内容以及用例图的已有的结构来分析哪个位置的用例是叫什么名称，哪个位置的参与者对应的是哪样的一个角色。这是了非常典型的一种考察方式。

第二种考察方式就是要根据题目的意思来分析两个用例之间它是什么样的关系，是包含关系还是扩展关系亦或是泛化关系。

那么这个两个方面的知识，对于参与者和用例的识别，往往是通过分析题干，紧扣题干，然后做一 一的匹配。
当然前提是大家要知道在用例图中基本的图例所表达的含义这一点是必须要知道的。

用例图主要有三种元素：参与者（Actor），用例，以及用例之间关系。其中包含、扩展是用例图中特有的关系，泛化在其他类图中同样存在。

上图含义分析：左边小人符号代表参与者，然后用箭头指向各个用例，代表这个参与者会使用到这些用例。

举例来说明第一类考察方式的解题思路
现在我们把新增书籍信息和查询书籍信息两个用例扣掉之后，我们根据现有图例分析两个用例分别在什么位置上？往往需要通过什么样的方式来分析呢？
往往需要通过分析用例之间的关系。图中其中一个空位置涉及到一个扩展关系。那我们就要看新增书籍会不会涉及到扩展关系？而查询书籍又会不会涉及到扩展关系？这样子来对比来分析哪个位置是新增书籍信息用例，哪个位置是查询书籍信息用例。这是对于第一种考察方式的解答，和我们之前讲的数据流图和 E-R 模型求解相关问题的思路是一致的。

包括关系
包含关系是用 include 这种关键字来表达。
当能够从两个或两个以上的用例中提取公共行为时，应该使用包括关系来表示它们。

扩展关系
扩展关系是用 extend 这种关键字来表达。
假设一个用例明显的混合了两种或两种以上的不同场景，即依据情况可能发生多种分支，则能够将这个用例分为一个基本用例和一个或多个扩展用例，这样使描写叙述可能更加清晰。

泛化关系
泛化关系是用空心三角箭头指向父类。
当多个用例共有一种类似的结构和行为时，能够将它们的共性抽象成为父用例，其它的用例作为泛化关系中的子用例。

注：泛化是反继承，也就是说父类是子类的泛化，子类是父类的继承。

包含关系和扩展关系两者区别在哪里呢？
下面通过实例进行说明。
包含关系。比如说 登记外界信息用例 会使用到用户登录，而且必然会使用到，意思就是你要登记外借信息，必然先要登录。那登记外借信息包含用户登录。
扩展关系。比如说 查询书籍信息用例，我们查询书籍就直接查，但是在查询的过程中发现信息有错误，那么那么我就需要修改。那修改书籍信息就是查询数据信息的扩展。其中查询用例必须执行，修改用例看情况执行。那么这就是一种扩展延伸的扩展。
所以要判断是包含还是扩展，关键在于是否必须。就像我们平常所接触到的 ATM 取款机一样，在以前取完款之后，吐凭条是必须的默认的选项，每次都会吐的，不管你怎么样他都会吐，没有给你选择的机会。那说明取款用例包含了打印凭条的用例，但现在改了，取完款后，他会问你是否要打印凭条，你可以选择是也可以选择否？换句话来讲，你可以打印出凭条，也可以不打印出凭条，这打印凭条就不是必须的了，有选择的空间呀。那这个时候打印凭条就变成了一个扩展用例，它们的关系就发生了变化。

---

类图与对象图

类图与对象图主要考察的内容是这三个方面

填类名，方法，属性名
主要是填类名，要根据题干给出的信息。然后来确认在一个类图当中哪一个类的类名是什么。就好比上图，咱们要把书籍列表、书籍借阅记录列表这些都把它删掉。然后你知道有这么几个类名或者说对象，又知道他们之间的关系，然后来分析哪个位置应该是哪一个类，这是最为常见的一种考察形式。其次就是方法名和属性名，这个概率比较低。

填多重度
填多重度 就是把图中多重度的位置给挖掉，让大家来填写。多重度有多种表达方式。

填关系
关系包括依赖、泛化、组合、聚合和实现。其实真正要我们了解的只有泛化、实现、组合、聚合，依赖很少考。实现是对接口来的，泛化是对类来的。所以它们的箭头都是空心箭头，只是了泛化关系用的是实线，实现关系是虚线而已。组合关系和聚合关系都是以菱形来表示的，只是组合关系是实心的菱形，而聚合了是空心的菱形。

• 泛化 (generalization) 关系是一个类（称为子类、子接口）继承另外的一个类（称为父类、父接口）的功能，并 可以增加它自己的新功能的能力，继承是类与类或者接口与接口之间最常见的关系。
• 关联 (association) 关系：表示类与类之间的联接，它使一个类知道另一个类的属性和方法。
• 聚合 (aggregation) 关系：关联关系的一种特例，是强的关联关系. 聚合是整体和个体之间的关系,即has-a的关系，此时整体与部分之间是可分离的，他们可以具有各自的生命周期，部分可以属于多个整体对象，也可以为多个 整体对象共享。
• 组合(合成)关系 (composition)：也是关联关系的一种特例，他体现的是一种contains-a的关系，这种关系比聚合 更强，也称为强聚合；他同样体现整体与部分间的关系，但此时整体与部分是不可分的，整体的生命周期结束也就 意味着部分的生命周期结束。

---

顺序图

顺序图它最大的特点就是 处理事务的时候，它的时间顺序情况一步一步走下去。

顺序图有这么一些基本的组成元素。顶端一般写对象，然后每个对象都需要引出一条生命线，用虚线画下来。整体的流程的执行顺序是从上往下走，其中箭头上标号的函数就是一个处理过程。第一步：cardInserted()插入卡片，第二部：create(this)创建相应的session，依次类推。然后箭头表示对象之间进行相应的交互，即消息；箭头的方法表示从谁到谁来发送相应的消息。以第一个消息为例，实际上是 CardReader(读卡器)向 ATM 系统发送了相应的消息。

顺序图在软考中的考察方式
它的核心点放在“消息”上面。因为顺序图它已经是一种动态图了，动态图表现的是对象之间的交互关系。所以往往会把顺序图当中的某些消息给它抠掉，也就是空出来，让你根据处理的流程来分析上图的6 号消息是干嘛的，7号消息又是在做什么的？所以这需要我们依据题目给出的描述，然后根据前面已有的 1、2、3、4 条消息，以完成的任务综合来分析，看后面还有哪些步骤要走。当然即便是让大家填这些消息，往往也已经把专有的这些消息的名称都已经列出来了，相当于做选择题一样的，让大家选合适的词来填到这个位置来。其次填对象名，主要是考察这两个方面的内容可以了，顺序图的考察往往还是比较简单的。

---

活动图

活动图是一种从结构来讲和程序流程图非常接近的图。这种图能够表现整个处理流程的基本情况以及分支的状态。

上图所示，首先用户下订单然后从一根粗的横线引出分支，一方面是生成送货单，另外一方面是用户选择支付方式。在支付方式选择这一块后面有一个菱形，这个菱形只是一个判断分支。如果说判断为真如何，判断为假又如何？这种结构跟程序流程图是保持一致的。另外那个粗横线代表的是什么含义呢？代表的是从粗横线这个位置产生了多少个并行的线程，从这里我们可以看到产生了两大分支，然后在下一个粗横线的位置它们合并了。所以这里就产生了两个不同的线程。

当然还有分成带泳道的活动图，带泳道的活动图里面只是添加了不同的对象。这样子划分出来之后，我们可以更加明确哪个活动是归属于谁，谁有它相应的责任人，所以称之为带泳道的活动图。

活动图在软考中的考察方式
对于这种图，我们需要了解一个流程和图的对应关系，然后抠出一些空，我们是否能够给它还原的问题。所以其实所有的图要解决的问题是类似的，都是把完整的图抠掉一部分，让你填充进去。所以要解决的时候应对机制也是一致的，那就是根据描述来尝试着自己来画这个图，自己画这个图会怎么画再跟这样的一个标准的图例进行匹配，看哪些位置应该有哪些操作，哪些动作。

---

状态图

状态图它所表现的是状态的变迁，所以把状态图也归为动态图。所以在状态图中往往是以状态为节点。我们可以看到下图有 Off、On 这都是状态。那么箭线代表的是什么呢？是触发事件，从某一种触发状态进入到另外一种触发状态，从而导致状态的变迁。这就是状态图。

状态图在软考中的考察方式
题目往往会给你一个系统描述，描述的过程中会涉及到多种状态的变迁。然后会把这个状态图抠掉，抠掉之后让大家来填充状态以及状态变迁的条件。先根据系统描述识别总共会有哪几种状态，然后一种状态到另外一种状态，需要什么样的条件把它列出来，从这种状态回到先前的状态，又需要什么条件也列出来，最后把这些东西转化成图形，结果自然也就出来了。

状态图以前就考过，就是会员的升级和降级的一些制度就可以用状态图来表现。比如说有普通的会员，有银卡会员，有金卡会员，有钻石卡会员。那么积分要达到多少才能够升级？比如说你不是会员，现在有 2000 积分能够升级为会员，有 5000 积分能够升级为银卡会员，再有 3000 积分能够升级为金卡或者说累积 1 万积分到金卡之类的这种升级制度的话，状态图表现是非常好的，能够清晰地把这些流转关系理清楚，这是状态图。

---

通信图

通信图又称为协作图，它其实是顺序图的另一种表达方式。

那顺序图是上面的一排是对象，通过对象引出相应的生命线。对象之间的交互在生命线上面以顺序的方式表达消息的传递，通过这种方式来让人清晰细的了解到整个流程它的执行顺序是怎么样的，会涉及到哪些对象，哪些对象参与什么样的一些操作，达到这样的一个效果。

通信图也是类似的，只是我们会发现这里展示到的通信图它已经和我们之前所讲的顺序图结构有了非常大的变化。它的对象就是一系列的节点，对象的交互还是通过箭头的方式来标识消息，消息仍然在箭头旁边进行标注。所以它和顺序图相比时间方面没强调的那么明晰，其他方面基本上保持一致。所以我们也把顺序图和通信图统称为交互图。

通信图在软考中的考察方式
在考试的时候一般会把这一个对象抠掉一些，把这些要传递的这些消息抠掉一些，然后做成填空题，让大家来回答。同时我们需要了解到通信图和顺序图，它们之间的差异主要就在于顺序图会强调时间顺序，了解这些方面的内容就可以了。

---

UML案例分析

我们在解题的时候要大致的浏览一遍题干，浏览之后再看问题，然后结合问题详细地看题干，这样子目标性会比较强，看到的信息也会不一样，因为你的关注程度不一样，某些细节可能就会注意到了。

【问题1】填写相应类名的问题
把这些类名定位到类图中的依据是什么呢？依据就是题干部分所描述的类与类之间的关系。当然在具体看题干之前，我建议大家先把这些类名熟悉一下。要对类名有一定的敏感度。当你看到题干描述当中的艺术家的时候，歌曲乐队歌手这一系列的信息，你要知道这是我们在建模过程中所用到的一系列的类。同时建议大家在看这些描述的时候，就把这些类名在描述里面给它标识出来。看完这一个基本信息之后，我们回到类图，从类图可以发现有这么一些关系存在，有继承关系，也有泛化关系，还会有聚合组合这样的一些关系。这就是我们关键解题的关系。为什么这么讲呢？因为这些特殊关系就决定了哪些地方必然是只有可能是哪些类。所以我们有必要把这些关系呢从描述里面抠出来来看待。首先有的这一个继承关系是非常具有代表性的。为什么有代表性呢？因为在整个的题干描述当中，只有一个地方存在这种继承的关系就是艺术家，它分为乐队和歌手，歌手乐队都属于艺术家。所以艺术家和歌手乐队之间就存在着相应的继承的关系。艺术家是父类，而歌手和乐队应该是子类，C和D存在聚合的关系，既然是聚合关系，那么哪一边是乐队，哪一边是歌手呢？注意看这个符号的位置，菱形代表了整体这一方， 所以 C 是整体这一边，而 D 是组成部分，所以 C 是乐队，D是歌手，A是艺术家。根据题干描述编写和演奏歌曲都是由艺术家来完成。所以B是歌曲。因为唱片由多条音轨构成，音轨上面只包含一首歌曲或空，聚合强调相似的东西聚合到一起，组合强调多个不同类型的部分组成了一个独一无二的全体。所以E是音轨，F是唱片。

【问题2】填写多重度
（1）0…* （2）2…。因为C是乐队，D是歌手，乐队是由2个或2个以上的歌手组成的，一个歌手可能不属于0个或多个乐队。从两个角度来看待问题和分析问题。（3）0…1（4）1…。因为B是歌曲，E是音轨，一个音轨只包含一个歌曲或空，一首歌曲分布在多个音轨上。（5）1…*（6）1。因为E是音轨，F是唱片，每张唱片由多条音轨构成，一条音轨中只包含一首歌曲或者为空，并且同一首歌曲在一张唱片中最多只出现一次，说明一张唱片包含一条音轨，这里不能说是0条，否则就没有意义了。再说了如果是0条，题目中就会告诉你的。

【问题3】填写缺少的关联
缺了观点要从哪里分析呢？要分析整个题干。这两个段落的内容其实已经都表现在图里面了，我们都能够找出一一对应的关系了。继续往底下看，会发现每一条音轨都有一个开始的位置和持续时间，一张唱片上音轨的次序是非常重要的。因此对于任意一条音轨播放器都需要准确的知道它的下一条音轨和上一条音轨是什么。那这样子的话就会存在着相应的联系了，因为一条音轨要跟它的上一条或下一条音轨建立相应的关联。那说明音轨和自己有一个联系，多重度都是0…1。因为题中说如果可能存在。

【问题4】根据状态图求最短序列
其实就是要找到一条路径从关闭通往播放，而且要距离最短。
一条路径是按任意键、打开框框、选择歌曲、播放状态。因为一旦歌曲被选择即进入播放状态，这是一条路径。还有什么路径呢？连接电脑之后，电量饱和或者说完成拷贝都会，到完成状态之后，断开连接，再选择歌曲再过去。所以相对来讲路径比较短的是按任意键，然后再选择歌曲就到了播放状态了，这就是最短的事件的路径。

---

第十三节.UML图的分类 2.0

UML 2.0包括14种图，分别列举如下:
(1) 类图。描述一组类、接口、协作和它们之间的关系。在面向对象系统的建模中，最常见的图就是类图。类图 给出了系统的静态设计视图，活动类的类图给出了系统的静态进程视图。
(2) 对象图。描述一组对象及它们之间的关系。对象图描述了在类图中所建立的事物实例的静态快照。和类图一 样，这些图给出系统的静态设计视图或静态进程视图，但它们是从真实案例或原型案例的角度建立的。
(3) 构件图。描述一个封装的类和它的接口、端口，以及由内嵌的构件和连接件构成的内部结构。构件图用于表 示系统的静态设计实现视图。对于由小的部件构建大的系统来说, 构件图是很重要的。构件图是类图的变体。
(4) 组合结构图。描述结构化类 (例如，构件或类) 的内部结构，包括结构化类与系统其余部分的交互点。组合 结构图用于画出结构化类的内部内容。
(5) 用例图。描述一组用例、参与者及它们之间的关系。用例图给出系统的静态用例视图。这些图在对系统的行 为进行组织和建模时是非常重要的。
(6) 顺序图。是一种交互图 (interaction diagram)，交互图展现了一种交互，它由一组对象或参与者以及它们 之间可能发送的消息构成。交互图专注于系统的动态视图。顺序图是强调消息的时间次序的交互图。
(7) 通信图。也是一种交互图，它强调收发消息的对象或参与者的结构组织。顺序图和通信图表达了类似的基本 概念，但它们所强调的概念不同，顺序图强调的是时序，通信图强调的是对象之间的组织结构 (关系)。在UML 1.X版本中，通信图称为协作图 (collaboration diagram)。
(8) 定时图。也是一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅只是关心消息的相对顺 序。
(9) 状态图。描述一个状态机，它由状态、转移、事件和活动组成。状态图给出了对象的动态视图。它对于接 口、类或协作的行为建模尤为重要，而且它强调事件导致的对象行为，这非常有助于对反应式系统建模。
(10) 活动图。将进程或其他计算结构展示为计算内部一步步的控制流和数据流。活动图专注于系统的动态视 图。它对系统的功能建模和业务流程建模特别重要，并强调对象间的控制流程。
(11) 部署图。描述对运行时的处理节点及在其中生存的构件的配置。部署图给出了架构的静态部署视图，通常 一个节点包含一个或多个部署图。
(12）制品图。描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合。制品图通常 与部署图一起使用。制品也给出了它们实现的类和构件。
(13) 包图。描述由模型本身分解而成的组织单元，以及它们之间的依赖关系。
其中类图、对象图、用例图 (后期已划分为动态图) 、组件图及配置图为静态图，其它的为动态图。

---

第十四节.补充小节

UML类图中常见的几种关系

$泛化（Generalization）,实现（Realization）,关联（Association）,聚合（Aggregation）,组合(Composition)，依赖(Dependency)$

注：关联关系包含聚合关系和组合关系

---

1.泛化（Generalization）

【泛化关系】：是一种继承关系,它指定了子类如何特化父类的所有特征和行为例如：老虎是动物的一种
【箭头指向】：带三角箭头的实线，箭头指向父类

---

2.实现（Realization)

【实现关系】：是一种类与接口的关系，表示类是接口所有特征和行为的实现
【箭头指向】：带三角箭头的虚线，箭头指向接口

---

3.关联（Association）

【关联关系】：是一种拥有的关系,它使一个类知道另一个类的属性和方法 例如：老师与学生，丈夫与妻子
【代码体现】：成员变量
【箭头及指向】：带普通箭头的实心线，指向被拥有者
关联可以是双向的，也可以是单向的。双向的关联可以有两个箭头或者没有箭头，单向的关联有一个箭头。

上图中，老师与学生是双向关联，老师有多名学生，学生也可能有多名老师。但学生与某课程间的关系为单向关联，课程是个抽象的东西他不拥有学生。

上图为自身关联：

---

4. 聚合（Aggregation）

【聚合关系】：是整体与部分的关系 例如：车和轮胎是整体和部分的关系

聚合关系是关联关系的一种，是强的关联关系
关联和聚合在语法上无法区分，必须考察具体的逻辑关系

【代码体现】：成员变量
【箭头及指向】：带空心菱形的实心线，菱形指向整体

---

5. 组合(Composition)

【组合关系】：是整体与部分的关系 例如：没有公司就不存在部门

组合关系是关联关系的一种，是比聚合关系还要强的关系
它要求普通的聚合关系中代表整体的对象负责代表部分的对象的生命周期

【代码体现】：成员变量
【箭头及指向】：带实心菱形的实线，菱形指向整体

---

6. 依赖(Dependency)

【依赖关系】：是一种使用的关系,所以要尽量不使用双向的互相依赖。
【代码表现】：局部变量、方法的参数或者对静态方法的调用
【箭头及指向】：带箭头的虚线，指向被使用者

---

总结

各种关系的强弱顺序：
$泛化=实现>组合>聚合>关联>依赖$

下面这张UML图，比较形象地展示了各种类图关系：

---

第十四节.软件质量保证

McCall软件质量模型

McCall软件质量模型从软件产品的运行、修正和转移三个方面确定了11个质量特性，其中运行方面包含了正确性、可靠性、效率、完整性、使用性这些质量特性。修正方面包含了维护性、测试性、灵活性这3个质量特性。转移方面包含了维护性移植性、复用性、共运行性这3个质量特性。