Issue 4906: Multiple owners of Clause                                                                                                                                                                               (action-semantics-ftf)
Source: International Business Machines (Mr. Sridhar Iyengar, siyengar@us.ibm.com)
Nature: Uncategorized Issue
Severity: 
Summary: [Sridhar Iyengar] 15.Page 2-238: Figure 2-41.  Looking at the metamodel,
it looks like the same 'Clause' can be owned by a LoopAction and a
ConditionalAction.  For pragmatic reasons, there should be an OCL
constraint preventing this from happening - unless the submitters feel
the same clause can be 'owned' by both types of Actions. (I tried to
find the constraint and did not see one).  I usually see a red flag when
multiple composite associations point to the same Class. (In this case
both LoopAction and ConditionalAction have a composite Association to
Clause.  In other parts of the spec where this pattern recurs, I did see
the OCL constraint! (See Figure 3, Page 15 and related well formedness
rule on Page 21 that makes sure an 'input pin must be owned by either an
Action or a Procedure but not both'.
Resolution: accept
Revised Text: Added xor constraint between association to Clause from
    ConditionalAction and LoopAction, in Composite Actions model in
    Composite Actions chapter.

Actions taken:
March 5, 2002: received issue
December 11, 2002: closed issue
Discussion: 
It's part of the semantics of strong composition that a Clause instance
will have only one container at runtime.  However, an xor constraint in
the metamodel will be added to be explicit.


End of Annotations:=====
Summary: Multiple owners of Clause

Text:

[Sridhar Iyengar] 15.Page 2-238: Figure 2-41.  Looking at the
metamodel,
it looks like the same 'Clause' can be owned by a LoopAction and a
ConditionalAction.  For pragmatic reasons, there should be an OCL
constraint preventing this from happening - unless the submitters feel
the same clause can be 'owned' by both types of Actions. (I tried to
find the constraint and did not see one).  I usually see a red flag
when
multiple composite associations point to the same Class. (In this case
both LoopAction and ConditionalAction have a composite Association to
Clause.  In other parts of the spec where this pattern recurs, I did
see
the OCL constraint! (See Figure 3, Page 15 and related well formedness
rule on Page 21 that makes sure an 'input pin must be owned by either
an
Action or a Procedure but not both'.