软件工程复习大纲131Word格式文档下载.docx
《软件工程复习大纲131Word格式文档下载.docx》由会员分享，可在线阅读，更多相关《软件工程复习大纲131Word格式文档下载.docx（18页珍藏版）》请在冰点文库上搜索。
UnifiedModelingLanguage统一建模语言P148
OMG：
ObjectManagementGroup对象管理组织P148
CRC：
Class-Responsibility-Collaborator类—责任—协作者P177
BPR：
BusinessProcessRe-engineering业务过程再工程P327
MTBF：
MeanTimeBetweenFailure平均故障（失效）间隔时间P355
MTTF：
MeanTimeToFailure平均故障（失效）时间P355
MTTR：
MeanTimeToRepatr平均修复时间P355
第1章概论P1-38
计算机软件：
指计算机系统中的程序及其文档。
一、软件的特点P3
1）软件是一种逻辑实体。
2）软件是被开发的或被设计的，它没有明显的制造过程，一旦开发成功，只需复制即可，但其维护的工作量大。
3）软件的使用没有硬件那样的机械磨损和老化问题，但是有退化问题。
2、为什么会出现软件工程？
P6
因为软件出现了软件危机，许多软件项目不能满足客户的要求，许多软件项目超出预算和时间安排。
软件危机：
随着计算机在各个领域的广泛应用，软件的需求量越来越大，软件的复杂度也越来越高，导致软件的开发远远满足不了社会发展的需要，超出预算的经费、超过预期的交付时间的事情经常发生。
由于缺乏文档以及没有好的开发方法的指导，使得大量已有的软件难以维护，出现了“软件危机”的局面。
3、软件工程定义P6
1）1968年FritzBauer在NATO（北大西洋公约组织）会议上给出的定义：
软件工程是建立和使用一套合理的工程原则，以便获得经济的软件，这种软件是可靠的，可以在实际机器上高效地运行。
2）IEEE在软件工程术语汇编中的定义：
软件工程是：
①将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；
②在①中所述方法的研究。
3）《计算机科学技术百科全书》中的定义：
软件工程是应用计算机科学、数学及管理科学等原理，开发软件的工程。
四、软件能力成熟度模型（CMM-SW）目的：
提供一种评价软件承接方能力的方法。
五、软件过程模型P18
软件过程模型也称软件开发模型，是软件开发全部过程、活动和任务的结构框架。
典型的软件过程模型有：
瀑布模型、演化模型（如增量模型、原型模型、螺旋模型）、喷泉模型、基于构件的开发模型、形式方法模型。
1）瀑布模型（waterfallmodel）是最原始的。
其特征是：
1 接受上一阶段的结果作为本阶段活动的输入。
2 依据上一阶段的结果实施本阶段应完成的活动。
3 对本阶段的工作进行评审。
4 将本阶段的结果作为输出，传递给下一阶段。
缺点：
缺乏灵活性，难以适应需求不明确或需求经常变化的软件开发；
开发早期存在的问题往往要到交付使用时才发现，维护代价大
瀑布模型是最早出现的也是应用最广泛的过程模型，对确保软件开发的顺利进行、提高软件项目的质量和开发效率起到重要的作用。
2）演化模型：
特别适用于对软件需求缺乏准确认识的情况。
3）增量模型（含义、特点、适合什么情况下采用）
●增量模型将软件的开发过程分成若干个日程时间交错的线性序列，每个线性序列产生软件的一个可发布的“增量”版本，后一个版本是对前一版本的修改和补充，重复增量发布的过程，直至产生最终的完善产品。
●增量模型特别适用于：
需求经常发生变化的软件开发。
4）原型模型
5）螺旋模型
6）喷泉模型
●喷泉模型是一种支持面向对象开发的模型。
●“喷泉”一词体现了面向对象方法的迭代和无间隙特性。
●迭代是指：
开发活动需要多次重复。
无间隙是指：
开发活动之间不存在明显的边界。
第三章需求工程P46-61
6、需求工程概述（作用、目的）P46
需求工程是应用已证实有效的技术、方法进行需求分析，确案、确认规约以及将规约转换到可运行的系统时的管理要求，需求工程通过合适的工具和符合系统地描述待开发系统及其特征和相关约束，形成需求文档，并对用户不断变化的需求演进给予支持。
软件需求工程细分为：
需求获取、需求分析与协商、系统建模、需求规约、需求验证以及需求管理6个阶段。
7、用况（usecase）P53
用况常称用例，它提供了系统将会被如何使用的描述。
创建用况模型的主要步骤如下：
1 确定谁会直接使用该系统，即执行者（actor）；
2 选取其中一个执行者。
3 定义该执行者希望系统做什么，执行者希望系统所做的每件事将成为一个用况。
4 对每件事来说，何时执行者会使用系统，通常会发生什么，这就是用况的基本过程。
5 描述该用况的基本过程。
8、需求分析P54
1、需求分析原则：
1 必须能够表示和理解问题的信息域。
2 必须能够定义软件将完成的功能。
3 必须能够表示软件的行为（作为外部事件的结果）。
4 必须划分描述数据、功能和行为的模型，从而可以分层次地揭示细节。
5 分析过程应该从要素信息移向细节信息。
2、抽象、分解与多视点分析
✧问题抽象方法要求分析人员在分析过程中捕捉用户描述或问题本身固有的一般-特殊关系，首先关注一般问题的解决途径，进而指导特殊问题的解决方法。
✧问题分解的目的是：
要能以层次化的方式对问题进行分解和不断细化。
3、需求分析的结果（或输出）：
就是需求规约。
9、需求规约与验证（每一阶段成果）P57
1.软件需求规约是分析任务的是最终产物。
2.需求验证的目的是：
要检验需求是否能够反映用户的意愿。
需求验证需要对需求文档中定义的需求执行多种检查。
3.需求管理是一组用于帮助项目组在项目进展中的任何时候去标识、控制和跟踪需求的活动。
第4章设计工程P62-85
软件需求分析解决“做什么”的问题，软件设计过程则解决“怎么做”的问题。
10、软件设计的任务P62
1）数据/类设计
——它将分析类模型变换成类的实现和软件实现所需要的数据结构。
在类和由CRC（类-责任-协作者）中定义的数据对象和关系以及数据字典中描述的详细数据内容提供了数据设计活动的基础。
2）体系结构设计
——定义了软件的整体结构，由软件部件、外部可见的属性和它们之间的关系组成。
体系结构设计表示可以从系统规约、分析模型和分析模型中定义的子系统的交互导出。
3）接口设计
——描述了软件内部、软件和协作系统之间以及软件同人之间的通信方式。
4）部件级设计
——将软件体系结构的结构性元素变换成对软件部件的过程性描述。
从类为基础的模型、流模型、行为模型等模型中得到的信息是部件设计的基础。
11、软件设计中的主要抽象手段和概念P65
1、主要抽象手段有：
过程抽象和是数据抽象。
2、概念：
①过程抽象也称功能抽象是指任何一个完成明确定义功能的操作都可被使用者当作单个实体看待，尽管这个操作实际上是由一系列更低级的操作来完成的。
②数据抽象是指定义数据类型和施加于该类型对象的操作，并限定了对象的取值范围，只能通过这些操作修改和观察数据。
12、模块化P66
即把软件按照规定原则，划分为一个个较小的，相互独立的但又相互关联的部件。
模块化实际上是系统分解和抽象的过程。
在软件工程中模块是数据说明，可执行语句等程序对象的集合，是单独命名的，并且是可以通过名字来访问的。
13、模块独立P68
1、所谓的模块独立是指：
模块完成独立的功能并且与其他模块的接口简单，符合信息隐蔽，模块间关联和依赖程度尽可能小。
（模块独立性是模块化、信息隐藏和局部化等概念的直接结果。
）
2、模块的独立性是很重要的：
1 功能被划分，并且接口被简化，所以具有有效模块的软件更易于开发。
2 由于因设计和编码修改引起的副作用受到局限，错误传播减小，并且模块复用成为可能，所以独立的模块更易于维护和测试。
3、模块独立性比较强的模块应该是：
高内聚，低耦合。
4、内聚是一个模块内部各个元素彼此结合的紧密程度的度量。
一般内聚性分为7个类型：
（1）.巧合内聚（偶然内聚）：
将几个模块中没有明确表现出独立功能的相同程序代码独立出来建立的模块称为巧合内聚模块。
（2）.逻辑内聚：
是指完成一组逻辑相关任务的模块，调用该模块时，由传送给模块的控制型参数来确定该模块应执行哪一种功能。
（3）.时间内聚
（4）.过程内聚
（5）.通信内聚：
是指一个模块内所有处理元素都集中在某个数据结构的一块区域中。
（6）.顺序内聚
（7）.功能内聚：
是指一个模块中各个部分都是为完成一项具体功能而协同工作，紧密联系不可分割。
十四、评估可选的体系结构（了解过程、概念）P74
卡耐基-梅隆大学软件工程研究所（SEI）建立了一套迭代的评价过程来评测软件体系结构的合理性。
这种方法称为ATAM（体系结构权衡分析法）。
在结构化分析与设计方法中，模块的内聚度和耦合度是判断结果好坏的主要标准。
十五、结构化程序设计方法P76
1、定义：
如果一个程序的代码块仅仅通过顺序，选择和循环这3种基本控制结构进行连结，并且每个代码块只有一个入口和一个出口，则称这个程序是结构化的。
通常结构化程序设计也采用自顶向下、逐步求精的设计方法，这种方法符合抽象和分解的原则（是人民解决复杂问题的常用方法）
2、图形表示法：
①程序流程图
②N-S图（盒图）
③PAD（problemanalysisdiagram）
④判定表（取值T和F）。
3、设计性语言PDL（programdesignlanguage）是一种用于描述功能部件的算法设计和处理细节的语言。
PDL是一种伪码。
第5章结构化分析与设计P86-135
16、数据流图（DFD）P88-97
数据流图（dataflowdiagramDFD）描述输入数据流到输出数据流的变化（即加工）用于对系统的功能建模。
数据流图的基本图形元素包括：
源或宿、加工、数据流、文件。
●源或宿（sourceorsink）：
是指存在于软件系统之外的人员或组织，表示软件系统输入数据的来源和输出数据的去向，因此也称为源点和终点。
用图形符号表示。
●加工（process）：
描述了输入数据流到输出数据流的变换，即将输入数据流加工成输出数据流。
用一个定义明确的名字标识。
●数据流（dataflow）：
由一组固定成分的数据组成，代表数据的流动方向。
●文件（file）：
用于存放数据。
16、数据字典（定义、条目、明确哪些是要素）P104
数据字典由字典条目组成，每个条目描述DFD中的一个元素。
2、字典条目的种类：
数据流、文件、数据项（组成数据流和文件的数据）、加工、源或宿。
第七章面向对象的分析和设计P148-211
十七、面向对象的基本概念P149-152
面向对象=对象+分类+继承+通过消息的通信。
1、对象（object）：
是指一组属性以及这组属性上的专用操作的封装体。
2、封装（encapsulation）：
是一种信息隐蔽技术，用户只能看见对象封装界面上的信息，对象的内部实现对用户是隐蔽的。
封装的目的是使对象的使用者和生产者分离，使对象的定义和实现分开。
3、继承（inheritance）：
是类间的基本关系，它是基于层次关系的不同类共享数据和操作的一种机制。
父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和操作外，可以继承其父类（或祖先类）的属性和操作，还可以对父类（或祖先类）中的操作重新定义其实现方法。
4、多态性（polymorphism）：
是指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。
5、动态绑定（dynamicbinding）：
是指在程序运行时才将消息所请求的操作与实现该操作的方法进行连接。
18、面向对象分析的步骤P153
1 获取客户对系统的需求，包括标识场景和用况，以及建造需求模型。
2 用基本的需求为指南来选择类和对象（包括属性和操作）。
3 定义类的结构和层次。
4 建造对象-关系模型。
5 建造对象-行为模型。
6 利用用况/场景来复审分析模型。
19、面向对象设计（OOD）的一般步骤P155
（1）系统设计——1.将子系统分配到处理器。
2.选择实现数据管理、界面支持和任务管理的设计策略。
3.为系统设计合适的控制机制。
4.复审并考虑权衡。
（2）对象设计——1.在过程级别（procedurallevel）设计每个操作。
2.定义内部类。
3.为类属性设计内部数据结构。
（3）消息设计——使用对象间的协作和对象-关系模型，设计消息模型。
（4）复审——对设计模型进行复审，并且在需要的时候进行迭代。
二十、用况建模
用况建模用于描述一个系统应该做什么，用况建模不仅用于新系统的需求获取，还可用于已有系统的升级。
用况建模步骤P166
1 定义系统。
2 确定参与者。
3 确定用况。
4 描述用况。
5 定义用况间的关系。
6 确认模型。
二十一、CRC技术P177
CRC（类—责任—协作者）技术，是一种标识类的技术。
标识类：
一组具有相同属性和操作的对象可以定义成一个类，因此标识类和标识对象是一致的。
标识类的过程可以分为①标识潜在对象和②筛选潜在对象二步进行。
二十二、类之间的关系P182
类图中的关系有关联、依赖、泛化、实现等
1、关联的种类主要有二元关联、多元关联、受限关联、聚集和组合。
●二元关联——描述两个类之间的关联，用两个类之间的一条直线来表示，直线上可写上关联名。
关联通常是双向的，因此可以有两个关联名，可以用一个实心的三角来指明关联名所指的方向。
●多元关联——是指3个或3个以上类之间的关联。
它由一个菱形，以及由菱形引出的通向各个相关类的直线组成，关联名可标在菱形的旁边，在关联的端点也可以标上重数等信息。
第9章人机界面设计P231-248
二十三、人机界面可以分为：
语言界面、图形用户界面、直接操纵用户界面、多媒体用户界面和多通道用户界面。
第10章程序设计语言和编码（任务）P249-262
1.程序设计语言的基本成分：
数据成分，运算成分，控制成分，传输成分。
2.程序设计风格包括：
源程序文档化、数据说明、语句结构和输入输出。
3.程序设计语言的分类：
从属于机器的语言（第一代语言）、汇编语言（第二代语言）、高级程序设计语言（第三代语言）、第四代语言（4GL）。
4.程序设计语言的特性和程序设计风格会深刻地影响软件的质量和可维护性。
第十一章软件测试P263-302
二十四、软件测试的目的P263
——是通过测试发现软件中的错误和缺陷，并加以纠正。
应该排除对测试的额错误观点，设计合适的测试用例，用尽可能少的测试用例，来发现尽可能多的软件错误。
二十五、白盒测试（方法）P265266
1、白盒测试（又称为结构测试）把测试对象看作一个透明的盒子，测试人员根据程序内部的逻辑结构及有关信息设计测试用例，检查程序中所有逻辑路径是否都按预定的要求正确地工作。
2、白盒测试方法主要有：
逻辑覆盖测试、基本路径测试、数据流测试和循环测试。
二十六、黑盒测试P265277
1、黑盒测试（又称为行为测试）把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只根据程序的需求规格说明书，检查程序的功能是否符合它的功能需求。
2、黑盒测试方法有：
等价类划分，边界值分析，比较测试，错误猜测和因果图方法。
3、边界值分析方法通常是等价类划分方法的一种补充。
它是专门挑选那些位于输入或输出范围边界附近的数据（即正好等于、或刚刚大于、或刚刚小于边界的值）用作测试用例
第十三章软件维护与再工程P317-331
二十七、软件维护
1、概念：
软件维护是指软件系统交付使用以后，为了改正错误或满足新的需要而修改软件的过程。
2分类：
根据起因不同，软件维护可分为：
纠错性维护、适应性维护、改善性维护和预防性维护。
二十八、再工程技术
1、概念：
再工程是指在逆向工程所获信息的基础上修改或重构已有的系统，产生系统的一个新版本。
其主要目的是为遗留系统转化为可演化系统提供一条现实可行的途径。
2再工程包含：
业务过程再工程和软件再工程。
●业务过程再工程BPR（也称业务过程重组）定义业务目标、标示并评估现有的业务过程以及修订业务过程以更好满足业务目标，这一部分通常由咨询公司的业务专家完成。
●软件再工程包含库存目录分析、文档重构、逆向工程、程序和数据重构以及正向工程。
其他概念：
✧软件的可维护性：
是指理解、改正、调整和改进软件的难以程度
✧逆向工程:
是指在软件生存周期中，将软件的某种形式描述转换成更抽象形式的活动。
✧重构（restructuring）：
指在同一抽象级别上转换系统的描述形式。
如把C++程序转换成Java程序
✧设计恢复（designrecovery）：
指借助工具从已有程序中抽象出有关数据结构设计、总体结构设计和过程设计的信息。
第十四章软件项目管理（定义、对象）P332
二十九、软件项目管理概述
软件项目管理是指软件生存周期中软件管理者所进行的一系列活动，其目的是在一定的时间和预设范围内，有效地利用人力、资源、技术和工具，使软件系统或软件产品按原定计划和质量要求如期完成。
2、项目管理是通过项目经理和项目组织的努力，运用系统理论的方法对项目及其资源进行计划，组织，协调，控制，旨在实现项目的特定目标的管理方法体系。
3、其基本内容为：
①项目定义；
②项目计划；
③项目执行；
④项目控制；
⑤项目收尾。
三十、软件项目管理的对象P335
——是软件工程项目，其范围覆盖了整个软件工程过程，而现代项目管理的要求就是要求要对项目的整个过程进行计划，以及对项目的实施进行控制，也就是对软件项目进行开发过程的支持、管理与质量和进度的控制。
三十一、软件度量P338
——是指计算机软件范围内的测量，主要是为产品开发的软件过程和产品本身定义相关的测量方法和标度，对软件开发过程度量的目的是为了对过程进行改进，对产品进行度量的目的是为了提高产品的质量。
度量的作用是为了有效地采用质量的方式来进行管理。
三十二、面向功能的度量P342
1、——它是一种针对软件的功能特性进行度量的方法，该方法主要考虑软件系统的“功能性”和“实用性”。
他建议一种称为“功能点”（functionpoint，FP）的测量，功能点是基于软件信息域的特征（可直接测量）和软件复杂性进行计算的。
2、功能点的计算步骤：
（1）计算信息域特征的值CT
（2）计算复杂度调整值
（3）计算功能点FP
三十三、软件质量模型（McCall模型）
——包括软件质量要素、评价标准和度量3个层次的软件质量度量模型框架。
软件质量要素——
（1）与软件运行相关的质量要素包括：
正确性、可靠性、效率、完整性和可用性；
（2）与软件修正相关的质量要素包括：
可维护性、灵活性和可测试性；
（3）与软件转移相关的质量要素包括：
可移植性、可复用性和可互操作性。
其中：
正确性：
一个程序满足它的需求规约已经实现客户任务目标的程度。
可用性：
一个程序期望以所需的精确度完成它的预期功能的程度。
可维护性：
定位和修复程序中一个错误所需的工作量。
可移植性：
把一个程序从一个硬件和/或软件系统环境移植到另一个所需的工作量。
三十四、软件可靠性计算公式
MTBF=MTTF+MTTR
平均故障（失效）间隔时间
MTTF：
平均故障（失效）时间
MTTR：
平均修复时间
升级会员 