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.
Each of the following is an ORM Component:
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.
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.
Here we restructure the definition of
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 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.
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.
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.
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
and the general constraint
a+b+c+d = 1 to allow the same
State-Net Real-Time Constraint string to be applied
to more than one state-net component.
Note that we now capture the concept of a re-entrant state in the
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.
There are extensive changes here -- compare for yourself.
Note the addition of two-way interactions. We could consider writing this formally as an OSM template.
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.
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.