• 目标：1》定义系统操作2》为系统操作创建契约

  简介      在UP中，用例和系统特性是用来描述系统行为的主要方式，并且足以满足要求。有时需要对系统行为进行更为详细和精确的描述。操作契约使用前置和后置条件的形式，描述领域模型里对象的详细变化，并作为系统操作的结果。领域模型是最常用的OOA模型，但是操作契约和状态模型也能够作为有用的与OOA相关的制品。 操作契约可以视为UP用例模型的一部分，因为它对用例指出的系统操作的效用提供了更详细的分析。图11-1所示的UP制品的相互影响强调了操作契约。该契约的主要输入时SSD中确定的系统操作、领域模型和领域专家的见解。该契约也可以作为对象设计的输入，因为他们描述的变化很可能是软件对象或数据库所需要的。

  示例      下面给出的是系统操作enterItem的操作契约。其中的关键元素是后置条件，其他部分虽然有用但重要性稍低。

  契约CO2:enterItem

  操作：enterItem(itemID:ItemID,quantity:integer)

  交叉引用：用例 : 处理销售

  前置条件：正在进行的销售

  后置条件：1》创建了SalesLineItem的实例sli(创建实例)。2》sli与当前Sale关联（形成关联）3》sli.quantity赋值为quantity（修改属性）4》基于itemID的匹配，将sli关联到ProductDescription（形成关联）

  “（创建实例）”这样的分类是为了帮助学习，并不是契约的有效部分。

  定义：契约有哪些部分      下面对契约中的每个部分进行了描述：

  操作：操作的名称和参数

  交叉引用：会发生此操作的用例

  前置条件：执行操作之前，对系统或领域模型对象状态的重要假设。这些假设比较重要，应该告诉读者。

  后者条件：最重要的部分。完成操作后，领域模型对象的状态。后续章节将详细描述这个问题。

  定义：什么是系统操作      可以为系统操作定义操作契约，系统操作时作为黑盒构件的系统在其公共接口中提供的操作。系统操作可以在绘制SSD草图时确定，如图11-2。更精确地讲，SSD展示了系统事件，即涉及系统的事件或I/O消息。输入的系统事件意味着系统具有用来处理事件的系统操作，正如OO消息（一种事件或信号）要由OO方法（一种操作）来处理那样。 涉及所有用例的系统操作的完整集合将系统视为一个构件或类，定义了公共的系统接口。在UML中，作为整体的系统可以表示成名称为（例如）System的类的一个对象。

  定义：后置条件      后置条件（postcondition）描述了领域模型内对象状态的变化。领域模型状态变化包括创建实例、形成或消除关联以及改变属性。    后置条件不是在操作过程中执行的活动，相反，它们是对领域模型对象的观察结果，当操作完成后，这些结果为真，就像浓烟散去后所能够清晰看到的事物。   概括说来，后置条件可以分为以下三种类型：（1》创建或删除实例 2》属性值的变化 3》形成或消除关联（精确地讲，是UML链接））。消除关联比较少见。删除实例的后置条件也十分少见，因为人们通常不会关心明确强制销毁现实世界中的事物。

  后置条件如何与领域模型相关      这些后置条件主要是在领域模型对象的语境中表示的。可以创建什么实例？（来自于领域模型）可以形成什么关联？（来自于领域模型），等等。

  动机：为什么需要后置条件      首先，后置条件并不总是必要的。在大多数情况下，系统操作的效果对开发者而言是相对清晰的，他们可以通过阅读用例、与专家交流或根据自己的知识对此进行理解。但有时需要更详细和精确的描述。契约正提供了此类描述。注意，后置条件支持细粒度的细节和精确性，以声明操作必须具备的结果。在用例中也可以表示为这种详细级别，但并不适宜，因为过于冗长和详细。契约是优秀的需求分析或OOA工具，能够详细描述系统操作（就领域模型对象而言）所需的变化，而不需描述这些操作是如何完成的。换言之，设计可以被延迟，我们可以重点分析必须发生的事物，而不是如何实现这些事物。

  准则：如何编写后置条件      用过去时态表达后置条件，以强调它们是由操作引起的状态变化的观察结果，而不是发生的活动。这也是后置条件名称的由来！例如 （较好）创建了SalesLineItem    而不是  （较差）创建SalesLineItem或SalesLineItem被创建。

  准则：后置条件因该完善到何种程度？敏捷与重量级分析       契约有可能是无用的。这一问题将在后续章节中讨论。但是假设契约有用，则为所有系统操作生成完整详细的后置条件集合是不可能的，或是没有必要的。就敏捷建模的本质而言，只是将其视为初始最佳的猜测，在这种理解下，详尽的后置条件是无法完成的，而所谓“完善”的规格说明也是几乎不可能的或不可信的。但是要理解，进行轻量的分析是现实和有效的，这并不是意味着要在编程前放弃任何调查，这又是另一种极端的误解。

  示例：enterItem的后置条件      以下内容剖析了enterItem系统操作后置条件的动机。

  创建和删除实例      输入itemID和商品项目的quantity后，会创建哪些新对象？SalesLineItem。因此：

  • 创建了SalesLineItem的实例sli(创建实例)。

  注意对实例的命名。该名字简化了在其他后置条件语句中对该新实例的引用。

  属性修改      在收银员输入商品项目标识和对应的商品数量后，应该修改了哪些新对象或现有对象的属性？SalesLineItem的quantity应该变为等于quantity参数。因此

  • sli.quantity赋值为quantity（修改属性）

  准则：是否应该更新领域模型      通常在创建契约的过程中会发现，需要在领域模型中记录新的概念类、属性或关联。不要局限于先前定义的领域模型，当你在思考操作契约过程中有新发现时，要对领域模型进行改进。在迭代和进化式方法中（并且反映了软件项目的真是情况），所有分析和设计制品都不是完善的，要根据新发现对其改进。

  准则：契约在何时有效      在UP中，用例是项目需求的主要知识库。用例可以为设计提供大部分或全部所需细节。这种情况下，契约就没有什么作用。但有时对于用例而言，所需状态变化的细节和复杂性难以处理或过于细节化。如果开发者在没有操作契约的情况下，能够准确地理解所需要完成的工作，则可以不编写契约。

  准则：如何创建和编写契约       创建契约时可以应用以下指导：1》从SSD中确定系统操作。2》如果系统操作复杂，其结果可能不明显，或者在用例中不清楚，则可以为其构造契约。3》使用以下几种类别来描述后置条件：1》创建和删除实例。 2》修改属性 3》形成清除关联。

  编写契约

  • 如上所述，以说明性的、被动式的过去时态编写后置条件，以便强调变化的观察结果，而非其如何实现的设计。例如：（较好）创建了SalesLineItem。 （较差）创建SalesLineItem。
  • 记住，要在已有或新创建的对象之间建立关联。例如，当enterItem操作发生时，仅创建SalesLineItem的实例是不够的。操作完成后，还应该将此信创建的实例与Sale关联。因此： 将SalesLineItem与Sale关联（形成关联）。

  最常见的错误   最常见的问题是遗漏了关联的形成。特别是当创建了新实例时，通常需要建立与若干对象的关联。不要遗忘这一点！

  应用UML：操作、契约和OCL      UML正式地定义了操作（operation）。引证如下：操作是可以调用对象执行的转换或查询的规格说明。例如，在UML中，接口元素就是操作。操作是抽象而非实现。相比之下，方法是操作的实现。引证如下：操作的实现。它规定了与操作关联的算法或过程。在UML元模型中，操作具有特征标记，在这种语境中最为重要的是，与一组UML约束对象关联，这些对象被分类为指定操作语义的前置条件和后置条件。概括一下，UML通过约束定义操作的语义，这些约束可以用前置或后置的形式指定。要注意，本章强调UML操作的规格说明不能表示算法或解决方案，而只能是状态的变化或操作的效果。契约除了用于指定整个System（也就是说，系统操作）的公共操作外，还能够用于任何粒度的操作：子系统的公共操作（或接口）、构件、抽象类等。例如，可以为Stack这样的单个软件类定义操作。本章讨论的粗粒度操作属于将整个系统作为黑盒构件的System类，但是UML操作可以属于任何类或接口，它们都具有前置和后置条件。

  用OCL表示的操作契约     本章中的前置后后置条件的格式是非正式的自然语言格式，完全可以被UML接受，并易于理解。但UML还具有正式、严谨的语言，成为对象约束语言（OCL），OCL可以用来表示UML操作的约束。准则：除非有不可避免的实际原因要求人们学习和使用OCL，否则要保持简单并使用自然语言。尽管我确信存在真实（且有效）的应用，但我从未见过使用OCL的项目，即便我调查了大量客户和项目。

   

  过程：UP的操作契约      前置和后置条件契约式UML指定操作的常用风格。在UML中，操作在许多级别中存在，从System到细粒度的类。系统级别的操作契约式用例模型的一部分，尽管原始的RUP或UP文档中并没有正式地强调这一点。RUP作者证实了用例模型中包括操作契约。

  阶段      初始--初始阶段不会引入契约，因为过于详细。   细化--如果使用契约的话，大部分契约将在细化阶段进行编写，这时已经编写了大部分用例。只对最复杂和微妙的系统操作编写契约。

   

~ 第10章：系统顺序图

• 目标： 1》确定系统事件      2》为用例场景创建系统顺序图

  简介      系统顺序图（SSD）是为阐述与所讨论系统相关的输入和输出事件而快速、简单地创建的制品。它们是操作契约和（最重要的）对象设计的输入。UML包含以顺序图为形式的表示法，用以阐述外部参与者到系统的事件。图10-1中所示的是强调系统顺序图的UP制品的相互影响。用例文本及其所示的系统事件是创建SSD的输入。SSD中的操作可以在操作契约中进行分析，在词汇表中被详细描述，并且（最重要的是）作为设计协作对象的起点。

  示例：NextGen SSD      对于用例中一系列特定事件，SSD展示了直接与系统交互的外部参与者、系统（作为黑盒）以及由参与者发起的系统事件（如图10-2所示）。

  什么是系统顺序图        用例描述外部参与者是如何与我们所希望创建的系统进行交互的。在交互中，参与者对系统发起系统事件(system event)，通常需要某些系统操作(system operation)对这些事件加以处理。   UML包含了顺序图作为表示法，以便能够阐述参与者的交互及参与者引发的操作。   系统顺序图表示的是，对于用例的一个特定场景，外部参与者产生的事件，其顺序和系统之内的事件。所有系统被视为黑盒，该图强调的是从参与者到系统的跨越系统边界的事件。准则：应为每个用例的主成功场景，以及频繁发生的或者复杂的替代场景绘制SSD。

  动机：为什么绘制SSD        基本上，软件系统要对以下三种事件进行响应：1）来自于参与者（人或计算机）的外部事件，2）时间事件，3）错误或异常（通常源于外部）。因此，需要准确地知道，什么是外部输入的事件，即系统事件。这些事件是系统行为分析的重要部分。   在对软件应用将如何工作进行详细设计之前，最好将其行为作为“黑盒”来调查和定义系统行为(system behavior)描述的是系统做什么，而无需解释如何做。这种描述的一部分就是系统顺序图。其他部分包括用例和系统操作契约（稍后进行讨论）。

  应用UML：顺序图      UML没有定义所谓的“系统”顺序图，而只是定义了“顺序图”。这一限定强调将系统的应用视为黑盒。之后，我们会在另一语境下使用顺序图，阐述完成工作的交互软件对象的设计。顺序图中的循环       注意在图10-2中是如何使用交互框(interaction frame)来表示顺序图中的循环的。

  SSD和用例之间的关系      SSD展示了用例中一个场景的系统事件，因此它是从对用例的考察中产生的（参见图10-3）。应用UML：是否应该在SSD中显示用例文本       通常不这么做。如果你为SSD适当地命名，可以指明对应用的用例。

  如何为系统事件和操作命名        系统事件应该在意图的抽象级别而非物理的输入设备级别来表达。如图10-4所示，系统事件的名称以动词开始（增加......，输入......，结束......，产生......），可以提高清晰程度，因为这样可以强调这些事件是命令或请求。

  如何为涉及其他外部系统的SSD建模        SSD也同样可以用来阐述系统之间的协作，但这个问题我们会在案例研究的猴戏迭代中讨论，因为被次迭代不包括远程系统协作。

  SSD的哪些信息要放入词汇表中        SSD中所示的元素（操作名称、参数、返回的数据）是简洁的。需要对这些元素加以适当的解释以便在设计时能够明确地知道输入了什么，输出了什么。词汇表是详细描述这些元素的最佳选择。   准则：对大多数制品来说，一般在词汇表中描述其细节。

  示例：Monopoly SSD       参见图10-5。

  过程：迭代和进化式SSD       不用为所有场景创建SSD，除非你在使用需识别所有系统操作的预算技术（例如功能点计数）。相反，只需为下次迭代所用的场景绘制SSD。同时，不应该花费太长时间来绘制SSD，用几分钟或半小时来绘制即可。当需要了解现有系统的接口和协作时，或者将其架构记录在文档时，SSD也是十分有效的。  UP中的SSD    SSD是用例模型的一部分，将用例场景隐含的交互可视化。尽管UP的创建者们意识到并理解这些图的用途，但最初的UP描述中并没有直接提到SSD。有大量可能有用和广泛使用的分析和设计制品或活动并没有在UP或RUP文档中提及，SSD就是其中之一。但是UP十分灵活，提倡引入任何能够增加价值的制品和实践。  UP阶段   初始--通常不会在该阶段引入SSD，除非你要对涉及的技术进行粗略的估算（不要指望初始阶段的估算是可靠的），这种估算的基础是对系统操作的识别。   细化--大部分SSD在细化阶段创建，这有利于识别系统事件的细节以便明确系统必须被设计和处理的操作，有利于编写系统操作契约，并且可能有利于对估算的支持。    

• 目标 1》确定与当前迭代相关的概念类 2》创建初始的领域模型 3》为模型建立适当的属性和关联。

  简介      领域模型是OO分析中最重要的和经典的模型。它阐述了领域中的重要概念。领域模型可以作为设计某些软件对象的灵感来源，也将作为在案例研究中所探讨的几个制品的输入。本章还将展示UML表示法上OOA/D知识的价值。基本表示法非常容易，但是对于有用模型的一些深奥的建模准则，则需要数周或数月才能掌握。     

        和敏捷建模和UP精神中的所有事物一样，领域模型也是可选制品。在图9-1中所示的UP制品相互影响力中强调了领域模型。领域模型的范围限定于当前迭代所开发的用例场景，领域模型能够被不断地演进用以展示相关的重要概念。相关的用例概念和专家的观点将作为创建领域模型的输入。反过来，该模型又会影响操作契约、词汇表和设计模型，尤其是设计模型中领域层(domain layer)的软件对象。

  示例      图9-2展示了以UML类图(class diagram)表示法绘制的部分领域模型。对领域模型应用UML类图表示法会产生概念透视图(conceptual perspective)模型。 确定一组概念类是OO分析的核心。如果能够通过熟练和快速(就是说，每次早期迭代不超过几个小时)的调查来完成这项工作，那么通常会在设计过程中得到回报，因为领域模型能够支持更好的理解和沟通。准则：避免瀑布思维倾向，为完成详尽或“正确”的领域模型而进行大量建模工作。这些方式都应避免，并且这种过量的建模工作反而会导致分析停滞，这种调查几乎不会有什么回报。

  什么是领域模型      这一精髓的面向对象分析步骤是从领域到重要概念或对象的分解。领域模型(domain model)是对领域类或现实世界中对象的可视化表示。领域模型也称为概念模型、领域对象模型和分析对象模型。定义：在UP中，术语"领域模型"指的是对现实世界概念类的表示，而非软件对象的表示。该术语并不是指用来描述软件类、软件架构领域层或有职责软件对象的一组图。UP对领域模型的定义是，可以在业务建模科目中创建的制品之一。更准确地讲，UP领域模型是UP业务对象模型(BOM)的特化，“专用于解释业务领域中重要的‘事物’和产品”也就是说，领域模型专注于特定领域。更为广泛的BOM是扩展的、通常十分庞大和难以创建的多领域模型，BOM覆盖整个业务及其所有子域，本章并不涵盖这部分内容，并且也不提倡创建BOM（因为需要在是实现前进行大量建模）。

        应用UML表示法，领域模型被描述为一组没有定义操作（方法的特征标记）的类图)（class diagram）。它提供了概念透视图。它可以展示：

  • 领域对象或概念类。
  • 概念类之间的关联
  • 概念类的属性。

  定义：为什么把领域模型称为“可视化字典”

        请仔细观察图9-2.看看它是如何对领域词汇或概念进行可视化和关联的。领域模型还显示了概念类的抽象。因为这种抽象可以表达其他大量事物，例如登陆、销售等。

        领域模型（使用UML表示法）描述的信息也可以采用纯文本方式（UP词汇表）表示。但是在可视化预言中更容易理解这些术语，特别是它们之间的关系，因为我们的思维更擅长理解形象的元素和线条连接。因此，领域模型是可视化字典，表示领域的重要抽象、领域词汇和领域的内容信息。

  定义：领域模型是软件业务对象图吗      如图9-3所示，UP领域模型是对所关注的现实世界领域中事物的可视化，而不是诸如Java或C#类的软件对象，或有职责软件对象（参见图9-4）。因此以下元素不适用于领域模型：

  • 软件制品，例如窗口或数据库，除非已建模的领域是针对软件概念的，例如图形化用户界面的模型。
  • 职责或方法。

  定义：“领域模型”的两个传统含义      在UP及本章中“领域模型”是现实世界中对象的概念透视图，而非软件透视图。但这一术语是多义的，也用来表示“软件对象领的领域层”也就是说，在表示层或UI层之下的软件对象层是由领域对象(domain object)组成的--领域对象是表示问题领域空间事物的软件对象，并且与“业务逻辑”或“领域逻辑”方法相关。我通常会使用领域层(domain layer)来表示领域模型针对软件的第二个含义，因为领域层也十分通用。

   

  定义：什么概念类      领域模型阐述领域中的概念类或词汇。概念类是思想、事物或对象。更正式的讲，概念类可以从其符号、内涵和外延来考虑。

  • 符号：表示概念类的词语或图形
  • 内涵：概念类的定义
  • 概念类所适用的一组示例

  定义：领域模型和数据模型是一回事吗       领域模型不是数据模型（通过对数据模型的定义来表示存储于某处的持久性数据），所以在领域模型里，并不会排除需求中没有明确要求记录其相关信息的类（这是对关系数据库进行数据建模的常见标准，但与领域建模无关），也不会排除没有属性的概念类。例如，没有属性的概念类是合法的，或者在领域内充当纯行为角色而不是信息角色的概念类也是有效的。

  动机：为什么要创建领域模型       领域模型和领域层使用相似的命名可以减少软件表示与我们头脑中的领域模型之间的差异。    动机：降低与OO建模之间的表示差异    这是OO的关键思想：领域层软件类的名称要源于领域模型中的名称，以使对象具有源于领域的信息和职责。图9-6阐述了这一思想。这样可以减少我们的思维与软件模型之间的表示差异。同事，这并非只是哲学上的考究--对时间与金钱也会有实际的影响。

  准则：如何创建领域模型       1、寻找概念类 2、将其绘制为UML类图中的类 3、添加关联和属性

  准则：如何找到概念类       既然领域模型表示的是概念类，那么关键问题是如何才能找到概念类。找到概念类的三条策略   1、重用和修改现有的模型。这是首要、最佳且最简单的方法，如果条件许可，通常从这一步开始。在许多常见领域中都存已发布的、绘制精细的领域模型和数据模型（可以修改为领域模型），这些领域包括库存、金融、卫生等等。我所参考的书籍包括Martin Fowler的《分析模式》(Analysis Patterns)、David hay的Data Model Patterns和Len Silverston的Data Model Resource Book(卷1和卷2) 2、使用分类列表   3、确定名词短语      重用现有的模型是最好的办法，但超出了本书的范围。第二个方法（使用分类列表）也很有效。   方法2：使用分类列表   我们可以通过制作概念类候选列表来开始创建领域模型。参看表9-1。   方法3：通过识别名词短语寻找概念类    在【Abbot83】中所建议的另一种有效(因为简单)技术是语言分析(linguistic analysis)，即在对领域的文本性描述中识别名词和名词短语，将其作为候选的概念类或属性。    准则：使用这种方法时必须小心。不可能存在名词到类的映射机制，并且自然语言中的词语具有二义性。领域模型是重要领域概念和词汇的可视化。那么从哪里找到这些术语？其中某些术语来源于用例。另外一些术语则源于其他文档，或是专家的想法。无论如何，用例都是挖掘名词短语的重要来源之一。

  示例：寻找和描绘概念类       参见图9-7 图9-8

  准则：敏捷建模--绘制类图的草图       注意图9-8中UML类图的这种草图风格，让类框的底部和右侧呈开发状态。这样可以在发现新元素时对类方便地进行扩展。

  准则：敏捷建模--是否要使用工具维护模型      敏捷模型在创建后通常很快就被抛弃了（即使这样，如果你使用白板的话，我还是建议用数据相机拍下来）。基于这种观点，则没有理由去维护或更新这些模型。但是这也不意味着更新模型就是错的。通常，进化的软件领域层对大部分重要术语会给予提示，而且长生命期的OO分析领域模型不会增加价值。

  准则：报表对象--模型中是否要包括“票据”

  准则：像地图绘制者一样思考；使用领域术语      地图绘制者的策略既可用于地图，也可以用于领域模型。准则： 以地图绘制者的工作思维创建领域模型：1》使用地域中现有的名称 2》排除无关或超出范围的特性 3》不用凭空增加事物

  准则：如何对非现实世界建模      有些软件系统的领域与自然领域或业务领域几乎没有类似之处，例如电信软件。然而还是有可能为这些领域创建领域模型。此时需要高度的抽象，对常见的非OO设计进行回归，并且认真吸取领域专家所使用的核心词汇和概念。

  准则：属性与类的常见错误      在创建领域模型时最常见的错误是，把应该是概念类的事物表示为属性。   准则：如果我们认为某概念类X不是现实世界中的数字或文本，那么X可能是概念类而不是属性。

  准则：何时使用“描述”类建模       描述类（description class）包含描述其他事物的信息。在[Coad92]中，这种类通常被命名为项目-描述符模式。图9-9   准则：何时需要描述类   在以下情况下需要增加描述类（例如，ProductDescription）

  • 需要有关商品或服务的描述，独立于任何商品或服务的现有实例
  • 删除其所描述事物（如Item）的实例后，导致信息丢失，而这些信息是需要维护的，但是被错误地与所删除的事物关联起来。
  • 减少冗余或重复信息。

  图9-10

  关联      找到并表示出关联是有助的，这些关联能够满足当前所开发场景的信息需求，并且有助于理解领域。关联（association）是类（更精确地说，是这些类的实例）之间的关系，表示有意义和值得关联的连接（图9-11）在UML中，关联被定义为“两个或多个类元之间的语义联系，涉及这些类元实例之间的连接”。  

         准则：何时表示关联   关联表示了需要持续一段时间的关系，根据语境，可能是几毫秒或数年。换言之，我们需要记录哪些对象之间的关系？ 由于领域模型是从概念角度出发的，所以是否需要记录关联，要基于现实世界的需要，而不是基于软件的需要，尽管在实现过程中，会有出现大量对关联的需要。图9-11关联。   准则：在领域模型中要考虑如下关联：1》如果存在需要保持一段时间的关系，将这种语义表示为关联（“需要记住”的关联）2》从常见关联列表中派生的关联。

        准则：为什么应该避免加入大量关联    在具有n个节点的图中，节点间有(n*(n-1))/2个关联，这可能是个非常大的数值。连线太多会产生“视觉干扰”，使图变的混乱，所以要谨慎地增加关联线。使用本章准则所建议的标准，并且重点关注“需要记住”的关联。   

        观点：关联是否会在软件中实现   在领域建模过程中，关联不是关于数据流、数据库外键联系、实例变量或软件方案中的对象连接语句；关联声明的是针对现实领域从纯概念角度看有意义的关系。也就是说，这些关系的大部分将作为（设计模型和数据模型中的）导航和可见性路径在软件中加以实现。但是，领域模型不是数据模型；添加关联是为了突出我们对重要关系的大致理解，而非记录对象或数据的结构。

        应用UML：关联表示法       关联被表示为类之间的连线，并冠以首字母大写的关联名称。见图9-12。警告：阅读导向箭头对模型来说并不具有特别意义，只是对阅读图的人有所帮助。

        准则：在UML中如何对关联命名      以“类名-动词短语-类名”的格式为关联命名，其中的动词短语构成了可读的和有意义的顺序。诸如“拥有”或“使用”这样简单关联名称通常是拙劣的，因为这种名称不会增强我们对领域的理解。关联名称应该使用首字母大写的形式，因为关联表示的是实例之间链接的类元。在UML中，类元应该首字母大写。以下是复合性关联名称的两种常见并且等价的合法格式：1》Records-current   2》RecordsCurrent

        应用UML：角色       关联的每一端称为角色(role)。角色具有如下可选项： 1》多重性表达式 2》名称 3》导航 多重性将在后面讨论。

         应用UML：多重性       多重性(multiplicity)定义了类A有多少个实例可以和类B的一个实例关联（见图9-13）。在图9-14中将给出一些多重性表达式的例子。多重性的值表示在特定时刻（而不是某个时间跨度内）有效关联的实例数量。多重性的值和建模者和软件开发者的关注角度有关，因为它表达了将要（或可能）在软件中反映的领域约束。见图9-15.

        应用UML：两个类之间的多重关联      在UML类图中，两个类之间可能会有多重关联，这并不罕见见图9-16。

        准则：如何在常见关联列表中找到关联      通过使用表9-2中的列表来开始添加关联。该列表中包含值得考虑的常见类别，对业务系统而言更是如此。

   

    示例：领域模型中的关联      参见图9-17和图9-18。

  属性      确定概念类的属性是有助的，能够满足当前所开发场景的信息需求。属性(attribute)是对象的逻辑数据值。

        准则：何时展示属性       当需求（例如，用例）建议或暗示需要记住信息时，引入属性。

        应用UML：属性表示法      属性在类框图的第二格中表示（参见图9-19）。其类型和其他信息是可选的。在UML中，属性的完整语法是：  visibility name:type multiplicity = default {property-string}，对该表达式译为中文是： 可见性  名称：类型  多重性=默认值 {特性表}   参见图9-20。依照惯例，大部分建模者会假设属性的可见性为私有的（-），除非有另外表示，所以我通常不会显式地标出可见性符号。   {readOnly}大概是属性的{property-string}部分最常用的值。   多重性用来指示可能出现的值，或者可以填充到（集合）属性中的对象数量。例如，许多领域要求知道某人的名和姓，但是中名是可选的。表达式middleName:[0..1]表示可选值，该属性可以出现0或1个值。准则：在哪里记录属性需求       有些建模者认可只在领域模型中保留这种规格说明，但是我发现这是一种错误倾向，并且被扩散了，因为人们往往不去仔细查看领域模型或需求指导。人们也通常不会维护领域模型。   我建议把所有这种属性需求置于UP词汇表（UP词汇表可充当数据字典）。可能我已经花费了一个小时和领域专家一起画出领域模型的草图；之后，我可以花费15分钟浏览这个草图并将其中表示的属性需求转移到词汇表中。另一种方法是，使用工具将UML模型和数据字典统一起来；这样所有属性会自动显示为数据字典的元素。  导出属性      Sale中的total属性可以从SalesLineItems中的信息计算或导出。当我们需要表达：这是重要属性，但是导出的，那么可以使用UML的约定：在属性名称前加以"/"符号。 收银员输入的数量可以被记录为SalesLineItem的属性（参见图9-21）。但该数量可以从关联的多重性的实际值计算出来，所以被表示为导出属性，即可以由其他信息导出的属性。

        准则：什么样的属性类型是适当的       关注领域模型中的数据类型属性    通俗的说，大部分属性类型应该是“简单”数据类型，例如数字和布尔。通常，属性的类型不应该是复杂的领域概念，例如Sale或Airport。图9-22中Cashier类的currentRegister属性是不合适的，因为其类型是Register，并不是简单数据类型（例如Number或String）。表达Cashier使用Register的最有效的做法是使用关联，而不是使用属性。   准则   领域模型中属性的类型更应该是数据类型(data type)。十分常见的数据类型包括：Boolean,Date（或DateTime）、Number、Character、String(Text)和Time。其他常见的类型还有Address、Color、Geometrics(Point、Rectangle)、Phone Number、Social Security、Number、Universal Product Code(UPC)、SKU、ZIP或者是邮政编码、枚举类型。   准则：通过关联而不是属性来表示概念类之间的关系。参见图9-23。

        数据类型      领域模型中的属性通常应该是数据类型(data type)。一般来说，数据类型是“基本”类型，诸如数字、布尔、字符、字符串和枚举(例如，尺寸={小，打})。更准确地讲，UML术语中的数据类型指的是一组值，而这组值的标识本身不具有任何含义（在我们的模型或系统的语境下）。换言之，对数据类型的等价性检验不是基于标识，而是根据值来判断的。      数据类型值往往是恒定不变的，例如，Integer的实例"5"是不变的；Date的实例“Nov.13,1990”可能也是不变的。而Person实例的lastName属性可能对不同人有不同的值。   从软件角度出发，很少会对Integer或Date实例的存储地址（标识）进行比较，一般是对值进行比较。另一方面，即使Person的不同实例具有相同的属性值，但还是可以区分和比较其存储地址，因为其唯一标识的重要性。

        观点：代码中的属性       在领域模型中建议属性主要为数据类型，并不意味着C#或Java的属性只能是简单的基础数据类型。领域模型是概念透视图，不是软件透视图。在设计模型中，属性可以是任何类型。

        准则：何时定义新的数据类型类       NextGen POS系统需要itemID属性，可以作为Item或ProductDescription的属性。注意，该属性看起来只是数字或字符串，例如，itemID:Integer或itemID:String。 但实际上，该属性并不仅仅是字符串或数字（商品项目标识符具有子域），更有效的做法是在领域模型中加入类ItemID（或者ItemIdentifier），并且将这个类作为itemID属性的类型。例如，itemID:ItemIdentifier。表9-3提供了一些准则，指明何时需要在模型中加入数据类型。

        应用UML：在何处描述这些数据类型类      在领域模型里，ItemID类应该表示为单独的类吗？这取决于你想要在图中强调的事物。既然ItemID是数据类型（实例的唯一标识不用于等价性检验），那么可能只会表示在类框的属性分格中，如图9-24。采用哪种解决方式取决于如何使用作为沟通工具的领域模型以及领域里概念的重要性。

        准则：任何属性都不表示外键      领域模型里的属性不应该用于表示概念类的关系。违反这一原则的常见情况是像在关系数据库设计中那样增加一种外键属性，用以关联两个类型。参见图9-25。可以用许多方法来表示对象之间的关系，外键就是其中一种方法，我们将推迟到设计时在决定如何实现对象关系，以避免设计蠕变(design creep)。

        准则：对数量和单位建模       大部分用数字表示的数量不应该表示为纯数字。应该给这些数量加上单位，并且通常还需要知道单位之间的转换关系。领域模型（和软件）应该具备处理数量的技巧。一般情况下，可以把数量表示为单独的Quantity类，并且关联到Unit类。通常可以对Quantity加以规格说明。参见图9-26。

  实例：领域模型中的属性       参见图9-27、 9-28

   结论：领域模型是否正确       没有所谓唯一正确的领域模型。所有模型都是对我们试图要理解的领域的近似。领域模型主要是在特定群体中用于理解和沟通的工具。有效的领域模型捕获了当前需求语境下的本质抽象和理解领域所需要的信息，并且可以帮助人们理解领域的概念、术语和关系。

  过程：迭代和进化式领域建模       在迭代开发中，我们会通过若干迭代对领域模型进行增量地演进。在每个迭代中，领域模型都会限定于之前和当前要考虑的场景，而不是膨胀为瀑布风格的“大爆炸”模型，以过早试图捕获所有可能的概念类和联系。因此，只创建部分领域模型反映这一情形，而不涉及其他。   准则：避免瀑布思维倾向，为完成详尽或“正确”的领域模型而进行大量建模工作，这些方式都应避免，这种过量的建模工作反而会导致分析停滞，这种投入几乎不会有什么回报。每次迭代的领域模型建模时间不超过几个小时。

        UP中的领域模型   如表9-4的建议所示，UP中的领域模型通常开始和完成于细化阶段。

        UP业务对象模型与领域模型       UP领域模型是较为少见的UP业务对象模型（BOM）的正式变体。不要与其他对BOM的定义混淆，UP BOM是一种描述整个业务的企业模型。BOM可以用来进行业务过程或再工程，而不依赖于任何软件应用。引证如下：【UP BOM】作为抽象，描述的是业务人员和业务实体应该怎样关联，以及它们如何协作以完成业务。    BOM使用不同的图（类图、活动图和顺序图）来阐述整个企业是如何运转的（或应该如何运转）。BOM通常有助于进行企业范围的业务过程工程，而在创建单个软件应用时并不常见。因此，UP定义了领域模型，作为BOM的常用制品子集或特化。引证如下：你可以选择开发“非完整的”业务对象模型，重点解释领域中的重要“事物”和产品。【...】这些都成为领域模型。

~ 第8章：迭代1-基础

• 简介   本章将概括案例研究在迭代1的需求，然后简要讨论初始和细化阶段的过程思想。为理解后续章节对本次迭代的讨论，阅读选择需求很重要。

  迭代1的需求和重点：OOA/D技术的核心       在这些案例中，细化阶段打得迭代1强调的是基础范围和在构建对象系统中所使用的常见OOA/D技术。当然，构建软件还需要其他许多技术，例如数据库设计、可用性工程、UI设计等，但是本书主要关注OOA/D和UML应用，其他技术不在本书涵盖范围之内。

  在迭代开发中，我们并非一次就实现所有需求       对迭代生命周期方法（例如UP、XP、Scrum等）的关键理解就是：我们对需求子集开始具有产品品质的编程和测试，并且我们在完成所有需求分析之前开始这些开发，这与瀑布过程相反。

  在多个迭代里对同一用例进行增量式开发      注意，并不是在迭代1里要实现处理销售用例中的所有需求。通常是在若干迭代内对同一用例的各种场景进行开发，并且逐渐地扩展系统直到最终完成所有需要的功能性（图8-1）另一方面，简短的用例可以在一次迭代中完成。

  过程：初始和细化      在初始阶段发生了什么   案例研究的初始阶段大概只持续了一周。因为这不是项目的需求阶段，所创建的制品应该是简明和不完整的，该阶段用时很短，并且只经过轻量级的调查。

        初始阶段是迈向细化阶段的一小步。在该阶段决定基本的可行性、风险和范围，对项目是否值得进行更深入的调查进行决策。并不是所有适合于初始阶段的活动都要涵盖在其中，这一阶段强调面向需求的制品。初始阶段中可能的活动和制品包括：

  • 简短的需求讨论会
  • 大多数参与者、目标和用例名称。
  • 大多数以摘要形式编写的用例。以详述形式编写10%~20%的用例，以加深对范围和复杂性的理解
  • 确定大多数具有影响和风险的质量需求。
  • 编写设想和补充性规格说明的第一个版本
  • 风险列表
  • 技术上的概念验证原型和其他调查，用以揭示特殊需求的技术可行性
  • 面向用户界面的原型，用于确定对功能需求的设想
  • 对购买/构建/复用构建的建议，在细化阶段进行精化。
  • 对候选的高层架构和构件给出建议。
  • 第一次迭代的计划
  • 候选工具列表

  细化之所在      细化阶段是最初的一系列迭代，在这一阶段，小组进行细致的调查、实现（编程和测试）核心架构、澄清大多数需求和应对高风险问题。在UP中，“风险”包含业务价值。因此，早期工作可能包括实现那些被认为重要的场景，而不是专门针对技术风险。

        细化阶段通常由两个或多个迭代组成，建议每次迭代的时间为2~6周。

        在这一阶段，不是要创建可以丢弃的原型。与之相反，该阶段产生的代码和设计是具有产品品质的最终系统的一部分。在一些UP的描述中，会误解"架构原型"(architectural prototype)这一术语用来描述局部系统。该术语不是指可废弃的、实验性的原型，在UP中，它表示最终系统的产品化子集。该术语更常见名称是可执行架构(executable architecture)或架构基线(architectural baseline)。  用一句话来概括细化：构建核心架构，解决高风险元素，定义大部分需求，以及预计总体进度和资源。

        在细化阶段可能出现的一些关键思想和最佳实践包括：

  • 实行短时间定量、风险驱动的迭代。
  • 及早开始编程
  • 对架构的核心和风险部分进行适应性的设计、实现和测试。
  • 尽早、频繁、实际地测试。
  • 基于来自测试、用户、开发者的反馈进行调整。
  • 通过一系列讨论会，详细编写大部分用例和其他需求，每个细化迭代举行一次。

        在细化阶段会开始构建哪些制品    表8-1列出的是可能在细化阶段开始构建的制品样例，同时指明这些制品要解决的问题。

        何时知道自己并没有理解细化阶段

  • 对于大部分项目，细化阶段都比“几个”月更长。
  • 只有一次迭代（除极少数易于理解的问题外）
  • 在细化开始前就定义了大部分的需求
  • 没有处理具有风险的元素和核心架构。
  • 没有产生可执行架构，没有进行产品代码的编程。
  • 认为细化阶段主要是需求或设计阶段，为构造阶段的实现进行准备。
  • 试图在编程之前进行彻底和细致的设计
  • 只有少量的反馈和调整；用户没有持续地参与评估和反馈。
  • 没有尽早和实际的测试
  • 在编程之前推测性地结束架构设计
  • 认为细化阶段是进行概念验证编程的阶段，而不是对产品化核心架构编程的阶段。

  如果在项目中出现这些现象，则表明你对细化阶段的理解是错误的，并且已经在UP之上强加了瀑布思想。

  过程：计划下一个迭代      通过风险、覆盖范围和关键程度组织需求和迭代。

  • 风险既包括技术复杂性、也包括其他因素，例如工作量或可用性的不确定性。
  • 覆盖范围意味着在早期迭代中至少要涉及系统的所有主要部分--或许是对大量构建进行“广泛和肤浅”的实现。
  • 关键程度是指客户认为具有高业务价值的功能。

  在迭代1之前完成等级划分，但是在迭代2之前要重新划分，依此类推，因为新需求和新理解会对等级排列产生影响。也就是说，迭代的计划是可适应的，并不是项目开始之时必须固定下来的。

• 简介   除用例之外，还有其他一些重要的UP需求制品，本章将介绍这些制品，这些内容与案例研究关系密切，并且提供了更为完整的需求示例。

  其他需求制品   用例不是要求的全部。

  》补充性规格说明   捕获并确定了其他类型的需求，例如报表、文档、包装、可支持性说明、许可授权等

  》词汇表 捕获术语和定义，它也可起到数据字典的作用

  》设想 概括了对项目的“设想”，即执行摘要。该制品为 项目主要思想提供简洁描述

  》业务规则（或领域规则）捕获了凌驾于特定应用之上的长期规则或政策，例如税法

  这些示例的详尽程度    本书首要目标是介绍OOA/D基础知识，而不是本章所论述的次要POS需求细节。因此本章只展示部分示例，并不展示完整详尽的需求示例。

       某些小节将作为承上启下的过渡小节，突出重点问题，提供对内容的感性认识，然后就会快速进入下面的内容。

  准则：初始阶段是否应该对此彻底地进行分析     非也。UP是一种迭代和进化式方法，这意味着应该早在完整地分析和记录大多数需求之前，尽早进行具有产品品质的编程和测试。来自早期编程和测试的反馈使需求进化。

         研究表明，在开始阶段，高阶粗粒度需求的“前十”列表是有帮助的。同样，在早期花费一定时间去理解非功能性需求（例如性能或可靠性）也是有帮助的，因为这对架构选择具有重要影响。

  可靠性规格说明：是否矛盾？    接下来所编写的需求示例可能会造成以下错觉：既然理解并良好定义了真实的需求，那么也可以用它来对项目进行可靠的预算和计划。这种错觉对非软件开发者来说尤其强烈，程序员会从其惨痛教训中认识到这种计划和预算是多么不可靠。

        真正重要的是快速构建可以通过用户验收测试的软件，而且能够满足用户真实的目标，但在用户对软件进行评估或使用之前，无法确定这些目标。

        编写设想和补充性规格说明是值得重视的，但是这些制品（或者任何需求）也并不是完全可靠的规格说明。只有编写代码、测试、获取反馈、进一步完成与用户和客户的协作并且对软件进行改写，才会真正达到目标。

        这并不是要号召无序分析和思考就匆忙地去编码，而是建议轻度地处理需求，尽快开始编程，并且不断引入用户和测试以得到反馈。

  准则：这些制品是否应该放在项目Web站点上      与普通的静态文档 不同，这些制品应该是超链接的，或者使用不用于字处理器或电子表格的其他工具进行记录。例如，其中大多数可以记录在WiKi Web上。

  NextGen示例：（部分）补充性规格说明    P78

  注解：补充性规格说明    补充性规格说明（supplementary specification）捕获了用例和词汇表难以描述的其他需求、信息和约束，其中包括系统范围的"URPS+"（可用性、可靠性、性能、可支持性和其他）等质量属性或需求。   在思考用例的时候，某用例专有的非功能性需求可以首先简要地写入用例，即用例的“特殊需求”小节。但是，在这种非正式描述后，应该将其归入补充性规格说明，以便所有非功能性需求集中在一处，避免重复。

  补充性规格说明中的元素包括：

  》“FURPS+”需求--功能性、可用性、可靠性、性能和可支持性

  》报表

  》硬件和软件约束（操作系统和网络系统等）

  》开发约束（例如，过程或开发工具）

  》其他设计和实现约束

  》国际化问题（货币单位、语言）

  》文档化（用户、安装和管理手册）和帮助

  》许可和其他法律问题

  》包装

  》标准（技术、安全和质量）

  》物理环境问题（例如，热度或振动）

  》操作问题（例如，如何处理错误，或者每隔多久进行备份）

  》特定应用领域规则

  》所关注领域的信息（例如，信用卡支付处理的整个过程）

  质量属性   有些需求可以称为系统的质量属性（quality attribute，或qualities attribute），包括可用性、可靠性等等。需要注意的是，这些指的是系统的质量，而非属性本身的质量，属性本身并没有高质量之说。

          当我们带上“架构师的帽子”时，系统范围的质量属性（记录于补充性规则说明中）将特别重要，因为架构分析和设计极为关心在功能性需求语境下质量属性的确定和选择，第33章将对此进行介绍。

  补充性规格说明中有功能性吗？难道不应该在用例中吗？    某些功能或特性并不适合采用用例的形式描述，可以采用特性的方式来描述功能性。

          UP当然也允许使用这种面向特性的方法来描述需求，在这种情形下，应在补充性规格说明中描述特性列表。

          UP提倡但不是强求对功能性使用用例。用例是一种优秀的方法，可以通过产品使用的典型场景把一组相关特性集中起来思考。但是用例并不是永远适用。

  应用专用的领域（业务）规则       一般来说，诸如税法等广泛应用的领域规则属于UP业务规则制品，UP将其作为核心的共享知识库。但是，对于更为局限的特定于应用的规则，例如如何计算某项商品折扣，可以记录在补充性规格说明中。

  所关注领域的信息      这对于主题问题专家是具有价值的，他们可以编写（或提供URI）一些与新软件系统有关的领域解释（销售和账务，地下油/水/气流量的地球物理学知识），以便为开发小组提供背景信息和更为深入的理解力

  NextGen示例：（部分）设想    P82

  注解：设想   编写执行摘要对项目运行进行简要的描述，使主要成员建立起对项目的共同设想，也是同样有帮助的。  设想不应该占据很长的篇幅，也不应该试图详细描述公司的需求。设想应该概括用例模型和补充性规格说明中的一些信息。

  涉众的关键高阶目标及问题   该小节总结高阶（通常高于特定用例）目标和问题，并且揭示了重要的非功能和质量目标，这些目标可能属于某个用例或跨越多个用例。

  准则：有哪些简化的方法？    特别是在输入定义高阶问题和确定目标的活动过程中，会发生创造性、研究性的小组工作。对于发现根源问题及目标、启发思路和定义优先级，存在一些有助于小组工作的技术：

  》思维导图（mind mapping）

  》产品设想包装制作（product vision box creation）

  》鱼骨图（fishbone diagram）

  》排列图(pareto diagram)

  》集体讨论（brainstorming）

  》多次投票表决（multi-voting）

  》记点投票表决（dot voting）

  》提名小组过程（nominal group process）

  》集体编写（brainwritting）

  》相关性分组（affinity grouping）

  可以在Web上找到这些方法的具体介绍。推荐在同一讨论会上采用其中几种方法，以便从不同角度发现共同的问题和需求。

  系统特性概要    为掌握主要特性而在设想文档中只列出用例名称是不够的，原因如下：

  1、太详细或层次太低。人们想要的是主要思想的概要

  2、用例名称可能掩盖了涉众真正关心的主要特性

  3、有些值得注意的特性跨越了多个用例或者与用例无关

  因此，使用特性作为替代的、补充性的方式来表示系统的功能，在这种语境下，更准确地说法是系统特性，即以高阶、简洁的语句对系统功能加以概括。更为正式地，在UP中，系统特性是“由系统提供的外部可观察到的服务，可以直接实现涉众的需求”

        定义：特性是系统能够实行的行为上的功能。特性应该通过如下语言上的测试：系统实行<特性X>

  将功能上的系统特性与各种非功能性需求和约束进行对比，例如“系统必须运行于Linux”，显然不能通过上述语言上的测试。例如，系统实现Linux。

  准则：如何编写功能列表      通常可以使用两级层次结构来组织系统特性。但是，如果设想文档的层次多于两级，则显得过于详细。设想文档的系统特性应该对功能性进行概括，非不应分解为细粒度元素的冗长列表。

          准则：在设想文档中包含的特性最好少于10个，因为更多的特性不能够被快速掌握。如果存在更多的特性，则需考虑对这些特性进行分组和概括。

  准则：我们是否应该在设想文档中重复其他需求？  准则：对于其他需求，要避免在设想和补充性规格说明（SS）中重复或近于重复。最好只在SS中记录这些需求。在设想文档中，可以指引读者到SS中阅读这些需求

  准则：你应该先编写设想还是用例？   不需要严格定义这种先后顺序。在开发者合作创建不同需求制品时，对一个制品的创建工作会影响并有利于澄清另一个制品。尽管如此，还是建议采用如下的顺序：

  1、首先编写简要的设想草案

  2、确定用户目标和对应的用例名称

  3、详细编写一些用例，并且开始编写补充性规格说明

  4、精化设想，对以上制品中的信息进行概括。

  NextGen示例:（部分）词汇表      P87

  注解：词汇表（数据字典）   词汇表（glossary）的最简形式是重要术语及其定义的列表。令人惊讶的一种常见情况是，不同涉众可以用略有不同的方式使用同一（通常是技术的或特定于领域的）术语。这一问题必须解决，以减少沟通上的问题和需求的二义性。  准则：及早开始编写词汇表。词汇表将很快成为关于细粒度元素细节信息的有效知识库。

  词汇表作为数据字典   在UP中，词汇表也充当数据字典（data dictionary）的角色，即记录关于数据之数据，也就是元数据（metadata）的文档。在初始阶段，词汇表应该是术语及其描述的简单文档。在细化阶段，词汇表可以扩展为数据字典。

  术语的属性包括：

    》别名

    》描述

    》格式（类型、长度、单位）

    》与其他元素的关系

    》值域

    》验证规则

   注意，词汇表中的值域和验证规则是反映系统行为的需求的组成部分。

  准则：我们是否可以在词汇表中记录组合术语    词汇表不仅用于记录原子术语，例如“产品价格”，它也能够并且也应该包括诸如“销售”（其中包含其他元素，例如日期和地点）的组合元素和用来描述用例参与者之间所传递的一组数据的简化名称。例如，在处理销售用例中，考虑如下陈述： 系统向外部支付授权服务发送支付授权请求，并请求批准支付。     “支付授权请求”是一组数据的别名，也需要在词汇表中加以解释。

  NextGen示例：业务规则（领域规则）  P88

  注解：领域规则    领域规则指出领域或业务是如何运作的。尽管应用需求通常都会受到领域规则的影响，但是这些规则不是任何一个应用的需求。公司政策、物理法则（例如油在地上如何流动）和政府法律都是常见的领域规则。

        领域规则通常称为业务规则（business rule），这也是其最常见的类型，但是这一术语并不是恰当的，因为大量软件应用不是面向业务问题的。  

        最好在单独的与应用无关的制品中确定和记录领域规则，这在UP中称为业务规则制品，这样便能够使分析在组织和项目范围内进行共享和重用，而不是只限定于特定项目的文档里。

        规则强调了情节的连续性而不是细节，有助于澄清用例中的歧义。例如，在NextGen POS中，如果有人问事否应该在处理销售用例中加入另一路径，即不允许不记录签名的信用卡支付，业务规则给出了答案，其表明任何信用卡授权公司都不允许这种情况。

  过程：迭代方法中的进化式需求   PPT6概括了制品示例及其在UP中的时限。通常，大多数需求制品始于初始阶段，并且主要在细化阶段开发。

  初始阶段    涉众要决定项目是否值得深入调查。实质的调查活动在细化阶段发生，而不是初始阶段发生。在初始阶段，设想以某种形式概括了项目思想，以帮助决策者决定是否值得继续，并且从哪里着手。

      因为大多数需求分析发生在细化阶段，所以在初始阶段应该只对补充性规格说明稍作开发，只需要突出重要的质量属性用以揭示主要风险和挑战。这些制品的输入可以在初始阶段的需求讨论会上产生。

  细化阶段   通过细化阶段，基于对部分系统增量构建的反馈、调整以及在若干开发迭代中举行的多个需求讨论会，对“远景”和设想文档加以精化。通过进一步的需求调查和迭代开发，其他需求将更为清晰并且可以记录在补充性规格说明中。

       在细化阶段结束时，完成并提交用例、补充性规格说明和设想是切实可行的，因为在此时，这些文档能够合理地反映稳定的主要特性和其他需求。尽管如此，补充性规格说明和设想不等同于冻结并“签署”了的规格说明；改写--并非僵化--是迭代开发和UP的核心价值。

        所谓的“冻结签署”是在细化阶段结束时，就项目剩余时间里所要完成的事项与涉众达成一致意见，并且就需求和进度给予承诺（可能是以合同形式），这是完全切合实际的。在某一时刻（在UP中是细化阶段的结束时刻），我们需要对“什么、多少、何时”有可靠的认识。从这种意义上说，签署关于需求的合约时正常的，也是有必要的。同时还需要具备变更控制过程（UP中明确的最佳实践之一），以便正式地考虑和批准需求变更，避免混乱和不受控的变更。

   “冻结签署”的事实还意味着如下几点：

   》 在迭代开发和UP中，无论在需求规格说明上付出多少努力，还是不可避免地会存在一些变更，这应该可以被接受。这些变更可能是能够为所有者带来竞争优势的、新近发生的对系统投机性的改进，或者是由于加深了认识而引起的改进。

  》  使涉众来进行评估、提供反馈以及掌握项目的方向以满足其真实意图，这是迭代开发的核心价值。“洗手不干”，不关注于参与项目，而是在一组冻结的需求上签字认可后就等待着项目结束，这样对涉众来说并没有好处，因为他们几乎不会得到真正满足其需要的结果。

  构造阶段    通过构造阶段，主要需求（包括功能性需求和其他需求）应该已经稳定下来，虽然还不是终结，但是已经可以专注于次要的微扰事物了。因此，在此阶段，补充性规格说明和设想都不必进行大量改动。

• 什么是初始阶段   大多数项目需要一个简短的起始步骤，在该步骤中要考虑以下几类问题：

  1、项目的设想和业务案例是什么？

  2、是否可行？

  3、购买还是开发？

  4、粗略估计一下成本：是一万还是十万美元，还是上百万美元？

  5、项目应该继续下去还是停止？

          想要定义设想并大致得出所需的预算，就必须研究需求。但是，初始阶段的目标并不是定义所有需求，或产生可信的预算或项目计划。

          对于是否存在过于简化的风险，其理念是，就未来新系统的总体目标和可行性而言，只进行足以形成合理判断的调查，并能够确定是否值得继续深入研究即可，而深入研究室细化阶段的工作。

           大多数需求分析是细化阶段进行的，并且伴以具有产品品质的早期编程和测试。

       因此，大多数项目的初始阶段的持续时间相对较短，例如耗时一周或几周。实际上，在许多 项目中，如果初始阶段的时间超过一周，那么“初始”就失去了它的意义，因为初始阶段只需确定这个项目是否值得认真研究，而不是真正去深入进行研究（这项工作应留待细化阶段进行）。

        用一句话来概括初始阶段：

          预见项目的范围、设想和业务案例

        用一句话来概括初始阶段要解决的问题：

          涉众是否就项目设想基本达成一致，项目是否值得继续进行认真研究

   

      在迭代开发和UP中，初始阶段的预算和计划是不可靠的。它只不过提供了对工作量的粗略估计，帮助人们决定是否将项目继续下去。

  初始阶段的持续时间     初始阶段主要是为项目目标建立一些初始的共同构想，确定项目是否可行，并决定是否值得进入细化阶段加以认真研究。如果预先就决定项目必须进行，并且项目显然是可行的，那么初始阶段会更加短暂。这时候，初始阶段可能只包含第一次需求研讨会，并为第一次迭代制定计划，然后就快速地进入细化阶段。

  初始阶段会创建的制品    PPT2列举了一般在初始阶段（或细化阶段早期）会创建的制品以及各个制品所解决的问题。后续几章将详细解释其中部分制品，特别是“用例模型”。  迭代开发的一个重要观点是：在初始阶段只完成其中部分制品，在后继迭代中对其进行精化。而且，除非认定某制品很可能具有实用价值，否则不应该创建该制品。因为是在初始阶段，所以相关的研究和制品内容都不多。

       在初始阶段可能要进行一些编程工作，其目的是创建“概念验证”原型，（典型的）通过面向UI的原型来澄清一些需求，以及为关键的“显示阻塞”技术问题做一些编程实验。

   

  是否意味着大量的文档   记住，这些制品都是可选的。要有选择地创建对项目确有价值的制品。因为这是迭代开发，所以重要的不是在初始阶段创建完整的规格说明，而是形成初始、概略的文档。这些文档在细化迭代中精化，以便响应由早期编程和测试得到的极有价值的反馈。  

         同样，创建制品或模型的重点不在于文档或图本身，而是其中蕴含的思想、分析和前期准备。这也正是敏捷建模的观点：建模的最大价值是增强理解，而非记录可靠的规格说明。

        还要注意的是，可以在以后的项目中部分重用以往项目中的制品。一般在不同项目中，风险、项目管理、测试和环境这些制品都可能存在大量相似之处。所有UP项目都应该用相同的名称，以相同方式来组织制品（例如风险列表、开发案例等）。这样就可以方便地从以往项目中找出能够在新项目中重用的制品。

  何时知道自己并不了解初始阶段

  1、当认为大部分项目的初始阶段会持续几周或更长时

  2、在初始阶段试图定义大部分的需求时

  3、期望初始阶段的预算和计划是可靠的

  4、定义架构（应该在细化阶段以迭代方式来定义架构）

  5、认为正确的工作顺序应该是：1>定义需求  2> 设计架构 3>实现

  6、没有业务案例或设想制品

  7、详细编写所有用例

  8、没有详细编写任何用例，与之相反，应该编写10%~20%的用例以便获得对问题范围的真实认知

   初始阶段中有多少UML初始阶段的目的是收集足够的信息来建立共同设想，决定项目是否继续进行，以及项目是否值得进入细化阶段来认真研究。   初始阶段更关注对基本范围的理解以及10%的需求，这主要是以文字方式表达的。实际上，本书就是如此，大多数UML图将出现在下一个阶段--细化阶段

+

• 简介 迭代开发是OOA/D成为最佳实践的核心，也是本书所介绍的OOA/D的核心。 敏捷实践（如敏捷建模）是有效地应用UML的关键。UP是相对流行的、示范性的迭代方法。本章将对这些主题进行介绍。

  相对于顺序或“瀑布”（waterfall）生命周期，迭代和进化式开发（interative and evolutionary development）对部分系统及早地引入了编程和测试，并重复这一循环。这种方式通常会在还没有详细定义所有需求的情况下假设开发开始，同时使用反馈来明确和改进演化中的规格说明。

  在迭代开发中，我们依赖于短时快速的开发步骤、反馈和改写来不断明确需求和设计。相比之下，瀑布模型提倡在编程之前就预先完成需求和设计步骤。一直以来，成功/失败的研究表明，瀑布模型和软件项目高失败率具有极大关系，对它的推广源于信念和风闻，而不是具有统计意义的证据。研究证实，迭代方法与较高的成功率、生产率和低缺陷率具有关系。

  什么事UP？ 其他方法能否对其进行补充   软件开发工程描述了构造、部署以及维护软件的方式。 统一过程已经成为一种流行的构造面向对象系统的迭代软件开发过程。特别是，Rational统一过程（Rational Unified Process ,RUP）是对统一过程的详细精化，并且已经被广泛采纳。

  UP是十分灵活和开放的，并且鼓励引进其他迭代方法中的有用的实践，诸如极限编程（Extreme Programming,XP）、Scrum等等。 例如，在UP项目中可以引入XP的测试驱动开发（test-driven development）、重构（refactoring）和持续集成（continuous integration）等实践。同样，也可以引入Scrum的公共项目室（“作战室”）和Scrum日常会议等实践。

  概括而言，本章介绍UP源于下述三个理由：

  1、UP是迭代过程。迭代开发对本书介绍OOA/D的方式，以及OOA/D的最佳实践具有影响。

  2、UP实践提供了如何实施OOA/D的示范结构。这也形成了本书的结构。

  3、UP具有灵活性，可以应用于轻量级和敏捷方法，这些方法包括其他敏捷方法（诸如XP或Scrum）的实现，稍后将对此作更多介绍。

  什么是迭代和进化式开发   迭代开发(interative development)是UP和大多数其他现代方法中的关键实践。在这种生命周期方法中，开发被组织成一系列固定的短期（如三个星期）小项目，称为迭代(iterative)，每次迭代都产生经过测试、集成并可执行的局部系统。每次迭代都具有各自的需求分析、设计、实现和测试活动。

        迭代生命周期基于对经过多次迭代的系统进行持续扩展和精化，并以循环反馈和调整为核心驱动力，使之最终成为适当的系统。随着时间和一次又一次迭代的递进，系统增量式地发展完善，因此这一方法也被称为迭代和增量式开发(interative and incremental development)(参见图2-1)。因为反馈和调整使规格说明和设计不断进化，所以这种方法也称为迭代和进化式开发(interative and evolutionary development)。

        每次迭代都产生可执行的但不完整的系统，它不是已经准备好可以交付的产品。直到多次迭代之后，系统才能够合格的用于产品部署。

        迭代的输出不是实验性的或将丢弃的原型，迭代开发也不是构造原型。与之相反，其输出是最终系统的产品子集。

   

  如何在迭代项目中处理变更

          每次迭代选择一小组需求，并快速设计、实现和测试。在早期迭代中，对需求和设计的选择对于最终期望来说可能并不准确。但是，在最终确定所有需求或经过深思熟虑而定义完整设计之前，快速地实施一小步的方式可以得到快速反馈--来自用户、开发人员和测试的反馈。

          这种反馈具有极高的价值。与“推测”完整、正确的需求或设计相反，团队可以从实际构造和测试的反馈中，挖掘出至关重要和实际的观点，并修改和调整对需求或设计的理解。 早期频繁地在“不错。。。但是”中循环，正是改进软件和发现什么对涉众有真正价值的实用方式。然而这并非对开发者不断变换方向的无序和反应式开发的认可，作为一条中间路线是可行的。

           除了明确需求之外，负载测试将验证局部设计和实现是否正确，或者是否需要在下次迭代中改变核心架构。最好及早解决和验证具有风险的、关键的设计决策，而迭代开发提供了完成这项工作的机制。

           因此，工作是通过一系列有序的构造--反馈--调整循环向前进展的。早期迭代中系统偏离“正确轨迹”的程度会大于后继迭代。随着时间的发展，系统将沿着这一轨迹收敛。如图2-2

   

  迭代开发的优点

      迭代开发的优点包括：

         1、减少项目失败可能性，提高生产率，降低缺陷率。对迭代和进化式的研究表明了这一点。

         2、在早期（而不是晚期）缓解高风险（技术、需求、目标、可用性等等）

         3、早期可见的进展

         4、早期反馈、用户参与和调整，会产生更接近涉众真实需求的精化系统。

         5、可控复杂性：团队不会被“分析瘫痪”或长期且复杂的步骤所淹没

         6、一次迭代中的经验可以被系统地用于改进开发过程本身，并如此反复进行下去。

   

  一次迭代的持续时间和时间定量

         大部分迭代方法建议迭代时间在2~6周之间。小步骤、快速反馈和调整时迭代开发的主要思想，迭代时间过长会破坏迭代开发的核心动机并增加项目风险。 迭代的一个关键思想是时间定量(timeboxed)，或时长固定。

  什么是瀑布生命周期    在瀑布生命周期过程中，试图在编程之前（详细定义所有或大部分需求）。而且在通常与编程之前创建出完整的设计。同样，会试图在开始前定义“可靠的”计划或时间表，但常常事与愿违。

   

  反馈和改写的必要性

      在复杂、变更系统中（如大多数软件项目），反馈和调整是成功的关键要素。

        1、来自早期开发中的反馈，有助于程序设计人员理解规格说明，客户演示也有助于精化需求。

        2、来自测试中的反馈，有助于开发者精化设计或模型。

        3、来自团队处理早期特性过程中的反馈，有助于精化时间表和估计

        4、来自客户和市场的反馈，有助于重新定义下一次迭代实现特性的优先级。

  + -

  如何进行进化和迭代式分析和设计  这里的介绍可能会给人留下这样的印象，即编程前的分析和设计毫无价值，但这是与瀑布思维同样偏激的误解。迭代和进化式分析设计师中庸之道。这里有个简短的例子，用以说明在运转良好的UP项目中，迭代方法是如何被运用的。这里假设在项目交付前，最终将有20次迭代。

  • 在第一次迭代之前，召开第一个时间定量的需求工作会议，例如确切的定义为两天时间。业务和开发人员（包括首席架构师）需要出席。

       1> 在第一天上午，进行高阶需求分析，例如仅仅确定用例和特性的名称，以及关键的非功能性需求。这种分析不可能是完美的。

       2>  通过咨询首席架构师和业务人员，从高阶列表中选择10%列表项（例如，30个用例中的10%），这些项目要具备以下三种性质：A、具有重要的架构意义（如果要实现，我们必须设计、构造和测试的核心架构） B、具有高业务价值（业务真正关心的特性） C、具有高风险（例如“能够处理500个并发交易”等）。所选的三个用例可能被标识为:UC2、UC11和UC14。

       3>在剩下的一天半内，对这三个用例的功能和非功能性需求进行详细的分析。完成这一过程后，对10%进行了深入分析，90%进行了高阶分析。

    在第一次迭代之前，召开迭代计划会议，选择UC2、UC11和UC14的子集，在特定时间内（例如，四周的时间定量迭代）进行设计、构造和测试。要注意的是，因为其中包含大量工作，所以并不是在第1次迭代中就要构造出全部三个用例。在选择了特定子集目标后，在开发团队的帮助下，将其分解为一系列更为详细的迭代任务。

    在三到四周内完成第1次迭代（选择时间定量，并严格遵守时间）。

      1> 在开始的两天内，开发者和其他成员分组进行建模和设计工作，在首席架构师的带领和指导 下，于“公共作战室”的众多白板上，画出UML的草图（及其他的模型）。

      2>  然后，开发者摘掉其"建模帽子"并带上"编程帽子"，开始编程、测试和集成工作并且剩余的时间均用于完成这项工作。开发者将建模草图作为其灵感的起点，但要清楚这些模型只是局部的，并且通常是含糊的。

      3> 进行大量的测试，包括单元测试、验收测试、负载测试和可用性测试等。

      4>  在结束前的一周，检查是否能够完成初始的迭代目标；如果不能，则缩小迭代的范围，将次要目标置回任务列表中。

      5> 在最后一周的星期二，冻结代码；必须检入、集成和测试所有代码，以建立迭代的基线。

      6> 在 星期三的上午，向外部涉众演示此局部系统，展示早期可视进展，同时要求反馈。 

    在第一次迭代即将结束时（如最后一周的星期三和星期四），召开第二次需求工作会，对上一次会议的所有材料进行复查和精化。然后选择具有重要架构意义和高业务价值的另外10%到15%的用例，用一到两天对其进行详细分析。这项工作完成后，会详细记录下大概25%的用例和非功能性需求。当然，这也不是完美的。

    于周五上午，举行下一次的迭代计划会议。

    以相同步骤进行第二次迭代

    反复进行四次迭代和五次需求工作会，这样在第四次迭代结束时，可能已经详细记录了约80%~90%的需求但只实现了系统的10% （注意，这些大量、详细的需求集是基于反馈和进化的，因此其质量远高于纯粹依靠推测而得出的瀑布式规格说明）

    我们大概推进了整个项目过程的20%。在UP的术语里，这是细化阶段(elaboration phase)的结束。此时，可以估计这些精化的、高质量的需求所需工作量和时间。因为具有依据现实得出的调查、反馈结论并进行了早期编程和测试，因此估计能够做什么和需要多长时间的结果会更为可靠。

    此后，一般不需要再召开需求工作会；需求已经稳定了（尽管需求永远不会被冻结）。接下来是一系列为期三周的迭代，在最后一个周五召开的迭代计划会议上选择适宜的下一步工作，每次迭代都要反复询问：“就我们现在所知，下一个三周应该完成的、最关键的技术和业务特性是什么？”

      PPT2-5 中描述了经过20次迭代的项目。

    利用这种方式、经过早期探索式开发的几次迭代之后，团队将能够更准确地回答“什么、多少、何时”。

  什么是风险驱动和客户驱动的迭代计划     UP（及大多数新方法）提倡风险驱动（risk-driven）与客户驱动(client-driven)相结合的迭代计划。这意味着早期的迭代目标要能够识别和降低最高风险，并且能构造客户最关心的可视化特性。

    风险驱动迭代开发更为明确地包含了以架构为中心（architecture-centric）迭代开发的实践，意味着早期迭代要致力于核心架构的构造、测试和稳定。为什么？因为没有稳固的架构就会带来高风险。

  什么是敏捷方法及其观点   敏捷开发(agile development)方法通常应用时间定量的迭代和进化式开发、使用自适应计划、提倡增量交付并包含其他提倡敏捷性（快速和灵活的响应变更）的价值和实践。除此之外，他们还提倡反映简易、轻量、沟通、自组织团队等更多敏捷性的实践和原则。

      Scrum敏捷方法中的实践范例包括公共项目工作室和自组织团队，这些实践通过每日例行会议来协调工作，在例会上要求每位成员回答四个特定的问题。  极限编程（XP）方法中的实践范例包括结对编程和测试驱动开发（test-driven development）。

      包括UP在内的任何迭代方法都可以施加以敏捷精神。

  什么是敏捷建模    有经验的分析员和建模者了解以下这条建模的秘诀： 建模（构建UML草图）的目的主要是为了理解，而非文档。  也就是说，建模的真正行为能够并且是应该能够对理解问题或解决方案空间提供更好的方式。 

      在"Agile Modeling" 一书中，将这种观点及与之一致的敏捷方法称为敏捷建模(agile modeling)。 这其中包含了以下许多实践和价值：

    1、采用敏捷方法并不意味着不进行任何建模，这是个错误理解。Feature-Driven Development、DSDM和Scrum等许多敏捷方法、一般都包含重要的建模期。正如Ambler(XP 方法和敏捷建模的专家)所言，即便是XP（可能是最少强调建模的最为知名的敏捷方法）的奠基人也认可敏捷建模，并且多年来有大量建模者都在实践中采用了敏捷建模。

    2、建模和模型的目的主要用于理解和沟通，而不是构建文档。

    3、不要对所有或大多数软件设计建模或应用UML。可以将简单的设计问题推延到编程阶段，在编程和测试过程中解决这些问题。只需对设计空间中不常见、困难和棘手的一小部分问题建模和应用UML  

    4、尽可能使用最简单的工具。建议使用支持快速输入和改变的“低能耗”创造力增强型的简易工具。同时，选择支持大可视空间的工具。例如，最好在白板上草图UML，使用数码相机捕获图形。（这里 并不是说UML CASE工具或字处理软件不可取或毫无价值，但是对于创造性工作来说，在白板上画草图更为流畅并便于修改。关键的规则是简单和敏捷，而不论使用何种技术）

    5、不要单独建模，而是结对在白板上建模，同时要记住建模的目的是发现、理解和共享大家的理解。小组成员要轮流画草图，以使每个人都参与其中。

    6、并行的创建模型。例如，在一块白板上勾勒UML动态视图的交互图，同时在另一白板上勾画出补充性的UML静态视图的类图。同时开发这两种模型（视图），并不断交替。

    7、在白板上用笔画草图时，应使用“足够好”的简单表示法。UML细节是否精准并不重要，关键是建模者能够互相理解，坚持使用简单、常用的UML元素。

    8、要知道所有模型都可能是不准确的，最终代码或设计会与模型有差异，甚至具有极大的差异。只有测试过的代码才能证实真正的设计；先前绘制的模型图都是不完整的，最好只是将其视为一次探索。

    9、开发者应该为自己进行OO设计建模，而不是创建模型图后交给其他编程者去实现--这是非敏捷的面向瀑布的方法。

   

  本书中的敏捷建模：为什么使用UML草图的快照  因为这些图是为了提高可读性而使用工具精心绘制的。为了让大家感受真实情况，本书有时会使用在白板绘制的UML草图的数码快照。这样虽然易读性差一些，但是可以提醒读者敏捷建模是很有用的，并且这种方式是案例研究所使用的实际工作方式。

  什么是敏捷UP  UP的创始人并没有为其赋予重量级或非敏捷的含义，尽管其庞大的可选活动集和制品集会给人留下这种印象。实际上，UP可以采纳和应用可适应性和轻量级的精神--敏捷UP。以下是应用的一些示例：

    1、推荐使用UP活动和制品的简集。虽然某些项目得益于使用较多的UML活动和制品，但一般来说应该保持简洁。要记住，所有UP制品都是可选的，除非它们能增加价值，否则避免创建这些制品。应该致力于早期的编程，而非构建文档。

    2、UP是迭代和不断进化的，所以在实现前的需求和设计师不完整的。它们是在一系列迭代中，基于反馈而产生的。

    3、以敏捷建模实践应用UML

    4、对于整个项目不应有详细的计划。应该制定估计结束日期和主要里程碑的高阶计划（称为阶段计划），但是不要对这些里程碑详细定义细粒度的步骤。只能预先对一个迭代制定更为详细的计划（称为迭代计划）。详细计划是由一次次迭代的调整而完成的。

  UP的其他关键实践   UP所倡导的核心思想是：短时间定量迭代、进化和可适应性开发。其他一些UP的最佳实践和关键概念包括：

     1、在早期迭代中解决高风险和高价值的问题

     2、不断地让用户参与评估、反馈和需求

     3、在早期迭代中建立内聚的核心架构

     4、不断的验证质量；提早、经常和实际地测试

     5、在适当的地方使用用例

     6、进行一些可视化建模（使用UML）

     7、认真管理需求

     8、实时变更请求和配置管理

  什么是UP的阶段    UP项目将其工作和迭代组织为四个主要阶段：

  1、初始（Inception）：大体上的构想、业务案例、范围和模糊评估

  2、细化（Elaboration）：已精化的构想、核心架构的迭代实现、高风险的解决、确定大多数需求和范围以及进行更为实际的评估

  3、构造（Construction）：对遗留下来的风险较低和比较简单的元素进行迭代实现，准备部署

  4、移交（Transition）：进行beta测试和部署

    图2-6说明了UP中常用的面向进度表的术语。注意，一个开发周期（以系统发布为产品作为结束标志）由多个迭代组成

  什么是UP科目     UP描述了科目(discipline)中的工作活动，例如编写用例。科目是在一个主题域中的一组活动（及相关制品），例如需求分析中的活动。在UP中，制品（artifact）是对所有工作产品的统称，如代码、Web图形、数据库模式、文本文档、图、模型等。

      UP中有几个科目，本书中只关注以下三个科目中的制品：

     1、业务建模：  领域模型制品，使应用领域中的重要概念的可视化。

     2、需求：用以捕获功能需求和非功能需求的用例模型及其补充性的规格说明制品。

     3、设计：设计模型制品，用于对软件对象进行设计。

   图2-7列出了更多的UP科目。  在图中，实现表示编程和构建系统，而不是部署。环境科目是指建立工具并为项目定制过程，也就是说，设置工具和过程环境。

   

  科目和阶段之间的关系    如图2-7所示，一次迭代的工作会遍历大部分或全部科目。然而，跨越这些科目的相对工作量会随着时间发生变化。自然而然，早期迭代倾向于更多的需求和设计，后期迭代则较少进行这方面的工作，因为通过反馈和改写过程，需求和核心已经趋向于稳定。

      就UP阶段（初始、细化等）的这一主题，图2-8阐述了对应于各阶段的相对工作量的变化。请注意，这只是建设性意见，而非强制。

   

  UP阶段和科目对本书结构的影响   案例研究强调初始和细化阶段。其重点是业务建模、需求和设计科目中的一些制品，因为这些都是需求分析、OOA/D、模式和UML的主要应用之处。

   

  下面的列表和图2-9描述了本书关于UP阶段的组织。

  1、初始阶段对应的章介绍需求分析的基本内容

  2、迭代1介绍OOA/D基础和如何为对象分配职责

  3、迭代2的重点是对象设计，特别介绍一些经常使用的“设计模式”

  4、迭代3介绍各种主题，例如架构分析和框架设计。

  如何定制过程和UP开发案例

   

  UP中有可选制品或实践吗    当然！ 几乎所有的制品和实践都是可选的。也就是说，某些UP实践和原则是一成不变的，例如迭代和风险驱动开发以及质量的持续验证。 然而，UP的一个关键内涵是，所有活动和制品（模型、图、文档。。。）都是可选的--或许除了代码！

   

  UP中描述的一组可能的制品可以看作药房里的一组药剂。就像不会有人不加选择地随便吃药，而是要对症下药一样，对于UP项目，开发团队应该选择一组能够解决其特定问题和需要的制品。一般来说，要关注一组具有较高实践价值的制品。

   

  定义：什么是开发案例   为项目选择实践和UP制品可以编写为简短文档，这称为开发案例（环境科目中的制品）（PPT01）可以作为本书所探讨的"NextGen项目"案例研究中的开发案例

  判断你是否理解迭代开发或UP  若出现以下迹象，表明你并没有理解以敏捷精神采用迭代开发和UP的真正含义。

  1、在开始设计或实现之前试图定义大多数需求。同样，在开始实现之前试图定义大多数设计；试图在迭代编程和测试之前定义和提交完整的架构

  2、在编程之前花费数日或数周进行UML建模，或者认为在绘制UML图和进行设计时要准确完整地定义及其详细的设计和模型。并且，认为编程只是简单机械地将其转换为代码的过程

  3、认为初始阶段=需求阶段，细化阶段=设计阶段，构造阶段=实现阶段（也就是说将瀑布模型叠加于UP之上）

  4、认为细化的目的是完整仔细地定义模型，以能够在构造阶段将其转换为代码

  5、坚信合适的迭代时间长度为三个月之久，而不是三周

  6、认为采用UP就意味着要完成大量可能的活动和创建大量的文档，并且认为UP是需要遵循大量步骤的、正规和繁琐的过程

  7、试图对项目从开始到结束制定详细计划；试图预测所有迭代，以及每个迭代中可能发生的事情。

关于作者：

       20世纪80年代中期以来，Craig帮助了数以千计的开发者，使他们能够应用OOA/D、熟练使用UML建模技术、采用迭代开发实践。

       在结束其街头流浪音乐家生涯后，Craig在20世纪70年代开始使用APL、PL/I和CICS建立系统。从20世纪80年代初期开始，他开始对人工智能产生兴趣、并用Lisp机器、Lisp、Prolog和Smalltalk建立过知识系统。他也为使用Java、.NET、C++和Smalltalk建立系统的公司工作过。他在大部分业余时间里担任过Changing Requirement乐队的主音吉他手。

       他在加拿大温哥华Simon Fraser大学获得计算机科学学士和硕士学位。

~ 第1章：面向对象分析和设计

• 本书的主要内容  “拥有一把锤子未必能成为架构师”，这句谚语在对象技术领域同样适用。对创建对象系统来说，了解面向对象语言（例如Java）是必要的，但不是首先要做的。了解“对象思想”才是关键所在！

      本书是对应用了统一建模语言（UML）和模式的OOA/D的介绍。同时，对于迭代开发，本书使用统一过程（Unified Process）的敏捷方法作为示例迭代过程。

  UML和对象思想 UML并不是OOA/D，也不是方法，它只是图形表示法。如果没有真正掌握如何创建优秀的面向对象设计，或者如何评估和改进现有设计，那么学习UML或者UML CASE工具是毫无意义的。对象思想才是重点和难点。因此本书重点阐述对象设计。 而且，我们需要一种用于OOA/D和“软件蓝图”的语言，这既是一种思考的工具，也是一种沟通的形式。因此，本书也将探讨如何在OOA/D中应用UML，并涵盖经常使用的UML表示法。

  OOD的原则和模式 应该如何为对象分配职责（responsibility）?对象之间应该如何协作？什么样的类应该做什么样的事情？这些都是系统设计中的关键问题，而本书将会讲授作为经典OO设计之象征的职责驱动设计（responsibility-driven design）。同时，某些针对设计问题的，经过反复验证的解决方案可以被表示成为最佳实践的原则、启示或模式（pattern），即问题-解决方案公式，这些公式是系统化的、典型的设计原则。本书将会通过讲授如何应用模式或原则，使读者更快地学习和熟练使用这些基本的对象设计习惯用法。

  案例研究 本书对OOA/D的介绍是通过一些贯穿全书的案例研究（ongoing case study）来阐述的，并且充分深入到分析和设计中，考虑和解决了现实问题中令人生畏但必须被考虑和解决的细节。

  用例 OOD(以及所有软件设计)与作为其先决活动的需求分析(requirement analysis)具有紧密联系，而在需求分析中通常包含用例（use case）的编写。因此，尽管这些主题并非是特定与面向对象的，但也会在案例研究的开始对其进行介绍。

  迭代开发、敏捷建模和敏捷UP   需求分析和OOA/D需要在某种开发过程的语境中进行描述和实践。在这种情况下，使用著名的统一过程  （Unified Process）的敏捷（轻量的、灵活的）方法作为迭代开发过程（iterative development process）的样例，并在这一过程中介绍需求需求分析和OOA/D的主题。然而，这里所涵盖的分析和设计主题对于许多开发过程是通用的，在敏捷UP的语境中学习它们并不影响这些技术对于其他方法的适用性，这些方法包括Srucm、Feature-Driven Development(FDD)、lean Development、Crystal Methods等等。

  重要的学习目标 在OO开发中，至关重要的能力是熟练地为软件对象分配职责。为什么？ 因为分配职责是必须要执行的一项活动（无论是画UML图时还是进行程序设计，都要为软件对象分配职责），并且它对软件构件的健壮性、可维护性和可重用性具有重要影响。

  什么是分析和设计 分析（analysis）强调的是对问题和需求的调查研究，而不是解决方案。“分析”一次含义广泛，最好加以限制，如需求分析（对需求的调查研究）或面向对象分析（对领域对象的调查研究）。

  设计 （design）强调的是满足需求的概念上的解决方案（在软件方面和硬件方面），而不是其实现。与“分析”相同，对“设计”一词最好也加以限制，如面向对象设计或数据库设计。

  什么是面向对象分析和设计 在面向对象分析（object-oriented analysis）过程中，强调的是在问题领域内发现和描述对象（或概念）。

  在面向对象设计(object-oriented design，简称对象设计)过程中，强调的是定义软件对象以及它们如何协作以实现需求。

  1、定义用例 需求分析可能包括人们如何使用应用的情节或场景，这些情节或场景可以被编写成用例（use case）。用例不是面向对象制品，而只是对情节的记录。但用例是需求分析中的一种常用工具。

  2、定义领域模型  面向对象分析关注从对象的角度创建领域描述。面向对象分析需要鉴别重要的概念、属性和关联。  面向对象分析的结果可以表示为领域模型，在领域模型中展示重要的领域概念或对象。需要注意的是，领域模型模型并不是对软件对象的描述，它使真实世界领域中的概念和想象可视化。因此，它也被称为概念对象模型（conceptual object model）。

  3、分配对象职责并绘制交互图  面向对象设计关注软件对象的定义--它们的职责和协作。顺序图(sequence diagram,UML的一种交互图)是描述协作的常见表示法。它展示出软件对象之间的消息流，和由消息引起的方法调用。

  4、定义设计类图 除了在交互图中显示对象协作的动态视图外、还可以用设计类图（design class diagram）来有效地表示类定义的静态视图。这样可以描述类的属性和方法。

  什么是UML  统一建模语言（UML）是描述、构造和文档化系统制品的可视化语言。

  在上面的UML定义中，关键点是可视化这个词，UML是图形化表示法的事实标准，用来绘制和展示与软件有关的图形（以及文字）。本书重点关注UML的常用图、这些常用图中的常用特性和在未来版本中不太可能变化的核心表示法。

  UML定义了各种UML简档（UML profile），这些简档专用于某些常用主题领域的表示法子集，例如对EJB使用UML EJB简档。

  在更深入的层次上，UML表示法的基础是UML元模型(meta-model)，它描述建模元素的语义，UML元模型主要对模型驱动架构（Model Driven Architecture，MDA）CASE工具供应商具有影响。开发者并不需要对其进行学习。

  + - 1、应用UML的三种方式

  • UML作为草图 非正式的、不完整的图（通常是在白板上手绘草图），借助可视化语言的功能，用于探讨问题或解决方案空间的复杂部分。

    UML作为蓝图 相对详细的设计图，用于：1）逆向工程，即以UML图的方式对现有代码进行可视化，使其易于理解。2）代码生成（前项工程）。

    对于逆向工程，UML工具读取源文件或二进制文件，并生成UML包图、类图和顺序图（一般情况下）。这些“蓝图”能够帮助读者从整体上理解元素、结构和协作。

    无论是人工还是使用自动工具生成代码，在此之间绘制一些详细的图都能够为生成代码的工作提供指导。一般情况下，代码生成工具使用图生成一些代码，然后由开发者编写并填充其他代码。

    UML作为编程语言  用UML完成软件系统可执行规格说明。可执行代码能够被自动生成，但并不像通常一样为开发者所见或修改；人们仅使用UML“编程语言”进行工作。如此应用UML需要有将所有行为或逻辑进行图形化表示的实用方法，但是目前在理论、工具的健壮性和可用性方面仍然处于发展阶段。

    UML和银弹思想  时间检验真理。UML仅仅是标准的图形化表示法，使用常用符号的可视化建模能够带来极大的帮助，但它不可能与设计和对象思想同等重要。设计知识是极不寻常的且更为重要的技能，它并不是通过学习UML表示法或者CASE或MDA工具就可以掌握的。如果不具备良好的OO设计和编程技能那么即使使用UML，也只能画出挫劣的设计。如果要深入了解这一主题，建议阅读“Death by UML Fever”(UML的发明者Grady Booch亦为认可)和"What UML Is and Isn't?" 因此，本书是对OOA/D和应用UML进行熟练OO设计的介绍

    敏捷建模（agile modeling）强调了UML作为草图的方式，这也是使用UML的普通方式，而且通常对时间投入具有高回报（一般费时较短）。虽然UML工具能够提供帮助，但是建议也考虑使用UML的敏捷建模方法。

  + -

  2、应用UML的三种透视图 UML描述的是原始图类型，如类图和顺序图。它并没有在这些图上叠加建模的透视图。例如，同样的UML类图表示法既能够描绘现实世界的概念，又能够描绘Java中的软件类。

  Systropy面向对象方法强调了这一观点。其主旨是，同一种表示法可以用来描述模型的三种透视图和类型

  • 概念透视图 用图来描述现实世界或关注领域中的事物。

    规格说明（软件）透视图   用图（使用与概念透视图中相同的表示法） 来描述软件的抽象物或具有规格说明和接口的构件，但是并不约定特定实现（例如，非特定为C#或Java中的类）。

    实现（软件）透视图  用图来描述特定技术中的软件实现。

    在实际设计过程中，很少会使用规格说明透视图（推迟了目标技术的选择，例如使用Java还是使用.Net）；大多数面向软件的UML图都会采用实现透视图。

    不同透视图中“类”的含义  在原始的UML中，图1-6中的矩形被称为类（class），但这个术语包含各种现象，如物理事务、抽象概念、软件事物、事件等等。

    一个方法在原始UML之上添加了另一个术语。例如，在UP中，领域模型中的UML框被称为领域模型(domain concept)或概念类（conceptual class）。领域模型表示的是概念透视图。设计模型中的UML框被称为设计类（design class），设计模型依据建模者的需要，表示的是规格说明透视图或实现透视图。

       为清晰起见，本书中与类相关的术语将与UML和UP保持一致，这些术语如下：

    1、概念类（conceptual class）--现实世界中的概念或事物。在概念或本质透视图中使用。UP领域模型中包含概念类。

    2、软件类（software class）--无论在过程还是方法中，都表示软件构件在规格说明或实现透视图中的类。

    3、实现类（implement class）--特定OO语言中的类。

  为何在某些章中没有大量使用UML 本书的主题并不是UML表示法，而是在OOA/D和相关需求分析的语境下，对UML应用、模式和迭代过程的全景揭示。需求分析通常先于OOA/D，因此，本书在开始几章先介绍关于用例和需求分析的重要主题，然后再后继各章中详细介绍OOA/D和UML。

  可视化建模的优点 用符号来表示说明问题所冒的风险是显而易见的，绘制或阅读UML意味着我们要以更加可视化的方式工作，开发我们的脑力，以便更快地掌握（主流）二维框-线表示法中的符号、单元及关系。

  这个古老而朴素的道理常常会遗失在大量的UML细节和工具中。这是不应该的！图可以帮助我们更为便利地观察全景，发现软件元素或分析之间的联系，同时允许我们忽略或隐藏旁支末节。这是UML或其他图形化语言的本质价值。