前言：02333软件工程自考，内容方面比较枯燥，理论知识点比较零散，建议结合思维导图*（附录1）进行学习，会更加系统，记忆性更强。考试的话，还是需要多多刷题。 如果文中有错漏的地方，请留言/私信提醒我修改，谢谢。

1.软件工程的概念 软件工程是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的学科。 2.“软件危机”现象 20世纪60年代以来，随着计算机的广泛使用，软件生产率、软件质量远远满足不了社会发展的需求，成为社会、经济发展的制约因素，人们通常把这一现象称为“软件危机”

本质：不同抽象层术语之间映射，以及不同抽象层处理逻辑之间的映射。 1、软件的概念 计算机软件一般是指计算机系统中的程序及其文档。其中，程序是计算机任务的处理对象和处理规则的描述；文档是为了理解程序所需的阐述性资料。 2.模型概念 简单地说，模型就是待建模系统的任意抽象，其中包括所有的基本能力、特性或其他一些方面，而没有任何冗余的细节。 进一步说，模型是在特定意图下所确定的角度和抽象层次上对物理系统的描述，通常包含对该系统的描述、对系统内各模型元素以及它们之间关系的语义描述。 3.求解问题的基本途径 为了求解其中的非结构化和半结构化问题，其基本途径是问题建模，问题建模是指运用所掌握的知识，通过抽象，给出该问题的一个结构。 常用的建模手段包括：结构化方法、面向对象方法以及诸多向数据结构方法等。 4.模型的分类 在软件开发中，软件系统模型大体可分为两类：概念模型和软件模型。概念模型是创建在需求层上的，它描述了系统是什么；软件模型是创建在抽象层上的，它描述了实现概念模型的软件解决方案。软件模型可进一步分为设计模型、实现模型和部署模型。

1.需求定义及其基本特性 一个需求是有关一个“要予构造”的陈述，描述了待开发产品/系统（或项）功能上的能力、性能参数或其他性质。 对于单一一个需求，必须具有五个基本特性： （1）必要的，该需求是用户说要求的； （2）无歧义的，该需求只能用一种方式解释； （3）可测的，该需求是可以进行测试的； （4）可跟踪的，该需求可从一个开发阶段跟踪到另一个阶段； （5）可测量的，该需求是可测量的。 2.功能需求和非功能需求 功能需求规约了系统或系统构件必须执行的功能。 非功能需求：分为性能需求、外部借口需求、设计约束和质量属性需求。 3.需求发现技术 初始发现需求的常用技术，如下所示

1.需求规约定义及其基本特性 需求规约是一个软件项/产品/系统所有需求陈述的正式文档，它表达了一个软件产品/系统的概念模型、 需求规约一般要满足四个基本特性 （1）重要性和稳定性程度：按需求的重要性和稳定性，对需求进行分级，例如：基本需求、可选需求、期望需求 （2）可修改的：在不过多地影响其他需求的前提下，可以容易地修改一个单一需求。 （3）完整的：没有遗漏的需求。 （4）一致的：不存在互斥的需求。 2.需求规约的表达 在实际工程中，需求规约的表达主要存在三种不同的风格。 （1）非形式化的需求规约。 （2）半形式化的需求规约。 （3）形式化的需求规约。 3.需求规约在软件开发中的作用 （1）需求规约是软件开发组织和用户之间一份事实上的技术合同书，是产品功能及其环境的体现。 （2）对于项目的其余大多数工作，需求规约是一个管理控制点。 （3）对于产品/系统的设计，需求规约是一个正式的、受控的起始点。 （4）需求规约是创建产品验收测试计划和用户指南的基础，即基于需求规约一般还会产生另外两个文档——初始测试计划和用户系统操作描述。

1.表达问题域信息的基本术语及其表示 （1）数据流：在结构化分析方法中，数据流是数据的流动，用于表达在分析中所要使用的、用于表达“客体”的信息。 （2）加工：在结构化分析方法中，加工是数据的变换单位，即它接受输入的数据，对其进行处理，并产生输出。 （3）数据存储：数据存储是数据的静态接口。 （4）数据源和数据潭：数据源是数据流的起点，数据潭是数据流的归宿地。数据源和数据潭是系统之外的实体，可以是人、物或其他软件。它们均用一个矩形表示。 2.表达功能模型的工具——DFD图 DFD图，即数据流图，是表达功能模型的工具。它是一种描述数据变换的图形化工具，其中包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。 3.数据字典、判定表和判定树 （1）在数据字典中，为了使定义的结构数据便于理解和阅读，一般按三种条目来组织，即数据流条目、数据存储数目和数据条目。 （2）判定表：判定表是用以描述加工的一种工具，通常用来描述一些不易用自然语言表达清楚或需要很大篇幅才能表示清楚的加工。 （3）判定树：判定树也是一种描述加工的工具，判定表可以用判定树等价表示。 4.结构化分析方法中每一术语在建模中的作用 （1）数据流用于表达在分析中所要使用的、用于表达“客体”的信息。 （2）加工用于表达在分析中所要使用、用于表达“处理”的信息。 （3）数据存储用于表达在分析中所要使用的、用于表达“结构化客体”的信息。 （4）数据源和数据潭为了表示系统的环境，可以使用它们和相关数据流来定义系统的边界。 5.构建系统功能模型的步骤 （1）建立系统环境图，确定系统语境、 （2）自顶向下，逐步求精，建立系统的层次数据流图。 （3）定义数据流。 （4）描述加工。 6.需求验证中发现的错误类型及方法 （1）需求验证中发现的错误类型有不正确的事实、遗漏、不一致、歧义性、错放及其他。 （2）需求验证中发现错误的方法有审查、单元测试、评估、集成和其他。

1.变换型数据流图和事务型数据流图 （1）变换型数据流图：具有较明显的输入部分，和变换部分之间的界面、变换部分和输出部分之间界面的数据流图，称为变换型数据流图。 （2）事务型数据流图：数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列中选出一个来执行，这类数据流图称为事务型数据流图。 2.模块以及模块内聚和耦合 （1）模块。模块是执行一个特殊任务的一个过程你以及相关的数据结构，通常有两个部分组成，一部分是接口，另一部分是模块体。 （2）模块内聚。内聚是指一个模块内部各成分之间相互关联程度的。从低到高常见的内聚类型有：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。 （3）模块耦合。耦合是指不同模块之间相互依赖程度的量。从强到弱常见的耦合类型有：内容耦合、公共耦合、控制耦合、标记耦合、数据耦合。 3.详细设计工具：框图、PAD图、N-S图和伪码 （1）框图。程序流程图又称框图，是软件设计的主要工具，是历史最悠久，使用最广泛的软件设计工人。 （2）PAD图。是问题分析图的缩写。 （3）N-S图。N-S图又称为盒图。 （4）伪码（PDL）。类程序设计语言也成为伪码，它是一种正文形式表示数据结构和处理过程的设计工具。PDL是一种“混合”语言。 4.变换设计和事务设计 （1）变换设计。变换设计是在需求规约的基础上，经过一系列设计步骤，将变换型数据流图转换成系统的模块结构图。基本步骤是： ·设计准备——复审并精化系统模型； ·确定输入、交换、输出这三部分之间的边界； ·第一级分解——系统模块结构图顶层和第一层的设计； ·第二级分解——自顶向下，逐步求精。 （2）事务设计。当数据流图具有明显的事务型特征时，也就是有一个明显的事务处理中心时，则比较适宜采用事务设计。十五设计的基本步骤和变换设计大体相同。 ·设计准备——复审并精化系统模型； ·确定事务处理中； ·第一级分解——系统模块结构图顶层和第一层设计； ·第二级分解——自顶向下，逐步求精。 5.“高内聚低耦合”的启发式规则 （1）改进软件结构，提高模块独立性。 （2）力求模块规模适中。 （3）力求深度、宽度、扇入、扇出适中。 （4）尽力使模块的作用域在其控制域之内。 （5）尽力降低模块接口的复杂度。 （6）力求模块功能可以预测。 6.概要设计规约指明的高层软件体系结构 （1）系统环境，包括硬件/软件接口、人机界面、外部定义的数据库及其与设计有关的限定条件等。 （2）软件模块的结构，包括模块之间的接口及设计的数据库和主要数据结构等。 （3）模块描述，包括模块接口定义、模块处理逻辑及必要的注释等。 （4）文件结构和全局数据文件的逻辑结构，包括记录描述、访问方式以及交叉引用等。 （5）测试需求等。

4.1.1 UML术语表总述 为了支持抽象分析和设计中的事物，UML给出了八个基本本语即类、接口、协作、用况、主动类、构件、制品、节点。每个术语都体现着一定的软件设计原理，例如类体现了数据抽象、过程抽象、局部化以及信息隐蔽等原理；用况体现了问题分离、功能抽象等原理；接口体现了功能抽象等。

4.1.2 类、接口、用况、协作等概念 (1)类：类是一组具有相同属性、操作、关系和语义的对象的描述。类主要用于抽象客观世界中的事物； (2)接口：每个操作描述了类、构件或子系统的一个服务，接口就是操作的一个集合。接口是对系统/产品的 “ 接缝 ” 予以模型化，表明了一个类、构件、子系统所需要得到的、且与实现无关的行为； (3)用况：用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果； (4)协作：协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交内容。

4.1.3 UML的4个术语 为了表达各类事物之间的相互依赖和作用，UML给出了4个术语，即关联、泛化、细化和依赖； (1)关联：关联是对一组有相同结构、相同链的描述，是类目之间的一种结构关系。关联可以用一条连接两个类目的线段表示，并可对其命名，其结构可以具有方向性,用一个实心三角形来指示关联的方向； (2)泛化：泛化是一般性类目和它的较为特殊类目之间的一种关系。子类可以继承父类的属性和操作，同时，也可以替换父类的