Issue 1440:  Section 2.2.4: CorbaOperation should not derive from NameSpace (boca-rtf)
Source:  (, )
Nature:  Revision
Severity: 
Summary: Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaOperation:BehavioralFeature, 
    TypedNamedElement,CorbaInterfaceFeature,NameSpace{
         attribute NameList contexts;
         attribute boolean is_oneway;
         relationship may_raise 0..* CorbaException inverse can_be_raised;
         relationship arguments Many is_ordered CorbaArgument inverse operation;
 };
 
 It is noted that CorbaOperation derives from NameSpace.  NameSpace was introduced into the meta-model 
 in order to align with UML.  Note that in the MOF, Operation indirectly derives from Namespace but that that 
 is not the case in UML.  Since BOCA and UML are at the same meta-level, proper alignment with UML 
 requires making the BOCA meta-model as similar as possible to the UML analysis meta-model, as long as 
 derivation from CORBA is not compromised.  However, alignment with the MOF is quite another matter, 
 since BOCA is a meta-level above the MOF.  Alignment with the MOF simply requires that the MOF model is 
 used to describe BOCA, not that the models be isomorphic.
 
 Therefore, in cases such as this where the MOF and UML models are dissimilar, the UML approach should 
 win out over the MOF approach.
 
 Recommendation:  Unless there is a compelling technical reason for BOCA to diverge from the UML 
 approach in this case, CorbaOperation should not derive from NameSpace.
 

Resolution: 
Revised Text: BehavioralFeature, 
Actions taken:
June 3, 1998: received issue
June 23, 1998: closed issue
Discussion: 

End of Annotations:=====
*ISSUE 12*

Section 2.2.4 (BOCA Meta-Model in CDL)

identifiable CorbaInterface:CorbaStructuredType, FeatureOwner{
        relationship subtype 0..* CorbaInterface inverse supertype;
        relationship supertype 0..* is_ordered CorbaInterface inverse
subtype;
};

is_ordered is not defined in the CDL grammar for relationship
declarations, although it is clear that it 
corresponds to the MultiplicityKind attribute of the same name.
Furthermore, nothing is defined in the 
grammar to correspond to the is_unique attribute of MultiplicityKind.

The syntax suggested by this example for specifying ordering and
uniqueness characteristics of 
relationships is awkward.  Consider a CDL declaration with no ordering
and uniqueness characteristics and 
which specifies the relationship_kind and multiplicity; for example:

relationship supertype references 0..* CorbaInterface inverse subtype;

This declaration is quite readable with a fairly natural language
progression from subject to verb.  The 
addition of inverse subtype isn't grammatical from an English language
standpoint, but the fact that it is 
appended to the end of the statement makes it less disruptive than it
otherwise would be and it is fairly 
intuitive that a statement about the inverse of the relationship would
appear at the end of the statement.

Now, considering how to qualify this statement with is_ordered and
is_unique , it would appear that the 
following would be the way to do it that best preserves the
statement's readability:

relationship supertype references 0..* CorbaInterface is_ordered
is_unique inverse subtype;

Recommendation:  Adopt this latter form, making the is_ordered and
is_unique specifiers optional.  
Omission of the is_ordered specifier should indicate that there is no
ordering requirement and omission of 
the is_unique specifier should indicate that there is no uniqueness requirement