软件工程攻略

软件工程复习攻略

1. 软件工程

1.1 软件

软件之定义

软件应该是某些项目的集合, 这些项目包括指令(Instruction), 数据(Data)以及文档(Document)

软件之特点

1. 逻辑产品而不是物理产品
2. 并不会被用坏
3. 开发或者说是工程, 并不是一种制造
4. 大多数软件都是特性化开发
5. 依赖于开发者的质量
6. 开销巨大
7. 难于维护

软件之难关

1. 难以准确的估计开发的耗费
2. 质量太差
3. 难以维护

由于软件的开发存在这么多的问题, 其主要原因是规模太大并且缺少一种有效的方法来进行整个软件的开发 从而引出软件工程

1.2 软件工程

软件工程之定义

(1) The application of a systematic disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software. (2) The study of approach as in (1).

关于软件质量

软件质量包括几个特性, 分别是可维护性, 可信赖性, 有效性, 便利性

软件工程的关键部分

软件工程的关键部分分别是过程(Process), 方法(Method)以及工具(Tool)

软件工程的目的

1. 按时完成(On schedule)
2. 耗费的管理(Cost Budget)
3. 高质量(High Quality)

第一部分总结

1. 软件是一种特殊的产品
2. 开发一个大型并且复杂的软件是一种挑战
3. 软件工程就是一种手段, 使得我们可以在开发软件的时候有一种工程化的方法
   1. Process
   2. Method
   3. Tool

2. 软件开发过程

2.1 软件生命周期

这里我们直接给出一个软件生命周期中的各个状态 可行性以及投资-->需求分析-- >结构设计-->细节设计-->实现-->集成-->维护-->退休 其中的结构设计和细节设计属于设计的部分

可行性以及投资部分

方法: 可行性分析 该部分应该输出可行性投资报告文档以及项目立项开发计划文档

需求分析部分

技术: 抽象, 分解, 原型, 建模, 多视角 输出: 软件需求规格说明书(SR)

结构设计部分

方法: 自顶向下, 模块化, 信息隐藏 输出: 软件结构设计文档, 数据结构以及数据库的设计说明, 集成测试计划文档

细节设计部分

方法: 基于SRS以及结构设计说明文档, 基于平台以及编程语言 输出: 详细设计说明书, 单元测试计划说明

实现部分

方法: 基于细节设计文档, 基于特定的编程语言 输出: 代码

集成部分

方法; 基于结构设计文档以及集成测试计划, 软件测试工具 输出: 集成测试报告, 可执行的软件系统

维护部分

方法: 基于文档或者基于软件的代码 输出: 软件的新版本

2.2 软件过程模型

• 关于软件过程 软件过程之定义: 一系列的可预测步骤, 帮助你按时完成高质量的软件 例子: 需求分析, 结构设计, 细节设计, 测试, 编码

软件过程模型即过程的一种抽象, 可以帮助你理解软件的开发

• 关于具体的软件过程模型
  • 瀑布流模型(Waterfall Model)
    • 缺点: 开发过程不可逆, 实际开发难以严格按该模型进行
    • 使用范围: 需求十分清楚, 开发过程中没有什么需求变动
  • 快速原型模型(Rapid Prototype Model)
    • 优点: 容易适应需求的变化, 可以得到良好的需求定义
    • 缺点: 客户和开发者对原型的理解不同, 难以进行原型设计
    • 使用范围: 对所开发的领域比较熟悉, 有快速的原型设计工具
  • 增量模型(Incremental Model)
    • 优点: 人员灵活分配, 不用投入大量的人力资源
    • 缺点: 可能遇到不能集成的风险, 软件必须具备开放式的体系结构
    • 使用范围: 进行产品升级或者新版本开发, 对开发领域熟悉并且已经有原型的开发也是十分合适
  • 螺旋模型(Spiral Model)
    • 优点: 设计比较灵活, 可以在项目的各个阶段进行变更, 容易计算成本
    • 缺点: 需要求相当丰富的风险评估的经验和专门的知识, 容易会造成损失, 而且过多的迭代次数会使得开发成本增加, 延迟提交的时间
    • 使用范围: 只适合大规模的软件项目

2.3 一些工具

略

第二部分总结

软件生命周期以及不同的软件过程模型的特点

3. 软件需求

3.1 需求工程

软件需求的定义

客户对于软件的需求, 包括功能, 性能, 设计约束, 计划等等

需求工程的定义

• The process to obtain customers’ or end-users’ software requirement
• Encompasses(包含) a set of tasks that lead to an understanding of software requirements
• Helps software engineers to better understand the problem they will work to solve

需求工程的过程

1. 需求获取(需求引导)
2. 需求分析
3. 需求说明
4. 需求确认
5. 需求管理

3.2 需求捕获技术

需求获取的目的:

• 从相关者中获取所有的需求
• 定义问题
• 定义问题的范围
• 在不同的相关者之间解决矛盾

需求获取的技术:

• 采访客户
• 开办研究会来讨论需求
• 询问
• 原型(使用HTML来设计原型)

3.3 需求分析和说明

需求分析模型 需求分析的核心就是去构建分析的模型

• 传统技术
  • Data Flow Diagram(DFD)
  • ER
  • Data Dictionary
  • State Transition Diagram
• 面向对象的技术
  • Use Case Diagram
  • Sequence Diagram
  • Collaboration Diagram
  • Class Diagram
  • State Diagram

需求分析的过程

1. 定义系统的范围
2. 分析需求的可行性
3. 确定需求的优先级
4. 建立需求分析模型
5. 建立数据字典

3.4 需求确认和管理

需求确认的技术

• 需求判断
• 原型分析
• 生成测试用例

需求管理

• 更改控制
• 版本控制
• 需求跟踪

第三部分总结

需求获取的技术, 需求分析的技术以及相应的模型, 需求的确认和管理的技术

4. 面向对象介绍

4.1 面向对象方法论

面向对象的软件工程

• 面向对象分析(OOA)
• 面向对象设计(OOD)
• 面向对象编程(OOP)
• 面向对象测试(OOT)
• 面向对象维护(OOM)

4.2 面向对象基础

关于一些联系, 关联等, 不多赘述 软件模型:

• 数学模型
• 描述模型
• 图模型

4.3 统一建模语言(UML)

这里不多叙述UML的画法, 包括类, 接口, 包, 组件等

关于UML中的联系

1. 关联
2. 聚合(空心菱形, 可以全都没有)
3. 组合(实心菱形, 不可或缺的一部分)
4. 泛化(类似继承)
5. 依赖(虚线箭头, 方法中的参数或者是成员变量)
6. 实现(虚线三角形, 实现某个接口)

4.4 第四部分总结

主要是关于UML以及面向对象的概念

5. 面向对象分析

5.1 面向对象分析的介绍

面向对象分析

• 发现和描述对象
• 分析内部组件和外部关系
• 建立OOA模型

关于OOA模型

• 用例建模
• 类建模
• 动态建模

5.2 用例建模

关于用例建模, 这里我们需要找到几种特殊的实体 首先是Actor以及Use case 参与者和用例的确定并不是特别困难

用例建模中用例之间的关系

• 包含(一种行为包含了另一种行为, 这意味着将会被一起完成的含义)
• 扩展(多种状态下的行为)
• 泛化(这里类似继承, 扩展是带有更多限制关系的泛化)
• 关联(两个用例之间存在联系)

5.3 类建模

这里注意的是CRC卡片以及各种类抽取的方法, 比如名词提取法 通过用例建模, 我们可以进行名词的提取, 通过某些规则过滤掉部分名词, 得到一部分的类名和属性名 CRC卡片可以帮助我们对类进行一定的补充, 修改等 在类建模的时候要注意某些设计模式, 比如MVC, Factory, Proxy, Observer, Strategy等模式, 多使用接口来实现, 少用继承

5.4 动态建模

动态建模的核心就是绘制出状态图 状态图一般来说应该拥有一个开始节点以及一个终止节点, 节点和节点之间的联系是有条件的, 通过条件进行状态的变迁 这里我们如果将状态的分析的足够完全的话, 就可以绘制出完整的状态图

第五部分总结

OOA的部分, 包括三个图, 用例图, 类图, 状态图, 以及CRC卡片的验证

6. 面向对象设计

6.1 软件设计

设计的原则

• 模块化
• 高内聚
• 低耦合
• 支持复用

关于耦合, 这里由低到高给出不同耦合:

• 消息耦合(状态的去中性化)
• 数据耦合(传递最基本的数据)
• 特征耦合(通过传递地址来传递高级数据结构)
• 控制耦合(传入控制参数来进行状态转移)
• 公共耦合(一个类直接使用另一个类的成员变量)
• 内容耦合(共享一个全局变量)

关于内聚, 这里给出由高到低的不同内聚情况:

• 函数内聚
• 通信内聚
• 过程内聚
• 时间内聚
• 逻辑内聚
• 偶然内聚

6.2 结构设计

这里主要讲了MVC, B/S, 层次结构等, 以及部分的设计模式, 不多赘述

6.3 组件设计

建立交互图 这里给出了一种新的图, 即时序图, 通过时序图来描述一个动作的流程情况 通过时序图就可以重新优化类图, 如果时序图出现了类图中没有的类, 就可以进行添加来重新优化类图 这里面要注意信息的隐藏

6.4 数据库设计(略)

6.5 用户界面设计(略)

第六部分总结

主要是耦合和内聚的知识, 以及时序图的部分

7. 实现

7.1 编程语言

我们需要选择一门便于实现的语言, 这样的选择会在项目的后期, 而不是预先选择语言

7.2 代码标准

关于命名的规则等, 这里需要团队统一命名的规范, 代码的布局等 便于代码的修改以及后期的集成

7.3 集成

关于实现和集成 这里给出多种集成的方案:

• 自顶向下
  • 优点: 错误隔离, 不会浪费资源, 逻辑模块要先于操作模块进行开发, 主设计流程会很快显示
  • 缺点: 低级别的模块可能不会被测试完全
• 自底向上
  • 优点: 操作性模块会被测试完全, 错误隔离
  • 缺点: 主要的设计缺陷会延迟被发现
• SandWich(混合模式)
  • 结合以上两种模式来进行, 对逻辑模块使用自顶向下, 对操作模块使用自底向上

7.4 第七部分总结

主要是关于一些编程语言的选择, 代码编写的规范以及最后代码集成的方案

8. 软件维护

8.1 软件维护(略)

8.2 维护的种类

关于维护的种类:

• 正确性维护
  • 也就是对错误进行修正
• 完全性维护
  • 会对代码进行修改
  • 会提高整个产品的性能等
• 适应性维护
  • 对软件产品进行修改
  • 会对操作环境进行改变
• 其他维护

第八部分总结

4种维护的内容

9. 软件测试

9.1 软件测试

软件测试贯穿于整个软件的生命周期之中, 是软件质量的保证 给出几种错误的类型:

• Error(错误, 也就是编程过程中的错误)
• Fault/Bug(漏洞, 由于error造成的错误)
• Defect(缺陷, 未探测到的错误)
• Failure(失效, 和软件的外部状态有关系)

9.2 基于非执行的软件测试

测试的内容:

• 文档中的错误
• 代码中的明确错误

9.3 基于执行的软件测试

基于执行的测试一般来说, 我们拥有一系列的输入输出的测试计划来进行测试 关于测试的内容:

• 实用性
  • 根据用户的需要, 给出各种测试用例, 包括一些便利性的测试
• 鲁棒性
  • 加强输入的随机性, 使得可操作的条件的范围增大, 不易出错
• 可依赖性
  • 根据某些数值来进行判断, 比如平均失效时间, 平均修复时间, 平均无故障时间
• 性能
  • 响应时间
  • 空间需求
• 正确性
  • 如果输入满足说明的要求是否能产生相对应的输出

关于测试的方法:

• 黑盒测试, 白盒测试, 单元测试, 集成测试

关于测试用例的设计是十分重要的

第九部分总结

主要是两种不同的测试方案