Issue 6264: Recommendation for InteractionOccurrences (uml2-superstructure-ftf) Source: Northrop Grumman (Dr. Brian Willard, nobody) Nature: Uncategorized Issue Severity: Summary: Recommend for InteractionOccurrences be equated to ActivityNodes of Activity Diagrams rather than ObjectNodes as currently specified. This spec reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447): Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions Interaction Overview Diagrams differ from Activity Diagrams in some respects. 1. In place of ObjectNodes of Activity Diagrams, Interaction Overview Diagrams can only have either (inline) Interactions or InteractionOccurrences. Inline Interaction diagrams and InteractionOccurrences are considered special forms of ActivityInvocations. Resolution: Revised Text: Actions taken: September 26, 2003: received issue March 9, 2005: closed issue Discussion: While the motivation for this suggestion is understandable, the proble m is that, despite the conceptual and notational similarities between activity flows and the flows shown in Interaction Overview Diagrams, the two are semantically distinct. Thus a flow in activity diagrams assumes token flow semantics, the semantics of flows represented in interaction overview diagrams are different (i.e., each lifeline has its own token and the tokens of different lifelines are not synchronized necessarily and can move at different speeds). Hence, despite its intuitive appeal, this recommendation is inappropriate. Disposition: Closed, no change End of Annotations:===== m: "Willard, Brian" To: "'issues@omg.org'" Subject: UML Superstructure 03-08-02 Date: Fri, 26 Sep 2003 07:06:51 -0700 X-Mailer: Internet Mail Service (5.5.2656.59) Recommend for InteractionOccurrences be equated to ActivityNodes of Activity Diagrams rather than ObjectNodes as currently specified. This spec reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447): Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions Interaction Overview Diagrams differ from Activity Diagrams in some respects. 1. In place of ObjectNodes of Activity Diagrams, Interaction Overview Diagrams can only have either (inline) Interactions or InteractionOccurrences. Inline Interaction diagrams and InteractionOccurrences are considered special forms of ActivityInvocations. Brian Willard System Engineer Northrop Grumman, AGS/BMS From: "Willard, Brian" To: "'uml2-superstructure-ftf@omg.org'" Subject: Issue 6264 comments Date: Wed, 8 Oct 2003 09:00:21 -0700 X-Mailer: Internet Mail Service (5.5.2656.59) Further recommendation: Wouldn't InteractionOverview Diagrams be more expressive and serve greater utility if they were simply defined as a variant of Activity Diagrams where (inline) Interactions or InteractionOccurrences equate to ActivityNodes? This retains the full expressive power of Activity Diagrams and further allows the behavior of an ActivityNode to be specified via an Interactions. Special treatment would apply when activity partitions apear in the diagram. The lifelines of Interactions must then be restricted to parts of the structured classifier represented by the swimlane. Source: Northrop Grumman (Dr. Brian Willard, brian.willard@ngc.com ) Nature: Uncategorized Issue Severity: Summary: Recommend for InteractionOccurrences be equated to ActivityNodes of Activity Diagrams rather than ObjectNodes as currently specified. This spec reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447): Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions Interaction Overview Diagrams differ from Activity Diagrams in some respects. 1. In place of ObjectNodes of Activity Diagrams, Interaction Overview Diagrams can only have either (inline) Interactions or InteractionOccurrences. Inline Interaction diagrams and InteractionOccurrences are considered special forms of ActivityInvocations. X-Sybari-Space: 00000000 00000000 00000000 00000000 From: Øystein Haugen (AS/ETO) To: "'Willard, Brian'" , "'uml2-superstructure-ftf@omg.org'" Subject: RE: ,ia, Issue 6264 comments Date: Wed, 8 Oct 2003 20:08:48 +0200 X-Mailer: Internet Mail Service (5.5.2653.19) Brian As responsible for the Interactions chapter originally, I have a few comments. An Interaction Overview Diagram defines an Interaction, not an Activity. Unfortunately this is important since the different variants of Behavior have different semantic models (but they all relate somewhat to the execution model of Common Behavior). Thus the story behind Interaction Overview Diagrams is the following. We use the _surface syntax_ of Activity Diagrams to depict dependencies between interaction entities (either inline Interactions or Interaction occurrences). By restricting which syntactic constructs to use, the transformation from Interaction Overview Diagram syntax to Sequence Diagram syntax is reasonably simple. In the (metamodel) repository it becomes an Interaction with CombinedFragments and InteractionOccurrences. On the other hand, Activity Diagrams can refer to other kinds of Behavior and as such refer to Interactions (or State Machines) as nodes. The resulting model is then an Activity. I do understand why you may be a little confused since you correctly point out that we have used metaclass names "ObjectNode" for something that actually refers to surface syntax which "by accident" coincide with symbols of Activity Diagrams. I should have been more careful to try and denote the symbols rather than the metamodel classes. Thanks, Oystein Haugen Oystein Haugen, dr. scient. Ericsson NorARC Lensmannslia 4 N-1362 Asker, Norway tel: +47 452 49493 > -----Original Message----- > From: Willard, Brian [mailto:brian.willard@ngc.com] > Sent: 8. oktober 2003 18:00 > To: 'uml2-superstructure-ftf@omg.org' > Subject: Issue 6264 comments > > > Further recommendation: Wouldn't InteractionOverview Diagrams be more > expressive and serve greater utility if they were simply defined as a > variant of Activity Diagrams where (inline) Interactions or > InteractionOccurrences equate to ActivityNodes? This retains the full > expressive power of Activity Diagrams and further allows the > behavior of an > ActivityNode to be specified via an Interactions. > Special treatment would apply when activity partitions apear > in the diagram. > The lifelines of Interactions must then be restricted to parts of the > structured classifier represented by the swimlane. > > Source: Northrop Grumman (Dr. Brian Willard, > brian.willard@ngc.com brian.willard@ngc.com>) > Nature: Uncategorized Issue > Severity: > Summary: > Recommend for InteractionOccurrences be equated to > ActivityNodes of Activity > Diagrams rather than ObjectNodes as currently specified. This spec > reference for this is: UML Superstructure 03-08-02 Chapter 14 > (on page 447): > > > Interaction Overview Diagrams are specialization of Activity > Diagrams that > represent Interactions Interaction Overview Diagrams differ > from Activity > Diagrams in some respects. > 1. In place of ObjectNodes of Activity Diagrams, Interaction Overview > Diagrams can only have either (inline) Interactions or > InteractionOccurrences. Inline Interaction diagrams and > InteractionOccurrences are considered special forms of > ActivityInvocations. > Date: Thu, 09 Oct 2003 22:46:16 +0100 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: "Øystein Haugen (AS/ETO)" CC: "'Willard, Brian'" , "'uml2-superstructure-ftf@omg.org'" Subject: Re: ,ia, Issue 6264 comments Oystein, Perhaps this suggestion is out of scope for the FTF, but it does seem desirable from both a pragmatic and a semantic perspective. Interaction Overview Diagrams can not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. Activities are mapped to Behaviors, and Interactions are just one such Behavior. It would make Interaction Overview diagrams more flexible, and they can be constrained by profiles if and as desired. Thanks, Guus Øystein Haugen (AS/ETO) wrote: Brian As responsible for the Interactions chapter originally, I have a few comments. An Interaction Overview Diagram defines an Interaction, not an Activity. Unfortunately this is important since the different variants of Behavior have different semantic models (but they all relate somewhat to the execution model of Common Behavior). Thus the story behind Interaction Overview Diagrams is the following. We use the _surface syntax_ of Activity Diagrams to depict dependencies between interaction entities (either inline Interactions or Interaction occurrences). By restricting which syntactic constructs to use, the transformation from Interaction Overview Diagram syntax to Sequence Diagram syntax is reasonably simple. In the (metamodel) repository it becomes an Interaction with CombinedFragments and InteractionOccurrences. On the other hand, Activity Diagrams can refer to other kinds of Behavior and as such refer to Interactions (or State Machines) as nodes. The resulting model is then an Activity. I do understand why you may be a little confused since you correctly point out that we have used metaclass names "ObjectNode" for something that actually refers to surface syntax which "by accident" coincide with symbols of Activity Diagrams. I should have been more careful to try and denote the symbols rather than the metamodel classes. Thanks, Oystein Haugen Oystein Haugen, dr. scient. Ericsson NorARC Lensmannslia 4 N-1362 Asker, Norway tel: +47 452 49493 -----Original Message----- From: Willard, Brian [mailto:brian.willard@ngc.com] Sent: 8. oktober 2003 18:00 To: 'uml2-superstructure-ftf@omg.org' Subject: Issue 6264 comments Further recommendation: Wouldn't InteractionOverview Diagrams be more expressive and serve greater utility if they were simply defined as a variant of Activity Diagrams where (inline) Interactions or InteractionOccurrences equate to ActivityNodes? This retains the full expressive power of Activity Diagrams and further allows the behavior of an ActivityNode to be specified via an Interactions. Special treatment would apply when activity partitions apear in the diagram. The lifelines of Interactions must then be restricted to parts of the structured classifier represented by the swimlane. Source: Northrop Grumman (Dr. Brian Willard, brian.willard@ngc.com ) Nature: Uncategorized Issue Severity: Summary: Recommend for InteractionOccurrences be equated to ActivityNodes of Activity Diagrams rather than ObjectNodes as currently specified. This spec reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447): Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions Interaction Overview Diagrams differ from Activity Diagrams in some respects. 1. In place of ObjectNodes of Activity Diagrams, Interaction Overview Diagrams can only have either (inline) Interactions or InteractionOccurrences. Inline Interaction diagrams and InteractionOccurrences are considered special forms of ActivityInvocations. -- _____________________________________________________________ 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" , "Øystein Haugen \(AS/ETO\)" Cc: "'Willard, Brian'" , Subject: RE: ,ia, Issue 6264 comments Date: Fri, 10 Oct 2003 07:50:18 +0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal But the semantics of interaction overview diagrams is nothing like the semantics of activity diagrams.... Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. All the best, Th. > -----Original Message----- > From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] > > Perhaps this suggestion is out of scope for the FTF, but it does seem > desirable from both a pragmatic and a semantic perspective. > Interaction Overview Diagrams can not only use the _surface syntax_ of > activity diagrams, but also the _semantic metamodel_ of activities. > Activities are mapped to Behaviors, and Interactions are just one such > Behavior. > Date: Fri, 10 Oct 2003 12:28:02 +0100 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: Thomas Weigert CC: "Øystein Haugen (AS/ETO)" , "'Willard, Brian'" , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, Issue 6264 comments Thomas, I didn't say it was a small job ("Perhaps this suggestion is out of scope for the FTF") > Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. There's two solutions to this 1. constrain such mixed usage 2. make it work: All of these things are Behaviors with Parameters (in/out), and it should be possible to mix the invocation of different behaviors. It was one of the goals of UML2 to have better defined abstractions for behavior. Perhaps we started with that but need to consolidate further. In terms of a usage example, think of a business process where the behavior invocations are actions for simple steps, and an interaction where the application behavior is complex. Thanks, Guus Thomas Weigert wrote: But the semantics of interaction overview diagrams is nothing like the semantics of activity diagrams.... Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. All the best, Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Perhaps this suggestion is out of scope for the FTF, but it does seem desirable from both a pragmatic and a semantic perspective. Interaction Overview Diagrams can not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. Activities are mapped to Behaviors, and Interactions are just one such Behavior. -- _____________________________________________________________ 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 :wq er-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Mon, 13 Oct 2003 13:19:44 -0400 Subject: Re: ,ia, Issue 6264 comments From: James Odell To: CC: "Oystein Haugen (AS/ETO)" , "'Willard, Brian'" UML 1.x Sequence Diagrams might have been interpreted a “extensional.” However, UML 2.0 Sequence Diagrams can seen as “intensional” as Activity Diagram. The UML 2.0 Sequence Diagram semantics are now strong enough to enable them to be executable. In fact, KlocWorks from Ottawa has a tool that can do just that. So, I am not so sure that this distinction is appropriate here. -Jim On 10/11/03 5:08 AM, Thomas Weigert scribed: I think you are delving into research here... It is not at all clear whether it is possible to combine these behavior descriptions in such simplistic manner. Sequence diagrams describe behavior in an extensional manner, that is by enumerating the set of possible traces. (Thus typically you don't just have a single diagram but a---sometimes rather large---set of sequence diagrams that together describe the desired behavior.) The other description techniques supported by UML are intensional, i.e., they describe an abstract machine that induces a set of traces. It might be possible to mix and match, but this is unchartered territory. Moreover, the dynamic semantics of UML is hardly defined at all, so you might have difficulty even stating the meaning of mixing these descriptions.... Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Friday, October 10, 2003 7:28 PM To: Thomas Weigert Cc: Øystein Haugen (AS/ETO); 'Willard, Brian'; uml2-superstructure-ftf@omg.org Subject: Re: ,ia, Issue 6264 comments Thomas, I didn't say it was a small job ("Perhaps this suggestion is out of scope for the FTF") > Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. There's two solutions to this 1. constrain such mixed usage 2. make it work: All of these things are Behaviors with Parameters (in/out), and it should be possible to mix the invocation of different behaviors. It was one of the goals of UML2 to have better defined abstractions for behavior. Perhaps we started with that but need to consolidate further. In terms of a usage example, think of a business process where the behavior invocations are actions for simple steps, and an interaction where the application behavior is complex. Thanks, Guus Thomas Weigert wrote: But the semantics of interaction overview diagrams is nothing like the semantics of activity diagrams.... Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. All the best, Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Perhaps this suggestion is out of scope for the FTF, but it does seem desirable from both a pragmatic and a semantic perspective. Interaction Overview Diagrams can not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. Activities are mapped to Behaviors, and Interactions are just one such Behavior. To: James Odell Cc: "'Willard, Brian'" , "Oystein Haugen (AS/ETO)" , uml2-superstructure-ftf@omg.org Subject: Re: ,ia, Issue 6264 comments X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 13 Oct 2003 13:30:35 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/13/2003 13:30:42, Serialize complete at 10/13/2003 13:30:42 I agree with Jim. I had this argument many years ago with a lady who claimed that it is quite feasible and reasonable to specify system the complete behavior of a system in terms of MSCs (in fact, it is merely a form of procedural programming) -- at least for a large category of useful systems. After some reflection, I had to agree with her. It is generally speaking not very suitable for event driven systems, but not all systems fall into that category. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com James Odell 10/13/2003 01:19 PM To: cc: "Oystein Haugen (AS/ETO)" , "'Willard, Brian'" Subject: Re: ,ia, Issue 6264 comments UML 1.x Sequence Diagrams might have been interpreted a “extensional.” However, UML 2.0 Sequence Diagrams can seen as “intensional” as Activity Diagram. The UML 2.0 Sequence Diagram semantics are now strong enough to enable them to be executable. In fact, KlocWorks from Ottawa has a tool that can do just that. So, I am not so sure that this distinction is appropriate here. -Jim On 10/11/03 5:08 AM, Thomas Weigert scribed: I think you are delving into research here... It is not at all clear whether it is possible to combine these behavior descriptions in such simplistic manner. Sequence diagrams describe behavior in an extensional manner, that is by enumerating the set of possible traces. (Thus typically you don't just have a single diagram but a---sometimes rather large---set of sequence diagrams that together describe the desired behavior.) The other description techniques supported by UML are intensional, i.e., they describe an abstract machine that induces a set of traces. It might be possible to mix and match, but this is unchartered territory. Moreover, the dynamic semantics of UML is hardly defined at all, so you might have difficulty even stating the meaning of mixing these descriptions.... Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Friday, October 10, 2003 7:28 PM To: Thomas Weigert Cc: Øystein Haugen (AS/ETO); 'Willard, Brian'; uml2-superstructure-ftf@omg.org Subject: Re: ,ia, Issue 6264 comments Thomas, I didn't say it was a small job ("Perhaps this suggestion is out of scope for the FTF") > Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. There's two solutions to this 1. constrain such mixed usage 2. make it work: All of these things are Behaviors with Parameters (in/out), and it should be possible to mix the invocation of different behaviors. It was one of the goals of UML2 to have better defined abstractions for behavior. Perhaps we started with that but need to consolidate further. In terms of a usage example, think of a business process where the behavior invocations are actions for simple steps, and an interaction where the application behavior is complex. Thanks, Guus Thomas Weigert wrote: But the semantics of interaction overview diagrams is nothing like the semantics of activity diagrams.... Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. All the best, Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Perhaps this suggestion is out of scope for the FTF, but it does seem desirable from both a pragmatic and a semantic perspective. Interaction Overview Diagrams can not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. Activities are mapped to Behaviors, and Interactions are just one such Behavior. Subject: RE: ,ia, Issue 6264 comments Date: Mon, 13 Oct 2003 15:54:04 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, Issue 6264 comments thread-index: AcORrtpyFswaywnBRniBCxsvhAQjuAAAsU7O From: "Nikolai Mansurov" To: "James Odell" , Cc: "Oystein Haugen (AS/ETO)" , "Willard, Brian" Dear Colleagues, Issue 6264 can be the most controversial one on the plate - I'm happy that the discussion is on. Let me summarize the points so far. The proposal it to treat InteractionOccurences as ActivityNodes of ActivityDiagrams rather than ObjectNodes as currently specified. This requires consolidation of the semantics of Interaction Overview Diagrams with the semantics of Activity Diagrams. Arguments "pro": - Interaction Overview Diagrams become more expressive and more useful (Brian) - This further allows specifying behavior of ActivityNodes via Interactions (Brian) - Interaction Overview Diagrams will not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. (Guus) - deliver on one of the goals of UML2 - better defined abstractions for behavior (Guus). I can add also the following: - eliminate the situation where there are two similar-looking notations that mean different things and are used for different purposes. UML with a (semantically) uniform notation for activities and interaction overviews (provided this is achievable!) may have lower learning curve. - introduce the concept of "executable sequence diagrams" (my personal favorite :-) Arguments "contra": - semantics of interaction overview diagrams are different from the semantics of activity diagrams - consolidation requires some research (Oystein, Thomas) - "extensional" vs "intensional" semantics (Thomas) - it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. (Thomas) - this suggestion is out of scope for the FTF (Guus) I can add the following: - large amount of technical effort involved in rewriting the meta-model of the Interaction Overview Diagrams. It seems from the discussion, that many people believe that such consolidation is doable (however, there are no concrete proposals so far). As Oystein has mentioned in his reply, Activity Diagrams can refer to other kinds of Behavior and as such refer to Interactions (or State Machines) as nodes. The resulting model is then an Activity. Here are my two cents into the discussion. Klocwork indeed has a product that is aimed at "bridging the gap" between "intensional" semantics of (a variant of)Sequence Diagrams and Interaction Overview Diagrams into the "extensional" semantics (for example, of state machines) via transformations. Klocwork is advocating the idea of "executable sequence diagrams", where because of the tool-defined execution semantics, Sequence Diagrams composed by Interaction Occurence Diagrams can serve as executable prototypes of the system under definition. Such notation is useful for example for systems engineering and requirements modeling, although requires more formal approach than UML 1.4. Klocwork does NOT have a solution to semantically consolidated Interaction Overview Diagrams and Activity Diagrams, since our product uses Interaction Overview Diagrams semantics. I agree with Thomas, that the effort in consolidating Interaction Overview Diagrams with ActivityDiagrams may be quite significant and some research is required. In particular, in our experience with executable Sequence Diagrams and Interaction Overview Diagrams, there may be some outstanding issues in the integrated treatment of guards, InteractionFragment and data. Pragmatically (effort required, timeline remaining compared to expected gains), it is easier to introduce Interaction Overview Diagrams as it is done now, and defer the consolidation until the next revision of UML 2.0. I agree with Guus, that such change is outside of the scope of the FTF, at least in the effort involved. (This is by no means intended to close the discussion on issue 6264 - just an intermediate summary plus my "two cents"). Best regards, Nikolai -----Original Message----- From: James Odell [mailto:email@jamesodell.com] Sent: Mon 10/13/2003 1:19 PM To: uml2-superstructure-ftf@omg.org Cc: Oystein Haugen (AS/ETO); 'Willard, Brian' Subject: Re: ,ia, Issue 6264 comments UML 1.x Sequence Diagrams might have been interpreted a “extensional.” However, UML 2.0 Sequence Diagrams can seen as “intensional” as Activity Diagram. The UML 2.0 Sequence Diagram semantics are now strong enough to enable them to be executable. In fact, KlocWorks from Ottawa has a tool that can do just that. So, I am not so sure that this distinction is appropriate here. -Jim On 10/11/03 5:08 AM, Thomas Weigert scribed: I think you are delving into research here... It is not at all clear whether it is possible to combine these behavior descriptions in such simplistic manner. Sequence diagrams describe behavior in an extensional manner, that is by enumerating the set of possible traces. (Thus typically you don't just have a single diagram but a---sometimes rather large---set of sequence diagrams that together describe the desired behavior.) The other description techniques supported by UML are intensional, i.e., they describe an abstract machine that induces a set of traces. It might be possible to mix and match, but this is unchartered territory. Moreover, the dynamic semantics of UML is hardly defined at all, so you might have difficulty even stating the meaning of mixing these descriptions.... Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Friday, October 10, 2003 7:28 PM To: Thomas Weigert Cc: Øystein Haugen (AS/ETO); 'Willard, Brian'; uml2-superstructure-ftf@omg.org Subject: Re: ,ia, Issue 6264 comments Thomas, I didn't say it was a small job ("Perhaps this suggestion is out of scope for the FTF") > Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. There's two solutions to this 1. constrain such mixed usage 2. make it work: All of these things are Behaviors with Parameters (in/out), and it should be possible to mix the invocation of different behaviors. It was one of the goals of UML2 to have better defined abstractions for behavior. Perhaps we started with that but need to consolidate further. In terms of a usage example, think of a business process where the behavior invocations are actions for simple steps, and an interaction where the application behavior is complex. Thanks, Guus Thomas Weigert wrote: But the semantics of interaction overview diagrams is nothing like the semantics of activity diagrams.... Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. All the best, Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Perhaps this suggestion is out of scope for the FTF, but it does seem desirable from both a pragmatic and a semantic perspective. Interaction Overview Diagrams can not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. Activities are mapped to Behaviors, and Interactions are just one such Behavior. Reply-To: From: "Conrad Bock" To: "Branislav Selic" , "James Odell" Cc: "'Willard, Brian'" , "Oystein Haugen \(AS/ETO\)" , Subject: RE: ,ia, Issue 6264 comments Date: Mon, 13 Oct 2003 18:18:12 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id h9DMDxQR004924 Jim, Bran, > [Jim] UML 1.x Sequence Diagrams might have been interpreted a > "extensional", However, UML 2.0 Sequence Diagrams can seen as > "intensional" as Activity Diagram. The UML 2.0 Sequence Diagram > semantics are now strong enough to enable them to be executable. In > fact, KlocWorks from Ottawa has a tool that can do just that. So, I > am not so sure that this distinction is appropriate here. > [Bran] I agree with Jim. I had this argument many years ago with a > lady who claimed that it is quite feasible and reasonable to specify > system the complete behavior of a system in terms of MSCs (in fact, > it is merely a form of procedural programming) -- at least for a > large category of useful systems. After some reflection, I had to > agree with her. The above only applies to control contructs, but much more is needed for executability. I was under the impression that interactions were fairly limited in the kinds of actions they can model. Can they set property values, create and destroy links, etc? If they can, then we have some serious overlap in functionality with the action model! Conrad To: Cc: "'Willard, Brian'" , "James Odell" , "Oystein Haugen \(AS/ETO\)" , uml2-superstructure-ftf@omg.org Subject: RE: ,ia, Issue 6264 comments X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 13 Oct 2003 18:37:01 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/13/2003 18:37:06, Serialize complete at 10/13/2003 18:37:06 One of the ways that we are using interactions is to model Java methods. In the process, we are uncovering a small number remaining holes such as the ones that you list. I am not sure what your concern is, I see the two as complementary: interactions talk about communications and AS about what causes that. I don't see any problem here. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Conrad Bock" 10/13/2003 06:18 PM Please respond to conrad.bock To: Branislav Selic/Ottawa/IBM@IBMCA, "James Odell" cc: "'Willard, Brian'" , "Oystein Haugen \(AS/ETO\)" , Subject: RE: ,ia, Issue 6264 comments Jim, Bran, > [Jim] UML 1.x Sequence Diagrams might have been interpreted a > "extensional", However, UML 2.0 Sequence Diagrams can seen as > "intensional" as Activity Diagram. The UML 2.0 Sequence Diagram > semantics are now strong enough to enable them to be executable. In > fact, KlocWorks from Ottawa has a tool that can do just that. So, I > am not so sure that this distinction is appropriate here. > [Bran] I agree with Jim. I had this argument many years ago with a > lady who claimed that it is quite feasible and reasonable to specify > system the complete behavior of a system in terms of MSCs (in fact, > it is merely a form of procedural programming) -- at least for a > large category of useful systems. After some reflection, I had to > agree with her. The above only applies to control contructs, but much more is needed for executability. I was under the impression that interactions were fairly limited in the kinds of actions they can model. Can they set property values, create and destroy links, etc? If they can, then we have some serious overlap in functionality with the action model! Conrad Reply-To: From: "Conrad Bock" To: "Branislav Selic" , Cc: "'Willard, Brian'" , "James Odell" , "Oystein Haugen \(AS/ETO\)" , Subject: RE: ,ia, Issue 6264 comments Date: Mon, 13 Oct 2003 18:47:21 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Importance: Normal Bran, > I am not sure what your concern is, I see the two as complementary: > interactions talk about communications and AS about what causes > that. I don't see any problem here. This argues against your earlier point that you can program completely with interactions, which presumably means without activities/actions. > One of the ways that we are using interactions is to model Java > methods. In the process, we are uncovering a small number remaining > holes such as the ones that you list. If the plan is to expans interactions so that it has copies of all the actions in the action model, I would flag that as making the semantic overlap with activities/actions even worse than it is. Conrad To: Cc: "'Willard, Brian'" , conrad.bock@nist.gov, "James Odell" , "Oystein Haugen \(AS/ETO\)" , uml2-superstructure-ftf@omg.org Subject: RE: ,ia, Issue 6264 comments X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 13 Oct 2003 19:06:18 -0400 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 10/13/2003 19:06:24, Serialize complete at 10/13/2003 19:06:24 I don't believe that the idea is for interactions to repeat what action semantics already provides. Actions specify what individual objects do and interactions specify how two or more objects achieve some end-to-end objective by interacting. The interactions are the result of a subset of actions that deal with communications as well as object creation and destruction. Hence, in my mind, they are complementary. An interaction model of a Java method describes the interactions of that method but relies on action semantics to specify the actions that result in interactions. However, I do believe that your point of needing to properly relate AS to interactions is an important objective. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Conrad Bock" 10/13/2003 06:47 PM Please respond to conrad.bock To: Branislav Selic/Ottawa/IBM@IBMCA, cc: "'Willard, Brian'" , "James Odell" , "Oystein Haugen \(AS/ETO\)" , Subject: RE: ,ia, Issue 6264 comments Bran, > I am not sure what your concern is, I see the two as complementary: > interactions talk about communications and AS about what causes > that. I don't see any problem here. This argues against your earlier point that you can program completely with interactions, which presumably means without activities/actions. > One of the ways that we are using interactions is to model Java > methods. In the process, we are uncovering a small number remaining > holes such as the ones that you list. If the plan is to expans interactions so that it has copies of all the actions in the action model, I would flag that as making the semantic overlap with activities/actions even worse than it is. Conrad Subject: RE: ,ia, Issue 6264 comments Date: Tue, 14 Oct 2003 12:49:34 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: ,ia, Issue 6264 comments thread-index: AcOR3x6wAiVNDrDZSxKVHMxQjA1mEwAihdOx From: "Nikolai Mansurov" To: "Branislav Selic" , Cc: "Willard, Brian" , , "James Odell" , "Oystein Haugen (AS/ETO)" , There is a certain overlap between action semantics and interactions. Once we have described how several objects interact (for example, using sequence diagrams and Interaction Overview Diagrams), it is possible to automatically derive the internal behavior of each object, such that the collection of objects, when assmebled, will reproduce the original behavior. Pragmatically, it is sufficient to provide an approximation of the original behavior: during requirements capturing it is unclear what is the bahvior that we are capturing anyway. There is certain duality between an inter-object specification (sequence diagrams, "one-story-for-all-objects") and intra-object specification (statecharts, "all-stories-for-one-object"). Another area where action semantics overlap with interaction is when data and conditions are used in inline expressions and guards in order to provide more complete (rather than exemplary) specification. In my experience, Sequence Diagrams plus Interaction Overview Diagrams plus Action Semantics (this is the combination of notations used in klocwork product) can be used as executable prototypes. The challenge is where exactly such executable semantics is introduced ? This can be done a) in the modeling language standard itself. Or this can be done separately in two ways: b) as an "executable" subset of the language; c) as tool vendor specific interpretation (tool accepts certain subset of models and "executes" such models, approximating the full semantics. What is the difference between a) and b) ? A non-executable semantics is more powerful, than executable one. Defining an executable semantics for Interaction Diagrams means that there is a single mapping between sequences of events in Interaction Diagrams and sequences of events in traces. In other words, a virtual machine. We indeed have such a virtual machine for Sequence Diagrams, including Interaction Overview Diagrams and data. In a non-executable semantic there can be more than one such mapping. For example, I can say, that a particular Sequence Diagram describes a scenario that should never happen. Non-executable semantics (too many possible scenarios are valid). With Executable Sequence Diagrams this is not possible, since there should be only one mapping to the implementation. I'm in favor of option b) above, in other words, not to restrict all interaction diagrams to have executable semantics, but to have a certain subset, that does. In the scope of Interaction Diagrams, these are rather big issues (maybe less so in the overall scope of UML 2 ?). In my opinion, such change is outside of the scope of the FTF. Cheers, Nick -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Mon 10/13/2003 7:06 PM To: conrad.bock@nist.gov Cc: 'Willard, Brian'; conrad.bock@nist.gov; James Odell; Oystein Haugen (AS/ETO); uml2-superstructure-ftf@omg.org Subject: RE: ,ia, Issue 6264 comments I don't believe that the idea is for interactions to repeat what action semantics already provides. Actions specify what individual objects do and interactions specify how two or more objects achieve some end-to-end objective by interacting. The interactions are the result of a subset of actions that deal with communications as well as object creation and destruction. Hence, in my mind, they are complementary. An interaction model of a Java method describes the interactions of that method but relies on action semantics to specify the actions that result in interactions. However, I do believe that your point of needing to properly relate AS to interactions is an important objective. Bran Selic IBM Software Group -- Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph. (613) 591-7915 fax (613) 599-3912 e-mail: bselic@ca.ibm.com "Conrad Bock" 10/13/2003 06:47 PM Please respond to conrad.bock To: Branislav Selic/Ottawa/IBM@IBMCA, cc: "'Willard, Brian'" , "James Odell" , "Oystein Haugen \(AS/ETO\)" , Subject: RE: ,ia, Issue 6264 comments Bran, > I am not sure what your concern is, I see the two as complementary: > interactions talk about communications and AS about what causes > that. I don't see any problem here. This argues against your earlier point that you can program completely with interactions, which presumably means without activities/actions. > One of the ways that we are using interactions is to model Java > methods. In the process, we are uncovering a small number remaining > holes such as the ones that you list. If the plan is to expans interactions so that it has copies of all the actions in the action model, I would flag that as making the semantic overlap with activities/actions even worse than it is. Conrad From: "Thomas Weigert" To: "Guus Ramackers" Cc: "=?us-ascii?Q?Oystein_Haugen_\=28AS/ETO\=29?=" , "'Willard, Brian'" , Subject: RE: ,ia, Issue 6264 comments Date: Sat, 11 Oct 2003 17:08:12 +0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal I think you are delving into research here... It is not at all clear whether it is possible to combine these behavior descriptions in such simplistic manner. Sequence diagrams describe behavior in an extensional manner, that is by enumerating the set of possible traces. (Thus typically you don't just have a single diagram but a---sometimes rather large---set of sequence diagrams that together describe the desired behavior.) The other description techniques supported by UML are intensional, i.e., they describe an abstract machine that induces a set of traces. It might be possible to mix and match, but this is unchartered territory. Moreover, the dynamic semantics of UML is hardly defined at all, so you might have difficulty even stating the meaning of mixing these descriptions.... Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Friday, October 10, 2003 7:28 PM To: Thomas Weigert Cc: Øystein Haugen (AS/ETO); 'Willard, Brian'; uml2-superstructure-ftf@omg.org Subject: Re: ,ia, Issue 6264 comments Thomas, I didn't say it was a small job ("Perhaps this suggestion is out of scope for the FTF") > Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. There's two solutions to this 1. constrain such mixed usage 2. make it work: All of these things are Behaviors with Parameters (in/out), and it should be possible to mix the invocation of different behaviors. It was one of the goals of UML2 to have better defined abstractions for behavior. Perhaps we started with that but need to consolidate further. In terms of a usage example, think of a business process where the behavior invocations are actions for simple steps, and an interaction where the application behavior is complex. Thanks, Guus Thomas Weigert wrote: But the semantics of interaction overview diagrams is nothing like the semantics of activity diagrams.... Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. All the best, Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Perhaps this suggestion is out of scope for the FTF, but it does seem desirable from both a pragmatic and a semantic perspective. Interaction Overview Diagrams can not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. Activities are mapped to Behaviors, and Interactions are just one such Behavior. -- _____________________________________________________________ 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: "Thomas Weigert" , "Guus Ramackers" Cc: "Oystein Haugen \(AS/ETO\)" , "'Willard, Brian'" , Subject: RE: ,ia, Issue 6264 comments Date: Mon, 13 Oct 2003 10:16:08 +0800 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Importance: Normal Guus, I don't mean to say that what you propose is not a good idea, in fact, it is very interesting. However, I think it goes beyond what we should be prepared to do in the FTF. I think this is a hard question to answer because of the fundamental difference of behavioral description and also because of the lack of semantic detail in the UML. All the best, Th. -----Original Message----- From: Thomas Weigert [mailto:Thomas.Weigert@motorola.com] Sent: Saturday, October 11, 2003 5:08 PM To: Guus Ramackers Cc: Oystein Haugen (AS/ETO); 'Willard, Brian'; uml2-superstructure-ftf@omg.org Subject: RE: ,ia, Issue 6264 comments I think you are delving into research here... It is not at all clear whether it is possible to combine these behavior descriptions in such simplistic manner. Sequence diagrams describe behavior in an extensional manner, that is by enumerating the set of possible traces. (Thus typically you don't just have a single diagram but a---sometimes rather large---set of sequence diagrams that together describe the desired behavior.) The other description techniques supported by UML are intensional, i.e., they describe an abstract machine that induces a set of traces. It might be possible to mix and match, but this is unchartered territory. Moreover, the dynamic semantics of UML is hardly defined at all, so you might have difficulty even stating the meaning of mixing these descriptions.... Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Sent: Friday, October 10, 2003 7:28 PM To: Thomas Weigert Cc: Øystein Haugen (AS/ETO); 'Willard, Brian'; uml2-superstructure-ftf@omg.org Subject: Re: ,ia, Issue 6264 comments Thomas, I didn't say it was a small job ("Perhaps this suggestion is out of scope for the FTF") > Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. There's two solutions to this 1. constrain such mixed usage 2. make it work: All of these things are Behaviors with Parameters (in/out), and it should be possible to mix the invocation of different behaviors. It was one of the goals of UML2 to have better defined abstractions for behavior. Perhaps we started with that but need to consolidate further. In terms of a usage example, think of a business process where the behavior invocations are actions for simple steps, and an interaction where the application behavior is complex. Thanks, Guus Thomas Weigert wrote: But the semantics of interaction overview diagrams is nothing like the semantics of activity diagrams.... Also, it will be quite difficult to explain the behavior of an activity diagram where some nodes are actions and some nodes are interactions. All the best, Th. -----Original Message----- From: Guus Ramackers [mailto:Guus.Ramackers@oracle.com] Perhaps this suggestion is out of scope for the FTF, but it does seem desirable from both a pragmatic and a semantic perspective. Interaction Overview Diagrams can not only use the _surface syntax_ of activity diagrams, but also the _semantic metamodel_ of activities. Activities are mapped to Behaviors, and Interactions are just one such Behavior. -- _____________________________________________________________ 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 OMG Issue No: 6264 Title: Recommendation for InteractionOccurrences Source: Northrop Grumman (Dr. Brian Willard, brian.willard@ngc.com) Summary: Recommend for InteractionOccurrences be equated to ActivityNodes of Activity Diagrams rather than ObjectNodes as currently specified. This spec reference for this is: UML Superstructure 03-08-02 Chapter 14 (on page 447): Interaction Overview Diagrams are specialization of Activity Diagrams that represent Interactions Interaction Overview Diagrams differ from Activity Diagrams in some respects. 1. In place of ObjectNodes of Activity Diagrams, Interaction Overview Diagrams can only have either (inline) Interactions or InteractionOccurrences. Inline Interaction diagrams and InteractionOccurrences are considered special forms of ActivityInvocations. Discussion: While the motivation for this suggestion is understandable, the problem is that, despite the conceptual and notational similarities between activity flows and the flows shown in Interaction Overview Diagrams, the two are semantically distinct. Thus a flow in activity diagrams assumes token flow semantics, the semantics of flows represented in interaction overview diagrams are different (i.e., each lifeline has its own token and the tokens of different lifelines are not synchronized necessarily and can move at different speeds). Hence, despite its intuitive appeal, this recommendation is inappropriate. Disposition: Closed, no change 321.951.5281