自考软件工程笔记总结.docx

自考软件工程笔记总结.docx

《自考软件工程笔记总结.docx》由会员分享，可在线阅读，更多相关《自考软件工程笔记总结.docx（29页珍藏版）》请在冰豆网上搜索。

自考软件工程笔记总结

第一章绪论

1.1软件工程的产生

1.1.1软件的特点

软件的定义：

计算机程序及其说明程序的各种文档

软件的特性：

（1）软件是一种逻辑产品，它与物质产品有很大的区别

（2）软件产品的生产主要是研制，软件产品的成本主要体现在软件的开发和研制上，软件开发研制完成后，通过复制就产生了大量软件产品

（3）软件产品不会用坏，不存在磨损、消耗问题

（4）软件产品的生产主要是脑力劳动，还未完全摆脱手工开发方式，大部分产品是“定做”的

（5）软件费用不断增加，软件成本相当昂贵

1.1.2软件生产的发展

1）程序设计时代（1946年~1956年）

这个阶段的生产方式是个体手工劳动，使用的工具是机器语言、汇编语言。

开发方法是追求编程技巧，追求程序运行效率

程序难读、难懂、难修改

硬件特征是价格贵、存储容量小、运行可靠性差

软件特征是只有程序、程序设计概念，不重视程序设计方法

2）程序系统时代（1956年~1968年）

这个阶段的生产方式是作坊式的小集团合作生产，生产工具是高级语言

开发方式仍旧靠个人技巧，但开始提出结构化方法

硬件特征是速度、容量、工作可靠性有明显提高，价格降低，销售有爆炸性增长

软件特征是程序员数量猛增，大量其他行业人员进入这个行业，因为缺乏训练，因而开发人员素质差

这时已意识到软件开发的重要性，但开发技术没有新的突破，大量软件开发的需求已提出，但开发人员的素质和落后的开发技术不适应规模大、结构复杂的软件开发，产生了尖锐的矛盾，导致了软件危机的产生

3）软件工程时代（1968年至现在）

这阶段的生产方式是工程化的生产，使用数据库、开发工具、开发环境、网络、分布式、面向对象技术来开发软件

硬件特征是向超高速、大容量、微型化以及网络化方向发展

软件特征是开发技术有很大进步，但是未能获得突破性进展，软件价格不断上升，没有完全摆脱软件危机

1.1.3软件危机

1.软件危机的产生

软件发展到第二阶段末期，软件开发技术的进步跟不上硬件发展的速度

2.软件危机的表现

（1）经费预算经常突破，完成时间一再拖延

（2）开发的软件不能满足用户要求

（3）开发的软件可维护性差

（4）开发的软件可靠性差

3.软件危机的原因

（1）软件的规模越来越大，结构越来越复杂

（2）软件开发管理困难而复杂

（3）软件开发费用不断增加

（4）软件开发技术落后

（5）生产方式落后

（6）开发工具落后

1.1.4软件工程

1968年北大西洋公约组织的工作会议上首先提出“软件工程”的概念，要用工程化的思想来开发软件

1.软件工程定义

用科学知识和技术原理来定义、开发、维护软件的一门科学

2.软件工程的性质

软件工程是一门综合性的交叉学科，涉及计算机科学、工程科学、管理科学、数学等领域

计算机科学中的研究成果均可用于软件工程，但计算机科学着重于原理和理论，而软件工程着重于如何建造一个软件系统

软件工程要用工程科学中的观点来进行费用估算、制定进度、制定计划和方案

软件工程要用管理科学的方法和原理进行软件的生产和管理

软禁工程要用数学的方法建立软件开发中各个种模型和各种算法

3.软件工程目标

目的是成功的建造一个大型软件系统

所谓成功，是要达到

付出较低的开发成本

达到要求的软件功能

取得较好的软件性能

开发的软件易于移植

需要较低的维护费用

能按时完成开发任务，及时交付使用

开发的软件可靠性高

4.软件工程内容

主要是软件开发技术和软件管理两个方面

软件开发技术中主要研究软件开发方法、软件开发过程、软件开发工具和环境

软件开发管理中主要研究软件管理学、软件经济学、软件心理学

5.软件工程面临的问题

a）软件费用

b）软件可靠性

c）软件维护

d）软件生产率

e）软件重用

1.2软件工程过程和软件生存周期

1.2.1软件工程过程

目的是为各种人员提供一个公共的框架，以便用相同的语言进行交流

（1）获取过程

（2）供应过程

（3）开发过程

（4）操作过程

（5）维护过程

（6）管理过程

（7）支持过程

1.2.2软件生存周期

指一个软件从提出开发要求开始直到该软件报废为止的整个过程

（1）可行性分析和项目开发计划

必须要回答的问题是“要解决的问题是什么”，有可行的解决办法吗，如果有需要多少费用多少资源时间

明确项目性质

明确项目目标

明确项目规模

确定该问题有没有可行的解决办法

指定项目开发计划

（2）需求分析

确定软件系统必须做什么

确定软件系统必须具备哪些功能

（3）概要设计

把确定的各项功能需求转换成需要的体系结构

设计软件的结构，明确该结构的模块组成

（4）详细设计

为每个模块完成的功能进行具体描述，把功能描述转变为精确地、结构化的过程描述

（5）编码

把每个模块的控制结构转换成计算机可接受的程序代码，即写成以某种特定程序设计语言表示的“原程序清单”

（6）测试

保证软件质量的重要手段

（7）维护

1.3软件生存周期模型、方法和工具

1.3.1软件生存周期模型

描述软件开发过程中各种活动如何执行的模型

1.瀑布模型

将软件生存周期各个活动规定为依线性顺序连接的若干阶段的模型

包括所有的软件生存周期环节，规定了由前至后、相互衔接的固定次序

缺点：

理想的线性开发模式，缺乏灵活性

开发过程中用户看不到软件是什么样子，造成开发方向错误

2.增量模型

一种非整体开发的模型，软件在该模型中是“逐渐”开发出来的，开发一部分展示一部分，可以及早发现问题。

或者开发一个“原型”软件，完成部分主要功能再逐步完善

具有较大的灵活性，适合于软件需求不明确、设计方案有一定风险的软件项目

缺点：

对于复杂的大型软件，开发一个原型往往达不到要求

3.螺旋模型

将瀑布模型与增量模型结合起来，加入了两种模型均忽略了的风险分析

开发过程分为几个螺旋周期，每个螺旋周期大致和瀑布模型相符合

每个周期内分四个工作不：

制定计划、风险分析、开发实施、用户评估

适合于大型软件的开发

缺点：

需要有相当丰富的风险评估经验和专门知识，使得应用受到一定限制

4.喷泉模型

一种以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法

克服了瀑布模型不支持软件重用和多想开发活动集成的局限性

是开发过程具有迭代性和无间隙性

5.基于知识的模型

又称只能模型，它把瀑布模型和专家系统结合在一起

还处于研究实验阶段，还未达到实用阶段

6.变换模型

适合于形式化开发的模型

1.3.2软件开发方法

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

1.结构化方法

由结构化分析，结构化设计、结构化程序设计构成，是一种面向数据流的开发方法。

简单实用，应用较广，技术成熟

2.Jackson方法

面向数据结构的开发方法

3.维也纳开发方法（VDM）

一种形式化的开发方法，软件需求用严格的形式语言描述，然后把描述模型逐步变换成目标系统

4.面向对象的开发方法

90年代主流

基本出发点是尽可能按照人类认识世界的方法和思维方式来分析和解决问题

包括面向对象分析、面向对象设计、面向对象实现

1997年推出统一建模语言UML，是面向对象的标准建模语言

1.3.3软件开发工具

1．软件工具的重要性

为了支持软件人员开发和维护活动而使用的软件

项目估算工具、需求分析工具、编码工具、测试工具、维护工具等

2．工具箱

将各种软件工具简单组合起来就构成工具箱

工具箱的工具界面不同意，工具内部无联系，工具切换由人工操作

3．软件开发环境

工具系统的整体化及集成化，使之形成完整的软件开发环境

使软件工具支持整个生存周期

4．计算机辅助软件工程

新的软件工具目的是实现软件生存周期各个环节的自动化，主要用于软件的分析和设计，使用这些工具开发人员可以以对话的方式建立各种软件系统

计算机辅助软件工程可以简单的定义为软件开发的自动化，CASE

结构化方法可以用于瀑布模型、增量模型、螺旋模型进行开发

Jackson方法可以用于瀑布模型、增量模型

维也纳方法只能用于变换模型进行开发

第二章软件可行性研究与项目开发计划

2.1可行性研究

目的是用最小的代价在尽可能短的时间内去确定该项目是否能够开发，是否值得开发

在较高层次上以较抽象的方式进行需求分析和设计过程

2.1.1可行性研究的任务

进行概要的分析研究，初步确定项目的规模和目标，确定项目的约束和限制，列举出来。

然后进行简要的需求分析，抽象出项目的逻辑结构，建立逻辑模型，从逻辑模型出发经过压缩的设计，探索出若干种可供选择的解决办法，对每种解决方法都要研究它的可行性

可以从以下三个方面分析研究每种解决方法的可行性

1.技术可行性、

技术可行性一般要考虑的情况包括

（1）开发的风险

（2）资源的有效性

（3）技术

（4）开发人员在评估技术可行性时，一旦估计错误，将会出现灾难性后果

2.经济可行性

进行开发成本的估算以及了解取得效益的评估，确定要开发的项目是否值得投资开发

3.社会可行性

要开发的项目时候存在任何侵犯、妨碍等责任问题，要开发项目的运行方式在用户组织内是否行得通，现有管理制度、人员素质、操作方式是否可行

2.1.2可行性研究的具体步骤

1.确定项目规模和目标

2.研究正在运行的系统

3.建立新系统的高层逻辑模型

使用建立逻辑模型的工具——数据流图和数据字典描述数据在系统中的流动和处理情况。

不是需求分析阶段，不是完整详细的描述，只是概括的描述高层的数据处理和流动

4.导出和评价各种方案

5.推荐可行的方案

6.编写可行性研究报告

2.1.3可行性研究报告的主要内容

1．引言

2．可行性研究前提

3．对象有系统的分析

4．所建议系统的技术可行性分析

5．所建议系统的经济可行性分析

6．社会因素可行性分析

7．其他可供选择方案

8．结论意见

2.2系统流程图

1．系统流程图的作用

用图形符号来表示系统中的各个元素。

表达了系统中各个元素之间的心理流动的情况

2．系统流程图的符号

3．系统流程图的例子

2.3成本——效益分析

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

估算将要开发的系统的开发成本，与可能取得的效益进行比较和权衡

效益分有形效益和无形效益

有形效益的分析

1．货币的时间价值

2．投资回收期

3．纯收入

2.4项目开发计划

1．项目概述

2．实施计划

3．人员组织及分工

4．交付期限

第三章软件需求分析

3.1需求分析的任务

3.1.1需求分析的概念

开发人员要准确的理解用户的要求，进行细致的调查分析，将用户非形式的需求陈述转化为完整的需求定义，再由需求定义装换到相应的形式功能规约（需求规格说明）的过程

需求分析的难点：

（1）问题的复杂性

（2）交流障碍

（3）不完备性和不一致性

（4）需求易变性

软件需求分析与说明的方法适用的基本原则：

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

（2）可以把一个复杂问题按功能进行分解并可逐层细化

（3）建模

结构化分析方法和面向对象分析方法都遵循以上原则

3.1.2需求分析的基本任务

要准确的定义新系统的目标，为了满足用户的需要，回答系统必须“做什么”的问题。

可行性研究和软件计划阶段对这个问题的回答是概括的、粗略的

本阶段主要进行以下几个方面的工作：

1.问题识别

双方确定对问题的综合需求，这些需求包括：

（1）功能需求：

所开发的系统必须具备什么样的功能，这是最重要的

（2）性能需求：

待开发的软件的技术性能指标。

存储容量，运行时间

（3）环境需求：

软件运行时所需要的软、硬件的要求

（4）用户界面需求：

人机交互方式、输入输出数据格式等等

另外还有可靠性、安全性、保密性、可移植性、可维护性等方面的需求

2.分析与综合，导出软件的逻辑模型

对获取的需求，进行分析检查，逐步细化软件的功能，划分成各个子功能，以确定系统的构成及主要成分，建立新系统的逻辑模型

3.编写文档

（1）编写“需求规格说明书”

（2）编写初步用户使用手册

（3）编写确认测试计划

（4）修改完善软件开发计划

3.1.3需求规格说明书主要内容

3.2结构化分析方法

简称SA，是面向数据流进行需求分析的方法

3.2.1自顶向下逐层分解的分析策略

对一个复杂问题分析人员不可能一开始就考虑到问题的所有方面及全部细节，对此采取的策略是分解，把一个复杂问题划分成若干小问题，然后分别解决，将问题的复杂性降低到人可以掌握的程度

分解可分层进行，先考虑问题最本质的方面，忽略细节形成问题的高层概念，然后逐层添加细节。

顶层抽象的概括整个系统，底层具体画出系统的每个细节，中间层是逐步过渡

这种层次分解使分析人员分析问题时不至于一下子陷入细节，而是逐步的去了解更多细节

依照这个策略，对于任何复杂的系统，分析工作都可以有计划、有步骤、有条不紊的进行

3.2.2描述工具

SA方法的描述工具是：

（1）数据流图

（2）数据字典

（3）描述加工逻辑的结构化语言、判定表、判定树

数据流图描述系统的分解，及系统由哪几部分组成，各部分之间的联系等等

数据字典定义了数据流图中每一个图形元素

结构化语言、判定便或判定树详细描述数据流图中不能被再分解的每一个加工

3.2.3SA分析步骤

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

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

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

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

3.3数据流图（DFD）

简称DFD，是SA方法中表示系统逻辑模型的一种工具，只反应系统必须完成的逻辑功能，所以是一种功能模型

3.3.1基本图形符号

数据流图有四种基本图形符号：

（1）数据流。

是数据在系统内传播的路径，由一组成分固定的数据项组成，必须有流向，除了与数据存储之间的数据流不用命名，其他用名词或名词短语命名

（2）加工（又称为数据处理）。

对数据流进行某些操作或变换。

加工用动词短语命名

（3）数据存储（又称为文件）。

指暂时保存的数据，它可以是数据库文件或任何形式的数据组织。

流向数据存储的数据流可以理解为写入文件或查询文件，流出的数据可以理解为从文件读取数据或得到查询结果

（4）数据源点或终点：

软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称为外部实体

在一张图上可重复画同名的源/终点，在方框的右下角加斜线则表示是一个实体。

有时数据存储也需重复标识

3.3.2画数据流图的步骤

按问题的层次结构进行逐步分解，并以一套分层的数据流图反应这种结构关系

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

顶层流图只包含一个加工，用以表示被开发的系统，然后考虑系统的输入输出数据。

顶层图的作用在于表明被开发的系统范围以及它与周围化境的数据交换关系

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

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

一般沿着输入流的方向，凡数据流的组成或值发生变化的地方则设置一个加工，这样一直进行到输出数据流。

知道每一个加工足够简单，不能再分解为止，不能再分解的加工称为基本加工

（3）注意事项

a）命名

b）画数据流而不是控制流

图中不反应加工的执行顺序

c）一般不画物质流

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

e）编号

子图的编号就是父图中相应加工的编号，加工的编号由子图号，小数点和局部号组成

f）父图与子图的平衡

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

保证了数据流图的一致性

g）局部数据存储

h）提高数据流图的易理解性

注意合理分解

为了使数据流图便于在计算机上输入与输出，以下给出了描述数据流图的另一套基本符号

3.3.3实例——售票管理系统

3.4数据字典（DD）

简称DD，用来定义数据流图中各个成分的具体含义，它以一种准确的、无二义性的说明方式为系统的分析、设计及维护提供了有关元素的一致的定义和详细的描述

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

3.4.1数据字典的内容及格式

数据字典是为分析人员查找数据流图中有关名字的详细定义而服务的，因此也像普通字典一样，要把所有条目按一定的次序排列起来，以便查阅

数据字典有以下四类条目：

数据流

数据项

数据存数

基本加工

数据项是组成数据流和数据存储的最小元素。

源点终点一般不在字典中说明

1.数据流条目

数据流条目给出了DFD中数据流的定义，通常列出数据流的各组成数据项

在定义数据流或数据存储组成时，使用下表给出的符号：

2.数据存储条目

数据存储条目是对数据存储的定义，主要内容举例如下：

3.数据项条目

数据项条目是不可再分解的数据单位，其定义格式及举例如下：

4.加工条目

加工条目是用来说明DFD中基本加工的处理逻辑的，由于上层的加工是由下层的基本加工分解而来，只要有了基本加工的说明，就可理解其他加工

加工条目的内容及举例如下：

数据字典中的加工逻辑主要描述该加工“做什么”，即实现加工的策略，而不是实现加工的细节，它描述如何把输入数据流变换为输出数据流的加工规则。

加工逻辑有几种常用的描述方法，结构化语言、判定表、判定树

3.4.2数据字典的实现

建立数据字典一般有两种形式：

1.手工建立：

数据字典的内容用卡片形式存放

（1）按四类条目规范的格式印制卡片

（2）在卡片上分别填写各类条目的内容

（3）先按图号顺序排列，同一图号的所有条目按数据流、数据项、数据存储和数据加工的顺序排列

（4）同一图号中的同一类条目（如数据流卡片）可按名字的字典顺序存放，加工一般按编号顺序存放

（5）统一成分在父图和子图都出现时，则只在父图上定义

（6）建立索引目录

2.利用计算机辅助建立并维护

（1）编制一个“字典生成与管理程序”，可以按规定的格式输入各类条目，能对字典条目增、删、改，能打印查询报告和清单，能进行完整性一致性检查。

美国密执安大学研究的PSL/PSA就是这样一个系统

（2）利用已有的数据库开发工具，针对数据字典建立一个数据库文件，可将数据流、数据项、数据存储和加工分别以矩阵表的形式来描述各个表项的内容，如数据流的矩阵表为：

有的DBMS本身包含一个数据字典子系统，建库时能自动生成数据字典

计算机辅助开发数据字典比手工建立数据字典有更多的优点，能保证数据的一致性和完整性，使用也方便，但增加了技术难度与积极开销

3.5加工逻辑的描述

加工逻辑也称为“小说明”，描述加工逻辑一般用一下三种工具：

结构化语言

判定表

判定树

3.5.1结构化语言

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

结构可分为外层和内层两层：

1.外层：

用来描述控制结构，采用顺序、选择、重复三种基本结构

（1）顺序结构：

是一组祈使语句、选择语句、重复语句的顺序排列

（2）选择结构：

一般用IF——THEN——ELSE——ENDIF、

CASE——OF——ENDCASE等关键词

（3）重复结构：

一般用DO——WHILE——ENDDO、REPEAT——UNTIL等关键字

2.内层：

一般是采用祈使语句的自然语言短语，使用数据字典中的名词和有限的自定义词，其动词含义要具体，尽量不用形容词和副词来修饰。

还可使用一些简单的算术运算和逻辑运算符号

3.5.2判定表

在有些情况下，数据流图中的某个加工的一组动作依赖于多个逻辑条件的取值。

这时用判定表就能够清楚地表示复杂的条件组合与应作的动作之间的对应关系

判定表由四部分组成，用双线分隔开四个区域：

构造一张判定表，可采取以下步骤：

1.提取问题中的条件

2.标出条件的取值

3.计算所有条件的组合数N

4.提取可能采取的动作或措施

5.制作判定表

6.完善判定表

初始的判定表可能不完善，表现在以下几个方面：

（1）缺少判定列中应采取的动作

（2）有冗余的判定列：

两个或多个规则中，具有相同的动作，而与它所对应的各个条件组合中有取值无关的条件

判定表能够把在什么条件下系统应做什么动作准确无误的表示出来，但不能描述循环的处理特性，循环处理还需结构化语言

例子：

3.5.3判定树

判定树是判定表的变形，一般情况下它比判定表更直观，更易于理解和使用

这三种描述加工逻辑的工具各有优缺点

对于顺序执行和循环执行的动作，用结构化语言描述

对于存在多个条件复杂组合的判断问题，用判定表和判定树

判定树较判定表直观易读，判定表进行逻辑验证较严格，能把所有的可能性全部都考虑到，可将两种工具结合起来，先用判定表做底稿，在此基础上产生判定树

经过需求分析，开发人员已经基本上理解了用户的要求，确定了目标系统的功能，定义了系统的数据，描述了处理这些数据的基本策略。

将这些共同的理解进行整理，最后形成文档——需求说明书

3.6IDEF方法

IDEF方法是美国空军在1981年针对集成化计算机辅助制造工程项目中用于进行复杂系统分析和设计的方法。

IDEF方法分为三部分：

IDEF0：

用来描述系统的功能活动及其联系，建立系统的功能模型

IDEF1：

用来描述系统的信息及其联系，建立系统的信息模型

IDEF2：

用来进行系统模拟，建立系统的动态模型

3.6.1IDEF0的图形表示

该方法中，将系统功能称为活动，将表示系统功能的图形称为活动图形

一个活动可以没有输入，但一定要有控制

3.6.2建立功能模型的基本方法

1.确定建模的范围、观点及目的

2.建立系统的内外关系图——A-0图

3.建立顶层图——A0图

4.建立低层次的图形

分解时，应遵循两条原则：

首先，保持在同一水平上分解（宽度优先），如A1，A2，A3等图，而不是A1，A11，A111（深度优先），可避免较高层次的变化影响较低层次，造成可能的重复工作，同时可较早的查出错误及遗漏

其次，对于同一水平层次上的各个方框，选择难度最大的部分往下分解，其后分解较容易的部分

在IDEF0图中几个活动之间无明确的顺序和时间，要注意分解时箭头表示的上下层之间的平衡关系。

3.6.3IDEF0方法的特点

1.采用方框和箭头等简单的图形符号描述系统的活动和数据流，描述活动所受到的约束条件及实现机制

IDEF0图宜作为正式文档

2.采用严格的自顶向下、逐层分解的方式建立系统功能模型

因此，IDEF0是建立系统功能模型的有效方法。

在开发CIMS——计算机集成制造系统的管理信息系统（MIS）过程中，大都采用此方法建立软件需求分析的功能模型

3.7结构化分析方法小结

结构化分析方法是软件需求分析中公认的、有成效的、技术