POSC Specifications Version 3.0 |
Epicentre Modeling Methodology |
The Epicentre meta model is specified by the EXPRESS language specification document for definition. The main concepts used are:
In order to provide a better match to the available implementation technology, the following EXPRESS syntax is not allowed in a conformant data model.
The following EXPRESS syntax is supported in modified form:
Entities conform to the EXPRESS definition and are specified by:
Entities have two forms of identification, identification of the instance record (primary) and identification of the real world thing being represented (secondary).
The instance identifier is assumed to be some machine generated code, entirely dependent on the system that is creating and administering the instances. The value of the instance identifier needs to be unique within a data store (here, data store means a systematically managed set of instances). Other than this, the content of the instance identifier has no significance. Epicentre does not specify any particular representation for instance identifiers and they are omitted from the entity specifications.
Some entity characteristics may correspond to information commonly used by people to distinguish one real world thing from another. Where characteristics are used in this way the methodology allows them to be designated as secondary identifiers. A secondary identifier consists of one or more attributes. The attribute components may be optional or mandatory and may be inherited from any supertype. Attributes of aggregate base type cannot be part of a secondary identifier.
The term secondary identifier is used because it is assumed that the instance identifier will define the primary identifier.
Secondary identifiers are declared using the uniqueness rule clause with a specific rule name of `si'. An entity may only have one (either direct or inherited) secondary identifier. Secondary identifiers should be defined at or above the first non-abstract entity.
Attribute declarations are used to specify the characteristics of an entity. Attributes consist of a name, a description and a data type. The data type may be an entity type, forming a relationship, or it may be a named simple or Epicentre data type.
An attribute may be optional or mandatory and may be aggregate or non aggregate in nature. Four aggregate types are available for use: BAG, SET, LIST, ARRAY. List and array types give significance to the position of a value within the aggregate.
An entity may be a subtype of one or more supertype entities and will inherit the attributes, where rules, and uniqueness rules of all of its supertypes. A supertype specification is a means of defining characteristic types common to all its subtypes.
A supertype may have many subtypes and a variety of EXPRESS specifications constrain how a supertype may be specialized when it is instantiated.
A supertype may be abstract, meaning all instances must be specialized, or nonabstract, meaning an instance may be specialized or unspecialized. Both abstract and nonabstract supertypes are allowed in Epicentre.
In EXPRESS, the specialization of a supertype is constrained by using a combination of oneof, and, and andor operators operating on its subtypes. This methodology only allows the oneof constraint. This restricts an instance to have, at most, the characteristics of one of its subtypes.
Inheritance of supertype characteristics is transitive. A supertype also may be a subtype and inherit the characteristics of its supertypes, which are inherited in turn by its subtypes.
Inherited characteristics may be specialized at the inheriting subtype. Here, specialized means the specification of the characteristic shall be more constrained in the subtype than in the original declaration of the supertype. Specialization is defined by redeclaring the supertype attribute in the subtype with the new base type that is a specialization of the original base type. The name of the attribute must, however, remain the same.
Specializations can also be used to redefine the aggregate type of a base type so that bags can be specialized to be sets, sets to lists, etc. Also entity base types can be redeclared to use any subtype of the original base type entity.
In EXPRESS, the concept of a relationship is carried by two attributes where the attributes are defined with a base type of the related entity or of an aggregate type of the related entity. Defining relationships with two attributes gives the ability to see the relationship from both entities involved in the relationship (both "what am I related to" as well as "what is related to me"). EXPRESS also gives significance to the relationship's "direction," requiring that attributes with entity base types are either explicit or inverse. This distinction is important because an inverse attribute can be created only as a consequence of creating its corresponding explicit attribute.
In addition to the EXPRESS data types, a suite of Epicentre data types has been defined using the EXPRESS meta type extension. Note that these are called Epicentre data types because they were specifically designed for use by Epicentre. They are not limited to use in an Epicentre data model nor is there a requirement that an Epicentre data model use all of them. The data types which are allowed in a conformant data model are summarized in the Summary of Data Types Appendix.
Most of these new types are analogous to the EXPRESS simple types. For example, the simple type STRING implies a behavior of an ordered list of characters, where the parameters associated with a STRING declaration can be used to declare additional restrictions on the list of characters. There is no implication of how these characters are represented, only the idea that you can find out what the characters are and their order. The type has a declaration syntax that includes the maximum width parameter and variable or fixed condition.
Similarly, each Epicentre data type has a defined behavior, usually some specification parameters that constrain the instances of the data type, and a declaration syntax.
A named Defined Data Type is a use of an underlying data type that is given a particular name. Use of a named defined type is similar to use of attribute domains in conventional methodologies. Conforming data models should use a named Defined Data Type rather than directly specifying the underlying type as the type of an attribute. This makes the model more understandable and facilitates maintenance. The use of an "ndt_" (for Named Defined Type) prefix for the name of the Defined Type will eliminate confusion with entity types.
In order to support the Epicentre data types, certain semantics must exist in a conformant data model. The required semantics includes the following concepts:
A conforming model that uses Epicentre Data Types must conform to the requirements of those data types.
Domain rules are handled in EXPRESS by the use of where clauses on entities. Where rules define further constraints on instance values. Any rule construct allowed by the EXPRESS language may be defined. However, three general types of where rules are commonly expected.
Select rules constrain the instantiation of a set of attributes of an entity. A Mandatory Select rule requires one and only one of the specified attributes is instantiated (i.e. not null) for an instance of the parent entity. An Optional Select rule is satisfied by a null result, where none or one of the member attributes may be instantiated.
Related instance rules constrain the instantiation of attributes that involve the same source entity and the same related (target) entity. Two types of this rule have been identified: Same Related Instance forces instances to be the same; Different Related Instance forces instances to be different. Thus, if two relationship paths are followed from the same source instance then the instances at the end of each path must either be the same instance or two different instances.
Value rules have no predetermined semantics or descriptions (i.e., they represent all other rules). Their scope is limited to the scope of EXPRESS domain rules.