Windchill 建模启发法

本节旨在介绍有关 Windchill 类体系结构设计的背景以及在建模中使用的方法。Windchill 类体系结构旨在实现以下目标：

• 推动可反映三层体系结构特征的业务对象的开发；即，客户端层的表示、服务器层的业务逻辑以及数据库层的持续性。

• 确定生成优化代码时可基于的模型。应提供生成的代码以管理对象的状态、在客户端与服务器之间传输对象以及处理数据库中的对象。

• 提供支持增值开发的环境。必须能够扩展模型并将新功能放入现有对象中。

要实现这些目标，一种方法是继承功能。

通过继承获得的功能

将子类添加到父类时 (在这种情况下，依次使用 Item 和 DomainItem 扩展类 WTObject)，则子类将继承先前的每个类的属性和方法。此方法适用于很多情况。但有时，您只需一小部分的继承功能。在这种情况下，要么对象中的功能远远多于实际所需，要么您仅复制所需代码并将其添加到您自己的对象中，从而造成冗余和潜在的维护问题。

另一种方法 (已在 Windchill 中实现) 是将如下图所示的功能划分为主要用于维护业务信息的对象 (也称为 knower)，以及主要用于执行业务操作的对象 (也称为 doer)。

通过划分获得的功能

使用此方法时，业务模型具有两种主要类型的类：业务信息类和业务管理器类。

业务信息类表示要在数据库中管理和维护的业务信息和关联。这些类用于扩展 Windchill 中提供的基础类。它们可以实现一个或多个业务管理器接口。这些类会在客户端和服务器之间随数据往复传送。

业务管理器类表示应用于业务信息对象的业务规则。这些类用于扩展 Windchill StandardManager 类。业务管理器会实现一个接口类，用于为业务管理器方法提供客户端 API。业务管理器类的代码位于服务器中。

下面是 Windchill 提供的管理器之一 LockService 的示例。(在命名类中，管理器有时也称为服务。)

在此示例中，可锁定对象是由 MyItem (同时扩展抽象类项) 实现的 "knower"。可锁定对象 (包括 MyItem) 由 StandardLockService ("doer") 管理，其中 API 由实现的远程接口 LockService 呈现。

除了从 Item 继承的属性和方法外，MyItem 还具有在 Lockable 接口中定义的功能。

图左侧显示了如何在客户端上对服务器端服务的接口进行建模。doer 是 StandardLockService，且在服务器上运行。它继承自 Windchill StandardManager，后者为典型管理器提供标准的基本操作，例如启动和关闭。(自行编写管理器时，它们也可以继承自 StandardManager。)

LockService 接口用于描述客户端上提供的锁定服务，即锁定和解锁。这些服务将从客户端远程调用到服务器。服务器上的 StandardLockService 实际上包含支持锁定和解锁方法的所有代码。

LockService 的 API 需要一个可锁定对象。它们可以接受 MyItem，因为 MyItem 已实现 Lockable 接口。同样，它们也可以接受实现 Lockable 接口的任何其他业务信息类。要获得对锁定服务功能的访问权限，必须针对类实现 Lockable 接口。