Issue 6078: Strict ordering in Inline Part Decomposition (uml2-superstructure-ftf) Source: SINTEF (Dr. Oystein Haugen, oystein.haugen(at)sintef.no) Nature: Clarification Severity: Minor Summary: Inline Part Decomposition as shown in Figure 341 p. 433 are practical, but often it is necessary to describe the individual ordering between the events on the different inner lifelines. Often the user will want this ordering to be strict rather than weak. There should be a way to denote that the ordering within an inline part decomposition should be strict. Originally reported by Ericsson engineer Peter Cigehn. Resolution: see above Revised Text: Actions taken: August 28, 2003: received issue March 8, 2005: closed issue Discussion: The simplest solution is to append the lifeline text with an optional strict keyword. This would mean that the events of the inline decomposition are strictly ordered from top to bottom. (When the decomposition is explicit reference, then the strict property would be associated with the referenced diagram.) Concrete changes to the Final Adopted document: In the paragraph on Notation for Lifelines (p 427) decomposition ::= ref interactionident should be augmented to: decomposition ::= ref interactionident [strict] In the paragraph on Notation for PartDecomposition (p 432) A new second paragraph should be inserted: If the part decomposition is denoted inline under the decomposed lifeline and the decomposition clause is the keyword strict, this indicates that the constructs on all sub-lifelines within the inline decomposition is ordered in strict sequence. See CombinedFragment on strict operator. End of Annotations:===== From: webmaster@omg.org Date: 28 Aug 2003 02:40:23 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Oystein Haugen Company: Ericsson mailFrom: oystein.haugen@ericsson.com Notification: Yes Specification: UML 2.0 Superstructure Section: 14.3.16 FormalNumber: ptc/03-08-02 Version: 2.0 RevisionDate: August 2003 Page: 433 Nature: Clarification Severity: Minor HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0) Description Strict ordering in Inline Part Decomposition Inline Part Decomposition as shown in Figure 341 p. 433 are practical, but often it is necessary to describe the individual ordering between the events on the different inner lifelines. Often the user will want this ordering to be strict rather than weak. There should be a way to denote that the ordering within an inline part decomposition should be strict. OMG Issue No: 6078 Title: Strict ordering in Inline Part Decomposition Source: Ericsson (Dr. Oystein Haugen, oystein.haugen@ericsson.no oystein.haugen@ericsson.com Oystein.Haugen@eto.ericsson.se) Summary: Inline Part Decomposition as shown in Figure 341 p. 433 are practical, but often it is necessary to describe the individual ordering between the events on the different inner lifelines. Often the user will want this ordering to be strict rather than weak. There should be a way to denote that the ordering within an inline part decomposition should be strict. Originally reported by Ericsson engineer Peter Cigehn. Discussion: Disposition: Unresolved Originally reported by Ericsson engineer Peter Cigehn. To: "Thomas Weigert" Cc: "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: ,cs cb, Ballot 13 proposed resolutions X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 22 Apr 2004 16:57:33 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 04/22/2004 16:57:35, Serialize complete at 04/22/2004 16:57:35 Thomas, I have reviewed your proposed resolutions for ballot 13 and have the following comments and concerns: (1) Issue 6078: (a) from your explanation, it looks to me that the vertical bar -- indicating choice -- in the expression: ref interactionident | [strict] is incorrect and should be removed. (b) it seems that the information that the inline decomposition is strict is only kept in the notation and not in the model. Presumably, this information is somehow transferred into some interaction operator of some combined fragment of the part decomposition corresponding to the lifeline -- however, how this is done is not described. This needs to be clarified. (2) Issue 6146: I agree with your "closed, no change" disposition, but I think your explanation is missing at least one major point. I believe that the question primarily related to the fact that Collaboration is defined as a kind of BehavioredClassifier -- which is perfectly reasonable since we want to be able to associate Interactions with Collaborations. It would be useful if this was added to the resolution. (3) Issue 6154: The text in the Semantics part of TimeObservationAction says that this action, "...when executed, returns the current value of time in the context in which....". I suggest replacing the word "returns" in this text with the word "reads" or "registers". Otherwise, it seems to clash with the fact that this action, being a write action does not have return values. (An aside: I should have been paying attention to this when it was being done in the U2P. Why should this action be restricted to just write-once-attributes? Why not make it more general? This seems like a piece of an SDL profile that snuck in under the radar.) (4) Issue 6251: I sent you an OCL constraint that effectively said that all roles that are connected by a connector have to be in the same Classifier (namespace). This also resolves issue 6668. So, I suggest that you change this to "resolved" and add my constraint. (In fact, the fix I sent you also includes a nice illustration which is a bit easier to follow than your textual explanation, so I suggest you replace the resolution with the one I proposed.) (5) Issue 6257: It would really help me and others if in the future you could put a figure number for the diagram that you want to change -- it makes it a lot easier to review the resolution proposal and to make the change once it is adopted. (I assume you mean figure 318 in this case?) (6) Issue 6355: I don't think that "Duplicate" is the right resolution to this issue. What happened here is that the reader who read the spec missed the rather convoluted "trick" that is used to specify when a connector end is connected to a port. The trick is used to avoid a "PortReference" concept, by providing a link to a part that owns the port that is being connected when the connector terminates on a port of some part (i.e., if this link is nil, then the connector terminates on a port or part, otherwise, it terminates on the port of a part, and you know which it is based on which port the connector end is linked to). This is very subtle and will be confusing to many unless additional text is provided. (7) Issue 6668: See my comment for issue 6251. Cheers, Bran "Thomas Weigert" 04/21/2004 04:33 PM To "Thomas Weigert" , Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: ,cs cb, Ballot 13 proposed resolutions Please find attached an additional issue resolution (included in the pack sent earlier)... Th -----Original Message----- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Monday, April 19, 2004 11:27 AM To: Branislav Selic; uml2-superstructure-ftf@omg.org Subject: ,cs cb, Ballot 13 proposed resolutions Please find attached the first installment of Ballot 13 proposals (I think that is the next ballot). OMG Issue No: 6078 Title: Strict ordering in Inline Part Decomposition Source: Ericsson (Dr. Oystein Haugen, oystein.haugen@ericsson.no oystein.haugen@ericsson.com Oystein.Haugen@eto.ericsson.se) Summary: Inline Part Decomposition as shown in Figure 341 p. 433 are practical, but often it is necessary to describe the individual ordering between the events on the different inner lifelines. Often the user will want this ordering to be strict rather than weak. There should be a way to denote that the ordering within an inline part decomposition should be strict. Originally reported by Ericsson engineer Peter Cigehn. Discussion: The simplest solution is to append the lifeline text with an optional strict keyword. This would mean that the events of the inline decomposition are strictly ordered from top to bottom. (When the decomposition is explicit reference, then the strict property would be associated with the referenced diagram.) Concrete changes to the Final Adopted document: In the paragraph on Notation for Lifelines (p 427) decomposition ::= ref interactionident should be augmented to: decomposition ::= ref interactionident [strict] In the paragraph on Notation for PartDecomposition (p 432) A new second paragraph should be inserted: If the part decomposition is denoted inline under the decomposed lifeline and the decomposition clause is the keyword strict, this indicates that the constructs on all sub-lifelines within the inline decomposition is ordered in strict sequence. See CombinedFragment on strict operator. Disposition: Resolved All the best, Th.[attachment "Comp struc + com beh issues 3rd v2 done.doc" deleted by Branislav Selic/Ottawa/IBM]