OOAD经典复习题

Createdbywhulelouchpage16/13/2020仅供个人使用Copyright©whulelouch1什么是面向对象分析与设计分析强调的是对问题和需求的调查研究而不是解决方案。设计强调的是满足需求的概念上的解决方案，而不是其具体实现。面向对象的分析过程中，强调的是在问题领域内发现昂和描述对象或概念。面向对象的设计过程中，强调的是定义软件对象以及他们如何协作以实现需求。2什么是UML统一建模语言UML是描述，构造和文档化系统的可视化语言。UML是图形化表示法的事实标准，用来绘制和展示与软件（特别是OO软件）相关的图形以及文字。3可视化建模的优点（与传统建模相比）图可以帮助我们更为便利的观察全景，发现软件元素或分析之间的联系，同时允许我们忽略或隐藏旁枝末节，绘制或阅读UML意味着我们可以用更加可视化的方式工作，这是UML以及其他可视化建模的本质价值。4什么是UP，UP的特点以及解决的问题软件开发过程(softwaredevelopmentprocess)描述了构造部署以及维护软件的方式。统一过程是一种流行的构造面的昂对象系统的迭代的软件开发过程，UP把普遍认可的最佳实践结合起来，成为联系紧密的具有良好文档的过程描述。UP是迭代过程；UP时间提供了如何实施OOA/D的示范结构；UP具有灵活性和开放性。可以应用于轻量级和敏捷方法。5什么是迭代和进化式开发迭代开发是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期小项目，称为迭代，每次迭代都产生经过测试，继承并可执行的局部系统，每次迭代都具有各自的需求分析，设计，实现和测试活动。迭代生命周期基于对经过多系迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为合适的西戎，随着时间和一次又一次迭代的递进，系统增量式地发展完善，这一方法也被称为迭代和增量式开发，因为反馈和调整使规格说明和设计不断进化，所以这种方法也被称为迭代和进化式开发。6对象之间的可见性瀑布生命周期7风险驱动and客户驱动UP提倡风险驱动和客户驱动相结合的迭代计划。这意味这早期的迭代目标要能够识别和降低最高风险，并且能够构造客户最关心的可视化特性风险驱动迭代开发明确地包含了一架构为中心迭代开发的时间，意味着早期迭代要致力于核心框架的构造，测试和稳定。8什么是敏捷方法敏捷方法通常是应用时间定量的迭代和进化式开发，使用姿势因计划，提倡增量交付并包含其他提倡敏捷性（快速和灵活的相应变更）的价值和实践。敏捷观点：个体和迭代，超越过程和工具；工作的软件，超越完整的文档；客户协作，超越合同谈判；响应变更，超越履行计划9UP的四个阶段UP项目将工作和迭代组织为四个主要的阶段：①初始阶段：大体上的构想，业务案例，范围和模糊评估②细化阶段：已经精化的构想，核心架构的迭代实现，高风险的解决，确定大多数的需求和范围以及进行更为实际的评估③构造阶段：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署。④移交阶段：进行beta测试和部署。UP科目：业务建模：领域模型制品使领域中重要概念的可视化需求：用以捕捉功能需求和非功能需求的用例模型及其表系统的规格说明制品设计：设计模型制品，用于软件对象进行设计10UP科目（规程）业务建模，需求，设计，实现，测试，部署，配置和变更管理，项目管理，环境。11初始阶段的持续时间Createdbywhulelouchpage26/13/2020仅供个人使用Copyright©whulelouch初始阶段主要是为项目目标建立一些初始的共同构想，确定项目是否可行，并决定是否值得进入细化阶段加以认真研究。如果与西安就决定项目必须进行，并且项目明显是可行的，那么初始阶段的时间将会非常短暂，这时候，初始阶段可能只包含第一次需求研讨会，并为第一次迭代制定计划，然后即快速地。初始阶段：建立项目共同设想和基本范围的比较简短的起始步骤。进入到细化阶段。12初始阶段创建的制品设想和业务用例，用例模型，补充性规格说明，词汇表，风险列表和风险管理计划，原型和概念验证，迭代计划，阶段计划和软件开发计划，开发案例13需求的定义需求就是系统必须提供的能力和必须遵守的条件。14进化式需求与瀑布式需求差异UP的需求管理定义中使用了”不断变更“一词，UP能包容需求中的变更，并将其作为项目的基本驱动力，这便是进化式需求和瀑布需求的核心差异。需求寻找方法：与客户一同编写用例；开发者和客户共同参与需求讨论会；请客户代理参加焦点小组；向客户演示每次迭代的成果以求的反馈15需求的类型和种类在统一过程中，需求按照“FURPS+”模型进行分类，这是一种有效的记忆方法，其含义如下：功能性（Functional）：特性、功能、安全性。可用性（Usability）：人性化因素、帮助、文档。可靠性（Reliability）：故障频率、可恢复性、可预测性性能（Performance）：响应时间、吞吐量、准确性、有效性、资源利用率。可支持性（Supportability）：适应性、可维护性、国际化、可配置性“FURPS+”中“+”是指一些辅助性的和次要的因素，比如：实现（Implementation）：资源限制、语言和工具、硬件等。接口（Interface）：强加于外部系统接口之上的约束操作（Operation）：对其操作设置的系统管理包装（Packaging）：例如物理的包装盒授权（Legal）：许可证或其他方式其中某些需求可以统称为质量属性（qualityattribute）、质量需求(qualityrequirement)或系统的“某属性”。这些需求包括：可用性、可靠性、性能和可支持性。在一般使用中，需求按照功能性（行为的）和非功能性（其他所有的行为）来分类，有些人不喜欢这种宽泛的分类方式，但这种方式已被广泛采用。16UP制品如何组织需求UP提供了一些需求制品。同所有UP制品一样，它们都是可选的。其中关键的制品包括：》用例模型：一组使用系统的典型场景。主要用于功能需求》补充性规格说明：基本上是用例之外的所有内容。主要用于所有非功能需求，例如性能或许可发布。该制品也用来记录没有表示为用例的功能特性，例如报表生成》词汇表：词汇表以最简单的形式定义重要的术语。同时也包含了数据字典（datadictionary）的概念，其中记录了关于数据的需求，例如有效性规则，容许值等。词汇表可以详述任何元素：对象属性、操作调用的参数、报表布局等。》设想：概括了高阶需求，这些需求在用例模型和补充性规格说明中进行细化。设想也概括了项目的业务案例。设想是简短的执行概要文档，用以快速了解项目的主要思想。》业务规则：业务规则（也称为领域规则）通常描述了凌驾于某一软件项目的需求或政策，这些规则是领域或业务所要求的，并且许多应用应该遵从这些规则。政府的税收法规是一个例子。领域规则的细节可以记录在补充性规格说明中，但是因为这些规则通常更为持久，并且对不止一个软件项目适用，所以应将其放入集中的业务规则制品（供公司的所有分析员共享），以便在这方面做出的分析工作能够被更好的重用。17参与者，场景和用例得定义Createdbywhulelouchpage36/13/2020仅供个人使用Copyright©whulelouch参与者（actor）是某些具有行为的事物，可以是人（由角色标识）、计算机系统或组织。场景（scenario）是参与者和系统之间的一系列特定的活动和交互，也称为用例实例（usecaseinstance）。场景是使用系统的一个特定的情节或用例的一条执行路径。通俗地讲，用例(usecase)就是一组相关的成功和失败场景集合，用来描述参与者如何使用系统来实现其目标。18为什么要使用用例？虽然这种方法看起来像随意的注释，但是极为重要。研究人员设计了他们自己能够理解的复杂分析方法，但是会使一般的业务人员迷惑不解。而在软件项目中，缺少用户参与是项目的主要原因之一，所以任何有利于用户参与的方法是绝对值得的。用例的另一个价值是强调了用户的目标和观点。我们会提出这样的问题：“谁使用系统？他们使用的典型场景是什么？他们的目的是什么？”与查询系统特性清单相比，以上问题更强调以客户为中心。富有创造力的人经常会将简单的思想变得晦涩并且过于复杂。我们经常会发现，用例建模新手过于关心那些次要的问题，比如用例图、用例关系、用例包等，而不是致力于简单地编写文本情节的实际工作中。用例的优越性就在于，能够根据需要对复杂程度和形式化程度进行增减调节。定义：用例是功能性需求吗？还有什么需求？它们的目的作用？答：用例就是需求，主要是说明系统如何工作的功能性或行为性需求。按照“FURPS+”用例强调了“F”,但也可以用于其它类型特别是与用例紧密相关的那些类型。在统一过程和其他现在方法中，用例被推荐作为发现和定义需求的核心机制。目的：用例的主要思想是为功能性需求编写用例从而降低详细的老式特性列表的重要性或者减少这种列表的使用。。19用例的三种常用描述形式表示法：用例的三种常用形式用例能够以不同形式化程度或格式进行编写：摘要--简洁的一段式摘要，通常用于主成功场景，前例中的处理销售就是摘要形式的用例。何时使用？在早期需求分析过程中，为快速了解主题和范围。可能只需要几分钟进行编写。非正式--非正式的段落格式。用几个段落覆盖不同场景。前例中处理退货就是非正式形式的用例。何时使用？同上详述--详细编写所有步骤及各种变化，同时具有补充部分，如前置条件和成功保证。何时使用？确定并以摘要形式编写了大量用例后，在第一次需求讨论会中，详细地编写其中少量（例如10%）的具有重要架构意义和高价值的用例。20什么是领域模型领域模型(domainmodel)是对领域类或现实世界中对象的可视化表示。领域模型也称为概念模型、领域对象模型和分析对象模型。定义：在UP中，术语领域模型指的是对现实世界概念类的表示，而非软件对象的表示。该术语并不是指用来描述软件类、软件架构领域层或有职责软件对象的一组图。UP对领域模型的定义是，可以在业务建模科目中创建的制品之一。更准确地讲，UP领域模型是UP业务对象模型(BOM)的特化，“专用于解释业务领域中重要的‘事物’和产品”也就是说，领域模型专注于特定领域。更为广泛的BOM是扩展的、通常十分庞大和难以创建的多领域模型，BOM覆盖整个业务及其所有子域，本章并不涵盖这部分内容，并且也不提倡创建BOM（因为需要在是实现前进行大量建模）。21为什么要创建领域模型领域模型和领域层使用相似的命名可以减少软件表示与我们头脑中的领域模型之间的差异。动机：降低与OO建模之间的表示差异。这是OO的关键思想：领域层软件类的名称要源于领域模型中的名称，以使对象具有源于领域的信息和职责。这样可以减少我们的思维与软件模型之间的表示差异。同事，这并非只是哲学上的考究--对时间与金钱也会有实际的影响。如何创建领域模型：寻找概念类，将其绘制成UML类图中的类，添加关联和属性；系统顺序图中的所有系统被视为黑匣子；外部参与者对系统一个行为，引起系统相应的行为和反馈。22什么是系统顺序图系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和（最重要的）对象设计的输入。UML包含以顺序图为形式的表示法，用以阐述外部参与者到系统的事件。23系统顺序图的应用：UMLUML没有定义所谓的“系统”顺序图，而只是定义了“顺序图”。这一限定强调将系统的应用视为黑盒。之后，我们会在另一语境下使用顺序图，阐述完成工作的交互软件对象的设计。24SSD和用例之间的关系SSD展示了用例中一个场景的系统事件，因此它是从对用例的考察中产生的（参见图10-3）。Createdbywhulelouchpage46/13/2020仅供个人使用Copyright©whulelouch应用UML：是否应该在SSD中显示用例文本。通常不这么做。如果你为SSD适当地命名，可以指明对应用的用例。25如何为系统事件和操作命名系统事件应该在意图的抽象级别而非物理的输入设备级别来表达