软件工程与计算II-24-考试总结

summary

1. 软件工程

1. 应用系统的、规范的、可量化的方法来开发、运行和维护软件，即将工程应用到软件。
2. 对1)中各种方法的研究。

2. 五十年代到00年代的特点

1. 1950s：科学计算；以机器为中心进行编程；像生产硬件一样生产软件。
2. 1960s：业务应用(批量数据处理和事物计算)；软件不同于硬件；用软件工艺的方式生产软件。
3. 1970s：结构化方法；瀑布模型；强调规则和纪律。它们奠定了软件工程的基础，是后续年代软件工程发展的支撑。
4. 1980s：追求生产力最大化；现代结构化方法/面向对象编程广泛应用；重视过程的作用。
5. 1990s：企业为中心的大规模软件系统开发；追求快速开发、可变更性和用户价值；web应用出现
6. 2000s：大规模web应用；大量面向大众的web产品；追求快速开发、可变更性、用户价值和创新。

2. 上下文图、0层图和N层图
   1. 上下文图是DFD的最高层次的图，是系统功能的最高抽象。上下文将整个系统看做一个过程，这个过程实现系统的所有功能。
   2. 0层图通常被用作整个系统的功能概图。
   3. 1层图分析以确定下一级转换
   4. N层图不断降解

7.2. 实体关系图 不重要

1. 图例：
   1. 传统实体:实体是需要在系统中收集和存储的现实世界事物的类别描述
   2. 属性:数据对象包含的一组作为对象的方面、质量、特征或描述符的属性
   3. 关系:传统实体之间的关系

3. 用例图的建立步骤
   1. 目标分析与解决方向的确定:需要实现什么，属于需求
   2. 寻找参与者:
   3. 寻找用例:
   4. 细化用例:判断标准是用例描述了为应对一个业务事件，由一个用户发起，并在一个连续时间段内完成，可以增加业务价值的任务。
4. 注意:
   1. 不要将用例细化为没有独立业务价值的单个操作:例如,不要将用户管理细化为增加、修改和删除三个更?的用例,因为它们要联合起来才能体现出业务价值。
   2. 不要将同?个业务目标细化为不同用例:例如特价策略制定和赠送策略制定。
   3. 不要将没有业务价值(而是技术实现需要)的内容作为用例:常见的错误有登录(应该描述为安全性质量需求)、“数据验证/输入/输出数据检查”(应该描述为数据需求或者业务规则)、“连接数据库”(属性软件内部实现?不是需求)、网络传输等。
   4. 不要将单个步骤细化为用例
   5. 不要将片面的一个方面细化为用例

7.5. 顺序图(交互图)

1. 图例：

2. 系统顺序图图例:
   1. alt一定要选(多选一):注意，每一种可选分支之间要用虚线分割，而且在表示执行态的圆柱上面要写监护条件，放在[]里面。
   2. opt一定要选(选择0或者1)
   3. loop:表示循环，在旁边使用[]书写循环条件

3. 步骤:
   1. 确定上下文环境
   2. 根据用例描述找到交互对象
   3. 按照用例描述中的流程顺序逐步添加消息s

7.6. 状态图

1. 图例:
   1. 状态：一组可观察的情况，描述了一个系统在给定时间的行为
   2. 状态转换：从一个状态到另一个状态的转换
   3. 事件：使系统表现出某种可预测的行为形式的事件
   4. 行为：由于过渡而发生的过程

10. 对给定的需求示例，设计功能测试用例

1. 以需求为线索，开发测试用例套件，确定输入/输出，开发测试用例。

1. 主程序子程序风格
   1. 优点:
      1. 流程清晰，易于理解
      2. 强控制性
   2. 缺点:
      1. 程序调用是一种强耦合的连接方式，非常依赖接口
      2. 程序调用的连接方式限制了部件之间的数据交互，可能会导致不必要的公共耦合。
   3. 适用：可以将系统功能依层次分解为多个顺序执行步骤的系统

3. 分层风格
   1. 优点:
      1. 设计机制清晰，易于理解(抽象层次分离，隔离复杂度)
      2. 支持并行开发(层次之间遵守程序稳定的接口)
      3. 更好的可复用性与内部可修改性(接口的稳定性，不同层次的部件能够互相替代)
   2. 缺点：
      1. 交互协议难以修改(可能需要改变所有的层次，接口具有强耦合性)
      2. 性能损失(禁止跨层调用)
      3. 难以确定层次数量和粒度
   3. 应用：适用于主要功能是在不同抽象层次上进行任务分解的复杂处理，能建立稳定的不同抽象层次之间的稳定交互协议，没有很高的实时性能要求的系统

5. 稳定依赖原则(SDP):朝着稳定(别人的修改不影响我)的方向进行依赖
   1. Ca:输入耦合度，包外部依赖本包的类个数
   2. Ce:输出耦合度，包内部依赖于包外部的类的个数
   3. 不稳定性: $I=\frac{Ce}{Ce+Ca}$, I越小越稳定

3. 例子

14. 人机交互设计

14.1. 可用性

1. 可用性不是用户界面的单一一维属性，它包含以下维度。
   1. 易学性：新手用户容易学习，能够很快使用系统。
   2. 效率：熟练的用户可以高效使用它
   3. 易记性：使用过软件系统的用户，能够有效记忆或快速重新学会使用该系统。(超市可以缓存之前的信息)
   4. 出错率：几乎没有错误，可以从错误中快速恢复
   5. 主观满意度：让用户有良好的体验。

14.2. 人机交互设计原则

1. 简洁设计(7±2原则)：文字不如图形
2. 一致性设计(实际模型和人的精神模型一致)，如下是一个不一致的例子(cancel和ok的位置问题)

2. 菜单系统
   1. 下拉式菜单：需要空间，可预测
   2. 弹出式菜单：灵活，定制，让用户惊讶
   3. 减少用户需要知道的命令，打字少，避免用户错误，提供上下文参考。
3. 黄金法则
   1. 让用户掌控一切
   2. 减少用户的内存负载
   3. 始终如一

15. 详细设计

15.1. 详细设计的出发点

1. 软件详细设计是在软件体系结构设计之后进行，以需求开发的结果(需求规格说明和需求分析模型)和软件体系结构的结果(软件体系结构设计方案与原型)为出发点。

15.2. 职责

1. 职责是执行任务(操作职责)或维护某些数据(数据职责)的义务。
   1. 行为职责通常由行为来履行。
   2. 数据职责通常由属性来完成。
   3. 可能会涉及到类之间的协作。
2. 职责分类
   1. 属性职责:对象的状态
   2. 行为职责:对象的行为
3. 通过职责建立静态设计模型

15.3. 职责分配

1. 将比较大的职责给很多对象。

15.3.1. GRASP原则(一般职责分配软件模式)

1. 特点:
   1. 低耦合：分配一个职责要保证低耦合度
   2. 高耦合：分配一个职责的时候要保持类的高聚合度
   3. 信息专家：将一个职责分配给专家-履行职责所必须的信息的类
   4. 创建者：创建规则在后面
   5. 控制者：控制规则在后面(避免大多数信息由一个类发出、组件相对较小、行为职责和数据绑定、职责单一)
2. 拇指原则:研究出来良好内聚性、耦合性和稳定性的替代方案。
3. 信息专家:统一提供对外的接口，而不是某一个具体的接口，数据和行为不要分开
4. 创建规则:如果有以下情况，则由创建者分配B类创建A类实例的职责：
   1. B 聚集了 A 对象
   2. B 包含了 A 对象
   3. B 记录了 A 的实例
   4. B 要经常使用 A 对象
   5. 当 A 的实例被创建，B具有传递给A的初始化数据(也就是 B 是创建 A 的实例这项任务的信息专家)
   6. 在有选择的地方，更喜欢B聚合或包含A对象

1. Mock Object类似于Stub，但是更加简单

15.4.2. 集成测试

15.6. 部分题目

1. 给定分析类图(概念类图)、系统顺序图和设计因素描述，建立设计类图(设计类图就是满足这三种控制风格的类图)/系统顺序图

2. 逻辑内聚:执行一系列操作，具体操作交给具体模块(如swtich)，解决控制耦合的方法

4. 过程内聚:执行一系列与步骤顺序有关的操作

6. 功能内聚:模块只执行一个操作或达到一个单一目的

8. 偶然内聚和逻辑内聚不可以接受

16.2. 结构化耦合

1. 数据耦合:两个模块的所有参数是同类型的数据项(发送正好)