软件工程复习
Posted Keep--Silent
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了软件工程复习相关的知识,希望对你有一定的参考价值。
文章目录
- 1.结构化程序设计的基本方法
- 2.白盒测试技术的覆盖标准 P216
- 3.软件工程三要素
- 4.内聚耦合
- 5.瀑布模型 增量模型 演化模型 并发模型 统一软件过程,螺旋模型
- 6.测试的关键问题
- 7.er图,特别是基数,形态,建立er图
- 8.集成测试,单元测试 确认测试 P224-228
- 9.软件生命周期
- 10.cocomo2模型,计算项目NOP,工作量成本估算
- 11.决策树法
- 12.BCWS BCWP BAC ACWP
- 13.模块独立性的标准及其定义
- 14.体系结构的深度,宽度, 扇入扇出 p252课后习题 3 4 7 8
- 15.MIF
- 16.软件结构图
- 17.程序流程图表示算法,对应的流图,流图的区域,计算环形复杂度,设计路径覆盖的测试用例
- 18.LOC
- 19.需求分析的定义
- 20.面向对象程序设计的特性
- 21.软件的可维护性
- 22.绘制某应用系统的用例图
- 23.分析UML类及建立相应类图
- 24.顺序图描述法
1.结构化程序设计的基本方法
目的:提高程序可读性和易维护性、可调性和可扩充性
只允许三种基本程序结构形式:顺序结构、分支结构和循环结构(只允许一 个流动入口和一个出口)
自顶向下:先整体后细节,先全局后局部,从最上层总目标开始设计,逐步具体化
模块化设计:把个复杂问题分成多个简单问题,把每么小目标作为个模块
特点:不会出现死循环,在程序的静态形式与动态执行流程之间具有良好的对应关系
2.白盒测试技术的覆盖标准 P216
if(a^b)
c=a-b;
else
c=a+b;
白盒测试法的覆盖标准有逻辑覆盖、循环覆盖和基本路径测试。
其中逻辑覆盖包含以下, 覆盖强度由弱到强的顺序依次是:
-
语句覆盖
语句覆盖就是每个语句至少被执行一次。 -
判定覆盖
每个判断的分支取真分支和取假分支至少经历一次,每个分支执行一次。比如if、else分支 -
条件逻辑覆盖
使得判定的每个条件都需要至少满足一次,关注条件真假。 -
判断逻辑条件覆盖
使得每个判断取到可能的结果,并且判断中的每个条件也要取到可能的结果。判断和条件都必须满足
即if/else两个判断都要执行到,if中的条件a取false和true,b取false和b取true。同时满足判定覆盖与条件覆盖。 -
条件组合覆盖
即每个判定中条件的各种取值组合至少出现一次
比如上面的if为真的条件中;
a为真,b为真
a为真,b为假
a为假,b为真
a为假,b为假
- 路径覆盖
执行所有可能执行的路径
3.软件工程三要素
方法,工具,过程
软件工程方法为软件开发提供了“如何做”的技术。它包括了多方面的任务,如项目计划与估算、软件系统需求分析、数据结构、系统总体结构的设计、算法过程的设计、编码、测试以及维护等。
软件工具为软件工程方法提供了自动的或半自动的软件支撑环境。目前,已经推出了许多软件工具,这些软件工具集成起来,建立起称之为计算机辅助软件工程(CASE)的软件开发支撑系统。CASE将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。
软件工程的过程则是将软件工程的方法和工具综合起来以达到合理、及时地进行计算机软件开发的目的。过程定义了方法使用的顺序、要求交付的文档资料、为保证质量和协调变化所需要的管理、及软件开发各个阶段完成的里程碑。
4.内聚耦合
内聚与耦合分别为对模块内部与模块之间关联度的衡量
- 内聚衡量模块内部各元素之间的相互依赖的紧密程度
- 耦合衡量不同模块彼此间互相依赖的紧密程度
内聚
内聚按强度从低到高有以下几种类型:
偶然内聚
如果一个模块的各成分之间毫无关系,则称为偶然内聚,也就是说模块完成一组任务,这些任务之间的关系松散,实际上没有什么联系。
逻辑内聚
几个逻辑上相关的功能被放在同一模块中,则称为逻辑内聚。
如一个模块读取各种不同类型外设的输入。尽管逻辑内聚比偶然内聚合理一些,但逻辑内聚的模块各成分在功能上并无关系,即使局部功能的修改有时也会影响全局,因此这类模块的修改也比较困难。
时间内聚
如果一个模块完成的功能必须在同一时间内执行(如系统初始化),但这些功能只是因为时间因素关联在一起,则称为时间内聚。
通信内聚
如果一个模块的所有成分都操作同一数据集或生成同一数据集,则称为通信内聚。
过程内聚
构件或者操作的组合方式是,允许在调用前面的构件或操作之后,马上调用后面的构件或操作,即使两者之间没有数据进行传递。
模块完成多个需要按一定的步骤一次完成的功能。(过程相关—控制耦合)。
例如:在用程序流程图设计模块时,若将程序流程图中的一部分划出各自组成模块,便形成过程内聚。
这里的完成次序可以是用户自定义的特殊顺序(这个顺序不一定是必要的)
信息内聚
模块完成多个功能,各个功能都在同一数据结构上操作,每一项功能有一个唯一的入口点。这个模块将根据不同的要求,确定该模块执行哪一个功能。
由于这个模块的所有功能都是基于同一个数据结构(符号表),因此,它是一个信息内聚的模块。
顺序内聚
如果一个模块的各个成分和同一个功能密切相关,而且一个成分的输出作为另一个成分的输入,则称为顺序内聚。
功能内聚
模块的所有成分对于完成单一的功能都是必须的,则称为功能内聚。
耦合
一般模块之间可能的连接方式有七种,构成耦合性的七种类型。它们之间的关系为(独立性由强到弱)
非直接耦合(Nondirect Coupling)
如果两个模块之间没有直接关系,它们之间的联系完全是通过主模块的控制和调用来实现的,这就是非直接耦合。这种耦合的模块独立性最强。
数据耦合(Data Coupling)
传递的仅能是数据
如果一个模块访问另一个模块时,彼此之间是通过数据参数(不是控制参数、公共数据结构或外部变量)来交换输入、输出信息的,则称这种耦合为数据耦合。
由于限制了只通过参数表传递数据,按数据耦合开发的程序界面简单、安全可靠。因此,数据耦合是松散的耦合,模块之间的独立性比较强。在软件程序结构中至少必须有这类耦合。
印记耦合(Stamp Coupling)
如果一组模块通过参数表传递记录信息,就是标记耦合。
事实上,这组模块共享了这个记录,它是某一数据结构的子结构,而不是简单变量。这要求这些模块都必须清楚该记录的结构,并按结构要求对此记录进行操作。在设计中应尽量避免这种耦合,它使在数据结构上的操作复杂化了。如果采取“信息隐蔽”的方法,把在数据结构上的操作全部集中。
控制耦合(Control Coupling)
如果一个模块通过传送开关、标志、名字等控制信息,明显地控制选择另一模块的功能,就是控制耦合。
这种耦合的实质是在单一接口上选择多功能模块中的某项功能。因此,对所控制模块的任何修改,都会影响控制模块。另外,控制耦合也意味着控制模块必须知道所控制模块内部的一些逻辑关系,这些都会降低模块的独立性。
外部耦合(External Coupling)
一组模块都访问同一全局简单变量而不是同一全局数据结构,而且不是通过参数表传递该全局变量的信息,则称之为外部耦合。
例如C语言程序中各个模块都访问被说明为extern类型的外部变量。外部耦合引起的问题类似于公共耦合,区别在于在外部耦合中不存在依赖于一个数据结构内部各项的物理安排。
特征耦合
整个数据结构作为参数传递而被使用的仅是其中的一部分数据元素
公共耦合(Common Coupling)
若一组模块都访问同一个公共数据环境,则它们之间的耦合就称为公共耦合。
公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。
这种耦合会引起下列问题:
所有公共耦合模块都与某一个公共数据环境内部各项的物理安排有关,若修改某个数据的大小,将会影响到所有的模块。
无法控制各个模块对公共数据的存取,严重影响软件模块的可靠性和适应性。
公共数据名的使用,明显降低了程序的可读性。
公共耦合的复杂程度随耦合模块的个数增加而显著增加。
若只是两个模块之间有公共数据环境,则公共耦合有两种情况。
若一个模块只是往公共数据环境里传送数据,而另一个模块只是从公共数据环境中取数据,则这种公共耦合叫做松散公共耦合。(一传一取)
若两个模块都从公共数据环境中取数据,又都向公共数据环境里送数据,则这种公共耦合叫做紧密公共耦合。(双向传取)
只有在模块之间共享的数据很多,且通过参数表传递不方便时,才使用公共耦合。否则,还是使用模块独立性比较高的数据耦合好些。
内容耦合(Content Coupling)
如果发生下列情形,两个模块之间就发生了内容耦合。
一个模块直接访问另一个模块的内部数据;
一个模块不通过正常入口转到另一模块内部;
两个模块有一部分程序代码重叠(只可能出现在汇编语言中);
一个模块有多个入口。
在内容耦合的情形,所访问模块的任何变更,或者用不同的编译器对它再编译,都会造成程序出错。好在大多数高级程序设计语言已经设计成不允许出现内容耦合。它一般出现在汇编语言程序中。这种耦合是模块独立性最弱的耦合。
5.瀑布模型 增量模型 演化模型 并发模型 统一软件过程,螺旋模型
并发模型
统一软件过程
RUP(Rational Unified Process),统一软件开发过程,统一软件过程是一个面向对象且基于网络的程序开发方法论。
RUP是风险驱动的、基于Use Case技术的、以架构为中心的、迭代的、可配置的软件开发流程。
RUP描述了如何有效地利用商业的可靠的方法开发和部署软件,是一种重量级过程(也被称作厚方法学),因此特别适用于大型软件团队开发大型项目
基本的概念,大概了解 RUP 究竟是个什么东西
核心概念
RUP中定义的核心概念主要有角色、活动和工作
(1)角色:RUP预先定义了许多角色,角色描述了在项目开发中,一个人或者一个开发团队的工作职能与任务。
(2)活动:它是一个有明确功能的独立模块,反映了系统的某个功能。
(3)工件:是在活动进行过程中产生、创建或修改的一段信息,同时也是项目开发的文档资料
RUP 开发中会用到的专业名词,看解释可以明白其代表的含义
开发过程
RUP中的软件生命周期在时间上被分解为四个顺序的阶段,分别是:初始阶段、细化阶段、构造阶段和交付阶段。每个阶段结束于一个主要的里程碑。每个阶段本质上是两个里程碑之间的时间跨度。在每个阶段的结尾执行一次评估以确定这个阶段的目标是否已经满足。如果评估结果令人满意的话,可以允许项目进入下一个阶段。
这是使用 RUP 开发的基本过程,遵循该过程的每一个阶段进行对应的工作,每个阶段必须交出满意答卷才能进行下一阶段
初始阶段
(1)对需求有大概了解,确定系统中大多数角色和用例。
(2)划分主要子系统,给出系统的体系结构概貌
(3)分析整个项目进行中的业务和需求方面的主要风险,评价项目可行性。
(4)考虑时间、经费、技术、项目规模和效益等因素
(5)制定开发计划
(6)初始阶段结束时是第一个重要的里程碑:生命周期目标里程碑。生命周期目标里程碑评价项目基本的生存能力
细化阶段
(1)进行需求风险分析。考虑项目目标是否偏离用户需求
(2)进行技术风险分析。通过建立原型等方法,考虑所选技术方案可行性
(3)进行技能风险分析。考虑实施项目人员素质能否胜任项目要求
(4)进行政策风险分析。考虑政策性因素对项目的影响
(5)进行高层分析和设计,并作出结构性决策。
(6)产生简要体系结构,包括用例列表、领域概念模型和技术平台等
(7)为构造制定计划
(8)同时为项目建立支持环境,包括创建开发案例,创建模板、准则并准备工具。
(9)细化阶段结束时第二个重要的里程碑:生命周期结构里程碑。生命周期结构里程碑为系统的结构建立了管理基准并使项目小组能够在构建阶段中进行衡量。此刻,要检验详细的系统目标和范围、结构的选择以及主要风险的解决方案
构造阶段
(1)构建阶段是一个制造过程,其重点放在管理资源及控制运作以优化成本、进度和质量,迭代增量的开发一个完整的软件系统。
(2)在构建阶段,所有剩余的构件和应用程序功能被开发并集成为产品,所有的功能被详细测试。
(3)构建阶段结束时是第三个重要的里程碑:初始功能里程碑。初始功能里程碑决定了产品是否可以在测试环境中进行部署。此刻,要确定软件、环境、用户是否可以开始系统的运作。此时的产品版本也常被称为“beta”版
交付阶段
(1)交付阶段的重点是确保软件对最终用户是可用的。
(2)交付阶段可以跨越几次迭代,包括为发布做准备的产品测试,基于用户反馈的少量的调整。用户反馈应主要集中在产品调整,设置、安装和可用性问题,所有主要的结构问题应该已经在项目生命周期的早期阶段解决了。
(3)在交付阶段的终点是第四个里程碑:产品发布里程碑。此时,要确定目标是否实现,是否应该开始另一个开发周期。在一些情况下这个里程碑可能与下一个周期的初始阶段的结束重合
瀑布模型
工作流程
需求分析—软件需求—分析—程序设计—编码—测试—运行
每个阶段都需要进行审核和文档输出(文档驱动)
模型作用
为软件开发和维护提供了有效的管理模式。在软件开发早期,在消除非结构化软件、降低软件复杂度、促进软件开发工程化方面起着显著的作用。
每个开发活动的特征:
·本活动依赖于上一项活动的输出作为工作对象,这些输出一般是代表某活动结束的里程碑式文档。
·根据本阶段的活动规程执行相应的任务。
·本阶段活动的最终产出——软件工件,将会作为下一活动的输入。
·对本阶段活动执行情况进行评审。
优点:
降低复杂度、提高透明性和可管理性、强调需求分析和设计、阶段审核和文档输出保证了阶段之间的正确衔接,能够及时发现问题。
缺点:
缺乏灵活性、不适用于需求不明的开发情况、风险控制能力较低、文档驱动增加了系统的工作量、只依赖于文档来评估进度,可能会得出错误结论、成功周期较长
适用场景:
需求明确、较大型系统、开发周期不紧张
演化模型
工作流程:
在瀑布模型的基础上,一次性开发难以成功,因此,演化模型提倡进行“两次开发”,分别是试验开发和产品开发。每个开发阶段按照瀑布模型进行具体开发活动。
适用场景:
需求不清、开发周期短的中小型系统。
优点:
明确用户需求、提高系统质量、降低开发风险
缺点:
管理难度提高、开发结构化较差、可能抛弃文档驱动、可能导致产品结构化较差
增量模型
模型概述:
结合瀑布模型和演化模型的优点,在需求不清时,对最核心或最清晰的需求,利用瀑布模型实现。再对后续需求进行重复开发(可能按照需求的优先级逐个进行),从而逐步建成一个完整的软件系统。
优点:
保障核心功能实现、开发风险较低、保障最高优先级的功能的可靠实现、提高系统稳定性和可维护性。
缺点:
增量粒度难以合理选择、确定所有的需求服务较困难
螺旋模型
模型概述:
将开发过程分为四个类型:风险分析、制定计划、实施工程、客户评估。每次评估之后确定是否进行螺旋线的下一个回路。
适用对象:
风险较高、开发周期较长的大型软件项目
优点和缺点:
降低风险,但是开发周期长。
6.测试的关键问题
7.er图,特别是基数,形态,建立er图
8.集成测试,单元测试 确认测试 P224-228
单元测试(Unit Testing)
单元测试又称模块测试,是针对软件设计的最小单位(模块)进行正确性检验的测试,检查每个程序模块是否实现了规定的功能,保证其能正常工作。
测试重点:
(1)系统的模块,子程序的正确性验证等
(2)白盒测试
集成测试(Integrated Testing)
集成测试是把已测试过的模块组装起来,对与设计相关的软件体系结构进行测试。
测试重点:
(1)把各个模块连接起来,模块接口的数据是否会丢失
(2)单独一个子模块的功能是否会对另一个模块的功能产生不利的影响
(3)各个子模块功能组合起来,能否达到预期的要求
(4)全局数据结构是否有问题
(5)单个模块的误差积累起来,是否会被放大从而达到不能接受的程度
(6)白盒测试+黑盒测试
确认测试(Confirm Testing)
确认测试是检验所开发的软件是否满足SRD(System Requirement Document)中定义的需求、性能要求,以及软件配置是否完全正确。
系统测试(System Testing)
系统测试是把通过确认测试的软件作为系统的一个元素,接入系统的实际运行环境中,与系统的其他部分(硬件、系统、数据库、第三方数据等)结合起来进行测试。
测试重点:
(1)整个系统运行的稳定性
(2)整个系统的兼容性
(3)是否符合“需求规格说明书”
(4)黑盒测试
验收测试(Acceptance Testing)
验收测试是检验软件产品的最后一关,在这个环节,测试主要从用户的角度着手。是一个确定产品能否满足合同/用户需求的测试。
9.软件生命周期
规划阶段
确定这个软件的开发目标及其可行性
设计阶段
完成说明书,确定开发阶段产品开发阶段
稳定阶段
测试和调试
发布阶段
10.cocomo2模型,计算项目NOP,工作量成本估算
COCOMOII模型中使用三个螺旋式的过程模型:应用组装模型,早期设计模型和后体系结构模型。
应用组装模型(Application Composition)
应用组装模型是基于对象点的度量模型,它通过计算屏幕、报表、第三代语言(3GL)模块等对象点的数量来确定基本的规模,每个对象点都有权重,由一个三级的复杂性因子表示,将各个对象点的权值累加起来得到一个总体规模,然后再针对复用进行调整。
早期设计模型(early design)
在项目开始后的一个阶段或者螺旋周期通常包括探索体系结构的可供选择方案或增量开放测量。为支持这一活动,COCOMOII提出了一个早期设计模型,这一模型使用功能点和等价代码行估算规模。
后体系结构模型(post architecture)
一旦项目进入开放阶段,就必然确定一个具体的生命周期体系结构,此时项目就能够为估算提供更多更准确的信息。
COCOMOII模型估算方法
在利用COCOMOII模型进行软件成本估算过程中,首先采用软件规模估算方法对项目的规模进行估算。再应用五个比例因子,通过相关计算,将规模转化为工作量,并通过十七个成本驱动因子对工作量进行调整。最后,采用进度计算公式,计算出开发该项目所需要的进度以及人数。
工作量成本估算
E = B + 0.01 ∗ ∑ j = 1 5 E M j \\displaystyle E=B+0.01*\\sum_j=1^5EM_j E=B+0.01∗j=1∑5EMj
P M = A ∗ S i z e E ∗ ∏ i n E M i \\displaystyle PM=A*Size^E*\\prod_i^n EM_i PM=A∗SizeE∗i∏nEMi
P R O D = N O P 人 月 , P M = N O P P R O D PROD=\\cfracNOP人月,PM=\\cfracNOPPROD PROD=人月NOP,PM=PRODNOP
计算项目NOP
N O P = 对 象 点 数 目 × 100 − R E U S E % 100 NOP=对象点数目 \\times \\cfrac100-REUSE\\%100 NOP=对象点数目×100100−REUSE%
11.决策树法
决策表(决策树)
定义
决策树(Decision Tree)是在已知各种情况发生概率的基础上,通过构成决策树来求取净现值的期望值大于等于零的概率,评价项目风险,判断其可行性的决策分析方法,是直观运用概率分析的一种图解法。由于这种决策分支画成图形很像一棵树的枝干,故称决策树。
决策树是一种树形结构,其中每个内部节点表示一个属性上的测试,每个分支代表一个测试输出,每个叶节点代表一种类别。
决策树是一种十分常用的分类方法。
决策点,是对几种可能方案的选择,即最后选择的最佳方案。如果决策属于多级决策,则决策树的中间可以有多个决策点,以决策树根部的决策点为最终决策方案。
状态节点,代表备选方案的经济效果(期望值),通过各状态节点的经济效果的对比,按照一定的决策标准就可以选出最佳方案。由状态节点引出的分支称为概率枝,概率枝的数目表示可能出现的自然状态数目每个分枝上要注明该状态出现的概率。
结果节点,将每个方案在各种自然状态下取得的损益值标注于结果节点的右端。
优点
决策树易于理解和实现,人们在学习过程中不需要使用者了解很多的背景知识,这同时是它的能够直接体现数据的特点,只要通过解释后都有能力去理解决策树所表达的意义。
对于决策树,数据的准备往往是简单或者是不必要的,而且能够同时处理数据型和常规型属性,在相对短的时间内能够对大型数据源做出可行且效果良好的结果。
易于通过静态测试来对模型进行评测,可以测定模型可信度;如果给定一个观察的模型,那么根据所产生的决策树很容易推出相应的逻辑表达式。
缺点
1)对连续性的字段比较难预测。
2)对有时间顺序的数据,需要很多预处理的工作。
3)当类别太多时,错误可能就会增加的比较快。
4)一般的算法分类的时候,只是根据一个字段来分类。
12.BCWS BCWP BAC ACWP
举例:某土方工程总挖方量为 4000立方米,计划用10天完成,每天400立方米,预算单价为45元/立方米,该挖方工程预算总费用为180000元。 开工后第7天早晨刚上班时业主项目管理人员前去测量,取得了两个数据:已完成挖方2000立方米,支付给承包单位的工程进度款累计已达120000元。
1、计算BCWP(实际完成工作的预算成本)
BCWP =45元/立方米 ×2000立方米=90000元
从这里可以看出,实际完成工作预算成本(BCWP)与项目进度没有直接关心,并不关系项目实际进度到了什么程度,只关系实际完成的工作量
2、计算BCWS(计划工作预算成本)
开工后第6天结束时,承包单位应得到的工程进度款累计额为BCWS=108000元。
3、计算ACWP(完成工作的实际成本)
本案例的ACWP很明显,直接给出了,ACWP=120000
进一步计算得:
4、费用偏差,也叫成本偏差:CV = BCWP- ACWP=90000-120000=-30000元,表明承包单位已经超支。
5、进度偏差:SV = BCWP- BCWS=90000-108000=-18000元,表明承包单位进度已经拖延。表示项目进度落后,较预算还有相当于18000元的工作量没有做。18000元/(400×45)=1天的工作量,所以承包单位的进度已经落后1天。
另外,还可以使用费用实施指数CPI和进度实施指数SPI测量工作是否按照计划进行。
CPI= BCWP/ACWP = 90000/120000=0.75.
SPI= BCWP/BCWS = 90000/108000=0.83.
CPI和SPI都小于1,给该项目亮了黄牌。
从上面可以看出,CV和CPI是一组指标,SV和SPI是一组指标。
注意:有的时候提到挣值EV,这个EV实际上就是BCWP
记忆方法:
1、 BCWS、BCWP、ACWP是基础的术语,这个一定要记住(B:预算;C:成本 S:计划 P:执行)
2、 BCWS(计划预算):是说在某个时刻,计划应该完成的工作的预算成本,只有这个指标与项目进度有关
3、 BCWP(执行预算):是说已经完成的工作,所对应的预算成本,很明显这个指标关心的是已经完成的工
作的预算,至于这个工作是否超时、超支,并不关心
4、 ACWP(执行成本):就是说已经完成的工作,所已经花费的成本,很明显这个指标关心的是已经完成
工作的成本,至于时候超时、超支,并不关心
5、 在实际工作中,我们要关心项目是否超时,这必然要与进度有关,所以与BCWS、BCWP有关
SV = BCWP – BCWS SPI = BCWP / BCWS
6、 在实际工作中,我们要关心项目是否超支,这与进度无关,所以与BCWS无关,只与BCWP、ACWP有关
CV = BCWP-ACWP CPI=BCWP/ACWP
7、在公式5和6中,被减数(被除数)都是BCWP
13.模块独立性的标准及其定义
内聚和耦合
模块的独立程度可以由两个定性标准衡量,这两个标准分别是内聚和耦合。
耦合衡量不同模块彼此间互相依赖(连接)的紧密程度;内聚衡量一个模块内部各个元素彼此结合的紧密程度。
-
耦合:
- 定义:
是对一个软件结构内不同模块之间互连程度的度量。耦合强弱取决于模块间接口的复杂程度,进入或访问一个模块的点,以及通过接口的数据。 - 分类:
(1)数据耦合:两个模块彼此间通过参数交换信息,而且交换的信息仅仅是数据。
(2)控制耦合:如果传递的信息中有控制信息(尽管有时这种控制信息以数据形式出现)
(3)特征耦合:当把整个数据结构作为参数传递而被调用的模块只使用其中一部分数据元素时
(4)公共环境耦合:当两个或多个模块通过一个公共数据环境相互作用时
(5)内容耦合:最高程度的耦合;如果出现以下情况之一,两个模块就发生了内容耦合:
a. 一个模块访问另一个模块的内部数据
b. 一个模块不通过正常入口而转到另一个模块的内部
c. 两个模块有一部分代码重叠(只可能出现在汇编语言)
d. 一个模块有多个入口(意味着一个模块有几种功能)
耦合设计原则:尽量使用数据耦合,少用控制耦合和特征耦合,限制公共环境耦合的范围,完全不用内容耦合。 - 定义:
-
内聚
-
定义:
标志着一个模块内哥哥元素彼此解和的紧密程度,它是信息隐藏和局部化概念的自然扩展。简单的说,理想内聚只做一件事情。(内聚和耦合是密切相关的,模块内的高内聚往往意味着模块间的低耦合,内聚和耦合都是进行模块化设计的有利工具,但是内聚更重要) -
分类:
A. 高内聚:
(1) 顺序内聚:如果一个模块内的处理元素和同一功能密切相关,而且这些处理必须顺序执行(9分)
(2) 功能内聚:如果模块内所有处理元素属于一个整体,完成一个单一的功能(10分)
B. 中内聚:
(1) 过程内聚:如果一个模块内的处理元素是相关的,而且必须经过特定的次序执行(5分)
(2) 通信内聚:如果模块中所有元素都使用同一输入数据和(或)产生统一输出数据(7分)
C. 低内聚:
(1) 偶然内聚:如果一个模块完成一组任务,这些任务彼此间即使有关系,关系也是很松散的。(0分)
(2) 逻辑内聚:如果一个模块完成的任务在逻辑上属于相同或相似的一类。(1分)
(3) 时间内聚:如果一个模块包含的任务必须在同一时间内执行(3分)
14.体系结构的深度,宽度, 扇入扇出 p252课后习题 3 4 7 8
15.MIF
16.软件结构图
17.程序流程图表示算法,对应的流图,流图的区域,计算环形复杂度,设计路径覆盖的测试用例
18.LOC
19.需求分析的定义
20.面向对象程序设计的特性
21.软件的可维护性
22.绘制某应用系统的用例图
23.分析UML类及建立相应类图
24.顺序图描述法
以上是关于软件工程复习的主要内容,如果未能解决你的问题,请参考以下文章