Issues for BOCA RTF-(defunct list)

List of issues (green=resolved, yellow=pending Board vote, red=unresolved)

List options: All ; Open Issues only; or Closed Issues only

Issue 1166: CDL case Studies--examples missiin
Issue 1169: Non-normative MODL issue
Issue 1170: "Type Definition"/CDL Inconsistency
Issue 1239: IDL/file structure mapping
Issue 1240: bom/98-02-17 B
Issue 1243: OBV/top of type hierarchy should be abstract
Issue 1244: OBV/inheritance restriction clarification
Issue 1246: CDL syntax for GeneralModel
Issue 1247: CDL syntax for CorbaModel
Issue 1249: CDL for BOCAModel
Issue 1291: Do not generate TypeManager for DependentObjects
Issue 1304: Keyword for BocaSignal as "event", should be "signal"
Issue 1413: Syntax for triggers and expressions traversing many relationships
Issue 1414: BocaCommand keyword incorrect
Issue 1415: Typographical error-BocaBusinessProcess defined twice
Issue 1429: Lack of support of UML isRoot
Issue 1430: Lack of support for UML concurrency specifier on BocaOperation
Issue 1431: Section 2.2.4: Boca Meta-Model in CDL
Issue 1432: Section 2.2.4: The attribute has_feature is inappropriate
Issue 1433: Section 2.2.4: Change IspartOf to IsOwnedBy
Issue 1434: Section 2.2.4: Change grammar for relationship declarations
Issue 1435: Section 2.2.4: CorbaStructuredType is declared twice
Issue 1436: Section 2.2.4: In exception_element relationship change Many to Composes
Issue 1437: Section 2.2.4: can_be_raised should be modified
Issue 1438: Section 2.2.4: CorbaInterface should derive only from CorbaStructuredType
Issue 1439: Section 2.2.4: Change CDL grammar for relationship declarations
Issue 1440: Section 2.2.4: CorbaOperation should not derive from NameSpace
Issue 1442: Change CDL declaration or UML diagram
Issue 1443: CDL declaration should specify Composes rather than Many
Issue 1444: CDL declaration should specify IsOwnedBy rather than IsPartOf
Issue 1445: CDL declaration of is_in should specify IsOwnedBy rather than IsPartOf
Issue 1446: CorbaUnion should redefine the has_feature relationship
Issue 1447: The defined_in relationship should be removed
Issue 1448: Re-define AggregationKind
Issue 1449: In CDL declaration of relationship change IsPartOf to IsOwnedBy
Issue 1450: BocaFeature should redefine the defines relationship
Issue 1451: Change CDL declaration of relationship redefined_by
Issue 1452: Why is inherit_specification attribute declared here?
Issue 1453: identifiable BocaStateSet: BocaStructuralFeature
Issue 1455: Declare these attributes as [MANAGER, is_locked, is_read_only]
Issue 1458: BocarelationshipReference issue
Issue 1459: inverse_type for References should be References
Issue 1460: relationship_kind declaration issue
Issue 1462: relationship_kind declaration issue (02)
Issue 1463: relationship_kind declarations issue (03)
Issue 1464: Change applied_ppliance to applied_appliance --editorial
Issue 1465: The keyword "event" is incorrect
Issue 1466: The keyword "process" is incorrect
Issue 1467: Remove (re)declaration of pass_by_value from BocaCommand
Issue 1468: Declaration of the pass_by_value attribute is redundant
Issue 1469: Clarify purpose of this declaration
Issue 1470: This forward reference is not necessary, remove it
Issue 1471: Keyword appliance_kind for BocaApplianceKind
Issue 1472: Declare MultiplicityKind as a dependent
Issue 1473: Names of these meta types are confusing
Issue 1474: name_space relationship redundant if TypedElement is subtype of NamedEleme
Issue 1476: Constraint not appearing in CDL declaration
Issue 1477: Constraint should formally appear in CDL declaration of this meta-type
Issue 1480: Inverses not reflected in CDL
Issue 1482: Information in CDL declaration of metamodel not reflected
Issue 1483: Section 2.2.2.1, UML diagram for Core Model
Issue 1485: Section 2.2.2.3, UML diagram for Structural Features
Issue 1487: Section 2.2.2.4, UML diagram for Domain Meta-Types
Issue 1488: Section 2.2.2.5, UML diagram for Appliances
Issue 1489: Section 2.2.2.7, UML diagram for Expressions
Issue 1490: Alignment with UML State Meta-model
Issue 1492: Alignment with UML Constraints
Issue 1493: Alignment with UML General
Issue 1494: Deriving from the legacy CORBA IDL meta-model
Issue 1495: Insufficient constraints in the meta-model
Issue 1611: Relationship of "Abstract Framework" to BOCA specification

Issue 1166: CDL case Studies--examples missiin (boca-rtf)

Summary: Table of Contents identifies Section 7 as Appendix 3 - CDL Case Studies and Examples, but the text does not include these examples.   Furthermore, Section 8 in the Table of Contents becomes Section 7 in the text.
 

 closed issue

Summary: Section 7.1, pages 225-234 include a representation of the Boca model
 expressed in MODL.   MODL is a non-normative, proprietary language which
 has some limitations with respect to proper representation and
 transformation of BOCA meta model semantics into MOF compliant IDL.  As
 explained in the preamble of the Appendix 3, MOF has no normative form
 of expression.   As referenced in the MODL text, there are a number of
 MOF/MODL representational problems.   There are errors due to the manual
 process of going from CDL to UML to MODL to MOF.  Somewhere in these
 manual transformations, there appeared added operations (e.g.,
 GeneralModel::NameSpace::lookup),   added assertions (e.g.,
 GeneralModel::NamedElement::NameSyntax), added exceptions (e.g.,
 GeneralModel::NameSpace::Element_Not_Found),  lost references ("blind"
 associations in their place), etc.   As a consequence, the MODL does not
 reflect the BOCA meta model.
 

Summary: BOCA
 The CDL contained within the "Type Definition" paragraphs throughout
 section 2.3 (Component Definition Language Specification) are not always
 consistent with the CDL listed in section 2.2.4, pages 73-81.   
 

Summary: BOCA
 The relationship between generated IDL and file structure is not defined
 by the BOCA specification.   There could be several workable
 implementation-specific approaches to file structure, but without
 consistent file structure patterns the resultant idl would not be
 interoperable between different idl generator mechanisms.    MOF IDL
 generation faces a similar situation, as documented in Mof-rtf issue
 957.  Also, work by Dan Frantz on the IDL Style Guide addresses some of
 the same issues. 
 
 Recommendation:
 Work with Dan Frantz and mof-rtf to establish a consistent IDL/file
 structure mapping across BOCA, MOF, and the IDL Style Guide.
 

Summary: BOCA
 The BOCA errata  document dated April 1, 1998 was intended to be an
 extension of the BOCA 1.1 Errata document bom/98-02-17, with revisions
 made in response to requests by the AB, and others, in the few days
 prior to April 1.    Unfortunately, there was a transcription error and
 some of the items contained in bom/98-02-17 were not included in the
 final errata.     Most of these items are typographical errors,
 inconsistencies, redundancies, or alignment considerations with the BOCA
 Interoperability Framework.    Those items which are in these categories
 follow, and I assume are not controversial.   There were a few items
 which may materially impact the specification - these will be
 re-introduced as separate issues. 
 

Summary: BOCA
 The OMG Objects By Value, document orbos/98-01-18,  defines abstract
 interfaces and indicates how they should be applied to a Busieess Object
 Framework.  Page 8-107, Section 8.10.1, includes the text:
 
 "A base type is a type that appears at the top of a hierarchy that
 includes both regular interface and value types.   For example, it could
 be the root type of a business object framework that includes both
 regular interface types and value types..."
 
 This requires that the common supertype of regular interfaces (e.g.,
 BocaIdentifiable) and  pass-by-value (e.g., most subtypes of
 BocaUnidentifiable) must be abstract.
 
 This issue was addressed in the BOCA errata document bom/98-02-17, but
 was inadvertently lost in the transcription to the final errata
 document.
 

Summary: The OMG Objects By Value, document orbos/98-01-18,  defines restrictions
 on inheritance relationships starting on page 5-26, section 5.3.2.1.
 This section of the Object By Value document includes a summarization
 table for allowable inheritance relationships.   (This specifies that an
 interface may inherit from multiple interfaces, no abstract values, and
 no stateful values.  An abstract value may support multiple interfaces
 and abstract values.  A stateful value may support multiple interfaces
 and abstract values, inherit from a single stateful value.)
 
 The BOCA document, page 90, defines constraints on specification
 inheritance, including that "a type can inherit from other types and/or
 idl interfaces".   This statement, and the other contraints, may not
 adequately reflect the semantic constraints added by the Objects By
 Value specification.
 
 This issue was addressed in the BOCA errata document bom/98-02-17, but
 was inadvertently lost in the transcription to the final errata
 document.
 
 

Summary: BOCA
 There are a some syntactic inconsistencies in the BOCA "GeneralModel"
 Meta-Model CDL  starting on page 73.   These are primarily typographical
 errors.
 
 *	in identifiable NamedTypedElement:
 	*	inconsistent with UML model showing name
 "TypedNamedElement"
 *	in identifiable StructuralFeature:
 	*	inheritance inconsistent with UML model showing name
 "TypedNamedElement"
 *	in "identifiable Classifier"
 	*	two usages of feature name "used_by"
 	*	misspelling of "TypedElement"
 *	in "identifiable NameSpace"
 	*	two usages of feature name "named_element"
 *	in "identifiable FeatureOwner"
 	*	syntax of <multiplicity_kind> is invalid
 

Summary: BOCA
 There are a some syntactic inconsistencies in the BOCA "CorbaModel"
 Meta-Model CDL  starting on page 74.   Most of these are typographical
 errors, some are due to constraints on use of identifiable types as
 attributes.
 

 Accept recommendatio. Issue closed

Summary: BOCA
 The CDL  for the BocaModel, beginning page 76, has some inconsistencies.
 

 received issue

Summary: Since DependentObject types will be instantiated locally and are not the
 direct subjects of queries there is no need for them to have type 
 managers.  Consequently, type manager interfaces should not be generated
 for these types.  This is consistent with the Interoperability
 Specification proposal.
 
 

Summary: keyword for BocaSignal as "event".  The correct keyword should be
 > "signal. 
 > 
 >         identifiable BocaSignal: BocaOperation{
 >           {is_readonly=TRUE;
 >           keyword="event";  <--------- should be keyword "signal"
 >           };
 >         };
 

Summary: It is the intent of "triggers" that they can traverse relations, these
 > relations may be "many" or "one" associations.  This is provided for
 > in
 > the Meta-Model by setting the "collection_content" parameter of the
 > "Traversal" node of an expressions, setting collection_content implies
 > a
 > single-value projection of the contents of the relation.  In other
 > cases
 > it is required to access a framework method of the collection returned
 > by the traversal (such as count, sum or average).  It is not clear in
 > the specification how this distinction is made in CDL syntax.  All of
 > the examples of both kinds of traversal use a dot ".".
 

Summary: Incorrect keyword in CDL specification of BocaCommand, should be
 > "command", not "dependant" (page 79).
 > identifiable BocaCommand: BocaDependent{
 >     [is_locked] attribute boolean pass_by_value=TRUE;
 >     [MANAGER, readonly, is_locked] attribute BocaType
 > base_type=BaseDependent;
 >     [MANAGER, readonly, is_locked] attribute string
 > keyword="dependent"; <-------------- should be "command"
 > }; /* DependentType */ <-------------- should be "/* CommandType */"
 

Summary: he following cdl declaration is repeated (typographical error) on
 > page 78
 > identifiable BocaBusinessProcess: BocaBusinessObject {
 >     [MANAGER, readonly, is_locked] attribute BocaType
 > base_type=BaseProcess;
 >     [MANAGER, readonly, is_locked] attribute string keyword="process";
 > }; /* processDef */
 >      
 

Summary: Section 6.1.2.1
 
 Lack of support for UML isRoot
 
 Recommendation:  Should be added as an attribute of BocaType

Summary: Section 6.1.2.1
 
 Lack of support for UML concurrency specifier on BocaOperation
 
 Recommendation: Should be added as an attribute of BocaOperation
 

 Not technically persuasive. issue rejected

Summary: Analysis: TypedElement derives from NamedElement, yet TypedNamedElement derives from both 
 TypedElement and from NamedElement.  It is not clear what the intent is here.  The corresponding UML 
 diagram (section 5.1) is ambiguous--it is hard to tell whether TypedElement derives from NamedElement or 
 ModelElement.  If the intent is for TypedElement to derive from NamedElement, then there would appear to 
 be no purpose for TypedNamedElement at all, since TypedElement is a NamedElement.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable FeatureOwner: NameSpace{
         attribute Set<AbstractFeature> has_feature;
         relationship has_features Composes 0..1 is_ordered AbstractFeature inverse defines;
 };
 
 The attribute has_feature is inappropriate since:
 a) AbstractFeature is an identifiable BOCA type and thus should not be the type of an attribute, and
 b) The necessary semantics are expressed by the relationship has_features
 
 Recommendation: Remove attribute has_feature

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaArgument:TypedNamedElement{
         attribute ParameterDirectionKind kind;
         relationship operation IsPartOf CorbaOperation inverse arguments;
 };
 
 The corresponding UML diagram (section 5.2) shows the relationship as one of composition (strong 
 aggregation).
 
 Recommendation:  Change IsPartOf to IsOwnedBy
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaArgument:TypedNamedElement{
         attribute ParameterDirectionKind kind;
         relationship operation IsPartOf CorbaOperation inverse arguments;
 };
 
 The declaration of the operation relationship illustrates the fact that the CDL grammar for relationship 
 declarations permits multiplicity to be omitted, in which case defaults defined in the meta-model for specific 
 types of relationship are assumed.  This encourages a lack of explicitness contrary to the intention of CDL to 
 provide a readable text rendition of a domain model with the most important semantics clearly visible.
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaStructuredType:CorbaType,FeatureOwner{
 };
 ...
 identifiable CorbaStructuredType : FeatureOwner, CorbaType {};
 
 CorbaStructuredType is declared twice.
 Recommendation: Remove the first declaration.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaException:NameSpace{
         relationship exception_element Many CorbaExceptionMember inverse is_in;
         relationship can_be_raised 0..* CorbaOperation inverse may_raise;
 };
 
 The corresponding UML diagram (section 5.2) shows the exception_element relationship as being one of 
 composition.
 
 Recommendation: In the exception_element relationship, change Many to Composes.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaException:NameSpace{
         relationship exception_element Many CorbaExceptionMember inverse is_in;
         relationship can_be_raised 0..* CorbaOperation inverse may_raise;
 };
 
 The can_be_raised relationship should be modified by a constraint stating that the CorbaOperation and the 
 CorbaException be within the same scope.  It is not clear whether the meta-model contains enough 
 information to support formal expression of this constraint.
 
 Recommendations: Review the declaration of NameSpace and of its descendents to determine whether new 
 relationships need to be declared to describe the semantics of the CORBA namespace scoping rules. (See 
 issue 54).

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaStructuredType : FeatureOwner, CorbaType {};
 
 identifiable CorbaInterface:CorbaStructuredType, FeatureOwner{
         relationship subtype 0..* CorbaInterface inverse supertype;
         relationship supertype 0..* is_ordered CorbaInterface inverse subtype;
 };
 
 The declaration of CorbaInterface as deriving from FeatureOwner is redundant, since CorbaInterface also is 
 declared to derive from CorbaStructuredType which derives from FeatureOwner.
 
 Recommendation:  CorbaInterface should explicitly derive only from CorbaStructuredType.
 

Summary: 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;
 };
 
 The declaration of the subtype and supertype relationships illustrates the fact that CDL grammar permits the 
 relationship_kind to be omitted from a relationship declaration.
 
 Recommendation: Change CDL grammar for relationship declarations to require explicit specification of the 
 relationship_kind.

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.
 

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;
 };
 
 The UML diagram (section 5.2) describes the first attribute differently; specifically it shows this attribute as 
 having the name context_id and its type as a sequence of strings.
 
 Recommendation: Either change the CDL declaration of CorbaOperation or the UML diagram so that the 
 two agree.

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;
 };
 
 In the corresponding UML diagram (Section 5.2) the arguments relationship is shown as being one of 
 composition.  Thus, the UML and CDL contradict each other.
 
 Recommendation: The CDL declaration of this relationship should specify Composes rather than Many.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaExceptionMember: TypedElement{
         relationship is_in IsPartOf CorbaException inverse exception_element;
 };
 
 In the corresponding UML diagram (Section 5.3), the relationship between CorbaException and 
 CorbaExceptionMember is shown as being one of composition.  Thus, the UML and CDL contradict each 
 other.
 
 Recommendation: The CDL declaration of this relationship should specify IsOwnedBy rather than IsPartOf.
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaEnumerator : TypedElement{
         relationship is_in IsPartOf CorbaException inverse exception_element;
 };
 
 Regarding the is_in relationship declaration:  The inverse exception_element is one of composition, and the 
 corresponding UML (section 5.3) confirms this.
 
 Recommendation: The CDL declaration of the is_in relationship should specify IsOwnedBy rather than 
 IsPartOf.
 

  The inverse exception_element is one of composition, and the 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaUnion: CorbaStructuredType{
         //attribute CorbaType discriminator_type;
 relationship discriminator_type Uses CorbaType;
 };
 ...
 identifiable CorbaUnionMember:StructuralFeature{
         attribute any label;
 };
 
 The corresponding UML diagram (section 5.3) shows an association wherein CorbaUnion is a composition 
 of CorbaUnionMember(s).  Yet, this is not reflected in the CDL.  It is not reflected in the CDL because of the 
 fact that this relationship is actually a specialization of the relationship between FeatureOwner and Feature.  
 It is understandable that this relationship was not declared in the CDL because of the following problem:
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable CorbaStruct:CorbaStructuredType{
 };
 
 identifiable CorbaStructureMember:StructuralFeature{
         // [required] attribute CorbaStruct defined_in;
         relationship defined_in Uses 1..1 CorbaStruct;
 };
 
 The problem and solution discussed in issue 18 applies here as well.  However, in this case, the relationship 
 is sort of redefined, but  with a different name, with a simple Uses specifier, and as a one-way relationship 
 (no inverse).  This despite the fact that the corresponding UML diagram (section 5.3) specializes the 
 Feature-FeatureOwner relationship. 
 
 Recommendation: The defined_in relationship should be removed.  CorbaStruct should redefine the 
 has_feature relationship it inherits from FeatureOwner by adding a constraint saying that the relationship 
 can be populated only with CorbaStructMember instances.  CorbaStructMember should redefine the defines 
 relationship it inherits from Feature by adding a constraint saying that the relationship can be populated only 
 with a CorbaStruct instance.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 enum AggregationKind{
         NOT_AGGREGATE,
         IS_AGGREGATE,
         IS_COMPOSITE};
 
 AggregationKind is modeled after a corresponding data type in UML.  However, the names of the values 
 differ needlessly from those of UML  Perhaps these names fit the BOCA style better.  However, it is more 
 important not to cause any confusion to those familiar with UML.
 
 Recommendation:  Define AggregationKind as follows:
 
 enum AggregationKind{
         NONE,
         SHARED,
         COMPOSITE};

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable BocaDuring: BocaFeatureOwner   {
         relationship owner IsPartOf BocaFeatureOwner inverse during_kw;
         // attribute BooleanExpression condition;
 relationship condition Uses BooleanExpression;
 }; /* DuringBlockDef */
 
 The declaration of the relationship owner as an IsPartOf relationship conflicts with corresponding UML 
 (section 2.2.2.1) which shows the relationship as being one of composition.
 
 Recommendation: In the CDL declaration of the relationship, change IsPartOf to IsOwnedBy.

Summary:  BocaFeature should redefine the defines relationship that it inherits from Feature by 
 adding a constraint stating that the relationship can only be populated by an instance of 
 BocaFeatureOwner.   
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 [is_abstract] identifiable BocaFeature: AbstractFeature{
         attribute boolean is_read_only=FALSE;
         attribute ScopeKind target_scope=INSTANCES;
         attribute VisibilityKind visibility=PUBLIC;
         attribute EventKind events=TRIGGERED_EVENTS;
         attribute string event_subject;
         attribute boolean is_locked=FALSE;
         [MANAGER,is_read_only] attribute string keyword;
         attribute boolean export=FALSE;
         // attribute BocaFeature redefines;
         relationship redefines References BocaFeature inverse redefined_by;
         relationship redefined_by References BocaFeature inverse redefines;
 }; /* Feature */
 
 The corresponding UML diagram (section 2.2.2.1) shows the redefined_by relationship as having multiplicity 
 *.
 
 Recommendations:  Change the CDL declaration of the relationship redefined_by  to show 0..* multiplicity.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 [is_abstract] identifiable BocaStructuralFeature: BocaFeature
                 , StructuralFeature
 {
         //attribute Expression computation;
          relationship computation Uses Expression;
         attribute WhenKind computation_kind=NO_COMPUTATION;
         // attribute BooleanExpression constraint;
          relationship constraint Uses BooleanExpression;
         attribute ChangeableKind changeable=IS_CHANGEABLE;
         attribute boolean inherit_specification=FALSE;
         // attribute Classifier returned_type;
          relationship returned_type Uses Classifier;
         attribute boolean is_state=TRUE;
         // attribute Set<ChangeConsumer> consumer;
         relationship consumer Many ChangeConsumer inverse producer;
 }; /* StructuralFeature */
 
 It is not clear why the inherit_specification attribute is declared here rather than in 
 BocaRelatiohshipReference.
 
 Recommendation:  Either provide a reason for this attribute"s presence here or move it to 
 BocaRelationshipReference.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable BocaStateSet: BocaStructuralFeature{
         {is_read_only=TRUE;
          keyword="state";
          };
 }; /* state */
 
 The corresponding UML diagram (section 2.2.2.3) shows an informally stated constraint "Type must be 
 CorbaEnumeration" but the constraint is not declared in the CDL.
 
 Recommendation: This constraint should appear formally in the CDL. If CDL expressions cannot express 
 the constraint, the expression syntax and meta-model should be upgraded accordingly.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 [is_abstract] relationship_kind BocaRelationshipReference: BocaStructuralFeature
                 {
                 attribute AggregationKind aggregation;
                 attribute boolean implicit_delete=FALSE;
                 attribute boolean implicit_copy=FALSE;
                 attribute boolean implicit_move=FALSE;
                 attribute BocaRelationshipReference with_respect_to;
                 attribute MultiplicityKind multiplicity=MultiplicityKind(0..1);
                 attribute boolean is_navigable=TRUE;
                 relationship inverse References BocaRelationshipReference;
 };
 
 The following attributes of BocaRelationshipReference should be features of particular subtypes of this 
 abstract type that are inherent features of those relationship subtypes rather than features of instances of 
 the relationship subtypes:
 ? aggregation
 ? implicit_delete
 ? implicit_copy
 ? implicit_move
 
 In other words they should be typemanager-level features rather than instance-level features.  Yet, these 
 attributes are not declared with the MANAGER specifier.
 
 Recommendation: Declare these attributes as [MANAGER, is_locked, is_read_only].
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 Another issue with the declaration of BocaRelationshipReference:  The inverse relationship declaration is 
 problematical because inverse is itself a keyword
 
 Recommendation: The relationship should be defined as follows:
 
 [MANAGER] relationship inverse_type References 1..1 BocaRelationshipReference

Summary: Recommendation: Issue 6 contains a recommendation to eliminate the Many specifier for relationship 
 declarations.  Thus, this declaration of the relationship_kind Many should be eliminated from the meta-
 model.  
 
 Furthermore, the inverse_type for References should be References.  The semantic constraints addressed 
 by having separate Many and References specifiers should be expressed as formal constraints on the 
 combinations of multiplicity of a relationship and of the relationship pointed to by the inverse_type 
 relationship. 
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 Another issue with the relationship_kind declarations:  As mentioned above (issue 6), it is preferable to force 
 relationship declarations to specify their multiplicity.  
 
 Recommendation: Rather than declare default multiplicities for a relationship_kind, it would be better to 
 declare, as invariant rules, appropriate constraints on the multiplicity for each relationship_kind.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 Another issue with the relationship_kind declarations:  They should include specifications of the value of the 
 aggregation attribute inherited from BocaRelationshipReference. 
 

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 Another issue with the relationship_kind declarations: Some of the inverse_type specifications are incorrect.  
 
 Recommendation: The following table lists the ones that are incorrect and provides the corrected values:
 
 relationship_kind
 old  inverse_type 
 correct  inverse_type 
 References
 Many
 References*
 Aggregates
 IsOwnedBy
 IsPartOf
 IsOwnedBy
 Aggregates
 Composes
 Composes
 IsPartOf
 IsOwnedBy
 IsPartOf
 Composes
 Aggregates
 
 *See issue 30

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable BocaApply: BocaBehavioralFeature {
         attribute Appliance applied_ppliance;
 };
 
 Recommendation: Change applied_ppliance to applied_appliance.

 Change applied_ppliance to applied_appliance.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable BocaSignal: BocaOperation{
                 {is_read_only=TRUE;
                 keyword="event";
                 };
 };
 
 The keyword “event” is incorrect—this is a vestige from an earlier version of the specification.
 
 Recommendation: Change “event” to “signal”

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable BocaBusinessEvent: BocaBusinessObject {
         [MANAGER, is_read_only, is_locked] relationship base_type Uses BocaType=BaseProcess;
         [MANAGER, is_read_only, is_locked] attribute string keyword="process";
 };  /* processDef */
 
 The keyword "process" is incorrect. 
 
 Recommendation: The obvious change is "process" to "event."  However, it is not clear what the purpose of BocaBusinessEvent is in the meta-model.  Some clarification is in order.
 

Summary: BocaCommand, a subtype of BocaDependent, redeclares the pass_by_value attribute in a redundant 
 fashion.
 
 Recommendation: Remove the (re)declaration of pass_by_value from BocaCommand.

Summary: The declaration of the pass_by_value attribute is redundant, since that is the inherited value.  No redefinition 
 is needed.
 
 Recommendation: Remove the (re)declaration of pass_by_value from BocaApplianceKind.
 

Summary: [is_abstract] appliance_kind Appliance {
 }; /* Appliance */
 
 It is not clear what the purpose of this declaration is.  It seems to simply create a meaningless empty 
 subtype of BocaApplianceKind.
  
 Recommendation:  Clarify the purpose this declaration or else remove it from the meta-model.

  Clarify the purpose this declaration or else remove it from the meta-model.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 appliance_kind Dependency;
 
 This forward reference is unnecessary.
 
 Recommendation:  Remove it.

  Remove it.

Summary: The specification of the keyword appliance_kind for BocaApplianceKind means that the declaration of Label 
 as an appliance_kind automatically makes BocaApplianceKind the supertype of Label.  Therefore, if, in 
 keeping with issue 39, Appliance is removed from the meta-model, then the Label declaration need not have 
 any explicit supertype.
 
 Recommendation: If Appliance is removed from the meta-model then remove the specification of Appliance 
 as the supertype of Label.

Summary: MultiplicityKind instances should be lightweight objects that are passed by value.
 
 Recommendation:  Declare MultiplicityKind as a dependent.  All relationships with this type should be 
 changed to attributes.
 

Summary: identifiable BocaEventConsumer{
         attribute boolean before=FALSE;
         // attribute Expression path_expression;
         relationship path_expression Uses Expression;
 }; /* TriggerElement */
 identifiable CallConsumer: BocaEventConsumer{
         attribute boolean failure=FALSE;
         relationship producer References 1..1 BocaOperation inverse consumer;
 };
 identifiable ChangeConsumer: BocaEventConsumer{
         attribute boolean remove=FALSE;
         relationship producer References 1..1 BocaStructuralFeature inverse consumer;
 };
 identifiable StateConsumer: ChangeConsumer{
         attribute boolean on_exit=FALSE;
 };
 The names of these meta-types are confusing.  
 
 Recommendation: The meta-type names should be changed as indicated in the following table:
 
 Old Name
 New Name
 BocaEventConsumer
 BocaTrigger
 CallConsumer
 BocaCallTrigger
 ChangeConsumer
 BocaChangeTrigger
 StateConsumer
 BocaStateChangeTrigger
 
 
 

Summary: The name_space relationship is redundant if TypedElement is a subtype of NamedElement (see issue 3) 
 because it duplicates the relationship between NamedElement and NameSpace.
 
 Recommendation: If, in fact, TypedElement is a subtype of NamedElement, then remove the name_space 
 relationship declaration from the declaration of BaseExpression.

Summary: Section 2.2.4 (BOCA Meta-Model in CDL)
 
 identifiable Expression: BaseExpression{
 };
 
 The corresponding UML diagram (section 2.2.2.7) informally states a constraint for this meta-type: “Must not 
 have side effects.”   However, the constraint does not appear in the CDL declaration.
 
 Recommendation: This constraint should appear formally in the CDL. The potential or lack of potential for 
 side effects can be detected by the by traversing the expression to determine what Invocations are made, 
 traversing the of_operation relationship that Invocation has with BocaOperation, and checking the value of 
 the the related BocaOperation’s is_query attribute.  If CDL expressions cannot express the constraint, the 
 expression syntax and meta-model should be upgraded accordingly

Summary: identifiable InvocationArgument{
         //attribute ExpressionElement value;
         relationship invocationValue Uses ExpressionElement;
         //attribute CorbaArgument of_argument;
         relationship of_argument Uses CorbaArgument;
         relationship call IsPartOf Invocation inverse argument;
 };
 
 The corresponding UML diagram (section 2.2.2.7) informally states a constraint for this meta-type: “Only in 
 arguments allowed.”   However, the constraint does not appear in the CDL declaration.
 
 Recommendation: This constraint should appear formally in the CDL declaration of this meta-type.

Summary: SubsetVariable’s function relationship and SubsetFunction’s variable relationship are logically inverses of 
 each other, yet that is not reflected in the CDL.  Furthermore, the corresponding UML diagram (section 
 2.2.2.7) shows the relationship as 1-1, yet the default multiplicities for Uses is not 1.
 
 Recommendation: Declare the inverses.  Determine the proper multiplicities for these relationships and state 
 them explicitly, making sure of agreement between the CDL and UML versions of the meta-model.
 

Summary: Section 5.4, UML diagram for Corba Nesting
 
 This information does not appear to be reflected in the CDL declaration of the meta-model.
 
 Recommendation: A clarification must be provided.  Nesting semantics may need to be formally specified in 
 the CDL declarations of the various meta-types as constraints on certain relationships.
 

Summary: Section 2.2.2.1, UML diagram for Core Model
 
 The following UML classifiers describing BOCA meta-types have attributes that are actually supposed to be 
 relationships.  The following table specifies the meta-types that have this problem and the problematic 
 attributes:
 
 BocaMeta-type
 Attribute
 Target BocaMeta-type
 BocaDuring
 condition
 BooleanExpression
 BocaStructuralFeature
 computation
 Expression
 BocaStructuralFeature
 constraint
 BooleanExpression
 BocaStructuralFeature
 returned_type
 Classifier
 BocaType
 base_type
 BocaType
 
 Recommendation: Remove the attributes or mark them as derived attributes. Draw the associations where 
 practical.

Summary: Section 2.2.2.3, UML diagram for Structural Features
 
 The following UML classifiers describing BOCA meta-types have attributes that are actually supposed to be 
 relationships.  The following table specifies the meta-types that have this problem and the problematic 
 attributes:
 
 BocaMeta-type
 Attribute
 Target BocaMeta-type
 BocaStructuralFeature
 computation
 Expression
 BocaStructuralFeature
 constraint
 BooleanExpression
 BocaStructuralFeature
 returned_type
 Classifier
 BocaRelationshipReference
 with_respect_to
 BocaRelationshipReference
 
 Recommendation: Remove the attributes or mark them as derived attributes. Draw the associations where 
 practical.
 

Summary: Section 2.2.2.4, UML diagram for Domain Meta-Types
 
 The following UML classifiers describing BOCA meta-types have attributes that are actually supposed to be 
 relationships.  The following table specifies the meta-types that have this problem and the problematic 
 attributes:
 
 BocaMeta-type
 Attribute
 Target BocaMeta-type
 BocaType
 base_type
 BocaType
 BocaRelationKind
 inverse_type
 BocaRelationshipReference
 BocaCollectionKind
 content_type
 Classifier
 
 Recommendation: Remove the attributes or mark them as derived attributes. Draw the associations where 
 practical.
 

Summary: Section 2.2.2.5, UML diagram for Appliances
 
 The following UML classifiers describing BOCA meta-types have attributes that are actually supposed to be 
 relationships.  The following table specifies the meta-types that have this problem and the problematic 
 attributes:
 
 BocaMeta-type
 Attribute
 Target BocaMeta-type
 Label
 labeled_element
 NamedElement
 Dependency
 guard
 BooleanExpression
 Dependency
 schedule
 ScheduleKind
 BocaEventConsumer
 path_expression
 Expression
 ECARule
 action
 ActionExpression
 
 Recommendation: Remove the attributes or mark them as derived attributes. Draw the associations where 
 practical.
 

Summary: Section 2.2.2.7, UML diagram for Expressions
 
 The following UML classifiers describing BOCA meta-types have attributes that are actually supposed to be 
 relationships.  The following table specifies the meta-types that have this problem and the problematic 
 attributes:
 
 BocaMeta-type
 Attribute
 Target BocaMeta-type
 Invocation
 of_operation
 CorbaOperation
 Invocation
 receiver
 ExpressionElement
 InvocationArgument
 value
 ExpressionElement
 InvocationArgument
 of_argument
 CorbaArgument
 BuiltInBinary
 left
 ExpressionElement
 BuiltInBinary
 right
 ExpressionElement
 Conditional
 condition
 ExpressionElement
 Conditional
 true_value
 ExpressionElement
 Conditional
 false_value
 ExpressionElement
 SubsetFunction
 the_set
 ExpressionElement
 SubsetFunction
 constraint
 ExpressionElement
 BuiltInUnary
 argument
 ExpressionElement
 ArrayAccess
 of_array
 ExpressionElement
 ArrayAccess
 argument
 ExpressionElement
 Traversal
 of_feature
 StructuralFeature
 Traversal
 argument
 ExpressionElement
 
 Recommendation: The apparent recommendation would be to remove the attributes or mark them as 
 derived attributes and to draw the associations where practical.  However, in this case it may be overkill to 
 have all of the expression types be full-blown identifiable objects that can engage in relationships.  It may be 
 more practical to make them dependent types and to use attributes.  This should be studied and any 
 changes must be reflected in the CDL declaration of the meta-model.
 

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*

 Close study of this issue, with input from OADTF and BOCA RTF.

Summary: Aligment with UML—Constraints
 
 Stated as only a general issue at this point:  The model for expressions and constraints could probably be 
 better aligned with UML, understanding, however, that UML does not rigorously model expressions the way 
 BOCA does.  Nevertheless, UML has a Constraint meta-type with very clear associations with other meta-
 type elements.  BOCA could probably come very, very close to that, while preserving its expression meta-
 model.
 
 However, the BOCA expression language may not be powerful enough to state the kinds of constraints 
 required by a precise contract for a type.  For example, see issues 18, 25, and 48 for cases where the 
 expression language may not support  the expression of certain required constraints. 
 
 Therefore, it may be wise to allow OCL expressions as an optional expression form.and to provide a meta-
 model for it.  The BOCA submitters have already done quite a bit of work in this area and OCL was in and 
 out of various versions of BOCA.  Proper alignment with UML would require subtyping UML to provide a 
 rigorous meta-model for OCL, so that OCL constraints can appear in tractable form in UML metadata.  The 
 BOCA OCL meta-model would be as isomorphic as possible with the UML OCL meta-model, while 
 incorporating the CORBA data types.
 
 Recommendation: Close study of this issue, with input from OADTF and BOCA RTF.
 

Summary: Alignment with UML—General
 
 It is extremely important to understand, and thus is worth reiterating, that any proposed UML subtyping is 
 not part of BOCA.  BOCA is a model for the CORBA target, so any subtyping of UML should stay in the UML 
 space and should have a matching (and as isomorphic as possible) set of constructs in the BOCA meta-
 model.  The reason for BOCA’s existence is to ensure that, when mapping a model expressed in UML to 
 CORBA, the rich semantics of UML are not lost in the translation.
 
 As stated in issue 61, those portions of the BOCA meta-model that do not carry the baggage (not meant as 
 a pejorative term) of the legacy CORBA IDL meta-model should align as closely as possible with UML.  
 Whereever subtyping of the UML meta-model is necessary it should be specified and proposed in 
 coordination with the OAD-TF and BOCA should have (as) isomorphic (as possible) elements in its own 
 meta-model.
 

Summary: Deriving from the legacy CORBA IDL meta-model
 
 Stated as only a general issue at this point:  The need for MOF compliance required reengineering the 
 legacy CORBA IDL meta-model so that it could be expressed as a UML model following the MOF 
 constraints (such as only binary associations).  The legacy is also expressed in CDL.  The expression of the 
 CORBA IDL meta-model could probably be more obviously aligned with the structural features of the 
 interface repository types.  In this short RTF cycle it hasn’t been possible to delineate these adjustments, but 
 this should be addressed.
 
 Recommendation: Close study of this issue.
 

Summary: Insufficient contraints in the meta-model
 
 Stated as only a general issue at this point: The meta-model has a dearth of formal constraints expressing 
 the semantics and well-formedness rules of the meta-model.
 
 Recommendation:  Close study of this issue.

Summary: Define relationship of "Abstract Framework" to Boca
 specification.
 

 received issue