§1
软件工程是一门学科,目的是生产出没有错误的软件,按时并且在预算内交付,满足用户的需求。
软件工程范畴非常广,可以归入数学或计算机科学,其他方面可以落入经济学、管理学或心理学的范畴。
软件危机指软件产品的质量低得通常不能接受,并且不能满足交付日期和预算限制。考虑到软件危机的周期长且难预测,可能将软件危机重新命名为软件萧条。
生命周期模型是对在构建一个软件产品时应当完成的步骤的描述。
将整个生命周期模型划分为一系列较小的步骤,称为阶段。
对某个具体的软件产品所做的一系列实际步骤,从概念开发到最终退役,称为该产品的生命周期。
瀑布模型(传统生命周期模型的6个阶段):
1.需求阶段:提取客户需求
2.分析(规格说明)阶段:软件项目管理计划
3.设计阶段:结构设计(模块+详细设计)、两份设计文档
4.实现阶段:代码编写+单元测试、集成后验收测试
5.交付后维护:纠错性和增强性维护
6.退役
传统软件开发方法可以描述为开发——维护模型
回归错误是指对软件某处进行修改时,不小心在与该处明显没有关联的另一处造成了新错误。
面向对象设计也叫职责驱动设计或按合同设计。
客户是想建造某一产品的个体。开发者是小组的成员,负责建造该产品。用户是客户委托商品所代表利益的人。
客户和开发者可能是同一组织的部分。——内部软件开发
客户和开发者是完全独立的组织中的成员。——合同软件
商用现货软件:可以卖的软件、开源软件
§2
进化树生命周期模型:显示了事件的顺序。而瀑布模型不可以。
特性的蔓延:连续地向需求中加入小的甚至是琐碎的特性。
联动引起的退化性差错。
迭代-递增生命周期模型,有五个核心工作流:需求工作流、分析工作流、设计工作流、实现工作流、测试工作流
迭代-递增模型的特点:
1.为检查软件产品是否正确提供多个机会
2.在生命周期的相对早期可以确定其蕴涵结构的健壮性(具有可以连续扩展以包含下一次递增的属性)
3.较早地减轻风险
4.总是有该软件的一个工作版
5.经验数据表明它很有用
其他模型:
1.编码-修补生命周期模型
2.瀑布生命周期模型
3.快速原型开发生命周期模型
4.开源生命周期模型(纠正性、完善性、适应性维护)
5.敏捷过程
6.同步-稳定生命周期模型(微软)
7.螺旋生命周期模型
各种生命周期模型的比较:
生命周期模型 | 长处 | 短处 |
---|---|---|
进化树模型 | 与现实世界软件开发最接近的模型,与迭代-递增模型等价 | |
迭代-递增生命周期模型 | 与现实世界软件开发最接近的模型,蕴涵统一过程方法 | |
编码-修补生命周期模型 | 适用于不需要任何维护的小程序 | 总的来说不适合重要的程序 |
瀑布生命周期模型 | 纪律性强制的方法,文档驱动 | 交付的产品可能不符合客户的要求 |
快速原型开发生命周期模型 | 确保交付的产品符合客户的要求 | 还没有证明无懈可击 |
开源生命周期模型 | 少量实例中工作得相当好 | 实用性有限,通常不太起作用 |
敏捷过程 | 客户的需求模糊时能很好地工作 | 似乎只适合小规模项目 |
同步-稳定生命周期模型 | 能满足未来用户的要求,确保各组件能够成功集成 | 除了在Microsoft公司,还没有广泛地应用 |
螺旋生命周期模型 | 风险驱动 | 只能用于大型的内部软件产品,开发者必须精通风险分析和风险排除 |
§3
今天最主要的面向对象的方法是统一过程,统一建模语言UML。
需求流:让开发组织确定客户的要求。(目标)
步骤:理解问题域并建造业务模型。
业务模型是说明目标产品代价合理性的文档。
限制条件:最终期限(主要)、可靠性、成本(重要)
最初对客户需求的调研有时称为概念探究。
分析流(提取类):分析和提取需求,以获得正确开发软件产品和易于维护它所必需的需求。(目标)
模糊是自然语言固有的特性。规格说明文档可能是矛盾的。
软件项目管理计划:可交付的东西(客户将要得到的)、里程碑(时间)以及预算
设计流(类的设计):详细设计,细化分析流的制品,直至材料处于程序员可实现的形式。(目标)
实现流:用选择的实现语言实现目标软件产品。(目标)
测试流:在统一过程中,测试从始至终与其他工作流并行进行。
测试流的性质随着被测试的制品的不同而不同。对所有制品都至关重要的是可追踪性。
单元测试:对组件进行系统测试 -> 集成测试:检查组件是否正确组合在一起 -> 产品测试:对产品功能进行整体测试 -> 验收测试:客户用真实数据 -> 交付后维护:1.检查要求的改变已经正确实现了 2.确保在对产品要求的改变时,不做其他无意识的改变 =>回归测试
统一过程的各阶段:开始、细化、构建、转换
开始阶段目标(需求流):决定是否值得开发目标软件产品,主要目标是明确提出的软件产品是否经济上可行
步骤:1.经济效益、按时交付、风险 2.明确风险
细化阶段目标(分析和设计流):细化最初的要求,细化体系结构,监控风险,细化它们的属性,细化商业案例以及生成软件项目管理计划。
构建阶段目标(实现、测试流):产生软件产品的第一个可工作版本(β版)。
转换阶段目标(完成后维护):确保客户的需求切实得到满足。
能力成熟度模型(CMM)是一组用于改进软件过程的相关策略,不考虑生命周期模型。
成熟度是过程本身良好程度的度量。
成熟度级别:
1.初始级:临时过程
2.可重复级:基本项目管理(根据经验对产品进行计划和管理)
3.定义级:过程定义(管理和技术有明确定义)
4.管理级:过程测量(有质量目标和生产目标)
5.最优级:过程控制(统计质量和过程控制技术对软件组织进行指引)
关键过程区是一个组织在迈向下一级别时要努力实现的目标。
统一过程是迄今为止将大型问题作为一些较小,较独立的子问题解决的最好办法。
它提供了递增和迭代的一个框架,这个机制用于解决大型软件产品的复杂性。
§4
布鲁克斯法则:向一个已经延期的软件项目增加人员会使项目完成得更晚。
民主小组:基本概念(无我编程)
优点:对查找错误的积极态度
传统的主程序员小组方法:关键特性(专业化和等级性)
主程序员和备程序员
编程秘书-文档
不实用性:主/备程序员都很难找到,秘书也是
现代编程小组:主程序员由两人替代(小组领导、小组经理)
小组领导:负责技术,小组经理:负责所有非技术型的管理事务
适当分散决策过程
同步-稳定小组(微软)
敏捷过程小组:结对编程,具备无我编程的特点
开源编程小组
人员能力成熟度模型,描述管理和开发一个组织的人力资源的最佳实践。
各小组组织方法的比较:
小组组织 | 优点 | 缺点 |
---|---|---|
民主小组 | 由于积极地寻找错误,因而代码质量高,特别适用于解决难的问题 | 有经验的人反感新手的评价不能从外部强加 |
传统的主程序员小组 | 《纽约时报》项目的主要成功之处 | 不实用 |
修改的主程序员小组 | 有许多成功的案例 | 没有与《纽约时报》项目可比拟的成功范例 |
现代分级编程小组 | 小组经理/小组领导结构避免对主程序员需求,可扩展,必要时支持分散决策 | 除非明确小组经理和小组领导间的负责范围,否则容易产生问题 |
同步-稳定小组 | 鼓励创造性,确保大量开发者为共同目标工作 | 在Microsoft公司之外还没有该方法应用的实例 |
敏捷过程小组 | 程序员不测试自己的代码,如果一个程序员离开不会有损失,经验欠缺的程序员可以向其他人学习,代码具有小组所有权 | 还没有更多的实例证实它的功效 |
开源小组 | 少数项目非常成功 | 应用面窄,需由出色的有号召力的人领导,需顶尖高手参与 |
§5
分析工具:
1.逐步求精法:尽可能将细节的定义推延到最后(迭代+递增),以便集中精力在重要的事项上。
米勒法则:一次一个人最多只能集中精力于7桩事情。
2.成本-效益分析法:对比估计的未来收益和预测的未来成本。
3.分治:最古老的分析工具。
4.关注分离
5.软件质量:
产品度量:测量产品本身的某个特性。
过程度量:开发者使用这些度量推断软件开发过程的信息。
软件工具(CASE):在开发过程的较早工作流(需求、分析、设计)帮助开发者的CASE工具称为高端CASE或前端工具,帮助实现流和交付后维护的CASE工具称为低端CASE或后端工具。
数据字典:在产品中定义的所有数据的计算机化列表。
另一个用处是为报表生成器和屏幕生成器提供数据。报表生成器产生生成报表所需的代码。屏幕生成器帮助软件开发者产生用于数据捕获屏幕的代码。
编程工具:指诸如文本编辑器这样的CASE工具。
小编程:单模块,大编程:模块级进行的,多编程:由小组进行的软件开发
多编程结合了小编程和大编程两方面
结构编辑器:可以随时检测程序员键入的语法错误,需要支持在线接口检查。
软件版本:修订版、变种版
构建大型产品时,版本控制,配置控制,建造工具是最基本的。
CASE技术——提高生产力
§10
我们人类处理信息量的限制的一个办法是使用逐步求精方法。
迭代和递增都是软件工程的固有特性。
核心工作流:需求、分析、设计、实现、测试
主要的面向对象方法是统一过程,统一过程是使用图形化语言——统一建模语言UML来表示要开发的软件。
模型是一套图表,表示软件产品的一个或多个方面。
需求工作流的目标是明确客户需要什么。
分析工作流的目标是分析和提炼需求。
实现工作流的目标是用选择的实现语言实现目标软件产品。
测试工作流从始至终与其他工作流并行进行。
成本-效益分析法是对比估计的未来收益和预测的未来成本。
度量(5种主要的基本度量)(1)规模 (2)成本 (3)持续时间 (4)工作量 (5)质量
CASE代表计算机辅助软件工程。最简形式是软件工具,例如画UML图的工具。
数据字典、报表生成器和屏幕生成器
每个制品的特定版本集是这个产品版本的配置。
基线是产品中所有制品的配置。
重用指使用一个产品中的组件来简化另一个功能不同的产品的开发。#
§11
需求流的整体目标是让开发组织确定客户的需要。
应用域是目标产品应用的特定环境。
发现客户需求的过程称为需求启发(或需求捕获)。
推敲和补充的过程称为需求分析。
术语表:在该领域应用的技术词汇列表和对应的解释。
业务模型是对公司的商业过程进行的描述。
访谈:程式化的访谈和非程式化的访谈
模型是代表要开发的软件产品的一个或多个方面的UML图。
用例为软件产品本身和软件产品的使用者之间的交互建立模型。
系统的使用者可以扮演不止一个角色。参与者不一定是人。
面向对象范型是迭代。功能性需求指定目标产品必须能够执行的行为。
非功能性需求指定目标产品本身的属性:例如平台限制、响应时间、可靠性
快速原型是仓促建立的软件,展示目标软件产品的主要功能。
用户友好一词指人类与软件产品沟通的容易性。
窗口、图标和下拉式菜单是图形用户界面的要素。
§12
规格说明文档是客户和开发者之间的一种合同。
结构化系统分析(半形式化技术)共有9个步骤。
步骤1,画DFD:确定逻辑数据流。
步骤2,决定哪部分计算机化以及如何计算机化(批处理或联机)
对于处理量大和要求严格控制的情况,经常选择批处理;对于小容量计算机,用联机处理。
步骤3,确定数据流的细节:数据字典
步骤4,定义处理的逻辑
步骤5,定义数据存储:数据实时访问图
步骤6,定义物理资源
步骤7,确定输入-输出规格说明
步骤8,确定大小
步骤9,确定硬件要求
有穷状态机,在需求分析时做,是形式化技术。
一个有穷状态机包括:状态集J 输入集K 转换函数T 初始状态S 最终状态集F
当前状态与事件与谓词 => 下一个状态
Petri网:形式化技术。
禁止弧:没有令牌也能转换。
Z:形式化技术。
一个规格说明文档必须既是非形式化的,足以让客户理解,又是形式化的,足以让开发小组将其作为要建造的产品的唯一描述。
§13
面向对象分析(OOA)是面向对象范型的半形式化分析技术。
分析流的两个目标:
1.得到对需求更深的理解
2.按设计和实现易于维护的思路描述需求。
统一过程有三种类:
实体类为长期存在的信息建模。
边界类为软件产品和它的参与者之间的交互行为建模。
控制类为复杂的计算和算法建模。
抽取实体类:功能建模,实体类建模,动态建模
实体类建模:名词抽取法:阶段1,用一个段落描述软件产品;阶段2,分辨名词
分析流的基本目标是生成规格说明文档。
§14
面向操作设计,强调操作,目标是设计具有高内聚性的模块。
面向数据设计,首先考虑的是数据。首先确定数据结构,然后设计符合数据结构的过程。
数据流分析(DFA)是一项得到具有高内聚模块的传统设计技术。
程序描述语言(PDL)——“伪码”
事务是从产品用户的观点来看的一个操作。
统一过程的前提是知道面向对象设计。
§15
二进制机器码是第一代语言。
第二代语言是汇编语言。
C、C++、Pascal或Java是第二代语言。
第四代语言:4GL。
实现流的目标是用所选的实现语言实现目标软件产品。
单元测试的测试数据可以用两个基本的方法系统地构建。
第一个是规格说明测试,这个技术也称为黑盒测试、行为测试、数据驱动测试、功能测试以及输入/输出驱动测试。
另一个是代码测试,白盒测试。
黑盒测试:
涉及测试用例、等价类划分、边界值分析
等价类成员+边界值+临近边界值
白盒测试:语句、分支和路径覆盖。
每个新的代码制品加入到已集成的模块中时都必须进行测试,这称为集成测试。
当集成过程结束时,软件产品作为一个整体进行测试,称为产品测试。
交给客户进行验收测试。
§17
UML是统一建模语言。
空菱形表示聚合,聚合是UML中表示局部-整体关系的术语。
线的端点处旁边的数字表示多重性。
组合是聚合的一个更强形式,部分-整体的关系。用一个空心菱形表示。
继承是泛化的一个特例,用空心三角形表示。
关联的方向需由一个实心三角形式的箭头来明确。
用例是软件产品的外部用户(参与者)和软件产品自身的交互模型。
包含关系在UML中当作构造型对待。
扩展关系:用例是标准用例的变体。
交互图显示软件产品中的对象与另一个对象交互的方式。
交互图:顺序图和通信图(协作图)
对象可以向本身发送消息——自调用
状态图
活动图:显示各种事件是如何协调的.
组件图:显示软件组件之间的依存度,包括源代码、编译代码以及可执行载入映像。
部署图:显示每个软件组件安装(或部署)在哪个硬件组件上。