Issue 6278: Sequence diagram conditions on Message arrows (uml2-superstructure-ftf) Source: Thematix Partners LLC (Mr. James J. Odell, email(at)jamesodell.com) Nature: Uncategorized Issue Severity: Summary: Sequence diagrams in UML 1.x supported a conditional expression to a message arrow that was inadvertently omitted from the UML 2.0 Superstructure specification. This annotation enabled the modeler to -- in essence -- place guards on messages. Such guards, or more properly ConditionalActions, would be evaluated at run time to determine which message arrow(s) would be executed. In particular, the UML 1.5 Superstructure document specifies the following: -In Section 3.60.5.1: "Any condition ... expression attached to the arrow becomes, in a detailed action model, the test clause action in a ConditionalAction ... in the dispatching Procedure. -In section 3.63.2: "An arrow may also be labeled with a condition and/or iteration expression." -In Section 3.63.3: "A branch is shown by multiple arrows leaving a single point, each possibly labeled by a condition. Depending on whether the conditions are mutually exclusive, the construct may represent conditionality or concurrency." -In 3.72.2.4: "A condition represents a Message whose execution is contingent on the truth of the condition clause. The condition-clause is meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format. An example would be: [x > y]." A "branch" condition, or ConditionalAction, is expressed in the form: Œ[¹ condition-clause Œ]¹ Recommendation: The UML 2.0 Superstructure FTF team should determine how to reinstate ConditionalActions for Sequence Diagrams, given the new abstract syntax for Sequence Diagrams. There are two reasons for this: 1) To maintain backward compatibility with UML 1.0 through 1.5 is important. 2) Pragmatically, it offers a graphically simple technique to express messaging situations that involve branching. Granted, the ALT operation supports the equivalent notion; however, it comes with a graphical complexity that is not always desired. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} Resolution: Revised Text: Actions taken: September 29, 2003: received issue March 9, 2005: closed issue Discussion: UML 2.0 interactions are not fully backwards compatible with UML 1.x interactions; neither are the respective sequence diagrams. Conditions in interactions are now shown with either opt or alt fragments. In additions, conditions can be shown using interaction overview diagrams. Adding the 1.x sequence diagram conditions would be completely inconsistent with the new style of sequence diagrams and would thus cause much confusion. It also was not scalable for real- life applications, albeit it looked cute in text books. The branching lifeline construct of UML1 would increase confusion and complexity of UML2, not decrease it. The original branching notation in UML1 had the following problems: - On a branch, the lifelines had to conceptually split into two logically-distinct lifelines, one corresponding to each arm of the branch. This is awkward to draw, difficult for tools to manage, confusing for people, and probably modeled incorrectly a large amount of the time. - It is also not clear which part of the split lifeline goes with which condition, especially if there are ne sted branches. It might be OK for just one lifeline, but if multiple lifelines appear in messages in the condition region, this may not even be conceptually sound. - There is no way to show the recombination of lifelines at the end of the branch. SOME lifelines may have messages that could merge back onto a single lifeline, but this is by no means required in all cases. - Nested conditional or loops become unworkable visually, and their semantic soundness is also questionable. In the new notation, the lifelines also conceptually split, but the separation of the diagram into physically-separate vertical sections, each corresponding to one arm of the branch, removes the visual problem. It also removes the conceptual problem: each region represents a conceptual split of ALL lifelines in the branch, so there is no problem in telling which version of a lifeline goes with which other version of a lifeline. When it comes to loops, the previous notation was even more deficient. You could draw a backward arrow, but the semantics were highly unfounded. We can't build a sound model on suggestive notation that is not well founded and which does not scale up. The new notation is absolutely clear and similar to much previous notation in modeling even before OO modeling. It is also close to a traditional program, so most users shouldn’t have a hard time following it. Even nonprogrammers have seen examples (in product manuals and other things) of structure text of the form IF xxx do this ... ELSE do this So even non techies are familiar with this kind of structure. The branching lifeline notation, however, was confusing for everybody. The old branching lifeline constructs were seriously flawed technically and visually. The new constructs are sound and scalable. Let's not put the bad ones back in. Disposition: Closed, no change End of Annotations:===== er-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 29 Sep 2003 11:42:09 -0400 Subject: Sequence Diagram "guard" issue for FTF From: James Odell To: Juergen Boldt X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h8TFcubP007080 Hi Juergen, Here is an issue for the Superstructure FTF. Thanks, Jim --------------------------------------------------------- OMG Issue No: ? Title: Sequence diagram conditions on Message arrows should be backward compatible with UML 1.x Source: Kabira, Inc. (James Odell ) Summary: Sequence diagrams in UML 1.x supported a conditional expression to a message arrow that was inadvertently omitted from the UML 2.0 Superstructure specification. This annotation enabled the modeler to -- in essence -- place guards on messages. Such guards, or more properly ConditionalActions, would be evaluated at run time to determine which message arrow(s) would be executed. In particular, the UML 1.5 Superstructure document specifies the following: -In Section 3.60.5.1: "Any condition ... expression attached to the arrow becomes, in a detailed action model, the test clause action in a ConditionalAction ... in the dispatching Procedure. -In section 3.63.2: "An arrow may also be labeled with a condition and/or iteration expression." -In Section 3.63.3: "A branch is shown by multiple arrows leaving a single point, each possibly labeled by a condition. Depending on whether the conditions are mutually exclusive, the construct may represent conditionality or concurrency." -In 3.72.2.4: "A condition represents a Message whose execution is contingent on the truth of the condition clause. The condition-clause is meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format. An example would be: [x > y]." A "branch" condition, or ConditionalAction, is expressed in the form: Œ[¹ condition-clause Œ]¹ Recommendation: The UML 2.0 Superstructure FTF team should determine how to reinstate ConditionalActions for Sequence Diagrams, given the new abstract syntax for Sequence Diagrams. There are two reasons for this: 1) To maintain backward compatibility with UML 1.0 through 1.5 is important. 2) Pragmatically, it offers a graphically simple technique to express messaging situations that involve branching. Granted, the ALT operation supports the equivalent notion; however, it comes with a graphical complexity that is not always desired. Discussion: {IF APPLICABLE - Summary of how the issue was proposed to be resolved and/or why it wasn't} OMG Issue No: 6278 Title: Sequence diagram conditions on Message arrows Source: Kabira Technologies, Inc. (Prof. James J. Odell, email@jamesodell.com omg@jamesodell.com) Summary: Sequence diagrams in UML 1.x supported a conditional expression to a message arrow that was inadvertently omitted from the UML 2.0 Superstructure specification. This annotation enabled the modeler to -- in essence -- place guards on messages. Such guards, or more properly ConditionalActions, would be evaluated at run time to determine which message arrow(s) would be executed. In particular, the UML 1.5 Superstructure document specifies the following: -In Section 3.60.5.1: "Any condition ... expression attached to the arrow becomes, in a detailed action model, the test clause action in a ConditionalAction ... in the dispatching Procedure. -In section 3.63.2: "An arrow may also be labeled with a condition and/or iteration expression." -In Section 3.63.3: "A branch is shown by multiple arrows leaving a single point, each possibly labeled by a condition. Depending on whether the conditions are mutually exclusive, the construct may represent conditionality or concurrency." -In 3.72.2.4: "A condition represents a Message whose execution is contingent on the truth of the condition clause. The condition-clause is meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format. An example would be: [x > y]." A "branch" condition, or ConditionalAction, is expressed in the form: .[¹ condition-clause .]¹ Recommendation: The UML 2.0 Superstructure FTF team should determine how to reinstate ConditionalActions for Sequence Diagrams, given the new abstract syntax for Sequence Diagrams. There are two reasons for this: 1) To maintain backward compatibility with UML 1.0 through 1.5 is important. 2) Pragmatically, it offers a graphically simple technique to express messaging situations that involve branching. Granted, the ALT operation supports the equivalent notion; however, it comes with a graphical complexity that is not always desired. Discussion: UML 2.0 interactions are not fully backwards compatible with UML 1.x interactions; neither are the respective sequence diagrams. Conditions in interactions are now shown with either opt or alt fragments. In additions, conditions can be shown using interaction overview diagrams. Adding the 1.x sequence diagram conditions would be completely inconsistent with the new style of sequence diagrams and would thus cause much confusion. It also was not scalable for real-life applications, albeit it looked cute in text books. Disposition: Closed, no change Subject: RE: ,ia, proposed issue resolution for issue 6278 Date: Wed, 11 Feb 2004 15:16:33 -0500 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: ,ia, ,ae, Proposed resolutions for issues 6018, 6085, 6230 Thread-Index: AcPwRoxo+Gj6xqiuTzaq2LRle2ksiwAkujgA From: "Nikolai Mansurov" To: "Branislav Selic" , Hello all, I'm posting for discussion the recommendation to close issue 6278 (see attached). The issue 6278 asks to include the UML 1.5 conditions on arrows. I support the recommendation TO CLOSE this issue. The new CombinedFragments (alt and loop) provide a more direct way to specify clauses that involve variants (alt) or iterations (loop). In comparison to the UML 1.x syntax, this brings the advantage of explicitly showing the lifelines involved in the clause, as well as the scope of the clause. This is achieved by using the graphical frame of the CombinedFragment. In the old (more light-weight) notation is is easy to see where the condition starts, but it is not at all clear where it ends (i.e. what is the scope of the conditional clause). This scoping is particularly important to be able to determine the state machine semantic of the objects involved in the interaction. The CombinedFragment is a general and uniform way of handling such situations. Adding the alternative way of doing things makes the language more complex. Cheers, Nick Weigert_Interaction issues resolution 6278.doc OMG Issue No: 6278 Title: Sequence diagram conditions on Message arrows Source: Kabira Technologies, Inc. (Prof. James J. Odell, email@jamesodell.com omg@jamesodell.com) Summary: Sequence diagrams in UML 1.x supported a conditional expression to a message arrow that was inadvertently omitted from the UML 2.0 Superstructure specification. This annotation enabled the modeler to -- in essence -- place guards on messages. Such guards, or more properly ConditionalActions, would be evaluated at run time to determine which message arrow(s) would be executed. In particular, the UML 1.5 Superstructure document specifies the following: -In Section 3.60.5.1: "Any condition ... expression attached to the arrow becomes, in a detailed action model, the test clause action in a ConditionalAction ... in the dispatching Procedure. -In section 3.63.2: "An arrow may also be labeled with a condition and/or iteration expression." -In Section 3.63.3: "A branch is shown by multiple arrows leaving a single point, each possibly labeled by a condition. Depending on whether the conditions are mutually exclusive, the construct may represent conditionality or concurrency." -In 3.72.2.4: "A condition represents a Message whose execution is contingent on the truth of the condition clause. The condition-clause is meant to be expressed in pseudocode or an actual programming language; UML does not prescribe its format. An example would be: [x > y]." A "branch" condition, or ConditionalAction, is expressed in the form: .[¹ condition-clause .]¹ Recommendation: The UML 2.0 Superstructure FTF team should determine how to reinstate ConditionalActions for Sequence Diagrams, given the new abstract syntax for Sequence Diagrams. There are two reasons for this: 1) To maintain backward compatibility with UML 1.0 through 1.5 is important. 2) Pragmatically, it offers a graphically simple technique to express messaging situations that involve branching. Granted, the ALT operation supports the equivalent notion; however, it comes with a graphical complexity that is not always desired. Discussion: UML 2.0 interactions are not fully backwards compatible with UML 1.x interactions; neither are the respective sequence diagrams. Conditions in interactions are now shown with either opt or alt fragments. In additions, conditions can be shown using interaction overview diagrams. Adding the 1.x sequence diagram conditions would be completely inconsistent with the new style of sequence diagrams and would thus cause much confusion. It also was not scalable for real-life applications, albeit it looked cute in text books. Disposition: Closed, no chan Date: Fri, 13 Feb 2004 15:56:32 +0000 From: Guus Ramackers Organization: Oracle User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en, en-us To: Nikolai Mansurov CC: Branislav Selic , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, proposed issue resolution for issue 6278 X-Brightmail-Tracker: AAAAAQAAAAI= X-White-List-Member: TRUE Nick, This issue was raised as a backward compatibility issue with UML 1.x. It was also raised as an issue to support the UML user who is not necessarily a seq modeling expert. There has been some discussion in public lists / conferences that "UML 2.0 is far too complex", catering for the expert user but not the average user. So I believe we should not dismiss this issue lightly. When earlier discussed, intention was to provide an optional alternative notation for choice and iteration (the typically most used constructs for "average" use) on top of the existing meta model to support backward compatibility. We have various places in UML where notation alternatives are offered, and this would not be out of place in sequence modeling. W.r.t. to the scope: tool vendors managed to implement code generation from sequence models for UML 1.x, particularly for synchronous programming models - a significant user base of UML. Hence, tool vendors can make the typical assumptions they made before. It may need some defaulting to store in the meta model, but that can be done. Thanks, Guus Nikolai Mansurov wrote: Hello all, I'm posting for discussion the recommendation to close issue 6278 (see attached). The issue 6278 asks to include the UML 1.5 conditions on arrows. I support the recommendation TO CLOSE this issue. The new CombinedFragments (alt and loop) provide a more direct way to specify clauses that involve variants (alt) or iterations (loop). In comparison to the UML 1.x syntax, this brings the advantage of explicitly showing the lifelines involved in the clause, as well as the scope of the clause. This is achieved by using the graphical frame of the CombinedFragment. In the old (more light-weight) notation is is easy to see where the condition starts, but it is not at all clear where it ends (i.e. what is the scope of the conditional clause). This scoping is particularly important to be able to determine the state machine semantic of the objects involved in the interaction. The CombinedFragment is a general and uniform way of handling such situations. Adding the alternative way of doing things makes the language more complex. Cheers, Nick -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: Guus Ramackers Cc: Nikolai Mansurov , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, proposed issue resolution for issue 6278 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Fri, 13 Feb 2004 12:04:57 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 02/13/2004 12:04:58, Serialize complete at 02/13/2004 12:04:58 Jim Odell might have useful input here since he raised the issue. My personal preference is to avoid two different ways of annotating the same thing (as I understand it, this is a notation issue and does not require any metamodel changes). Also, I never liked the old notation because I found it confusing -- you only noticed that the diagram was showing multiple alternatives if you were careful enough to read the message guards. Furthermore, it was difficult to understand which follow-on messages belonged to which alternative unless you made some not-necessarily valid assumptions about causality connections between messages. So, in addition to the confusion introduced by multiple notations there is the added confusion of the notation itself. But, as the old saying goes "de gustibus non est disputandum". To conclude I agree with Nick's "close, no change" recommendation on this issue. Bran Guus Ramackers 02/13/2004 10:56 AM To: Nikolai Mansurov cc: Branislav Selic/Ottawa/IBM@IBMCA, uml2-superstructure-ftf@omg.org Subject: Re: ,ia, proposed issue resolution for issue 6278 Nick, This issue was raised as a backward compatibility issue with UML 1.x. It was also raised as an issue to support the UML user who is not necessarily a seq modeling expert. There has been some discussion in public lists / conferences that "UML 2.0 is far too complex", catering for the expert user but not the average user. So I believe we should not dismiss this issue lightly. When earlier discussed, intention was to provide an optional alternative notation for choice and iteration (the typically most used constructs for "average" use) on top of the existing meta model to support backward compatibility. We have various places in UML where notation alternatives are offered, and this would not be out of place in sequence modeling. W.r.t. to the scope: tool vendors managed to implement code generation from sequence models for UML 1.x, particularly for synchronous programming models - a significant user base of UML. Hence, tool vendors can make the typical assumptions they made before. It may need some defaulting to store in the meta model, but that can be done. Thanks, Guus Nikolai Mansurov wrote: Hello all, I'm posting for discussion the recommendation to close issue 6278 (see attached). The issue 6278 asks to include the UML 1.5 conditions on arrows. I support the recommendation TO CLOSE this issue. The new CombinedFragments (alt and loop) provide a more direct way to specify clauses that involve variants (alt) or iterations (loop). In comparison to the UML 1.x syntax, this brings the advantage of explicitly showing the lifelines involved in the clause, as well as the scope of the clause. This is achieved by using the graphical frame of the CombinedFragment. In the old (more light-weight) notation is is easy to see where the condition starts, but it is not at all clear where it ends (i.e. what is the scope of the conditional clause). This scoping is particularly important to be able to determine the state machine semantic of the objects involved in the interaction. The CombinedFragment is a general and uniform way of handling such situations. Adding the alternative way of doing things makes the language more complex. Cheers, Nick -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 From: "Thomas Weigert" To: "Guus Ramackers" , "Nikolai Mansurov" Cc: "Branislav Selic" , Subject: RE: ,ia, proposed issue resolution for issue 6278 Date: Fri, 13 Feb 2004 18:14:59 +0100 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal I believe this is an example of what I called earlier "I don't like the current spec" type issues. The adopted spec decided, after much deliberation, to change sequence diagrams to make them more usable, more scalable, and more formal. There is nothing that prevent implementation of this part of the specification that is raised by issue 6278. In fact, implementations already exist. The issue does not discuss inconsistencies or other problems in the text. Therefore, by the principles that underlie the FTF as clarified by Bran recently, the most appropriate response is to close this issue as recommended in the resolution. All the best, Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Friday, February 13, 2004 4:57 PM To: Nikolai Mansurov Cc: Branislav Selic; uml2-superstructure-ftf@omg.org Subject: Re: ,ia, proposed issue resolution for issue 6278 Nick, This issue was raised as a backward compatibility issue with UML 1.x. It was also raised as an issue to support the UML user who is not necessarily a seq modeling expert. There has been some discussion in public lists / conferences that "UML 2.0 is far too complex", catering for the expert user but not the average user. So I believe we should not dismiss this issue lightly. When earlier discussed, intention was to provide an optional alternative notation for choice and iteration (the typically most used constructs for "average" use) on top of the existing meta model to support backward compatibility. We have various places in UML where notation alternatives are offered, and this would not be out of place in sequence modeling. W.r.t. to the scope: tool vendors managed to implement code generation from sequence models for UML 1.x, particularly for synchronous programming models - a significant user base of UML. Hence, tool vendors can make the typical assumptions they made before. It may need some defaulting to store in the meta model, but that can be done. Thanks, Guus Nikolai Mansurov wrote: Hello all, I'm posting for discussion the recommendation to close issue 6278 (see attached). The issue 6278 asks to include the UML 1.5 conditions on arrows. I support the recommendation TO CLOSE this issue. The new CombinedFragments (alt and loop) provide a more direct way to specify clauses that involve variants (alt) or iterations (loop). In comparison to the UML 1.x syntax, this brings the advantage of explicitly showing the lifelines involved in the clause, as well as the scope of the clause. This is achieved by using the graphical frame of the CombinedFragment. In the old (more light-weight) notation is is easy to see where the condition starts, but it is not at all clear where it ends (i.e. what is the scope of the conditional clause). This scoping is particularly important to be able to determine the state machine semantic of the objects involved in the interaction. The CombinedFragment is a general and uniform way of handling such situations. Adding the alternative way of doing things makes the language more complex. Cheers, Nick -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 To: Guus Ramackers Cc: Branislav Selic , Nikolai Mansurov , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, proposed issue resolution for issue 6278 X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Fri, 13 Feb 2004 09:51:14 -0800 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 02/13/2004 10:51:17, Serialize complete at 02/13/2004 10:51:17 I think it would be a bad idea to reinstate the branching lifeline construct of UML1 and it would increase confusion and complexity of UML2, not decrease it. I am speaking as the person who INVENTED the original notation (in UML 0.9), so I might be expected to have a proprietary interest in it, and I certainly understand it, but I recognize that it has serious flaws and that the new MSC-like notation for branches and loops is far superior and better founded, so I was quite willing to abandon the original notation. (Actually we recognized this a long time ago, but didn't have a good replacement until the MSC-like constructs were introduced.) The original branching notation had the following problems: - On a branch, the lifelines had to conceptually split into two logically-distinct lifelines, one corresponding to each arm of the branch. This is awkward to draw, difficult for tools to manage, confusing for people, and probably modeled incorrectly a large amount of the time. - It is also not clear which part of the split lifeline goes with which condition, especially if there are nested branches. It might be OK for just one lifeline, but if multiple lifelines appear in messages in the condition region, I'm not sure that it is even conceptually sound. - There is no way to show the recombination of lifelines at the end of the branch. SOME lifelines may have messages that could merge back onto a single lifeline, but this is by no means required in all cases. - Nested conditional or loops become unworkable visually, and their semantic soundness is also questionable. In the new notation, the lifelines also conceptually split, but the separation of the diagram into physically-separate vertical sections, each corresponding to one arm of the branch, removes the visual problem. It also removes the conceptual problem: each region represents a conceptual split of ALL lifelines in the branch, so there is no problem in telling which version of a lifeline goes with which other version of a lifeline. When it comes to loops, the previous notation was even more deficient. You could draw a backward arrow, but the semantics were highly unfounded. We can't build a sound model on suggestive notation that is not well founded and which does not scale up. The new notation is absolutely clear and similar to much previous notation in modeling even before OO modeling. It is also close to a traditional program, so I don't think most users should have a hard time following it. Even nonprogrammers have seen examples (in product manuals and other things) of structure text of the form IF xxx do this ... ELSE do this So even non techies are familiar with this kind of structure. The branching lifeline notation, however, was confusing for everybody. Backward compatibility is raised far too often in this forum as a justification for keeping flawed constructs. There is a good argument that previous constructs should not be changed arbitrarily just for the sake of change. On the other hand, it is the purpose of a new version of a standard to repair and replace flawed constructs, and they should not be preserved if they can be replaced by sound constructs that are equally easy to use (which is the case for the new alt and loop constructs). The old branching lifeline constructs were seriously flawed technically and visually. The new constructs are sound and scalable. Let's not put the bad ones back in. - Jim Rumbaugh Guus Ramackers 02/13/2004 07:56 AM To Nikolai Mansurov cc Branislav Selic , uml2-superstructure-ftf@omg.org Subject Re: ,ia, proposed issue resolution for issue 6278 Nick, This issue was raised as a backward compatibility issue with UML 1.x. It was also raised as an issue to support the UML user who is not necessarily a seq modeling expert. There has been some discussion in public lists / conferences that "UML 2.0 is far too complex", catering for the expert user but not the average user. So I believe we should not dismiss this issue lightly. When earlier discussed, intention was to provide an optional alternative notation for choice and iteration (the typically most used constructs for "average" use) on top of the existing meta model to support backward compatibility. We have various places in UML where notation alternatives are offered, and this would not be out of place in sequence modeling. W.r.t. to the scope: tool vendors managed to implement code generation from sequence models for UML 1.x, particularly for synchronous programming models - a significant user base of UML. Hence, tool vendors can make the typical assumptions they made before. It may need some defaulting to store in the meta model, but that can be done. Thanks, Guus Nikolai Mansurov wrote: Hello all, I'm posting for discussion the recommendation to close issue 6278 (see attached). The issue 6278 asks to include the UML 1.5 conditions on arrows. I support the recommendation TO CLOSE this issue. The new CombinedFragments (alt and loop) provide a more direct way to specify clauses that involve variants (alt) or iterations (loop). In comparison to the UML 1.x syntax, this brings the advantage of explicitly showing the lifelines involved in the clause, as well as the scope of the clause. This is achieved by using the graphical frame of the CombinedFragment. In the old (more light-weight) notation is is easy to see where the condition starts, but it is not at all clear where it ends (i.e. what is the scope of the conditional clause). This scoping is particularly important to be able to determine the state machine semantic of the objects involved in the interaction. The CombinedFragment is a general and uniform way of handling such situations. Adding the alternative way of doing things makes the language more complex. Cheers, Nick -- _____________________________________________________________ Guus Ramackers Product Manager UML and Web Services Tools Oracle JDeveloper Tools group 520 Oracle Parkway, TVP Reading RG6 1RA, UK work: +44-(0)1189-245101 e-mail: guus.ramackers@oracle.com fax: +44-(0)1189-245148 Date: Sat, 14 Feb 2004 14:22:17 +0100 From: Oystein Haugen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: James E Rumbaugh CC: Guus Ramackers , Branislav Selic , Nikolai Mansurov , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, proposed issue resolution for issue 6278 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=0.545, required 12, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54) Jim, Guus, Bran, Thomas, Nick I fully agree with JimR, Bran, Nick and Thomas on this issue. I think JimR explains very well the reasons for why this notation was dropped in UML 2.0. /Oystein James E Rumbaugh wrote: I think it would be a bad idea to reinstate the branching lifeline construct of UML1 and it would increase confusion and complexity of UML2, not decrease it. I am speaking as the person who INVENTED the original notation (in UML 0.9), so I might be expected to have a proprietary interest in it, and I certainly understand it, but I recognize that it has serious flaws and that the new MSC-like notation for branches and loops is far superior and better founded, so I was quite willing to abandon the original notation. (Actually we recognized this a long time ago, but didn't have a good replacement until the MSC-like constructs were introduced.) The original branching notation had the following problems: - On a branch, the lifelines had to conceptually split into two logically-distinct lifelines, one corresponding to each arm of the branch. This is awkward to draw, difficult for tools to manage, confusing for people, and probably modeled incorrectly a large amount of the time. - It is also not clear which part of the split lifeline goes with which condition, especially if there are nested branches. It might be OK for just one lifeline, but if multiple lifelines appear in messages in the condition region, I'm not sure that it is even conceptually sound. - There is no way to show the recombination of lifelines at the end of the branch. SOME lifelines may have messages that could merge back onto a single lifeline, but this is by no means required in all cases. - Nested conditional or loops become unworkable visually, and their semantic soundness is also questionable. In the new notation, the lifelines also conceptually split, but the separation of the diagram into physically-separate vertical sections, each corresponding to one arm of the branch, removes the visual problem. It also removes the conceptual problem: each region represents a conceptual split of ALL lifelines in the branch, so there is no problem in telling which version of a lifeline goes with which other version of a lifeline. When it comes to loops, the previous notation was even more deficient. You could draw a backward arrow, but the semantics were highly unfounded. We can't build a sound model on suggestive notation that is not well founded and which does not scale up. The new notation is absolutely clear and similar to much previous notation in modeling even before OO modeling. It is also close to a traditional program, so I don't think most users should have a hard time following it. Even nonprogrammers have seen examples (in product manuals and other things) of structure text of the form IF xxx do this ... ELSE do this So even non techies are familiar with this kind of structure. The branching lifeline notation, however, was confusing for everybody. Backward compatibility is raised far too often in this forum as a justification for keeping flawed constructs. There is a good argument that previous constructs should not be changed arbitrarily just for the sake of change. On the other hand, it is the purpose of a new version of a standard to repair and replace flawed constructs, and they should not be preserved if they can be replaced by sound constructs that are equally easy to use (which is the case for the new alt and loop constructs). The old branching lifeline constructs were seriously flawed technically and visually. The new constructs are sound and scalable. Let's not put the bad ones back in. - Jim Rumbaugh -- Dr. Oystein Haugen Associate Professor Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo Norway Tel: +47 22 85 27 37 (office) Tel: +47 913 90 914 (mobile) http://folk.uio.no/oysteinh Disposition: Unresolved