软件工程复习Word下载.docx

软件工程复习Word下载.docx

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

a）抽象自顶向下，逐层细化

b）模块化的开发方法

c）信息隐蔽和数据封装。

d）局部化

e）一致性

f）完备性

g）可验证性

8.软件工程基本原理：

a）按软件生存期分阶段制定计划并认真实施

b）坚持进行阶段评审

c）坚持严格的产品控制

d）使用现代程序设计技术

e）明确责任

f）用人少而精

g）不断改进开发的过程

9.识别用户要求，必须考虑的问题：

a）功能和性能

b）可靠性和质量

c）总的系统目标

d）成本与进度的把控

e）制造需求

f）市场竞争情况

g）有效的技术

h）将来可能的扩展

10.可行性研究

a）问题识别

b）市场调查

c）分析准备

d）环境分析

e）物理分析

f）功能分析

g）信息分析

h）动态分析

i）确立系统方案和成本估算

j）模型评审

k）成本可行性

l）法律可行性

11.面向对象设计

面向对象=对象+分类+继承+消息通信，基本组成部分叫对象，计算是通过新对象的确立和对象之间的通信来执行。

相对于面向过程开发，核心：

数据被封装在对象中，而不是全局变量中，数据流是通过消息传递，而不是面向过程解决办法。

算法被包裹在对象中，实现功能。

酽锕极額閉镇桧猪訣锥。

12.统一建模语言：

UML概述

UnifiedModelingLanguage的缩写，他聚集了建模的精髓。

数据建模（实体关系图ERD）

业务建模（工作流）

对象建模

构件建模

13.UML图

用例图：

描述系统边界和主要功能；

主要该系统在它的上下文环境所提供的服务。

1）上下文环境建模：

主要指在位于系统之外并与系统进行交互的参与者以及他们扮演的角色的含义。

2）功能需求建模：

说明系统想要的行为。

交互图（时序图，协作图）：

描述用例的实现，其主要描述了系统的外部视图，如何通过对象之间的交互实现用例。

包括顺序图和协作图，顺序图也叫时序图或序列图，他是按照时间顺序来的。

彈贸摄尔霁毙攬砖卤庑。

类图：

标示系统的静态机构

类图从系统的逻辑视图展现了一组类、接口、协作和它们之间的关系，类图给出系统的静态设计视图，主动类的类图给出了系统的静态进程视图。

其主要包括謀荞抟箧飆鐸怼类蒋薔。

1）类及其结构和行为

2）接口

3）协作

4）关联、依赖、泛化关系

5）多重性和导航指示符

6）角色名字

类图的关系：

父子关系实现关系

关联关系（单向关联有箭头，多项无箭头）

聚合：

整体和部分关系

组合关系（也是整体与部分，但是部分离开整体无法存活）

依赖关系（动物无法离开氧气，为依赖关系）

整体类图

状态图：

模型化对象的行为

泳道图

构件图和部署图：

展现物理实现的体系结构

衍型：

扩展建模能力

14.软件需求：

a）为满足用户解决某一问题而达到某个目标所需要的条件或者能力，系统或系统部件为满足合同、规格、标准说明或其他正式的强制性文档所必须具有的条件和能力。

为满足以上条件和能力的文档化说明厦礴恳蹒骈時盡继價骚。

b）软件需求包括：

业务需求、用户需求、功能需求、非功能性需求。

c）业务需求：

描述了组织愿景，即为什么要开发一个系统；

系统的业务范围、业务对象、客户特性、价值和各种特性的优先级别。

茕桢广鳓鯡选块网羈泪。

d）用户需求：

描述了系统必须完成任务，即用户对系统的目标要求。

它只涉及到外部可见行为，不涉及内部特性。

是用户对自身需求的一种陈述。

这种陈述可能与实际需求不一致。

鹅娅尽損鹌惨歷茏鴛賴。

e）功能需求：

定义了开发者应该提供的软件功能或服务，但不涉及这些功能和服务的实现。

f）非功能需求：

对功能需求的补充，包括了对系统的各种限制和用户对系统的质量的要求。

如系统响应时间或截面。

i.包括产品必须遵从的标准、规范和合约

ii.外部接口的具体细节

iii.性能要求

iv.设计实现的约束条件

15.需求获取的过程

需求获取包括以下活动：

（a）发现和分析问题

（b）获取需求

（c）需求归档

需求获取的主要步骤

（a）理解业务领域，即目标软件的业务环境，如银行、电信，了解后可以建立自对业务理解后的数据模型。

通过结合实际业务，迭代完善业务模型籟丛妈羥为贍偾蛏练淨。

（b）定义项目的视图和范围，定义项目范围是描述项目该做什么，不该做什么一般使用用例图。

（c）寻找软件的需求来源，客户、竞品、系统需求规格说明书、当前系统的问题报告和改进要求、市场调研报告、观察用户如何工作、用户工作场景分析、事件和响应。

預頌圣鉉儐歲龈讶骅籴。

（d）识别用户类和用户代表，确定系统的用户及其分类，与用户一块工作，确定系统的决策者。

（e）确定系统的业务流程和业务规则

（f）访谈和记录

（g）需求整理和描述

16.面向对象的UML需求获取方法：

a）用户模型视图：

从用户角度来标示系统，通过用例图来标示

b）结构模型视图：

通过静态的数据模型图，类图、对象图来建模

c）行为模型视图：

描述系统的动态和行为，以及在上述两种视图中的各元素如何交互。

d）实现模型视图

e）环境模型视图

面向对象模型，分为三个独立模型

a）有用例和场景组成功能视图

b）用类和对象标示的分析对象模型

c）用状态图和顺序图标示的动态模型

17.对需求文档的要求：

1）完整：

要求必要的需求信息，必须进行完整的描述

2）无歧义：

每种需求只有一种解释。

3）一致性：

对需求规格说明，必须保持一致。

4）可验证：

可演示、测试、分析、审查、特殊的检查

5）可修改

6）可追踪：

向前和向后的追踪性。

18.软件需求评审的主要内容：

a）用例：

是否清晰，用例规格。

b）功能：

是否清楚，是否必须，是否满足，是否覆盖异常

c）性能：

是否精确描述，是否制定指标，是否制定使用环境

d）接口：

外部、内部描述是否清晰。

调用关系。

e）数据：

是否确定系统的输入、输出

f）硬件

g）软件

h）通信

i）正确性完整性一致性，兼容性，安全性清晰性，健壮性，可扩展性。

19.需求管理：

a）需求变更：

建议变更---分析影响---作出决策---交流---合并

b）版本控制：

确定需求文档版本

c）需求跟踪：

d）需求状态跟踪

20.需求变更的控制策略：

a）需求变更原因：

内部原因，外部原因

i.内部原因：

需求获取的不确切，需要发生变更，以适应真正的客户需求

ii.外部原因：

客户需求与之前发生了变化，如：

客户的组织结构和工作流程发生了变化。

b）需求变更的策略

i.认识到变更不可避免的时候，为变更指定计划

ii.重新确定需求的基线

iii.指定变更的唯一渠道，防止因为变更导致的需求扩散。

iv.指定合理的需求变更管理过程：

如必须经过变更管理委员会确定的变更，才能真正进入需求文档，而不是开发人员擅自做主变更需求。

渗釤呛俨匀谔鱉调硯錦。

21.软件设计

a）传统结构化软件设计：

数据设计，体系结构设计，接口设计，过程设计。

b）面向对象的软件设计：

体系结构设计、类设计、接口设计、构件设计

i.体系结构设计：

软件的主要结构元素其之间的关系

ii.类设计：

转化为设计类的实现及软件实现所要求的数据结构

iii.数据设计：

主要是关系数据库中的E-R实体关系图

iv.构件级设计：

构件级设计

22.软件设计原则：

a）设计应遵循：

过程抽象，数据抽象。

b）过程应遵循模块化的原则

i.模块可分解

ii.模块可组装

iii.模块可被理解

iv.模块连续性

v.模块保护

c）应遵循信息屏蔽的原则

d）模块独立性：

高内聚，低耦合。

e）模块设计原则：

先把该模块下的所有下层模块看成黑盒

23.极限编程

a）极限编程是一种原型设计方法，是基于实践的设计方法。

b）极限编程的原则：

交流、简单、反馈、勇气。

i.交流：

鼓励开发人员与客户直接沟通，用沟通代替文档。

ii.XP不建议过分构建系统设计，反对杞人忧天的做法。

简单最好，实现为前提。

iii.反馈要迅速，反馈越快越好，进行结对编程，测试优先，现场客户。

iv.拥抱变化，不变是变化，要有坚持XP设计的勇气，同时有放弃勇气。

c）XP的重要方法：

i.放弃包袱，轻装上阵。

ii.结对编程

iii.测试优先，以测试用例为驱动，单元测试。

iv.重构

v.持续集成

vi.小版本

vii.现场客户

24.软件体系结构

软件体系结构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个子模块和子系统有效的组织起来，组织成一个完整的系统。

铙誅卧泻噦圣骋贶頂廡。

25.常见的风格：

管道过滤器风格：

26.面向对象的设计风格

27.层次结构的风格（每一层定义一个抽相机，为上一层提供服务，并作为下一次层的客户）

28.数据仓库风格（共享系统单元，所有人可以访问这些数据，此系统常见于专家系统中）

专家黑板系统

29.设计模式：

设计模式分为三类：

1）创建型模式：

与对象的创建有关

2）结构型模式：

处理类与对象的组合，将一组对象组合成一个大的结构

3）行为型模式：

描述类与对象交互和职责分配。

按照使用范围，又分为对象和类两种类型

其中23中设计模式，主要

创建型：

描述怎么创建一个对象，他隐藏对象创建的具体细节，实用程序可不依赖具体的对象，因此当增加一个新对象时几乎不需要修改代码。

其隐藏了这些类的实例如何创建、如何放在一起。

擁締凤袜备訊顎轮烂蔷。

创建型类模式有：

工厂模式

创建型对象模式有：

抽象工厂，构造模式，原型模式，单例模式

重点1：

抽象工厂模式：

以同一接口建立一整组相关或相互依赖的对象，而不用指明个对象真正所属的具体类。

抽象工厂的特点：

1.封装性：

都是接口，不关心细节。

只需知道工厂类即可，就能创建出一个对象，省时省力。

2.约束性：

产品约束在产品内部，外部不需要关心。

缺点：

1.扩展性困难，增加一个新产品，需要抽象类，抽象类实现工厂都要修改，改动太大。

抽象工厂是一种契约关系，一种契约修改，所有的代码都要修改。

贓熱俣阃歲匱阊邺镓騷。

使用场景：

1.使用对象组，这类对象有相同约束，如：

文本编辑器，在Linux下的和Windows下的因为底层API不同，代码实现不同。

但是功能是相同的，有共同的约束条件，可以用抽象