大二下软件工程与计算II期末总结

写在前面 ：总结内容都是期末考试内容，算是对自己辛苦总结的记录，实际上对显示编码并没有太多帮助

软件工程概述

软件工程概念

软件工程发展的六个阶段

项目启动

团队管理的方法

常见团队结构

质量保障方法

配置管理方法

需求开发阶段

需求识别：

业务-用户-系统

项目-过程-硬件-软件-其他-不切实际的需求

软件需求识别：

需求分析方法：

1. 用例图
2. 概念类图 -概念类-关联-属性
3. 顺序图 交互对象-消息-附加条件
4. 状态图 识别状态-转移触发条件即行为

软件设计

软件设计基础

软件设计定义

软件设计的核心思想

软件设计的三个层次

软件体系结构设计（基础-设计与构建）

人机交互设计

易用性的解释

设计原则：共8条

简洁设计

一致性设计

低出错率设计

易记性设计

可视化设计（包含两条）

差异性设计

导航

反馈

详细设计基础

详细设计的模块化和信息隐藏（概念及面向对象中的应用）

耦合：两个模块之间联系的复杂性

内聚：模块内部联系的紧密程度

耦合类型：

1. 内容耦合：即代码的共享，一个模块可以更改或者依赖另一个模块的代码，如goto 内部类
2. 公共耦合：变量的共享，如全局变量（直接访问成员变量）
3. 重复耦合：代码逻辑重复，出现相同代码
4. 控制耦合：模块之间传递控制逻辑而不是数据
5. 印记耦合：模块之间传递复杂数据结构且只使用其中一部分
6. 数据耦合：模块传递简单数据

内聚类型：

1. 偶然内聚：模块内操作没有任何关联
2. 时间内聚：模块内的操作有时间上的关联
3. 过程内聚：模块内的操作有逻辑上的前后顺序
4. 逻辑内聚：模块操作在逻辑上是同一种操作
5. 通信内聚：模块操作是针对同一个数据结构进行的
6. 功能内聚：只有一个操作或者所有操作完成一个单一目标
7. 信息内聚：模块内的方法之间是独立的，针对模块内的相同数据结构进行操作（ADT）

信息隐藏概念：即每一个模块都隐藏一份重要的设计决策，即自己的职责。对外表现为一个契约，其中的设计决策和决策实现逻辑都被隐藏起来。

隐藏的两类信息：模块根据需求得到的职责；内部具体实现细节。

面向对象的模块化

访问耦合的类型（关联）：一个类如何持有另一个类的引用

1. 隐式访问（级联访问）
2. 函数参数访问
3. 成员变量访问
4. 实现中访问
5. 无访问

改善时用到的原则：

1. 针对接口编程：访问时要访问接口，不进行直接属性访问
2. 接口最小化原则：避免接口实现类实现了其他类用不到的方法。所以接口方法的创建根据实际类使用的情况创建，只创建用得到的方法，接口适当缩小。
3. 迪米特法则：避免级联访问对象。当对象的方法返回另一个对象的引用时，不能级联访问。即要委托执行。

继承耦合的类型：

1. 修改规格：子类任意修改父类的接口（如删除接口）
2. 修改实现：子类任意修改父类的实现方法
3. 精化规格：子类按照特定（相同与父类的）语义修改父类的接口
4. 精化实现：子类按照特定语义修改父类的实现
5. 拓展父类接口或者属性
6. 无继承

改善时用到的原则

1. 里氏替换原则LSP：父类可以被子类完全替换
2. 用组合代替继承：如果只是想复用父类的代码，可以通过组合代替继承，实现更高的灵活性。

提高内聚的原则：

1. 集中信息与行为
2. 单一职责原则

面向对象方法下的信息隐藏

封装

封装职责（即对象的状态信息）和内部实现细节。

1. 所有数据都是private的，getter和setter方法的提供要注意（可以在其中添加数据计算来返回对应数据，没必要和成员变量一一对应；起名也有讲究，名字不能暴露内部实现）
2. 不能传递内部复杂数据结构的引用。（比如内部是数组，就不能返回数组，而是返回其中一个元素，不能暴露数组结构：迭代器模式）
3. 封装其他对象的引用（新建一个相同对象返回）
4. 封装类型信息（LSP）
5. 封装潜在变更（将方法中可能会变更的地方独立出去，变成新的接口来调用，这样就不会影响原来的类）

开闭原则OCP：为变更而设计

好的设计对拓展开放，对修改关闭：新功能要增加代码，而不是修改代码。

可通过依赖倒置DIP和多态来实现

多态：通过将新的需求或者需要更改的需求变为一个新的类，作为程序中某个原有类的子类，通过多态机制实现了拓展/变更，且没有修改。

DIP：高层模块和底层模块都依赖于抽象。即高层调用接口，底层实现接口。双方依赖的都是抽象，如果依赖的是具体类，则需要分离抽象接口，使双方再次依赖抽象。这也可以看出，Dip十分适合在分层体系结构中使用。所以，若原来的设计实现了DIP，则通过构造新的类实现两者依赖的中间抽象类即可实现OCP。

设计模式

可修改性：

1. 狭义的可修改性
2. 可拓展性
3. 灵活性（对实现的动态配置）

通过接口和实现分离；继承（父类有接口，子类来实现）来实现可修改性

策略模式：

定义一组算法，并将算法封装到一个类中，共同实现一个策略接口，可以在具体实现时挑选一个策略即算法进行使用，算法独立于上下文类进行变化。

设置策略接口和多个策略实现类，上下文类（策略的使用类）拥有策略接口类的引用。

先创建各个具体的策略实现类，上下文类可能提供一些信息给策略实现类来使用，对上下文类还要有方法来分配特定的策略实现类。

简单工厂（静态工厂模式）：

根据传入的参数不同，创建并返回不同的产品实例；专门负责类的创建。

产品如果多的话，判断逻辑会比较复杂。

工厂模式：

设置一个工厂接口，多个工厂具体类实现该接口。一个工厂具体类只能创建一种具体的产品。产品的实例化推迟到子类。

抽象工厂：

新增新的抽象产品类；一个具体的工厂可以实现生产多个抽象的产品大类中的产品，不单单只能生产一个产品大类。若只有一个抽象产品类，就会退回工厂模式。

注意：若新增一个产品体系，就需要在抽象工厂和某个想生产其产品的具体工厂添加对应的实现方法，不符合OCP原则。

单件模式：

让一个类只存在一个实例，自行实例化并向外界提供这个实例。该类的构造方法和对象都是私有的；同时对象的创建只有该类才能进行；提供一个静态方法来为外界提供这个静态的对象。

具体工厂就是单例模式。

迭代器模式：

是指不暴露底层数据结构实现的同时遍历其中所有元素。

为一个数据结构创建一个迭代器类，数据结构中提供方法get-Iterator来获取该类。通过对应迭代器类来遍历该数据结构即可，数据结构内部不被暴露。

首先有一个迭代器接口类，每个迭代器实现这个抽象类。同时有个集合类接口，可以创建迭代器。具体集合类实现集合类接口，创建具体的迭代器类。实现DIP依赖倒置。

软件构造，测试，交付，维护

软件构造，代码设计

软件构造包含的活动：详细设计，编程，测试，调试，代码度量，集成与构建，构造保障活动

软件构造的实践方法：重构，测试驱动开发，结对编程

代码改进手段：格式 命名 复杂决策 数据使用

高可靠性代码：契约性设计 防御性编程 （注意 前置条件和后置条件）使用mock开发单元测试用例

软件测试，交付

软件测试方法：黑盒测试 白盒测试（细分方法） 主要用于需求中的功能测试

集成测试 stub（主要是硬编码+driver

单元测试 mock （模拟类）+driver

Junit会用

交付

用户文档：是指为用户编写的软件系统操作方式和参考指南，如用户使用手册或者联机参考手册。

系统文档：侧重于系统维护方面的内容，包含性能调整，用户授权和系统安全，故障维护等等方面。是为系统维护人员提供的文档，需要涉及软硬件组成，网络连接方式，授权管理等内容。

软件维护，演化

维护的重要性：

1. 软件系统的需求可能变化，导致软件系统提供的作用降低
2. 随着软件生命周期的延长，软件系统的外部环境可能变化，影响软件使用
3. 软件总是有漏洞，发现后要及时处置

开发可维护软件的方法

1. 聚焦于软件的变更性：时刻注意需求的变更；设计软件遵循开闭原则，为变更而设计：
2. 降低维护困难：维护需求跟踪链，有充足的技术文档帮助说明软件系统；保障代码可读性

演化

软件演化生命周期模型

初始开发–演化–服务–逐渐淘汰–停止

逆向工程

注重理解软件系统。通过分析软件系统的构件和连接方式，通过更高层次的抽象重新构建系统，即抽取需求分析和设计内容，不关注实现，从而理解系统的大致结构

再工程

检查和改造一个软件系统，用新的模式及实现复原目标系统。注重软件系统的修改，往往需要一个前道的逆向工程。

软件开发过程模型

软件生命周期模型

为了从宏观上理解软件的开发阶段，从生产到废弃将软件的开发分为几个阶段，每个阶段都有其目标和负责人等，这些阶段就是软件生命周期

构建-修复模型

小型系统的开发，通过不断的修改和重复构建实现系统。

不注重可维护性 复杂度 需求

瀑布模型

将开发划分为几个迭代过程，使得开发者可以集中精力开发其中一个部分而不用关注复杂的宏观过程，是文档驱动的。

缺点：文档的期望过高，线性开发流程不切实际；

每个阶段划分的粒度过大，往往很久之后才能发现问题；

增量迭代模型

将开发流程划为几个并行的迭代的瀑布模型同时进行开发，在项目初期就有明确的项目前景和范围。

迭代式开发符合项目开发流程，具有实用性；并行开发的速度更快，提高了开发效率；持续交付可及时得到反馈，提高了满意度

当需求多变的复杂情况下，无法在开始时确定项目的大致前景

演化模型

在增量迭代的基础上，先确定核心需求开发出核心系统，得到用户反馈后继续迭代下一个系统。

更加适合需求多变的场景。

缺点：难以在项目开始时确定大致的项目前景和核心需求；后续迭代需要重视分析和构造，否则退化为构建修改

原型模型

原型分为演化式原型和抛弃式原型，原型模型强调抛弃式原型的使用而不是演化式原型

通过提前构造抛弃式原型，将未来应用于现在，减少应为知识的局限性导致的不确定性。

缺点：原型构造代价大 不舍得抛弃

螺旋模型

风险驱动，完全按照解决风险的方式进行软件开发活动。存在4个阶段通过构建原型的方式进行风险解决。

减少了由于风险产生的项目出错与损失。

缺点：螺旋模型通过原型解决风险，有着和原型一样的缺点；螺旋模型的项目复杂度高，项目管理难以进行