Issue 13263: Support BDD's for State Machines (sysml-rtf) Source: Change Vision (Mr. Michael Jesse Chonoles, mjchonoles(at)yahoo.com) Nature: Uncategorized Issue Severity: Summary: One very powerful organizational technique of SysML is the pairing of definitional diagrams with usage diagrams BDD (for Blocks) à IBDs BDD (for Activities) à ACTs BDD (for Constraint Blocks) à PARs The BDD form identifies the elements (structural, functional, constraint) and the 2nd form assembles the elements using detailed design techniques suitable for the element form. It would be convenient and symmetric to support a similar diagram ppar for State Machnies BDD(for States) àSTMs In the past, Class diagrams for States (in UML 1.x) were used. However, it appears that UML 2.x has deleted the ability to use inheritance relationships among states. Though we could look to UML to fix this, I believe it is possible to model state->substate relationships as compositions without a change to UML to produce a satisfactory conclusion. Resolution: Defer Postponed to the next RTF Revised Text: Actions taken: January 15, 2009: received issue January 3, 2017: Deferred April 6, 2017: closed issue Discussion: This issue is being deferred because no proposed resolution was voted on during the schedule of the SysML 1.3 RTF. Disposition: Deferred End of Annotations:===== te: Thu, 15 Jan 2009 07:21:21 -0500 From: "Chonoles, Michael J" Subject: SysML: Support BDD's for State Machines To: issues@omg.org Thread-Topic: SysML: Support BDD's for State Machines Thread-Index: Acl3C8Tk4biQoHOSS7efc7WlwwqPrQ== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 15 Jan 2009 12:21:23.0672 (UTC) FILETIME=[C7C56D80:01C9770B] One very powerful organizational technique of SysML is the pairing of definitional diagrams with usage diagrams BDD (for Blocks) à IBDs BDD (for Activities) à ACTs BDD (for Constraint Blocks) à PARs The BDD form identifies the elements (structural, functional, constraint) and the 2nd form assembles the elements using detailed design techniques suitable for the element form. It would be convenient and symmetric to support a similar diagram ppar for State Machnies BDD(for States) àSTMs In the past, Class diagrams for States (in UML 1.x) were used. However, it appears that UML 2.x has deleted the ability to use inheritance relationships among states. Though we could look to UML to fix this, I believe it is possible to model state->substate relationships as compositions without a change to UML to produce a satisfactory conclusion. Michael Chonoles Lockheed Martin X-SENDER-IP: 10.37.193.66 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.40,296,1238976000"; d="doc'32?scan'32,208,32";a="22950785" X-SENDER-IP: 129.86.8.18 X-SENDER-REPUTATION: None X-IronPort-AV: E=Sophos;i="4.40,296,1238976000"; d="doc'32?scan'32,208,32";a="38971484" Subject: Potential Resolution for Issue 13263 Date: Tue, 5 May 2009 08:07:47 -0400 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnNehrv/fwgSM27S/m3sa0WlNGKow== From: "Sawyer, George A \(US SSA\)" To: X-OriginalArrivalTime: 05 May 2009 12:07:48.0124 (UTC) FILETIME=[1B1B2DC0:01C9CD7A] Good Morning, Time permitting, I would like to discuss the following proposed resolution for BDDs for state machines at this week's telecon. <> My expectation is that the discussion should require no more than 5 minutes or so. Regards, George Sawyer BAE SYSTEMS Recommended Resolutions for 13263.doc Date: Tue, 05 May 2009 08:46:19 -0400 From: "Chonoles, Michael J" Subject: RE: Potential Resolution for Issue 13263 To: "Sawyer, George A (US SSA)" , sysml-rtf@omg.org, issues@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnNehrv/fwgSM27S/m3sa0WlNGKowAAnscw X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 05 May 2009 12:47:00.0439 (UTC) FILETIME=[9531F670:01C9CD7F] Hi everyone, I'm back (from short term disability) I appreciate your work. However, my thinking is that 1) We don't need an explicit IBD notation. As with activity/parametric diagrams, the equivalent of the IBD is the activity diagram notation itself (or parametric diagram). I would expect to see a stereotyped diagram usages of a BDD for the state machine, tied to the state machine diagram. 2) While diagrammatically a state machine has substates visually contained in their superstates, the actual relationship is more of generalization. Any ongoing do/activity, or event/action pairs defined in a superstate is inherited by the substates unless overridden. Generalization is normally disjoint, except for when explicitly indicated as overlapping. I believe all the fancy generalization keywords (such as discriminators) would apply. Entry/exit actions are not inherited, but are more like the way constructors/destructors work -- "outside-in" going into the substates and inside-out leaving. 3) I haven't yet thought it completely through, but submachines are more of an aggregation situation and can have multiplicity. 4) Using this class diagram approach for state machines has a long history and was originally pushed by Jim Rumbaugh. 5) The advantage of this alternative notation is a) Parallel understanding and simplicity-- there's always a bdd-specially diagram. The current irregularity always comes up when I'm teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a BDD-PAR, and the class logically asks what about BDD-STM. I teach many SysML courses, and it would make the student's understand better, feel that the languages was logically designed. b) State machine notation is not always easy to understand. I've found that the equivalent BDD/class diagram approach for showing the state structure was easier --- especially once I had taught the BDD notation. It highlights the complex inheritance relationships among event/action pairs, etc. Michael Jesse Chonoles LMCO -----Original Message----- From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] Sent: Tuesday, May 05, 2009 8:08 AM To: sysml-rtf@omg.org Subject: Potential Resolution for Issue 13263 Good Morning, Time permitting, I would like to discuss the following proposed resolution for BDDs for state machines at this week's telecon. <> My expectation is that the discussion should require no more than 5 minutes or so. Regards, George Sawyer BAE SYSTEMS Subject: RE: Potential Resolution for Issue 13263 Date: Tue, 5 May 2009 20:42:58 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Potential Resolution for Issue 13263 thread-index: AcnNehrv/fwgSM27S/m3sa0WlNGKowANwmeQ From: "Tim Weilkiens" To: "Sawyer, George A (US SSA)" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n45IgAlg026944 Maybe I missed previous discussions. But I don't understand the motivation of this resolution. Which current problem with SysML will be resolved? Tim > -----Original Message----- > From: Sawyer, George A (US SSA) > [mailto:george.a.sawyer@baesystems.com] > Sent: Tuesday, May 05, 2009 2:08 PM > To: sysml-rtf@omg.org > Subject: Potential Resolution for Issue 13263 > > Good Morning, > > Time permitting, I would like to discuss the following > proposed resolution for BDDs for state machines at this > week's telecon. > > <> > > My expectation is that the discussion should require no more > than 5 minutes or so. > > Regards, > George Sawyer > BAE SYSTEMS > > > > Date: Tue, 05 May 2009 15:08:58 -0400 From: "Chonoles, Michael J" Subject: RE: Potential Resolution for Issue 13263 To: Tim Weilkiens , "Sawyer, George A (US SSA)" , sysml-rtf@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnNehrv/fwgSM27S/m3sa0WlNGKowANwmeQAADIY4A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 05 May 2009 19:09:36.0824 (UTC) FILETIME=[08445380:01C9CDB5] Tim SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My students complain that we're missing BDD-->STM. A state machine modeling approach using Class diagrams was proposed by Jim Rumbaugh and was popular as it clarifies the inheritance of state features. (In addition, it shows a possible way of implementing state machines using and OO approach -- though this is not relevant to SysML). It would be relavitivy easy to do (possibly easier than BDD-->:ACT) and would greatly improve the understanding of SysML. It would address some of the comments that I get that SysML seems to be an ad-hoc notation, with little consistency. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 05, 2009 2:43 PM To: Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Maybe I missed previous discussions. But I don't understand the motivation of this resolution. Which current problem with SysML will be resolved? Tim > -----Original Message----- > From: Sawyer, George A (US SSA) > [mailto:george.a.sawyer@baesystems.com] > Sent: Tuesday, May 05, 2009 2:08 PM > To: sysml-rtf@omg.org > Subject: Potential Resolution for Issue 13263 > > Good Morning, > > Time permitting, I would like to discuss the following > proposed resolution for BDDs for state machines at this > week's telecon. > > <> > > My expectation is that the discussion should require no more > than 5 minutes or so. > > Regards, > George Sawyer > BAE SYSTEMS > > > > Subject: RE: Potential Resolution for Issue 13263 Date: Tue, 5 May 2009 21:19:49 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Potential Resolution for Issue 13263 thread-index: AcnNehrv/fwgSM27S/m3sa0WlNGKowANwmeQAADIY4AAAIgMQA== From: "Tim Weilkiens" To: "Chonoles, Michael J" , "Sawyer, George A (US SSA)" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n45JL3H8004582 Michael, thanks for clarification. Tim > -----Original Message----- > From: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] > Sent: Tuesday, May 05, 2009 9:09 PM > To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Tim > SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My > students complain that we're missing BDD-->STM. A state > machine modeling approach using Class diagrams was proposed > by Jim Rumbaugh and was popular as it clarifies the > inheritance of state features. (In addition, it shows a > possible way of implementing state machines using and OO > approach -- though this is not relevant to SysML). It would > be relavitivy easy to do (possibly easier than BDD-->:ACT) > and would greatly improve the understanding of SysML. It > would address some of the comments that I get that SysML > seems to be an ad-hoc notation, with little consistency. > > Michael > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, May 05, 2009 2:43 PM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Maybe I missed previous discussions. But I don't understand > the motivation of this resolution. Which current problem with > SysML will be resolved? > > Tim > > > -----Original Message----- > > From: Sawyer, George A (US SSA) > > [mailto:george.a.sawyer@baesystems.com] > > Sent: Tuesday, May 05, 2009 2:08 PM > > To: sysml-rtf@omg.org > > Subject: Potential Resolution for Issue 13263 > > > > Good Morning, > > > > Time permitting, I would like to discuss the following proposed > > resolution for BDDs for state machines at this week's telecon. > > > > <> > > > > My expectation is that the discussion should require no more than 5 > > minutes or so. > > > > Regards, > > George Sawyer > > BAE SYSTEMS > > > > > > > > > Date: Tue, 05 May 2009 21:35:16 -0400 From: "Friedenthal, Sanford" Subject: RE: Potential Resolution for Issue 13263 To: "Sawyer, George A (US SSA)" , "Chonoles, Michael J" Cc: sysml-rtf@omg.org, issues@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnNehrv/fwgSM27S/m3sa0WlNGKowAAnscwABtxRIA= X-MS-Has-Attach: yes X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 May 2009 01:45:06.0383 (UTC) FILETIME=[482FADF0:01C9CDEC] George, Michael I think a state machine could appear on a bdd since it is a classifier like an activity. However, the individual states are not classifiers and therefore should not be depicted on a bdd like indicated. The reason the activity works is that the call actions and the activities they call have some similarity to parts. States do not have this equivalence. Sandy -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 8:46 AM To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org Subject: RE: Potential Resolution for Issue 13263 Hi everyone, I'm back (from short term disability) I appreciate your work. However, my thinking is that 1) We don't need an explicit IBD notation. As with activity/parametric diagrams, the equivalent of the IBD is the activity diagram notation itself (or parametric diagram). I would expect to see a stereotyped diagram usages of a BDD for the state machine, tied to the state machine diagram. 2) While diagrammatically a state machine has substates visually contained in their superstates, the actual relationship is more of generalization. Any ongoing do/activity, or event/action pairs defined in a superstate is inherited by the substates unless overridden. Generalization is normally disjoint, except for when explicitly indicated as overlapping. I believe all the fancy generalization keywords (such as discriminators) would apply. Entry/exit actions are not inherited, but are more like the way constructors/destructors work -- "outside-in" going into the substates and inside-out leaving. 3) I haven't yet thought it completely through, but submachines are more of an aggregation situation and can have multiplicity. 4) Using this class diagram approach for state machines has a long history and was originally pushed by Jim Rumbaugh. 5) The advantage of this alternative notation is a) Parallel understanding and simplicity-- there's always a bdd-specially diagram. The current irregularity always comes up when I'm teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a BDD-PAR, and the class logically asks what about BDD-STM. I teach many SysML courses, and it would make the student's understand better, feel that the languages was logically designed. b) State machine notation is not always easy to understand. I've found that the equivalent BDD/class diagram approach for showing the state structure was easier --- especially once I had taught the BDD notation. It highlights the complex inheritance relationships among event/action pairs, etc. Michael Jesse Chonoles LMCO -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 3:09 PM To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Tim SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My students complain that we're missing BDD-->STM. A state machine modeling approach using Class diagrams was proposed by Jim Rumbaugh and was popular as it clarifies the inheritance of state features. (In addition, it shows a possible way of implementing state machines using and OO approach -- though this is not relevant to SysML). It would be relavitivy easy to do (possibly easier than BDD-->:ACT) and would greatly improve the understanding of SysML. It would address some of the comments that I get that SysML seems to be an ad-hoc notation, with little consistency. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 05, 2009 2:43 PM To: Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Maybe I missed previous discussions. But I don't understand the motivation of this resolution. Which current problem with SysML will be resolved? Tim -----Original Message----- From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] Sent: Tuesday, May 05, 2009 8:08 AM To: sysml-rtf@omg.org Subject: Potential Resolution for Issue 13263 Good Morning, Time permitting, I would like to discuss the following proposed resolution for BDDs for state machines at this week's telecon. <> My expectation is that the discussion should require no more than 5 minutes or so. Regards, George Sawyer BAE SYSTEMS Recommended Resolutions for 132631.doc DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:received:in-reply-to :references:date:x-google-sender-auth:message-id:subject:from:to:cc :content-type; bh=8Zo1nMHHy26LwygtG4xPAqodovcSmTvRjcpQGiFc5Cc=; b=qHtdGc0bVdtsMINwLbRruJpQVupuIS0dWAtx+ZiWYNl/2p3D5ozPq0hCfMY47rEdvk CH1N45AlkStsrotVIyeOIHFuNFciIJ/cYxBhModqin6sOQ3ThemJMJk0fTC10s0rfmOy rVFDEPJsZHf5o56N9uEuPpdToXsVg57drbpNw= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:cc:content-type; b=gofXmAefzvNXtIjRV+mwZoYURcWO8DzH/APZxbsRjeUiZZ8IKLW8ElL/rKhz8PHe+8 zZIZVnLMDXN+mntKojJweIp3jsEzNEar9pffyXSsN5aqVHo//etiJfrovc5PfHio9F5V bHxsc+LB4hi+tCjI7kOTmNCapsynwr8IFi2Po= Sender: lonniev@gmail.com Date: Tue, 5 May 2009 22:32:09 -0600 X-Google-Sender-Auth: b7b5ac56efb97b2b Subject: Re: Potential Resolution for Issue 13263 From: Lonnie VanZandt To: "Friedenthal, Sanford" Cc: "Sawyer, George A (US SSA)" , "Chonoles, Michael J" , sysml-rtf@omg.org, issues@omg.org Michael, George, Can you elaborate on what problem this solution is resolving? Why doesn't it suffice to put a diagram frame header such as "stm [Block] MyDynamicBlock [the Hierarchical State Machine of MyDynamicBlock]" on a UML State Machine Diagram to make it look like SysML? What is it about a SysML State Machine that requires something different than a UML (Harel) state machine diagram? Viewing the proposal, I see something that is far too similar to a class or block structural diagram; however, a hierarchical state machine is not a structural composition, it is a behavioral aspect of a block/class. Yes, there are State Machine patterns which represent states as objects but there are also others which represent the states as behavioral properties (methods). The BDD/IBD as state diagram too strongly suggests that the states are structural properties. Also, looking at the IBD state diagram, one asks, what is the information flow exchanged over the connectors between the states? This is an inappropriate question because, generally, states in a dynamic object do not exchange information. Yes, they represent or manipulate shared private or protected data of the object but typically they do not pass information between themselves (because they are behaviors within an entity and not entities themselves). If one is wanting to model the realization of a particular State Machine pattern for a dynamic system, one can separately model the class composition of their chosen state machine "engine". (If you still have access to Artisan's 4G TDK, you can find such models in the code generators for state machines for C#, C++, Ada, and Java.) Miro Samek's text on C and C++ Statecharts also has several object models for the frequently used state machine implementation. Realization of these patterns is all within the realm of UML. My primary concern is that State Machine diagrams express behavioral properties of an object and not contextual structural composition of an object's parts. Lonnie. PS: I think my remark is a verbose version of Sandy's comment... On Tue, May 5, 2009 at 7:35 PM, Friedenthal, Sanford wrote: George, Michael I think a state machine could appear on a bdd since it is a classifier like an activity. However, the individual states are not classifiers and therefore should not be depicted on a bdd like indicated. The reason the activity works is that the call actions and the activities they call have some similarity to parts. States do not have this equivalence. Sandy -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 8:46 AM To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org Subject: RE: Potential Resolution for Issue 13263 Hi everyone, I'm back (from short term disability) I appreciate your work. However, my thinking is that 1) We don't need an explicit IBD notation. As with activity/parametric diagrams, the equivalent of the IBD is the activity diagram notation itself (or parametric diagram). I would expect to see a stereotyped diagram usages of a BDD for the state machine, tied to the state machine diagram. 2) While diagrammatically a state machine has substates visually contained in their superstates, the actual relationship is more of generalization. Any ongoing do/activity, or event/action pairs defined in a superstate is inherited by the substates unless overridden. Generalization is normally disjoint, except for when explicitly indicated as overlapping. I believe all the fancy generalization keywords (such as discriminators) would apply. Entry/exit actions are not inherited, but are more like the way constructors/destructors work -- "outside-in" going into the substates and inside-out leaving. 3) I haven't yet thought it completely through, but submachines are more of an aggregation situation and can have multiplicity. 4) Using this class diagram approach for state machines has a long history and was originally pushed by Jim Rumbaugh. 5) The advantage of this alternative notation is a) Parallel understanding and simplicity-- there's always a bdd-specially diagram. The current irregularity always comes up when I'm teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a BDD-PAR, and the class logically asks what about BDD-STM. I teach many SysML courses, and it would make the student's understand better, feel that the languages was logically designed. b) State machine notation is not always easy to understand. I've found that the equivalent BDD/class diagram approach for showing the state structure was easier --- especially once I had taught the BDD notation. It highlights the complex inheritance relationships among event/action pairs, etc. Michael Jesse Chonoles LMCO -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 3:09 PM To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Tim SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My students complain that we're missing BDD-->STM. A state machine modeling approach using Class diagrams was proposed by Jim Rumbaugh and was popular as it clarifies the inheritance of state features. (In addition, it shows a possible way of implementing state machines using and OO approach -- though this is not relevant to SysML). It would be relavitivy easy to do (possibly easier than BDD-->:ACT) and would greatly improve the understanding of SysML. It would address some of the comments that I get that SysML seems to be an ad-hoc notation, with little consistency. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 05, 2009 2:43 PM To: Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Maybe I missed previous discussions. But I don't understand the motivation of this resolution. Which current problem with SysML will be resolved? Tim -----Original Message----- From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] Sent: Tuesday, May 05, 2009 8:08 AM To: sysml-rtf@omg.org Subject: Potential Resolution for Issue 13263 Good Morning, Time permitting, I would like to discuss the following proposed resolution for BDDs for state machines at this week's telecon. <> My expectation is that the discussion should require no more than 5 minutes or so. Regards, George Sawyer BAE SYSTEMS X-Trusted-NM: yes From: "Nerijus Jankevicius" To: "Friedenthal, Sanford" , "Sawyer, George A \(US SSA\)" , "Chonoles, Michael J" Cc: Subject: Re: Potential Resolution for Issue 13263 Date: Wed, 6 May 2009 09:49:34 +0300 X-Mailer: Microsoft Outlook Express 6.00.2900.5512 Guys, For me, Activities and Statemachines look identical. Both could be represented in BDD using "classbox" notation. Inheritance is allowed also. Sandy, you are not right, States have equivalence to CallBehaviorAction in Activities. Every state may call another StateMachine and it becomes "submachine state" in this case. UML spec says: "Submachine state A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. " So, we can represent composite statemachines in the same form as we do with Activities. No changes required. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: "Friedenthal, Sanford" To: "Sawyer, George A (US SSA)" ; "Chonoles, Michael J" Cc: ; Sent: Wednesday, May 06, 2009 4:35 AM Subject: RE: Potential Resolution for Issue 13263 George, Michael I think a state machine could appear on a bdd since it is a classifier like an activity. However, the individual states are not classifiers and therefore should not be depicted on a bdd like indicated. The reason the activity works is that the call actions and the activities they call have some similarity to parts. States do not have this equivalence. Sandy -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 8:46 AM To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org Subject: RE: Potential Resolution for Issue 13263 Hi everyone, I'm back (from short term disability) I appreciate your work. However, my thinking is that 1) We don't need an explicit IBD notation. As with activity/parametric diagrams, the equivalent of the IBD is the activity diagram notation itself (or parametric diagram). I would expect to see a stereotyped diagram usages of a BDD for the state machine, tied to the state machine diagram. 2) While diagrammatically a state machine has substates visually contained in their superstates, the actual relationship is more of generalization. Any ongoing do/activity, or event/action pairs defined in a superstate is inherited by the substates unless overridden. Generalization is normally disjoint, except for when explicitly indicated as overlapping. I believe all the fancy generalization keywords (such as discriminators) would apply. Entry/exit actions are not inherited, but are more like the way constructors/destructors work -- "outside-in" going into the substates and inside-out leaving. 3) I haven't yet thought it completely through, but submachines are more of an aggregation situation and can have multiplicity. 4) Using this class diagram approach for state machines has a long history and was originally pushed by Jim Rumbaugh. 5) The advantage of this alternative notation is a) Parallel understanding and simplicity-- there's always a bdd-specially diagram. The current irregularity always comes up when I'm teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a BDD-PAR, and the class logically asks what about BDD-STM. I teach many SysML courses, and it would make the student's understand better, feel that the languages was logically designed. b) State machine notation is not always easy to understand. I've found that the equivalent BDD/class diagram approach for showing the state structure was easier --- especially once I had taught the BDD notation. It highlights the complex inheritance relationships among event/action pairs, etc. Michael Jesse Chonoles LMCO -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 3:09 PM To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Tim SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My students complain that we're missing BDD-->STM. A state machine modeling approach using Class diagrams was proposed by Jim Rumbaugh and was popular as it clarifies the inheritance of state features. (In addition, it shows a possible way of implementing state machines using and OO approach -- though this is not relevant to SysML). It would be relavitivy easy to do (possibly easier than BDD-->:ACT) and would greatly improve the understanding of SysML. It would address some of the comments that I get that SysML seems to be an ad-hoc notation, with little consistency. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 05, 2009 2:43 PM To: Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Maybe I missed previous discussions. But I don't understand the motivation of this resolution. Which current problem with SysML will be resolved? Tim -----Original Message----- From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] Sent: Tuesday, May 05, 2009 8:08 AM To: sysml-rtf@omg.org Subject: Potential Resolution for Issue 13263 Good Morning, Time permitting, I would like to discuss the following proposed resolution for BDDs for state machines at this week's telecon. <> My expectation is that the discussion should require no more than 5 minutes or so. Regards, George Sawyer BAE SYSTEMS Subject: RE: Potential Resolution for Issue 13263 Date: Wed, 6 May 2009 10:54:55 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnOF6J2VT791N5ZSAW+zrRPUqr2LgACgknQ From: "BERNARD, Yves" To: "Nerijus Jankevicius" , "Friedenthal, Sanford" , "Sawyer, George A \(US SSA\)" , "Chonoles, Michael J" Cc: X-OriginalArrivalTime: 06 May 2009 08:54:56.0515 (UTC) FILETIME=[544D8530:01C9CE28] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n468sjkm016803 Hello all, For my point of view, and despite what is currently written in the SysML specification, a call action is not similar to a part but to a reference definition (beside, I should raise an issue on that point...). A part definition assume that there is a composite association. If an activitiy is indeed composed of actions, it doesn't own any other activities and then the current notation is misleading. It would be fine to correct it and to avoid disseminating that kind of misuse. Note that we could get something semantically correct and fairly similar from a "visual" point of view using classical (and derived) associations. To come back to the original subject, I would said that anyway, as Sandy said, states are not classifiers unlike Activities or Statemachines then if we can expect to show submachines in a bdd, it's not the case for other kind states. I understand the interest of tree-like representation of state machines but they cannot be provided through a bdd: another kind of diagram is required. Note also that a state (like an action) cannot have generalization relationship, precisely because it's not a classifier. The submachine state shall not be mix up with statemachine it "calls", like a CallBehaviorAction shall not be mix up with the invoked behavior. Cheers, Yves -----Message d'origine----- De : Nerijus Jankevicius [mailto:nerijus@nomagic.com] Envoyé : mercredi 6 mai 2009 08:50 À : Friedenthal, Sanford; Sawyer, George A (US SSA); Chonoles, Michael J Cc : sysml-rtf@omg.org Objet : Re: Potential Resolution for Issue 13263 Guys, For me, Activities and Statemachines look identical. Both could be represented in BDD using "classbox" notation. Inheritance is allowed also. Sandy, you are not right, States have equivalence to CallBehaviorAction in Activities. Every state may call another StateMachine and it becomes "submachine state" in this case. UML spec says: "Submachine state A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. " So, we can represent composite statemachines in the same form as we do with Activities. No changes required. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: "Friedenthal, Sanford" To: "Sawyer, George A (US SSA)" ; "Chonoles, Michael J" Cc: ; Sent: Wednesday, May 06, 2009 4:35 AM Subject: RE: Potential Resolution for Issue 13263 > George, Michael > > I think a state machine could appear on a bdd since it is a classifier > like an activity. However, the individual states are not classifiers and > therefore should not be depicted on a bdd like indicated. The reason the > activity works is that the call actions and the activities they call > have some similarity to parts. States do not have this equivalence. > > Sandy > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 8:46 AM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Hi everyone, I'm back (from short term disability) > > I appreciate your work. > > However, my thinking is that > > 1) We don't need an explicit IBD notation. As with activity/parametric > diagrams, the equivalent of the IBD is the activity diagram notation > itself (or parametric diagram). I would expect to see a stereotyped > diagram usages of a BDD for the state machine, tied to the state machine > diagram. > > 2) While diagrammatically a state machine has substates visually > contained in their superstates, the actual relationship is more of > generalization. Any ongoing do/activity, or event/action pairs defined > in a superstate is inherited by the substates unless overridden. > Generalization is normally disjoint, except for when explicitly > indicated as overlapping. I believe all the fancy generalization > keywords (such as discriminators) would apply. Entry/exit actions are > not inherited, but are more like the way constructors/destructors work > -- "outside-in" going into the substates and inside-out leaving. > > 3) I haven't yet thought it completely through, but submachines are more > of an aggregation situation and can have multiplicity. > > 4) Using this class diagram approach for state machines has a long > history and was originally pushed by Jim Rumbaugh. > > 5) The advantage of this alternative notation is > a) Parallel understanding and simplicity-- there's always a > bdd-specially diagram. The current irregularity always comes up when I'm > teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a > BDD-PAR, and the class logically asks what about BDD-STM. I teach many > SysML courses, and it would make the student's understand better, feel > that the languages was logically designed. > b) State machine notation is not always easy to understand. I've > found that the equivalent BDD/class diagram approach for showing the > state structure was easier --- especially once I had taught the BDD > notation. It highlights the complex inheritance relationships among > event/action pairs, etc. > > Michael Jesse Chonoles > LMCO > > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 3:09 PM > To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Tim > SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My > students complain that we're missing BDD-->STM. A state machine > modeling approach using Class diagrams was proposed by Jim Rumbaugh and > was popular as it clarifies the inheritance of state features. (In > addition, it shows a possible way of implementing state machines using > and OO approach -- though this is not relevant to SysML). It would be > relavitivy easy to do (possibly easier than BDD-->:ACT) and would > greatly improve the understanding of SysML. It would address some of the > comments that I get that SysML seems to be an ad-hoc notation, with > little consistency. > > Michael > > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, May 05, 2009 2:43 PM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Maybe I missed previous discussions. But I don't understand the > motivation of > this resolution. Which current problem with SysML will be resolved? > > Tim > > -----Original Message----- > From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] > Sent: Tuesday, May 05, 2009 8:08 AM > To: sysml-rtf@omg.org > Subject: Potential Resolution for Issue 13263 > > Good Morning, > > Time permitting, I would like to discuss the following proposed > resolution for BDDs for state machines at this week's telecon. > > <> > > My expectation is that the discussion should require no more than 5 > minutes or so. > > Regards, > George Sawyer > BAE SYSTEMS > > > > This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Date: Wed, 06 May 2009 07:06:59 -0400 From: "Friedenthal, Sanford" Subject: RE: Potential Resolution for Issue 13263 To: Nerijus Jankevicius , "Sawyer, George A (US SSA)" , "Chonoles, Michael J" Cc: sysml-rtf@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnOFteq+cNH2GnYQouwSf1UxXYs7wAIg2jQ X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 May 2009 11:07:04.0066 (UTC) FILETIME=[C97DCE20:01C9CE3A] Nerijus I agree a submachine state is analogous to the call action. However, I was referring to a 'state' which is a namespace and not a classifier. Sandy -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, May 06, 2009 2:50 AM To: Friedenthal, Sanford; Sawyer, George A (US SSA); Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: Re: Potential Resolution for Issue 13263 Guys, For me, Activities and Statemachines look identical. Both could be represented in BDD using "classbox" notation. Inheritance is allowed also. Sandy, you are not right, States have equivalence to CallBehaviorAction in Activities. Every state may call another StateMachine and it becomes "submachine state" in this case. UML spec says: "Submachine state A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. " So, we can represent composite statemachines in the same form as we do with Activities. No changes required. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: "Friedenthal, Sanford" To: "Sawyer, George A (US SSA)" ; "Chonoles, Michael J" Cc: ; Sent: Wednesday, May 06, 2009 4:35 AM Subject: RE: Potential Resolution for Issue 13263 > George, Michael > > I think a state machine could appear on a bdd since it is a classifier > like an activity. However, the individual states are not classifiers and > therefore should not be depicted on a bdd like indicated. The reason the > activity works is that the call actions and the activities they call > have some similarity to parts. States do not have this equivalence. > > Sandy > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 8:46 AM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Hi everyone, I'm back (from short term disability) > > I appreciate your work. > > However, my thinking is that > > 1) We don't need an explicit IBD notation. As with activity/parametric > diagrams, the equivalent of the IBD is the activity diagram notation > itself (or parametric diagram). I would expect to see a stereotyped > diagram usages of a BDD for the state machine, tied to the state machine > diagram. > > 2) While diagrammatically a state machine has substates visually > contained in their superstates, the actual relationship is more of > generalization. Any ongoing do/activity, or event/action pairs defined > in a superstate is inherited by the substates unless overridden. > Generalization is normally disjoint, except for when explicitly > indicated as overlapping. I believe all the fancy generalization > keywords (such as discriminators) would apply. Entry/exit actions are > not inherited, but are more like the way constructors/destructors work > -- "outside-in" going into the substates and inside-out leaving. > > 3) I haven't yet thought it completely through, but submachines are more > of an aggregation situation and can have multiplicity. > > 4) Using this class diagram approach for state machines has a long > history and was originally pushed by Jim Rumbaugh. > > 5) The advantage of this alternative notation is > a) Parallel understanding and simplicity-- there's always a > bdd-specially diagram. The current irregularity always comes up when I'm > teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a > BDD-PAR, and the class logically asks what about BDD-STM. I teach many > SysML courses, and it would make the student's understand better, feel > that the languages was logically designed. > b) State machine notation is not always easy to understand. I've > found that the equivalent BDD/class diagram approach for showing the > state structure was easier --- especially once I had taught the BDD > notation. It highlights the complex inheritance relationships among > event/action pairs, etc. > > Michael Jesse Chonoles > LMCO > > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 3:09 PM > To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Tim > SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My > students complain that we're missing BDD-->STM. A state machine > modeling approach using Class diagrams was proposed by Jim Rumbaugh and > was popular as it clarifies the inheritance of state features. (In > addition, it shows a possible way of implementing state machines using > and OO approach -- though this is not relevant to SysML). It would be > relavitivy easy to do (possibly easier than BDD-->:ACT) and would > greatly improve the understanding of SysML. It would address some of the > comments that I get that SysML seems to be an ad-hoc notation, with > little consistency. > > Michael > > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, May 05, 2009 2:43 PM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Maybe I missed previous discussions. But I don't understand the > motivation of > this resolution. Which current problem with SysML will be resolved? > > Tim > > -----Original Message----- > From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] > Sent: Tuesday, May 05, 2009 8:08 AM > To: sysml-rtf@omg.org > Subject: Potential Resolution for Issue 13263 > > Good Morning, > > Time permitting, I would like to discuss the following proposed > resolution for BDDs for state machines at this week's telecon. > > <> > > My expectation is that the discussion should require no more than 5 > minutes or so. > > Regards, > George Sawyer > BAE SYSTEMS > > > > Date: Wed, 06 May 2009 10:44:05 -0400 From: "Chonoles, Michael J" Subject: RE: Potential Resolution for Issue 13263 To: "Friedenthal, Sanford" , "Sawyer, George A (US SSA)" Cc: sysml-rtf@omg.org, issues@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnNehrv/fwgSM27S/m3sa0WlNGKowAAnscwABtxRIAAG4ShMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 May 2009 14:44:40.0471 (UTC) FILETIME=[2FB71A70:01C9CE59] Sandy is quite right. I now remember that the fundamental objection is that UML 2 (inadvertently) prevented this from being legal. I had discussed this with Bran Selic and wrote an issue on UML 2.x. >From the UML perspective this is not a big problem, but from SysML students' POV the lack of symmetry is often remarked and makes our language seem ad-hoc and more difficult. Having architectural parallels would make the language easy to learn. However, because the problem is ultimately within UML, I recommend deferring this until I can UML 2 to come around. Thanks for everyone's time. Michael LMCO -----Original Message----- From: Friedenthal, Sanford Sent: Tuesday, May 05, 2009 9:35 PM To: Sawyer, George A (US SSA); Chonoles, Michael J Cc: sysml-rtf@omg.org; issues@omg.org Subject: RE: Potential Resolution for Issue 13263 George, Michael I think a state machine could appear on a bdd since it is a classifier like an activity. However, the individual states are not classifiers and therefore should not be depicted on a bdd like indicated. The reason the activity works is that the call actions and the activities they call have some similarity to parts. States do not have this equivalence. Sandy -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 8:46 AM To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org Subject: RE: Potential Resolution for Issue 13263 Hi everyone, I'm back (from short term disability) I appreciate your work. However, my thinking is that 1) We don't need an explicit IBD notation. As with activity/parametric diagrams, the equivalent of the IBD is the activity diagram notation itself (or parametric diagram). I would expect to see a stereotyped diagram usages of a BDD for the state machine, tied to the state machine diagram. 2) While diagrammatically a state machine has substates visually contained in their superstates, the actual relationship is more of generalization. Any ongoing do/activity, or event/action pairs defined in a superstate is inherited by the substates unless overridden. Generalization is normally disjoint, except for when explicitly indicated as overlapping. I believe all the fancy generalization keywords (such as discriminators) would apply. Entry/exit actions are not inherited, but are more like the way constructors/destructors work -- "outside-in" going into the substates and inside-out leaving. 3) I haven't yet thought it completely through, but submachines are more of an aggregation situation and can have multiplicity. 4) Using this class diagram approach for state machines has a long history and was originally pushed by Jim Rumbaugh. 5) The advantage of this alternative notation is a) Parallel understanding and simplicity-- there's always a bdd-specially diagram. The current irregularity always comes up when I'm teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a BDD-PAR, and the class logically asks what about BDD-STM. I teach many SysML courses, and it would make the student's understand better, feel that the languages was logically designed. b) State machine notation is not always easy to understand. I've found that the equivalent BDD/class diagram approach for showing the state structure was easier --- especially once I had taught the BDD notation. It highlights the complex inheritance relationships among event/action pairs, etc. Michael Jesse Chonoles LMCO -----Original Message----- From: Chonoles, Michael J Sent: Tuesday, May 05, 2009 3:09 PM To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Tim SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My students complain that we're missing BDD-->STM. A state machine modeling approach using Class diagrams was proposed by Jim Rumbaugh and was popular as it clarifies the inheritance of state features. (In addition, it shows a possible way of implementing state machines using and OO approach -- though this is not relevant to SysML). It would be relavitivy easy to do (possibly easier than BDD-->:ACT) and would greatly improve the understanding of SysML. It would address some of the comments that I get that SysML seems to be an ad-hoc notation, with little consistency. Michael -----Original Message----- From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] Sent: Tuesday, May 05, 2009 2:43 PM To: Sawyer, George A (US SSA); sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Maybe I missed previous discussions. But I don't understand the motivation of this resolution. Which current problem with SysML will be resolved? Tim -----Original Message----- From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] Sent: Tuesday, May 05, 2009 8:08 AM To: sysml-rtf@omg.org Subject: Potential Resolution for Issue 13263 Good Morning, Time permitting, I would like to discuss the following proposed resolution for BDDs for state machines at this week's telecon. <> My expectation is that the discussion should require no more than 5 minutes or so. Regards, George Sawyer BAE SYSTEMS Date: Wed, 06 May 2009 10:46:07 -0400 From: "Chonoles, Michael J" Subject: RE: Potential Resolution for Issue 13263 To: "Friedenthal, Sanford" , Nerijus Jankevicius , "Sawyer, George A (US SSA)" Cc: sysml-rtf@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnOFteq+cNH2GnYQouwSf1UxXYs7wAIg2jQAAgc04A= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 May 2009 14:46:45.0922 (UTC) FILETIME=[7A7D6820:01C9CE59] Yes, I believe the notation works, but the metamodel may have problems here -----Original Message----- From: Friedenthal, Sanford Sent: Wednesday, May 06, 2009 7:07 AM To: Nerijus Jankevicius; Sawyer, George A (US SSA); Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Nerijus I agree a submachine state is analogous to the call action. However, I was referring to a 'state' which is a namespace and not a classifier. Sandy -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, May 06, 2009 2:50 AM To: Friedenthal, Sanford; Sawyer, George A (US SSA); Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: Re: Potential Resolution for Issue 13263 Guys, For me, Activities and Statemachines look identical. Both could be represented in BDD using "classbox" notation. Inheritance is allowed also. Sandy, you are not right, States have equivalence to CallBehaviorAction in Activities. Every state may call another StateMachine and it becomes "submachine state" in this case. UML spec says: "Submachine state A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. " So, we can represent composite statemachines in the same form as we do with Activities. No changes required. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: "Friedenthal, Sanford" To: "Sawyer, George A (US SSA)" ; "Chonoles, Michael J" Cc: ; Sent: Wednesday, May 06, 2009 4:35 AM Subject: RE: Potential Resolution for Issue 13263 > George, Michael > > I think a state machine could appear on a bdd since it is a classifier > like an activity. However, the individual states are not classifiers and > therefore should not be depicted on a bdd like indicated. The reason the > activity works is that the call actions and the activities they call > have some similarity to parts. States do not have this equivalence. > > Sandy > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 8:46 AM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Hi everyone, I'm back (from short term disability) > > I appreciate your work. > > However, my thinking is that > > 1) We don't need an explicit IBD notation. As with activity/parametric > diagrams, the equivalent of the IBD is the activity diagram notation > itself (or parametric diagram). I would expect to see a stereotyped > diagram usages of a BDD for the state machine, tied to the state machine > diagram. > > 2) While diagrammatically a state machine has substates visually > contained in their superstates, the actual relationship is more of > generalization. Any ongoing do/activity, or event/action pairs defined > in a superstate is inherited by the substates unless overridden. > Generalization is normally disjoint, except for when explicitly > indicated as overlapping. I believe all the fancy generalization > keywords (such as discriminators) would apply. Entry/exit actions are > not inherited, but are more like the way constructors/destructors work > -- "outside-in" going into the substates and inside-out leaving. > > 3) I haven't yet thought it completely through, but submachines are more > of an aggregation situation and can have multiplicity. > > 4) Using this class diagram approach for state machines has a long > history and was originally pushed by Jim Rumbaugh. > > 5) The advantage of this alternative notation is > a) Parallel understanding and simplicity-- there's always a > bdd-specially diagram. The current irregularity always comes up when I'm > teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a > BDD-PAR, and the class logically asks what about BDD-STM. I teach many > SysML courses, and it would make the student's understand better, feel > that the languages was logically designed. > b) State machine notation is not always easy to understand. I've > found that the equivalent BDD/class diagram approach for showing the > state structure was easier --- especially once I had taught the BDD > notation. It highlights the complex inheritance relationships among > event/action pairs, etc. > > Michael Jesse Chonoles > LMCO > > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 3:09 PM > To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Tim > SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My > students complain that we're missing BDD-->STM. A state machine > modeling approach using Class diagrams was proposed by Jim Rumbaugh and > was popular as it clarifies the inheritance of state features. (In > addition, it shows a possible way of implementing state machines using > and OO approach -- though this is not relevant to SysML). It would be > relavitivy easy to do (possibly easier than BDD-->:ACT) and would > greatly improve the understanding of SysML. It would address some of the > comments that I get that SysML seems to be an ad-hoc notation, with > little consistency. > > Michael > > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, May 05, 2009 2:43 PM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Maybe I missed previous discussions. But I don't understand the > motivation of > this resolution. Which current problem with SysML will be resolved? > > Tim > > -----Original Message----- > From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] > Sent: Tuesday, May 05, 2009 8:08 AM > To: sysml-rtf@omg.org > Subject: Potential Resolution for Issue 13263 > > Good Morning, > > Time permitting, I would like to discuss the following proposed > resolution for BDDs for state machines at this week's telecon. > > <> > > My expectation is that the discussion should require no more than 5 > minutes or so. > > Regards, > George Sawyer > BAE SYSTEMS > > > > Date: Wed, 06 May 2009 11:57:46 -0400 From: "Friedenthal, Sanford" Subject: RE: Potential Resolution for Issue 13263 To: "Chonoles, Michael J" , Nerijus Jankevicius , "Sawyer, George A (US SSA)" Cc: sysml-rtf@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnOFteq+cNH2GnYQouwSf1UxXYs7wAIg2jQAAgc04AAAoKPMA== X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 May 2009 15:58:24.0711 (UTC) FILETIME=[7CC48D70:01C9CE63] Agreed. -----Original Message----- From: Chonoles, Michael J Sent: Wednesday, May 06, 2009 10:46 AM To: Friedenthal, Sanford; 'Nerijus Jankevicius'; 'Sawyer, George A (US SSA)' Cc: 'sysml-rtf@omg.org' Subject: RE: Potential Resolution for Issue 13263 Yes, I believe the notation works, but the metamodel may have problems here -----Original Message----- From: Friedenthal, Sanford Sent: Wednesday, May 06, 2009 7:07 AM To: Nerijus Jankevicius; Sawyer, George A (US SSA); Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: RE: Potential Resolution for Issue 13263 Nerijus I agree a submachine state is analogous to the call action. However, I was referring to a 'state' which is a namespace and not a classifier. Sandy -----Original Message----- From: Nerijus Jankevicius [mailto:nerijus@nomagic.com] Sent: Wednesday, May 06, 2009 2:50 AM To: Friedenthal, Sanford; Sawyer, George A (US SSA); Chonoles, Michael J Cc: sysml-rtf@omg.org Subject: Re: Potential Resolution for Issue 13263 Guys, For me, Activities and Statemachines look identical. Both could be represented in BDD using "classbox" notation. Inheritance is allowed also. Sandy, you are not right, States have equivalence to CallBehaviorAction in Activities. Every state may call another StateMachine and it becomes "submachine state" in this case. UML spec says: "Submachine state A submachine state specifies the insertion of the specification of a submachine state machine. The state machine that contains the submachine state is called the containing state machine. The same state machine may be a submachine more than once in the context of a single containing state machine. A submachine state is semantically equivalent to a composite state. " So, we can represent composite statemachines in the same form as we do with Activities. No changes required. Regards, -- Nerijus Jankevicius SysML Product Manager OMG-Certified UML Professional No Magic Europe Savanoriu pr. 363, LT 49425 Kaunas, Lithuania P.O. box 2166, LT- 3000, Kaunas Phone: +370-37-324032 Fax: +370-37-320670 e-mail: nerijus@magicdraw.com WWW: http://www.magicdraw.com -- MagicDraw - Architecture made simple! ----- Original Message ----- From: "Friedenthal, Sanford" To: "Sawyer, George A (US SSA)" ; "Chonoles, Michael J" Cc: ; Sent: Wednesday, May 06, 2009 4:35 AM Subject: RE: Potential Resolution for Issue 13263 > George, Michael > > I think a state machine could appear on a bdd since it is a classifier > like an activity. However, the individual states are not classifiers and > therefore should not be depicted on a bdd like indicated. The reason the > activity works is that the call actions and the activities they call > have some similarity to parts. States do not have this equivalence. > > Sandy > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 8:46 AM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org; issues@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Hi everyone, I'm back (from short term disability) > > I appreciate your work. > > However, my thinking is that > > 1) We don't need an explicit IBD notation. As with activity/parametric > diagrams, the equivalent of the IBD is the activity diagram notation > itself (or parametric diagram). I would expect to see a stereotyped > diagram usages of a BDD for the state machine, tied to the state machine > diagram. > > 2) While diagrammatically a state machine has substates visually > contained in their superstates, the actual relationship is more of > generalization. Any ongoing do/activity, or event/action pairs defined > in a superstate is inherited by the substates unless overridden. > Generalization is normally disjoint, except for when explicitly > indicated as overlapping. I believe all the fancy generalization > keywords (such as discriminators) would apply. Entry/exit actions are > not inherited, but are more like the way constructors/destructors work > -- "outside-in" going into the substates and inside-out leaving. > > 3) I haven't yet thought it completely through, but submachines are more > of an aggregation situation and can have multiplicity. > > 4) Using this class diagram approach for state machines has a long > history and was originally pushed by Jim Rumbaugh. > > 5) The advantage of this alternative notation is > a) Parallel understanding and simplicity-- there's always a > bdd-specially diagram. The current irregularity always comes up when I'm > teaching SysML. There's a BDD-IBD, there's a BDD-ACT, there's a > BDD-PAR, and the class logically asks what about BDD-STM. I teach many > SysML courses, and it would make the student's understand better, feel > that the languages was logically designed. > b) State machine notation is not always easy to understand. I've > found that the equivalent BDD/class diagram approach for showing the > state structure was easier --- especially once I had taught the BDD > notation. It highlights the complex inheritance relationships among > event/action pairs, etc. > > Michael Jesse Chonoles > LMCO > > > -----Original Message----- > From: Chonoles, Michael J > Sent: Tuesday, May 05, 2009 3:09 PM > To: Tim Weilkiens; Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Tim > SysML has a strongly parallel BDD-->IBD, BDD-->ACT; BDD-->PAR. My > students complain that we're missing BDD-->STM. A state machine > modeling approach using Class diagrams was proposed by Jim Rumbaugh and > was popular as it clarifies the inheritance of state features. (In > addition, it shows a possible way of implementing state machines using > and OO approach -- though this is not relevant to SysML). It would be > relavitivy easy to do (possibly easier than BDD-->:ACT) and would > greatly improve the understanding of SysML. It would address some of the > comments that I get that SysML seems to be an ad-hoc notation, with > little consistency. > > Michael > > > -----Original Message----- > From: Tim Weilkiens [mailto:Tim.Weilkiens@oose.de] > Sent: Tuesday, May 05, 2009 2:43 PM > To: Sawyer, George A (US SSA); sysml-rtf@omg.org > Subject: RE: Potential Resolution for Issue 13263 > > Maybe I missed previous discussions. But I don't understand the > motivation of > this resolution. Which current problem with SysML will be resolved? > > Tim > > -----Original Message----- > From: Sawyer, George A (US SSA) [mailto:george.a.sawyer@baesystems.com] > Sent: Tuesday, May 05, 2009 8:08 AM > To: sysml-rtf@omg.org > Subject: Potential Resolution for Issue 13263 > > Good Morning, > > Time permitting, I would like to discuss the following proposed > resolution for BDDs for state machines at this week's telecon. > > <> > > My expectation is that the discussion should require no more than 5 > minutes or so. > > Regards, > George Sawyer > BAE SYSTEMS > > > > Reply-To: From: "Conrad Bock" To: "'Chonoles, Michael J'" , "'Friedenthal, Sanford'" , "'Sawyer, George A \(US SSA\)'" Cc: , Subject: RE: Potential Resolution for Issue 13263 Date: Wed, 6 May 2009 11:05:28 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnNehrv/fwgSM27S/m3sa0WlNGKowAAnscwABtxRIAAG4ShMAAA4JCQ X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n46F5YVX014888 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242227174.69468@A8VLx66YV93olnqvAi9RPw X-Spam-Status: No Michael, > I now remember that the fundamental objection is that UML 2 > (inadvertently) prevented this from being legal. I had > discussed this > with Bran Selic and wrote an issue on UML 2.x. What exactly is the issue? BTW, here's an article on states as classes/blocks: http://www.conradbock.org/statemachine.html Conrad Reply-To: From: "Conrad Bock" To: "'Chonoles, Michael J'" , "'Friedenthal, Sanford'" , "'Nerijus Jankevicius'" , "'Sawyer, George A \(US SSA\)'" Cc: Subject: RE: Potential Resolution for Issue 13263 Date: Wed, 6 May 2009 12:27:01 -0400 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcnOFteq+cNH2GnYQouwSf1UxXYs7wAIg2jQAAgc04AAA06YIA== X-MailScanner-Information: Please contact postmaster@mel.nist.gov for more information X-NISTMEL-MailScanner-ID: n46GR6kw027433 X-MailScanner: Found to be clean X-MailScanner-SpamCheck: X-MailScanner-From: conrad.bock@nist.gov X-MailScanner-Watermark: 1242232030.07205@l5nNzD5I3uIYlGqe0B4nZQ X-Spam-Status: No Nerijus, et al, > So, we can represent composite statemachines in the same form as we > do with Activities. No changes required. This is true for the "called" state machines, at least to the exent these are treated as separate executions (the "insertion" semantics sort of muddies things, but might be OK). Called state machines are less often used than called activities. And the semantics of the other states would be a problem, unless you used the semantics from the paper I referenced (unlike actions in activities). But overall I don't see a problem using other behaviors than activities on bdd's, at least for the "calling" elements in those behaviors. Conrad Date: Wed, 06 May 2009 13:23:18 -0400 From: "Chonoles, Michael J" Subject: RE: Potential Resolution for Issue 13263 To: conrad.bock@nist.gov, "Friedenthal, Sanford" , "Sawyer, George A (US SSA)" Cc: sysml-rtf@omg.org, issues@omg.org Thread-Topic: Potential Resolution for Issue 13263 Thread-Index: AcnNehrv/fwgSM27S/m3sa0WlNGKowAAnscwABtxRIAAG4ShMAAA4JCQAAKHzvA= X-MS-Has-Attach: X-MS-TNEF-Correlator: X-OriginalArrivalTime: 06 May 2009 17:23:19.0990 (UTC) FILETIME=[59CA6D60:01C9CE6F] Conrad Good article (of course) I believe the problem is that in UML 2, a STATE is not a CLASSIFIER but a NAMESPACE and therefore cannot support features or generalization. I believe it was a CLASSIFIER in 1.3 and before, but I can't find my copy of the old specs. Of course, we can create a compatible notation, but I believe if a STATE was a CLASSIFIER, the impact to SysML would be small. -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Wednesday, May 06, 2009 11:05 AM To: Chonoles, Michael J; Friedenthal, Sanford; 'Sawyer, George A (US SSA)' Cc: sysml-rtf@omg.org; issues@omg.org Subject: RE: Potential Resolution for Issue 13263 Michael, > I now remember that the fundamental objection is that UML 2 > (inadvertently) prevented this from being legal. I had > discussed this > with Bran Selic and wrote an issue on UML 2.x. What exactly is the issue? BTW, here's an article on states as classes/blocks: http://www.conradbock.org/statemachine.html Conrad