软件工程第十版课后习题答案(中文版)

第一章概述1.2通用的软件产品开发和定制化软件开发之间最重要的区别是什么?这在实践中对于通用软件产品的用户意味着什么?根本区别在于，在通用软件产品开发中，规范由产品开发者拥有。对于定制产品开发，规范由客户拥有和控制。这一点的影响是重大的——开发者可以根据一些外部变化（例如竞争产品）迅速决定更改规范，但当客户拥有规范时，更改必须在客户和开发者之间进行协商，并且可能会产生合同影响。对于通用产品的用户，这意味着他们无法控制软件规范，因此无法控制产品的演变。开发者可能会决定包含/排除功能并更改用户界面。这可能会对用户的业务流程产生影响，并在安装新版本的系统时增加额外的培训成本。这也可能会限制客户改变自己业务流程的灵活性。1.3软件产品应该具有的4个重要属性是什么?另外举出4个可能有意义的属性。四个重要的属性是可维护性、可靠性和安全性、效率和可接受性。其他可能重要的属性可能是可重用性（它是否可以在其他应用程序中重用）、可分布性（它是否可以分布在处理器网络上）、可移植性（它是否可以在多个平台上运行，例如笔记本电脑和移动平台）和互操作性（它是否可以与广泛的其他软件系统一起工作）。对4个关键属性的分解，例如可靠性分解为安全性、安全性、可用性等，也是这个问题的有效答案。1.4除了异构性、企业和社会的变革、可信和信息安全之外，说一说软件工程在21世纪有可能面对的其他问题和挑战(提示：想一想环境)。软件工程面临的问题与挑战众多，主要包括：开发节能系统，以提升其在低功耗移动设备上的适用性，并减少IT设备的整体碳排放。开发模拟系统的验证技术，这对于预测和应对气候变化的程度至关重要。开发适合多文化背景用户使用的系统。开发能够迅速适应新商业需求的灵活系统。设计便于外包开发的系统架构。开发具有高安全性的系统，能够抵御各种攻击。开发易于最终用户调整和配置的系统。探索测试、验证和维护最终用户开发系统的有效方法。1.5参考1.1.2节讨论的应用类型，举例说明为什么设计和开发不同类型的应用需要特殊化的软件工程技术。不同应用类型需要使用不同的开发技术，原因如下：成本与变更频率。一些系统（如消费设备中的嵌入式系统）更改成本极高；其他系统则需要频繁变化以响应需求变化（如业务系统）。更改成本极高的系统需要进行广泛的前期分析以确保需求一致性，并进行广泛的验证以确保系统符合规格。这对于快速变化的系统来说并不具成本效益。最重要的“非功能”需求。不同系统对非功能需求的优先级不同。例如，飞机中的实时控制系统以安全为主要优先级；交互式游戏则以响应性和可用性为优先级。用于实现安全的技术不适用于交互式游戏；游戏所需的广泛用户界面设计在安全关键的控制系统中不需要。软件生命周期和交付计划。一些软件系统的生命周期相对较短（如许多基于网络的系统），而其他系统的生命周期可达数十年（如大型指挥和控制系统）。某些系统需要快速交付以便实用。开发短生命周期、快速交付系统的技术（如使用脚本语言、原型开发等）不适用于需要长期支持的系统，这些系统需要采用允许长期支持的技术，如设计建模。1.8讨论一下职业工程师是否应该和医生或律师一样颁发资格证书。这些是可能的讨论要点——任何讨论都会涉及广泛的范围，并触及诸如职业操守等其他问题。认证的优势认证向雇主表明具备某种最低水平的能力。认证提升了职业的公众形象。认证通常意味着建立和检查教育标准，因此是一种确保课程质量的机制。认证在争议发生时意味着责任。认证机构可能被接受为在国家和国际层面代表该职业的权威认证可能提高软件工程师的地位，并吸引特别有能力的人进入该职业。认证的劣势认证往往导致保护主义，认证成员往往不保护他人免受批评。认证并不保证能力，仅表明在认证时达到了最低标准。认证费用高昂，会增加个人和组织的成本。认证往往会抑制变革。在技术发展非常迅速的领域，这是一个特别的问题。第二章软件过程2.1针对以下每个系统，请推荐最合适的可以管理其开发的基础的通用软件过程模型，按照所开发系统的类型给出你的理由。一个汽车中的防抱死刹车控制系统；一个支持软件维护的虚拟现实系统；一个准备替换现有系统的大学会计系统；一个交互式的旅行规划系统，可以帮助用户以最小的环境影响规划旅程。1.防抱死制动系统：这是一个安全关键系统，因此在实施前需要大量的前期分析。它肯定需要一个计划驱动的开发方法，要求进行仔细的需求分析。因此，瀑布模型是最适合使用的方法，或许可以在不同开发阶段之间进行正式转换。2.虚拟现实系统：这是一个需求会变化并且具有大量用户界面组件的系统。增量开发可能是最合适的模型，或许需要一些UI原型开发。可以使用敏捷过程。3.大学会计系统：这是一个需求相对明确的系统，并且将在与许多其他系统（如研究经费管理系统）配合使用的环境中使用。因此，基于重用的方法可能是适合的。4.交互式旅行规划系统：这是一个具有复杂用户界面的系统，但必须稳定可靠。由于系统需求会随着用户实际使用经验的积累而变化，因此增量开发方法是最合适的。2.3考虑图2-3中所示的集成和配置过程模型。为什么在这个过程中要重复需求工程活动?您需要重复需求工程活动，因为根据系统/组件的可重用性来调整系统需求是至关重要的。这些活动包括：1.初始活动：了解系统功能并概述系统应执行的广泛需求。应以足够详细的方式表达这些需求，以便您可以据此决定某个系统/组件是否满足某些需求并能够重用。2.详细需求工程活动：一旦选定了系统/组件，您需要进行更详细的需求工程活动，以检查重用软件的功能是否满足业务需求，并识别所需的更改和添加。2.4为什么在需求工程过程中区分用户需求开发和系统需求开发是重要的?用户需求和系统需求之间存在根本差异，这意味着应该分别考虑它们。用户需求旨在从用户角度描述系统的功能和特性，用户理解这些需求至关重要。它们应该用自然语言表达，可能不会表达得非常详细，以允许一些实现的灵活性。参与该过程的人员必须能够理解用户的环境和应用领域。系统需求比用户需求详细得多，旨在成为系统的精确规范，可能是系统合同的一部分。它们也可能用于开发外包的情况，开发团队需要完整的规范说明应该开发什么。系统需求是在用户需求确定后制定的。2.6为什么在复杂系统中变化是不可避免的?举出一些有助于预测可能的变化并使所开发的软件更适应变化的软件过程活动的例子(除了原型和增量交付之外)。系统必须变化，因为当它们安装在环境中时，环境会适应它们，这种适应自然会产生新的/不同的系统需求。此外，系统的环境是动态的，随着业务、业务目标和业务政策的变化不断产生新需求。除非系统适应这些需求，否则其功能将与支持业务所需的功能脱节，从而变得不那么有用。支持变化的过程活动示例包括：记录需求的理由：记录需求被包含的原因，这有助于未来的变化。需求可追溯性：显示需求之间以及需求与系统设计/代码之间的依赖关系。设计建模：设计模型记录软件的结构。代码重构：通过提高代码质量，使其更易于变更。2.9指出SEI的能力成熟度框架中所包含的过程评估和改进方法的两个优点和两个缺点流程改进框架的优势这种方法提供了一种衡量流程当前状态的手段，以及一种引入流程改进的有序方法。它作为借鉴其他人在流程改进方面的经验的一种方式非常有用。流程改进框架的劣势与任何测量系统一样，存在一种倾向，即为了提升测量结果而进行改进，而不是专注于满足实际业务目标的改进。成熟度模型方法操作起来成本高昂且官僚。它并不真正适合那些采用敏捷开发方法。第三章敏捷软件开发3.2敏捷方法所基于的原则是如何加快软件的开发和部署的?敏捷开发的基本原则是：个人和交互胜过过程和工具。通过利用个人技能和能力，并确保开发团队了解彼此的工作，避免了正式沟通和过程保证的开销。这意味着团队可以专注于工作软件的开发。工作软件胜过全面的文档。这有助于加速开发，因为不会花费时间开发、检查和管理文档。相反，程序员的时间集中在代码的开发和测试上。客户协作胜过合同谈判。敏捷开发人员认为，与其花费时间开发、分析和谈判要包含在系统合同中的需求，不如在开发过程中直接从客户那里获得关于需求的反馈更有效。这允许比需要合同的情况更早地开发和交付有用的功能。响应变化胜过遵循计划。敏捷开发人员正确地认为，对变化做出响应比遵循基于计划的过程更有效，因为无论使用什么过程，变化都是不可避免的。更改计划以适应变化会产生巨大的开销，而计划的不灵活性意味着可能会做一些后来被丢弃的工作。3.3极限编程将用户需求表达为故事，每个故事写在卡片上。讨论这种方法对于需求描述的优点和缺点故事的优点：它们代表了经常出现的真实情况，因此系统将支持最常见的用户操作。用户很容易理解和评论故事。它们代表了功能的增量——实现一个故事为用户提供了一些价值。故事的缺点：它们可能不完整，而且它们的非正式性质使得这种不完整性难以察觉。它们关注的是功能需求，而不是非功能需求。当使用故事时，不可能表示性能和可靠性等横切系统需求。系统架构和用户故事之间的关系不清楚，因此架构设计很困难。3.6比较Scrum方法和传统的基于计划的方法中的项目管理(如第23章所介绍的)。你的比较应该基于每种方法对项目人员分配计划、项目成本估算、维持团队延续性、管理项目团队成员变化等方面的有效性1.项目人员分配计划ScrumScrum采用非正式的方式进行人员分配。团队成员会根据产品待办事项列表中的功能特性，如果认为自己的专长合适，就会“竞标”来实施这些功能。或者，Scrum主管也可以分配任务。在Scrum中，没有正式的机制来规划具备非常特殊专长的项目成员临时分配到一个团队中。这种需求必须由Scrum主管识别，并且他或她需要讨论如何提供这些专长。基于计划的开发项目计划用于识别系统要交付的部分，并在需求文档中加以说明。然后可以识别出每个部分所需的专长，并基于此规划人员分配到项目中。2.项目成本估算Scrum项目成本是基于软件的预期交付日期和Scrum团队中的人员来估算的。系统的功能会进行调整，以确保在原始成本估算内总能交付一些可工作的系统。当然，这可能对客户来说不够充分，他们需要参与重新安排系统交付的时间。基于计划的开发项目成本基于需求文档中指定的功能性以及系统的非功能性需求进行分析。成本可能会根据团队规模和交付时间进行调整。通常情况下，成本会被低估，最终项目的实际成本会远高于最初的估算。团队成员的平均成本是默认的。3.维持团队凝聚力Scrum团队成员每天会面，无论是面对面还是通过电子方式。鼓励广泛的非正式讨论和沟通。团队成员从项目待办事项中协商工作任务。这一切都促成了产品所有权的共同感和一个非常有凝聚力的团队。基于计划的开发团队凝聚力是项目经理的责任，他或她必须采取明确的行动来促进这一点。总体方法依赖于相对不频繁的正式会议，这并不利于发展一个有凝聚力的团队。4.管理项目团队成员的变动Scrum这是Scrum中很少讨论的话题，但却是一个根本性问题，因为很多信息是非正式的，依赖于人们记住已经达成的共识。当有人离开时，尤其是在很少有项目文档的情况下，很难让新成员快速上手。基于计划的开发项目管理计划围绕专长而不是个人制定，并且项目文档应该是可用的。因此，如果团队成员离开，那么具有相当专长的新成员可以阅读已完成的工作，在理解之后，应该能够作为替代者。3.8为什么在将敏捷方法规模化应用到由分布式开发团队开发的更大项目中的时候，有必要从基于计划的方法中引入一些方法和文档?当大型团队开发软件时，项目规划通常至关重要。这包括确保在开发过程中需要时，可以获取合适的人员，以及确保由不同团队开发的系统不同部分能够协调交付。这意味着如果部分A依赖于部分B，时间表应确保在部分A开发之前先完成部分B。需求分析和文档化对于决定如何分配工作并确保每个团队对其他团队的工作有一定的了解非常重要。设计文档，尤其是接口规范，对于团队能够独立开发而不需要接触正在开发中的软件非常重要。风险管理可能需要确保所有团队了解面临的风险，并能够组织工作以最小化这些风险。风险管理也可能有助于应对不同团队采用的不同交付时间表3.10让一个用户紧密参与软件开发团队的一个问题是他们会被“同化”。也就是说，他们会采用开发团队的观点，并丢掉关于用户需要的观点。提出3种有利于避免这一问题的方法，并讨论每种方法的优点和缺点让多个用户参与到开发团队中。优点是您可以获得关于问题的多个视角，更好地覆盖用户任务，从而获得需求，并且不太可能有非典型用户。缺点是成本、让用户参与的困难以及可能的用户冲突。改变参与团队的用户。优点同样是多个视角。缺点是每个用户都需要时间才能发挥生产力，以及可能来自不同用户的相互冲突的需求。与其他用户代表验证用户建议。优点是对建议进行独立检查；缺点是这会减慢开发过程，因为进行检查需要时间。第四章需求工程4.2找出下面这段售票系统需求陈述中有二义或遗漏的地方：一个自动化的售票机销售火车票。用户选择他们的目的地并输入信用卡和个人身份信息。机器吐出火车票，而用户的信用卡账户会进行付款。当用户按下启动按钮，一个显示候选目的地的菜单被激活，同时系统向用户显示一条选择目的地以及所需要的票的类型的消息。一旦选择了目的地，系统显示票价并请客户输入他们的信用卡。检查信用卡是否有效之后，系统请用户输入个人身份(PIN码)。信用卡交易确认后，票被吐出。存在的歧义和遗漏包括：客户是否可以一次性购买多个同一目的地的车票，还是必须逐个购买？如有误操作，客户能否取消购票请求？若输入无效卡，系统应如何处理？若客户在选择目的地前就插入卡（类似于ATM机操作），会出现什么情况？若客户想购买去往其他目的地的车票，是否需要再次按下“开始”按钮？系统是否仅提供从机器所在车站出发的直接连接车站的车票，还是包括所有可能的目的地？4.4为售票系统书写一组非功能性需求，明确所期望的可靠性和响应时间。售票系统的可能非功能需求包括：在任何一天的06:00到23:00之间，整个系统的停机时间不应超过5分钟。在任何一天的06:00到23:00之间，系统故障后的恢复时间不应超过2分钟。在任何一天的23:00到06:00之间，整个系统的停机时间不应超过20分钟。所有这些都是可用性要求——请注意，这些要求根据一天中的时间而有所不同。在大多数人旅行时发生的故障比在客户很少时发生的故障更不可接受。在客户按下机器上的按钮后，显示器应在0.5秒内更新。在收到信用卡验证后，出票时间不应超过10秒。在验证信用卡时，显示屏应为客户提供状态消息，表明正在进行活动。这告诉客户验证这种可能耗时的活动仍在进行中，而且系统并没有简单地失败。售票请求的最大可接受故障率为1:10000。请注意，这实际上是ROCOF。我没有指定可接受的错误票数量，因为这取决于系统是否包括允许记录客户请求的跟踪设施。如果是这样，相对较高的故障率是可以接受的，因为客户可以投诉并获得退款。如果没有，只有非常低的故障率是可以接受的。显然，这些要求是任意的，还有许多其他可能的答案。您只需检查它们的可信度。4.6一个负责起草系统需求规格说明的工程师，应当如何记录功能性需求和非功能性需求之间的关系?请给出你的建议追踪功能需求和非功能需求之间的关系是复杂的，因为非功能需求往往是针对整个系统的，而不是单一功能或一组功能。一种可行的方法是明确指出与特定功能需求相关的系统级非功能需求，并将它们单独罗列。所有对每个功能需求有影响的系统需求都应被详细列出。可以通过如下表所示的方式，将它们联系起来。功能要求相关的非功能性系统需求非功能性需求系统应提供一种操作，允许操作员打开释放阀，将蒸汽排入大气中。安全要求：如果在蒸汽发生装置上进行维护工作，则不得释放蒸汽。时间要求：操作员开始行动后，阀门必须在2秒内完全打开。在这个例子中，请注意系统级非功能需求通常会比针对特定操作的定时要求具有更高的优先级。显然，任何能够合理地将功能需求和非功能需求联系起来的方法都是可以接受的。4.7根据你自己关于ATM机使用的经验，开发一组可以作为理解ATM机系统需求的基础的用况有多种不同类型的自动取款机，所以，显然，不可能有一套确定的用例可以产生。然而，我期望看到涵盖主要功能的用例，如提取现金、显示余额、打印对账单、更改密码和存入现金。用例描述应该描述所涉及的参与者、输入和输出、正常操作和异常情况。取款：参与者：客户，ATM，会计系统输入：客户的卡，PIN，银行账户详情输出：客户的卡，收据，银行账户详情正常操作：客户将卡插入机器。他/她被提示输入PIN，并在键盘上输入。如果正确，他/她将看到一系列选项。选择“取款”选项。客户被提示输入所需现金金额并输入金额。如果账户中有足够的资金，现金将被分配，打印收据并更新账户余额。在分配现金之前，卡片被退还给客户，机器提示客户取卡。异常：无效卡。卡片被机器保留；建议客户寻求建议。PIN错误。请求客户重新输入PIN。如果3次尝试后仍然错误，卡片被机器保留，并建议客户寻求建议。余额不足。交易终止。卡片退还给客户。显示余额：参与者：客户，ATM，会计系统输入：客户的卡，PIN，银行账户详情输出：客户的卡正常操作：客户使用卡和PIN进行身份验证，如“取款”并选择“显示余额”选项。他们账户的当前余额显示在屏幕上。卡片退还给客户。异常：无效卡。如“取款”所述PIN错误。如“取款”所述打印对账单：参与者：客户，ATM，会计系统输入：客户的卡，PIN，银行账户详情输出：客户的卡，打印的对账单正常操作：客户使用卡和PIN进行身份验证，如“取款”并选择“打印对账单”选项。他们账户的最后五笔交易被打印出来。卡片退还给客户。异常：无效卡。如“取款”所述PIN错误。如“取款”所述更改PIN：参与者：客户，ATM输入：客户的卡，PIN输出：客户的卡正常操作：客户进行身份验证，如“取款”并选择“更改PIN”选项。他/她被提示两次输入新PIN。输入的PIN应该相同。客户的PIN被加密并存储在卡上。卡片退还给客户。异常：无效卡。如“取款”所述。PIN错误。如“取款”所述。PIN不匹配。邀请客户重复过程以重置他/她的PIN。存款：参与者：客户，ATM，会计系统输入：客户的卡，PIN，银行账户详情，要存款的现金输出：客户的卡，收据正常操作：客户使用卡和PIN进行身份验证，如“取款”并选择“存款”选项。客户被提示输入要存款的现金金额并输入金额。然后，他或她将获得一个存款信封，将现金放入其中然后将其退还给机器。客户的账户余额被更新为存款金额，但这被标记为未清算资金，直到检查后才清算。发出收据，并退还客户的卡。异常：无效卡。如“取款”所述。PIN错误。如“取款”所述。在信封发出1分钟内未存款。交易终止。卡片退还给客户。4.9当系统面临必须满足的紧急修改时，系统中的软件可能不得不在相应的需求变更被批准前就进行修改。建议一个实施这类修改的过程模型，使之可以确保需求文档和系统实现不会变得不一致下图展示了一个用于保持需求文档与系统一致性的变更流程。该流程应对变更设定优先级，确保紧急变更得到及时处理，并在修改系统需求时优先考虑这些变更。变更后的代码应作为最终变更流程的输入。同时，当有更多时间进行分析时，可能会发现更优的变更方法。分析变更请求[紧急变更]修改程序代码记录代码更改重新提交变更请求以待分析变更请求数据库[非紧急变更]评估需求影响更改需求设计/修改代码更新变更请求数据库第五章系统建模5.2如何使用一个已经存在的系统模型?解释为什么这样一个系统模型并不一定是完整和正确的。如果你在开发一个新系统的模型情况还是这样吗?您可能会创建并使用一个已经存在的系统的模型，原因包括：为了理解和记录现有系统的架构与运作方式。作为讨论对该系统可能变更的焦点。为了指导系统的重新实施。除非您的目的是完全记录现有系统的操作，否则您不需要一个完整的模型。在这种情况下，模型的目的是帮助您处理系统的某些部分，因此只需要对这些部分进行建模。此外，如果模型被用作讨论焦点，您可能不会对细节感兴趣，因此可以在模型中忽略系统的部分。一般来说，对于新系统的模型也是如此，除非正在进行基于模型的开发，这种情况下需要一个完整的模型。您可能需要完整模型的另一种情况是，根据合同要求，必须将此类模型作为系统文档的一部分产生。5.5开发一个顺序图来描述一所大学中的一个学生注册一门课程时所涉及的交互。课程可能有人数限制，因此注册过程必须包含针对是否还有空位的检查。假设学生通过访问一个电子课程目录来找出可选的课程5.6仔细观察你所使用的电子邮件系统中消息和邮箱是如何表示的。建模为了表示邮箱和电子邮件消息而需要在系统实现中使用的对象类Mailmessage（邮件信息）:sender（发送者）receiverlist（接收者列表）cclist（抄送列表）bcclist（密送列表）date（日期）subject（主题）returnpath（返回路径）routinginfo（路由信息）spaminfo（垃圾信息）mailer（邮件发送者）messageinfo（消息信息）messagebody（消息主体）attachments（附件）signature（签名）read（）reply（）replyall（）print（）forward（）send（）Mailbox（邮箱）:name（名称）pathname（路径名）creationdate（创建日期）changedate（更改日期）messages（消息）unreadmessages（未读消息）flaggedmessages（已标记的消息）deletedmessages（已删除的消息）movemessage（）copymessage（）deletemessage（）fetchmail（）（提取邮件）create（）rename（）delete（）5.7基于你对于银行ATM机的经验，画一个活动图来建模当一个客户从机器中提取现金时所涉及的数据处理5.10你是一个软件工程经理，你的团队中的一个资深成员提出应当使用模型驱动的工程来开发一个新系统。你在决定是否应该将该方法引入软件开发中时要考虑哪些因素?在做出决策时，应考虑以下几个因素：团队对UML和MDA的掌握程度（团队是否已具备相关专业知识，还是需要接受大量培训）支持MDA的工具有效性和成本（工具是否已内部可用，或需另行购买。它们是否满足正在开发的软件类型的需求）软件的预期使用寿命（MDA更适用于长期使用的系统）对高性能或高吞吐量的需求（MDA依赖代码生成，可能不如手工编码高效）采用MDA的长远利益（这种方法是否能真正节省成本）开发团队的热情和承诺（团队成员是否都支持这一新方法）在编写规范之前可能必须设计架构，以提供一种构建规范和同时开发不同子系统规范的方法，以便允许分包商制造硬件，并为系统成本提供模型。第六章体系结构设计6.1当描述一个系统时，为什么必须要在得到完整的需求规格说明之前就开始系统体系结构的设计?在设计规范之前，可能需要先制定架构。这样做是为了提供一个清晰的方法来结构化规范，并允许同时开发各种子系统规范。这样的做法有助于分包商制造硬件，并且为系统成本估算提供了一个模型。6.3在为一个可用性和信息安全需求都是最重要的非功能性需求的系统设计体系结构时，为什么可能会出现设计冲突?从根本上说，为了提供可用性，架构中需要有（a）复制的组件，以便在一个组件失败时，可以立即切换到备份组件。同时，还需要有正在处理的数据的多个副本。安全性要求最小化数据副本的数量，并在可能的情况下，采用每个组件只了解完成其工作所需的信息的架构。这减少了入侵者访问数据的机会。因此，可用性（复制，多个副本）和安全（专业化，最小副本）之间存在根本的建筑冲突。系统架构师必须在这些根本对立的要求之间找到最佳的折衷方案。6.7将要开发一个信息系统以用于维护关于一个公用事业公司所拥有资产(例如建筑、车辆、设备)的信息。希望该系统可以在新的资产信息可用时，在现场工作的员工可以使用移动设备进行更新。该公司有几个已有的资产数据库，它们应当通过该系统进行集成。基于图6-18中所示的通用信息系统体系结构，为这个资产管理系统设计一个分层体系结构。1.BrowserUI和MobileUI：BrowserUI：浏览器用户界面MobileUI：移动设备用户界面2.中间层（从左到右）：Mobiledevicemanagement：移动设备管理Formsmanager：表单管理器Alertmanager：警报管理器Authenticationandauthorization：认证和授权3.最下面一层（从左到右）：Databasesearch：数据库搜索Databasealerts：数据库警报Databasebrowser：数据库浏览器Databasequerymanagement：数据库查询管理Buildingsdatabase：建筑物数据库Equipmentdatabase：设备数据库Infrastructuredatabase：基础设施数据库Vehicledatabase：车辆数据库6.8使用这里所介绍的语言处理系统通用模型，设计一个系统的体系结构，该系统接受自然语言命令，并将其翻译为数据库查询语言(例如SQL)。Dictionary:字典Abstractsyntaxtree:抽象语法树Lexicalanalysis:词汇分析Partofspeechtagger:词性标注器Commandparser:命令解析器Parameteranalysis:参数分析SQLcodegenerator:SQL代码生成器6.9使用如图6-18中所示的信息系统基本模型，针对一个面向移动设备用于显示某个特定机场航班到达和起飞信息的应用，建议其中应该包含哪些构件?这是一个混合系统，系统的某些元素托管在远程服务器上，而某些元素则内置在应用程序中。您需要考虑信息系统的各个层次，并识别可能包含在每个层次中的组件。这些组件的例子可能包括：第1层（数据库级别）：航班数据库；航班状态数据库；机场信息；第2层（信息检索级别）：状态管理；航班管理；搜索；第3层（用户交互级别）：认证；会话管理；表单处理（）第4层（用户界面）：应用程序UI然后，您需要决定哪些信息系统元素应该在移动设备上托管，哪些应该远程托管。1.数据库级别很明显，试图在应用程序上托管主要的数据库组件是没有意义的，因此在应用程序中，这些被一个数据库查询组件所替代，该组件提供了对这些数据库的访问权限。2.信息检索级别应用程序中需要一个搜索组件，但这实际上应该是运行在服务器上的更广泛数据库搜索的前端。用户感兴趣的航班及其状态信息必须在应用程序中本地收集和管理。3.用户交互级别这也必须在应用程序中处理，尽管它基于存储的信息，例如认证依赖于存储用户的凭据，并在调用应用程序时自动进行认证。4.用户界面级别仅在应用程序中实现第七章设计和实现7.1使用图7-3中所示的表格化表示法对气象站用况“报告状态和重配置”进行描述。你应当对这里所需要的功能做出合理的假设系统：气象站用况：报告状态参与者：气象信息系统、气象站数据：气象站向气象信息系统发送状态更新，提供有关其仪器、计算机和电源供应的状态信息。激励：气象信息系统与气象站建立卫星链接并请求状态信息。响应：状态摘要上传到气象信息系统备注：系统状态通常与天气报告同时被激励。系统：气象站用况：重新配置参与者：气象信息系统、气象站数据：气象信息站向气象站发送重新配置命令。这将其置于远程控制模式，在该模式下，可以从远程系统发送进一步的命令来更新气象站软件。激励：来自气象信息系统的命令。响应：确认系统处于远程控制模式备注：在必须安装软件更新时偶尔被激励。7.3使用UML对于对象类的表示法设计下列对象类，识别属性和操作。根据你自己的经验来决定与这些对象相关联的属性和操作。一个移动电话或者平板电脑上的消息通信系统一个个人计算机的打印机一个个人音乐系统一个银行账户一个图书馆目录这里有许多可能的设计，并且可以给对象增加大量的复杂性。然而，我真正寻找的只是简单对象，这些对象封装了这些工件的主要需求。可能的设计显示在下面的图中。1.Messagingsystem（消息系统）message(status,sender,length,body)（消息（状态、发送者、长度、主体））messagelist（消息列表）attachments（附件）create_message()（创建消息）send_message()（发送消息）copy_message()（复制消息）select_message()（选择消息）edit_message()（编辑消息）add_to_list()（添加到列表）remove_from_list()（从列表中删除）view_attachment()（查看附件）notify()（通知）2.Librarycatalogue（图书馆目录）Publicationrecords（出版物记录）Transactions（交易）Datecreated（创建日期）Dateupdated（更新日期）Permissions（权限）keywordindex（关键词索引）newentry()（新条目）editentry()（编辑条目）deleteentry()（删除条目）search()（搜索）create_index()（创建索引）editpermissions()（编辑权限）recordtransaction()（记录交易）3.Musicsystem（音乐系统）songstore（歌曲库）playlists（播放列表）volume（音量）nowplaying（正在播放）recentlyplayed（最近播放）display（显示）batterylevel（电池电量）play()（播放）stop()（停止）selectplaylist()（选择播放列表）selectsong()（选择歌曲）search()（搜索）randomplay()（随机播放）repeat()（重复）changevolume()（改变音量）displaystatus()（显示状态）4.Printer（打印机）document（文档）tonerlevel（墨粉水平）paperstatus（纸张状态）errorstatus（错误状态）display（显示）setup_printer()（设置打印机）print()（打印）cancelprintjob()（取消打印作业）selftest()（自检）startup()（启动）shutdown()（关闭）5.BankAccount（银行账户）accountnumber（账号）accounttype（账户类型）dateopened（开户日期）dateclosed（关闭日期）balance（余额）transactionlist（交易列表）overdraftlimit（透支限额）open()（打开）close()（关闭）credit()（信贷）debit()（借记）showbalance()（显示余额）editoverdraftlimit()（编辑透支限额）addtransaction()（添加交易）listtransactions()（列出交易）7.7画一个顺序图展示小组日程系统在一组人正在安排一个会议时对象间的交互Organizer（组织者）G:GroupDiary（G组日记）D1:Diary（D1日记）D2:Diary（D2日记）D3:Diary（D3日记）Setup(window,participants)（设置（窗口，参与者））getAvail(W1,P1)（获取可用性（W1，P1））Availdates(p1)（可用日期（p1））getAvail(W2,p2)（获取可用性（W2，p2））Availdates(p2)（可用日期（p2））getAvail(W3,p3)（获取可用性（W3，p3））Availdates(p3)（可用日期（p3））reserve(date)（预订（日期））confirm(date)（确认（日期））report(window)（报告（窗口））[Datesavailable]：日期可用[Nodatesavailable]：没有可用日期在上述图表中，假设会议有3名参与者，包括一名组织者。组织者提出一个会议时间“范围”，涉及相关参与者。团队日历会依次与每位参与者的日历进行协调，根据他们的时间安排来调整这个范围。例如，如果组织者提议的会议时间是6月18日至19日，团队日历首先查看组织者的日历（D1），确认这些日期是否有空。然后，团队日历将这个确认后的时间范围告知参与者D2的日历，而不是最初提议的时间范围。如果在这个时间范围内没有找到大家都有空的日期，系统会通知组织者。如果有可行的日期，系统会选定一个日期，更新所有相关日历，并通知组织者确认。7.9举例解释为什么一组人在开发一个软件产品时配置管理系统很重要配置管理的目标有两个：一是确保不同开发人员对系统的更改不会相互影响；二是保证能够随时创建系统的特定版本。如果没有配置管理，就很难追踪每位开发人员对代码所做的修改，而且后一个程序员的改动可能会覆盖前一个程序员的成果。比如，一个程序员可能修改了一个组件来提升性能，而另一个程序员可能修复了该组件的一个功能错误。如果没有配置管理，最后提交代码的开发者可能会覆盖之前的改动，导致之前的修改丢失。此外，一个系统通常由多个组件组成，每个组件都有多个版本，每个版本都有其特定用途。例如，可能存在适用于Windows、Linux和MacOS等不同平台的系统版本。这些版本中有些组件是特定的，有些是共享的，如果没有配置管理工具的帮助，组装这些版本很容易出错。一旦在某个版本中错误地包含了不合适的组件，就很可能导致软件后续出现故障。7.10一个小公司开发了一个可以专门为每个客户专门配置的专业软件产品。新客户通常都有一些特定的需求要加入到系统中，他们会为这些需求的开发和集成支付费用。该软件公司有一个机会去投标一个新项目，这将会使客户基数翻倍。新客户希望参与一些系统的配置。解释为什么在这种情况下让这个软件产品开源对于拥有该软件的公司而言可能是个好主意开源的主要好处在于它将开发开放给广泛的开发人员，从而加速产品的开发和调试。如果客户群翻倍，小公司将面临巨大压力，因为他们需要招募大量新员工，因此通过开源可以降低扩展成本。在这种情况下，由于产品专门针对不同用户的需求，拥有该软件的公司仍然可以向这些用户收取对系统进行更改的费用。因此，销售软件的收入损失可以通过增加的服务更多客户的努力来弥补。此外，大公司通常不愿意从可能倒闭的小公司购买产品。某种程度上，开源为客户提供了保障，即使原始软件所有者不可用，他们也可以获得源代码，从而继续维护他们的系统。最后，开源可能会增加人们对公司产品的了解，从而吸引更多客户。第八章软件测试8.2为什么测试只能表明错误的存在，而不是显示没有错误存在?假设对一个程序进行穷举测试，即检查每个可能的有效输入，是不可能的（对于所有但微不足道的程序都是如此）。测试用例要么没有揭示程序中的错误，要么揭示了程序错误。如果它们揭示了程序错误，那么它们就证明了存在错误。然而，如果它们没有揭示错误，这仅仅意味着它们已经执行了一个对于所选输入来说没有错误的代码序列。对同一代码序列的下一次测试（使用不同的输入）可能会揭示错误。8.4你被安排测试“Paragraph”对象中一个名为catWhiteSpace的方法，该方法在一个段落里面将所有连续的空格符替换成单个的空格符。为这个例子确定测试划分，并且为catWhiteSpace方法设计一组测试。测试分为以下几个部分：只包含单个空格的字符串。字符串中间有连续空格。字符串开头或结尾有连续空格。测试示例包括：Thequickbrownfoxjumpedoverthelazydog（单个空格）Thequickbrownfoxjumpedoverthelazydog（中间空格数量不同）“Thequickbrownfoxjumpedoverthelazydog”（开头有空格序列）“Thequickbrownfoxjumpedoverthelazydog”（结尾有空格序列）“Thequickbrownfoxjumpedoverthelazydog”（开头两个空格）“Thequickbrownfoxjumpedoverthelazydog”（开头多个空格）“Thequickbrownfoxjumpedoverthelazydog”（结尾两个空格）“Thequickbrownfoxjumpedoverthelazydog”（结尾多个空格）8.5什么是回归测试?解释该如何使用自动化测试以及JUnit这样的测试框架来简化回归测试回归测试是在开发新功能或更改系统时，对已经实现的功能运行测试的过程。回归测试检查系统更改是否没有给先前实现的代码引入问题。自动化测试和测试框架（如JUnit）极大地简化了回归测试，因为每次更改时都可以自动运行整个测试集。自动化测试包括它们自己的检查，以确定测试是否成功，否则检查回归测试成功与否的成本很低。8.7编写一个可以用于为野外气象站系统设计测试的场景一个可能的气象站系统高级测试场景是：约翰是一名气象学家，负责为明尼苏达州制作气象地图。这些地图是使用气象绘图系统从自动收集的数据中生成的，它们显示了明尼苏达州天气的不同数据。约翰选择要生成地图的区域、地图的时间段，并请求生成地图。在创建地图时，约翰运行一个气象站检查，检查所有远程收集的气象站数据，并查找数据中的间隙——这意味着远程气象站存在问题。这里有许多可能的替代场景。它们应该确定所涉及的参与者的角色，并讨论该角色可能执行的典型任务。8.8你是如何理解术语“压力测试”的?谈一谈如何对Mentcare系统进行压力测试压力测试是指故意将系统的负载增加到超过其设计限制，以观察它如何应对高负载。系统应该优雅地降级，而不是崩溃Mentcare系统被设计为客户端-服务器系统，具有下载到客户端的可能性。要对系统进行压力测试，需要安排(a)许多不同的诊所同时尝试访问系统，以及(b)向系统中添加大量记录。这可能涉及使用模拟系统来模拟多个用户第九章软件演化9.1为什么在现实环境中使用的软件系统必须进行变更，否则就会逐渐失去其作用?系统必须改变或逐渐变得不那么有用，原因有以下几点：系统的存在改变了其环境中的工作方式，这产生了新的需求。如果这些需求得不到满足，系统的有用性就会下降。使用该系统的业务会根据市场力量的变化而变化，这也会产生新的系统需求。系统的外部法律和政治环境发生变化，产生了新的需求。出现了提供显著好处的新技术，系统必须改变以利用这些技术。9.4什么情况下一个组织会决定废弃一个被评估为高质量和商业价值的系统?软件可能被废弃和重写的情况示例包括：当维护成本高且组织决定投资新硬件时。无论如何，这都将涉及大量的转换成本，因此可能会借机重写软件。当业务流程发生变化并且需要新的软件来支持该流程时。当用于开发软件的工具和语言的支持不可用时。这在早期的4GL中是一个特别的问题，在许多情况下，供应商已经不再营业。根据当地情况，还有其他原因可能导致软件被废弃。9.5对遗留系统演化的策略选择是什么?什么时候你通常会替换整个或部分系统而不是继续进行软件维护?遗留系统演进的战略选择是：放弃对系统的维护，并用新系统替换它。继续维护系统。进行一些再工程（系统改进），使系统更易于维护并继续维护。将系统的现有功能封装在包装器中，并通过编写调用现有系统作为组件的新代码来添加新功能。将系统分解为独立的单元，并将它们包装为组件。这与上述解决方案类似，但在系统的使用方式上提供了更大的灵活性。通常，在以下情况下会选择替换选项：系统的硬件平台正在被替换，公司希望标准化一些与当前系统不一致的开发方法，某些主要子系统正在被替换（例如数据库系统），或者现有系统的技术质量较低，并且目前没有用于再工程的工具。9.7你是公司的一名软件项目经理，专门从事离岸石油业的软件开发，你现在需要发现影响公司软件系统的维护性的因素。你该如何设置一个程序去分析维护的过程以及提出并度量软件的维护指标?这是一个非常开放的问题，有许多可能的答案。基本上，学生应该确定影响可维护性的因素，例如（程序和数据的复杂性、有意义的标识符的使用、编程语言、程序文档等）。然后，他们应该建议如何在维护成本已知的现有系统中评估这些因素，并讨论交互问题。方法应该是发现那些维护成本特别高的程序单元，并评估这些组件和其他组件的成本因素。然后检查相关性。其他因素可能导致异常，因此应该在问题组件中寻找这些因素。9.8简要描述3种不同类型的软件维护。为什么有时候很难区分它们?软件维护的三种主要类型是：纠错维护或故障修复。对系统进行的更改是为了修复报告的故障，这些故障可能是程序错误或规格错误或遗漏。适应性维护或环境适应。更改软件以使其适应环境的变化，例如其他软件系统的变化。完善性维护或功能添加。这涉及向系统添加新的功能或特性。有时它们很难区分，因为同一组更改可能涵盖所有三种类型的维护。例如，系统中报告的故障可能通过升级其他一些软件来修复，然后使系统适应使用这个新版本（纠错+适应）。新软件可能具有额外的功能，并且作为适应性维护的一部分，可能会添加新的特性以利用这一点。第二十二章项目管理22.2解释最好的程序设计者为什么不一定能成为最好的软件管理者。22.1节中列出的管理活动可以帮助你回答这个问题管理活动，如提案撰写、项目规划和人员选择，需要一套技能，包括展示和沟通技能、组织技能以及与其他项目团队成员沟通的能力。编程技能与这些技能不同（事实上，程序员经常被批评缺乏人际交往技能），所以不能说优秀的程序员可以重新调整他们的能力成为优秀的管理者。22.4除了图22-1中所列的风险，识别可能在软件项目中出现的其他6种风险其他可能的风险是：技术：在达到预期交易限制之前，通信网络饱和。人员：可用人员的技能水平低于预期。组织：组织变革意味着项目进度加快。工具：软件工具无法处理大型系统可用的数据量。需求：引入了新的非功能性需求，需要对系统架构进行更改。估计：软件的难度被低估了。22.6价格锁定的合同，即承包人以某个确定价格投标一系统开发，是一种将项目风险从委托人转移给承包人的做法。如果出现问题，需要由承包人承担。分析一下为什么这种合同容易增加产品风险的可能性固定价格合同增加了产品风险的可能性，因为它们从开发过程中移除了选项。因为合同是固定价格的，承包商自然不愿意增加项目的努力或时间支出，因为这会减少他们在工作中的利润。因此，如果出现问题，他们会寻找方法来减少产品的范围或降低产品开发的成本（例如，通过减少用于测试的努力）。这两个因素都可能导致产品不符合客户的预期22.8在极限编程团队中许多管理决策权被下放到团队成员手中，这会带来哪些问题?虽然将管理决策下放到团队的概念在激励方面很有吸引力，但可能会出现两种类型的问题：决策可能主要受技术考虑因素的影响，而不是业务决策