软件工程期末复习笔记09级福师大数计院.docx

软件工程期末复习笔记09级福师大数计院.docx

《软件工程期末复习笔记09级福师大数计院.docx》由会员分享，可在线阅读，更多相关《软件工程期末复习笔记09级福师大数计院.docx（24页珍藏版）》请在冰豆网上搜索。

软件工程期末复习笔记09级福师大数计院

2.1软件工程&软件过程概述

（1）软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据；

（2）软件的特征：

1、复杂性；2、不可见性（它是客观世界空间和计算机空间之间的一种逻辑实体，不具有物理的形体特征）3、可变性（需要随着应用、硬件、用户和社会等各种因素的变化而不断地被修改和扩展）4、一致性（大多数软件仍然是定制的，而不是通过已有的构件组装而成的）

（3）软件危机是指在计算机软件的开发和维护过程中遇到的一系列严重问题。

（4）软件危机的表现:

1、软件开发的成本和进度难以准确估计，延迟交付甚至取消项目的现象屡见不鲜；2、软件存在着错误多、性能低、不可靠、不安全等质量问题；3、软件成本在计算机系统的整个成本中所占比例越来越大4、软件维护极其困难，而且很难适应不断变化的用户需求和使用环境

（5）软件工程的定义：

1、将系统性的、规范化的、可定量的方法应用于软件的开发、运行和维护，即工程化应用到软件上；2、对1中所述方法的研究

（6）软件工程的三要素：

过程（管理和控制产品质量的关键）、方法（为软件开发提供了“如何做”的技术）和工具（为软件工程方法提供了自动的或半自动的软件支撑环境）

（7）软件质量的特征：

1、软件产品质量满足用户要求的程度2、软件各种属性的组合程度3、用户对软件产品的综合反映程度；4、软件在使用过程中满足用户要求的程度

（8）

（9）软件过程：

软件工程人员为了获得软件产品而在软件工具的支持下实施的一系列软件工程活动。

（10）软件过程的基本活动:

1、问题提出；2、软件需求规格说明；3、软件设计；4、软件实现；5、软件确认；6、软件演化

（11）软件过程模型：

----------瀑布模型：

软件开发的各项活动严格按照线性的方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容

适用范围：

在开发的早期阶段软件需求被完整确定的情况。

特点：

这种模型强调文档的作用，并要求每个阶段都要仔细验证

缺点：

各个阶段的划分完全固定会大量的文档、中间提出的变更要求很难得到响应、早期错误可能要等到开发后期的测试阶段才能发现

----------快速原型模型：

尽可能“快速”地构建原型，一旦确定了客户的真正需求，所构建的原型将被丢弃。

适用范围：

小型或中等规模的交互式系统、大型系统的某些部分（用户界面）、生命周期较短的系统

特点：

原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求得以减少软件需求不明确所带来的开发风险

缺点：

所选用的开发技术和工具往往不一定符合主流的发展，快速建立起来的系统结构加上连续的修改可能会导致产品质量低下

-----------增量模型：

在各个阶段并不交付一个可运行的完整产品，而是交付满足客户需求的一个子集的可运行产品。

适用范围：

不知道

特点：

适应用户逐步细化需求的形成过程，以减少软件开发过程中的返工

缺点：

1、软件需具备开放式的体系结构才能使加入的构件不破坏已构造好的系统部分；2、容易退化成边做边改的方式，从而使软件过程的控制失去整体性

-------------螺旋模型：

它将软件过程划分为若干个开发回线，每个开发回线又分为四个步骤适用范围：

大型复杂的软件系统，特别是适应于内部的大规模软件开发

特点：

它强调可行方案和约束条件从而支持软件的重用，有助于将软件质量作为特殊目标融入产品开发之中。

缺点：

1、要求客户接受相信风险分析，并作出反应2、风险分析大大影响项目的利润时，风险分析就毫无意义3、软件开发人员必须善于寻找可能的风险

--------------形式化方法模型：

用形式化的数学方法将系统描述转换成可执行的程序

适用范围：

对安全性、可靠性和保密性要求极高的软件系统开发

特点：

软件系统具有较少的缺陷和较高的安全性

缺点：

1、开发人员需经特殊培训2、系统大多数是交互性强的软件，难以用形式化方法描述3、形式化描述和转换是费时费力的工作

---------------基于组件的开发模型：

依赖于可复用的软件组件及其相应的集成框架，提高了开发效率和产品质量

适用范围：

如今广泛应用

特点：

充分体现了软件复用的思想，降低了开发风险和成本，能够快速交付所开发的软件

缺点：

某些商业组件不能进行修改，系统演化将受到一定的限制

2.2需求工程

（1）业务需求：

组织或客户对于系统的高层次目标要要求，定义了项目的远景和范围，即确定软件产品的发展方向、功能范围、目标客户和价值来源

业务需求的内容：

1、业务要求（业务范畴、功能、服务内容）2、客户（目标客户）3、特性（区别于竞争产品的特性）3、价值4、优先级（产品功能特性的优先级次序）

用户需求：

是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特征

用户需求的描述：

1、原则（应该易于用户理解，采用自然语言或直观图形）2、问题（自然语言表达容易含糊和不准确）

系统需求：

更加详细地描述系统应该做什么，通常包括许多不同的分析模型，例如对象模型、数据模型、状态模型等，它只要是面向开发人员进行描述，是开发人员进行软件设计的基础

系统需求的描述：

1、结构化语言（PDL）2、可视化模型（数据流图、UML）3、形式化方法

功能需求：

描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节

非功能需求：

从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准

（2）需求工程的过程：

1、需求获取（开发人员聆听客户的需求，观察用户的行为）2、需求分析（分析和整理所收集的用户需求）3、需求规格说明（以文档形式，精确地阐述系统必须提供的功能和性能及限制条件）4、需求验证（使用评审和商议等有效手段进行验证，最终形成一个需求基线）5、需求管理（在软件开发过程中有效地管理和控制需求变更）

（3）需求获取：

应该识别项目相关人员的要求，解决不同项目相关人员之间的需求冲突

需求获取技术：

1、用户访谈（一种理解商业功能和商业规则的最有效方法）2、需求专题讨论会（主要风险承担者集中在一起，在需求上达成共识，对操作过程尽快取得统一意见，能够很快地产生初步系统定义）3、问卷调查（可用于确认假设和收集统计倾向数据）4、现场考察（掌握用户如何实际使用一个系统以及到底用户需要哪些信息）5、原型化方法（帮助开发人员、用户以及客户更好地理解系统的需求，比开发人员常用的技术术语更易于理解）6、基于用例的方法

（4）需求分析的主要工作内容：

1、定义系统的边界（建立系统与其外部实体间的界限和接口的简单模型，明确接口处的信息流）

2、建立软件原型（当遇到需求不确定的问题时）

3、分析需求的可行性

4、确定需求的优先级

5、建立需求分析模型（需求分析的核心）

6、创建数据字典

（5）软件需求规格说明书：

精确地阐述一个软件系统必须提供的功能和性能以及它所考虑的限制条件

软件需求规格说明书的作用：

1、成为用户、分析人员和设计人员之间进行理解和交流的手段2、支持系统测试活动3、用于规划和控制系统的开发过程

软件需求规格说明书的内容包含功能、外部接口、性能、特征、设计约束；不包括项目开发计划、产品保证计划、软件设计细节

软件需求规格说明书的使用范围：

1、用户通过需求规格说明文档指定需求，检查需求描述是否满足原来的期望；2、设计人员通过需求规格说明文档了解软件需要开发的内容，将其作为软件设计的基本出发点；3、测试人员根据软件需求规格说明书中对产品行为的描述，制定测试计划、测试用例和测试过程；4、产品发布人员根据软件需求规格说明书和用户界面设计编写用户手册和帮助信息

（6）需求验证：

为了确保需求说明准确、完整地表达必要的质量特点

需求验证主要围绕需求规格说明的质量特性展开的，质量特性包括（正确性、无二义性、完整性、可验证性、一致性、可修改性和可跟踪性）

（7）需求变更控制：

1、仔细评估已建议的变更2、挑选合适的人选对变更作出决定3、变更应及时通知所有涉及人员4、项目要按一定的程序实施需求变更

（8）用例分析：

1、用例三要素：

参与者（与系统交互的外部实体）、用例（从用户角度描述系统外部可见的功能和行为，是与参与者交互的，并且给参与者提供可观测的有意义的结果的一系列活动的集合）、边界

2、参与者的泛化关系：

一般与特殊的层次结构

3、用例的关系：

（泛化关系【generalization】：

描述用例之间一般与特殊关系）

（包含关系【include】：

一个基本用例的行为包含了另一个用例的行为，对用例之间的共性部分进行建模，包含用例是“必须的”，不是“可选”的）

（扩展关系【extend】：

将异常行为或可选分支抽象成一个单独的扩展用例，扩展表示的是“可选”的，而不是“必须”的）

（实现关系【realize】：

基本用例描述了一个业务目标，但该业务目标又有多种可能的实现途径）

（精化关系（refine）：

一个基本用例可以分解出许多更小的关键精化用例，这些用例更细致地展现了基本用例的核心业务）

4、边界决定视界，视界决定抽象层次

2.3OO分析与设计

（1）对象：

是系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，由一组属性和对这组属性进行操作的一组服务组成。

类：

是具有相同属性和服务的一组对象的集合，它为属于该类的全部对象提供了统一的抽象描述，其内部包括属性和服务两个主要部分。

封装：

把对象的属性和服务结合成一个独立的系统单位，并尽可能隐藏对象的内部细节。

继承：

指子类可以自动拥有父类的全部属性和服务。

多态：

在父类中定义的属性或服务被子类继承后，可以具有不同的数据类型或表现出不同的

行为。

消息：

是对象发出的服务请求，一般包含服务的对象标识、服务标识、输入信息和应答信息等。

关联：

对象属性之间的静态联系，它通过对象的属性来表现对象之间的依赖关系

当一个类“知道”另一类的时，可以用关联关系

聚合：

对象之间的组成关系，即一个或一些对象是另一个对象的组成部分，表示对象之间的整体与部分关系。

（部分和整体生命周期可以不同）例如雁群和大雁

组合：

体现严格的部分整体关系，部分和整体有相同的生命周期。

（2）用例视图：

描述系统应该具有的功能集，它从系统外部用户的角度出发，实现对系统的抽象表示。

设计视图：

用来揭示系统功能的内部设计和协作情况。

进程视图：

描述系统的并发工作状况，它包含形成系统并发与同步机制的线程和进程，主要是提供给系统开发商和集成商使用。

实现视图：

由一些独立的构件和文件组成，显示实现模块及其之间的依赖关系。

分布视图：

描述系统的物理架构，显示系统硬件拓扑结构的节点，提供给开发人员、集成人员和测试人员。

（3）用例图：

定义了系统的功能需求，它完全是从系统的外部观看系统功能，并不描述系统内部对功能的具体实现

类图：

描述系统的静态结构，表示系统中的类、类与类之间的关系以及类的属性和操作。

对象图：

描述了一组对象以及它们之间的关系，表示类的对象实例

状态图：

表示一个状态机，强调对象行为的事件顺序

活动图：

反映系统中从一个活动到另一个活动的流程，强调对象间的控制流程

顺序图和协作图：

表示一组对象之间的动态协作关系，其中顺序图反映对象之间发送消息的时间顺序，协作图反映收发消息的对象的结构组织，它们是同构的，可以互相转换

（4）

组合

聚合

（5）类的关系：

--关联关系：

一种结构关系，表达模型元素间的一种语义联系，它是对具有共同的结构特征、行为特征、关系和语义的链的描述

（1）常规关联关系：

一种结构关系，它描述了一组对象之间的连接

（2）限定关联关系：

带有限定符的关联，限定符的作用：

给定关联一端的一个对象和限定符值，可确定另一端的一个对象或对象集。

--依赖关系：

是一种使用关系，描述一个类的修改可能导致另外一个类修改的一种关系。

--聚合关系：

是一种特殊形式的关联，它表示类之间的整体与部分的关系。

--组合关系：

是一种特殊形式的聚集，组合关系中的整体与部分具有同样的生存期。

--泛化关系：

是一种特殊/一般的关系，即继承关系

--实现关系：

实现是类元之间的语义关系，其中的一个类元指定了由另一个类元保证执行的契约（接口）

用例关系……………………………………………………………………

（6）实体类：

用于描述必须存储的信息及其相关行为，它是对系统的核心信息建模，通常这些信息需要永久地保存

边界类：

用于描述外部参与者与系统之间的交互，它是对系统依赖于外部环境的部分进行建模，较好地屏蔽了外界变化对系统的影响。

控制类：

用于描述一个用例所具有的事件流控制行为，它本身并不处理具体的任务，而是调度其他类完成具体的任务。

（7）耦合：

表示两个子系统或类之间的关联程度

当一个子系统或类发生变化时对另一个子系统或类的影响很小，则称他们是松散耦合的；反之，如果变化的影响很大时，则称他们是紧密耦合的。

（8）聚性：

是子系统内部的相关程度

高内聚：

子系统中彼此相关的多个对象执行类似的任务

低内聚：

子系统内的多个对象彼此不相关时

高内聚的方法：

做且仅做一件事。

高内聚的类：

表示且仅表示一种类型的对象，例如员工中的经理类

（9）软件设计的技术原则：

1、开-闭原则：

软件应该对扩展开放，对修改关闭；不允许更改的是系统的抽象层；允许扩展的是系统的实现层；面临新需求时，设计必须是稳定的。

2、里氏互换原则：

任何基类可以出现的地方，子类一定可以出现

例如：

白马，马也；乘白马，乘马也……

子类出现的地方，基类不一定可以出现

例如：

娣，美人也；爱娣，非爱美人也。

3、依赖反转原则：

要针对接口编程，不要针对实现编程；高层模块不应该依赖于底层模块；高层模块、底层模块都应该依赖抽象

4、迪米特法则：

一个软件实体应当与尽可能少得其他实体发生相互作用；如果被修改模块是相当独立的，那么就不会将修改的压力传递给其他的模块。

例如：

不要和陌生人说话

（10）软件体系结构：

1、仓库体系结构：

是一种集中式的模型。

各子系统可以直接访问中央数据仓库存储的共享数据。

子系统之间紧密耦合。

适用于：

命令控制系统，现代编译器，管理信息系统，CAD系统和CASE工具集

2、分层体系结构（抽象机模型）：

将软件设计组织成为类或组件的层次或集合，每层提供一组服务，每层定义一个抽象机，完成一个特定目的，不同的层次之间通过接口进行通信。

应用：

ISO/OSI开放系统

3、C/S（客户机/服务器结构）：

是一种分布式模型，采用发请求、得结果的模式

4、MVC（模型/视图/控制器结构）：

该结构是为同样的数据提供多个视图的应用程序而设计的，它将交互系统的组成分解成模型、视图、控制器三种部件

应用：

Struts2

2.4软件测试

软件测试：

对软件产品质量的检验和评价，它一方面检查软件产品质量中存在的质量问题，同时又对产品质量进行客观的评价

软件测试的目的：

以最少的时间和人力系统地找出软件中潜在的各种错误和缺陷。

软件测试的基本原则：

测试次序：

单元测试—集成测试—系统测试—验收测试

黑盒测试：

又称功能测试，完全不考虑程序内部的逻辑结构和内部特征，只依据程序的需求规格说明书，检查程序功能是否符合它的功能说明。

白盒测试：

又称结构测试，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。

3.1软件需求的质量：

p82，p96练习第2题，课件04软件需求—04软件需求-01需求工程-2.swf-—第23页开始

Ø正确性：

需求规格说明对系统功能、行为、性能等的描述必须与用户的期望相吻合，代表了用户的真正需求。

Ø无二义性：

需求规格说明中的描述对于所有人都只能有一种明确统一的解释

Ø完整性：

需求规格说明应该包括软件要完成的全部任务，不能遗漏任何必要的需求信息。

Ø可验证性：

需求规格说明中描述的需求都可以运用一些可行的手段对其进行验证和确认

Ø一致性：

需求规格说明对各种需求的描述不能存在矛盾，如术语使用冲突、功能和行为特性方面的矛盾以及时序上的不一致等

Ø可修改性：

需求规格说明的格式和组织方式应保证后续的修改能够比较容易和协调一致

Ø可跟踪性：

每一项需求都能与其对应的来源、设计、源代码和测试用例联系起来

Ø

3.2软件生命周期模型的选择：

p27,课件02软件过程—02软件过程-1.swf—第33页开始

3.3用例图的绘制：

3.4CMMI：

课件02软件工程—02软件工程-2.swf—第18页开始

CMMI的目的：

将现在所有的以及将被发展出来的各种能力成熟度模型，集成到一个框架中去，整合不同模型中的最佳实践、建立统一模型；覆盖不同领域，供企业进行整个组织的全面过程改进。

一级：

初始级（软件过程是混乱无序的，对过程计划没有定义，成功依靠的是个人的才能和经验，管理方式属于反应式）

二级：

可重复级（建立了基本的项目管理来追踪进度、费用和功能，制定了必要的项目管理，能够利用以前类似的项目应用取得成功）

三级：

已定义级（已经将软件管理和过程文档化、标准化，同时综合成该组织的标准软件过程，所有的软件开发都是用该标准软件过程）

四级：

已管理级（收集软件过程和产品质量的详细度量，对软件过程和产品有定量的理解和控制）

五级：

优化级（软件过程的量化反馈和新的思想与技术促进过程的不断改进）

CMMI组织成熟度方法：

一级：

初始级

二级：

可重复级（软件配置管理、过程和产品质量保证、供应合同管理、项目控制和监督、软件项目计划、需求管理、测量和分析）

三级：

已定义级（产品集成、同行评审、组间协调、软件产品工程、集成软件管理、培训大纲、组织过程定义、组织过程聚焦、需求开发、技术解决方案、验证、确认、风险管理、决策分析和决定）

四级：

定量管理级（组织过程性能、定量项目管理）

五级：

优化级（过程更改管理、技术更改管理、缺陷预防）

3.5软件质量的一些思考：

09软件测试—09软件测试-1.swf—第1页开始

软件测试人员的职责：

3.6需求管理的一些思考：

课件04软件需求—04软件需求-01需求工程-2.swf-—第48页开始

怎么防止项目变更失控：

1、明确授权（明确客户方有权提出变更申请的人员、明确实施方有权受理变更的人员、控制双方人数）这样可以整体控制，杜绝私下交易，致无人完整知道变更情况，还可以屏蔽客户内部矛盾，减少因内部看法不同而导致反复的变更；2、对变更进行必要审核，决定是否修改，不是所有变更都要修改，决定什么时候修改，不是所有变更都要立刻修改，核心模块的修改要严格把关3、评估变更的代价和影响，让客户了解变更的后果，与客户一起判断，让客户确认是否接受变更的代价，客户确认变更后，再组织实施变更；4、变更要按配置管理规定制定，确保交付物的一致性和完整性，所有变更要跟踪和验证，确保按要求完成

3.7软件工程的一些思考：

08软件实现—08软件实现.swf

3.8非师类同学再想想：

01软件工程概述—01软件工程概述-1.swf—第28页（人月神话）

韩国汽车从笑话到神话02软件过程—02软件过程1.swf-第7页开始

李大嘴做月饼04软件需求—04软件需求-01需求工程-1.swf第16页开始

人月神话的启示：

1、人员数量和时间可以互相转换的情况，只针对可以完全分解的任务

2、当任务由于次序上的限制不能分解时人数的增加对进度是没有帮助的

3、沟通和分增加的工作量随人员的数量线性变化

4、软件开发本质上是一项系统工作——错综复杂关系下的一种实践——沟通、交流的工作量非常大，添加更多的人手实际上是延长了而不是缩短了时间进度

5、软绵绵公司虽然能有天兵相助，但是技术总监花了一个月的时间对他们进行培训，这额外地增加了三个人月的工作量

6、另外原则划分为三个部分的工作，会重新分解成5个部分；某些已经完成的工作必定会丢失，系统测试必须被延长

7、软绵绵的项目，在第三个月的月末，仍然残留着七个人月的工作，但此时只有五个有效的人月。

产品还是会延期，如同没有增加任何人手；

Brooks法则：

向进度落后的项目中增加人手，只会使进度更加落后。

4应用题