什么是分析类

分析类是这样的类：

 它代表问题域中的简洁抽象；

 应该映射到真实世界的业务概念（并且据此仔细命名）。 问题域是首先产生软件系统（以及从此而来的软件开发活动）需求的域。通常，这是特定的业务

领域，如在线销售或者客户关系管理。然而，务必注意，问题域可能根本不是任何特定业务活动，但 是可能产生需要软件在其上运转的一块物理硬件─这是嵌入式系统。基本上，所有业务软件开发服 务于某种业务需求，自动化一个已有业务过程或者开发具有有意义的软件组件的新产品。

找出分析类

分析类的最重要方面是，应该使用清晰和无歧义的方法映射到某个真实世界业务概念，如客户、 产品或账户。然而，这是假设业务概念本身是清晰和无歧义的，这种情况却很少见。因此，OO分析 师的工作是力求把混淆或不恰当的业务概念澄清为能够形成分析类基础的事物。这是为什么分析工作 困难的原因。

因此建模OO软件的{dy}步是澄清问题域。如果它包含清晰定义的业务概念并且具有简单的、功 能化的结构，那么事实上解决方案就垂手可得了。这些工作的大部分是在需求工作流中捕获需求的活 动、创建用例模型和项目词汇表的活动中完成的。然而，进一步的澄清工作发生在创建分析类的用例 实现的过程中。

分析模型中的所有类都是分析类，而不是从设计考虑而产生的类（问题域），这一点是很重要的。 当你详细设计时，可能发现一个分析类被精化为一个或多个设计类。

尽管在先前章节中，我们必须开始于考虑特定的对象，现在清楚了，OO 分析的真正目的是找出 那些对象的类。实际上，找出恰当的分析类是OO分析和设计的关键。如果分析类不恰当，那么基于 需求和分析工作的需求工程的后续工作，将会处在危险之中。因此，在分析工作流中花费足够的时间 确保已经识别恰当的分析类集合是很关键的。要很好地使用这段时间，因为几乎可以肯定，它将在以 后节省时间。

在本书中，我们xx业务系统的开发，因为这是大多数OO分析师和设计师专心从事的事业。然 而，嵌入式系统的开发仅是正常业务系统开发的特殊情况，所有相同的原则都适用。业务系统通常由 功能性需求所主导，因此通常需求和分析活动是非常困难的。在嵌入式系统中，它趋向于由非功能性 需求所主导，需求常常是给定的，分析趋向于直接，但是设计可能是困难的。需求对于所有类型的系 统来说都至关重要，对于某些嵌入式系统，例如 x 射线控制器，它们是生命攸关的大事。

8.3.1 分析类剖析

分析类应该展示非常“高级层次”的属性集合，它们表示最终设计类可能具有的属性。我们可以 说分析类为设计类捕获候选属性准备了条件。

分析类操作，在高级层次上，说明类必须提供的关键服务。在设计中，它们将成为实际的、可实 现的操作。然而，一个分析级的操作常常分解成多于一种的设计级的操作。

我们已经在第7章非常详细地覆盖了UML语法，但是在分析中，实际上仅使用该语法的、小的子 集。当然，分析师为了使模型更加清晰总是可以自由添加修饰。然而，分析类的基础语法总是避免实 现细节。毕竟，在分析中，我们尝试捕获大场景。

分析类的最小形式由以下部分组成：

? 名称─这是强制的。

? 属性─尽管只有候选属性的重要子集在此时建模，但是属性的名称是强制的。属性类型被认 为是可选的。

? 操作─ 在分析中，操作仅是类职责的高级层次的陈述。只在它们对于理解该模型很重要时， 显示操作的参数和返回类型。

? 可视性─通常不显示。

? 构造型─如果它们增强模型，可以显示出来。

? 标记值─如果它们增强模型，可以显示出来。

 第三部分 分 析

示例显示在图8-3中。 分析类的思想是，尽力捕获抽象的本质，忽略实现细节，直到你达到设计阶段。

8.3.2 如何产生良好的分析类

我们可以概括形成良好分析类有以下几种做法：

? 它的名称反映目的；

? 它是简洁的抽象，建模问题域的任一个特定元素；

? 它清晰地映射到问题域中的可识别的特征；

? 它具有小的、良好定义的职责集合；

? 它是高内聚的；

? 它是低耦合的。

类名称

属性

操作

在分析中，你力图从正在建模的系统角度xx简洁地建模问题域的一个方面。例如，你正在建模 银行系统的客户 Customer，将想捕获客户 Customer 的名称和地址等，但是你不可能对他们在航班上 对于窗口或过道座位的偏好感兴趣。你需要从你正在建模的系统角度xx真实世界的事物。

你经常仅从它的名称就能够得出{dy}念头，一个类是不是“好”类。如果考虑电子商务系统，客 户 Customer 借指真实世界的事物似乎非常xx，并且将是类的很好候选。同样，购物篮 ShoppingBasket也是一个很好的抽象─我们几乎直觉地知道它的语义是什么。然而，诸如网站访问 者WebSiteVisitor的事物似乎具有相对模糊的语义，实际上看起来像客户Customer扮演的、与电子商 务系统相关的角色。你应该总是寻找“简洁的抽象”─具有清晰的和显而易见语义的事物。

职责是类和它的客户之间的契约或者是类对它的客户的义务。本质上，职责是类提供给其他类的 服务。分析类具有直接同类（由它的名称所表达）的目的相一致的以及直接同该类正在建模的真实世 界“事物”相一致的非常内聚的职责集合，这一点是至关重要的。回到ShoppingBasket示例，你将期 望该类具有如下职责：

? 向购物篮添加商品；

? 从购物篮删除商品；

? 显示购物篮中的商品。 这是内聚的职责集合，一切都是为了维护客户选择的商品集合。它是内聚的，因为所有的职责都

朝着相同的目标─维护客户已经选择的商品集合。实际上，我们能够把这些职责概括为非常高级层 次的职责“维护购物篮”。

现在，你同样能够向 ShoppingBasket 中添加如下职责：

? 验证信用卡；

? 接收付款；

? 打印收据。 但这些职责似乎同购物篮的目的或直觉语法不匹配。它们不是内聚的，显然应该赋予其他什么

类─ 可能是类CreditCardCompany、类Checkout以及类ReceiptPrinter。把职责适当地分配给分析类 以{zd0}化每个类中的内聚性，是很重要的。

{zh1}，良好的类与其他类之间具有{zd1}数目的耦合。我们以给定类与其他类具有关系的数目来度

量类间的耦合度。类间职责的平均分布趋向于产生低耦合度。把控制或职责局限于单一的类趋向于增 加到该类的耦合度。我们在第15章考虑{zd0}化内聚和最小化耦合的方法。

8.3.3 分析类经验法则

以下是创建形式良好的分析类的一些经验法则。

? 每个类大约3~5个职责─典型地，类应该保持尽可能简单，这通常限制类能够支持的3~5个职 责的数目。先前ShoppingBasket 的示例是带有小的和可管理数目职责的专注的类的好的示例。

? 不存在独立的类─好的OO分析和设计的精华是，类相互协作让用户受益。同样，每个类应该 同小部分类协作以提供所期望的功能。类可以把它们的一些职责托付给专注于特定功能的其他

“辅助”类。

? 当心很多非常小的类─ 有时很难取得正确的平衡。如果模型看起来具有大量的非常小的类， 每个类都具有一个或者两个职责，那么你应该仔细查看以把一些小的类整合成更大的类。

? 当心少数几个非常庞大的类─上述的反面是，模型具有很少的类，但每个类都是具有职责数 量（>5）的庞大的类。解决问题的策略是依次查看这些类，看看是否每个类都能够被分解成为 两个或者多个能够承担恰当数目职责的、更小的类。

? 当心“伪类”─伪类其实是一般的过程函数，它伪装成类。Grady Booch 讲了一件奇闻轶事， 一个非常简单的系统却具有成千上万个类。仔细审视，每个类恰有一个被称为dolt（）（傻瓜） 的操作。当分析师习惯于从上而下功能分解的技术，{dy}次处理OO分析和设计时，伪类对他 来说总是很危险的。

? 当心{wn}类─ 存在似乎能够承担任何工作的类。看看名称为“system”和“controller”的 类！处理这个问题的策略是看看{wn}类的职责是否能够分解成内聚的子集。如果是，每个这些 内聚职责集合可能独立成类。这些更小的类协作以实现由原始{wn}类所提供的行为。

? 避免深度继承树─设计良好的继承层次的本质是继承层次中每个抽象层次应该具有良好定义 的目的。容易添加很多实际上不能服务于任何目的层次。实际上，通常的错误是使用继承来实 现一种功能分解，其中每个抽象层次恰有一个职责。无论从哪个方面来讲，这都是无意义的， 是会导致复杂的、难以理解的模型。分析中，继承仅用在存在直接产生于问题域的、清晰的、 显而易见的继承层次的场合。 在{zh1}的要点中，我们需要澄清“深度”继承的意义。在分析中，类代表业务事物，“深度”是超过三层或者更多的继承层次。这是因为业务事物趋向于形成更宽（不超过三层）的继承层次。 在设计中，该继承树由解域的类所组成，“深度”依赖于目标系统的实现语言。在 Java、C++、 C#、Python 以及 Visual Basic中，我们仍然把三层或者更多层次的继承认为是“深度”继承。然而，在 Smalltalk 中，继承树可以比这更深，它是由Smalltalk系统的结构所决定的。