软工复习材料

软件工程复习材料第1页共8页2.1软件工程&软件过程概述什么是软件，软件的特点软件是在计算机系统支持下，能够完成特定功能和性能的程序、数据和相关的文档。（书本）软件是计算机程序、规程以及运行计算机系统可能需要的相关文档和数据。（课件）软件=知识+程序+数据+文档（书本）软件=程序+规程+数据+文档（课件）软件的特点：软件是抽象的逻辑产品，而不是物理产品。灵活性和不会磨损和老化。软件开发更依赖于开发人员的业务素质、智力、人员的组织、合作和管理。软件存在潜伏错误，硬件错误一般能排除。软件开发成后，只需对原版进行复制。软件在使用过程中维护复杂：（1）纠错性维护-改正运行期间发现的潜伏错误；(2)完善性维护-提高或完善软件的性能；（3）适应性维护-修改软件，以适应软硬件环境的变化；（4）预防性维护-改进软件未来的可维护性和可靠性。（5）软件不会磨损和老化。什么是软件危机，软件危机的表现软件危机是指在软件开发和维护中所遇到的一系列严重的问题。软件危机的表现对软件开发成本和进度的估计常常很不准确。用户对已完成的软件不满意的现象时有发生。软件产品的质量往往是靠不住的。软件常常是不可维护的。软件通常没有适当的文档资料。软件工程的定义、目标及原则定义是：1将系统化的、规范化的、可量化的的方法应用于软件的开发、运行和维护的过程；2对1中所述方法的研究目标：是在给定成本，进度的前提下，开发出满足用户或市场需求的高质量的软件产品。原则：抽象、信息隐藏、模块化、局部化、一致性、完全性和可验证性。软件质量要素产品转移：可移植性、可重用性、互操作性产品运行：正确性、可靠性、效率、完整性、实用性产品校正：可维护性、灵活性、可测试性8个质量要素：（1）正确性（2）可用性（3）可靠性（4）有效性（5）可维护性可移植性（7）安全性（8）可复用性人月神话(1)缺乏合理的时间进度是造成项目滞后的最主要原因，它比其他所有因素加起来影响还大。(2)良好的烹饪需要时间，某些任务无法在不损害结果的情况下加快速度。(3)所有的编程人员都是乐观主义者：“一切都将运作良好”。(4)由于编程人员通过纯粹的思维活动来开发，所以我们期待在实现过程中不会碰到困难。(5)但是，我们的构思是有缺陷的，因此总会有bug。(6)我们围绕成本核算的估计技术，混淆了工作量和项目进展。人月是危险和带有欺骗性的神话，因为它暗示人员数量和时间是可以相互替换的。(7)在若干人员中分解任务会引发额外的沟通工作量——培训和相互沟通。(8)关于进度安排，我的经验是为1/3计划、1/6编码、1/4构件测试以及1/4系统测试。(9)作为一个学科，我们缺乏数据估计。(10)因为我们对自己的估计技术不确定，所以在管理和客户的压力下，我们常常缺乏坚持的勇气。(11)Brook法则：向进度落后的项目中增加人手，只会使进度更加落后。(12)向软件项目中增派人手从三个方面增加了项目必要的总体工作量：任务重新分配本身和所造成的工作中断；培训新人员；额外的相互沟通。瀑布模型、快速原型、增量模型、螺旋模型、通用软件过程模型等软件过程模型的特点、适用范围瀑布模型的特点：1.阶段间具有顺序性和依赖性2推迟实现的观点3.质量保证的观点瀑布模型的缺点：1.各个阶段的划分完全固定，阶段之间产生大量的文档，极大地增加了工作量；2.开发过程中很难响应客户的变更要求；3.早期的错误可能要等到开发后期的测试阶段才能发现，进而带来严重的后果。瀑布模型的适用于：1.需求是预知的2软件实现方法是成熟的3项目周期较短4.在开发的早期阶段软件需求被完整确定。快速原型目的：尽早与用户见面，减少开发风险和需求不确定性。快速原型需要迅速建造一个可以运行的软件原型，以便理解和澄清问题，使开发人员与用户达成共识。原型是软件的一个早期可运行的版本，它反映了最终系统的部分重要特性。快速原型的缺点：1.原型系统的内部结构可能不好。2.开发人员需要掌握建立快速原型的开发技术和工具。快速原型的适用于：1.小型或中等规模的交互式系统。2.大型系统的某些部分，例如用户界面3.生命周期较短的系统。增量模型的特点：1.能在较短时间内向用户提交可完成部分工作的产品。2.逐步增加产品功能可以使用户有效充裕的时间学习和适应新产品，从而减少一恶搞全新的软件可能给用户组织带来的冲击。增量模型的优点：1.整个产品被分解成若干个构件逐步交付，用户可以不断地看到所开发软件的可运行中间版本。2.将早期增量作为原型有助于明确后期增量的需求3.降低开发风险4.重要功能被首先交付，从而使其得到最多的测试。增量模型的缺点：1.需要软件具备开发式的体系结构；2.需求难以在增量实现之前详细定义，因此增量与需求的准确映射以及所有增量的有效集成可能会比较困难。3.容易退化为边改方式，使软件过程的控制失去整体性。螺旋模型的优点：1.关注软件的重用；2.关注早期错误的消除3.将质量目标放在首位。4.边学习、边建模、边开发、边使用、边开进。螺旋模型的缺点：1.风险分析需要成本，影响收益，所以只适用于大规模软件项目；2.客户未必能接受，所以往往适应于内部的大规模软件开发；3.需要风险评估的经验，否则会带来更大风险。通用软件过程模型形式化方法模型是采用形式化的数学方法将系统描述转化成可执行的程序。形式化适用：特别适合于那些对安全性、可靠性和保密性要求极高的软件系统，这些系统需要在投入运行前进行验证。形式化优点:由于数学方法具有严密性和准确性，形式化方法开发过程所交付的软件系统具有较少的缺陷和较高的安全性形式化缺点：1.开发人员需要具备一定技能并经过特殊训练2.形式化描述和转换是一项费时费力的工作3.现实应用的系统大多数是交互性强的软件，但是这些系统难以用形式化方法进行描述。任务思维与过程思维思维过程包括分析、综合、比较、抽象、概括判断和推理等基本过程。RUP软件过程的基本特点、阶段划分、主要工作流RUP阶段划分：1.初始阶段2.细化阶段3.构造阶段4.移交阶段5.生产阶段主要工作流1.业务建模工作流2.需求工作流3.设计工作流4.实现工作流5.验证和确认（V&V）工作流6.部署工作流7.配置和变更管理工作流8.项目管理工作流9.环境工作流2.2SA&OO结构化分析方法的特点、数据流图作用对象、类、接口、封装、继承、多态、消息、关联、组合、聚合、依赖、实现对象是现实世界中个体或事物的抽象标识，是其属性和相关操作的封装。类是某些对象的共同特征（属性和操作）的标识。继承，类之间的继承关系是现实世界中遗传关系的直接模拟，它表示类之间的内在联系以及对属性和操作的共享，即子类可以沿用父类（被继承类）的某些特征。聚合部分与整体的关系。多态是指在父类及其子类中，对外接口的定义形式相同，却可以对应多种接口的实现形态。消息传递是对象与其外部世界相互关联的唯一途径。概念、用途、画法：用例图、类图、对象图、状态图、活动图、顺序图、协作图类的关系、用例的关系类的关系常见的关系有：继承（Inheritance），关联关系（Association），聚合关系（Aggregation），复合关系（Composition），依赖关系（Dependency）。用例的关系:包含关系:基本用例的行为包含了另一个用例的行为。2.3需求工程业务需求、用户需求、功能需求和非功能需求、系统需求的基本概念业务需求就是系统目标，它必须是业务导向、可度量、合理、可行的。就是说你做的东西，用户能做什么，对用户有什么帮助，他的价值用户需求：是从用户角度描述的系统功能需求和非功能需求，通常只涉及系统的外部行为，而不涉及系统的内部特性。用户需求的描述原则：应该易于用户的理解。一般不采用技术性很强的语言，而是采用自然语言和直观图形相结合的方式（用例图、用例描述、活动图、领域概念模型）进行描述。问题：自然语言表达容易含糊和不准确。系统需求：是更加详细地描述系统应该做什么，通常包括许多不同的分析模型。（用例图、交互图、分析类图、状态图）。系统需求主要是面向开发人员进行描述，是开发人员进行软件设计的基础。功能需求：描述系统应该提供的功能或服务，通常涉及用户或外部系统与该系统之间的交互，一般不考虑系统的实现细节。非功能需求：从各个角度对系统的约束和限制，反映了应用对软件系统质量和特性的额外要求，例如响应时间、数据精度、可靠性、开发过程的标准等。举例：（1）系统应在20秒之内响应所有的请求。（2）系统每周7天、每天24小时都可以使用。（3）对于一个没有经验的用户而言，经过两个小时的培训就可以使用系统的所有功能。需求工程的过程模型，每个环节的主要任务（1）需求工程策划（2）需求获取（3）需求分析（4）需求规范化（5）需求验证（6）总结需求获取的过程模型，每个环节的主要任务（1）定义软件问题（2）创建框架用例（3）精化用例（4）评审用例模型主要项目干系人的角色及作用需求调研的常见方法、优缺点、注意事项什么是用例，正确识别Actor及用例，用例识别的误区用例描述了一个完整的系统事件流程，其重点在于参与者与系统之间的交互而不是内在的系统活动，并对参与者产生有价值的可观测结果。用例分析以参与者为中心，用例粒度以完成参与者目的为依据。框架用例的作用业务用例：业务建模阶段，每个用例以能说明一件完整的事情，可以描述一项完整的业务流程。概念用例：概念建模阶段，每个用例一能描述一个完整的事件流为宜，可以描述一项完整业务中的一个步骤。系统用例：系统建模阶段，每个用例以能够描述操作者与计算机的一次完整交互为宜。一个系统的业务用例定义在多于10个，不超过30个之间。在同一个需求阶段，所有用例的粒度应该是同一量级的。粒度选择的问题本质上是因为边界认定不同而产生的。构建完整用例的步骤（1）重新研究用例名称、用例目标、标识所有执行者（2）标识触发条件和前置条件（3）描述或精化原有的基本交互动作序列（4）提炼并描述扩展的交互动作序列（5）描述用户与系统交互过程中传递的信息项（6）标识后置条件可行性分析的主要关注点需求分析的过程模型,每个环节的主要任务(1)需求优先级分析为每项需求确定优先级（功能性需求，非功能需求）安排待分析用例的优先次序据此编排调整软件开发计划对重要、紧迫的需求（给予更多关注，分配更多的开发资源，确保其优先实现，确保实现质量）(2)用例分析不断加深理解用例模型，更深入理解软件需求用更精确uml语言表述需求（删除需求的模糊性，检查需求的一致性，消除需求的冗余性）引入用例功能的逻辑设计方案（检查需求的可实现性，识别需求的实现风险，提高需求的可验证性）(3)构建快速原型纠结的问题（自然语言可能存在的模糊性、不一致性。UML语言用户理解可能有难度，用户说不出心中所想，开发人员解释不清系统模样）(4)分析模型评审评审用例模型（正确性、完全性、可行性）需求优先级概念什么是分析模型，分析模型的作用领域概念模型精化领域概念模型的方法：需求获取，领域模型，用例描述，术语词典。领域概念模型：发现表象下的本源，找出最基本的对象及相互间关系，描绘出它们如何交互而形成要分析的问题领域。领域就是分析问题时将整体分解以后的相对独立的部分。针对项目成败影响最为关键的部分建模（针对核心业务建模，适用二八原则。针对系统难点建模，关注非功能性需求，特殊应用环境，客户特殊要求。）建立领域概念模型必须首先标识关键概念，来源包括：需求描述与用例说明，业务领域中的相关规范、标准和术语定义，反映业务领域知识的既往经验。UML类图是表示领域概念模型的适当机制。边界类、实体类、控制类的概念，如何识别边界类、实体类、控制类边界类：描述外部的参与者与系统之间的交互。控制类：描述一个用例所具有的事件流控制行为。实体类：描述必须存贮的信息及其相关行为。识别边界类应当注意的问题:边界类应关注于参与者与用例之间交互的信息或者相应的事件，不要描述窗口组件等界面的组成元素。在分析阶段，力求使用用户的术语描述界面。边界类实例的生命周期并不仅限于用例的事件流，如果两个用例同时与一个参与者交互，那么它们有可能会公用一个边界类（如听课，听音乐），以便增加边界类的复用性。识别控制类当用例比较复杂时，特别是产生分支事件流的情况下（一个用例可以有多个控制类，每个类负责用例的某项子功能）在某些情况下，用例事件流的逻辑结构十分简单，这是没有必要使用控制类，边界类可以实现用例的行为。如果不同用例包含的任务间存在着比较密切的联系，则这些用例可以使用一个控制类，其目的是复用相似部分以便降低复杂性。通常情况下，应该按照一个用例对应一个控制类的方法识别出多个控制类，再分析这些控制类找出它们之间的共同之处。识别实体类实体类通常是用例中的参与对象，对应着现实世界中的“事物”需要开发人员进一步理解应用领域来源于用例描述、词汇表、领域概念模型是具有持久意义的信息项软件需求规格说明的内容、作用。需求验证的作用、要点需求变化的理解、需求变更控制过程2.4软件设计软件设计基本原则：抽象与逐步求精、模块化、信息隐藏、关注点分离耦合度和内聚性的概念耦合度：表示两个子系统（或类之间的关联程度）内聚性：是子系统内部的相关程度耦合：表示两个子系统（或类）之间的关联程度。当一个子系统（或类）发生变化时对另一个子系统（或类）的影响很小，则称它们是松散耦合的；反之，如果变化的影响很大时，则称它们是紧密耦合的。块间联系的大小可从三个方面衡量（方式、作用、数据）耦合性几种类型（内容耦合、公共耦合、控制耦合、复合耦合、数据耦合）内聚内聚性：是子系统内部的相关程度。高内聚：子系统中彼此相关的多个对象执行类似的任务。低内聚：子系统内的多个对象彼此不相关时。高内聚的方法：做且仅做一件事，这会很容易理解与维护。高内聚的类：表示且仅表示一种类型的对象。偶然型，逻辑型，瞬时型，通信型，顺序型，功能型（内聚性弱到强）软件设计的过程模型、每个环节的主要任务单一职责、开闭原则、里氏互换、依赖反转、接口隔离、迪米特法则单一职责：可以看做是低耦合、高内聚在面向对象原则上的引申里氏互换：任何基类出现的地方，子类一定可以出现软件体系结构定义软件体系结构主要包括哪些视图，每种视图的作用逻辑视图、开发视图、物理视图、运行视图、数据视图。包的划分原则、包的依赖及消除软件构件的概念体系结构设计的过程模型、每个环节的主要任务3简答题（35分）3.1软件工程&软件过程概述关于人月神话的一些思考。掌握常见几种软件生命周期的特点、适用范围；能够针对给定的一些软件项目，选择相应的生命周期模型，并简要陈述理由。辩证看待程序语言、开发工具、编程技巧以及软件工程方法在成功进行软件开发中所起的作用。麦当劳薯条生产的思考。3.2软件需求关于李大嘴做月饼的思考。理解软件需求的质量：正确性、无二义性、完整性、可验证性、一致性、可修改性、可跟踪性；能够针对给定的需求陈述语句，判断需求描述是否满足质量要求。能够识别错误的用例描述，并予以改正。能够识别给定用例图的错误。理解软件需求在软件开发中的重要作用。理解软件开发中需求管理困难的原因。理解软件需求确认的内涵及作用。理解软件需求变更控制的基本策略。需求工程的过程模型中主要包括哪些设计活动？3.3软件设计能够识别类之间的关系并予绘制。如何消除包的依赖关系理解软件结构的形态要求软件设计的过程模型中主要包括哪些设计活动？软件分析设计的思想原则用户需求远比技术重要需求其实很少改变，改变的是对需求的理解接受变化不要低估软件规模的需求在软件设计中没有捷径可以走任何设计模式、体系结构都有优缺点沟通对设计质量的的提高同样重