课程大纲
概述
软件即是艺术又是科学产物,它同时需要激情和规范。 编写好的软件既需要想象力和创造力的自由翱翔, 又需要残酷现实的工程权衡。
——Robert Martin
软件是人们智慧的产品,兼具工程和艺术属性, 因此软件工程师需要有数学的思维、工程的严谨和艺术的创造三位一体的训练。
——杨芙清
软件概念
软件 = 程序 + 数据 + 文档 程序 = 算法 + 数据结构
特点
- 复杂性
- 一致性
- 可变性
- 不可见性
软件危机概念
计算机软件的开发和维护过程中所遇到的一系列问题。 几乎所有软件存在这些问题。
典型表现
- 对软件开发成本和进度的估计常常不准确。
- 用户对“已完成”的软件系统常常不满意。
- 软件产品的质量常常靠不住
- 软件常常不可维护
- 软件常常没有适当的文档资料
- 软件成本在计算机系统总成本所占的比例逐年上升。
- 软件开发生产率提高的速度,远远跟不上计算机应用普及的速度。
原因
-
客观
软件本身的特点
-
主观
不正确的开发管理方法
软件工程概念
定义
IEEE 给出的定义如下:
软件工程是:(1)将系统化、规范化、可量化的方法应用于软件的开发、运行和维护, 即将工程化方法应用于软件;(2)对(1)中所述方法的研究。
实践的精髓
- 理解问题
- 策划解决方案
- 实施计划
- 检查结果的正确性
实践的原则
- 存在价值
- 保持简洁
- 保持愿景
- 关注使用者
- 面向未来
- 提前计划复用
- 认真思考
软件职业道德
IEEE 和 ACM 联合制定,八项原则
- 公众(public)
- 客户和雇主(client and employer)
- 产品(product)
- 判断(judgment)
- 管理(management)
- 专业(profession)
- 同行(colleagues)
- 自身(self)
软件过程
要解决软件危机,首要任务就是把软件活动视作可控的、可度量的和可改进的过程
——Watts Humphrey
软件过程概述
定义
软件过程是开发高质量产品的一系列相关活动的集合。 软件过程的目的是为各种人员提供一个公共的框架,以便用相同的语言进行交流。
四个基本活动
- Software specification:定义系统应该做什么
- Software design and implementation:定义系统的架构和实现
- Software validation:检验系统是否满足用户的需求
- Software evolution:随用户需求的变化变更系统
软件过程描述
四种组织形式
- 线性(linear)
- 迭代(iterative)
- 增量(incremental)
- 并行(parallel)
其他描述
- Products:过程活动中的工作产品
- Roles:软件过程中相关人员的职责
- Pre- and post-conditions:表达式,过程活动进行前后都为真
软件过程活动
需求工程过程
软件需求规格说明:理解和定义用户需要什么样的服务,确定系统运行和开发时的约束。
设计与实现
-
设计过程
设计出实现了需求规格说明的软件系统。
-
设计活动
把软件的结构转变为可执行的程序。
-
两阶段设计
- 总体设计:概括的说,应该怎样实现系统。
- 详细设计:应该怎样具体的实现这个系统。
软件确认
Verification and validation(V&V):系统符合规格说明,满足用户的期望。
- 检验
- 审查
-
测试
使用测试用例来执行系统,检验系统的正确性。
软件演化
软件具有灵活性,经常变更。
软件过程模型
瀑布模型
瀑布模型(waterfall)又称为经典生命周期(classic life cycle), 他提出了一个系统的、顺序的开发方法。
传统的瀑布模型:需求分析->规格说明->设计->编码->综合测试->维护
快速原型模型
快速迭代开发,常用于用户界面设计、定义软件需求。
增量模型
增量模型交互一系列称为增量的版本,随着每个版本的交互,逐步为用户提供更多的功能。
RUP(Rational 统一过程)
用例驱动,架构为核心,迭代并且增量。
-
4 个阶段
- 起始阶段(Inception Phase):定义需求,提出大致架构,制定开发计划。
- 细化阶段(Elaboration Phase):扩展初始用例,扩展体系结构,评审修订项目计划。
- 构建阶段(Construction Phase):系统开发和测试。
- 转换阶段(Transition Phase):部署系统
-
最佳实践
- 迭代式开发
- 管理需求
- 使用基于构件的体系结构
- 可视化建模
- 验证软件质量
- 控制软件变更
敏捷软件开发
敏捷宣言
- 个人和他们之间的交流胜过开发过程和工具
- 可运行的软件胜过了宽泛的文档
- 客户合作胜过了合同谈判
- 对变更的良好响应胜过了按部就班的遵循计划
技术实践(XP)
-
用户故事
用户故事写在卡片上,开发团队把用户故事分解为一系列的任务。
-
重构
重构是以不改变代码外部行为而改进其内部结构的方式来修改软件系统的过程。
-
TDD
测试驱动开发,先写测试,然后写代码让所有测试通过。
-
结对编程
两个人面对同一台计算机共同为一个故事开发代码。
-
持续集成
团队的成员应该经常集成他们的工作,每次集成通过自动化的构建来验证,从而更快 的检测出集成错误。
管理实践
-
每日站立会议
每日工作前,团队成员的例行沟通机制,由 Scrum 和 Master 组织,Team 成员全体站立参加。
聚焦下面的三个主题:
- 我昨天为本项目做了什么?
- 我计划今天为本项目做了什么?
- 我需要什么样的帮助以更高效的工作?
理解需求
需求工程概述
需求工程概述
对应用应该提供的服务和所受到的约束进行理解、分析、建立文档、检验的过程。
需求的两个方面
-
需求开发
- 需求获取
- 需求分析
- 编写需求规格说明
- 需求确认
-
需求管理
- 需求跟踪
- 需求变更控制
- 版本管理
- 需求复用
需求的两种层次
-
用户需求
描述系统能为用户做什么,通常只涉及系统的外部行为,使用自然语言和图来描述。
-
系统需求
定义系统需要实现的功能,一个用户需求可以拓展为多个系统需求。
需求的两种类型
-
功能需求
描述系统应该提供的功能和服务。功能需求应该具备完整性和一致性。
-
非功能需求
系统的特性和约束,可靠性,性能,可用性等
需求获取
过程
技术
-
访谈
与涉众的正式或非正式的访谈。
-
场景
用户将来如何使用系统的现实例子。
-
用例
每个用例就是一个场景。
- 原型
需求规格说明
SRS
需求验证
一致性
任何一条需求不能和其他需求互相矛盾。
完整性
SRS 应该包括用户需要的每一个功能或性能。
现实性
现有的软硬件技术可以实现需求。
有效性
需求确实满足用户的实际需要。
需求建模
模型分类
- 环境模型
- 交互模型(用例图和顺序图)
- 结构模型(类图)
- 行为模型(状态图)
- 数据驱动模型(数据流图)
需求建模的方法
-
结构化分析
-
数据模型(ERD)
Entities:实体是客观世界中存在的,可相互区分的事务。 Attributes:属性是实体或联系所具有的性质。 Relations:实体之间相互连接的方式。一对一(1:1),一对多(1:N),多对多(M:N)
-
功能模型(DFD)
外部实体用长方形表示,处理加工用椭圆表示,箭头表示数据流,数据存储用双横线表示。
-
行为模型(状态转换图)
状态图符号:
- 初态:实心圆
- 终态:空心圆
- 中间状态:圆角矩形,上面部分为状态的名称,中间部分为状态变量的名字和值,下面部分是活动表。
- 带箭头的连线:状态转换
活动表语法:事件名(参数表):动作表达式 事件表达式语法:事件说明[守卫条件]:动作表达式
-
数据字典(DD)
DD 是对所有与系统相关的的数据元素的一个有组织的列表,已经精确的,严格的定义。
基本符号: 顺序+:以确定次序,连接两个或多个分量 a + b + c 选择|, []:从两个或多个可能元素中选取一个[a | b | c] 重复{}:把指定的分量重复零次或多次
-
面向对象分析
面向对象方法学概述
面向对象方法学要点
- 客观世界是由各种对象组成,任何食物都是对象
- 把所有对象都划分成各种对象类,每个类都定义了一组数据和方法
- 把若干对象类组成一个层次结构的系统(继承)。
- 对象彼此间仅能通过传递消息互相联系。
面向对象的基本概念
- 对象:由一组属性和一组方法构成
- 类:具有相同属性和服务的一组对象的集合
- 消息:消息传递是对象与外部世界关联的唯一途径。
- 封装(encapsulation):将对象的状态信息和行为捆绑为一个逻辑单元,并尽可能隐藏 对象的内部细节,使得对状态的访问和修改只能通过封装提供的接口进行。
- 继承(inheritance):子类继承父类的操作和属性,便于复用。
- 多态(polymorphism):用相同的操作名在一个类层次的不同类中实现不同的功能。
面向对象建模
基于场景的方法
- 用例图
- 顺序图
- 活动图
- 泳道图
基于类的方法
- 类图
- 类之间的关系
- CRC 模型
基于行为的方法
- 状态图
设计
设计概述
设计原理
- 模块化
- 抽象
- 逐步求精
- 信息隐藏
-
模块独立
- 内聚
- 耦合
设计过程
面向对象设计
设计准则
- 弱耦合
- 强内聚
- 可重用
设计过程
- 类设计
- 体系结构设计
- 接口设计
- 构件设计
体系结构设计
体系结构风格
- 数据为中心的体系结构
- 管道-过滤器
- 主程序/子程序
- 分层体系结构
- 客户机/服务器
- MVC
构件设计
构件定义
构件设计过程
软件重用
- 重用级别
- 重用成分
- 重用方式
基本设计原则
- OCP(开闭原则)
- 针对接口编程原则
- SRP(类的单一职责)
- LSP(Liskov 替换原则)
- ISP(接口分离原则)
- LOD(迪米特法则)
- CAPR(合成/复用原则)
构件详细设计
- 图形工具
- 列表工具
- 语言工具
基于构件的软件工程
- 两个子过程
- 构件标准
用户界面设计
-
黄金规则
- 把控制权交给用户
- 减轻用户的记忆负担
- 保持界面一致
基于模式的设计
- 设计模式概念
- 分类
- 工厂模式
- 模板方法模式
实现
编码
良好编程实践
- 变量名有意义且一致
- 代码的“自文档”性
- 使用参数
编码风格
- 程序内部文档
- 数据说明
- 语句构造
配置管理
概念
- 什么是配置管理
- 什么是配置项
- 什么是基线
- 配置管理库
配置管理过程
- 标识配置项
-
变更控制
- 流程
- 版本控制
- 配置审计
- 状态报告
质量管理
原则
过程
软件质量
软件质量保证
- 评审
- 软件测试
- 软件正确性证明
软件度量
-
三个维度
- 产品
- 过程
- 项目
软件测试
软件测试基础
定义
目标
准则
方法
- 黑盒
- 白盒
软件测试策略
概念
常用测试策略
测试步骤
单元测试
- 5 个测试重点
- 测试过程
- 自动化测试
集成测试
- 非建增式集成测试
-
建增式集成
- 自顶向下
- 自底向上
- 回归测试
确认测试
- 确认与验证
- Alpha 测试
- Beta 测试
系统测试
软件测试技术
测试方案概念
白盒测试技术
- 5 种逻辑覆盖
- 基本路径测试
黑盒测试技术
- 等价划分
- 边界值分析
- 错误推测