软件工程复习要点.docx

软件工程复习要点.docx

《软件工程复习要点.docx》由会员分享，可在线阅读，更多相关《软件工程复习要点.docx（29页珍藏版）》请在冰豆网上搜索。

软件工程复习要点

软件工程关键概念和解题方法

ByTechiah

软件的定义

软件是：

⑴指令的集合（计算机程序），通过执行这些指令来提供期羞的特性、功能和性能；

⑵数据结构，使得程序能够合理地操纵信息；

（3）文档，描述程序的操作和使用。

软件的特性

・软件是开发/设计出来的，而不是传统意义上生产制造出来的。

・软件不会“磨损”

•虽然这个产业正在向基于构件的构建模式发展，但大多数软件仍是按照客户要求定制的。

软件不会磨损，其失效率应该呈现为“理想曲线”。

但是软件将会面临变更，每次变更都町能引入新的错误，使得失效率像“实际曲线”陡然上升。

软件工程

种子定义：

（软件工程是）建立和使用一套合理的工程原则，以便经济地获得可靠的、可以在实际机器上高效运行的软件。

IEEE定义：

软件工程是：

（1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。

（2）

（2）在⑴中所述方法的研究。

五种框架活动

沟通（与客户沟通与协调，以理解项目目标）

策划（工作、技术任务、风险、资源、产品，进度计划）

建模（用模型来理解软件需求，完成设计）

需求分析

设计

构建（编码、测试）

代码生成

测试

部署（软件交付用户，用户测评并反馈）

过程模式类型

步骤模式一定义与过程的框架活动相关的问题。

例如“建立沟通（一个框架活动）”，它可能包括需求获取等任务模式任务模式一定义了与软件工程动作或工作任务相关、关系软件工程实践成败的问题。

例如“需求获取”是一个任务模式

阶段模式一定义在过程中发生的框架活动序列，即使这些活动流本质上是迭代的。

例如“螺旋模型”和“原型开发”就是两种阶段模式。

过程流

线性过程流：

沟通->策划->建模->构建->部署

迭代过程流：

返祖边：

策划->沟通，建模->建模，构建->沟通

演化过程流：

成坏，部署完成后进行增量交付

并行过程流：

沟通->建模连边

（以上内容详见图）

惯用模型

增毘模型（图见P32）

适用情形：

初始的软件需求明确，但是整个开发过程却不宜单纯运用线性模型。

同时，可能迫切需要为用户迅速提供一套功能有限的软件产品，然后在后续版本中再进行细化和扩展功能。

特点：

综合了线性过程流和并行过程流的特征。

每个增量都提交一个可以运行的产品。

原型开发模型（图见P33）

适用情形

客户提出了一些基本功能，但没有详细定义功能和特性需求

开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况并不确定特点

很少是好用的，可能太慢太人，难以使用。

一般作为被丢弃的系统。

UML-统一建模语言

统一过程（UP）（图见P41）

沟通+策划->起始

策划+建模->细化

构建->构建

构建+部署->转换

发布，软件增量->生产

敏捷软件开发的宣言

“我们正在通过亲身实践以及帮助他人实践的方式来揭示更好的软件开发之路，通过这项工作，我们认识到：

个人和他们之间的交流胜过了开发过程和工具

可运行的软件胜过了宽泛的文档

客户合作胜过了合同谈判

对变更的良好响应胜过了按部就班地遵循计划

也就是说，虽然上述右边的各项很有价值，但我们认为左边的各项具有更人的价值。

”

敏捷过程

•是由客户对他们需求的描述（场景）所驱动的

・意识到计划是短期的

・着重强调构建活动的软件迭代开发

・交付多个软件增量

・适应变更的出现

收集需求

目的是

标识问题

提出解决方案的元素

协商不同方法

确定一套解决需求问题的初步方案

质量功能部署（QFD）

・功能部署决定系统所需的每一个功能的“价值”（由客户感知）

•信息部署确定数据对彖和事件

・任务部署检查系统行为

・价值分析决定需求的相对优先权

分析模型的元素

基于场景的元素

功能说明一一处理软件功能的描述

用例一一描述“参与者”和系统之间的交互作用基于类的元素

由场景喑不

行为元素

状态图

面向数据流元素

数据流图

桥接

系统元素-分析模型-设计模型

域分析（一种普适性活动）

软件域分析是识别、分析和详细说明某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的……

［面向对象的域分析是］在某个特定应用领域内,根据通用的对彖、类、部件和框架，识别、分析和详细说明公共的、可复用的能力

分析模式

模式名称：

捕获模式本质的描述符。

目的：

描述该模式实现了或代表什么。

动机：

说明怎样用模式解决问题的一个场景。

影响环境：

对外部问题（影响）的描述，即能够影响如何使用模式，当应用该模式时，影响即将被解决的外部问题。

解决方案：

对如何应用模式来解决强调结构和行为问题的描述。

效果：

解决了发生在应用模式时和应用过程中存在权衡的问题。

设计：

通过使用已知的设计模式讨论如何实现该分析模式。

已知应用：

在实际系统中使用的例子。

相关模式：

与命名模式有关的一个或更多分析模式，因为

（1）通常与命名的模式共同使用；

（2）结构上与命名模式相似；

（3）是命名模式的一个变体。

需求监视

在增量开发时特别需要：

分布式调试-发现错误及确定其原因。

运行时验证-确定软件是否与其规格说明相匹配。

运行时确认-评估演化的软件是否满足用户目标。

业务活动监视-评价系统是否满足业务目标。

演化和代码设计-在系统演化时給利益相关者提供信息。

需求建模

基于场景的模型

从用户角度来看的系统。

（用例图）数据模型

表示数据在系统内是如何转换的。

面向类的模型

定义对彖、属性和关系。

（类图）

面向流的模型

表示数据在系统内是如何转换的。

（数据流图）行为模型

表示事件对系统状态的影响（状态图）

事件流是通过文字描述一个用例的方法，说明用例的逻辑流程。

软件域分析是识别、分析和详细说明某个特定应用领域的公共需求，特别是那些在该应用领域内被多个项目重复使用的……［面向对象的域分析是］在某个特定应用领域内，根据通用的对象、类、部件和框架，识别、分析和详细说明公共的、可复用的能力

需求建模策略

需求建模的一种视角，被称作结构化分析，它考虑数据和把数据转换为独立实体的过程。

数据对彖的建模方式是，定义对象的属性和关系。

操纵数据对彖的过程的建模方式是，表明当数据对象流过系统时它们如何转换数据。

分析建模的第二种方法，被称作面向对象分析，该方法关注于

定义类

类彼此之间协作以影响客户需求的方式

基于类建模表示：

・系统操纵的对彖

•操作（也称作方法或服务），应用于对彖以影响操纵。

•对象之间（某种层级）的关系

・协作，在所定义的类之间发生

基于类的模型元素包扌舌类和对彖、属性、操作、CRC模型、协作图和包。

分析类

分析类代表“系统中具备职责和行为的事物”的初期概念模型。

这些概念模型最终将演进为设计模型中的类和子系统。

分析类表现为如下方式之一：

•外部实体（例如其他系统、设备、人员），产生或使用基于计算机系统的信息

•事物（例如报告、显示、字母、信号），问题信息域的一部分

•偶发事件或事件（例如所有权转移或完成机器人的一组移动动作），在系统操作坏境内发生

•角色（例如经理、工程师、销售人员），由和系统交互的人员扮演

•组织单元（例如部门、组、团队），和某个应用系统相关

•场地（例如制造车间或码头），建立问题的环境和系统的整体功能

・结构（例如传感器、四轮交通工具、计算机），定义了对象的类或与对彖相关的类例子见P109

潜在类

保留信息。

只有记录潜在类的信息才能保证系统正常工作，在这种分析过程中的潜在类是有用的。

所需服务。

潜在类必须具有一组可确认的操作，这组操作能用某种方式改变类的属性值。

多个属性。

在需求分析过程中，焦点应在于“主”信息；事实上，只有一个属性的类可能在设计中有用，但是在分析活动阶段，最好把它作为另一个类的某个属性。

公共属性。

可以为潜在类定义一组属性，这些属性适用于类的所有实例。

公共操作。

可以为潜在类定义一组操作，这些操作适用于类的所有实例。

必要需求。

在问题空间中出现的外部实体，和任何系统解决方案运行时所必需的生产或消费信息，几乎都被定义为需求模型中的类。

（pllO）

类的类型

实体类，也称作模型或业务类，是从问题说明中直接提取出来的（例如FloorPlan和Senor）。

边界类用于创建用户町见的和在使用软件时交互的接1丨（如交互屏幕或打印的报表）。

控制类自始至终管理“工作单元”[UML03]o也就是说，设计控制类可以管理：

・实体类的创建或更新；

・当边界类从实体对象获取信息后的实例化：

・对象集合间的复杂通信；

・对彖间或用户和应用系统间交换数据的确认。

类之间三种不同的通用关系[WIR90J:

is-part-of（是一部分）关系--复合聚合类

has-knowledge-of（有知识）的关系

depends-upon（依赖）关系

评审CRC模型

所有参加（CRC模型）评审的人员拿到一部分CRC模型索引卡。

拆分协作卡片（也就是说每个评审员不得有两张存在协作关系的卡片）。

分类管理所有的用例场景（以及相关的用例图）。

评审组长细致地阅读用例。

当评审组长看到一个已命名的对象时，给拥有相应类索引卡的人员一个令牌。

当令牌传递时，索引卡的拥有者需要描述卡上记录的职贵。

评审组确定（一个或多个）职责是否满足用例需求。

如果记录在索引卡上的职责和协作不能满足用例，就需要修改卡片。

修改可能包括定义新类（和相关的CRC索引卡），或者在已有的卡上说明新的或修改的职贵、协作。

类状态具有被动和主动两种特征［CHA93］。

被动状态只是某个对彖所有属性的当前状态。

一个对彖的主动状态指的是对象进行持续变换或处理时的当前状态。

系统的状态

状态一一在给定的时间内，观察到的一组系统行为特征的情况状态转换一一从一个状态到另一个状态的运动

事件一一能导致系统表现出一些可预测的行为方式的发生活动一一以作出转变结果形式出现的过程

行为建模

1.列出不同的系统状态（系统如何表现？

）

2.表明系统如何从一个状态转变为另一个状态（系统怎样改变状态？

）

指出事件

指出活动

3.画状态图或顺序图

WebApp的需求模型

内容分析。

给出由Web应用系统提供的全部系列内容。

内容包括文本、图标和图像、视频和音频数据。

数据建模用来确定和描述每一个数据对彖。

交互分析。

详细描述了用户与Web应用系统采用了哪种交互方式。

开发用例提供这种交互方式的详细描述。

功能分析。

作为交互分析一部分创建的使用场景（用例）定义了将用于Web应用系统内容并描述其他处理功能的操作。

所有的操作和功能都被详细的描述。

配置分析。

详细描述Web应用系统驻留的环境和基础设施。

交互模型

由四个元素组成

用例

顺序图

状态图

用户界面原型

软件设计宣言-良好的软件设计应该展示：

坚固：

程序应该不含任何妨碍其功能的缺陷。

适用：

程序应该符合开发的目标。

愉悦：

使用程序的体验应是愉快的。

设计原则

设计过程中不要有“井蛙之见”。

设计应起源于分析模型。

设计不要白费力气做重复工作。

在软件和真实世界的问题之间，设计应能“最小化知识距离”[DAV95]。

设计应表现出_致性和集成性。

设计结构应适应变化。

即使遇到数据、事件或操作条件异常时，设计结构应能温和处理。

设计不是编码，编码不是设计。

创建设计时就应对其质量进行评估，而不是创建之后。

评审设计以最小化概念上的（语义的）错误。

设计的基本概念

抽象一一数据、过程、控制

体系结构一一软件的整个结构

模式一一已证实的解决方案的"精髓”

关注点分离一一任何复杂问题如果被分解为若干块，该复杂问题更容易地被处理。

模块化一一数据和功能的划分

信息隐蔽一一控制接口

功能独立一一专一的功能和低耦合

求精一一所有抽彖精化的细节

方面种理解全部需求如何影响设计的机制

重构种简化设计的重新组织的技术

面向对象设计概念一附录II

设计类一一提供设计细节，使分析类得以实现

设计模式模版

模式名一一以简短但富于表现力的名字描述模式的本质

目的一一描述模式及其做什么

也称为一一列出任何模式的别名

动机一一提供问题的实例

适用性一一指出模式适用的具体设计解决方案

结构一一描述要求实现模式的类

参与者一一描述要求实现模式的类的职责

协作描述参与者如何协作，以完成他们的职责

结构一一描述了影响模式的“设计力量”和在实现模式时，必须考虑的潜在权衡相关模式一一相关设计模式的交叉索引

模块功能独立通过开发具有“专一”功能和“避免”与其他模块过多的交互的模块，可以实现功能独立。

独立性有两条定性标准进行评估：

内聚性显示了某个模块相关功能的强度。

一个内聚的模块执行一个独立的任务，与程序的其他部分构件只需要很少的交互。

简单地说，一个内聚的模块应该（理想情况下）只完成一件事情。

耦合性显示了模块间的相互依赖性。

耦合性依赖于模块之间的接11复杂性、引用或进入模块所在的点以及什么数据通过接口进行传递。

方面

考虑两个需求，A和B。

“如果已经选择了一种软件分解［精化］,在这种分解中，如果不考虑需求A的话，需求B就不能得到满足”［Ros04］,那么需求A横切需求B。

方面是一个横切关注点的表示。

重构

Fowler［FOW99］用下面的方式定义重构：

“重构是使用这样一种方式改变软件系统的过程：

不改变代码【设计］的外部行为而是改进其内部结构。

”

当重构软件时，检查现有设计：

冗余性

没有使用的设计元素

低效的或不必要的算法

拙劣的或不恰当的数据结构

其他设计不足，修改这些不足以获取更好的设计。

00设计概念

设计类

实体类

边界类

控制类

继承一一超类的所有特点立即被所有子类继承。

消息一一刺激接收对彖产生某种行为

多态种可以显著减少扩展已存在的设计的特性

设计类

在设计时，分析类被精化变为实体类

边界类是在设计中创建接II被开发的（例如：

交互式屏幕或打印报表），用户看到并与使用的软件交互。

边界类的设计，其职责管理将实体对彖呈现给用户的方式。

控制类彼设计用来管理

实体对彖的创建和更新；

边界对彖的实例化，因为它们获得来自实体对彖的信息;对象集之间的复杂通信；

验证对彖之间或用户与应用程序之河的数据通信。

设计类的特征

完整性-包含所有必须的属性，只包含那些“对实现该类的目的是足够”的方法

原始性■每个类方法关注于提供一个服务

高内聚性-小的、集中的、专一的类集合

低耦合性-类之间的协作保持在最小范附内

书P146设计模型的维度图

体系结构为什么重要？

软件体系结构的表示有助于对基于计算机的系统开发感兴趣的各方（利益相关者）开展交流。

体系结构突出了早期的设计决策，这些决策对随后所有的软件工程工作有深远影响，同时对系统作为一个可运行实体的最后成功有重要作用。

体系结构“构建了一个相对小的、容易理解的模型，该模型描述了系统如何构成以及其构件如何一起工作”[BAS03]。

体系结构风格

每种风格描述一种系统类别，包括：

（1）完成系统所需要的某种功能的一组构件（例如数据库、计算模块）；

（2）能使构件间实现“通信、协调和合作”的一组连接件：

（3）定义构件如何集成为系统的约束：

（4）语义模型.能使设计者通过分析系统组成成分的已知属性来理解系统的整体性质。

・以数据为中心的体系结构

・数据流体系结构

・调用和返回体系结构

■面向对彖体系结构

・层次体系结构

体系结构模式

并发性一一应用程序必须以模拟并行的方式来处理多任务

操作系统进程管理模式

任务调度器模式

持久性一一如果数据在创建它的进程运行结束之后仍然要存在，则数据是持久的。

两种常见模式是：

数据库管理系统模式,它把DBMS的存储和检索功能应用到应用系统的体系结构之中应用级持久性模式,它把持久性特征构建到应用系统体系结构之中

分布性一一在分布式坏境中，系统或系统内的构件之间相互通信的方式代建的作用是在客户端构件和服务器端构件之间担当“中间人”O

定体系结构的原型集

原型（类似于类）是表示系统行为元素的一种抽彖

体系结构的考虑要素

经济性・最好的软件应该是整洁的并依赖抽象化以减少无用的细节。

易见性-对于那些随后将验证这些模型的软件工程师而言，体系结构的决策及其依据应该是显而易见的。

隔离性■在设计中不产生隐藏依赖的关注点分离。

对称性-体系结构的对称性意味着它的属性是均衡一致的。

应急性■紧急的、自组织的行为和控制。

体系结构的复杂性

通过考虑体系结构中构件间的依赖关系，对提议的体系结构的整个复杂性进行评估［Zhao98］

共享依赖表示使用相同资源的消费者之河或为相同消费者生产的生产者之间的依赖关系。

流依赖表示资源的生产者和消费者之间的依赖关系。

约束依赖表示在一组活动间相互控制流上的约束。

体系结构描述语言（ADL）

构件的定义

OMG统一建模语言规范［OMG01］是这样定义构件的：

“系统中模块化的、町部署的和可替换的部件，该部件封装了实现并对外提供一组接II。

”00观点：

构件包含一组协作的类

传统观点：

一个构件包含处理逻辑，实现处理逻辑所需的内部数据结构以及能保证构件被调用和实现数据传递的接口。

构件基本设计原则

开闭原则（OCP）o“模块［构件］应该对外延貝有开放性，对修改具有封闭性”。

Liskov替换原则（LSP）o“子类可以替换它们的基类”。

依赖倒置原则（DIP）o“依赖于抽象，而非具体实现”。

接口分离原则（ISP）o“多个客户专用接II比一个通用接II要好”。

发布复用等价性原则（REP）o“复用的粒度就是发布的粒度”。

用户界面设计的黄金规则把控制权交给用户减少用户的记忆负担保持界面一致

把控制权交给用户

以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。

提供灵活的交互。

允许用户交互被中断和撤销。

当技能水平高时可以使交互流线化并允许定制交互。

使用户与内部技术细节隔离开来。

设计应允许用户与出现在屏幕上的对彖直接交互。

减轻用户的记忆负担

减少对短期记忆的要求。

建立有意义的默认设置。

定义直观的快捷方式。

界面的视觉布局应该基于真实世界的象征。

以一种渐进的方式揭示信息。

保持界面一致

允许用户将当前任务放入有意义的坏境中。

在完整的产品线内保持一致性。

如果过去的交互模型已经建立起了用户期塑，除非有不得已的理由，否则不要改变它。

用户界面设计模型

用户模型一一系统所有最终用户的轮廓

设计模型一一用户模型的设计实现

心理模型（系统感觉）一一用户脑海里对界面产生的映像

实现模型一一“视感”界面，结合了用来描述界面语法和语义的支撑信息

用户界面设计过程

界面分析和建模->界面设计->界面构造->界面确认

呈螺旋型，即完成至尾部后迭代至开始

验证与确认

验证是指确保软件正确地实现某一特定功能的一系列活动。

确认指的是确保开发的软件可追溯到客户需求的另外一系列活动。

Boehm[Boe81]用另一种方式说明了这两者的区别：

验证：

我们在正确地构造产品吗？

确认：

我们在构造正确的产品吗？

代码生成-单元测试

设计模型-集成测试

需求分析模型-确认测试

系统工程-系统测试

单元测试

对单个模块的测试，在面向对彖测试中，其重点在于封装的类，类中包含的测试是最小的可测试单元

集成测试策略

集成测试是构件软件体系结构的系统化技术，勇士也是进行一些已在发现与接11相关的错误的测试。

选择：

“一步到位”方法，非增量式的

增量构件策略

测试方法

自顶向下集成测试：

通过自顶向卞逐渐将桩模块替换为实际模块完成测试

自底向上增量式测试：

通过先测试底层模块，然后将已测试过的部分划分为簇，逐步向上层测试，过程中不需要桩模块

三明治测试：

混合增量式测试，结合自顶向下和自底向上进程集成和测试，其测试中同时可能存在桩模块和簇

回归测试:

在修改软件后执行以测试过的某些子集，以确保变更中没有传播不期望的副作用,避免因修正旧错误导致的新错误

冒烟测试：

每口都构建一个构造，包含所有至此的所有进度，并对其进行测试以发现导致此构造工作异常的错误，这个测试方法可以是以上任意的。

此举有利于在早期发现错误以避免可能导致项目延迟的“业务堵塞”错误。

通用测试标准

接口的完整性-在把每个模块或簇添加到软件中时，测试内部和外部模块的接II。

功能的有效性■通过测试来发现软件中的功能缺陷。

信息内容-通过测试来发现局部的或全局的数据结构中的错误。

性能-验证规定的性能边界是否测试过。

00测试策略

类测试相当于单元测试

测试类中的操作

检查类的状态行为

集成测试应用三种不同的策略

基于线程的测试一一对响应系统的一个输入或爭件所需的一组类进行集成基于使用的测试一一对响应系统的一个用例所需的一组类进行集成簇测试一一对演示一个协作所需的一组类进行集成

高阶测试

恢复测试

通过各种方式强制地使软件发生故障，并验证其能适当恢复。

安全测试

验证建立在系统内的保护机制是否能够实际保护系统不受非法入侵。

压力测试

以非正常的数量、频率或容量的方式执行系统。

测试是想要破坏程序。

举例：

一如果正常的中断频率为每秒5次，强度测试设计为每秒50次中断。

一把输入数据的量提高一个数量级来测试输入功能会如何响应。

一若某系统正常运行可支持200个终端并行工作，强度测试则检验1000个终端并行工作的情况。

性能测试

用来测试软件在集成环境中的运行性能，特别是针对实时系统和嵌入式系统，仅提供符合功能需求但不符合性能需求的软件是不能被接受的。

性能测试可以在测试过程的任意阶段进行，但只有当整个系统的所有成分都集成在一起后，才能检查一个系统的真正性能。

性能测试常常和强度（压力）测试结合起来进行，而且常常需要硬件和软件测试设备，这就是说，常常有必要在一种苛刻的环境中衡量资源的使用（比如，处理器周期）。

移动App测试

用户体验测试-确保app满足利益相关者对可用性和可访问性的期塑设备兼容性测试■在多个设备上进行测试

性能测试・测试非功能性需求

连接性测试■测试app可靠连接的能力

安全性测试-确保app满足利益相关者对安全性的期望实地测试-在实际的用户环境中，在用户设备上测试app认证测试■满足已颁布的标准

驱动模块：

用来模拟被测试模块的上一级模块，相当于被测模块的主程序。

它接收数据，将相关数据传送给被测模块，启动被测模块，并打印出相应的结果。

桩模块：

用来模拟被测模块工作过程中所调用的模块，它们一般只进行很少的数据处理。

（只存在于自顶向下测试）

驱动模块和桩模块都是额外的开销，虽然在单元测试中必须编写，但并不需要作为终的产品提供给用户。

症状和原因的关系

症状与原因出现的地方可能相隔很远症状可能在另一个错误被改正时消失实际上可能是非错误因素引起的可能是由系统或编译错误引起的可能是人们坚信的假定引起的症状可能是间断的

调试技术蛮干法/测试回溯法归纳法排除法

常用测试方法

穷举测试

选择测试

软件测试-白盒测试，黑盒测试

白盒测试

・目标是确保程序中的每一条语句和条件都至少被执行一次

基本路径测试

首先计算环复杂度V（G）=简单决策数+1或流程图中封闭区域数+1（仅计算简单封闭区域）

（V（G）越高，错误概率越高）

下一步，导出独