软件工程（四）——结构化设计、模块独立性、面向对象设计、软件测试与维护

目录

一、界面设计

二、结构化设计

1.概要设计

2模块独立性

三、面向对象设计

1.面向对象设计的五大基本原则(SOLID)和其他5个原则

2.设计模式

三、软件测试与维护

1.白盒测试和黑盒测试

2.测试的阶段

3.软件维护阶段

四、系统演化策略

---

一、界面设计

        人机界面设计，就是设计一个软件的界面，供用户与系统交互。 人机界面设计有三个黄金法则

• 置于用户控制之下：允许用户交互中断和撤销；不强迫用户进入不必要、不希望的动作方式来定义交互方式。例如：你点一个网站，同时跳出来广告页面可能会让你特别恼火 等
• 减少用户记忆负担：定义直觉性的捷径，界面视觉布局应该基于真实世界的隐喻。
• 保持界面的一致性：同一个类型的系统，界面布局风格应该保持一致，不要每个模块的界面五花八门。

二、结构化设计

1.概要设计

概要设计主要做模块的划分；详细设计负责对模块内部算法的设计

概要设计主要做模块的划分，模块接口设计。对应的测试阶段是集成测试。概要设计负责设计软件系统总体架构；将系统划分成模块，确定模块功能与接口、调用关系等；数据结构设计(详细设计也有涉及)、数据库设计；编写概要设计文档、数据库设计说明书、用户手册、修订测试计划等。

结构化系统设计基本原理： 抽象；模块化；自顶向下、逐步求精；信息隐蔽、模块独立

围绕这基本原理结构化系统设计有几个基本原则：

分解—协调原则 ； 自顶向下原则 ； 信息隐蔽、抽象原则 ； 一致性原则 ； 明确性原则；高内聚低耦合；模块扇入系数和扇出系数要合理；模块规模适当

2模块独立性

三、面向对象设计

1.面向对象设计的五大基本原则(SOLID)和其他5个原则

1. 单一职责原则(Single responsibility principle),指类的功能应该是尽量单一的；
2. 开放封闭原则(Open and close principle)，指类的功能扩展是开放的，修改内容应该是封闭的
3. 里氏替换原则(Liskov substitution principle),即一个模块中如果使用了一个基类，那么这个基类应该可以被子类替换，同时不改变程序的正确性；
4. 接口分离原则(interface segregation principle),即接口要尽量独立，不要把很多接口包含在一个模块中，否则，当用户需要某个接口时，会把用户不需要的接口导入进来。
5. 依赖倒置原则(dependency inversion principle), 高级别模块不应依赖低级别模块，但都依赖于抽象；或者说应该针对接口编程，而不是针对实现编程。
6. 重用发布等价原则(Release Reuse Equivalency Principle):重用的粒度就是发布的粒度
7. 共同封闭原则(Common Closure Principle):包中的所有类对于同一类性质的变化是共同封闭的。一个变化对一个包产生影响，那么包中的类都会产生影响，而其他包的不造成影响
8. 共同重用原则(Common  Reuse  Principle):一个包中所有的类都是共同重用的。如果重用了包中的一个类，那么就要重用包中所有的类。
9. 稳定依赖原则:(Stable Dependencies Principle):朝着稳定的方向进行依赖
10. 稳定抽象原则(Stable Abstractions Principle):包的抽象程度应该和其稳定程度一致。

2.设计模式

        模式一种解决问题的解决方案，也是一种解决问题套路。模式有多个层级

1. 架构模式属于高层的，例如C/S结构就是架构模式，架构模式反应了开发软件系统过程中所作的基本设计决策
2. 设计模式属于中层，主要关注软件系统的设计，设计模式与具体的实现语言无关
3. 惯用法是最低层的模式，关注软件的设计与实现，实现时通过某种特定的程序设计语言来描述构件与构件之间的关系。每种编程语言都有自己特定的模式，即语言的惯用法。例如引用计数就是C++语言的一种惯用法

         设计模式分为创建型模式,结构型模式,行为型模式三大种。创建型模式目的是为了解决对象创建的问题，结构型模式为了组建更大的结构，而行为型模式为了解决交互和职责分配的问题。设计模式具体内容如下

设计模式的理解：对23个设计模式的总结_superSmart_Dong的博客-CSDN博客_充分理解23设计模式

三、软件测试与维护

软件测试应该要尽早，不断地测试；最要交叉检查代码，尽量避免测试自己的程序，因为测试自己的程序容易惯性思维，从而容易忽略错误；程序不仅要有正确的数据进行测试，“不合理”的数据也要进行测试，至少不能导致系统崩溃；修改程序后要进行影响性分析要做回归测试；发现的错误越多那么隐藏的错误数量越多。

测试分为动态测试和静态测试。静态测试就是不依赖于计算机纯手工检查代码，比如桌前检查，代码审查，代码走查。动态测试就是依赖于计算机运行的测试，比如黑盒测试、白盒测试，黑白结合的灰盒测试。

1.白盒测试和黑盒测试

黑盒测试不看程序结构，只看输入和输出，从而设计测试用例。而白盒测试需要观察程序结构设计测试用例。

对于黑盒测试，等价类划分的主要思想就是根据相同输出结果对应的输入归成一个等价类，不同等价类至少要一个测试用例。而边界值分析的思想是，程序中条件判断的分界线处最容易出错，比如大于等于容易在开发中写成大于,因此需要在条件判断的区间两端处设计测试用例。而错误推测根据开发经验测试容易出错的环节。因果图，列出输入项和输出项之间的逻辑关系和约束 ，把输入项列表列成二进制分别取值进行测试，统计实际结果与预期输出的差异。

对于白盒测试，就是画出简易程序流程图，根据运行流程设计测试用例，从而判断出实际结果和预期结果的差异。其中语句覆盖是最松的测试，路径覆盖是最严的。

2.测试的阶段

• 单元测试：主要是模块的功能测试、性能等
• 集成实施，主要测试模块间的接口
• 确认测试：由用户参与进来，验证软件与需求的一致性。对于α 和β测试，其中 α测试是在开发环境，把软件交给用户，运行软件随意操作。而β测试，就是将产品对外发布一个测试版本，供用户运行软件且可以随意操作。
• 系统测试：模拟在真实环境下，验证完整的软件配置项能否和系统正确连接。通常在与生产环境高度一致的测试环境进行运行测试。
• 回归测试：程序变更后，可能会误改动到不需要变更的用例，因此需要对老用例的正确性进行重新测试。

 

         在集成测试中，分为一次性组装和增量组装。一次性组装测试工作量小，而增量式组装测试更为细致。增量式组装有自顶向下和自底下上的测试方案。当自顶向下测试时，测试高层模块，就要先写下层的被调用的测试模块来配合高层模块的测试，配合高层测试的下层demo就是桩模块。当自底下上，或两者混合测试时，上层模块demo来调用下层模块进行测试，这个上层模块就称为驱动模块。

        系统测试的测试主要内容就是非功能测试。比如说请求响应时间，高数据量测试，高并发测试，系统重启后软件是否能够恢复运行等。负载测试主要看重高并发时运行效果，强度测试主要看重系统可用资源较低时软件能否正常运行，容量测试主要看系统能够正常运行的最高并发量、最高请求量是多少。

3.软件维护阶段

        维护阶段发生在软件上线发布之后，是软件生命周期中最长的一个阶段。上线后的程序变更通常就是维护。维护大致分为四种：

• 正确性维护：又称改正性维护。指修正开发时造成的漏洞，但是未在上线之前发现的软件BUG。
• 适应性维护：指在软件运行环境变化，软件为了适应新的运行环境所做的变更。比如数据库，操作系统升级，导致软件被动地修改。
• 完善性维护：指在增加功能，提升性能的维护操作。
• 预防性维护：目的是为了改进应用软件的可靠性和可维护性，指适应未来可能产生的风险进行的维护操作。

四、系统演化策略

        一个系统要演化成一个新系统。通常有4中策略，淘汰、集成、重构(继承)、改造。对于业务价值低，同时技术水平也很低的模块通常采用将模块抛弃的策略。对于有业务价值的模块，但是技术水平低，比如代码乱七八糟，通常采用重构的策略。对于有技术水平的模块，但是业务价值低的，通常认为是因为信息孤岛的现象造成的，也就是系统间没有互联互通，因此要将此类模块集成。对于高技术水平，高业务价值的模块，只要小修小改就可以。