MOF14 — Association Generalization Proposal

Here is a detailed proposal for adding association generalization to MOF
1.5. This proposal does not address reference redefinition or overriding.
I hope this proposal provides sufficient detail so that Steve Crawley can
make changes to the specification. Please send your comments.

Regards,
Don

Changes to Model

Remove constraints [C-34] AssociationsHaveNoSupertypes, [C-35]
AssociationMustBeRootAndLeaf, and [C-36] AssociationsCannotBeAbstract.

Add a nonabstract association from AssociationEnd to AssociationEnd called
RedefinesEnd. One end is called redefinedEnd, has a reference by the same
name, and has multiplicity *. The other end is called redefiningEnd, has no
reference, and has multiplicity *. This association is used to correlate an
end with its corresponding end in a supertype association.

Add new constraint: SupertypeEndsAreRedefined
Evaluation policy: Deferred.
Description: An end redefines each supertype's end.
Context Association
Inv: self.supertypes.contents->select(gc | gc.oclIsTypeOf(AssociationEnd))->
forAll(ge : AssociationEnd |
self.contents->select(sc |
sc.oclIsTypeOf(AssociationEnd))->
forAll(se : AssociationEnd | se.redefinedEnd->exists(re | re =
ge)
and se.otherEnd.redefinedEnd->exists(ore | ore =
ge.otherEnd)))

Add new constraint: RedefinedEndBelongsToSupertype
Evaluation policy: Immediate.
Description: Each redefinedEnd belongs to a supertype.
Context AssociationEnd
Inv: self.container.oclAsType(Association).supertypes.contents->
includesAll(self.redefinedEnd)

By the way, I noticed a bug. [C-38] AssociationsMustBeBinary is an
immediate constraint, but it should be deferred. Otherwise, there is no
valid way to create an Association.

Changes to Abstract Mapping

Add the following to Core Association Semantics.

A link cannot be directly created for an Association with isAbstract set to
true, but can be added indirectly as a link of a subtype association.

Where a generalization exists between two associations, each link of the
subtype association is logically a link of the supertype association - for
each subtype Link <a, b> there implicitly exists a supertype Link <a, b> (or
<b, a> depending on which subtype end redefines which supertype end).

Removing a link from a Link_Set causes the logical link to be removed from
each subtype association's Link_Set. Removing a link from a Link_Set also
causes the logical link to be removed from each supertype association's
Link_Set where the logical link is not otherwise present in the supertype
Link_Set based on either having been put explicitly into the supertype
Link_Set (where not abstract) or on being a link of some other subtype of
the supertype. The net effect is that a Link_Set is a union of links put
explicitly into the Link_Set with the Link_Sets of all subtypes.

Changes to IDL Mapping

In the template for associations, no add or modify operations are generated
for an abstract association.

In the template for references, no set, add, or modify operations are
generated for an abstract association.

Operations on RefObject for setting, adding, and modifying, and operations
on RefAssociation for adding and modifying raise a new MofError, "Abstract
Association", for creating a link of an abstract association.

Changes to JMI

In the template for associations, no add operation is generated for an
abstract association.

In the template for references, no set operation is generated for an
abstract association. Also, the add and set operations on a reference
collection throws a new JmiException, "AbstractAssociation", for an abstract
association.

For the reflective JMI interfaces, JmiException "AbstractAssociation" is
thrown for refAddLink on an abstract association and for refSetValue on a
reference on an abstract association.