OSM Meta-Model


This page is currently being used to coordinate changes between two versions of the OSM meta-model. Where changes are proposed, the old diagram is shown first, then there is commentary on the proposed modifications, and then the new diagram is shown.

For more information on the formal definition of OSM, we recommend Appendix A of Object-oriented Systems Analysis: A Model-Driven Approach, D.W. Embley, B.D. Kurtz, S.N. Woodfield, Prentice-Hall, Englewood Cliffs, NJ, 1992. We have related technical reports here, especially the work done by Dr. Stephen Clyde.


This page describes the OSM Meta-Model. The Meta-Model is divided into the following sections:

This meta-model has been lexicalized and simplified in some areas. In other areas, new constructs have been added.

ORM Components

Each of the following is an ORM Component:

Object Class

We want to change the term object class to object set. We no longer have dominant and independent high-level object classes. A relational object class is a special kind of high-level object class. A constant object class is one whose membership is fixed when it is created, so the only way to change its membership is through model evolution. A constant singleton object class corresponds to our notion of an object. An object-class object is the object view of an object class (this supports our wave/particle analogy for objects and object classes). The participation constraint on object-class name has been strengthened from 1:* to 1.

Relationship Set

The participation constraint on relationship-set name has been strengthened from 1:* to 1. Also, constant relationship set and constant singleton relationship set are analogous to constant object class and constant singleton object class, described above.

Relationship Set (cont.)


Old diagram:

Here we restructure the definition of Generalization/Specialization Constraint.

New diagram:

Aggregation and Association

OBM Components

Each of the following is an OBM or State-Net Component:

The meta-model for state nets has changed significantly in several ways. First, we have added priority constraints to states and transitions that allow us to control the priority with which we fire transitions and enter states. Second, there is a single state net for an entire generalization/specialization hierarchy. Together with this, we associate membership in an object class with the idea of having a thread in a state or transition that pertains to the object class. An object O is a member of class C if and only if O has a thread that is in a state or firing a transition that pertains to C.


We have changed the notion of states being members of a state net. Instead, we say that states pertain to object classes. Perhaps we should change the current relationship set State[1:*] pertains to Object Class[0:*], since the basis State[1] pertains directly to Object Class[0:*] together with the generalization/specialization hierarchy can be used to compute the full "pertains" set.

The participation constraint on state name has been strengthened from 1:* to 1. State names are fully qualified by the name of the object class to which the state pertains. For example, if state S pertains to class C, its fully-qualified name is C.S.

Old diagram:

Here we change State pertains to Object Class to State directly pertains to Object Class. The former relationship set can be computed from the latter together with the generalizations of an object class. This change lets us omit two general constraints.

New diagram:


Like states, described above, transitions now pertain to object classes. Also, the participation constraint on transition identifier has been strengthened from 1:* to 1. Another significant change is the correspondence between initial (final) transitions and transitions with a single subsequent- (prior-) state conjunction.

Old diagram:

There are several changes here. First, we remove the relationship set Transition pertains to Object Class, and instead let that be computed from State directly pertains to Object Class. This eliminates a couple of general constraints. Two other changes are to make this segment more consistent with the rest of the meta-model. First, Transition Identifier becomes Transition Name, and the general constraint a+b+c+d = 1 to allow the same lexical State-Net Real-Time Constraint string to be applied to more than one state-net component.

New diagram:


Note that we now capture the concept of a re-entrant state in the relationship set Subsequent State does not merge thread when firing is based on Subsequent-State Conjunction. Also, the path marker associated with a conjunction is now called State-Conjunction Name, and it must be unique. Like state and transition names, state-conjunction names are fully qualified by the object-class name.

Old diagram:

There are extensive changes here -- compare for yourself.

New diagram:

OIM Components

Note the addition of two-way interactions. We could consider writing this formally as an OSM template.

Old diagram:

The primary difference here is in the treatment of the parameters and name of an interaction. Also, the participation-constraint variables have been renumbered. Corresponding changes are found in the general constraints.

New diagram:

Miscellaneous Components

Notes no longer apply to other components. They simply are part of the application model, and can be attached anywhere. Also, the OSA Component class was removed to simplify the model. This necessitates the general constraint shown here to assure mutual exclusion, but it allows us to lexicalize the meta-model more easily.

 BYU Home Page  OSM Home Page
Send questions or comments to:
Steve Liddle liddle@byu.edu