OOAD复习资料New.doc

在开始设计或实现之前试图定义大多数需求？（错） 在编程和测试之前定义和提交完整的架构。（错） UP中，所有开发活动和制品可选，根据特定问题和需要选择制品。（对） UP和瀑布模型不同，不是在开始就定义全部需求。（对） 初始阶段不是需求阶段，而是研究可行性的阶段，要进行充分的调查以确定继续或终止项目。（对） 细化阶段也不是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题的阶段。（对）UP是迭代和不断进化的，所有实现前的需求和设计是不完整的。（对） 对整个项目不应有详细的计划。应该制定估计结束日期和主要里程碑的阶段计划，但是不要对这些里程碑详细定义细粒度的步骤。只能预先对一个迭代制定更为详细的迭代计划。详细计划是由一次次迭代的调整而完成的。（对） 不要单独建模，而是结对(或三个人)在白板上建模，同时记住建模的目的是发现、理解和共享大家的理解。（对） 采用敏捷开发并不意味着不用建模。（对） 不要对所有或大多数软件设计建模或应用UML。只需要对设计空间中不常见、困难和棘手的一小部分问题建模和应用UML。（对） 大部分迭代方法建议迭代时间在2－6周之内。小步骤、快速反馈和调整是迭代开发的主要思想，时间过长会增加风险。（对） 迭代的输出不是实验性的或将丢弃的原型，迭代开发也不是构造原型，其输出是最终系统的产品子集。（对） 用例部分会使用一些UML用例图，但绝不会引入大量图形。初始阶段，主要以文字方式表达需求。（对） 初始阶段定义大部分需求。（错） 期望初始阶段的预算和计划是可靠的。（错） 定义架构（应该在细化阶段以迭代方式定义架构）。（错） 认为正确的工作顺序应该是：定义需求，设计架构，实现。（错） 没有业务案例或设想制品。（错） 详细编写所有用例。（错） 没有详细编写任何用例。与之相反，应该详细编写10%-20%的用例以便获得对问题范围的真实认知。（对） 用例描述了从参与者（Actor）角度看系统（黑盒子）做了什么 WHAT。（对） 用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。（对） 用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。（对） 用例主要是说明系统如何工作的功能性或行为性需求。 （对） 用例中，一个用户可以充当多种角色。（对） 主成功场景：典型的、无条件的、理想方式的成功场景 扩展：成功或失败的替代场景 用例之重在于编写文本，用例图和用例关系在编写用例工作中是次要的。（对） 世界级用例专家都对用例图和用例关系不予重视，而是着重于编写文本。（对） 初始阶段并是不要以向详细形式编写用例。（对） 细化阶段结束时，详细编写了80-90%的用例。（对） 构造阶段编写用例，在这个阶段可能涉及编写一些次要的用例，也可能举办需求讨论会，但是次数大大少于细化阶段。（对） 应该早在完整地分析和记录大多数需求之前，尽早进行具有产品品质的编程和测试。（对） 通常在若干迭代内对同一用例的不同场景进行开发，渐进的扩充系统直到最终完成所有需要的功能。（对） 细化不是设计阶段，不是要完成所有模型的开发。（对） 细化不是要创建可以丢弃的原型，所产生的代码应该是最终系统的产品化子集。（对） 细化阶段没有处理具有风险的元素和核心架构。（错） 认为细化阶段是进行概念验证编程的阶段，而不是对产品核心架构编程的阶段。（错） 避免瀑布思维倾向，为完成详尽或正确的领域模型而进行大量建模工作。这些方式都应避免，并且这种过量的建模工作反而会导致分析停滞，这种调查几乎不会有什么回报。（对） 领域模型是对所关注的现实世界领域中事物的可视化，而不是诸如java或C#类的软件对象，或有职责软件对象。 以下元素不适用于领域模型：软件制品，例如窗口或数据库、职责或方法。 库存、金融、卫生等很多领域都存在已经发布的、绘制精细的领域模型和数据模型。以此为基础修改为领域模型。（对） 领域模型是从概念角度出发，是否需要记录关联，基于现实世界的需要，而不是基于软件的需要，尽管在实现过程中，会出现大量对关联的需要。（对） 领域模型关联表示中，阅读导向箭头对模型不具有特别意义，只是对阅读图的人有所帮助。（对） 关联命名中，以“类名－动词短语－类名”的格式为关联命名，其中的动词短语构成了可读的和意义的顺序。（对） 关联多重性的值表示在特定的时刻（而不是在某个时间跨度内）有效关联的实例数量。（对） 没有唯一正确的领域模型。（对） 用例文本及其表示的系统事件是创建SSD的输入。（对） SSD中的操作可以在操作契约中进行分析，在词汇表中被详细描述，并且作为设计协作对象的起点。（对） 为所有系统操作产生完整详细的后置条件集合是不可能的，或是没必要的。 初始：初始阶段不会引人契约，因为过于详细。 细化：如果使用契约的话，大部分契约将在细化阶段编写，这时已经编写了大部分的