软件工程考试复习(参考).doc

一、考试题型及分值分布（1）单选题（20题，每题2分，共40分）（2）判断题（10题，每题1分，共10分）（3）简答题（6题，每题5分，共30分）（4）应用题（1题，20分）二、复习范围（1）软件危机及产生的原因软件危机指在计算机软件的开发和维护过程中所遇到的一系列严重问题。这些问题绝不仅仅是不能正常运行的软件才具有的，实际上，几乎所有软件都不同程度地存在这些问题。-如何开发、如何维护软件。产生的原因与软件本身的特点有关非常复杂成本高风险大维护困难（2） 软件工程是一种层次化技术，其主要包括哪些内容？ 软件工程是一种层次化的技术方法：提供了建造软件在技术上需要“如何做”。涵盖一系列的任务：需求分析、设计、编程、测试和维护。 工具：对过程和方法提供了自动的或半自动的支持。工具被集成起来 ，形成计算机辅助软件工程(CASE) （3） 通用的软件过程框架包括哪些活动？沟通：包含了涉众之间大量的交流和协作，还包括需求获取以及其他相关活动。策划：指为后续的软件工程工作制定计划。它描述了需要执行的技术任务、可能的风险、资源需求、工作产品和工作进度计划。建模：包括创建模型和设计两方面。创建模型有助于客户和开发人员更好地理解软件需求，设计可以实现需求。构建：包括编码和测试。部署：软件(全部或者完成的部分)交付到用户，用户对其进行评测并给出反馈意见。典型的普适性活动软件项目跟踪和控制：由项目组根据计划来评估项目进度，并采取必要的措施保证项目按计划进行风险管理：对可能影响项目成果或产品质量的风险进行评估。软件质量保证：确定和执行用以保证软件质量的活动。正式的技术复审：评估软件工程产品，尽量在错误传播到下一个动作或活动之前发现并清除错误。测量：定义和收集过程、项目和产品的度量，以帮助团队在发布软件的时候满足客户要求。软件配置管理：管理整个软件过程中变更所带来的影响。可复用管理：定义产品复用的标准(包括软件构件)，并且建立构件复用机制。工作产品的准备和产生：包括了创建产品所必需的活动，如建模、文档、日志、表格和列表等。（4） 各种软件过程模型的特点及适用的场景？1） 瀑布模型特点：结构化，有序；适用于传统软件工程领域的结构化开发。2） 螺旋过程模型特点：它结合了原型的迭代性质和瀑布模型的系统性和可控性，螺旋模型可应用在计算机软件的整个生命周期，螺旋模型是开发大型系统和软件的理想方法，螺旋模型把原型开发作为降低风险的机制；适用于庞大、复杂并具有高风险的系统。3） 原型过程模型特点：原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发；快速原型法是在需求不明确的情况下常用的一种方法。（5） UP的三大特点及其五个阶段。1） a.用例驱动 b.以体系架构为核心 c.迭代并且增量2) UP包括起始阶段，细化阶段，构建阶段，转化阶段，生产阶段。 起始阶段 ：包括用户沟通和计划活动两个方面，强调定义和细化用例，并将其作为主要模型。 细化阶段 ：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示。 构建阶段:将设计转化为实现，并进行集成和测试。 移交阶段 ：将产品发布给用户进行测试评价，并收集用户的意见，之后再次进行迭代修改产品使之完善。（6） 分析模型的建模目的是什么？分析模型主要包括哪四大类元素？ 分析模型的目的是为基于计算机的系统提供必要的信息、功能和行为域的说明。模型应该能够动态改造，以便于软件工程师更多地了解将要实现的系统，以便于共利益者更多地了解他们到底需要什么。1）基于场景的建模：使用基于场景的方法可以从客户的视角描述系统。如最基本的用例图。同样，它们可以作为创建其他建模元素时的输入。 2）基于类的建模：每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象，这些对象被分成类具有相似属性和共同行为的事物集合。3）基于行为的建模： 需求分析模型必须提供描述行为的建模元素，就是uml中的状态图。状态图是一种表现系统行为的方法，该方法描述系统状态以及导致系统状态改变的事件。状态时任何可以观察到的行为模式。4）面向信息流的建模：信息在基于计算机的系统中流动时会被转换，系统接受多种形式的输入，使用函数输入，生成多种形式的输出。 （7） 面向对象分析方法和结构化分析方法各自特点及他们使用了哪些技术？（8）软件设计的原则有哪些？(1)可靠性用软件系统规模越做越大越复杂，其可靠性越来越难保证。应用本身对系统运行的可靠性要求越来越高，软件系统的可靠性也直接关系到设计自身的声誉和生存发展竞争能力。软件可靠性意味着该软件在测试运行过程中避免可能发生故障的能力，且一旦发生故障后，具有解脱和排除故障的能力。软件可靠性和硬件可靠性本质区别在于：后者为物理机理的衰变和老化所致，而前者是由于设计和实现的错误所致。故软件的可靠性必须在设计阶段就确定，在生产和测试阶段再考虑就困难了。(2)健壮性健壮性又称鲁棒性，是指软件对于规范要求以外的输入能够判断出这个输入不符合规范要求，并能有合理的处理方式。软件健壮性是一个比较模糊的概念，但是却是非常重要的软件外部量度标准。软件设计的健壮与否直接反应了分析设计和编码人员的水平。(3)可修改性要求以科学的方法设计软件，使之有良好的结构和完备的文档，系统性能易于调整。(4)容易理解软件的可理解性是其可靠性和可修改性的前提。它并不仅仅是文档清晰可读的问题，更要求软件本身具有简单明了的结构。这在很大程度上取决于设计者的洞察力和创造性，以及对设计对象掌握得透彻程度，当然它还依赖于设计工具和方法的适当运用。(5)程序简便(6)可测试性可测试性就是设计一个适当的数据集合，用来测试所建立的系统，并保证系统得到全面的检验。(7)效率性软件的效率性一般用程序的执行时间和所占用的内存容量来度量。在达到原理要求功能指标的前提下，程序运行所需时间愈短和占用存储容量愈小，则效率愈高。（8）标准化原则在结构上实现开放，基于业界开放式标准，符合国家和信息产业部的规范。（9）先进性满足客户需求，系统性能可靠，易于维护。（10）可扩展性软件设计完要留有升级接口和升级空间。对扩展开放，对修改关闭。（9）软件体系结构风格 体系结构风格 定义了一个系统家族，其包括一个词汇表和一组约束。 一个词汇表包含一些构件和连接件类型， 一组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格 反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个模块和子系统有效地组织成一个完整的系统。 对体系结构风格的研究和实践为大粒度的软件复用提供了可能。 数据流风格 典型的体系结构风格 管道/过滤器风格 调用返回风格 仓库风格数据流风格 特点：当输入数据经过一系列的计算和操作构件的变换形成输出数 据时，可以应用这种体系结构。 管道/过滤器、批处理序列属于数据流风格。（2）管道/过滤器风格 拥有一组过滤器构件，这些构件通过管道连接管道将数据从一个构件传 送到下一个构件。 每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某 种形式的数据输入，并且产生某种特定形式的数据输出。 如果数据流退化成为单线的变换，则称为批处理序列。这种结构接收一 批数据，然后应用一系列连续的构件（过滤器）变换它。调用-返回风格 在此类体系结构中，存在以下3种子风格。 主程序/子程序风格 分层风格在这种体系结构中，整个系统被组织成一个分层结构，每一层为上层提供服务，并作为下一层的客户。面向对象风格 I.系统的构件封装了数据和必须应用到该数据上的操作，构件间通过消息传递进行通信与合作。 II与主程序/子程序的体系结构相比，面向对象风格中的对象交互会复杂一些。 III面向对象风格与网络应用的需求在分布性、自治性、协作性、演化性等方面具有内在的一致性。仓库风格 数据仓库（如文件或数据库）位于体系结构的中心，其他构件经常访问该数据仓库，并对仓库中的数据进行增加、修改或删除操作。 数据库系统、超文本系统和黑板系统都属于仓库风格。 仓库风格：中心存储库变换成“黑板”，黑板构件负责协调信息在客户间的传递，当用户感兴趣的数据发生变化时，它将通知客户软件。黑板系统的传统应用是信号处理领域，如语音和模式识别。另一应用是松耦合代理数据共享存取。（10） 软件测试的目的是什么？有哪些测试策略？测试目的：为了发现软件设计和实现过程中的疏忽所造成的错误。传统的测试策略：单元测试是针对程序中的模块或构件，主要揭露编码阶段产生的错误。集成测试针对集成的软件系统，主要揭露设计阶段产生的错误。确认测试是根据软件需求规约对集成的软件进行确认，主要揭露不符合需求规约的错误。系统测试是针对基于计算机系统中的软件，以揭露不符合系统工程中对软件要求的错误。（11）自顶向下和自底向上两种集成测试方法的优缺点。1）自顶向下集成的优点： 不需要驱动模块；能尽早对程序的主要控制和决策机制进行检验，能较早发现整体性的错误；深度优先的自顶向下集成能较早对某些完整的程序功能进行验证。 自顶向下集成的缺点： 测试时低层模块用桩模块替代，不能反映真实情况；重要数据不能及时回送到上层模块。2）自底向上集成的优点： 不需要桩模块，所以容易组织测试；将整个程序结构分解成若干个簇，对同一层次的簇可并行进行测试，可提高效率。 自底向上集成的缺点： 整体性的错误发现得较晚。(12) 测试、测试测试和测试如果软件是为一个客户开发的，那么，最后由客户进行验收测试（acceptance test），以使客户确认该软件是他所需要的。如果软件是给许多客户使用的（如市场上销售的各种软件），那么让每个客户做验收测试是不现实的。大多数软件厂商都使用一种称为测试和测试的过程，来发现那些似乎只有最终用户才能发现的错误。测试是由用户在开发者的场所进行的，软件在开发者对用户的“指导下”进行测试。经测试后的软件称为版软件。测试是由软件的最终用户在一个或多个用户场所进行的，与测试不同，开发者通常不在测试现场。测试是软件在开发者不能控制的环境中的“活的”应用用户记录所有在测试中遇到的（真正的或想象的）问题，并定期把这些问题报告给开发者，接到测试的问题报告后，开发者对软件进行最后的修改，然后着手准备向所有的用户发布最终的软件产品。（13） 白盒测试和黑盒测试的基本概念白盒测试（又称为结构测试）把测试对象看作一个透明的盒子测试人员根据程序内部的逻辑结构及有关信息设计测试用例检查程序中所有逻辑路径是否都按预定的要求正确地工作。黑盒测试（又称行为测试）把测试对象看做一个黑盒子测试人员完全不考虑程序内部的逻辑结构和内部特性只依据程序的需求规格说明书，检查程序的功能是否符合它的功能需求。（14）给出需求，能绘制出用例图和设计类图1.各种过程模型的区别和联系 瀑布模型： 1 特点： 结构化，有序 2 过程：沟通 策划 建模 构建 部署 演化过程模型： 1.特点：迭代的过程模型 （1）原型过程模型（可作为一个独立的过程模型。更多时候作为一种技 原型模型的主要思想：先借用已有系统作为原型模型，通过“样品”不断改进， 使得最后的产品就是用户所需要的。 原型模型通过向用户提供原型获取用户的反馈，使开发出的软件能够真正 反映用户的需求。同时，原型模型采用逐步求精的方法完善原型，使得原型能够“快速”开发，避免了像瀑布模型一样在冗长的开发过程中难以对用户的反馈作出快速的响应。相对瀑布模型而言，原型模型更符合人们开发软件的习惯，使目前较流行的一种实用软件生存期模型。 （2）螺旋过程模型 特点：它结合了原型的迭代性质和瀑布模型的系统性和可控性。 优点：螺旋模型强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解，继而做出应有的反应，因此特别适用于庞大、复杂并具有高风险的系统。 自身特点：1、采用循环的方式逐步加深系统的定义和实践的深度，同 时降低风险。 2、确定一系列里程碑。确保共利益者都支持可行的和令人满意的系统解决方案。联系：（1）原型模型是在瀑布模型的基础上进行完善的过程模型，瀑布模型是线性的，有序的；但是原型模型就让瀑布模型形成了一个环，有迭代的特点。 （2）螺旋过程模型，它结合了原型的迭代性质和瀑布模型的系统性和可控性。 （图表见下页）2 什么是统一过程模型？特点： 用例驱动 功能描述 以架构为核心 软件结构的蓝图 迭代并且增量 起始 细化 构建 移交瀑布模型（经典生命周期）原型过程模型惯用过程模型演化过程模型螺旋模型过程模型统一过程模型敏捷过程模型思考：为什么迭代过程更容易管理变更？ 如何建立能解决不可预测的过程？答案在于过程（对于飞快变化的项目和技术条件）的可适应性。 原地踏步式的连续适应性变化收效甚微，因此敏捷软件过程必须增量地适应。为了达到这一目的，团队则需要客户的反馈（以做出正确的适应性改变），可执行原型或部分实现的可运行系统是客户反馈的最有效媒介。因此，应当使用增量式开发策略，必须在很短的时间间隔内交付软件增量（可执行原型或部分实现的可运行系统）来适应（不可预测的）变更步伐。这种迭代的方法使客户能够：周期性地评价软件增量，向软件项目组提出必要的反馈，影响能够接受反馈的过程适应性变更。 迭代模型的一个重要特性即是支持项目的并行开发。从整个项目周期的角度，是通过各次迭代过程时间上的重叠来实现的，例如将多个产品化迭代与多个构建迭代的后续迭代重叠，以分别向用户交付迭代演进版本；而在迭代过程之中，则可以通过任务的逻辑划分来做到。然而，这需要满足很多的条件，比如设计优良、健壮的体系架构，才使得将产品的功能需求分配到不同构建迭代过程中完成变得现实可行；又如只有层次分明、接口稳定的模块设计，才可能真正实现各模块的并行开发，虽然现在强大的软件配置管理工具可以从技术层面支持团队协同开发，但仍解决不了并行开发的根本问题。实际上迭代模型是典型的以体系架构为中心的开发方法，没有健壮的体系架构，迭代最终只能退化成多次小瀑布模型过程的循环，真的成了“增量就是打补丁,迭代就是推倒重来”.迭代模型的开发流程： 根据软件开发计划，修正与细化各次迭代的具体目标与工作范围（如须解决的风险，将实现的需求项等），针对迭代目标，组织与裁减核心开发流程（包括业务分析、需求开发、分析设计、编码实现、测试、发布与部署等），策划具体的活动内容与任务，安排人力、物力资源的分配，设定具体的时间表等等。优点比较：与大粒度、不够精细的软件开发计划不同，迭代计划关注的时间短、策划的依据比较确定，由此对迭代过程采取时间框管理。与里程碑控制不同，它以保证计划进度为首要目标，主要通过裁减迭代的任务范围，比如将任务推后到下次迭代，来跟上进度期限（增加人力的方式须谨慎考虑）。本次迭代的执行结果，往往成为调整项目估计和策划下次迭代的经验参照和依据，使得下次迭代计划更为精细与切实可行。思考 1.在分析建模的过程中有哪3个域需要考虑？ 功能域 信息域 行为域 2.在软件工程中，为什么模型是很重要的？ 作为软件工程师，每天的工作都离不开模型，会用模型来辅助理解整个项目大的构想体系结构、不同的构件如何结合，以及其他一些特征。当然，也可以把模型不断细化，以便更好地理解软件需求并完成符合这些需求的软件设计。思考：简述需求工程的7项任务 需求工程的7项任务：起始 、导出、精化、协商、规格说明、确认和管理。 （PS：某些需求工程的任务并行发生且要全部适应项目的要求） 起始 发现价值 项目范围（粗粒度）当确定了商业要求或是发现了潜在新市场、新服务时才开始的。业务领域的共利益者定义业务用例，确定市场的宽度和深度，进行初略的可行性分析，并确定项目范围的工作说明。所有的这些信息都取决于变更，但是应该充分地与软件开发组及时讨论。 在项目起始阶段中，要建立基本的理解，包括对问题、谁需要解决方案、所需要解决方案的性质，与姜木利益相关者的和开发人员之间达成初步交流合作的效果。 导出（需求获取/诱导） 对于需求的获取也就是导出是十分困难的。从三个方面可以理解导出的困难之处。 范围问题 系统的边界不清楚，或是客户或用户的说明带有不必要额技术细节，这些细节可能会到时混淆而不是澄清系统的整体目标。 理解问题 客户和用户不能完全确定需要什么，对问题域没有完整的认识，与开发人员存在沟通的问题，省略那些他们认为是“明显的”信息。确定的需求和其他用户需求相冲突，需求说明有歧义或不可测试。 易变问题 需求会随时间不断变化 精化（构建分析模型） 在起始和导出阶段获得的信息会在精化阶段进行扩展和提炼。改任务集中于开发一个精确的分析模型，用以说明软件的三个方面：信息，功能和行为。 协商（协调需求冲突） 只给定了有限的业务资源，而客户和用户提出了过高的要求，只是常有的事。另一个相当常见的现象是，不同的客户或用户提出了相互冲突的需求。需求工程师必须通过协商过程来调节这些冲突。应该让客户、用户、和其他共利益者对各自的需求排序，然后按优先级讨论冲突，使用迭代的方法给需求排序，评估每项需求对项目产生的成本和风险，表述内部冲突。删除、组合或修改需求，以便参与各方面均能达到一定的满意度。规格说明 在基于计算机的系统的环境下，术语规格说明对不同的人有不同的含义。一个规格说明可以是一份文档，一套图形化的模型，一个形式化的数学模型，一组使用场景，一个原型或上诉各项的任意组合。确认（评审SRS） 在确认这一步将对需求工程的工作产品进行质量评估。需求确认要检查规格说明以保证：已无歧义地说明了所有系统需求；已检测出不一致、疏忽和错误并得以纠正；工作产品符合为过程、项目、和产品建立的标准。需求管理 基于计算机的系统其需求会变更，而且变更的要求贯穿于系统的整个生存期。需求管理是用于帮助开发人员在项目进展中标识、控制和跟踪需求以及需求变更的一组活动。 思考：需求模型每类元素对模型的贡献，每类元素为什么是唯一的，以及每个元素所表现的信息。 需求模型的元素有3类：（1） 基于场景的元素；（UML中的用例图） 使用基于场景的方法可以从客户的视角描述系统。如最基本的用例图。 同样，它们可以作为创建其他建模元素时的输入。 贡献： 需求模型基于场景的元素通常是正在开发模型的第一部分。 明白软件所需功能和功能之间的交互。 （2）基于类的元素；（UML中的类图） 每个使用场景都暗示着当一个参与者和系统交互时所操作的一组对象 这些对象被分成类具有相似属性和共同行为的事物集合。 贡献： 类图用于对系统静态设计视图的建模，涉及到对系统的词汇、协作、 模式的建模。在UML中，类图显示了一组类、接口、协作以及它们之间 的关系。在UML的静态机制中类图是一个重点，它不但为设计人员所关心， 更为实现人员所关注。 （3）行为元素；（UML中的状态图） 需求分析模型必须提供描述行为的建模元素，就是uml中的状态图。 状态图是一种表现系统行为的方法，该方法描述系统状态以及导致系统状 态改变的事件。状态时任何可以观察到的行为模式。 贡献： 1、描述一个操作的执行过程中所完成的工作或者动作 2、描述对象内部的工作 3、描述用例的执行 4、处理多线程 5、显示如何执行一组相关的动作，以及这些动作如何影响周围对象需求模型的3类元素分别对应了软件工程的3个方面：基于场景的元素功能域基于类的元素信息域行为元素行为域所以每类元素都是唯一的。思考：基于用例、类、行为模型的区别 一、基于用例的建模 （1）新建初试用例 （先画用例图） 两个首要的需求工程工作是起始和导出，它们提供了开始编写用例 所需要的信息，确定共利益者，定义问题的范围，说明整体的运行目建 立优先级顺序，概述所有已知的功能需求。 开始开发用例时，应该列出特定参与者执行的功能或活动。这些可 以从所需的系统功能的列表通过与共利益者交流等方式而获得。 1.定义术语表 每个业务领域都具有它本身独一无二的词汇，需求分析的目的就 是理解和定义这些词汇。词汇应该被项目相关人所理解。术语表必须 解决同音异义和同义异音问题。 2.标识参与者 首先，需要标识业务参与者。参与者是在业务中扮演某个角色的 人、部门或者独立的软件系统。一般来说，参与者使用系统或给系 统提供服务。 与现实生活一样，参与者可以在不同的时刻，扮演不同的业务角 色。例如，小刘在Nowhere Cars商店上班时，他是一个助手；如果他 在回家之前要租用一辆汽车，就成为一个顾客。 3. 标识系统用例 一旦有了参与者，就可以从参与者的角度看系统,问系统能给参与 者提供哪些服务?通过一问一答,就可以查找用例。 （2）细化初始用例 为全面理解用例描述功能，对于交互操作给出另外的描述是非常必要 的。就是进行用例规约，写出用例描述。如：表一User Case:0101注册用户角色：游客前置事件：游客未登录基本事件流:1.显示注册页面，Register.jsp2填写注册信息 2.1用户名 必填 长度小于10 2.2密码 两次密码需相同 必填 长度小于16 2.3qq号码 选填 长度小于16 2.4E-mail 格式需正确 必填 长度小于503.信息输入正确，点击提交4.显示注册成功界面,RegisterSuccess.jsp 信息有误详述注册失败界面,RegisterFailure.jsp后置条件: 注册成功可选事件流1：后置条件1: 可选事件流2：后置条件2: 表一 （3）编写正规用例 最后，结合以上2步骤，分析整合处理，完成最终的用例建模。2、 基于类的建模 （一） 寻找分析类 我们以问题陈述为输入信息，采用“名词动词法”寻找分析类。名词 动词法的主要规则是从名词与名词短语中提取对象与属性；从动词与动词 短语中提取操作和关联。 1找备选类 首先。可以逐字逐句地阅读上面那段需求描述,并将其中的所有的名词 及名词短语列出来，可以得到备选类列表。 2从备选类中筛选出候选类 并不是所有的备选类都是适合候选类，有些名词对于要开发的系统来 说无关紧要。甚至不属于系统；而有些名词表述的概念则相对较小，适 合某个候选类的属性。因此，需要对备选类进行一番筛选，将这些不适 合的排除掉。 （二）确定类关系 通过上面的工作，从需求描述中找到了6个相关的类，接下来就是确 定类之间的关系。 1确定类关系 为了反映和记录这些类之间的关系，可以使用UML中的类图将其记录 下来。 2.给关联添加属性 （1）确定关联的多重性 基于以上的分析可以得到类图。 如果系统较大，可以以上面的类图为基础，把关联度紧密的类合 成一个包，以便更好的组织子系统。 （2） 确定关联的导航性 类图中的诸如导航性，角色名，导出属性，限定符及约束等高级 属性不是每个类模型都必须加入的。 (3) 确定约束 (4) 确定关联的限定符 3给类添加职责 当找到了反应问题域本质的主要类，并清理他们之间的关系之后，就 可以为这些类添加相应的职责。类的职责包括以下两个内容：类所维护的 信息(成员变量)和类提供的行为(成员方法)。 在本阶段将主要的成员变量和成员方法标识出来，以便更好的理解问题域。三 行为建模 行为建模，就是uml中的状态图。状态图是一种表现系统行为的方法， 该方法描述系统状态以及导致系统状态改变的事件。状态时任何可以观察到的 行为模式。 （一）理解系统内的变更 （二）识别事件 （三）为每个用例生成序列区别： 基于用例模型：描述角色以及角色与用例之间的连接关系。说明的是谁要使用 系统，以及他们使用该系统可以做些什么。一个用例图包含了多个模型元素，如系统、参与者和用例，并且显示了这些元素之间的各种关系，如泛化、关联和依赖。 用例模型描述一组用例、参与者以及它们之间的关系，其展示的是该系统在它的外面环境中所提供的外部可见服务。 基于类的模型：是描述系统中的类，以及各个类之间的关系的静态视图。能够让我们在正确编写代码以前对系统有一个全面的认识。类图是一种模型类型，确切的说，是一种静态模型类型。类模型描述一组对象、接口、协作等事物之间的关系 行为模型：描述类的对象所有可能的状态，以及事件发生时状态的转移条件。可以捕获对象、子系统和系统的生命周期。他们可以告知一个对象可以拥有的状态，并且事件(如 消息的接收、时间的流逝、错误、条件变为真等)会怎么随着时间的推移来影响这些状态。一个状态图应该连接到所有具有清晰的可标识状态和复杂行为的类；该图 可以确定类的行为，以及该行为如何根据当前的状态变化，也可以展示哪些事件将会改变类的对象的状态。状态模型是对类模型的补充。状态模型展示了一个状态机，由状态、转换、事件和活动组成。强调事件行为的顺序。一：这3种模型各有侧重1:用例图侧重描述用户需求，2:类图侧重描述系统具体实现；二：描述的方面都不相同1:类图描述的是系统的结构，2:状态图描述的是系统的行为；在有的文献书籍中，将这3种模型分为三类：结构分类、动态行为和模型管理：1：结构分类包括用例图、类图，2：动态行为包括状态图，3：模型管理则包含类图。思考：简要说明结构化分析和面向对象分析的主要区别一结构化分析 结构化分析是以数据流图为工具，实现对问题空间即需求的描述。它主要以数据流、数据变换为考虑对象，从这个角度来描述整个系统的状况。通过数据流图为蓝本对系统的功能加以分解，一直到最小的功能元素单元，然后开发人员据此进行程序设计。 结构化分析强调的是开发方法的结构和理性，它的本质是功能分解，从代表目标系统整体功能的单个处理着手，自顶向下不断地把复杂的处理分解为子处理，这样一层一层地分解下去，直到仅剩下的若干个容易实现的子处理为止。当所分解的子处理十分简单时，就可以写出各个最底层处理的处理描述。但随着软件工程的发展，接过话分析与设计方法表现出以下弊端： （1）结构化分析是围绕现实处理功能的过程来构造系统的。然而，用户需要的变化大部分是针对功能的，因此，用结构化方法分析设计出的系统结构常常不稳定。 （2）结构化分析定了了目标系统的边界，且开发系统的结构依赖于对系统边界的定义因此，很难把系统扩展到新的边界，系统难修改和扩充。 （3）结构化分析系统时，几乎每开发一个新的软件系统都要针对具体系统做大量重复和复杂的工作，代码重用性差。二面向对象的分析（OOA） 1）问题领域分析（标识对象） 分析领域的业务范围、业务规则和业务处理过程，确定系统的责任、范围和边界，确定系统的需求、在分析中需要着重对系统与外部的用户和其他系统的交互进行分析。确定交互的内容、步骤和顺序。 2）发现和定义对象、类（标识结构） 识别对象和类，确定它们的内部特征：属性与服务操作。这是一个从现实世界到概念模型的抽象过程，是认识从特殊到一般的上升过程。 3）识别对象的外部联系（标识主题） 在识别和定义对象与类的过程中，需要同时识别对象与对象、类与类之间的各种外部联系，包括结构性的静态联系和行为性的动态联系，包括特殊与一般、整体与部分、实例连接、消息链接等联系。 4）建立系统的静态结构模型（定义属性） 根据系统的静态结构，建立系统的静态结构模型，并且把它们用图形和文字说明表达出来。这主要是在前面对于类和对象、及其联系的分析基础上，绘制对象类图和对象图、系统与子系统结构图等，编制相应的说明文档。 5）建立系统的动态行为模型（定义方法） 分析系统的行为，建立系统的动态行为模型，并且把它们用图形和文字说明表达出来，如绘制交互图、状态图等，编制相应的说明文档。三结构化方法（面向过程）和面向对象方法的区别（1）处理问题时的出发点不同 结构化方法强调过程抽象化和模块化，以过程为中心； 面向对象方法强调把问题域直接映射到对象及对象之间的接口上，用符合人们通常思维方式来处理客观世界的问题。（2）处理问题的基本单位和层次逻辑关系不同 结构化方法把客观世界的问题抽象成计算机可以处理的过程，处理问题的基本单位是能够表达过程的功能模块，用模块的层次结构概括模块或模块间的关系和功能； 面向对象方法是用计算机逻辑来模拟客观世界中的物理存在，以对象的集合类作为处理问题的基本单位，尽可能使计算机世界向客观世界靠拢，它用类的层次结构来体现类之间的继承和发展。（3）数据处理方式与控制程序方式不同 结构化方法是直接通过数据流来驱动，各个模块程序之间存在着控制与被控制的关系； 面向对象方法是通过用例（业务）来驱动，是以人为本的方法，站在客户的角度去考虑问题。思考：简述设计模型，以及分析模型和设计模型的联系设计模型分为：数据或类的设计 体系结构设计 接口设计 构件级设计 部署级设计数据或类设计：是将类模型转化为设计类的实现以及软件实现所需要的数据结构。体系结构设计：定义了软件的主要构造元素之间的关系、课用于达到系统所定义需求的体系结构风格和设计模式以及影响体系结构实现方式的约束。体系结构设计表示基于计算机系统的框架可以从需求模型导出。接口设计：描述了信息如何流入好人流出系统以及被定义为体系结构一部分构件之间是如何通信的。 有3个要素：（1）用户界面UI （2）和其他系统、设备、网络或其他信息生成者或 使用者的外部接口 （3）各种设计构件之间的内部接口这些接口设计元素能够使软件进行外部通信，还能使软件体系结构中的构件之间进行内部的通信和协作。构件级设计：完整的描述了每个软件构件的内部细节。 细节：构件级设计为所有局部数据对象定义数据结构 为所有在构件内发生的处理定义算法细节 定义允许访问所有构件操作部署级设计：指明软件功能和子系统将如何在支持软件的物理计算环境内 分布。分析模型：是概念层次的东西，与具体实现技术无关，分析模型又称分析类，分为边界类、控制类、实体类, 分析用于获取系统中主要的“职责簇”，他们代表系统的原型类，是系统必须处理的主要抽象概念的“第一个关口”。分析类是跨越需求和设计实现的桥梁。联系：分析模型的每个元素都提供了创建四种设计模型所必需的信息。数据/类设计：将分析类模型转化为设计类的实现以及软件实现所要求的 数据结构。体系结构设计：定义软件的主要结构元素之间的联系、可用于达到系统所定义需求的体系结构风格和设计模式以及影响体系结构实现方式的约束。接口设计：描述软件和协作系统之间、软件和使用人员之间是如何通信的。构件设计：将软件体系结构的结构元素变换为对软件构件的过程性描述。如下图：思考：简述软件体系结构风格体系结构风格 定义了一个系统家族，其包括一个词汇表和一组约束。 一个词汇表包含一些构件和连接件类型， 一组约束指出系统是如何将这些构件和连接件组合起来的。体系结构风格 反映了领域中众多系统所共有的结构和语义特性，并指导如何将 各个模块和子系统有效地组织成一个完整的系统。 对体系结构风格的研究和实践为大粒度的软件复用提供了可能。 数据流风格 典型的体系结构风格 管道/过滤器风格 调用返回风格 仓库风格（1） 数据流风格：（见图一） 特点：当输入数据经过一系列的计算和操作构件的变换形成输出数 据时，可以应用这种体系结构。 管道/过滤器、批处理序列属于数据流风格。 图一（2）管道/过滤器风格 拥有一组过滤器构件，这些构件通过管道连接管道将数据从一个构件传 送到下一个构件。 每个过滤器独立于其上游和下游的构件而工作，过滤器的设计要针对某 种形式的数据输入，并且产生某种特定形式的数据输出。 如果数据流退化成为单线的变换，则称为批处理序列。这种结构接收一 批数据，然后应用一系列连续的构件（过滤器）变换它。（3） 调用-返回风格 在此类体系结构中，存在以下3种子风格。 主程序/子程序风格（见图二） 图二分层风格（见图三）在这种体系结构中，整个系统被组织成一个分层结构，每一层为上层提供服务，并作为下一层的客户。 图三面向对象风格 I.系统的构件封装了数据和必须应用到该数据上的操作，构件间通过消息传递进行通信与合作。 II与主程序/子程序的体系结构相比，面向对象风格中的对象交互会复杂一些。 III面向对象风格与网络应用的需求在分布性、自治性、协作性、演化性等方面具有内在的一致性。（4） 仓库风格（见图四） 数据仓库（如文件或数据库）位于体系结构的中心，其他构件经常访问该数据仓库，并对仓库中的数据进行增加、修改或删除操作。 数据库系统、超文本系统和黑板系统都属于仓库风格。 图四 仓库风格：中心存储库变换成“黑板”，黑板构件负责协调信息在客户间的传递，当用户感兴趣的数据发生变化时，它将通知客户软件。黑板系统的传统应用是信号处理领域，如语音和模式识别。另一应用是松耦合代理数据共享存取。（见图五） 图五 思考：（一）简述软件体系结构框架 一、定义：体系结构框架是特定应用领域问题的体系结构模式，它在组织形 式上是一个待实例化的完整系统。 定义了软件系统的构成单元和关系 创建了基本的模块 定义了涉及功能更改和扩充的插件位置。 重要作用：重用2、 趋势：面向某领域（包括业务领域，如ERP，和计算领域，如GUI）的、可复用的“半成品”软件，它实现了该领域的共性部分，并提供一系列定义良好的可变点以保证灵活性和可扩展性。可以说，软件体系结构框架是领域分析结果的软件化，是领域内最终应用系统的模板。随着软件规模的扩大、应用的广泛和软件复用技术的发展，以子程序或类（Class）为单位的软件复用有许多不足：（1） 子程序库日趋其庞大以致于使用人员难以掌握，（2） 大多数类粒度很小，且其自身往往不能完成有用的功能。这一问题迫使人 们在复用中将一组类（或模块）及其交互作为一个整体来考虑，由此出现了 软件体系结构框架。三、软件体系结构框架至少包含以下组成部分：（1） 一系列完成计算的模块，在此称为构件。（2） 构件之间的关系与交互机制。（3） 一系列可变点（也称热点，Hot-spots，或调整点）。（4） 可变点的行为调整机制。四、开发人员通过软件体系结构框架的行为调整机制，将领域中具体应用所特有的软件模块绑定到该软件框架的可变点，从而得到最终应用系统，这一过程称为软件体系结构框架的例化（instantiation）。通过软件体系结构框架的使用，开发人员可将主要精力放在应用所特有的模块的开发上，从而大大提高了软件生产率和质量。软件体系结构框架的行为调整机制是指如何针对具体的应用调整该框架的可变部分、如何在可变点加入特定应用模块所采用的方法和规则。行为调整机制可分为四种：（1） 模板参数化。软件体系结构框架提供代码自动生成工具，该工具根据用户 设置的参数自动生成所需的代码。（2） 继承和多态。通过面向对象中的子类继承和重载，在子类中加入新的功能 或改变父类的行为。（3） 动态绑定。在运行时刻动态绑定所需的对象服务，可通过软件模式技术实 现。（4） 构件替换。通过替换框架中可插拔的构件来加入业务特定的功能，不同于一般的可复用软件制品，软件体系结构框架的一个显著特点是逆向控制（Inversion of Control），在复用过程中，前者需被显式调用，控制是在应用特定的模块中，软件框架则不然，应用开发人员只要将应用特定的模块绑定到框架内，框架则根据自己的交互机制自动调用该模块，控制由框架负责。五、分类（1）按其应用的范围可分为： 系统基础设施框架。用于简化系统级软件的开发，如操作系统、用户界面、语言处理等，典型例子为MacApp