软考笔记——第十章--结构化开发方法-系统设计

第十章 结构化开发方法-系统设计

• 系统分析与设计、需求分析、需求工程、结构化分析与设计、测试基础知识、系统运行与维护、软件架构介绍

1.系统分析概述

• 系统分析是一种问题求解技术，它将一个系统分解成各个组成部分，目的是研究各个部分如何工作、交互，以实现其系统目标。
• 目的和任务：系统分析的主要任务是对现行系统进一步详细调查，将调查中所得到的文档资料集中，对组织内部整体管理状况和信息处理过程进行分析，为系统开发提供所需的资料，并提交系统方案说明书。
• 系统开发的目的是将现有系统的物理模型转换为目标系统的物理模型。

2.系统设计

• 系统设计基本原理：

  • 抽象
  • 模块化
  • 信息隐蔽
  • 模块独立

• 模块的设计要求独立性高，就必须高内聚，低耦合，内聚是指一个模块内部功能之间的相关性，耦合是指多个模块之间的联系。

• 内聚

• 内聚程度从低到高如下表所示：

  内聚分类	定义	记忆关键字
  偶然内聚	一个模块内的各处理元素之间没有任何联系	无直接关系
  逻辑内聚	模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能	逻辑相似、参数决定
  时间内聚	把需要同时执行的动作组合在一起形成的模块	同时执行
  过程内聚	一个模块完成多个任务，这些任务必须按指定的过程执行	指定的过程顺序
  通信内聚	模块内的所有处理元素都在同一个数据结构上操作，或者各处理使用相同的输入数据或者产生相同的输出数据	相同数据结构、相同输入输出
  顺序内聚	一个模块中的各个处理元素都密切相关于同一个功能且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入	顺序执行、输入为输出
  功能内聚	最强的内聚，模块内的所有元素共同作用完成一个功能，缺一不可	共同完成、缺一不可

• 耦合

• 耦合程序从低到高如下表所示：

  耦合分类	定义	记忆关键字
  无直接耦合	两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，不传递任何信息	无直接关系
  数据耦合	两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递	传递数据值调用
  标记耦合	两个模块之间传递的是数据结构	传递数据结构
  控制耦合	一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量的值有选择的执行模块内的某一功能	传递变量、选择执行某一功能
  外部耦合	模块间通过软件之外的环境联合（如I/O将模块耦合到特定的设备、格式、通信协议上）时	软件外部环境
  公共耦合	通过一个公共数据环境相互作用的那些模块间的耦合	公共数据结构
  内容耦合	当一个模块直接使用另一个模块的内部数据，或通过非正常入口转入另一个模块内部时	模块内部关联

• 在系统分析阶段，进入设计阶段，要把软件“做什么”的逻辑模型转换成“怎么做”的物理模型。

• 系统设计的主要目的是为系统制定蓝图，在各种技术和实施方法中权衡利弊，精心设计，合理地使用各种资源，得出新系统的详细设计方案。步骤分为：概要设计和详细设计。

• 概要设计基本任务：设计软件系统总体结构、数据结构及数据库设计、编写概要设计文档、评审。

• 详细设计的基本任务：模块内详细算法设计、模块内数据结构设计、数据库的物理设计、其他设计、编写详细设计说明书、评审。

3.系统总体结构设计

• 系统结构设计原则：分解–协调原则、自顶向下原则、信息隐蔽和抽象原则、一致性原则、明确性原则、模块间高内聚低耦合、模块的扇入系数和扇出系数合理、模块规模适当。
• 子系统划分的原则：子系统要具有相对独立性、子系统之间数据的依赖性尽量小、子系统划分的结果应使数据冗余较小、子系统的设置应考虑今后管理发展的需要、子系统的划分应便于系统分阶段实现、子系统的互粉应考虑到各类资源的充分利用。

4.WebApp分析与设计

• WebApp是基于web的系统和应用。大多数WebApp采用敏捷开发过程模型进行开发。
• WebApp的特性：网络密集性、并发性、无法预知的负载量、性能、可用性、数据驱动。
• WebApp五种需求模型：内容模型、交互模型、功能模型、导航模型、配置模型。
• WebApp设计：架构设计（MVC（模型–视图–控制器））、构件设计（WebApp构件设计通常包括内容设计元素和功能设计元素）、内容设计（通常采用线性结构、网格结构、层次结构、网络结构）、导航设计。

5.软件需求

• 按需求内容分类：业务需求、用户需求、系统需求
• 从客户角度分类：基本需求、期望需求、兴奋需求
• 软件需求分类：功能需求、性能需求、设计约束、属性、外部接口需求

6.需求工程

• 需求工程六个阶段：需求获取、需求分析与协商、系统建模、需求规约、需求验证、需求管理。

7.需求管理

• 定义需求基线
• 处理需求变更
• 需求跟踪

8.结构化分析

• 结构化的分析方法SA：自顶向下，逐步分解，是面向数据的，强调分析对象的数据流，需要建立：功能模型（数据流图）、行为模型（状态转换图）、数据模型（E–R图）以及数据字典（数据元素、数据结构、数据流、数据存储、加工逻辑、外部实体）。

9.数据流图

• 数据流图是可以分层的，从顶层到0层、1层等，顶层数据流图只含有一个加工处理表示整个管理信息系统，描述了系统的输入和输出，以及和外部实体的数据交互。
• 数据流图基本设计原则：
  1. 数据守恒原则
  2. 守恒加工原则
  3. 对于每个加工，必须有输入输出数据流
  4. 外部实体与外部实体之间不存在数据流
  5. 外部实体与数据存储之间不存在数据流
  6. 数据存储与数据存储之间不存在数据流
  7. 父图与子图的平衡原则：子图的输入输出数据流同父图相应加工的输入输出数据流必须一致，。父图与子图之间的平衡原则不存在于单张图。
  8. 数据流与加工有关，且必须经过加工

10.数据字典

• 数据字典是用来定义在数据流图中出现的符号或者名称的含义，在数据流图中，每个存储、加工、实体的含义都必须定义在数据字典中，并且父图与子图之间这些名称要相同。

11.软件测试

• 系统测试是为了发现错误而执行程序的过程，成功的测试是发现了至今尚未发现的错误的测试。
• 测试原则：
  • 应尽早并不断的进行测试
  • 测试工作应该避免由原开发软件的人或小组承担
  • 在设计测试方案时，不仅要确定输入数据，而且要根据系统功能确定预期的输出结果
  • 既包含有效、合理的测试用例，也包含不合理、失效的用例
  • 校验程序是否做了该做的事和不该做的事
  • 严格按照测试计划进行
  • 妥善保存测试计划和测试用例
  • 测试用例可以重复使用或追加测试
• 测试阶段：
  • 单元测试：对单个模块进行测试，测试依据是软件详细说明书
  • 集成测试：一次性组装和增量式组装
  • 确认测试：对完成的软件进行功能上的测试，内部确认测试（无用户情况）、Alpha测试（用户在开发环境下进行测试、Beta测试（用户在实际使用时进行的测试）、验收测试（用户根据SRS对项目进行验收））
  • 系统测试：对软件进行性能测试，有三个方面：负载测试、强度测试、容量测试
  • 回归测试：软件修改错误或变更后，进行回归测试以验证之前正确的代码是否引入了错误。
• 测试方法：
  • 动态测试：程序运行时测试
    • 黑盒测试法：功能性测试，不了解软件代码结构，根据功能设计用例，测试软件功能。
    • 白盒测试法：结构性测试，明确代码流程，根据代码逻辑设计用例，进行用例覆盖。
    • 灰盒测试法：既有黑盒，也有白盒。
  • 静态测试：程序静止时，对代码进行人工审查
    • 桌前检查：程序员检查自己编写的程序，在程序编译后，单元测试前。
    • 代码审查：由若干个程序员和测试人员组成评审小组，召开程序评审会来进行审查。
    • 代码走查：采用开会来对代码进行审查，但并非简单的检查代码，而是由测试人员提供测试用例，让程序员扮演计算机的角色，手动运行测试用例，检查代码逻辑。
• 测试策略：
  • 自底向上：从最底层模块开始测试，需要编写驱动程序，而后开始逐一合并模块，最终完成整个系统的测试。优点是较早的验证了底层模块。
  • 自顶向下：先测试整个系统，需要编写桩程序，而后逐步向下直至最后测试最底层模块。优点是较早的验证了系统的主要控制和判断点。
  • 三明治：既有自底向上也有自顶向下的测试方法，二者都包括。兼有二者的优点，缺点是测试工作量大。

12.测试用例设计

• 黑盒测试用例：将程序看做一个黑盒子，只知道输入输出，不知道内部代码，由此设计出测试用例，分为下面几类：
  • 等价类划分
  • 边界值划分
  • 错误推测
  • 因果图
• 白盒测试用例：知道程序的代码逻辑，按照程序的代码语句，来设计覆盖代码分支的测试用例，覆盖级别从低至高分为六种：
  • 语句覆盖
  • 判定覆盖
  • 条件覆盖
  • 判定/条件覆盖
  • 条件组合覆盖
  • 路径覆盖

13.调试

• 测试是发现错误，调试是找出错误的代码和原因。
• 调试的方法：蛮力法、回溯法、原因排除法（具体包括演绎法、归纳法、二分法）

14.系统转换（了解）

• 系统转换是指新系统弄开发完毕，投入运行，取代现有系统的过程。有三种转换计划：
  • 直接转换
  • 并行转换
  • 分段转换
• 数据转换与迁移，将数据从旧数据库迁移到新数据库中。
• 转换的过程称为ETL，有三个步骤：抽取（旧数据库数据）—转换（三种转换方法）—装载（装入新数据库，并校验数据）

15.软件维护

• 软件维护是软件生命周期中的最后一个阶段，不属于系统开发过程。
• 可维护性：
  • 易测试性
  • 易分析性
  • 易改变性
  • 稳定性
• 系统维护包括硬件维护、软件维护和数据维护，其中软件维护类型如下：
  • 正确性维护
  • 适应性维护：外部环境发生了改变，被动进行的对软件的修改和升级。
  • 完善性维护：基于用户主动对软件提出更多的需求，修改软件，增加更多的功能，使其比之前的软件功能、性能更高，更加完善。
  • 预防性维护

16.系统评价

• 系统评价分类：立项评价、中期评价、结项评价。