《OOAD复习资料New》由会员分享，可在线阅读，更多相关《OOAD复习资料New（19页珍藏版）》请在金锄头文库上搜索。
1、在开始设计或实现之前试图定义大多数需求？(错)在编程和测试之前定义和提交完整的架构。（错）中，所有开发活动和制品可选，根据特定问题和需要选择制品。（对）UP和瀑布模型不同，不是在开始就定义全部需求。（对）初始阶段不是需求阶段，而是研究可行性的阶段，要进行充分的调查以确定继续或终止项目.（对)细化阶段也不是需求或设计阶段，而是迭代地实现核心架构并解决高风险问题的阶段。(对）P是迭代和不断进化的，所有实现前的需求和设计是不完整的。(对）对整个项目不应有详细的计划。应该制定估计结束日期和主要里程碑的阶段计划，但是不要对这些里程碑详细定义细粒度的步骤。只能预先对一个迭代制定更为详细的迭代计划.详细计划
2、是由一次次迭代的调整而完成的。(对)不要单独建模，而是结对(或三个人)在白板上建模,同时记住建模的目的是发现、理解和共享大家的理解。(对)采用敏捷开发并不意味着不用建模。（对）不要对所有或大多数软件设计建模或应用UML。只需要对设计空间中不常见、困难和棘手的一小部分问题建模和应用UML。（对)大部分迭代方法建议迭代时间在-6周之内。小步骤、快速反馈和调整是迭代开发的主要思想，时间过长会增加风险。（对）迭代的输出不是实验性的或将丢弃的原型，迭代开发也不是构造原型，其输出是最终系统的产品子集。（对）用例部分会使用一些ML用例图，但绝不会引入大量图形。初始阶段，主要以文字方式表达需求。（对）初始阶段
3、定义大部分需求。（错）期望初始阶段的预算和计划是可靠的。（错）定义架构（应该在细化阶段以迭代方式定义架构）。(错）认为正确的工作顺序应该是:定义需求，设计架构,实现。(错）没有业务案例或设想制品。（错)详细编写所有用例。(错）没有详细编写任何用例.与之相反,应该详细编写1020的用例以便获得对问题范围的真实认知。（对）用例描述了从参与者（Ato）角度看系统（黑盒子)做了什么 WHA.（对）用例是文本形式的情节描述，用以说明某参与者使用系统以实现某些目标。(对）用例是文本文档，而非图形；用例建模主要是编写文本的活动，而非制图。(对） 用例主要是说明系统如何工作的功能性或行为性需求。(对）用例中，
4、一个用户可以充当多种角色.(对）主成功场景:典型的、无条件的、理想方式的成功场景扩展：成功或失败的替代场景用例之重在于编写文本，用例图和用例关系在编写用例工作中是次要的。（对)世界级用例专家都对用例图和用例关系不予重视，而是着重于编写文本。（对)初始阶段并是不要以向详细形式编写用例。（对）细化阶段结束时，详细编写了090%的用例。(对）构造阶段编写用例，在这个阶段可能涉及编写一些次要的用例,也可能举办需求讨论会,但是次数大大少于细化阶段。(对)应该早在完整地分析和记录大多数需求之前,尽早进行具有产品品质的编程和测试。(对)通常在若干迭代内对同一用例的不同场景进行开发，渐进的扩充系统直到最终完成
5、所有需要的功能.(对)细化不是设计阶段,不是要完成所有模型的开发。(对）细化不是要创建可以丢弃的原型，所产生的代码应该是最终系统的产品化子集。(对)细化阶段没有处理具有风险的元素和核心架构。(错)认为细化阶段是进行概念验证编程的阶段，而不是对产品核心架构编程的阶段。（错)避免瀑布思维倾向，为完成详尽或正确的领域模型而进行大量建模工作。这些方式都应避免，并且这种过量的建模工作反而会导致分析停滞,这种调查几乎不会有什么回报。（对）领域模型是对所关注的现实世界领域中事物的可视化，而不是诸如va或C类的软件对象,或有职责软件对象。以下元素不适用于领域模型：软件制品，例如窗口或数据库、职责或方法。库存、
6、金融、卫生等很多领域都存在已经发布的、绘制精细的领域模型和数据模型。以此为基础修改为领域模型.（对)领域模型是从概念角度出发，是否需要记录关联，基于现实世界的需要，而不是基于软件的需要，尽管在实现过程中,会出现大量对关联的需要。（对）领域模型关联表示中，阅读导向箭头对模型不具有特别意义，只是对阅读图的人有所帮助。（对）关联命名中，以“类名动词短语-类名”的格式为关联命名,其中的动词短语构成了可读的和意义的顺序。(对)关联多重性的值表示在特定的时刻（而不是在某个时间跨度内)有效关联的实例数量。（对）没有唯一正确的领域模型。(对）用例文本及其表示的系统事件是创建SD的输入.(对)SD中的操作可以在
7、操作契约中进行分析,在词汇表中被详细描述,并且作为设计协作对象的起点。(对)为所有系统操作产生完整详细的后置条件集合是不可能的，或是没必要的。初始：初始阶段不会引人契约，因为过于详细.细化：如果使用契约的话,大部分契约将在细化阶段编写，这时已经编写了大部分的用例,只对最复杂和微妙的系统操作编写契约。尽早编程、测试和演示有助于尽早引发不可避免的变更。ML包图也可作为软件架构文档中的视图，其主要输入是补充性规格说明中记录的架构方面的约束和要点。敏捷构建静态模型和动态模型提倡并行创建模型:花费较短的时间创建交互图（动态），然后转到对应的类图(静态),交替进行。通信图中，一般不为第一个消息使用顺序编号
8、.RDD中，认为软件对象具有职责，即对其所作所为的抽象。对于软件领域对象来说，由于领域模型描述了领域对象的属性和关联，因此其通常产生与认知相关的职责。在绘制ML交互图时,就是在决定职责的分配。绘制UML交互图以及编写代码时,就可以运用GRAS原则了。对于用例中一系列特定事件,SD展示了直接与系统交互的外部参与者,系统作为黑盒以及由参与者发起的系统事件.SD由用例导出，若用例很清楚，可以不用画SSD,可以以用例名命名SSD.不用为所有场景创建SD。（对）初始：不会引入SSD,除非对所涉及的技术进行估算。细化:大部分SSD在此阶段完成。有利于系统事件的细节以便明确系统必须设计和处理的操作，有利于编
9、写操作契约，有利于估算的支持。组合聚集部分，容器容纳内容,记录者进行记录,封装的容器或记录器是创建其容纳或记录的事物很好的候选者。对稳定的元素和普遍的元素的高耦合一般不是一个问题。一个aaJ2EE应用对 Ja库 （ja.til, 等等）的耦合没有问题， 因为它们是稳定的，并被普遍使用。不要花费太多时间到“未来验证”的或没有实际理由的低耦合设计上。对于同一用例场景的所有系统事件使用相同的控制器类。为了使发送者对象能够向接收者对象发送消息,发送者必须具有接收者的可见性,即发送者必须拥有对接收者对象的某种引用或指针。不要测试对象的类型,也不要使用条件逻辑来执行基于类型的不同选择。UP项目将其工作和迭
10、代组织为四个主要阶段:w 初始（Inception）:大体上的构想、业务案例、范围和模糊评估 可行性研究.w 细化（Ebation）:已精化的构想、 核心架构的迭代实现、 高风险的解决、确定大多数需求和范围以及进行更为实际的评估。 w 构造(Constrction):对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署 。w 移交(Tnsiton) 进行bea测试和部署。P核心思想： 短时间定量迭代、进化和可适应性开发. U中:在早期迭代中解决高风险和高价值的问题。 不断地让用户参与评估、反馈和需求。 在早期迭代中建立内聚的核心架构。 不断地验证质量;提早、经常和实际地测试。 实行变更请
11、求和配置管理。迭代的一个关键思想是时间定量或时长固定。约定了时间，不许按时完成，实在完不成,不能推迟时间,而是剔除一些任务或需求.早期迭代远离系统的“真实路径。通过反馈和调整，系统向最适宜的需求和设计收敛.在后期迭代中，很少会在需求上产生显著变化,但是存在这种可能性.这种后期的变化可能会给组织带来业务竞争优势. 如何在迭代项目中处理变更w 一方面认同和稳定一组需求，另一方面接受需求不断变更的事实。w 每次迭代选择一小组需求,快速设计、实现和测试。w 早期迭代可能并不准确，但是快速实施可以得到快速反馈-来自用户、开发人员和测试人员的反馈。w 早期迭代中系统偏离正确轨迹的程度会大于后继迭代.随着时
12、间的发展，系统将会收敛。w 最好及早解决和验证具有风险的、关键的设计决策。初始阶段要解决的问题:涉众是否就项目设想基本达成一致;项目是否值得继续进行认真研究？ 初始阶段会创建的制品 设想和业务用例(Visionand Bsiess Cs)描述高阶目标与约束、业务案例，并提供执行摘要。 用例模型（eCase ol)描述功能需求。在初始阶段,确定大部分用例名称，详细分析10的用例。 补充性规格说明(Supplemntar Spciition)描述其他需求，主要是非功能性需求。初始阶段,多考虑关键的非功能性需求，其对架构将会产生主要影响。 词汇表（Glossry)关键领域术语和数据字典。 风险列表和
13、风险管理计划(ikLstRiskMaagentPln）描述风险(业务、技术、资源和进度）及应对和缓解的方法. 原型和概念验证（Protpes nd roofofconcepts) 澄清设想，验证技术思路. 迭代计划（Iertion Plan）描述第一个细化迭代的任务。 阶段计划和软件开发计划(hase lan & SftwreDvelopment Pln）对细化阶段的持续时间和工作量进行粗略估计。工具、人员、教育和其他资源。 开发案例（vepment Case）就待定项目,对U步骤和制品进行定制的描述。在UP中,通常会为特定项目进行定制。关键的UP需求制品 用例模型一组使用系统的典型场景.主要
14、用于功能（行为的）需求。 补充规格说明基本上是用例之外的所有内容.主要用于所有非功能需求，例如性能或许可发布. 该制品也用来记录没有表示(或不能表示)为用例的功能特性，例如报表生成。 词汇表-定义重要的术语，数据字典记录了关于数据的需求，例如有效性规则，容许值等.对象属性、操作调用的参数、报表布局等. 设想概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。设想也概括了项目的业务案例。设想是简短的执行概要文档，用以快速了解项目的主要思想。 业务规则领域规则，描述了凌驾于某一软件项目的需求或政策,这些规则是领域或业务所要求的,并且许多应用应该遵从这些规则。例如政府的税收法规. 领域规则
15、的细节可以记录在补充性规格说明中，因为这些规则通常更为持久，对不止一个软件项目适用,应将其放入集中的业务规则制品，以便重用。有三种外部参与者: 主要参与者: 具有用户目标，并通过使用S的服务完成。通常用来发现驱动用例的用户目标。 协助参与者： 为u提供服务(例如，信息服务)。自动付费授权服务即是一例.协助参与者通常是计算机系统，但也可以是组织或人。协助参与者通常是为了明确外部接口和协议。 为何确定协助参阅者?为了明确外部接口或利益。 幕后参与者:在用例行为中具有影响或利益，但不是主要或协助参与者。例如，政府收税机构。通常是为了确保确定并满足所有必要的重要事物.如果不明确地对幕后参与者进行命名,则有时很容易忽略其影响或利益。不同形式化程度或格式编写用例 摘要-简洁的一段式概要,通常用于主成功场景。何时使用 在早期需求分析过程中，为快速了解主体和范围使用.可能只需要几分钟编写.
