This section is intended to give you some background on the design of the Windchill class architecture and the approach we have used in modeling. The Windchill class architecture was designed with the following objectives in mind:

One approach to achieving these objectives is to inherit functionality.

Functionality through Inheritance

As you add subclasses to a parent class, in this case extending class WTObject with Item and then DomainItem, the attributes and methods of each preceding class are inherited by the subclasses. This approach works in many circumstances. But sometimes you need only a small percentage of the functionality that is being inherited. In that case, either you have much more than you actually need in your object, or you copy just the code you want and add it to your own object, creating redundancy and potential maintenance problems.

Another approach, which we have implemented in Windchill , is to partition functionality, as in the figure below, into objects that are responsible primarily for maintaining business information (also called knowers) versus objects responsible primarily for performing business operations (also called doers).

Functionality through Partitioning

Using this approach, business models have two major kinds of classes: business information classes and business manager classes.

Business information classes represent the business information and associations you want to manage and maintain in a database. These classes extend the foundation classes provided in Windchill. They may implement one or more business manager interfaces. These classes go back and forth between the client and the server with data.

Business manager classes represent the business rules that are applied to the business information objects. These classes extend the Windchill StandardManager class. Business managers implement an interface class that provides a client-side API to the business manager methods. The code for business manager classes is located in the server.

The following is an example of one of the managers Windchill provides, the LockService. (In naming classes, managers are sometimes also called services.)

LockService Example

In this example, Lockable is a “knower” that is implemented by MyItem (which also extends the abstract class Item). Lockable objects, including MyItem, are managed by the StandardLockService (a “doer”), with APIs exposed by the implememnted remote interface LockService.

Besides the attributes and methods it inherited from Item, MyItem also has the functionality defined in the Lockable interface.

The left side of the figure shows how to model the interface for a server-side service on a client. The doer is StandardLockService and it runs on the server. It inherits from the Windchill StandardManager, which provides standard, basic operations for a typical manager, such as starting and shutting down. (When you write your own managers, they also can inherit from StandardManager.).

The LockService interface describes the lock services that are available on the client, lock and unlock. These services are invoked remotely from the client to the server. StandardLockService on the server actually contains all the code to support the lock and unlock methods.

LockService’s APIs expect a Lockable object. They can accept MyItem because MyItem implemented the Lockable interface. Likewise, they can accept any other business information class that implements the Lockable interface. To get access to the lock service functionality, a class must implement the Lockable interface.