软件工程自考复习资料全.docx

软件工程自考复习资料全.docx

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

软件工程自考复习资料全

第一章绪论

一、软件的基本概念

1.软件是计算机系统中的程序及其文档。

2.程序是计算机任务的处理对象和处理规则的描述；文档是为了理解程序所需的阐述性的文书和资料。

3.文档一般主要面向管理人员、开发人员、用户、使用维护人员。

4.文档在软件工程中的作用：

（1）提高软件开发过程的能见度。

（2）提高开发效率。

（3）作为开发人员阶段工作成果和结束标志。

（4）记录开发过程有关信息便于使用和维护。

（5）提供软件运行、维护和培训等资料。

（6）便于用户了解软件功能、性能。

5.软件的生产经历了三个阶段：

*程序设计时代：

生产方式是个体手工劳动，使用工具是机器、汇编语言，主要通过汇编来实现，不注重程序设计方法。

*程序系统时代：

生产方式是作坊式小集团合作生产，生产工具是高级语言，开始提出结构化方法。

*软件工程时代：

生产方式是工程化生产，使用数据库、网络、先进的开发技术和方法。

6.软件既是知识性（逻辑性）工业产品，具有一些独特的特性是：

*软件是逻辑产品，具无形性，通过计算机的执行才能体现它的功能和作用。

*软件只会退化，不存在磨损和消耗问题。

*成本主要体现在软件的开发和研制上，可进行大量的复制。

*主要靠脑力劳动生产，开发和维护成本高。

7.软件的主要结构和功能是在分析设计阶段决定的。

8.软件的复杂性主要体现在程序的复杂性，即模块内程序的复杂性。

直接关联到软件的简单和可理解性、开发费用多少、开发周期长短和软件潜伏错误的多少。

二、软件危机

1.软件危机是指在软件开发和维护时遇到的一系列难以控制的问题导致的供需矛盾。

出现在软件发展的第二阶段末期，随着第三代计算机的诞生之际。

2.软件危机主要体现在：

*软件发展速度跟不上硬件的发展和用户需求。

*软件成本和开发进度不能预先预算，用户不满意。

*软件产品质量差，成本高，可靠性没有保证。

*软件可维护性差，产品没有配套文档。

3.软件危机产生原因：

（1）软件规模变大，结构更加复杂。

（2）软件开发管理困难。

（3）软件开发技术和工具落后。

（4）软件开发费用增加。

（5）采用落后的个体手工生产方式开发。

4.解决途径：

（1）纠正对软件开发的错误观念。

（2）提高软件工程管理水平，重视文档重要性。

（3）使

用好的软件开发工具，研究软件开发技术，规范软件开发流程，提高开发效率。

5.为了克服软件危机，人们首先想到要用形式化方法来开发软件。

三、软件开发

1.软件开发的本质是实现问题空间的概念和处理逻辑到运行平台的概念和处理逻辑间的映射。

2.软件开发基本途径：

先通过需求建模，把问题域的概念和处理逻辑向需求（抽象）层次进行映射，再把需求层的概念和处理逻辑向设计（抽象）层进行映射，依次进行，直到映射到运行平台这一抽象层为止。

3.软件开发涉及的技术：

过程方向（即求解软件的开发逻辑）和过程途径（即求解软件的开发手段，基本手段是问题建模）。

4.软件开发方法：

是一种使用早已定义好的技术集及符号表示习惯来组织软件生产的过程。

5.问题建模是指运用所掌握的知识，通过抽象，给出该问题的一个结构。

建模手段有结构化方法、面向对象方法和诸多面向数据结构的方法。

6.模型是待建系统的任意抽象，包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节，是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统边界的描述、对系统内各模型元素以及它们之间关系的语义描述。

7.软件系统模型大体分为概念模型和软件模型，而软件模型进一步分为设计模型、实现模型、部署模型。

四、软件开发环境

1.软件开发环境是相关的一组软件工具的集合，支持一定的软件开发方法或按照一定的软件开发模型组织而成，与软件生存期、软件开发方法、软件处理模型密切相关。

●按解决问题分类：

程序设计环境、系统合成环境、项目管理环境。

●按演变趋向分类：

以语言为中心的环境、工具箱环境、基于方法的环境（分为支持软件开发周期特定阶段的管理和开发过程管理。

后者即项目计划和控制、任务管理）。

2.软件开发环境是高度集成的一体化系统，主要目标是提高软件开发的生产率、降低软件成本。

五、软件工具

1.软件工具是指为支持计算机软件的开发、维护、模拟、移植或管理而研制的程序系统，是为了支持软件人员开发和维护活动而使用的软件。

2.软件工具由工具、工具接口、工具用户接口组成，主要目的是提高软件生产率和改善软件质量。

3.发展特点：

（1）由单个工具到多个工具集成化方向发展。

（2）重视用户界面设计，不断采用新理论技术。

（3）它的商品化推动软件产业的发展，进而增加了对软件工具的需求，促进了软件工具的商品化过程。

4.分为6类：

模拟工具、开发工具、测试和评估工具、运行和维护工具、性能测试工具、程序设计支持工具。

六、软件工程

1.由于软件危机，产生了以软件开发技术（主要研究软件开发方法、过程、工具和环境）和软件工程管理（主要研究软件管理学、心理学、经济学）为研究内容的软件工程学科，以达到软件开发工程化的最终目标。

2.软件工程是用科学知识、技术以及工程管理原则和方法来定义、开发、维护软件，按预算和进度实现满足用户要求的软件产品的一门综合性的交叉学科。

3.软件工程是一种自顶向下分阶段实现的软件程序开发方法，着重于建造软件系统，要用管理科学的方法和原理进行软件生产的管理。

4.软件工程的概念于1968年提出，涉及计算机科学、工程科学、管理科学、数学等领域。

5.软件工程面临的问题有：

软件费用、软件可靠性、软件可维护性、软件生产率和软件重用。

6.软件工程过程是指规定了获取、供应、开发、操作、维护、管理、支持过程时，要实施的过程、活动和任务。

7.软件工程的纵向分解是把软件生产分为几个阶段。

七、计算机辅助软件工程

1.计算机辅助软件工程（CASE），英文是ComputerAidedSoftwareEngineering，是一组工具和方法的集合，可以辅助软件开发生命周期各阶段进行软件开发。

2.较早期的CASE是结构的基于图形的CASE。

3.CASE领域是一个应用、集成和综合的领域。

它把软件开发技术、软件工具和软件开发方法集成到一个统一而一致的框架，吸收了CAD、网络、软件工程、数据库、操作系统和许多其他计算机领域的原理和技术。

4.根据支持的范围，CASE工具可分为窄支持（支持单个过程任务的工具）、较宽支持（工作台支持某一过程所有活动或某些活动）、一般支持（环境软件过程所有活动或至少大部分活动）工具。

另外还可根据支持过程和功能进行分类。

5.CASE生存期步骤：

CASE需求、CASE剪裁、CASE引入、CASE操作、CASE演化、CASE废弃。

6.CASE系统所涉及的技术有：

支持软件开发过程本身的技术、支持软件开发过程管理的技术。

从CASE系统产生方式看还有一种生成CASE系统的生成器所采用的技术：

元-CASE技术。

7.集成化CASE的五级模型：

●平台集成：

工具运行在相同的硬件/操作系统平台上。

●数据集成：

不同软件工程能相互交换数据，工具使用共享数据模型来操作。

分为三个级别：

共享文件、共享数据结构、共享仓库。

●表示集成：

工具使用相同的用户界面。

分为三个级别：

窗口系统集成、命令集成、交互集成。

●控制集成：

工具激活后能控制其它工具的操作。

●过程集成：

工具在一个过程模型和“过程机”的指导下使用。

即CASE系统嵌入了关于过程活动、阶段、约束和支持这些活动所需的工具的知识。

第二章软件需求和软件需求规约

一、可行性研究

1.可行性研究是用最小的代价在尽可能短的时间内确定该软件项目是否能够开发，是否值得开发，给出“行或不行”的回答。

实质是以较抽象的方式进行一次简化的、压缩了的需求分析、设计过程。

它是系统方案实现的必要性。

2.可行性研究任务：

（1）先进行概要的分析研究，初步确定项目的规模和目标、约束和限制，把它们清楚的列出来。

（2）分析员进行简要的需求分析，抽象出项目逻辑结构，建立逻辑模型。

（3）经压缩设计，探索出若干种可选的解决方法，对每种方法研究其可行性。

3.可行性研究主要考虑开发风险、资源有效性和技术等情况，具体分为：

技术可行性：

指在现有条件下估算开发项目的技术风险。

对项目的功能、性能、限制条件进行分析，要解决技术风险问题，研究硬件等开发资源的有效性。

研究内容为：

成本-效益分析、公司经营长期策略、开发所需成本和资源、潜在的市场前景。

经济可行性：

指进行开发成本的估算及预期取得经济效益的评估。

研究范围是效益分析。

社会可行性：

涉及范围有合同、责任、侵权、用户组织的管理模式、规范及其他一些技术人员常不了解的陷阱。

4.可行性研究步骤：

（1）确定项目规模和目标。

（2）研究正在运行的系统。

（3）建立新系统的高层逻辑模型。

（4）导出和评价各种方案。

（5）推荐可行的方案。

（6）编写可行性研究报告。

5.可行性研究报告的主要内容有：

引言、可行性研究前提、对现有系统的分析、所建议系统的技术可行性分析、所建议系统的经济可行性分析、社会因素可行性分析、其他可供选择的方案、结论意见。

6.项目开发计划是一种管理性文档，内容包括：

项目概述、实施计划、人员组织和分工、交付期限。

7.与“可行性研究报告”、“项目开发计划”文档有关的人员是管理人员和开发人员。

与“程序维护手册”文档有关的人员是管理人员和维护人员。

8.可行性分析中，系统流程图用于描述当前运行系统。

二、效益分析

1.成本-效益分析首先估算开发系统的开发成本，再与可能取得的效益进行比较和权衡。

目的是从经济角度评价开发一个新的软件项目是否可行。

2.效益分为有形效益（用货币的时间价值、投资回收期、纯收入等指标度量）和无形效益（从性质和心理上衡量）。

纯收入：

是软件生存周期内系统的累计经济效益和投资之差。

投资回收期：

是累计的经济效益等于最初的投资费用所需的时间。

货币的时间价值：

通常用利率表示货币的时间价值。

设年利率为i，现存入P元，n年后的价值为F=P*（1+n*i）。

3.一个软件开发成本为5万元，寿命为3年。

未来3年的每年收入预计为22000元、24000元、26620

元。

银行年利率为10%。

试对此项目进行成本效益分析，以决定其经济可行性。

解：

3年后，5万的价值为50000*（1+3*10%）=65000元。

3年软件总获利为22000*（1+2*10%）+24000*（1+1*10%）+26620=79420元>65000元，所以此项

目盈利，经济可行。

4.系统的经济效益是因使用新的系统而增加的收入和使用新的系统可以节省的运行费用之和。

三、需求和需求分析

1.软件需求以一种技术形式，描述了一个产品/系统应具有的功能、性能和其他性质。

如功能要求、环境需求、用户界面要求。

2.需求的性质：

必要的、无歧义的、可测的、可跟踪的、可测量的。

3.需求分为：

功能需求：

规约系统或系统构件必须执行的功能的一类需求，是整个需求的主体。

非功能需求：

指软件产品为满足用户业务需求而必须具有的除功能需求以外的特性，包括性能需求、外部接口需求、设计约束需求和质量属性需求。

4.需求分析是指开发人员要准确理解用户需求，进行细致的调查分析，将用户非形式的需求转化成完整的需求定义，再由需求定义转化到相应的需求规格说明的过程。

可概括成“理解，分解，表达”六字。

5.需求分析是软件开发工作的基础，基本任务是准确定义新系统的目标，为满足用户的需要，回答系统必须做什么的问题。

首要任务是确定软件系统功能，定义需求并建立系统功能模型。

6.需求分析阶段需编写的文档有：

需求规格说明书：

是软件设计、验收的依据，双方对软件要做什么的共同理解，也是需求分析的最终结果。

内容包括对主要数据、功能、用户界面和运行环境、软件性能的描述。

一般伴随可行性分析报告产生。

初步用户使用手册、确认测试计划。

7.需求分析之前要进行必要的可行性分析，研究对象是用户要求，用户和分析设计人员双方确定对问题的功能需求、性能需求、环境需求、用户界面需求。

此阶段建立原型的目的是确定系统的功能和性能需要求。

8.需求分析的难点：

（1）问题的复杂性。

（2）交流障碍。

（3）用户需求易变性。

（4）用户陈述的不一致性和不完备性。

解决途径：

（1）与用户充分交流。

（2）合同约束需求的变更。

（3）选用适当的开发模型。

（4）用户参与需求评审。

（5）需求规格说明由用户确认。

（6）研究需求分析的方法和自动化工具（如CASE技术）。

9.各种需求分析方法都有共同适用的基本原则：

（1）能表达和理解问题的数据域和功能域。

（2）可把一个复杂问题按功能分解并可逐层细化（描述软件主要处理的数据域，并给软件开发提供一种可转化为数据设计、结构设计、过程设计的数据与功能表示）。

（3）建模。

10.需求分析阶段可用的工具有：

数据流图、判定表、数据字典等。

11.需求分析阶段的工作：

对问题的识别和分解、分析和综合：

（1）确定对系统的综合要求。

（2）分析系统的数据要求。

（3）导出系统的逻辑模型。

（4）修正系统开发计划。

导出软件逻辑模型、制定规格说明书、需求分析评审。

12.初始需求发现技术：

自悟、交谈、观察、小组会、提炼。

13.常用的软件需求分析方法有：

结构化分析方法（SA）、功能分解法、信息建模法、面向对象的分析方法（OOA）。

四、需求规约

1.需求规约是一个系统/产品所有需求陈述的正式文档，它表达了一个系统/软件产品的概念模型。

2.需求规约的性质：

（1）重要性和稳定性程度。

（2）可修改的。

（3）完整的。

（4）一致的。

3.需求规约的三种表达风格：

非形式化的需求规约：

以一种自然语言来表达。

半形式化的需求规约：

以半形式化符号体系（包括术语表、标准化的表达格式等）表达。

形式化的需求规约：

以一种基于良构数学概念的符号体系来编制。

4.需求规约和项目需求是两个不同的概念。

需求规约是开发组织和用户之间一份事实上的技术合同书，

关注产品需求，回答“交付给客户的产品/系统是什么”；而项目需求是客户和开发者之间对产品/系

统需求的理解，关注项目工作与管理，回答“开发组要做的是什么”。

5.需求规约的内容包括：

引言、信息描述、功能描述、行为描述、检验标准、参考书目和附录。

6.需求规约的作用：

1）需求规约是软件开发组织和用户之间事实上的技术合同书，是产品功能及其环境的体现。

2）对于项目的其余大多数工作，需求规约是一个管理控制点。

3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。

4）需求规约是创建产品验收测试计划和用户指南的基础。

第三章结构化方法

一、结构化分析方法

1.软件系统/产品的需求工作中的三大挑战：

问题空间的理解、人与人之间的通信、需求的变化性。

2.在软件需求分析和设计工程的对象是数据和程序，按实施原则的处理是先数据后程序。

每一种分析方法必须能够表达和理解问题的数据域（包括数据流、数据内容、数据结构）和功能域（反映数据域的控制信息）。

3.结构化分析方法（SA）是面向数据流进行需求分析的方法。

是一种建模活动，使用简单易读符号，根

据软件内部数据传递、变更的关系，以“分解”和“抽象”为基本原则，以自顶向下逐层分解的分析策略，描绘满足功能要求的软件模型。

4.SA分析步骤：

（1）了解当前系统的工作流程，活得当前系统的物理模型。

（2）抽象出当前系统的逻

辑模型。

（3）建立目标系统的逻辑模型。

（4）做进一步的补充和优化。

5.SA方法优点：

适用于开发数据处理类型软件的需求分析，利用半形式化工具表达需求，简明易懂。

缺点：

（1）是一个静态模型，不反映处理顺序，不能控制模型，不适合描述实时控制系统。

（2）只有和E-R图结合才能较完整描述用户对系统的需求。

（3）只有和形式化方法结合才能精确描述软件需求。

（4）不适合描述人机界面系统的要求。

（5）要借助需求分析工具，提高需求分析质量和效率。

6.SA方法特征：

（1）严格定义需求。

（2）划分开发阶段。

（3）制定规范文档。

（4）分析控制流程是其

主要特征。

7.SA是早期的软件工程方法，主要用于数据处理方面的问题。

二、结构化方法描述工具

1.数据流图（DFD图），以图形方式描绘数据在系统中的流动和处理过程，只反映系统必须完成的逻辑

功能，是一种功能模型。

体现系统“做什么”的功能，通过功能分解可完成对其细化，描述系统的分解。

基本元素有：

数据流：

是数据的流动，具有名字和方向。

加工：

又称数据处理，是数据的变换单位，接受输入的数据内容或数据结构，进行处理并产生输出，必须有名字。

数据存储：

是数据的静态结构，也叫文件，指暂时保存的数据，是数据库文件或任何形式的数据组织，必须用名词或名词短语命名。

数据源：

是数据流的起点，必须有名字；

数据潭：

是数据流的归宿地，不能作为计算机处理的成分，必须有名字，和数据源统称外部实体。

“数据流”表示“加工”表示“数据存储”表示“数据源”和“数据潭”表示

使用这些基本元素应注意的问题：

①数据流起到连接其它实体的作用；在应用中，数据流和数据存储一般需要给出标识，但对流入或流出数据存储的数据流，在语义比较清晰的情况下可省略；②加工之间可以有多个数据流，这些数据流可以没有直接关系，数据流图也不表明他们的先后次序。

2.数据字典（DD）是用来定义数据流图各个成分的具体含义，以准确、无二义性的说明方式为系统的分

析、设计、维护提供有关因素的一致的定义和详细的描述。

建立形式有：

手工建立、利用计算机辅助建立并维护。

它和数据流图共同构成系统的逻辑模型，是需求说明书重要组成部分。

四类基本条目：

数据流、数据项、数据存储、基本加工条目。

数据字典定义数据流或数据存储组成时使用的符号：

=被定义为+与{|}或{}重复

m{}n重复（）可选“”数据元素..连接符

3.加工逻辑是只指对数据流图中的数据处理进行逻辑上的说明，详细描述数据流图中不能再分解的每一个加工，采用三种工具：

结构化语言：

介于自然语言和形式化语言间的一种半形式语言。

非为外层（采用顺序、选择、重复三种基本结构，描述控制结构）和内层。

判定表：

构成如下：

条件类别

条件组合

操作

操作执行

判定树：

是判定表的变形，更直观易懂。

与判定表主要用于描述存在多个条件复杂组合的判断问题。

4.另外还有结构化英语等工具。

三、数据流图的绘制

1.绘图方法有：

自顶向下、分层绘制、初步求精等。

2.步骤：

（1）先画出系统的输入输出，即先画顶层数据流图。

顶层数据流图包括一个加工以表示被开发

的系统。

（2）画系统内部，即画下层数据流图。

将层号从0号开始编号，采用自顶向下、由外向内德原则。

画更下层数据流图时，则分解上层图中的加工，一般沿输入流方向，凡数据流的组成或值发生变化的地方则设置一个加工，一直进行到输出流。

如果加工的内部还有数据流则继续分解，直到每个加工足够简单，不能分解为止。

不能分解的加工叫基本加工。

3.注意问题：

（1）命名：

不能使用缺乏具体含义的名字，加工名应能反映处理的功能。

（2）画数据流而不是控制流：

数据流名称只能是名词或名词短语，整个图中不反映加工的执行顺序。

一般不画物质流。

（3）每个加工至少有一个输入数据流和一个输出数据流，反映出此加工的来源和结果。

（4）编号：

某个加工分解成一张数据流图时，上层图为父图，下层图为子图。

子图和其上的所有加工应编号，子图编号和父图编号相对应。

（5）父图和子图的平衡。

子图的输入输出数据流同父图加工的输入输出数据流必须一致。

（6）当局部数据存储作为某些加工的数据接口或某些加工特定的输入输出时，就把它画下来，有助于实现信息隐蔽性。

（7）提高数据流图的易理解性。

四、数据流图的基本类型

1．数据流图一般分为变换型数据流图和事务型数据流图。

两者的区别在于前者具有明显变换特征的数据

流图，后者适用于具明显事物特征的数据流图。

2.变换型数据流图是一个顺序结构，由输入、变换、输出三部分组成。

工作过程分为：

取得数据、变换

数据、给出数据。

事务型数据流图是将它的输入流分离成许多发散的数据流，形成许多加工路径，并根据输入的值选择

其中一个路径来执行。

3.变换型数据流图设计步骤：

（1）确定DFD的变换中心、逻辑输入和逻辑输出。

（2）设计软件结构的顶层和第一层：

变换结构。

（3）设计中、下层模块。

（4）设计的优化。

4.事务型数据流图设计步骤：

（1）确定DFD的事务中心和加工路径。

（2）设计软件结构的顶层和第一层：

事务结构。

（3）设计中、下层模块、优化等工作，与变换型流程图设计一致。

五、结构化设计和总体设计

1.软件设计是应用各种各样的技术和原理，定义一个系统或部件的框架、组成、接口或其他特征的过程或“该过程的结果”，是将软件需求变换成软件表示的过程。

2.模块在程序中是数据说明、可执行语句等程序对象的集合，或是单独命名和编址的元素，在软件体系结构中，模块是可组合、分解和更换的单元。

基本属性有接口、功能、逻辑（反映内部特性）、状态。

5.软件设计基本原理是：

抽象：

即抽出事物本质的共同特性而暂不考虑细节和其它因素，能确定组成软件的过程实体。

模块化：

解决一个复杂问题时自顶向下逐层把软件系统划分为若干模块的过程。

信息隐藏：

在设计和确定模块时，使一个模块内包含的信息，对于不需要这些信息的其他模块来说，是不能访问的。

定义和实施对模块过程细节和局部数据结构的存取限制。

模块独立性（最主要的原理）：

每个模块指完成系统要求的独立的子功能，且与其他模块的联系最少且接口简单。

4.软件设计基本任务：

软件系统结构设计、数据结构和数据库设计、网络系统设计、软件总体设计文档、评审。

5.结构化设计（SD）又叫面向数据流的设计，是以需求分析阶段产生的数据流图为基础，按一定步骤映射成软件结构。

6.结构化设计分为总体设计和详细设计，它们是全局和局部的关系。

主要任务是在需求分析的基础上，

定义满足需求要的结构，即针对给定的问题，给出该问题的软件解决方案，确定“怎么做”的问题。

7.总体设计阶段的工具：

模块结构图、层次图、HIPO图。

8.总体设计基本步骤：

先将系统DFD图转化成初始的模块结构图，再基于“高内聚低耦合”软件设计原则，通过模块化，将初始的模块结构图转化为最终的、可供详细设计使用的模块结构图（MSD）。

9.根据数据流的特性，将数据流图分为变换型数据流图和事务型数据流图。

变换流指DFD具有明显的输入、变换、输出界面。

事务流指DFD中输入流被分离成许多数据流，形成

许多加工路径，并根据输入值选择其中一条路径来执行。

10.模块结构图是软件系统的模块层次结构，反映整个系统的功能实现，用网状或树状结构的图形表示。

形态特征：

深度（模块的层数）、宽度（一层中最大的模块个数）、扇入（一个模块直接上属模块的个数）、扇出（一个模块直接调用下属模块的个数）。

画图注意事项：

同一名字的模块在结构图中只出现一次；调用关系只能从上到下；模块调用次序一般从左到右。

11.模块的控制域指这个模块本身以及所有直接或间接从属它的模块的集合。

模块的作用域是受该模块内一个判定所影响的所有模块的集合。

当一个模块的作用域不在其控制域内，或把该模块移到上一层次，或把在作用域内但不在控制域内的模块移到控制域内，尽量使模块的作用域是其控制域的子集。

六、耦合性和内聚性

1.耦合性也叫块件关系，根据模块外部特征提出的，是对软件系统结构中各模块间相互联系紧密程度的一种度量