2022年软件工程期末复习.docx

《2022年软件工程期末复习.docx》由会员分享，可在线阅读，更多相关《2022年软件工程期末复习.docx（42页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、精选学习资料 - - - - - - - - - 软件工程期末复习名师归纳总结 - - - - - - -第 1 页,共 25 页精选学习资料 - - - - - - - - - 作者：日期：2 名师归纳总结 - - - - - - -第 2 页,共 25 页精选学习资料 - - - - - - - - - 一 基本概念1 简述 1983 年 IEEE 为软件下的定义； 5822926 运算机程序、 方法、规章、相关的文档资料以及在运算机上运行程序时所必需的数据；2 简述软件危机的表现有哪些？以及解决软件危机的途径有哪些？软件危机的主要表现包括：1 软件开发进度难以猜测,开发成本难以掌握,导致

2、超预算、超时；2 产品功能难以满意用户需求；3 软件产品质量无法保证；4 软件缺少适当的文档资料,保护困难；5 软件成本超过硬件成本；6 软件开发生产率的提高速度跟不上运算机应用普及深化的趋势；解决软件危机的途径有：1 治理措施：项目治理、配置治理、过程治理、质量掌握 2 技术措施：开发过程、开发技术与方法和开发工具3 软件工程的定义1993 年 IEEE 给出的定义：软件工程是：系统的、 规范的、 可度量的途径应用于软件开发、运行和保护过程,也就是把工程应用于软件；争论中提到的途径；”软件工程是环绕软件开发的一门交叉学科：4 软件工程的 10 个学问领域软件工程 =运算机科学 +工程学 +治

3、理学软件工程过程 Software Engineering Process 软件工程工具和方法 Software Engineering Tools and Methods 软件需求 Software Requirementl 软件设计 Software Design 软件构造 Software Construction 软件测试 Software Testing 3 名师归纳总结 - - - - - - -第 3 页,共 25 页精选学习资料 - - - - - - - - - 软件保护 Software Maintenance 软件配置治理 Software Configuration m

4、anagement 软件工程治理 Software Engineering management 软件质量 Software Quality 5 软件工程的目标是什么,软件工程的三要素都是什么？软件工程的目标：软件工程必需以有组织的质量保证为基础,进行全面质量治理,不断地过程改进使软件工程方法走向成熟；软件工程的三要素包括：过程、方法和工具过程为准时合理地开发出满意用户需求的运算机软件而进行一系列有组织的活动；过程定义了技术方法的接受、工程产品 包括模型、文档、数据、报告、表格等 的产生、里程碑的建立、质量的保证和变更的治理；方法为软件开发供应“ 如何做” 的技术,它涵盖了项目方案、需求分析、

5、系统设计、程序实现、 测试与保护等一系列的开发活动如何来做；开发方法经受了从面对结构、面对对象、面对组件到面对服务的进展工程；工具为过程和方法供应自动的或半自动的支持；这些软件工具被集成起来,建立起一个支持软件开发的系统,称之为运算机帮助软件工程 Engineering ；6 软件工程的七条基本原理CASE , Computer Aided Software 美国闻名的软件工程专家巴利.玻姆 Barry Boehm提出了软件工程的七条基本原理：1用分阶段的生命周期方案严格治理；2坚持进行阶段评审；3实行严格的产品掌握；4接受现代程序设计技术；5结果应能清晰地审查；6开发小组的人员应少而精；7承

6、认不断改进软件工程实践的必要性；7 简述软件过程的定义,软件过程又可以分为那几个类型？软件过程 Software Procedure 是为获得软件产品,在软件工具支持下由软件工程师完成 的一系列软件工程活动；软件过程可概括为基本过程、支持过程和组织过程等三种类型；其中,基本过程包括：猎取过程、供应过程、开发过程、运作过程和保护过程；支持过程包括：文档编制过程、配置治理过程、质量保证过程、验证过程、确认过程、联合评审过程和 问题解决过程等过程；组织过程包括：治理过程、基础设施过程、改进过程和培训过程；4 名师归纳总结 - - - - - - -第 4 页,共 25 页精选学习资料 - - - -

7、 - - - - - 8 里程碑 Mile Stone 思想阶段工作的目标进行总结、评审、调整和部署下一个里程碑；目的：合理安排, 细化治理 “ 粒度” ,降低项目风险；9 基线思想基线是指一个 或一组 配置项在项目生命周期的不同时间点的一种状态,各阶段有各阶段的基线：需求基线、设计基线、测试基线等；基线一旦建立后变化需要受掌握；10 简述软件生存周期的概念, 说明软件生存周期划分为那几个主要时期？每个时期有包括哪些主要阶段？软件生存周期是指软件产品从定义到开发、使用和保护, 直到最终被弃用的时期,称为生存周期；生存周期的可划分为方案时期、开发时期和运行时期等三个主要时期；其中方案时期包括问题

8、定义和可行性争论两个阶段；开发时期包括需求分析、总体设计、 详细设计和实现等四个阶段；运行时期的又称为运行和保护阶段；11 简述教材中介绍了那些软件开发模型？这些模型各有什么特点？教材中重点介绍了瀑布、原型、增量、螺旋四个传统模型和RUP、XP 两个现代模型；其中, 瀑布模型严格依据生存周期开发软件,每个阶段必需完成规定的、完整、精确的合格文档,前一阶段的输出文档就是后一阶段的输入文档；其主要特点包括：活动间具有次序性和依靠性；推迟实现的观点；质量保证的观点；快速原型模型法是开发人员在一个基本的需求的基础上快速开发出一个软件原型,然后由用户使用和评判原型、开发人员依据用户看法再修改原型,然后再

9、使用评判再修改、直至将原型进化为最终产品；快速原型模型的特点包括： 做出系统原型,及早向用户展现系统要实现的界面及功能,增强用户的合作信心； 直观化的表达,简洁沟通,排除懂得上的歧义； 修改集中在前期的原型确认上,较大程度削减后期实施中的返工； 入手快,加快开发进度；增量模型是一种演化模型,先完成一个系统子集的开发,再按同样的开发步骤增加子集 ,如此递增下去直至满意全部系统需求；每个增量可按快速原型法进行；增量模型的特点包括：无须等待猎取完整需求就可入手,尽快见到成果,增强双方信心； 分步开发, 降低复杂性和难度,削减技术风险, 并可并行开发； 边开发边投入,可及早发觉问题,削减投资风险； 各

10、个子集是逐步并入已有的系统中,加入子集不能破坏已构造好的部分,这需要软件具备开放式的体系结构； 适用于需求不完整的软件开发,指的是需求逐步摸清、逐步完善,并非随便转变,5 名师归纳总结 - - - - - - -第 5 页,共 25 页精选学习资料 - - - - - - - - - 介绍的 XP（极限编程）属于该模型；螺旋模型 Spiral model 是一种融合了瀑布模型、快速原型模型和增量模型的演进模型,并引入风险分析机制；适合大型复杂的系统开发；螺旋模型特点 包括：多种模型结合的一种演进模型,融合了瀑布模型、快速原型和增量模型的全部特点,融进了循环往复、迭代演进的思想； 增加风险分析,

11、一旦风险成立,原方案应终止、修订,力求风险可控 客户始终参加每个阶段的开发 ,每个阶段的成果需客户确认,防止错误的积存；统一过程RUP Rational Unified Process是由 Rational 公司在推出统一建模语言UML后,推出的一个软件开发框架RUP ,称为软件统一开发过程；12 统一过程 RUP 定义了那几个主要阶段？初始阶段 Inception: 主要完成商业需求, 确定项目边界； 里程碑是生命周期目标 Lifecycle Objective ,评判项目基本的生存才能；细化阶段 Elaboration: 主要完成领域问题分析和软件设计；猎取用户需求（功能和非功 能需求）,

12、建立需求模型；进一步确立体系结构和设计软件结构等工作；里程碑是生命 周期结构 Lifecycle Architecture ；构造阶段 Construction: 主要完成系统实现、 测试,里程碑是初始功能 Initial Operational ,产品版本常被称为“beta ”版；交付阶段 Transition: 重点是确保软件对最终用户是可用的；里程碑：产品发布 Product Release 13 统一过程 RUP 工作流1 6 个核心过程工作流Core Process Workflows 商业建模 Business Modeling ：弄清项目边界和约束,做出方案；需求 Require

13、ments：描述系统应做什么,开发人员和用户达成需求基线；分析和设计 Analysis & Design ：将需求转化成运算机可以实现的模型；实现 Implementation ：用程序设计语言将设计模型组织成可执行的文件、数据；测试 Test：是发觉软件中的错误,在试验环境下验证全部的需求是否被正确 的实现；部署 Deployment ：将软件分发给最终用户,安装在真实的环境下,由用户操 作运行；2 3 个核心支持工作流 Core Supporting Workflows 是对核心过程工作流的配套支持和管 理,保证核心过程工作流顺畅、高效运行；配置和变更治理：工作文档的治理,在版本更新、需求

14、变更中做到各类文档及 时、同步跟踪,保证各文档内容完整、一样；项目治理 Project Management ：资源配置、评估监控、风险掌握、方案调整等 治理工作,目的效益最大化；环境 Environment ：软件开发环境,包括人员、设备、过程和工具,以及各种 规范、指导手册和保证措施；6 名师归纳总结 - - - - - - -第 6 页,共 25 页精选学习资料 - - - - - - - - - 14 简述 rup 模型中基线与里程碑的概念,二者之间的关系；基线,是软件文档或源码或其它产出物 的一个稳固版本,它是进一步开发的基础,也可以懂得成为一个阶段的起点并已经制定了相应的工作标准,

15、个标准；并且只有经过授权后才能变更这里程碑, 是方案中确定的阶段性工作完成目标,要求提交阶段交付物,作为阶段评估的标准；基线和里程牌的关系：基线是为了建立参照点,是阶段的起点； 里程牌是建立阶段性目标,是阶段终点,最终的里程牌可能是一次迭代的终结；15 简述软件方案的目标和主要工作 . 软件方案的目标：争论项目的可行性,争论合理地运用软件项目开发所需的资源、经费,把握开发进度,掌握项目开发过程按此方案进行；主要工作包括 :确定项目实施范畴、定义递交的工作成果、制定项目实施的时间方案、成本和预算方案、人力资源方案等；评估实施过程中主要的风险、16 软件方案的活动有哪些？这些活动的内容是什么？软件

16、方案主要活动包括：问题定义,可行性争论,项目方案；这些活动的内容是：问题定义：确定项目实施范畴,回答项目“ 做什么？” 的问题；可行性争论：项目的必要性和可能性；制定项目方案：编制项目开发方案；17 简述问题定义的目的和主要任务；问题定义的目的：弄清要运算机解决的根本问题所在要解决的问题是什么？,确定新系统的作用域,以及项目所需的资源、工期和经费；问题定义的主要任务：编写项目报告提交审查,作为可行性分析的依据；18 简述可行性分析的目的、任务和内容；可行性分析的目的：确定项目的必要性和可能性；可行性分析的任务包括：可行性分析；写可行性争论报告；编制开发方案；可行性分析的内容包括：技术、经济和社

17、会三个方面的可行性：7 名师归纳总结 - - - - - - -第 7 页,共 25 页精选学习资料 - - - - - - - - - 19 简述需求分析的目的、必要性和参加角色需求分析的目的是：弄清用户对系统的细节要求,完整、精确、清晰、具体地回答目标系统“ 做什么” ；精确地懂得用户提出的软件功能、性能及其环境的要求；需求分析的必要性：用户与开发者的学问领域不同,产生歧义；软件开发失败 50%是需求不合理,早期错误易放大；参加角色： 开发方包括分析师、设计师和架构师； 用户方包括领域专家、用户和部门负责人；20 需求开发的任务有哪些？需求开发的任务包括需求猎取：收集用户对目标软件系统在功

18、能、性能、行为、设计约束等方面的期望；需求分析： 通过符号和文字说明描述系统模型,使用户和开发者间建立共同语言基础,排除懂得上的歧义的过程；需求说明： 既编写需求文档,也称编写需求规格说明书；需求说明书是需求分析阶段的最终成果, 也是需求分析阶段复审的依据；是用户领域专家、的途径和媒介；是交付给用户文档的一部份；软件分析师、 软件设计师共同沟通需求验证 :即需求评审；依据需求说明书,分析师、设计师、客户会审文档,对需求的正确 性、一样性、完整性、无二义行进行评审、确认；21 需求的层次软件需求包括三个不同的层次：业务需求、用户需求、功能需求,也包括非功能需求；1业务需求 business re

19、quirement 业务需求是反映企业/组织对软件系统的高层次目标要求,即软件系统的建设目标；业务需求通常是“ 问题定义” 或“ 可行性争论” 阶段猎取的内容；在需求规格说明书中反映在项目背景、系统目标或任务概述的描述中；猎取的主要对象是客户方的高管、专家、部门负责人；2用户需求 user requirement 用户需求：用来描述用户使用产品必需要完成的任务；使用业务领域的术语描述,接受开发者与用户都能懂得的语言和图形表达；用户需求是经过调查、归纳后双方认同的结果；猎取的主要对象是部门负责人、软件的操作者或称终端用户；3. 功能需求 functional requirement 功能需求定义

20、了开发人员必需实现的软件功能,结果在需求规格说明书中 ;功能需求用软件行业术语表达： 通常是需求建模的结果即目标系统的规律模型,如结构化的功能模型、数据模型、行为模型,面对对象的类模型等；4. 非功能需求特性是指一些非功能需求,是满意业务需求的性能要求；如界面的交互性、数据的安全性、数据的事务性、用户的并发性、响应的快速性、操作的实时性、错误与反常的复原性、软件的容错性等等；项目的失败或拖延一般不是在功能上,而恰恰倒是在性能要求上,由于这些性能与软件的体系结构有关,与构成系统的网路与硬件环境等底层技术有关,往往超越一8 名师归纳总结 - - - - - - -第 8 页,共 25 页精选学习资

21、料 - - - - - - - - - 般开发人员的技术才能；22 需求猎取的一般方法需求猎取方法以采访、观看、座谈、对从前的系统版本的测试等；必要时接受快速原型法； 先集中在使用者对系统的观点上,以收集用户原始资料,数据、工作方式、工作流程、使用要求等为工作起点,深化到部门、车间、班组,做好原始纪录； 然后依据对问题及环境的懂得与开发体会,改正用户需求的模糊、 歧义和不一样性要求,排除用户的不合理要求,挖掘用户尚未提出但具有价值的潜在需求,使用户需求逐步精确化、一样化和完全化； 需求猎取非一次完成：需要往复进行、逐步深化； 需求猎取的内容：写进“ 需求规格说明书”,确认；23 需求猎取的策略

22、 循序渐进的策略； 确定优先级：先进行重点的需求调研,有助于识别出重大的风险,并为制定迭代方案提供指导； 不要陷入技术：需求未明确,应回避对技术问题争论； 挖掘用户需求 : “诱导式”就是挖掘用户需求；客户并非 IT 专业人士, 需求的概念是模糊的、笼统的,而且尺度难以把握,猜测潜在需求； 区分不必要的需求：客户对有些需求提不出来,自然也会提出一些不必要的需求；24 简述概要设计和具体设计的内容；软件设计包括概要设计和具体设计；概要设计又分为体系结构设计和领域问题结构设计；体系结构设计： 是支撑和治理软件运行的环境设计；由于现代的软件是处在操作系统、网络、各种服务器共同搭建的环境下运行,并且具

23、有并发、安全、事务等多方面的治理,是软件设计优先考虑的问题；领域问题结构设计：满意需求的软件功能设计,核心所在； 将领域问题的分析模型细化成软件结构模型,也就是划分软件的模块结构及确定模块之间的关系；具体设计又分为如下三个部分：对模块内部的过程和数据结构进行设计；也就是对模块内进行算法分析和程序设计；人机交互界面的具体设计,仍有与其它外部系统接口设计；完成对数据库的物理设计概要设计是依据需求确定软件和数据的总体框架；和数据结构；25 9 具体设计是进一步精化成软件的算法名师归纳总结 - - - - - - -第 9 页,共 25 页精选学习资料 - - - - - - - - - 25 简述衡

24、量软件模块独立性的度量标准有哪些？模块独立性是指模块能够完成独立的功能；模块符合信息隐匿和信息局部化原就；模块间关连和依靠程度尽量小；衡量软件模块独立性的度量标准的指标有取决于模块的内部特点的指标内聚度和取决于模块的外部特点的指标耦合度；内聚度：一个模块内部各个元素间语句和程序段 彼此的紧密程度的度量；耦合度：指软件结构中各模块间相互联系紧密程度的一种度量；26 简述内聚度的七个等级？内聚度表示一个模块内部各成分之间彼此结合的紧密程度；内聚度按其高低程度可 分为七级,高内聚度模块独立性强,设计尽可能提高模块内聚度； 偶然性内聚：是指一个模块内各成分为完成一组功能而组合在一起,它们相互之间 即使

25、有关系,也很松散； 规律性内聚：模块内完成的诸任务规律上相关；该类内聚的缺点是执行中要从模块 作判定的开关量 ,从而 增加了块间偶合 掌握偶合 ；外引入用 时间性内聚：假如一个模块包含的诸任务必需在同一时间段内执行,就称之为时间 性内聚 过程性内聚：模块的过程性内聚度是指模块内成份彼此相关,并且必需按特定的次 序在本模块内执行； 通讯性内聚：是指模块中各组成成分都将对某个数据结构的同一区域进行操作,以 达到通信的目的； 次序性内聚：一个模块内的各处理成分均与同一功能相关,且这些处理必需次序执 行,通常,一个处理成分的输出是另一个处理成分的输入；功能性内聚：模块内全部成分形成一个整体,完成单个功

26、能,就称功能内聚,功能 内聚是最高程度的内聚形式；27 耦合度的七个等级耦合度是模块独立性最显著特点；耦合度按其高低程度可分为七级,松耦合是软件 设计始终追求的目标； 非直接耦合 : 模块不依靠另一个模块能独立工作,这是最松的耦合； 数据耦合 : 两模块间通过参数交换数据信息,就称这两模块为数据耦合；模块之间除传递关键数据外仍附加公共数据； 特点耦合 : 掌握耦合 : 假如两模块间通过参数交换信息,此时如传递的信息中含有掌握信息,就为掌握耦合； 外部耦合 : 当如干模块均与同一个外部环境关联,它们之间便存在外部耦合； 公共耦合 : 当如干模块通过全局的数据环境相互作用时,它们之间存在公共耦合；

27、 内容耦合 :当一个模块使用另一个模块内部的数据或掌握信息；一个模块直接转移到另一个模块内部等,模块间的耦合就是内容耦合；10 名师归纳总结 - - - - - - -第 10 页,共 25 页精选学习资料 - - - - - - - - - 28 简述模块的作用域与掌握域的概念及其相关设计原就；模块的作用域：从功能方面考虑,受模块内一个判定影响的全部模块的集合；模块的掌握域：从结构方面考虑,包括它自己及其全部下属模块的集合；相关设计原就是：模块的作用域应在掌握域之内；29 具体设计的表达方式有哪些？1.伪代码 Pseudocode：是一种算法描述语言, 也称 PDL 语言 Program D

28、esign Language ；伪代码介于自然语言与编程语言之间,用伪代码描述的算法可以简洁用任何一种编程语言实现；伪代码表达算法必需结构清晰、代码简洁、可读性好；2.程序流程图：用图形符号表达算法,直观表达循环、分支等复杂结构,是喜闻乐见的 表现形式；3.盒图 N-S Nassi 和 Shneiderman：也是一种图形符号表达方式,同样可以表达各种流 向掌握,但比程序流程图紧凑、功能域明确；4.PAD 图PAD-Problem Analysis Diagram28：同样是用图形符号表达算法,但它具有结构化的表达方式,因此结构非常清晰,很简洁翻译成程序代码；PAD 支持自顶向下,逐步求精方法

29、的使用；判定表与判定树：对于规章较多,判定条件较复杂的情形,宜接受这两种方法表达；5.判定表与判定树：对于规章较多,判定条件较复杂的情形,宜接受这两种方法表达；30 简述面对数据流的结构化分析SA方法中,有哪些建模方法？功能建模 :数据流图 DFDData Flow Diagram+ 数据字典 DDData Dictionary ；数据建模 :实体关系图 行为建模 :状态转换图ERDEntity Relation Diagram ；STDState Transform Diagram ；加工说明 PESPECProcess SPECification和判定表等帮助工具；31 简述数据流图（ D

30、FD）的图形符号有哪些？数据流：表示数据流的名称和数据的流向从加工动身或流向加工；外部实体：系统外与系统交互的人或实体；数据加工：数据处理；数据储备：数据进行长久储存的环节；32 简述数据字典的作用、内容和组成元素有哪些？数据流图描述了数据加工,但没有描述数据的内容；数据流图必需与描述并组织数据条目的数据字典 DDData Dictionary 配套使用；数据字典描述的对象：描述数据流图中显现的全部数据和加工；这里的数据描述是概念11 名师归纳总结 - - - - - - -第 11 页,共 25 页精选学习资料 - - - - - - - - - 性的,属数据结构的抽象描述；加工接受加工小说

31、明进行概念性的描述；数据字典的组成元素包括：数据流条目、数据储备条目、数据项条目；加工条目也称为小说明 ；33 简述面对对象的基本概念有哪些？1对象与面对对象 对象（ Object ）：即表示客观世界中的某个具体的事物；面对对象（Object Oriented）：是人类的活动,是人类认知、观看客观事物的方法论；2面对对象的抽象与分类3类的封装与对象的整体性4关联性与交互性 客观事物都不是孤立存在的,万物之间相互依存、相互沟通；关联性表达客观事物的社会性、共存性、组织性,是静态的结构描述；消息机制是对象的交互性,表示对象生存环境的依靠性；5继承性对事物的分类本身就表达继承性；软件开发利用继承性可

32、对Object 更好地分类,软件结构更严谨,代码的复用性更强；6多态性 对象在不同的条件下,同样的行为会表现不同的成效,这就是 Object 的多态polymorphism ；面对对象编程语言供应抽象类、接口、重载等技术支持多态的实现；34 面对对象的五大特性有哪些？面对对象的特性有抽象性、封装性、继承性、多态性和消息机制等五大特性；35 简述面对对象开发过程的内容有哪些？ 需求猎取：开发者以OO 的观点 OOV 来观看客观世界的目标即猎取需求,然后用自然语言写到需求规格说明 OOS中,也就是对客观世界的最高层抽象； 面对对象分析 OOA Object Oriented Analysis 与面

33、对对象设计 OODObject Oriented Design ； 面对对象编程Object Oriented ProgramOOP 与面对对象测试Object Oriented Testing OOT 是代码实现过程,它依靠于编程语言和工具； 软件保护 Object Oriented Software MaintenanceOOSM ；12 名师归纳总结 - - - - - - -第 12 页,共 25 页精选学习资料 - - - - - - - - - 36 与传统的软件开发方法相比较,面对对象开发的主要优点有哪些？1自然性即客观性2操作数据对象而非数据实体3阶段连接平滑4结构性好、复用性

34、强5提高扩展性和保护性37 简述 UML 中定义了那些图形符号？并简述起作用；用例图 Use Case 描述系统参加者与领域问题的功能类图 Class 描述系统的规律结构,类、接口及它们的协作关系包图 Package 描述类的复用组织 分组对象图 Object 描述类的实例在某时刻的关系构件图 Component 描述系统按构件组成上的关系配置图 Deployment 描述系统运行环境的配置情形时序图 Sequence 描述某些对象共同合作完成某项功能而按时间次序进行的消息传递协作图 Collaboration描述某些对象共同合作完成某项功能的依靠关系活动图 Activity描述某个用例按大事

35、流转所经受的的活动,即业务流程状态图 State chart描述某个业务流程按大事流转所经受的状态,即状态机38 简述用例图中有哪些模型元素？并简述其含义？参加者： 指存在于系统外部并与该系统发生交互的人或其他系统,代表系统的使用者或使用环境；用例 Use Case ,用例用于表示系统供应的服务,它定义了系统是如何与参加者交互,描述了参加者与系统之间的交互过程；角色与用例间的关系关联,它表示参加者与系统中的哪些用例交互；用例之间的关系：包含 和扩充 关系以及泛化关系；参加者之间的泛化关系；13 名师归纳总结 - - - - - - -第 13 页,共 25 页精选学习资料 - - - - -

36、- - - - 39 简述类图中有哪些模型元素？并简述其含义？提示：一切可以显现在类图中的元素；类：类名、属性、方法（可见性、作用域）特别类：接口 类之间的关系的定义、表示和属性：关联、依靠、聚合、组合、泛化、实现；各种类关系之间的关系；40 简述包图中有哪些模型元素？并简述其含义？提示：一切可以显现在包图中的元素；包和包之间的关系；41 简述活动图中有哪些构成元素？并简述这些元素的含义？42 简述 OOA 模型的结构OOA 的核心任务是搞清用户需求,最终要建立起OOA 模型；UML 的 OOA 模型由“ 用例模型” 和“ 概念模型” 两大部分组成；用例模型,是将用自然语言描述的领域问题,转换

37、成 要面对用户,反映用户需求；UML 语言表达的模型,主完整的用例模型由用例图和业务场景描述两个部分组成,用例图表示功能的划分；业务场景描述就对每个用例的大事流进行描述；概念模型（类模型 /结构模型 /静态模型）；将用例模型映射成类模型：从用例模型中找出类,面对设计人员；主要工作是：依据用例图进行类的划分与封装；描述类间的静态关系与结构；用交 互图表达类对象间的消息传递；43 对象间的可拜访性 属性可见性： B 是 A 的一个属性（关联、聚合）； 参数可见性： B 的对象是 A 的一个方法的参数； 局部声明可见性：B 的对象是在A 的一个方法中声明的一个局部变量； 全局可见性： B 的对象在某

38、种程度上全局可见；14 名师归纳总结 - - - - - - -第 14 页,共 25 页精选学习资料 - - - - - - - - - 44 对象长久化 对象长久化常用技术实体类的实例称为数据对象,对象长久化主要用于数据对象的长久化,简称数据持久化；一个数据对象的长久化就是储存到实体表中的一条记录,作属性的值；对象长久化常用技术 对象的序列化对实体对象的拜访就是操指将对象的相关信息（对象序列号、属性名、属性值等）转换为字节流,然后再把字节流写入数据流；可以把对象这些信息储备在本地的文件里,也可以把它通过网络传输到远程；通过对象反序列化,得到原对象完全相同的副本； 对象长久化到数据库中数据库

39、可以是对象数据库或关系数据库； 用 XML （ eXtensible Markup Language ）储备；45 “实体模型” 到“ 关系模型” 的 OR 映射1 一个对象类可以映射为一个以上的库表,当类间有一对多的关系时 ,一个表也可以对应多个类；2 对象关系 一对一、一对多、多对多 的映射可能有多种情形,但一般映射为一个表或多个表, 在表间定义相应的主键 PK（Primary key ）和外键 FK（ Foreign key ）建立实体间的关系；3 单一继承的泛化关系可以对超类、子类分别映射表,也可以不定义父类表而让子类表拥有父类属性；反之,也可以不定义子类表而让父类表拥有全部子类属性；

40、4 对多重继承的超类和子类分别映射表,对多次多重继承的泛化关系也映射一个表；5 对映射后的库表进行冗余掌握调整46 软件测试的定义,使其达到合理的关系范式；软件测试是为了发觉错误而运行程序的过程；软件测试的目的是发觉程序中的错误,是为了证明程序有错, 而不是证明程序无错；测试对象不仅是程序,仍应当包括开发过程中产生的全部产品,包括文档,其目的是为了尽早地、尽可能多的发觉 并排除软件中潜在的错误；47 软件测试的基本原就 Who 来测试？测试工作应当由独立的、专业的软件测试机构来完成,设计人员和程序员要参加测试；对测15 名师归纳总结 - - - - - - -第 15 页,共 25 页精选学习

41、资料 - - - - - - - - - 试结果肯定要有一个确认的过程,一般由角色A 测试出来的错误,肯定要有一个角色B 来确认,严峻的错误可以召开评审会进行争论和分析； 测试 What？程序员交付的模块、系统和文档； 测试 Extent？设计测试用例,充分掩盖全部条件或全部语句即可； When 测试？尽早和不断的测试,即将这种“ 测试” 贯穿于软件开发的各个阶段,坚持各个阶段的技 术评审,以便尽早地发觉和预防错误； How 测试？设计测试用例时不仅要考虑到合法的输入,仍要考虑到不合法的输入以及各种边界条 件；对发觉错误较多的程序模块,应进行重点测试；48 软件缺陷,软件缺陷的属性：从产品内部

42、看, 缺陷是软件产品开发或保护过程中存在的错误、品外部看,缺陷是系统所需要实现的某种功能的失效或违反；软件缺陷的属性：毛病等各种问题； 从产缺陷标识、 缺陷类型、 缺陷严峻、 程度缺陷、 优先级、 缺陷状态、 缺陷起源、 缺陷来源、缺陷根源等；49 简述测试用例的概念测试用例（ Test Case） 是关于具体测试步骤的文档,以判定被测软件的工作是否正常；内容包括： 测试目标、 测试环境、 输入数据、 测试步骤、 预期结果等； 从表现形式上看,测试用例可以是纯文本的文档,也可以是用程序设计语言编写的一段代码；50 简述基本测试方法的分类情形测试方法分类内容静态测试走查 评审语句掩盖是最简洁、最弱掩盖； 它只掩盖可执行语句至少执行一语句掩盖动白逻判定掩盖次；判定掩盖又叫分支掩盖,是对每个判定式取真、假各一次, 使每辑态盒条件掩盖个判定的每个分支都至少执行一次,同时满意语句掩盖；条件掩盖是把程序中每个判定的每个条件为真和假各取值一次；覆测测盖试试条件掩盖深化到判定中的每个条件,但不肯定满意判定掩盖的要法求；判定 /条件掩盖能同时满意判定、条件两种掩盖