软件工程复习大纲.docx
《软件工程复习大纲.docx》由会员分享，可在线阅读，更多相关《软件工程复习大纲.docx（14页珍藏版）》请在冰豆网上搜索。
软件工程复习大纲
软件工程复习提纲
软件工程复习提纲
第一部分引言
软件危机的定义及表现
软件工程的的定义和层次化技术
软件生存周期
瀑布模型，增量模型，快速原型，喷泉模型，螺旋模型
第二部分结构化技术
给一个应用题要会做结构化分析和结构化设计（与平时的作业类似，画数据流图和结构图）
需求的层次
需求的工作活动
总体设计的任务
深度、宽度、扇出和扇入
模块的独立性
七内聚和七耦合
详细设计任务和原则
程序的环形复杂度（McCabe方法）
Myers软件测试目的
测试与软件开发各阶段的关系
黑盒测试的定义和方法
白盒测试的定义和方法
软件测试的策略
维护的分类
第三部分面向对象技术
面向对象的基本概念，
用况建模和用况的关系
静态建模和类之间的关系
动态建模中的时序图
构件
基于构件的软件开发
综合题面向对象建模用例建模，静态建模和动态建模：
第一部分引言
软件危机的定义及表现:
软件危机定义：
软件在开发和维护过程中遇到的一系列严重问题
软件危机包含两层含义：
如何开发软件如何维护数量不断膨胀的已有软件
软件危机的表现：
（1）软件开发的进度难以控制，经常出现经费超预算、完成期限一再拖延的现象
（2）软件需求在开发初期不明确，导致矛盾在后期集中暴露，从而对整个开发过程带来灾难性的后果（3）由于缺乏完整规范的资料，加之软件测试不充分，从而造成软件质量低下，运行中出现大量问题。
（4）软件文档资料不完整、不合格（5）软件的可维护性差
程序中的错误难以改正，程序不能适应硬件环境的改变，不能应用户要求增加新的功能。
（6）软件价格昂贵，软件成本在计算机系统总成本中所占的比例逐年上升
软件工程的定义和层次化技术:
软件工程：
是研究和应用如何以系统化的、规范的、可度量的方法去开发、运行和维护软件，即把工程化应用到软件上软件生存周期
软件工程是一种层次化的技术。
包含了一个观点和三个要素
质量观点：
软件工程必须以有组织的质量保证为基础开发软件
三要素：
●软件工程过程：
是进行一系列有组织的活动，从而能够合理和及时地开发出计算机软件。
过程定义了技术方法的采用、工程产品（包括模型、文档、数据、报告、表格等）的产生、里程碑的建立、质量的保证和变更的管理
●软件工程方法：
为软件开发提供“如何做”的技术。
它包括了项目计划、需求分析、系统设计、程序实现、测试与维护等一系列的任务。
●软件工程工具：
为过程和方法提供自动的或半自动的支持。
这些软件工具被集成起来，建立起一个支持软件开发的系统，称之为计算机辅助软件工程（CASE,ComputerAidedSoftwareEngineering）。
CASE集成了软件、硬件和一个存放开发过程信息的软件工程数据库，形成了一个软件工程环境。
瀑布模型，增量模型，快速原型，喷泉模型，螺旋模型
瀑布模型（WaterfallModel）：
1970年WinstonRoyce提出了著名的"瀑布模型"，直到20世纪80年代早期，它一直是惟一被广泛采用的软件开发模型。
特点：
●自上而下、相互衔接的固定次序，如同瀑布流水，逐级下落。
●在瀑布模型中，软件开发的各项活动严格按照线性方式进行，当前活动接受上一项活动的工作结果，实施完成所需的工作内容。
当前活动的工作结果需要进行验证，如果验证通过，则该结果作为下一项活动的输入，继续进行下一项活动，否则返回修改。
●瀑布模型强调文档的作用，并要求每个阶段都要仔细验证。
但是，这种模型的线性过程太理想化，已不再适合现代的软件开发模式，其主要问题在于：
●各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；
●由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发的风险；
●早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果
增量模型：
也称为渐增模型，它分批地逐步向用户提交产品，每次提交一个满足用户需求子集的可运行的产品
●使用增量模型开发软件时，把软件产品作为一系列的增量构件来设计、编码、集成和测试。
●每个构件由多个相互作用的模块构成，并且能够完成特定的功能。
●使用增量模型时，第一个增量构件往往实现软件的基本需求，提供最核心的功能。
例如:
使用增量模型开发文字处理软件时，第一个增量构件可能提供基本的文件管理、编辑和文档生成功能；第二个增量构件提供更完善的编辑和文档生成功能；第三个增量构件实现拼写和语法检查功能；第四个增量构件完成高级的页面排版功能。
●把软件产品分解成增量构件时，应该使构件的规模适中，规模过大或过小都不好。
●最佳分解方法因软件产品特点和开发人员的习惯而异。
分解时惟一必须遵守的约束条件是，当把新构件集成到现有软件中时，所形成的产品必须是可测试的，必须不破坏原来已经开发出的产品。
快速原型模型（RapidPrototypeModel）：
●第一步是建造一个快速原型（样板），实现客户或未来的用户与系统的交互，用户或客户对原型进行评价，进一步细化待开发软件的需求。
逐步调整原型使其满足客户的需求。
●第二步则在第一步的基础上开发客户满意的软件产品
该方法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的开发风险，具有显著的效果。
使用该方法一旦确定了客户的真正需求，所建造的原型将被丢弃。
原型系统的内部结构并不重要，重要的是必须迅速建立原型，随之迅速修改原型，以反映客户的需求
喷泉模型：
适用于面向对象方法。
主张分析和设计过程的重叠、不严格区分。
模块集成过程：
反复经过分析、设计、测试、集成，再分析、设计、测试、集成
螺旋模型（SpiralModel）：
1988年，BarryBoehm正式发表了软件系统开发的“螺旋模型”，它将瀑布模型和快速原型模型结合起来强调风险分析，特别适合于大型复杂的系统
螺旋模型沿着螺线进行若干次迭代，图中的四个象限代表了以下活动：
（1）制定计划：
确定软件目标，选定实施方案，弄清项目开发的限制条件；
（2）风险分析：
分析评估所选方案，考虑如何识别和消除风险；
（3）实施工程：
实施软件开发和验证；
（4）客户评估：
评价开发工作，提出修正建议，制定下一步计划。
螺旋模型也有一定的限制条件，具体如下：
（1）如果执行风险分析将大大影响项目的利润，那么进行风险分析毫无意义，因此，螺旋模型只适合于大规模软件项目。
（2）只有在开发人员具有风险分析和排除风险的经验及专门知识时，使用这种模型才会获得成功
第二部分结构化技术
给一个应用题要会做结构化分析和结构化设计（与平时的作业类似，画数据流图和结构图）
3.3结构化分析建模
需求的层次
需求的层次：
软件需求包括三个不同的层次：
1、业务需求（businessrequirement）反映了组织机构或客户对系统、产品高层次的目标要求，它们在项目视图与范围文档中予以说明。
2、用户需求（userrequirement）文档描述了用户使用产品必须要完成的任务，这在使用用例（usecase）文档或方案脚本（scenario）说明中予以说明。
3、功能需求（functionalrequirement）定义了开发人员必须实现的软件功能，使得用户能完成他们的任务，从而满足了业务需求。
作为补充，软件需求规格也包括：
4、非功能需求（non-functionalrequirement）它包括产品必须遵从的标准、规范和合约；外部界面的具体细节；性能要求；设计或实现的约束条件及质量属性。
注：
软件需求各组成部分之间的关系p26
需求的工作活动
主要活动：
需求获取需求建模（需求分析）需求传递：
编写规格（规约）说明书需求验证需求管理
总体设计的任务
软件系统结构的总体设计：
基于功能层次结构建立系统采用某种设计方法，将系统按功能划分成模块的层次结构确定每个模块的功能建立与已确定的软件需求的对应关系确定模块间的调用关系确定模块间的接口评估模块划分的质量
深度、宽度、扇出和扇入
深度、宽度、扇出和扇入都应适当:
●程序结构的深度：
程序结构的层次数称为结构的深度。
结构的深度在一定意义上反映了程序结构的规模和复杂程度。
●程序结构的宽度：
层次结构中同一层模块的最大模块个数称为结构的宽度。
模块的扇入和扇出：
●扇出表示一个模块直接调用（或控制）的其他模块数目。
●扇入则定义为调用（或控制）一个给定模块的模块个数。
多扇出意味着需要控制和协调许多下属模块。
而多扇入的模块通常是公用模块。
观察大量软件系统后发现，设计得很好的软件结构通常顶层扇出比较高，中层扇出较少，底层扇入到公共的实用模块中去（底层模块有高扇入）
模块的独立性
模块独立性,是指软件系统中每个模块只涉及软件要求的具体的子功能,而和软件系统中其它的模块的接口是简单的;
例如:
若一个模块只具有单一的功能且与其它模块没有太多的联系,则称此模块具有模块独立性一般采用两个准则度量模块独立性。
即模块间耦合和模块内聚
七内聚和七耦合
耦合是模块之间的互相连接的紧密程度的度量。
内聚是模块功能强度（一个模块内部各个元素彼此结合的紧密程度）的度量。
模块独立性比较强的模块应是高内聚低耦合的模块
详细设计任务和原则
在详细设计过程中，需要完成的工作是：
确定软件各个组成部分内的算法以及各部分的内部数据组织选定某种过程的表达形式来描述各种算法。
进行详细设计的评审
目标：
给出软件模块结构中各个模块的内部过程描述，从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言表达的程序。
编写软件的“详细设计说明书”。
详细设计的任务：
●为每个模块确定所采用的算法，并选择某种适当的工具表达算法的执行过程，写出模块的详细过程性描述。
●确定每一模块使用的数据结构。
●确定模块接口的细节，包括对系统外部的接口和用户界面，对系统内部其他模块的接口，以及模块的输入数据、输出数据及局部数据的全部细节。
（在详细设计结束时，应该把上述结果写入详细设计说明书，并且通过复审成为正式文档，交付给编码阶段作为工作的依据。
●为每一个模块设计出一组测试用例，以便在编码阶段对模块代码进行预定的测试。
（模块的测试用例是软件测试计划的重要组成部分，通常应包括输入数据、期望的输出结果等内容。
测试用例应由负责详细设计的软件人员来完成，因为他们对模块功能的实现了解得最清楚）
程序的环形复杂度（McCabe方法）
mcCabe’sTheory（ThomasmcCabe,1976）
●第1步：
将程序流程图转化为程序图（ControlFlowGraph）程序图是一种简化了的流程图，也就是把程序流程图中每个处理符号都退化成一个点，原来连接不同处理符号的箭头变成连接不同点的有向弧，这样得到的有向图就称为程序图
●第2步：
计算CFG的环形复杂度（CyclomaticComplexity）
McCabe环形复杂度的特点：
●分支或循环增多时，CC也随之增大，故CC值实际上是为软件测试的难易度提供了一个定量度量的方法，间接表示了软件的可靠性。
●CC是可加的：
2模块的总复杂度=各自CC之和。
●实践经验表明，对于CC>10的程序，应分成几个小程序处理，以降低出错率。
Myers软件测试目的
Myers软件测试目的：
●测试是软件的执行过程，目的在于发现错误；
●一个好的测试用例在于能发现至今未发现的错误；
●一个成功的测试是发现了至今未发现的错误的测试
测试的目的是：
●想以最少的时间和人力，系统地找出软件中潜在的各种错误和缺陷。
●测试的附带收获是：
它能够证明软件的功能和性能与需求说明相符合。
●实施测试收集到的测试结果数据为可靠性分析提供了依据。
●测试不能表明软件中不存在错误，它只能说明软件中存在错误。
测试与软件开发各阶段的关系
测试过程是依开发相反顺序安排的自底向上，逐步集成的过程。
黑盒测试的定义和方法
黑盒测试又叫做功能测试或数据驱动测试。
这种方法是测试人员把测试对象看做一个黑盒子，不考虑程序内部的逻辑结构和内部特性,只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
黑盒测试方法是在程序接口上进行测试，主要是为了发现以下错误:
●是否有不正确或遗漏了的功能?
●在接口上，输入能否正确地接受?
能否输出正确的结果?
●是否有数据结构错误或外部信息（例如数据文件）访问错误?
●性能上是否能够满足要求?
●是否有初始化或终止性错误?
用黑盒测试发现程序中所有的错误，必须把满足输入条件和输出条件的数据都进行测试，即穷尽测试。
但这是不可能的。
白盒测试的定义和方法
白盒测试又称为结构测试或逻辑驱动测试。
此方法把测试对象看作一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。
软件人员使用白盒测试方法，主要想对程序模块进行如下的检查：
●对程序模块的所有独立的执行路径至少测试一次；
●对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次；
●在循环的边界和运行界限内执行循环体；
●测试内部数据结构的有效性，等。
白盒测试要做到穷尽测试，可能吗？
软件测试的策略
测试过程按4个步骤进行：
A.单元测试
B.组装测试
C.确认测试
D.系统测试
维护的分类
软件维护定义：
是指在软件系统已经交付使用之后，软件使用人员为了适应新的要求、满足新的需要或为了改正软件中存在的错误而对软件系统进行修改的过程。
软件系统维护分为以下四类：
●诊断和改正错误——改正性维护（correctivemaintenance）,约占全部维护活动的17~21%；
●为了适应变化了的环境（如软\硬件升级、新数据库等）而修改软件——适应性维护（adaptivemaintenance），约占全部维护活动的18~25%；
●为了增加新功能，修改已有功能，改造界面，增加HELP等，而修改软件——完善性维护（perfectivemaintenance）,约占全部维护活动的50~66%
●为了改进未来的可维护性或可靠性，或为了给未来的改进奠定更好的基础而修改软件——预防性维护（preventivemaintenance），与其它维护活动共占总维护的4%左右
注：
●一般维护的工作量占生存周期70%以上，维护成本约为开发成本的4倍（80-20Rule）；
●文档维护与代码维护同样重要
第三部分面向对象技术
面向对象的基本概念，
面向对象=对象（object）+分类（classification）+继承（inheritance）+通过消息的通信（communicationwithmessages）可以说，采用这四个概念开发的软件系统是面向对象的
1.对象（object）
⏹对象是指一组属性以及这组属性上的专用操作的封装体
⏹属性（attribute）通常是一些数据，有时它也可以是另一个对象。
每个对象都有它自己的属性值，表示该对象的状态。
对象中的属性只能通过该对象所提供的操作来存取或修改
⏹操作（operation）（也称方法或服务）规定了对象的行为，表示对象所能提供的服务
⏹封装（encapsulation）是一种信息隐蔽技术，用户只能看见对象封装界面上的信息，对象的内部实现对用户是隐蔽的。
封装的目的是使对象的使用者和生产者分离，使对象的定义和实现分开
一个对象通常可由对象名、属性和操作三部分组成
2.类（class）
⏹类是一组具有相同属性和相同操作的对象的集合。
一个类中的每个对象都是这个类的一个实例（instance）
⏹类是创建对象的模板，从同一个类实例化的每个对象都具有相同的结构和行为
3.继承（inheritance）
继承是类间的基本关系，它是基于层次关系的不同类共享数据和操作的一种机制。
父类中定义了其所有子类的公共属性和操作，在子类中除了定义自己特有的属性和操作外，可以继承其父类（或祖先类）的属性和操作，还可以对父类（或祖先类）中的操作重新定义其实现方法
4.消息（message）
消息传递是对象间通信的手段，一个对象通过向另一个对象发送消息来请求其服务。
一个消息通常包括接收对象名、调用的操作名和适当的参数（如果有必要的话）。
消息只告诉操作。
消息完全由接收者解释，接收对象需要完成什么操作，但并不指示接收者怎样完成，完成者独立决定采用什么方法完成所需的操作
5.多态性（polymorphism）
多态性是指同一个操作作用于不同的对象上可以有不同的解释，并产生不同的执行结果。
例如“画”操作，作用在“矩形”对象上，则在屏幕上画一个矩形，作用在“圆”对象上，则在屏幕上画一个圆。
也就是说，相同操作的消息发送给不同的对象时，每个对象将根据自己所属类中定义的这个操作去执行，从而产生不同的结果
6.动态绑定（dynamicbinding）
⏹动态绑定是指在程序运行时才将消息所请求的操作与实现该操作的方法连接起来
⏹传统的程序设计语言的过程调用与目标代码的连接（即调用哪个过程）放在程序运行前（即编译时）进行（称为静态绑定），而动态绑定则是把这种连接推迟到运行时才进行
⏹动态绑定是一种在运行时确定被执行代码的技术
用况建模和用况的关系
用况建模是用于描述一个系统应该做什么的建模技术，用况建模不仅用于新系统的需求获取，还可用于已有系统的升级。
用况模型用用况图来描述
⏹用况图展示了各类外部执行者与系统所提供的用况之间的连接。
一个用况是系统所提供的一个功能（也可以说是系统提供的某一特定用法）的描述
⏹执行者是指那些可能使用这些用况的人或外部系统，执行者与用况的连接表示该执行者使用了那个用况
⏹用况图给出了用户所感受到的系统行为，但不描述系统如何实现该功能
⏹用况通常用普通正文描述，也可以用活动图来描述
静态建模和类之间的关系
又名类和对象建模
类和对象模型的基本模型元素有类、对象以及它们之间的关系。
系统中的类和对象模型描述了系统的静态结构，在UML中用类图和对象图来表示
动态建模中的时序图
顺序图用来描述对象间的交互行为，它关注于消息的顺序，即对象间消息的发送和接收的顺序。
顺序图还揭示了一个特定场景的交互，即系统执行期间发生在某时间点的对象之间的特定交互。
它适合于描述实时系统中的时间特性和时间约束
顺序图有两个坐标，垂直坐标表示时间（从上到下），水平坐标表示一组对象（用对象框表示）
构件
构件（Component）的典型定义：
●Pressman书中的定义：
构件是某系统中有价值的、几乎独立的并可替换的一个部分，它在良好定义的体系结构语境内满足某清晰的功能
●Brown的定义：
构件是一个独立发布的功能部分，可以通过其接口访问它的服务
●“计算机科学技术百科全书”的定义：
软件构件是软件系统中具有相对独立功能，可以明确标识，接口由规约指定，与语境有明显依赖关系，可独立部署，且多由第三方提供的可组装软件实体；软件构件须承载有用的功能，并遵循某种构件模型；可复用构件是指具有可复用价值的构件
构件的要素:
规格说明：
建立在接口概念之上，作为服务提供方与客户方之间的契约一个或多个实现受约束的构件标准包装方法构建按不同的方式分组（成为包）来提供一套可替换的服务部署方法
商用成品构件:
Commercialoff-the-shelf简称COTS指由第三方开发的满足一定构件标准的，可组装的软件构件
3C构件模型:
关于构件的一个指导性模型由构件的三个不同方面的描述组成
●概念（concept）：
关于“构件做什么”的抽象描述，可以通过概念去理解构件的功能。
概念包括接口规约和语义描述两部分，语义描述和每个操作相关联（至少表示为前后置谓词形式）
●内容（content）：
概念的具体实现，描述构件如何完成概念所刻画的功能
●周境（context）：
描述构件和外围环境在概念级和内容级的关系，刻画构件的应用环境，为构件的选用和适应性修改提供指导
REBOOT构件模型:
REBOOT（ReuseBasedonObject_OrientedTechnology）：
基于面向对象技术的复用
一种基于刻面（facet）的模型:
刻面：
对领域进行分析，所得到的一组基本的描述特征
刻面可以描述构件执行的功能、所操作的数据、构件应用的周境或任何其他特征
通常的刻面描述限制在不超过7或8个刻面
一个构件通常包括以下刻面：
●抽象（abstraction）：
它是构件概念的抽象性描述
●操作（operation）：
它是构件所提供的操作的描述
●操作对象（operand）：
它描述操作的对象
●依赖（dependency）：
它描述构件与外界的依赖关系
常用的构件标准:
CORBA（公共对象请求代理体系结构）:
CommonObjectRequestBrokerArchitecture
OMG发布的构件标准
核心是ORB（ObjectRequestBroker），定义了异构环境下对象透明地发送请求和接收响应的基本机制
COM+:
微软开发的一个构件对象模型，提供了在运行于Windows操作系统之上的单个应用中使用不同厂商生产的对象的规约
EJB：
一种基于Java的构件标准
提供了让客户端使用远程的分布式对象的框架
EJB规约规定了EJB构件如何与EJB容器进行交互
基于构件的软件开发
综合题面向对象建模用例建模，静态建模和动态建模：
升级会员 