软件工程方法与实践习题答案——第5、8章.doc

习题五 简答题1. 以图1（一个在学校首次报名的 UML 活动图）为例，说明如何绘制活动图。图1 学校首次报名的UML活动图答：要创建一个UML活动图，需要反复执行下列步骤。(1) 定义活动图的范围。首先应该确定建模的范围，是对整个系统建模，还是一个子系统。一旦定义了作图的范围，应该在其顶部，用一个注释指明该图的标题和惟一的标识符，还可标注该图的时间及作者姓名。本题的建模范围是一个学校管理系统中的“报名”部分。(2) 添加活动。活动是活动图的核心，活动是完成系统任务所必须执行的处理步骤。可从用例模型出发，对每个角色(actor)所驱动的主要用例引入一个活动，如果是对整个系统建模，应对每个主要流程引入一个活动。在“报名”的活动图中确定了“Fill out enrollment ”(填写报名表)、“Enroll in university”(登记入学)、“Obtain help to fill out forms”(帮助填写报名表)、“Attend university overview presentation”(参加介绍学校会议)等6个活动。(3) 添加起点和结束点。每个活动图只能有一个起始点和多个结束点，结束点可以是所有活动的结束，也可以是对执行过程的终止。(4) 添加活动间的转变。当一个活动结束时将进入下一个活动，称为活动转移。可标明活动转移的条件、引起活动转移的事件。如活动“填写报名表”有两个活动转移，当填写报名表不正确时，则转移到活动“帮助填写报名表”；当填写正确时，则转移到活动“登记入学 ”。(5) 添加判断点。当对建模的逻辑需要做出一个判断时，需要添加判断点。例如，在图1中 ，在“Enroll in university”活动之后，还必须按照入学条件进行判断，满足条件的继续执行入学报到的活动，而不满足入学条件的则结束。(6) 找出并行活动。若两个活动间没有直接的联系，而且它们都必须在第三个活动开始前结束，则它们是可以并行运行的。在图1中，用同步线描述系统任务中的并发活动，活动“Attend university overview presentation”(参加介绍学校会议)和“Enroll in seminars” (注册研讨班)及“Make initial tuition payment”(交付初始的学费)可并行执行，使用同 步线表示它们都要在结束整个流程前完成。2. 简述扩展、包含和细化三种UML依赖关系的异同。答：扩展、包含和细化都是描述了元素之间的依赖关系，但具体含义不同。扩展（extend）关系是对基本用例在对某些“扩展点”的功能的增加。通过向被扩展的用例添加动作来扩展用例。包含（include）关系表示一个元素为了实现或完成其全部的功能，需要用到已存在的另一个模型元素，本质上是一种使用关系。细化关系是不同语义层（如分析和设计）之间模型元素的依赖关系，表示一个元素对另一个因此细化关系可描述的语义范围较广，包括模型的逐步细化、优化、变换、模板、模型合成、框架组成等。3. 软件开发为什么要使用UML建模？它有何特点？答：软件开发的过程犹如雕琢一件工艺品，由无形到有形，由粗到细。鉴于软件系统的复杂性和规模的不断增大，项目失败的可能性也相应增加。需要建立不同的模型对系统的各个层次进行描述。在长期的研究与实践中，人们越来越深刻地认识到，建立简明准确的表示模型是把握复杂系统的关键。模型是对事物的一种抽象，在软件开发过程中，建立各种模型，以便更透彻地了解系统的本质。由于UML以图形模型为主，模型的直观性及丰富的信息描述便于开发人员与用户的交流。建立的模型也为以后的系统维护和升级提供了文档。总的来说，使用模型可以使人们从全局上把握系统的全貌及其相关部件之间的关系，可以防止过早地陷入各个模块的细节。因此，面向对象的分析与设计应该从建模开始。UML是一种标准的图形化、可视化的建模型语言，UML的核心是建立系统的各类模型。其主要特点是：统一标准。UML统一了面向对象的主要流派Booch、OMT和OOSE等方法中的基本概念，已成为对象组织OMG的正式标准，并提供了标准的面向对象的模型元素的定义和表示。面向对象。UML集面向对象技术的众家之长。吸取了面向对象技术领域中其他流派的长处。可视化、表示能力强。系统的各种模型都能用UML的可视化模型清晰地表示，对系统描述能力强，模型蕴涵的信息丰富，可用于复杂软件系统的建模。独立于过程。UML是系统建模语言，独立于开发过程。易掌握、易用。UML的概念明确，建模表示法简洁明了，图形结构清晰，易于掌握使用。正是由于UML具有上述优点，所以对于大型复杂系统的建模，UML是最合适的选择。4. 简述UML实际建模过程。答：UML建模过程是一个迭代过程。每次迭代都建立相应的模型。分为以下几个阶段： 分析阶段。建模的目的是捕捉系统的功能需求，分析、提取所开发系统的“客观世界”领域的类以及描述它们的合作关系。常以用例图为首选模型。 设计阶段。建模的目的是通过考虑实现环境，将分析阶段的模型扩展和转化为可行的技术实现方案。常建立以类图为主的静态模型，及包括状态模型、顺序模型、活动模型和合作模型等动态模型。 实现阶段。主要工作就是进行编码，同时对已构造的模型作相应的修正。 配置阶段。通过模型描述所开发系统的软硬件配置情况建立配置模型。 测试阶段。使用前几个阶段所构造的模型来指导和协助测试工作。5. 在UML中，状态图、协作图、活动图、顺序图在系统分析中各起到了什么作用？答：状态图(State Diagram)用来描述一个特定对象在其生存周期或在某段时间内的所有可能的状态及其引起状态转移的事件。一个状态图包括一系列的状态以及状态之间的改变。例如订单的状态变化等，在实时系统中用得较多，还可以用于辅助设计用户界面。顺序图(Sequence Diagram) 清晰地描述一组对象之间动态的交互关系、时间的约束关系，着重描述对象间消息传递的时间顺序，所以顺序图在实时系统中被大量使用。当参与交互的对象数目增加，交互关系复杂时用顺序图描述会显得杂乱，协作图(Collaboration Diagram)从另一个角度来更好地描述相互协作的对象间的交互关系和链接(Link)关系。着重体现交互对象间的静态链接关系和协作关系。协作图也可以从顺序图生成。活动图(Activity Diagram)是由状态图变化而来的，从系统任务的观点来看，系统的执行过程是由一系列有序活动组成的。活动图可以有效地描述整个系统的流程，描述了系统的全局的动态行为，且只有活动图是唯一能够描述并发活动的UML图。6. 顺序图与协作图都是交互图，它们有何不同？所描述的主要系统特征是什么？顺序图(Sequence Diagram) 重点描述某些对象间消息传递的时间顺序，对象间的通信和交互通过在对象的生命线之间传送的消息来表示。还常给出消息的说明信息及消息之间的时间限制及一些约束信息等。但当参与交互的对象数增加，交互关系复杂时难于表达清楚对象之间的交互关系。协作图(Collaboration Diagram) 则着重体现交互对象间的静态链接关系和协作关系，不强调执行事件的顺序，而是强调为了完成某个任务，对象之间通过发送消息实现协同工作关系。可以有效地描述当参与对象数较多时的交互关系。7. 状态图与活动图有何相同与不同之处？在建立系统模型时，应该如何使用这两类模型？答：活动图(Activity Diagram)是由状态图变化而来的,它们各自用于不同的目的。状态图着重描述了对象的状态变化以及触发状态变化的事件。但是，从系统任务的观点看系统，它是由一系列有序活动组成的，活动图是从活动的角度描述系统任务，并且可以描述系统任务中的并发活动。活动图描述了系统中各种活动的执行顺序，刻画一个方法中所要进行的各项活动的执行流程。活动图显示动作及其结果，着重描述操作实现中完成的工作以及用例或对象内部的活动。此外，在状态图中状态的变迁通常需要事件的触发，而活动图中一个活动结束后将立即进入下一个活动。8. 什么是抽象类？在建模时有时使用抽象类有什么好处？答：抽象类是指没有实例的类，定义一些抽象的操作，即不提供实现方法的操作，只提供操作的特征，并标注abstract。如在建立类模型时，常将一些属性与操作类似的类作为一个抽象类的子类，使系统结构更加清晰，增加系统的可读性。9. 以例5-5中图5.22“资源管理用例图”为例，说明和的区别。答：在图5.22中，用例“删除资源”和“更新资源”与用例“查找资源”之间是的关系，本质上是一种使用关系，当一个用例包含另一个用例时，这两个用例之间就构成了使用关系。说明“删除资源”和“更新资源”的操作都需要首先“查找资源”。扩展是向一个用例中加入一些新的动作后构成了另外一个用例，后者是继承前者的一些行为得来的。图5.22中，对用例“更新资源”中增加动作“清除技能”，得到用例“从资源中清除技能”，增加动作“指定技能”，得到用例“把技能指定给资源”，因此，用例“更新资源”与“从资源中清除技能”和“把技能指定给资源”之间的关系是。10. 在分析和设计阶段都需要建立类图，试说明分析类图与设计类图的主要区别是什么。答：在软件开发的不同阶段都使用类图，但这些类图表示了不同层次的抽象。在需求分析阶段，类图是研究领域的概念；在设计阶段，类图重点描述类与类之间的接口。由于分析类图主要描述应用领域中的概念，它们的类可以从这些概念中得出，或者说分析类图中的类是从需求中获取的。设计类图描述软件的接口部分，而不是软件的实现部分。面向对象开发方法非常重视区别接口与实现之间的差异，可以用一个类型(Type)描述一个接口，这个接口可能因为实现环境、运行特性或者用户的不同而具有多种实现方式。设计类图更易于开发者之间的相互理解和交流。设计类图通常是在分析类图的基础上进行细化和改进的。11. 问题描述：储户用存折取款，首先填写取款单，根据“银行卡”中的信息检验取款单与存折，如有问题，将问题反馈给储户；否则，登录“储户存款数据库”，修改相应数据，并更新“帐卡”，同时发出付款通知，出纳向储户付款。 建立系统的用例模型； 建立角色和用例的描述模板。答：通过分析，确定系统的角色为：储户、存款数据库、存折、出纳。用例为：填写取款单、验证取款单与存折、银行卡管理、数据库管理、付款。银行取款系统的高层用例图储户存折出纳存款数据库付款数据库管理填写取款单银行卡管理管理验证取款单与存折描述模板：角色描述模板：角色：储户角色职责：提供取款存折和取款信息。角色职责识别：提供存折、填写取款单、领取付款。角色：存折角色职责：储户存、取款的凭证。角色职责识别：(1)向系统提供取款凭证。(2)与“银行卡管理”子系统交互，核对取款单。角色：出纳角色职责：向储户付款。角色职责识别:(1) 根据储户存款数据库的通知，向储户付款。 (2)与“付款”子系统交互。角色：存款数据库角色职责： 对储户信息及存、取款业务进行管理。角色职责识别：(1)在系统支持下完成银行数据库管理工作。(2)为银行卡管理及通知付款提供信息。用例描述模板：用例名：验证取款单与存折执行者：储户、存折、存款数据库目标： 根据“银行卡”中的信息检验取款单与存折。功能描述：1. 获取“银行卡”中的信息。2. 检验取款单与存折信息。3. 返回验证结果。其他非功能需求: 高可靠性、实时性主要步骤：1. 储户填写取款单。2. 根据银行卡信息，检验取款单与存折信息是否正确。3. 若取款单与存折有问题，将信息返回给储户，否则登录“储户存款数据库”，修改相应数据，并更新“银行卡”。相关用例：填写取款单、银行卡管理、数据库管理相关信息：(优先级、性能、执行频率)：优先级：根据储户类型，决定处理的优先次序，VIP用户优先。性能：实时性、高可靠性。其他用例模板略。12. 一个小型图书资料管理系统的主要功能有：图书资料的借出、归还、查询和管理，该系统有图书管理员和普通读者，普通读者要使用系统必须先注册。图书管理员负责添加、更新和修改、删除图书资料，登记和查询图书的借阅、归还情况。读者可以按照作者或主题检索图书资料，还可以预订图书资料，即当新购买或有读者归还时，系统立即通知读者来借阅。 确定系统的类，并定义其属性和操作； 画出系统的分析类图。参考答案：在分析系统需求的基础上，采用名词识别法与实体识别法，确定以下系统的类：Book类该类标识一本书，其属性包括书名、作者、出版社等。User Information类该类标识一个用户，其属性包括用户名、密码、用户类型等。Librarian类 该类是User Information类的子类，其操作包括查询读者信息，添加、删除、更新读者信息、查询书籍信息、添加、删除、更新书籍信息等。Borrower类该类是User Information类的子类，其操作包括查询个人信息、修改密码等。System Manager类该类是User Information类的子类，其操作包括查询图书管理员信息，添加、删除、更新图书管理员信息等。BorrowCriteria类该类标识一条借书规则，其属性包括规则名，规则应用对象等。Info Database类该类标识一个数据库，其属性有数据库名，其操作有读数据、写数据和查找数据。Communication类该类实现各数据库间的数据传输，其操作包括建立通信套接字、绑定端口、建立连接、发送数据、接受数据等。系统的分析类图：User Information由于图书馆的多本书构成书库，增加BookDatabase类，与Book类之间是聚合关系。同样由于借书规则不止一条，增加CriteriaDatabase类，与BorrowCriteria类之间是聚合关系。13.为什么说RUP与UML密切结合，能够开发出满足最终用户需要的高质量软件？答：好的软件过程，是应用UML成功地进行软件开发的关键。在众多的软件开发过程中， RUP统一过程（Rational Unified Process）能够与UML最佳结合，不仅因为该过程的开发者也是UML的创立者，更因为RUP过程能够有效地测度工作进度，控制和改善工作效率。RUP是最佳软件开发经验的总结，具有迭代式增量开发、使用实例驱动、以软件体系结构为核心的三个鲜明特点，还包括了软件开发中的6大经验：迭代式开发；管理需求；使用基于组件的软件体系结构；可视化建模；验证软件质量；控制软件变更。因此，RUP与UML密切结合，能够开发出满足最终用户需要的高质量软件。14.分析RUP的二维开发模型，说明RUP的迭代开发过程。答：在RUP中，软件开发生存周期根据时间和RUP的核心工作流划分为二维空间。横轴描述RUP开发过程的动态结构，纵轴描述RUP的静态组成部分。横轴把软件开发周期（Cycle）划分为起始（Inception）、演化（Elaboration）、构造（Construction）和提交(Transition) 四个连续的阶段(Pahse)。纵轴表示核心工作流。RUP中有商业建模、需求、分析和设计、实现、测试、部署、配置和变更管理、软件项目管理和环境9个核心工作流(Core Workflows)：RUP中的每个阶段都由一个或多个连续的迭代组成，每一个迭代都是一个完整的开发过程，产生一个可执行的产品版本，在每个阶段结束前都应有一个里程碑（MileStone）评估该阶段的工作，只有当阶段目标达到时才允许项目进入下一阶段，产生一个阶段里程碑。这是一种更灵活、风险更小的方法，是多次通过不同的开发工作流，这样可以更好地理解需求，构造一个健壮的体系结构，并最终交付一系列逐步完成的版本，称为一个迭代生存周期。习题八 简答题1. 等价分类法的基本思想是什么？答：根据程序的输入特性，将程序的定义域划分为有限个等价区段“等价类”，从等价类中选择出具有“代表性”的用例，即测试某个等价类的代表值就等价于对这一类其他值的测试。如果某个等价类的一个输入数据(代表值)测试中查出了错误，说明该类中其他测试用例也会有错误。2. 自顶向下渐增与自底而上渐增各有何优、缺点？答：自顶向下渐增优点：能够尽早发现系统主控方面的问题，并尽早测试系统结构的问题。缺点：需要编写桩模块，由于下属模块往往不止一个，也不止一层，加之模块接口的复杂性，桩模块很难模拟各下层模块之间的调用关系，也无法验证桩模块是否完全模拟了下属模块的功能。因此很难尽早查出底层容易出错的复杂模块中的错误，所以导致过多的回归测试。自底向上渐增优点：需要编写驱动模块。驱动模块是模拟主程序或者调用模块的功能，处于被测试模块的上层，所以驱动模块只需模拟向被测模块传递数据，接收或打印从被测模块返回的数据等功能，比编写桩模块容易。还能够尽早查出底层涉及较复杂的算法和实际的I/O模块中的错误。缺点：只有当系统所有模块全部组装完成，才能看到系统完整的结构，才能测试系统的主控功能。3. 渐增式与非渐增式有何区别？为什么通常采用渐增式？答：非渐增式是将所有的模块一次连接起来，简单、易行，节省机时，但测试过程中难于查错，发现错误也很难定位，测试效率低。渐增式是将模块一个一个地连入系统，每连入一个模块，都要对新子系统进行测试。这种组装测试方案虽然用机时多，但比较非渐增式容易查出错误及进行错误定位，有利于查出模块接口部分的错误，测试效率高。因此通常采用渐增式。4. 什么是测试和测试？答：测试是在开发机构的监督下，在确认测试阶段后期由个别用户对软件进行测试，目的是评价软件的FLURPS(功能、局域化、可使用性、可靠性、性能和支持性)，注重界面和特色。测试是在进行了测试的基础上，由支持软件预发行的客户对FLURPS进行测试，主要目的是测试系统的可支持性，是在软件产品正式发布前的测试。5. 黑盒法与白盒法的区别是什么？各自运用在什么情况下？答：白盒法测试又称结构测试或逻辑驱动测试。必须考虑程序内部结构和内部特性，针对特定条件或与循环集设计测试用例，对软件的主要逻辑路径进行测试。一般主要用于模块测试。黑盒法测试又称功能测试或基于规格说明的测试。这种方法是从用户观点出发，测试时把被测程序当作一个黑盒，不考虑程序内部结构和内部特性，测试者只知道该程序输入和输出之间的关系或程序的功能的情况下，依靠能够反映着这一关系和程序功能需求规格的说明书，来确定测试用例和推断测试结果的正确性。一般用于集成测试、确认测试及功能测试、系统测试等。6.软件测试与其他软件开发活动相比具有什么样的特点？答：软件测试的目标在于，以最小的工作量和成本，尽可能多地发现软件系统中存在的各种错误和缺陷，以确保软件系统的正确性和可靠性。其主要特点是： 软件测试的开销大。按照Boehm的统计，软件测试的开销大约占总成本的30%50%。 不能进行“穷举”测试。只有将所有可能的情况都测试到，才有可能检查出所有的错误，但这是不可能的。 软件测试难度大。既然不能进行 “穷举”测试，又要查出尽可能多的错误，随着软件的规模和复杂度不断增加，软件测试工作的难度越来越大。测试也是一种开发活动，但鉴于软件测试的以上特点，它比其他软件开发活动更加复杂、困难和重要，且无论怎样强调它的重要性都不过分。7.软件测试通常包含哪几个基本步骤？答：软件测试通常应该对需求、总体设计、详细设计、编码实现各个阶段所获得的开发产品进行测试，软件测试应该贯穿于整个软件开发的全过程。软件测试过程按测试的先后次序可分为以下步骤进行：单元测试、集成测试、确认测试和系统测试，最后进行验收测试。单元测试。完成每个模块的测试，尽可能发现模块内部的错误。单元测试主要采用白盒测试法。集成测试。把已测试过的模块按照一定顺序组装起来，构成软件系统。主要采用黑盒测试法。但对发现错误较多的新子系统，还可能采用白盒法进行回归测试。确认测试：检验所开发的软件能否满足所有功能和性能需求的最后手段，通常均采用黑盒测试法。系统测试：完成确认测试以后，检验它能否与系统的其他部分（如硬件，数据库及操作人员）协调工作，需要进行系统测试。验收测试：检验软件产品质量的最后一道工序是验收测试。与前面讨论的各种测试活动的不同之处主要在于它突出了客户的作用，同时软件开发人员也应有一定程度的参与。8.软件调试有哪些方法？各自有什么特点？答：常见的软件调试策略包括：试探法、归纳法、演绎法、回溯法和对分法等。试探法。一种比较原始的调试策略。它的基本思想是通过分析软件系统运行过程中大量数据信息、中间结果的变化情况来查找错误发生的原因、确定错误发生的位置。该方法简单、易行，但调试效率低，只适用于结构比较简单的小型系统。归纳法。一种由特殊到一般的逻辑推理方法。根据软件测试所取得的个别错误数据，错误线索着手，通过分析这些线索之间的关系而发现错误。演绎法。一种由一般到特殊的逻辑推理方法。根据已有的测试数据，设想所有可能的出错原因，然后通过测试逐一排除不正确、不可能的出错原因，最后证明剩余的错误的合理性，确定错误发生的位置。回溯法。从软件系统中发现错误位置开始，沿着程序的控制流程往回追踪程序代码，直至找到错误发生的位置或范围。回溯法