软件工程-笔记

第一章 软件工程概述
什么是软件工程?
软件工程就是利用计算机和计算相关的知识来解决问题。
分析:将问题分解成可以理解并能够处理的若干小部分,确定问题的本质含义。
合成:一旦分析了这个问题之后,就需要根据针对问题不同方面的构件来构造解决方案。
为了帮助我们解决问题,我们会采用各种方法、工具、过程和范型。
方法:是产生某些结果的形式化过程。
工具:是用更好的方式来完成某件事情的设备或自动化系统。
过程:把工具和技术结合起来,共同生产特定产品。

范型:构造软件特定的方法或哲学。

软件工程师的角色是什么?
软件工程师使用计算机的功能进行工作,并将其作为一般解决方案的一部分,而不是研究计算机本身的理论和结构。
软件工程取得哪些成就?
• 在项目初期的分析阶段改正一个错误,比起把系统移交给客户再去改正,所需成本只有后者的 1/10.
•

由同事检查和评论彼此的设计和代码的过程能够揭示出其余 4/5 的故障。

什么是好的软件?

• 制造业的观点:质量是与规格说明的一致。
检查产品是否一次就构建正确,以避免花费大量重复劳动去修复产品支付后的故障。因此,制造业的观点是过程的观点,它提倡遵守良好的过程,
• 用户的观点:质量是恰好达到目的。
• 产品的观点:质量是与产品的内在特性相联系的。
他们假设良好的内部质量指标将会导致良好的外部质量,例如可靠性和可维护性等。我们必需开发和用户观点联系起来的模型。
产品的质量:建立模型,把用户的外部视图和软件人员的内部视图联系起来。(正确性、可靠性、有效性、完整性、可用性、可维护性、可测试性、灵活性、可移植性、可复用性、可操作性)
• 过程的质量:许多软件工程师认为开发和维护的质量和产品的质量是同等重要的。

• 商业环境背景下的质量:

系统的方法
系统:一组实体、一组活动、实体和活动之间关系的描述以及系统边界的定义。
系统开发可以首先在实际系统中实现一组变化,然后增加一系列变化以生成完整的设计方案,而不是从 当前一步一下跳到将来。
我们必须同时从两个不同的方面看待系统:静态的和动态的。
静态的:告诉我们系统如何运转。

动态的展示系统如何演变成最终的系统。

软件工程发生了多大的变化:
软件不仅执行用户需要的主要功能,而且还执行网络控制、安全性、用户界面和处理,及数据或对象管

理。传统的“瀑布”开发方法假定开发活动是线性前进的,这种方法不再灵活也不再适用于当今的系统。

改变软件工程的七大要素:商业产品投入市场的紧迫性、计算机在经济成本中的转变、功能强大的桌面

计算的可用性、互联网、面对对象的采用及其有效性、图形用户界面、软件开发瀑布的不可测性。

Wasserman 通过提出软件工程中 8 个基本概念来应对这一挑战。

1.抽象:在某种概括层次上对问题进行描述,使得我们能集中于问题的关键方面而不会陷入细节。 这个与 转换不同,转换是把问题转移到另外一个我们能够利用数字的知识来解决问题。

2.分析和设计方法及表示法:软件工程没有类似的标准,由此产生的误解是当今软件工程一个关键问题。

3.用户界面原型化:构建一个系统的小版本,可用于:
• 帮助用户或客户标示系统的关键需求
• 证明设计或方法的可行性

当我们和客户认为手头的问题的解决方案令人满意,迭代过程就终止了。

4.软件体系结构:系统的体系结构根据一组体系结构单元以及单元之间的相互关系来描述系统。
至少问题有 5 种方法可以将系统划分为单元。
1)基于指派到模块的功能
2)基于外部数据的结构
3)基于系统必须处理的事件
4)基于系统用户的输入

5)基于表示的对象的类以及它们之间的相互关系

5.软件过程:大型、复杂的系统需要更多的结构、检查和平衡。这种类型的高风险系统需要分析和设计工具、项目管理、配置管理、更复杂的测试工具以及对系统更严格的评审和因果分析。

6.复用:复用不仅仅是代码。但是构建一个长期、有效的可复用的构件库是很困难的。
• 通用性和专业性往往存在冲突
• 构造的成本

• 构件失效的权责,修改问题

7.测度:通过量化我们做了什么以及我们的目标是什么,就可以用通用的数学语言来描述我们的行动和结果,从而评估我们的进展。

8.工具和集成环境:任何工具集成必须处理下列 5 个问题
• 工具在异构型网络中互操作能力
• 用户界面的共性
• 工具和开发过程之间的连接

• 工具共享数据的方式一个工具通知和启动另一个

第二章 过程和生命周期的建模
将一组有序的任务称为过程,它(过程)涉及活动、约束和技术。
特性:

• 过程规定了所有主要的过程活动
• 遵从一组约束使用资源,并产生中间结果和最终产品
• 过程可以是用某种方式链接起来的子过程构成。过程可以组织称层次结构,以便使每个子过
程具有自己的过程模型。
• 每一个过程具有进入和退出标准。
• 活动可以按照一定的顺序加以组织,这样就可以清楚地知道应当什么时候执行一个活动。
• 每一个过程都有其知道原则,用于解释每一个活动的目标。
• 约束或控制可以应用于活动、资源或产品。

因为软件开发过程描述了软件产品从概念到实现、交互、使用和维护的整个过程,因此,有时候把软件开发过程描述称软件生命周期。

过程之所以重要,是应为它强制活动具有一致性和一定的结构。

过程不仅仅是步骤,它将步骤组织称使人们能够生产满足一系列目标和标准的产品。

软件过程模型:

原因:

软件开发活动中的活动、资源和约束的共同的理解。

发现过程及其组成部分中存在的不一致、冗余和遗漏的地方
开发团队可以根据目标评估候选活动是否合适

有助于开发团队理解应该在哪里对过程进行裁剪

瀑布模型:它是从制造业的角度看待软件开发的。随着人们对问题的逐步理解和对候选方案的评估,软件在不断演化。软件是一个创造的活动。没有说明我们创建最终产品过程中所需的往返活动的任何特有信息。

V 模型:v 模型使得隐藏在瀑布模型中的迭代和重做活动更加明确。V 模型关注活动和正确性。

原型化模型:原型化不仅仅附属于瀑布模型,它本身也是一种有效的过程模型的基础。

阶段化开发:
增量开发:定义一个小的功能子系统,然后在每一个心的发布增加新功能。

迭代开发:每一个心的发布中改变每个子系统的功能。

螺旋模型:把开发活动和风险管理结合起来。
它以需求和一个原始的开发计划为起点,在产生”操作概念“文档(它从高层描述系统如何工作)之前,该过程插入一个评估风险以及可选原型的步骤。一组需求被详细检查,以确
保需求尽可能完整和一致。
操作概念是第一次迭代的产品。
需求是第二次迭代的产品。
第三次迭代中,系统开发产生设计
第四次开发能够测试
螺旋模型的没一次迭代都需要根据需求和约束进行风险分析,以权衡不同的选择。
敏捷开发:相对于过程和工具,他们更强调做好自己的工作。
在生产运行软件上花费时间,而不是花费在编写文档上。
.
.
.
第三章 计划和管理项目
开发一个系统需要花多长时间
开发一个系统需要多少成本?
项目进度通过列举项目的各个阶段,把每个阶段分解成离散的任务或活动,来描述特定项目的软件开发
周期。进度还描绘这些活动之间的交互,并估算每项任务或活动将花费的时间。因此,进度是一个时间
线。
•
•
可以用 4 个参数对每个活动进行描述:前驱、工期、截止日期和终点。
前驱:活动开始之前必须发生的一个事件或一组事件。
工期:

终点:表示活动已经结束,通常是一个里程碑或可交付产品。

许多项目经理使用 CPM、甘特图或 PERT 方法来检查他们的项目。

第四章 获取需求

需求:对期望的行为的表达。

规格说明阶段:决定我们的软件将完成哪些需求(相对于由专用硬件设备处理的需求,由其它软件实现的需求,或者由操作员完成的需求)

设计阶段:制定关于将如何实现指定行为的计划。

需求引发
”只有通过同每一个与系统相关的人讨论需求,将这些不同的观点合并成一致的一组需求,并且与风险承担者一起评审这些文档,才能使所有人都对需求是什么达成一致。“

论点:用”论点集“来管理不一致性。由于风险承担者对领域的理解和需求会随着时间的推移而发生变化,设法在需求过程的早期解决不一致性是毫无意义的。

在软件开发的整个过程中,应该将风险承担者的看法文档化并维护在单独的”观点集“中。需求分析员定义观点之间的一致性规则,并对观点集进行分析,看看是否符合一致性规则。

如果违反”一致性“规则,将不一致性记录为”观点集“的一部分,这样,其他软件开发人员就不会进行错误地实现一个当对一个相关的”观点“进行修改时,对记录的不一致性重新进行检查,看看”观点集“还是不一致的;并对一致性规则定期检查,看看是否不断演化的”观点集“破坏了规则。

风险承担者:
• 委托人,为开发的软件支付费用的人
• 客户,购买软件的人
• 用户,熟悉当前系统,并将使用最终系统的人员。
• 领域专家,对软件必须自动化的问题很熟悉的人员。
• 律师或审计人员,对政府、安全性以及法律的需求熟悉的人员。

• 软件工程师或其他技术专家

需求的类型

功能需求:根据要求的活动来描述需要的行为。
功能需求定义解决方案空间的边界。解决方案空间是使得软件满足需求的设计方式的集
合。
质量需求:描述一些解决方案必须有的质量特性,如快速的响应时间、易用性,高可靠性...
设计约束:限制问题解决方案集的设计决策。
过程约束:对构建系统的技术和资源的限制。
质量需求似乎像所有产品都应该具备的”母性“特性。
解决冲突:请求客户对需求进行优先级划分通常是有用的。
• 绝对要满足的需求。
• 非常值得但不是必须的需求

• 可要可不要的需求

两种需求文档
需求定义:该文档通过描述打算构建的系统将要安装的环境的实体,以及关于这些实体的约束、监控和转换,来表述需求。

需求规格说明:系统边界清楚地说明了可以被系统监控和控制的那些实体。

需求的特性
• 需求是正确的吗?
• 需求是完备的吗?
如果这个需求制定了所有约束下的、所有状态下的、所有可能的输入的输出以及必须的行为,那么这组需求就是完备的。
• 需求是无二义性的吗?
• 需求是一致的吗?
• 需求是可行的吗?
• 每一个需求都是相关的吗:让风险承担者集中于必需的,值得要的需求。
• 需求是可测试的吗:

• 需求是可跟踪的吗?

建模表示法
实体-联系图:略
UML: 用例图、类图、时序图、合作图、状态图、OCL 特性...
需求确认:检查我们的需求定义是否准确地反映客户的需求。

需求验证:检查一个文档或制品是否符合另一个文档或制品。

第五章 设计体系结构
软件系统设计是一个迭代的过程。
第一步:分析系统的需求规格说明以及标识最终系统所必须展现的所有关键特性或约束。

• 这些性质可以帮助我们确定哪种体系风格在我们的设计中是有用的。
• 在第一步,我们迭代地进行三项活动:描绘体系结构计划、分析体系结构怎么能很好此促进所期
望的性质、根据分析结果改进和优化体系结构计划。
• 我们关注的是系统级别的决策,如通信、协调、同步和共享。

第二步:模型文档化

• 每个模型都是结构体系的一个视图,这些视图是互相联系的,我们必须清楚视图之间的联系以及
他们如何写作以最终形成一个完整一致的设计。

第三步:设计评审。

体系结构模型
我们使用体系结构模型的方式有以下 6 种

• 理解系统:将做什么,以及如何做?
• 确定系统哪些部分复用已经构建的系统的元素
• 展示系统构建的蓝图
• 推测系统会如何演变,包括性能、成本以及原型开发的问题
• 分析依赖关系,选择最合适的设计

• 为管理决策提供支持,了解实现和维护时所固有的风险

体系结构视图:描述这个系统的分布,或者它能够展示的设计系统提供的所有服务以及这些服务间如何协调操作的视图,而不管服务与代码模块之间是如何对应的。

• 分解视图:将系统描述为若干个可编程的单元。
• 依赖视图:软件单元之间的依赖(过程依赖、数据依赖)。对某个软件单元的调整,它可以有效地帮助我们看清该改变的影响。
• 泛化视图:一个软件单元是否为另一个单元的特例或泛化。
• 执行视图:在考虑到构建和连接器的情况下,展示系统运行时的结构。每个构件都是不同于其他构件之间的通信机制,连接器是一种构建之间的通信结构。
• 实现视图:在代码单元和原文件建立映射。
• 部署视图:在运行时实体和计算资源之间建立起映射。

• 工作分配视图:

系统体系结构代表了该系统的整体设计结构,因此,它应该是所有这些视图的集合。

软件体系结构风格是已建立的、大规模的系统结构模式。

• 管道和过
• C\S 架构
• P2P 网络
• 发布---订阅
• 信息库

• 分层

文档化软件体系结构

SAD 应该包含下面的信息
• 系统综述
• 视图
• 软件单元
• 分析数据和结果
• 设计合理性

• 定义、术语表、缩写词

软件产品线:建立产品线一个显著特征是把衍生产品集视为产品系列。
一个系统的共性会被描述位可复用资源的集合(需求、设计、代码和测试用力)

• 需求
• 软件体系结构:产品间的不同点可以独立化或参数化为体系结构中的变量
• 模型和分析结果:单个产品的体系结构模型和分析很有可能建立在产品线的体系结构分析的基础
上的。
• 软件单元:包括重要的设计工作的复用,如借口规格说明、其他单元的联系和交互、文档、测试
用例、支撑代码
• 测试:测试计划、测试文档、测试数据和测试环境复用
• 项目计划
• 团队组织

产品线体系结构的优势

• 构建替换
• 构建特化
• 产品线参数:把软件单元当成产品线体系结构的参数,这样各种参数可以形成各种系统的配置。

• 体系结构扩展和收缩:

第六章 设计模块
设计原则:把系统功能和行为分解成模块化的指导方针。

模块化:是一种把系统中各不相关的部分进行分离的原则,以便于个部分能够独立研究。我们使用两个概念来度量模块的独立程度。耦合度和内聚度。

耦合度:

• 内容耦合:当一个模块修改了另外一个模块的内部数据项,一个模块修改了另一个模块的代码,或一个模块中的分支转移到另外一个模块中的时候,就出现内容耦合。
• 公共耦合:对公共数据的改变意味着需要通过反向跟踪所有访问过该数据的模块来评估该改变的影响。
• 控制耦合:当某个模块通过传递参数或返回控制码来控制另外一个模块的活动时,我们就说这两个模块是控制耦合的。
• 标记耦合:一个复杂的数据结构来从一个模块到另一个模块传送信息,并且传递的时该数据结构本身,那么这两个模块之间的耦合就是标记耦合。
• 数据耦合:如果传递的只是数据值,那么就是数据耦合。内聚度:模块内部元素(数据、功能、内部模块)的“粘合”程度。
• 巧合内聚:不相关的功能,进程或数据处于同一个模块中。
• 逻辑内聚:当一个模块中的各个部分之通过代码的逻辑结构关联。
• 时态内聚:数据和功能仅仅因一个人物中同时被使用而形成联系。
• 过程内聚:一个模块的功能组合在一起是为了确保某个顺序。
• 通信内聚:基于数据集的内聚。
• 功能内聚:一个模块中包含了所有必须的元素,并且每一个处理元素对于执行单个功能
来说都是必须的。某个功能内聚的模块只执行模块设计的功能。

• 信息内聚:在功能内聚的基础上,将其调整为数据抽象化和基于对象的设计。

接口:为系统其余部分定义了该软件单元提供的服务,以及如何获取这些服务,对环境的要求。
软件单元接口的规格说明:以单元的边界为依据对软件单元做出描述:该单元的访问函数、参数、返回值和异常。还包括以下几点

• 目标
• 前置条件
• 协议
• 后置条件

• 质量属性

信息隐藏:每个软件单元都封装一个将来可以改变的独立的设计决策,然后我们根据外部可见的性质,在接口和接口规格说明的帮助下描述各个软件单元。

“设计决策”包括数据形式或数据操作、硬件设备或者其他需要和软件交互的构件、构件之间的消息传递的协议、或者算法的选择。

增量式开发:可以使用单元之间的依赖关系来设计一个增量式设计开发进度表。

抽象:

通用性:其实现原则是:
• 将特定的上下文环境信息参数化
• 去除前置条件

• 简化后置条件:把一个复杂的软件单元分解成若干个具有不同后置条件的单元,再将他们集中起来解决原来需要解决的问题。

面向对象设计模式
• 工厂方法模式:
。
。
。

设计中其他方面的考虑:数据管理、异常处理、用户界面设计,面对对象度量

第七章 编写程序

第八章 测试程序

故障类型:

• 算法故障:由于处理步骤中的某些错误,是的对于给定的输入,构建的算法或逻辑没有产生适当的输出。
• 精度故障
• 压力故障
• 边界故障
• 性能故障:不能以需要规定的速度执行。
• 恢复故障:

测试步骤:

1. 功能测试
2. 性能测试
3. 验收测试

4. 安装测试

第九章 测试系统
系统配置:是向特定客户交付的一组系统构建。
配置管理:确保需求、设计或代码中的变化反映在文档中以及影响到的其他构建中的。
用户培训
操作员培训
培训助手:文档、联机帮助...

第十章 交付系统

第 11 章 维护系统
系统运转之后,任何针对系统改变所做的工作,都被认为是维护。
系统的类型

• S 系统:问题是完全定义的问题,并且存在一个或多种正确的解决方案,以这种方式构造的系统。
• P 系统:先抽象地描述问题,然后,根据我们的抽象描述,编写系统的需求规格说明。
• E 系统:融入在现实世界的系统,并随着现实世界的变化而改变。

维护活动

• 理解系统
• 维护系统文档
• 扩展功能,适应变化的需求
• 发现问题或系统失效的根源
• 改正故障
• 重构代码
• 重新编写设计和代码构建
• 维护对系统所做的改变