软件工程学习笔记

维护类型：

（1） 更正性维护

修改系统内未发现的错误
（2）适应性维护

适应新的软硬件环境，以提高系统的性能和运行效率

（3）完善性维护

增加一些在软件需求规范书中没有规定的功能与性能特征。

（4）预防性维护

为未来的修改与调整奠定更好的基础。例如，将目前能应用的报表功能改成通用报表生成功能，以应付今后报表内容和格式可能的变化。

根据对各种维护工作分布情况的统计结果，一般纠错性维护占21%，适应性维护工作占25%，完善性维护达到50%，而预防性维护以及其他类型的维护仅占4%，可见系统维护工作中，一半以上的工作室完善性维护。

耦合类型:

（1） 内容耦合：一个模块直接访问另一个模块的内部数据、一个模块不通过正常入口转到另一模块内部、两个模块有一部分程序代码重迭(只可能出现在汇编语言中、一个模块有多个入口。
（2） 公共耦合：若一组模块都访问同一个公共数据环境，则它们之间的耦合就称为公共耦合。公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
（3） 外部耦合： 一组模块都访问同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息，则称之为外部耦合。
（4） 控制耦合：如果一个模块通过传送开关、标志、名字等控制信息，明显地控制选择另一模块的功能，就是控制耦合。
（5） 标记耦合：一组模块通过参数表传递记录信息，就是标记耦合。这个记录是某一数据结构的子结构，而不是简单变量。
（6） 数据耦合：一个模块访问另一个模块时，彼此之间是通过简单数据参数 (不是控制参数、公共数据结构或外部变量) 来交换输入、输出信息的。
（7） 非直接耦合：两个模块之间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。

内聚类型：

（1）功能内聚（Functional Cohesion）

如果一个模块内所有处理元素完成一个，而且仅完成一个功能，则称为功能内聚。

功能内聚是最高程度的内聚。但在软件结构中，并不是每个模块都能设计成一个功能内聚模块。

（2）顺序内聚（Sequential Cohesion）

如果一个模块内处理元素和同一个功能密切相关，而且这些处理元素必须顺序执行，则称为顺序内聚。

（3）通信内聚（Communicational Cohesion）

如果一个模块中所有处理元素都使用同一个输入数据和（或）产生同一个输出数据，称为通信内聚。

（4）过程内聚（Procedural Cohesion）

如果一个模块内的处理元素是相关的，而且必须以特定的次序执行，称为过程内聚。

过程内聚与顺序内聚的区别是： 顺序内聚中是数据流从一个处理单元流到另一个处理单元，而过程内聚是控制流从一个动作流向另一个动作。

（5）时间内聚（Temporal Cohesion）

如果一个模块包含的任务必须在同一段时间内执行，称为时间内聚。也称为瞬时内聚。

（6）逻辑内聚（Logical Cohesion）

如果模块完成的任务在逻辑上属于相同或相似的一类，称为逻辑内聚。

（7）偶然内聚（Coincidental Cohesion）

如果一个模块由完成若干毫无关系的功能处理元素偶然组合在一起的，就叫偶然内聚。

多态

一般将多态分为通用多态和特殊多态。
通用多态包括参数多态和包含多态

参数多态利用泛型编程，是发散式的，是静态绑定的，让相同的实现代码应用于不同的场合，看重的是算法的普适性

包含多态利用OOP，是收敛式的，是动态绑定的，让不同的实现代码应用于相同的场合，看重的是接口与实现的分离度。

特殊多态包括强制多态和过载多态
强制多态即一种类型的变量在作为参数传递时隐式转换成另一种类型，比如一个整型变量可以匹配浮点型变量的函数参数，
过载多态同一个名(操作符、函数名)在不同的上下文中有不同的类型。程序设计语言中基本类型的大多数操作符都是过载多态。

下午部分

认认真真审题，重点部分划线，多看两遍，别偷懒，很容易丢失信息。

一、数据流图

加工时，可能出现的输入、输出错误
只有输入而无输出或者黑洞
只有输出而无输入或者奇迹
输入的数据流无法通过加工产生输出流或者灰洞
输入的数据流与输出的数据流名称相同

二、UML
在UML中，用例之间有3种关系：包含(include)、概括(generalize)和扩展(extend)。
如果多个用例中都含有相同的事件流，那么可以将其抽取出来放在一个单独的用例中，其他用例都可以通过包含(include)这个用例来使用其中的事件流。包含关系可以避免在多个用例的描述中重复拷贝相同的事件流。
概括关系是指子用例(child use case)继承父用例(parent use case)的行为，而子用例本身还可以增加新的行为或重置父类的某些行为。这种关系与面向对象程序设计中的“继承”很类似。
一个用例(基础用例，base use case)中加入一些新的动作后则构成了另外一个用例(扩展用例，extending use case)，那么这两个用例之间的关系就是扩展关系。扩展关系与概括关系有相似之处，但是比概括关系更为严格。基础用例必须声明特定的扩展点，而扩展用例只能在这些扩展点上添加新行为。
三、
程序题要注意上下文关联

四、
java和C++互相看看，查漏补缺