为指定为此任务输入的分析类创建一个或多个初始设计类,并指定跟踪依赖关系。本步骤中创建的设计类将在后续步骤中得到优化、调整、拆分或合并;在后续的步骤中将指定各种描述分析类如何设计的设计属性 - 如操作、方法和状态机。
根据设计的分析类的类型(边界、实体或控制),您可以使用特定的策略创建初始设计类。
边界类代表到用户或其他系统的接口。
一般情况下,代表到其他系统的接口的边界类被建模为子系统,因为它们往往有复杂的内部行为。如果接口行为很简单(也许只是充当到外部系统的现有 API 的传递),那么您可能会选择用一个或多个设计类代表接口。如果您选择这种方式,请对每个协议、接口或
API 使用单个的设计类,并记录关于您在类的特别需求中使用的标准的特别需求。
代表到用户的接口的边界类一般遵循用户界面中的每个窗口对应一个边界类或每种形式对应一个边界类的规则。结果,边界类的职责就可能处于一个相当高的级别,并需要在本步骤中进行优化和详细说明。用户界面的其他模型或原型可能是本步骤中要考虑的另一个输入来源。
边界类的设计取决于项目可用的用户界面(UI)开发工具。使用当前的技术,在开发工具中直接直观地构造 UI 是很常见的。这将自动创建需要与控制和实体类的设计相关的 UI 类。如果 UI 开发环境自动创建实施 UI
所需的支持类,那么就没有必要在设计中考虑这些支持类了。您只设计开发环境没有为您创建的内容。
在分析期间,实体类代表被操纵的信息单元。 它们往往是被动的、持久的,并且可能被确定并与持久性分析机制相关联。关于设计基于数据库的持久性机制的详细信息包含在任务:数据库设计中。性能考虑事项可能会迫使持久类的一定重构,从而造成在角色:数据库设计人员和角色:设计人员之间联合讨论的“设计模型”的更改。
有关持久类的设计问题的更广泛的讨论展示在后面题为确定持久类的部分中。
控制对象负责管理用例的流动并因此协调其大多数操作;控制对象封装的逻辑不是特别与用户界面问题(边界对象)或数据工程问题(实体对象)相关。这种逻辑有时称为应用逻辑或业务逻辑。
在设计控制类时请考虑下列问题:
-
复杂性 - 您可以用边界类或实体类处理不复杂的控制或协调行为。然而,随着应用变得越来越复杂,该方法的重大缺点也逐渐显露出来,例如:
-
用例协调行为嵌入到了 UI 中,这使更改系统变得更加困难
-
相同的 UI 不能简单地在不同的用例实现中使用
-
UI 因为增加了功能而增加负担,结果降低了性能
-
实体对象可能因为用例特定的行为而增加负担,结果降低了其泛化程度
为了避免这些问题的发生,就引进了控制类来提供与协调事件流相关的行为。
-
更改可能性 - 如果更改事件流的可能性很低或者成本可以忽略不计,那么其他控制类的额外开支和复杂性就可能没有正当的支持理由。
-
分发和性能 - 在不同节点上或在不同流程空间中运行部分应用程序的需要产生了将设计模型元素专门化的需要。这种专门化往往通过添加控制对象并将来自边界和实体类的行为分发到控制类来完成。在执行这一操作期间,边界类朝着提供纯
UI 服务移动,实体类朝着提供纯数据服务移动,而控制类则提供剩余部分。
-
事务管理 - 管理事务是典型的协调活动。因为缺乏处理事务管理的框架,需要一个或多个事务管理器类进行交互,以确保您能保持事务的完整性。
在后两种情况下,如果控制类代表独立的控制线程,那么使用活动类来对控制线程建模可能会更加适合。在实时系统中,使用工作产品:封装体是较为合适的建模方法。
|