| Previous | Table of Contents | Next |
While the MOF specification gives the required computational semantics for M1-level metadata, it does not (and should not)
state that these semantics constitute the only behavior. It is envisaged that vendor and end-user implementations of metadata
servers may support additional semantics. In addition, the computational semantics of M2-level derived Attributes, derived
Associations and Operations are not specified at all in the standardized part of the MOF Model.
In theory, the complete computational semantics of a meta-model server can include any behavior that the implementor chooses.
The purpose of the sub clause is to set down some conventions to guide the implementor.
Many operations on Instance and Associations are provided to support access to the public state of a model; e.g. the “get?
operations for Attributes, the “query? operations for Associations. For normal (non-derived) Attributes and Associations,
the standard computational semantics of an access operation are to simply return the corresponding value or collection. For
derived Attributes and Associations, there are no standard semantics at all.
In general, it is bad style for an access operation to have observable side-effects on the primary metadata.
Similarly, it is bad style for an Operation with “isQuery? true to have such side-effects.
The rationale for this rule is that the user would not expect an access operation to have visible side-effects.
NOTE: It may be reasonable (for example) for an Attribute “get? operation to update a private counter Attribute that records
the number of accesses. The legitimacy of this kind of behavior depends on whether or not the state modified can be classified
as “primary? metadata.
The standard semantics of metadata update operations define which metadata is expected to be modified by the operation. However,
there is no explicit requirement that other metadata should not be changed.
It is bad style for an update operation for a non-derived Attribute, Reference, or Association to change any
primary metadata other than that which is identified by the standard semantics.
The rationale for this rule is that the user would not expect such changes to occur.
NOTE: This rule is not intended to apply to operations for derived Attributes, References or Associations, or to Operations
with “isQuery? false.
M2-level Attributes and Associations can be defined as being derived from other information in a meta-model (i.e., by setting
the respective “isDerived? flag to true). The required M1-level behavior of derived Elements is identical to that for equivalent
non-derived Elements. Behavior that contradicts the semantics in this clause and in the relevant mapping specification is
non-conformant.
However, since derived Attributes and Associations have to be implemented using mechanisms that are beyond the scope of the
MOF Model, conformance is ultimately the responsibility of the meta-model implementor.
It is recommended that implementor defined M1-level operations for derived Elements should have MOF conformant behavior. The
alternative (non-conformant behavior) tends to break the illusion that the Attribute or Association is “real,? and should
be avoided. If the required semantics are unimplementable, the meta-model is incorrect.
The MOF specification does not define how Constraints defined in a meta-model should be evaluated. In particular, it does
not define whether Constraint evaluation can change the metadata.
It is bad style for the evaluation of a Constraint to change metadata.
The rationale is two fold. First, Constraints are provided as mechanism for specifying metadata correctness, not as a mechanism
for defining behavior. Second, since the MOF specification does not say when Constraint evaluation should occur (in all cases),
side-effects in Constraint evaluation could be a major source of interoperability problems.
The MOF specification does not define when deferred Constraint evaluation should occur. In theory, it can occur at any time,
including when the user invokes an access operation.
It is bad style for an access operation on a non-derived Attribute, Reference, or Association to raise an exception to indicate that the metadata is structurally inconsistent or that a Constraint has been violated.
The rationale is that an application program that is reading metadata (rather than updating it) is typically not in a position
to do anything about the violation of deferred structural constraints or model specific Constraint. Alternatively, an application
may try to access the metadata, knowing that it is inconsistent, so that it can then correct it.
It is bad style for an access operation on a derived Attribute, Reference, or Association to raise a similar exception unless
the inconsistency makes it impossible to calculate the required derived value(s). The same rule applies to Operations with
“isQuery? true.
The rationale being less prescriptive about derived access operations is that the formulae used to derive the value(s) will
typically have certain assumptions about the consistency of the metadata.