信息化与信息系统（2）

1. 软件需求

1. 分类1

1. 业务需求

1. 反映企业或客户对系统高层次的目标要求

2. 项目投资人、购买产品的用户、客户单位的管理人员、市场营销部门或产品策划部门

2. 用户需求

1. 描述用户的具体目标，或用户要求系统必须能完成的任务

2. 描述用户能使用系统做些什么

3. 系统需求

1. 从系统的角度来说明软件的需求，包括功能需求、非功能需求和设计约束等

2. 也成为行为需求，规定了开发人员必须在系统中实现的软件功能，用户利用这些功能来完成任务，满足业务需要

2. 分类2

1. 功能需求

1. 表示系统为客户提供某项功能（服务），使用户的业务目标得以满足

2. 非功能需求

1. 表示系统具备的属性或品质，例如，可维护性、效率等

3. 设计约束

1. 限制条件或补充规约，通常是系统的一些约束说明

2. 例如，必须采用国有自主知识产权的数据库系统，必须运行在unix操作系统之下

3. 质量功能部署（QFD）

1. 定义 -- 一种将用户要求转化成软件需求的技术，其目的是最大限度地提升软件工程过程中用户的满意度

2. 分类

1. 常规需求 -- 用户任务系统应该做到的功能或性能，实现越多用户会越满意

2. 期望需求 -- 用户想当然认为系统应具备的功能或性能，但并不能正确描述自己想得到的这些功能或性能需求，如果期望需求没有得到实现，会让客户感到不满意

3. 意外需求 -- 兴奋需求，是用户要求范围外的功能或性能，实现这些需求用户会更高兴，但不实现也不影响其购买的决策

2. SA方法

1. 核心是数据字典

2. 模型

1. 数据模型 -- 实体联系图（E-R图）--描述实体、属性，以及实体之间的关系

2. 功能模型 -- 数据流图（DFD） -- 从数据传递和加工的角度，利用图形符号通过逐层细分描述系统内各个部件的功能和数据在它们之间传递的情况，来说明系统所完成的功能

3. 行为模型（状态模型）-- 状态转换图（STD） -- 通过描述系统的状态和引用系统状态转换的事件，表示系统行为，指出作为特定事件的结果将执行哪些动作

3. 需求验证

1. 内容

1. SRS正确地描述了预期的、满足项目干系人需求的系统行为和特征

2. SRS中的软件需求是从系统需求、业务规格和其他来源中正确推到而来的

3. 需求是完整的和高质量的

4. 需求的表示在所有地方是一致的

5. 需求为继续进行系统设计、实现和测试提供了足够的基础

2. 方法

1. 需求评审 -- 技术评审

2. 需求测试

3. UML

1. 四种关系

1. 依赖 --两个事物之间的语义关系，其中一个事物发生变化会影响另一个事物的语义

2. 关联 -- 描述一组对象之间连接的结构关系

3. 泛化 -- 一般化和特殊化的关系，描述特殊元素的对象和替换一般元素的对象

4. 实现 -- 类之间的语义关系，其中的一个类指定了由另一个类保证执行的契约

2. 五个系统视图 （口诀：逻辑不用进）

1. 逻辑视图 -- 设计视图，表示设计模型中在架构方面具有重要意义的部分，即类、子系统、包和用例实现的子集

2. 进程视图 -- 是可执行线程和进程作为活动类的建模；是逻辑视图的一次执行实例，描述了并发和同步结构

3. 实现视图 -- 对组成基于系统的物理代码的文件和构件进行建模

4. 部署视图 -- 把构件部署到一组物理节点上，表示软件和硬件的映射和分布结构

5. 用例视图 -- 是最基本的需求分析模型

3. 类之间的主要关系 （关系强到弱： 泛化= 实现 >组合>聚合> 关联>依赖）

1. 关联

1. 不同类的对象之间的结构关系，它在一段时间内将多个类的实例连接在一起

2. 对象实例之间的关系，而不表示两个类之间的关系

3. 连接模型元素及链接实例，用一条实现表示

2. 依赖

1. 两个类A和B，如果B的变化可能引起A的变化，则称类A依赖于B

2. 表示一个元素以某种方式依赖于另一个元素，用一条虚线加箭头来表示

3. 泛化

1. 一般事物与该事物中的特殊种类之间的关系，也就是父类与子类之间的关系

2. 继承关系是泛化关系的反关系，子类继承父类，而父类则是子类的泛化

3. 表示一般与特殊的关系，用一条实线加空心箭头来表示

4. 共享聚集（聚合）

1. 表示类之间的整体与部分的关系

2. 用一条实线加空心菱形来表示

5. 组合聚集

1. 表示类之间的整体与部分的关系

2. 与聚合的区别在于，组合关系中的部分只能属于一个整体，生命周期相同

3. 用一条实线加实心菱形来表示

6. 实现

1. 表示类与接口的关系，用一条虚线加空心箭头来表示

4. 14种图

1. 类图 -- 描述一组类、接口、协作和他们之间的关系，是最常见的图

2. 对象图 -- 描述一组对象和它们之间的关系，描述了在类图中建立的事物实例的静态快照

3. 构件图 -- 描述一个封装的类和它的接口、端口，以及由内嵌和连接件构成的内部结构

4. 组合结构图 -- 描述结构化类的内部结构，包括结构化类与系统其余部分的交互点。组合结构图用于画出结构化内部的内容

5. 用例图 -- 描述一组用例、参与者及它们之间的关系

6. 顺序图（序列图） -- 一种交互图，展现了一种交互，由一组对象或参与者以及它们之间可能发送的消息构成

7. 通信图 -- 一种交互图，它强调收发消息的对象或参与者的结构组织，强调的是时序，强调的是对象之间的组织结构

8. 定时图（计时图） -- 一种交互图，它强调消息跨越不同对象或参与者的实际时间，而不仅仅是关心消息的相对顺序

9. 状态图 -- 描述一个状态机，它由状态、转移、事件和活动组成

10. 活动图 -- 将进程或其他计算结构展示为计算内部一步步的控制流和数据流

11. 部署图 -- 描述对运行时的处理节点及在其中生存的构件的配置

12. 制品图 -- 描述计算机中一个系统的物理结构。制品包括文件、数据库和类似的物理比特集合

13. 包图 -- 描述模型本身分解而成的组织单元，以及它们之间的依赖关系

14. 交互概览图 -- 是活动图和顺序图的混合物

4. 软件架构

1. 核心 -- 能否达到架构级的软件复用

2. 架构风格

1. 数据流风格 -- 批处理序列结构风格和管道/过滤器

2. 调用/返回风格 -- 主程序/子程序、数据抽象和面向对象，以及层次结构

3. 独立结构风格 -- 进程通信和事件驱动的系统

4. 虚拟机风格 -- 解释器和基于规则的系统

5. 仓库风格 -- 数据库系统、黑板系统和超文本系统

3. 评估人员关注 -- 质量属性

4. 相关名词

1. 敏感点 -- 一个或多个构件的特性

2. 权衡点 -- 影响多个质量的特性

5. 评估方式

1. 调查问卷

2. 基于场景的方式

1. 最为常用

2. 分类

1. 架构权衡分析法（ATAM）

2. 软件架构分析法（SAAM）

3. 成本效益分析法（CBAM）

3. 描述方面

1. 刺激 -- 场景中解释或描述项目干系人怎么引发与系统的交互部分

2. 环境 -- 描述的是刺激发生时的情况

3. 响应 -- 系统是如何通过架构对刺激做出反应的

4. 作用 -- 分析软件架构对场景的支持程度，从而判断该架构对这一场景所代表的质量需求的满足程度

3. 基于度量的方式

5. 软件设计

1. 分类

1. 结构化设计

1. 一种面向数据流的方法

2. 以SRS和SA阶段所产生的DFD和数据字典等文档为基础

3. 自顶向下、逐步求精和模块化的过程

2. 面向对象设计

2. 原则

1. 高内聚 -- 模块内部各成分之间的联系程度

2. 低耦合 -- 模块之间联系的程度

3. 区别 -- OOD是OOA方法的延续，其基本思想包括抽象、封装和可扩展性，其中可扩展性主要通过继承和多态来实现

OOA: Object-Oriented Analysis（面向对象分析方法)

OOD: Object-Oriented Design(面向对象设计)

6. 设计模式

1. 目的 -- 可以方便的复用成功的软件设计

2. 要素 -- 模式名称、问题、目的、解决方案、效果、实例代码和相关设计模式

3. 处理范围

1. 类模式

1. 处理类和子类之间的关系

2. 静态关系

2. 对象模式

1. 处理对象之间的关系

2. 动态性

4. 目的和用途

1. 创建型模式

1. 用于创建对象

2. 工厂方法、抽象工厂、原型、单例、建造者模式

2. 结构型模式

1. 用于处理类或对象的组合

2. 适配器、桥接、组合、装饰、外观、享元、代理 模式

3. 行为型模式

1. 用于描述类或对象的交互以及职责的分配

2. 责任链、命令、解释器、迭代器、中介者、备忘录、观察者、状态、策略、模板方法、访问者 模式

7. 测试方法

1. 静态测试

1. 被测试程序不在机器上运行，而采用人工监测和计算机辅助静态分析的手段对程序进行监测

2. 测试类型

1. 文档 -- 检查单的形式

2. 代码 -- 桌前检查、代码走查和代码审查

2. 动态测试

1. 定义：在计算机上实际运行程序进行软件测试

2. 方法

1. 白盒测试

1. 适用

1. 结构测试

2. 单元测试

2. 特点

1. 将程序看作是一个透明的白盒，测试人员完整清楚程序的结构和处理算法，按照程序内部逻辑结构设计测试用例，检测程序中主要执行通路是否都按预定要求正确工作

3. 方法

1. 控制流测试、数据流测试和程序变异测试

2. 使用人工检查代码的方法来检查代码的逻辑问题

3. 逻辑覆盖-- 语句覆盖、判定覆盖、条件覆盖、条件组合覆盖、修改的条件/判定覆盖和路径覆盖

2. 黑盒测试

1. 适用

1. 功能测试

2. 集成测试、确认测试和系统测试

2. 定义

1. 将程序看作是一个不透明的黑盒，不考虑程序内部结构和处理算法，只检查程序功能是否能按照SRS的要求正常使用，程序是否能适当地接受输入数据并产生正确的输出信息，程序运行过程中能否保持外部信息的完整性等

3. 方法

1. 等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交实验法

3. 分类2

1. 单元测试

1. 也称为模块测试，测试的对象是可独立编译或汇编的程序模块、软件架构或OO软件中的类

2. 目的是检查每个模块能否正确地实现设计说明中的功能、性能、接口和其它设计约束条件，发现模块内可能存在的各种差错

2. 集成测试

1. 检查模块之间，以及模块和已集成的软件之间的接口关系，并验证已集成的软件是否符合设计要求

3. 确认测试

1. 目的 -- 主要用于验证软件的功能、性能和其他特性是否与用户需求一致

2. 分类

1. 内部确认测试 -- 由软件开发组织内部按照SRS进行测试

2. Alpha测试 -- 由用户在开发环境下进行测试

3. Beta测试 -- 由用户在实际使用环境下进行测试；通过后，才能把产品发布或交付给用户

4. 系统测试 -- 对象是完整、集成的计算机系统，目的是在真实系统工作环境下，验证完整的软件配置项能否和系统正确连接，并满足系统/子系统设计文档和软件开发合同规定的要求

5. 配置项测试 -- 对象是软件配置项，目的是检验软件配置项与SRS的一致性

6. 回归测试

1. 目的 -- 测试软件变更之后，变更部分的正确性和对变更需求的符合性，以及软件原有的、正确的功能、性能和其他规定的要求的不损害性

2. 对象

1. 未通过软件单元测试的软件，在变更之后，应对其进行单元测试

2. 未通过配置项测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试和配置项测试

3. 未通过系统测试的软件，在变更之后，首先应对变更的软件单元进行测试，然后再进行相关的集成测试、配置项测试和系统测试

4. 因其他原因进行变更之后的软件单元，也首先应对变更的软件单元进行测试，然后再进行相关的软件测试