指南： 边界类
 边界类 |
|
主题
解释 
边界类用于对系统与其环境（即系统的主角）之间的交互进行建模。边界类中包括了交互的以下方面：
- 使用系统的“内部元素”来协调主角的行为；
- 接收从主角到系统的输入，例如信息或请求；
- 提供从系统到主角的输出，例如存储的信息或派生的结果。
因此，边界类可用于获取对用户界面的需求。目前所创建的许多用户界面都是面向对象的，并且面向对象的界面由于使用起来直观有效而成为了发展趋势，因此创建用户界面的对象模型是非常值得的。虽然用户界面设计方面的许多决定都最好在设计用户界面原型和快速开发用户界面的过程中作出，但仍有必要在对象模型中对用户界面的结构和可用性需求进行研究。
使用边界类建立用户界面模型
要理解本指南的其余部分，请参见指南：用户界面（一般）中的“窗口基本原理：设置环境”一节。
可以使用边界类来建立基于窗口的用户界面模型；从较高的层次上，可以将其描述为以下几点：
- 使用一个边界类来表示一个主窗口。
- 使用一个边界类来表示主窗口中每个由主角操作的相关逻辑对象（类型）；每个这样的对象也常会有自己的辅助窗口，例如特征窗口。
- 使用边界类的职责来描述需要对其相关窗口和对象执行的操作。
- 使用边界类的属性来描述其相关窗口和对象的特征。
- 使用边界类之间的关系来表示关系，例如其相应窗口和对象的聚合关系分层结构及导航路径。
- 使用边界类的特殊需求来表示其相应窗口和对象的可用性需求和其他类型的需求，例如设计与实施需求。
对于以上示例中的窗口及其对象，我们可以确定如下边界类、职责、属性、关系和特殊需求。
边界类示例
可以为文档编辑器确定以下边界类：
请注意，其中包括了 Character 边界类。这是因为在这一特定的应用程序（即文档编辑器）中，要将一个字符看作其自身的对象，Character 边界类是必不可少的。当然，如果 Character 类在所建模的应用程序中并非必需，就不应使用 Character 类。在这种情况下，Character 边界类可能是过细的划分。
可以为邮件应用程序确定以下边界类：
可以为文件处理确定以下边界类：
边界类职责示例
可以为文档编辑器确定以下职责：
Split 职责用于将一个 Document 拆分为两个（子）窗口。Find(Text) 职责用于在 Document 中查找某一 Text。
可以为邮件应用程序确定以下职责：
Arrange(Criteria) 职责用于根据各种标准（如发送方、主题和接收时间等）对 Mail Box 中的 Mail Message 进行整理。
可以为文件处理确定以下职责：
边界类属性示例
可以为文件编辑器确定以下属性：
请注意，这里列出的是概念层次上的属性类型，在实际的用户界面中，属性类型可以用各种度量单位（如厘米、英寸等）来实现。
可以为邮件应用程序确定以下属性：
边界类关系示例
可以为文件编辑器确定以下聚合关系：
请注意，主窗口（在下例中为 Document）常常是一个聚合关系类，因为它可以包含任意数量的其他对象。但是，聚合关系类（例如 Paragraph）也可以存在于其他聚合关系类中，并不一定表示主窗口。
可以为邮件应用程序确定以下聚合关系：
就文件而言，Folder 和 File 之间的关系可建模为一个聚合关系：
可以为文件编辑器确定以下关联关系：
一个 Footnote 必须始终与一个 Character 相关联。在另一方面，一个 Character 可以和一个或多个 Footnote 相关联。
请注意聚合关系和（普通）关联关系之间的区别。 聚合关系常用于建立包含结构的模型，而关联关系则用于建立不同包含分层结构之间的关系和备选导航路径的模型。
建立用户控制继承的模型就是关联关系的一种高级应用。这样，被继承对象和继承对象之间就应存在关联关系；这种情况的一个示例是 Paragraph 继承 Style：
可以为文件编辑器确定以下泛化关系：
一个 Document 也是一个 File，这意味着 Document 继承了 File 的所有职责和属性。
可以为邮件应用程序确定以下泛化关系：
边界类特殊需求示例
边界类的特殊需求可以是：
- 可用性需求，例如与边界类相关的用户执行时间、学习时间和错误率。
- 非功能性需求，这些需求记录在边界类中，但需要在设计和实施相应的用户界面时进行处理。这种需求的一个示例是，某个边界类应该使用某个特定的构件（例如一个 ActiveX 控件）来实施。
示例：
有关 Character 类的可用性需求可以是：
-
Character 类应该提供以下导航功能，即通过一次鼠标动作即可转到任何关联关系的脚注。
有关 Mail Message 类的可用性需求可以是：
-
当阅读现有的邮件消息时，邮件用户不应该受到输入邮件消息的干扰。
有关 Mail Box 的可用性需求可以是：
-
邮件用户应该可以通过单击鼠标一次来完成对邮件消息的整理。
其他可用性需求与属性值和对象容量有关。这是因为用户界面常会需要提供一个简明易懂的界面，用于特定属性值的有关范围；或者需要提供对于特定对象容量范围的可用管理方式。这样的范围应代表正常的情况，即包括多达 90% 的正常情况。然而，用户界面将包含所有值，其中包括那些超出范围的值，但用户界面还可以为正常范围内的值进行优化。
示例：
有关 Document 类所包含的对象容量的可用性需求可以是：
-
一个 Document 应该能够管理 1000 个 Paragraph，而不会使窗口的滚动变慢。
有关 Mail Message 类属性值的可用性需求可以是：
-
一个 Subject 应该能包含 40 个没有用连字符连接的字符。
建立主角与边界类之间的关联关系
由于边界类对主角和系统之间的交互进行了建模，我们可以将各个主角和处理与该主角交互的边界类相关联，从而使交互更加清晰。
示例：
我们已经为文档编辑器确定了一个主角：与 Document 进行交互的 Writer。
一个 Writer 可以处理多个不同的 Document。一个 Document 可以由多个不同的 Writer 来创建。请注意，这可能意味着 Document 需要有区分不同 Writer 的能力。
此外，在这种情况下，从上下文中可以知道，Writer 与 Document 下聚合关系分层结构中的所有对象进行交互。
我们也为邮件应用程序确定了一个主角：与 Mail Box 进行交互的 Mail User。
在这种情况下，从上下文中同样可以知道，Mail User 与 Mail Box 下聚合关系分层结构中包含的所有对象进行交互。
边界类及其关系的优劣标准
许多用户界面都存在拥有太多窗口而且窗口导航路径太长这一问题。除了导致额外的无用交互之外，太长的窗口导航路径还会使用户更容易在系统中“迷路”。理想情况下，所有的窗口都应该可以从同一个主窗口打开。这样，您的最大导航长度就为二。要避免使导航长度大于三。
所以，应确保每个主角只有一个主窗口，如果可能的话，这个主窗口应包含该主角需要访问的所有对象。这就是构建用户界面的一个重要目标。如果不能实现该目标，那么主窗口就应为该主角提供到达需要访问的所有对象的导航路径。主角将为此花费相当多的“使用时间”来与这一主窗口进行交互，这一点很重要。
因此，它对用户界面的对象模型具有以下影响：
- 如果可能，每个主角应该只和一个表示主窗口的边界类（聚合关系）相关。
- 同一个主角使用的所有边界类之间应该建立某种关系。这种关系常通过一个聚合关系分层结构（从表示主窗口的边界类开始）来实现。
- 聚合关系分层结构的各个层次包含的对象应该尽可能多，而层次的总数则应该尽可能少。
- 边界类一般应属于一个（且只属于一个）聚合关系分层结构，以便让主角知道如何去查找到它。
- 聚合关系分层结构应尽可能少，否则会使主角的思维模型复杂化。
- 当一个关联关系的多重性为一，并且被关联关系的类分属不同的聚合关系分层结构时，如果两个聚合关系分层结构能合并在一起，就应考虑用一个聚合关系来替换此关联关系。但是值得注意的是，这可能会导致在一个较深的聚合关系分层结构和两个较浅的聚合关系分层结构之间的折衷聚合关系分层结构。
以上提供了相当详细的优劣标准。归纳起来，我们可以列出如下标准（虽然不够详细，但至少说明了边界类的使用目的）：
- 边界类应该有助于提高系统的可用性。
- 边界类应该尽可能地保持在较高的层次（如概念层次）上。
- 边界类应该合理封装介于系统与主角之间的交互。
- 如果主角改变他们为系统提供输入的方式，边界类就应该是唯一需要改变的对象。
- 如果系统改变为主角提供输出的方式，边界类就应该是唯一需要改变的对象。
- 边界类必须“知道”其他对象类型（例如控制对象和实体对象）的需求，以便它们能够得以实施，并相对于“系统内部元素”保持其可用性和有效性。
