Previous Topic: EncapsulationNext Topic: Attributes


Encapsulation Options

There are three types of encapsulation from which to choose:

The encapsulation option you select affects:

Open Encapsulation

The entity type is not encapsulated. Use this form of encapsulation for detailing (also known as "dependent" or "characteristic entity types") entity types in object models where the project has decided to encapsulate business object types rather than individual entity types.

Restricted Encapsulation

Some of the restrictions inherent in full encapsulation are applied. Updates must be handled by an entity type's own operations, while any action diagram may perform a read. The features of the entity type can be protected. This choice is not pure encapsulation. It cannot bring all the benefits. It does not bring all the costs.

The restricted option confines the maintenance of an entity type to a few operations, improving the integrity of the type, the modularization of logic and the organization of developer responsibilities.

The features of restricted entity types may be protected. Protected features are only visible within the operations of the entity type owning the feature. By default, all basic and designed attributes of a restricted entity type are protected, unless the attribute is a part of the primary identifier of the type.

Transient Entity Types

A transient entity type is one whose occurrences are not physically stored. Entity types that are implemented by a corresponding relational database table are termed persistent. Transient types have no corresponding relational database table.

While there may be a simple one-to-one correspondence between a transient entity type and a persistent entity type, other mappings may prove useful. For example the data of several different transient types can be stored in one table corresponding to one persistent type. Or a transient type may gather together the data stored in several tables.

Since transient types do not represent persistent storage, there is no need for a set of transient types to be normalized.

Transient views (this term covers transient import, transient export and local views) may be defined for transient entity types. Persistent views (this term covers entity action, persistent import and persistent export views) may not. By way of contrast, persistent entity types may have both persistent and transient views.

Business Object Types

A business object type is an entity type that:

When an entity type is given a transaction operation (that is, a procedure step is registered as an operation of the entity type) that entity type is automatically marked as a business object type.

When building an object/data model in a top-down fashion, mark the main entity types as business object types, since these are the entity types we expect to offer transaction operations.

No Occurrence Entity Types

A No Occurrence Entity Type is an entity type that owns operations, attributes, and relationships, but which has no set of occurrences. The entity type represents an object. One may think of this as an entity type with no instances, or a single instance that does not belong to any type.

The entity type must be transient. All its operations must be type operations.

Use No Occurrence Entity Types to represent in models any package of functionality that does not correspond to a type of thing, but which correspond to a single thing. Examples are, the functions of an existing system or the functions of a transient type that supports utility operations (that reformat dates for example) or the functions of a type that has a single occurrence, where there is little or no chance there will ever be multiple occurrences; such as The Company, Head Office, or The Government.

Where there is a single occurrence at the moment, but further occurrences may occur in the future, then it is preferable to record the entity type as multiple occurrence, and enter this minimum, maximum, and average occurrences as one.

By way of contrast, most entity types will represent types of things, for example Customer, Employee, Property for which multiple occurrences (instances) will exist at runtime. Operations will usually be focused on single occurrences of the type (instance operations).