软件工程同等学历复习笔记Word文件下载.docx
《软件工程同等学历复习笔记Word文件下载.docx》由会员分享，可在线阅读，更多相关《软件工程同等学历复习笔记Word文件下载.docx（29页珍藏版）》请在冰点文库上搜索。
（7）工程文化：
包括工程价值、工程思想和工程行为三个方面的内容。
第二章：
软件工程过程模型
1．软件生命周期
如同任何事物都有一个发生、发展、成熟直至衰亡的全过程一样，软件系统或软件产品也有一个定义、开发、运行维护直至被淘汰这样的全过程，我们把软件将要经历的这个全过程称为软件的生命周期。
它包含：
软件定义、软件开发、软件运行维护三个时期，并可以细分为可行性研究、项目计划、需求分析、概要设计、详细设计、编码实现与单元测试、系统集成测试、系统确认验证、系统运行与维护等几个阶段。
2．瀑布模型
瀑布模型诞生于20世纪70年代，是最经典的并获得最广泛应用的软件过程模型。
瀑布模型中的“瀑布”是对这个模型的形象表达，即山顶倾泻下来的水，自顶向下、逐层细化。
（1）特点：
线性化模型、阶段具有里程碑特征、基于文档的驱动、阶段评审机制。
（2）作用：
为软件项目按规程管理提供了便利，为其他过程模型的推出提供了一个良好的拓展平台。
（3）局限性：
主要适合于需求明确且无大的需求变更的软件开发，但不适合分析初期需求模糊的项目。
3．原型模型
（1）快速原型方法：
是原型模型在软件分析、设计阶段的应用，用来解决用户对软件系统在需求上的模糊认识，或用来试探某种设计是否能够获得预期结果。
（2）原型进化模型：
针对有待开发的软件系统，先开发一个原型给用户使用，然后根据用户的使用意见，对原型不断修改，使它逐步接近，并最终到达开发目标。
4．增量模型
增量模型结合了瀑布模型与原型进化模型的优点。
在整体上按照瀑布模型的流程实施开发，以方便对项目的管理。
但在软件的实际创建中，则将软件系统按功能分解为许多增量构件，逐个地创建与交付，直到全部构件创建完毕，并都被集成到系统之中交付使用。
比较瀑布模型、原型进化模型，增量模型具有非常显著的优越性。
但增量模型对软件设计有更高的技术要求。
5．螺旋模型
螺旋模型是一种引入了风险分析与规避机制的过程模型，是瀑布模型、快速原型方法和风险分析方法的有机结合。
其基本方法是，在各个阶段创建原型进行项目试验，以降低各个阶段可能遇到的项目风险。
6．喷泉模型
喷泉模型是专门针对面向对象软件开发方法而提出的。
“喷泉”一词用于形象地表达面向对象软件开发过程中的迭代和无缝过渡。
7．组件复用模型
组件复用方法是最近几年发展起来的先进的软件复用技术，在基于组件复用的软件开发中，软件由组件装配而成，这就如同用标准零件装配汽车一样。
因此，组件复用模型能够有效地提高软件生产率。
第三章：
项目分析和规划
1.计算机系统分析
（1）计算机系统
计算机系统是一个非常复杂并具有智能特性的开发系统，包括：
硬件系统、软件系统、网络通信系统、人工操作系统等诸多子系统。
（2）系统分析
系统分析是对软件项目的高层分析，需要获取的是有关系统的框架描述，并需要使系统从它所处的环境中分离出来，为划分系统边界与确定系统构架提供依据。
（3）系统分析模型
分析模型是指采用作图方式对系统进行直观的描述。
系统前期分析过程中经常使用的图形模型有系统框架图和系统流程图。
其中，系统框架图用于说明系统的基本构造框架，而系统流程图则用于表现系统的基本加工流程。
2.项目可行性分析
（1）意义
•以少量的费用对项目能否实施尽早作出决断。
•根据项目条件限制，对系统的体系构造、工作模式等作出高层抉择。
•其结果可作为一个高层框架被用于需求分析之中。
（2）分析内容
•技术可行性：
从技术与技术资源这两个方面作出可行性评估。
•经济可行性：
从项目投资和经济效益这两个方面作出可行性评估。
•应用可行性：
从法律法规、用户操作规程等方面作出可行性评估。
（3）分析过程
•建立系统模型。
•进行可行性评估。
•撰写可行性研究报告。
3.项目成本效益分析
（1）项目成本估算方法：
基于软件规模的成本估算；
基于任务分解的成本估算。
（2）项目效益分析指标：
纯收入；
投资回收期；
投资回收率。
4.项目规划
（1）项目开发计划
项目开发计划涉及的内容包括：
•开发团队的组织结构，人员组成与分工。
•项目成本预算。
•项目对硬件、软件的资源需求。
•项目任务分解和每项的任务里程碑标志。
•基于里程碑的进度计划和人员配备计划。
•项目风险计划。
•项目监督计划。
（2）项目进度表
项目进度是基于里程碑制定的，可以使用进度图表来描述项目进度。
甘特图表是一种常用的项目进度图表，可以直观地描述项目任务的活动分解，以及活动之间的依赖关系、资源配置情况、各项活动的进展情况等。
第四章软件需求分析
1.需求分析任务
（1）用户需求
用户需求是用户关于软件的一系列意图、想法的集中体现，是用户关于软件的外界特征的规格表述。
（2）系统需求
系统需求是比用户需求更具有技术特性的需求陈述，是提供给开发者或用户方技术人员阅读的，并将作为软件开发人员设计系统的起点与基本依据。
主要包括：
功能、数据、性能、安全等诸多方面的需求问题。
2.需求分析过程
需求分析是对软件系统的后期分析，需要进行的活动包括：
分析用户需求、建立需求原型、分析系统需求和进行需求验证等。
3.用户需求获取
（1）用户调查是最基本的用户需求信息收集方法，比较常用的调查方法包括：
访谈用户、开座谈会、问卷调查、跟班作业、收集用户资料。
（2）需求原型可被用来解决用户对软件系统在需求认识上的不确定性。
一般情况下，开发人员将软件系统中最能够被用户直接感受的那一部分东西构造成为原型。
例如，界面、报表或数据查询结果。
4.结构化分析建模
所谓模型，就是对问题所做的一种符号抽象。
可以把模型看作为一种思维工具，利用这种工具可以把问题规范地表示出来。
主要的分析模型包括：
（1）功能层次模型。
它使用矩形来表示系统中的子系统或功能模块，使用树形连线结构来表达系统所具有的功能层级关系。
（2）数据流模型。
用于描述系统对数据的加工过程，其图形符号是一些具有抽象意义的逻辑符号，主要的图形符号包括：
数据接口、数据流、数据存储和数据处理。
可以依靠数据流图来实现从用户需求到系统需求的过渡。
结构化分析就是基于数据流的细化实现的，它是结构化分析方法的关键。
数据流图（DataFlowDiagram）：
简称DFD，它从数据传递和加工角度，以图形方式来表达系统的逻辑功能、数据在系统内部的逻辑流向和逻辑变换过程，是结构化系统分析方法的主要表达工具及用于表示软件模型的一种图示方法。
数据流图（DFD）中有以下几种主要元素：
→（箭头）：
数据流。
数据流是数据在系统内传播的路径，因此由一组成分固定的数据组成。
如订票单由旅客姓名、年龄、单位、身份证号、日期、目的地等数据项组成。
由于数据流是流动中的数据，所以必须有流向，除了与数据存储之间的数据流不用命名外，数据流应该用名词或名词短语命名。
□（矩形）：
数据源（或数据潭）。
代表系统之外的实体，可以是人、物或其他软件系统。
○（圆圈）：
对数据的加工（处理）。
加工是对数据进行处理的单元，它接收一定的数据输入，对其进行处理，并产生输出。
〓（两条平行线）：
数据存储。
表示信息的静态存储，可以代表文件、文件的一部分、数据库的元素等。
层数据流图。
（3）数据关系模型。
也称为ER图，是应用最广泛的数据库建模工具。
需要通过数据实体、数据关系和数据属性这三类图形元素建立数据关系模型。
（4）系统状态模型。
通过系统的外部事件、内部状态为基本元素来描绘系统的工作流程，这种建模方式比较适合于描述一些依赖于外部事件驱动的实时系统。
5.需求有效性验证
需求有效性验证是指对已经产生的需求结论所要进行的检查与评价。
一般需要对需求文档草稿从有效性、一致性、完整性、现实性等几个方面进行有效性验证。
比较常用的需求有效性验证方法与工具包括：
需求评审、需求原型评价和基于CASE工具的需求一致性分析。
6.需求规格定义
需求规格说明书是需求分析阶段需要交付的基本文档，将成为开发者进行软件设计和用户进行软件验证的基本依据，涉及引言、术语定义、用户需求、系统体系结构、系统需求等有关软件需求及其规格的诸多描述与定义。
第五章软件概要设计
1．设计过程与任务
概要设计中首先需要进行的是系统构架设计，然后是软件结构、数据结构等方面的设计。
主要有以下几个方面的设计任务：
制定规范、系统构架设计、软件结构设计、公共数据结构设计、安全性设计、故障处理设计、可维护性设计、编写文档、设计评审。
2．系统构架设计
（1）集中式结构
集中式系统由一台计算机主机和多个终端设备组成。
其具有非常好的工作稳定性和安全保密性。
但系统建设费用、运行费用比较高，灵活性不够好，结构不便于扩充。
（2）客户机/服务器结构
客户机/服务器结构依靠网络将计算任务分布到许多台不同的计算机上，但通过其中的服务器计算机提供集中式服务。
其优越性是结构灵活、便于系统逐步扩充。
（3）多层客户机/服务器结构
两层结构：
将信息表示与应用逻辑处理都放在了客户机上，服务器只需要管理数据库事务。
三层结构：
将两层结构的客户机上的容易发生变化的应用逻辑部分提取出来，并放到一个专门的“应用服务器”上。
B/S结构：
是Web技术与客户机/服务器结构的结合。
其优点是不需要对客户机进行专门的维护。
（4）组件对象
分布式结构通过组件进行计算分布。
它依赖于对象中间件建立，具有灵活的构架，系统伸缩性好，能够给系统的功能调整与扩充带来便利。
3．软件结构设计
软件结构设计是对组成系统的各个子系统的进一步分解与规划。
主要设计内容有：
确定模块元素、定义模块功能、定义模块接口、确定模块调用与返回、进行结构优化。
（1）模块概念
模块化：
使用构造程序，可使软件问题简化。
抽象化：
概要设计中的模块被看成是一个抽象化的功能黑盒子。
信息隐蔽：
每个模块的内部实现细节对于其他模块来说是隐蔽的。
（2）模块的独立性
软件系统中每个模块都只涉及自己特定的子功能，并且接口简单，与软件中其他模块没有过多的联系。
一般采用耦合和内聚这两个定性的技术指标进行度量。
耦合用来反映模块相互关联程度，模块间连接越紧密，耦合性就越高。
内聚用来反映模块内元素的结合程度，模块内元素结合越紧密，则内聚性就越高。
为提高模块独立性，要求模块高内聚、低耦合。
耦合形式由低至高是：
非直接耦合、数据耦合、控制耦合、公共耦合、内容耦合。
（1）非直接耦合
如果两个模块之间没有直接关系，它们之间的联系仅限于受到共同主模块的控制与调用，则称这种耦合为非直接耦合。
由于非直接耦合的模块之间没有数据通信，因此模块的独立性最强。
（2）数据耦合
当一个模块访问另一个模块时，如果彼此之间是通过模块接口处的参数实现通信，并且参数所传递的数据仅用于计算，而不会影响传入参数模块的内部程序执行路径，则称这种耦合为数据耦合。
数据耦合是一种松散的耦合。
依靠这种类型的耦合，模块之间既能实现通信，又有比较强的独立性。
因此，软件结构设计中提倡使用这类耦合。
（3）控制耦合
当一个模块访问另一个模块时，如果彼此之间是通过模块接口处的参数实现通信，并且参数传递了开关、标志、名字等控制信息，由此影响了传入参数模块的内部程序执行路径，则称这种耦合为控制耦合。
由于接口参数影响着内部程序执行路径，因此控制耦合比数据耦合要强一些，会使模块的独立性有所下降。
当需要通过一个单一的接口传递模块内多项功能的选择信息时，往往需要用到控制耦合。
显然，在控制耦合形式下，对所控制模块的修改，需要受到控制参数的限制。
（4）公共耦合
公共耦合是一种通过访问公共数据环境而实现通信的模块耦合形式，例如，独立于模块而存在的数据文件、数据表集、公共变量等，都可以看作为公共数据环境。
公共耦合中的公共数据环境是提供给任何模块的，当模块之间的耦合是公共耦合时，那些原本可以依靠接口提供的对数据的限制也就没有了。
因此，相比依靠接口的耦合形式，公共耦合必然会使模块的独立性下降。
也正因为如此，实际应用中，只有在模块之间需要共享数据，并且通过接口参数传递不方便时，才使用公共耦合。
需要注意的是：
模块之间公共耦合的复杂程度，将会随着耦合模块个数的增加而显著增加。
为了降低公共耦合带来的复杂性和提高模块的独立性，实际应用中还会针对公共耦合专门设置一些限制，例如不使用公共耦合数据传递控制信息。
（5）内容耦合
如果发生下列情形，两个模块之间就发生了内容耦合。
一个模块直接访问另一个模块的内部数据。
一个模块不通过正常入口转到另一模块内部。
两个模块有一部分程序代码重叠。
一个模块有多个入口。
内容耦合是一种非常强的耦合形式，严重影响了模块独立性。
当模块之间存在内容耦合时，模块的任何改动都将变得非常困难，一旦程序有错则很难修正。
因此，设计软件结构时，也就要求绝对不要出现内容耦合。
所幸的是，大多数高级程序设计语言已经设计成不允许出现内容耦合，它一般只会出现在汇编语言程序中。
内聚形式由低至高是：
偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。
（1）偶然内聚
当模块内各部分之间没有联系，或即使有联系，这种联系也很松散时，将会出现偶然内聚。
偶然内聚模块由于是随意拼凑而成，模块内聚程度最低、功能模糊，很难进行维护。
（2）逻辑内聚
逻辑内聚是把几种相关的功能组合在一起形成为一个模块。
在调用逻辑内聚模块时，可以由传送给模块的判定参数来确定该模块应执行哪一种功能。
逻辑内聚模块比偶然内聚模块的内聚程度要高，因为它表明了各部分之间在功能上的相关关系。
但是它每次执行的不是一种功能，而是若干功能中的一种，因此它不易修改。
另外，在调用逻辑内聚模块时，需要进行控制参数的传递，由此增加了模块间的耦合。
（3）时间内聚
时间内聚模块一般是多功能模块，其特点是模块中的各项功能的执行与时间有关，通常要求所有功能必须在同一时间段内执行。
例如初始化模块，其功能可能包括给变量赋初值、连接数据源、打开数据表、打开文件等，这些操作要求在程序开始执行的最初一段时间内全部完成。
时间内聚模块比逻辑内聚模块的内聚程度又稍高一些，其内部逻辑比较简单，一般不需要进行判定转移。
（4）过程内聚
如果一个模块内的处理是相关的，而且必须以特定次序执行，则称之为过程内聚模块。
在使用流程图设计程序的时侯，常常通过流程图来确定模块划分，由此得到的就往往是过程内聚模块。
例如，可以根据流程图中的循环部分、判定部分和计算部分将程序分成三个模块，这三个模块就是过程内聚模块。
过程内聚模块的内聚程度比时间内聚模块的内聚程度更强一些，但过程内聚模块仅包括完整功能的一部分，因此模块之间的耦合程度比较高。
（5）通信内聚
如果一个模块内各功能部分都使用了相同的输入数据或产生了相同的输出数据，则称之为通信内聚模块。
例如图5-18中的处理工资模块。
通信内聚模块由一些独立的功能组成，因此其内聚程度比过程内聚程度要高。
（6）顺序内聚
如果一个模块内的诸多功能元素都和某一个功能元素密切相关，而且这些功能元素必须顺序安排（前一项功能的数据输出作为后一项功能的数据输入），则称之为顺序内聚模块。
当根据数据流图划分模块时，由此得到的通常就是顺序内聚模块。
顺序内聚模块也包含着多项功能，但它有一个核心功能，其他功能则围绕着这个核心而安排。
因此，顺序内聚程度比通信内聚程度更高。
（7）功能内聚
如果一个模块中各个部分都是完成某一具体功能必不可少的组成部分，各个部分协同工作、紧密联系、不可分割，则称该模块为功能内聚模块。
功能内聚模块的特征是功能单一、接口简单，因此其容易实现、便于维护。
与其他内聚类型相比，功能内聚具有最高的内聚程度，软件结构设计时应以其作为追求目标。
4．面向数据流的结构设计
（1）变换分析
软件结构由输入、变换和输出三个部分组成。
（2）事务分析
软件结构由接收事务与事务活动两个部分组成。
（3）混合流分析与设计
软件系统是变换流与事务流的混合。
对于这样的系统，通常采用变换分析为主、事务分析为辅的方式进行软件结构设计。
5.数据库结构设计
（1）逻辑结构设计
设计数据表
规范数据表
关联数据表
设计数据视图
（2）物理结构设计
数据存储结构
数据索引与聚集
数据完整性
第六章面向对象分析与设计
1．面向对象方法学
面向对象技术涉及面向对象分析（OOA）、面向对象设计（OOD）和面向对象编程实现（OOP）这三个方面的问题。
（1）基本概念
类：
面向对象模块单位，作用是为创建对象实例提供模板。
其具有数据与行为这两个方面的特征，并需要通过属性、操作和方法进行描述。
属性、操作与方法：
类具有数据与行为这两个方面的特征，并需要通过属性、操作和方法进行描述。
类的继承性：
指上级父类能够把自己的属性、操作传递给下级子类。
类的多态性：
子类对象可以像父类对象那样使用，它们可以共享一个操作名，然而却有不同的实现方法。
对象：
对象是类模块实例化的结果。
消息：
指对象之间的通信。
（2）优越性
跟现实世界更加接近
可使软件系统结构更加稳定
软件具有更好的可重用性
软件更加便于维护与扩充
2．面向对象分析建模
面向对象分析建模需要建立的是软件系统的用户领域模型，需要从系统业务流程、组织结构和行为过程等几个方面对系统进行分析。
（1）用例图
用例图涉及参入者、用例等元素，用于描述用户与系统之间的交互关系，说明系统所具有的业务能力和业务流程，能够方便开发者理解用户领域的专有术语和业务内容。
例如：
（2）活动图
活动图是一种行为模型，主要用于描述用例图中用例的内部活动状态与活动转换过程，以获得对用例的交互行为与工作流程的细节说明。
涉及活动状态、活动转换等元素。
（3）分析类图
建立类图的概念模型，描述体现现实世界中数据构造的实体类及其它们之间的关系。
类与类之间的关系主要有：
关联、泛化和聚集
（3.1）关联关系
在用户需求陈述中，类之间的关联往往表现为两个类之间存在某种语义上的联系。
例如下面的陈述：
若顾客通过互联网购买商品，需要先提供购物定单。
这条陈述即反映了“顾客”与“定单”之间所存在的语义上的联系。
关联关系一般使用连接两个类的关联线表示。
关联线可以提供以下信息：
关联名称：
用于表示标记关联，如图6-14中的“提交定单”。
关联端名：
用于反映类在这一关联关系中扮演了什么角色，如图6-14中的“提交”、“被提交”。
关联导向性：
是指关联关系只在指定方向上成立，可以使用是一个指向符号表示，例如图6-14中的“提交定单”，其导向是由消费者指向购物定单。
关联限定符:
关联限定符通常用于一对多或多对多关联关系中，用于指明如何识别关联关系中另一端的类中的对象，可使多重性由一对多或多对多缩减为一对一或多对一的，如图6-15中的“定单编号”。
（3.2）聚集关系（聚合关系）
聚集是一种特殊的关联，用于反映类图中具有整体特征的类与具有部分特征的类之间的关系。
需求陈述中若出现了“包含”、“组成”等字句，则往往意味着存在聚集关系。
表示聚集的图形符号是在表示关联关系的直线末端紧挨着整体类的位置画一个菱形。
聚集关系具有传递性与反对称性。
其中，传递性是指如果A包含B，B又包含C，则A也将包含C。
反对称性是指如果A包含B，则B不能包含A。
聚集关系可以分为共享聚集与复合聚集两种形式。
如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成，则该聚集称为共享聚集，这是一种较弱的聚集关系，整体对部分并没有什么专门的限制，它们分别独立存在，只不过部分可以合并起来，其图形符号是空心菱形。
如图6-17中的装瓶的箱子与瓶子之间，就是这种共享聚集关系。
如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失，则该聚集称为复合聚集，这是一种较强的聚集关系，也称组合关系，其图形符号是实心菱形。
如窗口与窗口内控件之间的聚集关系。
当在屏幕上打开一个窗口时，窗口内的文本框、列表框、按钮等控件会一同出现，而一旦关闭了窗口，则组成窗口的诸多控件也同时消失。
因此，窗口和它的组成部分之间是复合聚集关系。
（3.3）泛化关系
类之间的泛化关系也就是前面介绍的类的继承关系，使用三角形图形符号表示，用于表明上级父类的属性、操作能够被下级子类继承。
图6-19中的图书与纸质图书、电子图书之间也具有这种泛化关系。
（3.4）依赖关系
依赖关系用于描述两个类之间存在的与依赖有关的语义上的连接关系。
其中，一个模型元素是独立的，另一个模型元素不是独立的，它依赖于独立的模型元素，需要由独立元素提供服务，如果独立元素改变了，将影响依赖于它的模型元素。
例如，一个类使用了另一个类的对象作为它的操作的参数，一个类使用了另一个类的对象作为它的数据成员，一个类工作依赖于另一个类向它发送消息等，这样的两个类之间就都存在着依赖关系。
依赖关系使用带箭头的虚线连接有依赖关系的两个类，其箭头指向独立的类。
图6-20是“定单提交窗口”与“定单”之间存在的依赖关系，其中“定单”类是独立的，而“定单提交窗口”依赖于“定单”类。
（4）序列图
以用例图中的用例为描述单位，以类图中的类为对象依据，以活动图中的活动转换为行为依据，建立与时间顺序有关的用例中对象之间的交互模型。
3．面向对象设计建模
面向对象设计建模需要把分析阶段的结果扩展成技术解决方案，需要建立的是软件系统的技术构造模型。
（1）设计类图
设计类图中的类是构造系统的基本模块单位，需要在分析类图基础上进行更加完整的面向设计的描述。
除了实体类，设计类图中还需要考虑用于向外提供操作接口的边界类和用于实现内部协调的控制类。
（2）协作图
描述
升级会员 