Issue 1490:  Alignment with UML State Meta-model (boca-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: 
 Alignment with UML—State Meta-model
 
 Stated as only a general issue at this point:  The model for state and state transitions should be able to be 
 closer to UML.
 
 Recommendation: Close study of this issue, with input from OADTF and BOCA RTF.
 
 *ISSUE 63*

Resolution: 
Revised Text: 
Actions taken:
June 3, 1998: received issue
June 23, 1998: closed issue
Discussion: 
 Close study of this issue, with input from OADTF and BOCA RTF.
End of Annotations:=====
*ISSUE 61*

Alignment with UML--Relationships

Elements of the meta-model that do not derive from CORBA that is, that
are not constrained by the legacy 
of the IDL meta-model should be as isomorphic as possible to UML.  A
particular area of concern is that of 
relationships.

The primary UML meta-types having to do with associations are
Association, AssociationEnd, and 
AssociationClass.  An association is allowed to have 2 or more
AssociationEnds, each of which is 
associated with a Classifier, meaning binary or n-ary Associations
among Classifiers are supported.  The 
isNavigable attribute of AssociationEnd specifies whether it is
possible to discover the Association by 
iterating through the elements of a Classifier.  AssociationClass is
an Association that can have its own 
features.
 
When designing a meta-model well-geared toward linear, textual
expression, having to declare an 
Association separately from the Classifiers that are being associated
is cumbersome.  Furthermore, binary 
relationships are sufficient for the CORBA business object space and
AssociationClasses are not deemed 
necessary, at least at this time.  Moreover, Associations that have no
navigable AssociationEnds are 
probably not appropriate for business objects, for these are blind
Associations that the business objects 
cannot detect.

Recommendations:

1. Define a submeta-type of UML Association called BusinessAssociation
that constrains the number of 
AssociationEnds to 2 and that constrains the AssociationEnds such that
at least one of them is 
navigable.  This submeta-type would NOT part of BOCA but, rather,
would be an addition to the UML 
meta-model.
2. Define a BocaAssociation meta-type that is as isomorphic as
possible to UML BusinessAssociation.
3. Define a BocaAssociationEnd meta-type that is as isomorphic as
possible to UML AssociationEnd.  This 
is quite close to what BocaRelationshipReference is now and would
replace it.
4. Change the CDL keyword relationship to association.
5. CDL relationship declarations would continue to appear within the
declarations of the BocaTypes 
participating in the relationships.  The fact of a CDL declaration of
a relationship would create an 
instance of BocaAssociation and two instances of BocaAssociationEnd.
An inverse would always be 
declared, but its semantics would be simply to name the other
BocaAssociationEnd.

The inverse relationship may or may not be explicitly declared within
its enclosing type.

The Association name would be inferred from the declaration rather
than explicitly declared.

6. This approach is as illustrated by the following example:

identifiable InsurancePolicy
{
   ...
      association protects References 0..* PolicyHolder is_unique
inverse holds;
}

identifiable Customer
{
   ...
      association holds References 0..* InsurancePolicy is_unique
inverse protects;
}
      
This results in creation of a BocaAssociation meta-object with name
InsurancePolicy-Protects-Holds-
Customer that is associated with a BocaAssociationEnd named protects
and a BocaAssociationEnd 
named holds.  The aggregation attribute of the both ends is set to
NONE.  

Each BocaAssociationEnd has its isNavigable attribute set to true.
If, however, Customer were not to 
explicitly declare the relationship as well, then its end of the
relationship (holds) would have its 
isNavigable attribute set to false.

identifiable ApartmentBuilding
{
   ...
      association encloses Composes 2..* Apartment is_unique inverse
is_enclosed_by;
}

identifiable Apartment
{
   ...
      association is_enclosed_by IsOwnedBy 1 ApartmentBuilding inverse
encloses;
}

In this case the aggregation attribute of the encloses
BocaAssociationEnd is set to COMPOSITE.

7. Define submeta-types of UML AssociationEnd that correspond to the
subtypes of 
BocaRelationshipReference, such as Composes, IsOwnedBy, etc.
Alternately, change the BOCA 
meta-model to remove these subtypes and simply consider CDL specifiers
such as Composes and 
IsOwnedBy to be expressions of the setting of attributes of AssociationEnds