Issue 3202: Another State machine issue (uml2-superstructure-ftf) Source: OpenModeling (Mr. Jos Warmer, jos.warmer(at)openmodeling.nl) Nature: Uncategorized Issue Severity: Summary: State Machines The metaclass StateVertext, including its subclasses PseudoState, StubState and SyncState is not owned by a StateMachine. The associations from StateVertext to - container : CompositeState - outgoing : Transition - incoming : Tranision can all be empty. If they are all empty in a model, we do not know to which statemachine this StateVertex belongs. IS this the intention ? Resolution: see above Revised Text: Actions taken: January 10, 2000: received issue March 9, 2005: closed issue Discussion: The issue described here is partially obsolete relative to the UML2.0 metamodel. The StateVertex is properly owned and can navigate back to its owning region. End of Annotations:===== QUESTION 2 State Machines The metaclass StateVertext, including its subclasses PseudoState, StubState and SyncState is not owned by a StateMachine. The associations from StateVertext to - container : CompositeState - outgoing : Transition - incoming : Tranision can all be empty. If they are all empty in a model, we do not know to which statemachine this StateVertex belongs. IS this the intention ? Shouldn't there either be: - a rule that at least one of the above associations is not empty or - an explicit 'owns' association/aggregation between a StateMachine and StateVertex The same question applies to State, which can be 'stand-alone' as well. _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl From: "Eran Gery" To: "'Jos Warmer'" Cc: Subject: RE: Questions for State Machine package Date: Mon, 10 Jan 2000 17:15:29 +0200 Message-ID: <006201bf5b7d$8852a360$0100007f@potato.ilogix.co.il> MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 Importance: Normal In-Reply-To: <3.0.6.32.20000110145230.009194a0@pop3.NL.net> X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 0fgd9K/4e9<2=!!I^?!! > -----Original Message----- > From: Jos Warmer [mailto:J.Warmer@klasse.nl] > Sent: Monday, January 10, 2000 3:53 PM > To: uml-rtf@omg.org > Subject: Questions for State Machine package > > > Hi there, > > I have two questions related to the State MAchine metamodel. > Can anyone explain this ti me ? > > Regards, Jos > ______________________________________________________________ > ______________ > ___ > QUESTION 1 > > State Machines: > > Why is "FinalState" a separate metaclass ? > > It seems that a final state can be modeled as a kind of > PseudoState > (with PseudoStateKind = final). > > FinalState has no attributes of its own, and all > associations inherited > from State must be empty for a final state: > - A final state cannot have an entry action > - A final state cannot have an exit action > - A final state cannot have an doActivity > - A final state cannot have a deferrableEvent > - A final state cannot have an internalTransition > > Could anybody explain the reason of existence for a > FinalState metaclass ? In UML 1.2 that was indeed the case. Although finalState resembles a pseudo state alot, there is one significant semantic difference: a final state as oppose to other pseudo states is a real state it the sense that it is not a transient node. All other pseodo states are transient nodes - meaning that they are never a part of the active state configuration after a run-to-completion. A final state can be in the active state configuration for indefiniote period, across indefinite number of RTC steps. This is a major difference that justifies making the final state different from a pseudo-state. > > ______________________________________________________________ > ______________ > ___ > QUESTION 2 > > State Machines > > The metaclass StateVertext, including its subclasses > PseudoState, > StubState and SyncState is not owned by a StateMachine. > > The associations from StateVertext to > - container : CompositeState > - outgoing : Transition > - incoming : Tranision > can all be empty. > If they are all empty in a model, we do not know to which > statemachine > this StateVertex belongs. IS this the intention ? Obviously not... > > Shouldn't there either be: > - a rule that at least one of the above associations is not > empty > or Indeed. The OCL should require that either the container is not empty > unless it is the top state. The top state is the state that (statemachine.top > .eq. state). Apropos, have you looked at other UML elements such as classes, operations etc ? I doubt whether we force a well connected instance hierarchy across the board. > - an explicit 'owns' association/aggregation between a > StateMachine > and StateVertex > > The same question applies to State, which can be > 'stand-alone' as well. > > _____________________________________________________ > Klasse Objecten tel : +31 (0)35 6037646 > Chalonhof 153 fax : +31 (0)35 6037647 > 3762 CT Soest email : J.Warmer@klasse.nl > The Netherlands internet: http://www.klasse.nl > From: "Eran Gery" To: "'Jos Warmer'" Cc: , "Guus Ramackers (E-mail)" Subject: RE: Questions for State Machine package Date: Wed, 13 Jan 1999 12:54:55 +0200 Message-ID: <002101be3ee3$280fe060$471c5ac2@potato.ilogix.co.il> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <3.0.6.32.20000112103953.009282f0@pop3.NL.net> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ))+e9`UHe9^=@e9FGT!! Jos, In general there's no clear border between "implementation" and "specification", but this is a philosophical debate. I agree that UML statechart provide a complete imperative specification of the behavior rather than just the legal sequences as proposed by Alan. That said, we've been fully aware that certain modelers wish to take the abstract sequences approach, as coined by Guus as "sequence) in which the operations of that Class can be invoked. The behavior of each of these operations is defined by an associated method, rather than through action expressions on transitions". Eran. > -----Original Message----- > From: Jos Warmer [mailto:J.Warmer@klasse.nl] > Sent: Wednesday, January 12, 2000 11:40 AM > To: Eran Gery > Cc: uml-rtf@omg.org > Subject: RE: Questions for State Machine package > > > Eran, > > I think that some of the confusion is coning from the fact that UML > statecharts are viewed as describing actual implementations in the > form of some statemachine. > > You might want to take a look at the RFI response of Alan > Wills (Trireme) > hwo requests that the commonly used 'descriptive interpretation' of > statemachines should be explicitly included in the UML. > > From RFI Response Alan Wills / Trireme > > Statecharts - descriptive interpretation > > Currently, statecharts in UML prescribe an implementation > in some form > of state machine. A broader descriptive interpretation is > much more widely > useful. In this interpretation: > - The presentation of a statechart for a class says > nothing about its > implementation. The purpose of the statechart is to show > a plan of what > sequences of operations or usecases make sense. For > example, a statechart > of Person could show that when single, the operation of > marriage is > possible; and when married, the operation of divorce is > an option. > - There is no canonical statechart for any class: it's up > to the analyst/ > designer to decide what she wants to tell her readers. Multiple > statecharts > may be used to describe a class. For example, we could also > show the anesthetist's view of a Person's states: awake, > asleep or dead. > > < ... etc ... > > > You might want to read his complete description at page 6 of > his response. > > Regards, Jos > > _____________________________________________________ > Klasse Objecten tel : +31 (0)35 6037646 > Chalonhof 153 fax : +31 (0)35 6037647 > 3762 CT Soest email : J.Warmer@klasse.nl > The Netherlands internet: http://www.klasse.nl > protocol state machines". See p 189 in the semantics document. An excerpt from there: "One application area of state machines is in specifying object protocols, also known as object life cycles. A From: "Eran Gery" To: "'Jos Warmer'" Cc: , "Guus Ramackers (E-mail)" Subject: RE: Questions for State Machine package Date: Wed, 13 Jan 1999 16:15:16 +0200 Message-ID: <002f01be3eff$2690d0c0$471c5ac2@potato.ilogix.co.il> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook 8.5, Build 4.71.2232.26 X-MimeOLE: Produced By Microsoft MimeOLE V4.72.3110.3 Importance: Normal In-Reply-To: <3.0.6.32.20000112103953.009282f0@pop3.NL.net> Content-Type: text/plain; charset="iso-8859-1" X-UIDL: 5@7!!JUA!!lRVd9_:Me9 Jos, In general there's no clear border between "implementation" and "specification", but this is a philosophical debate. I agree that UML statechart provide a complete imperative specification of the behavior rather than just the legal sequences as proposed by Alan. That said, we've been fully aware that certain modelers wish to take the abstract sequences approach, as coined by Guus as "sequence) in which the operations of that Class can be invoked. The behavior of each of these operations is defined by an associated method, rather than through action expressions on transitions". Eran. > -----Original Message----- > From: Jos Warmer [mailto:J.Warmer@klasse.nl] > Sent: Wednesday, January 12, 2000 11:40 AM > To: Eran Gery > Cc: uml-rtf@omg.org > Subject: RE: Questions for State Machine package > > > Eran, > > I think that some of the confusion is coning from the fact that UML > statecharts are viewed as describing actual implementations in the > form of some statemachine. > > You might want to take a look at the RFI response of Alan > Wills (Trireme) > hwo requests that the commonly used 'descriptive interpretation' of > statemachines should be explicitly included in the UML. > > From RFI Response Alan Wills / Trireme > > Statecharts - descriptive interpretation > > Currently, statecharts in UML prescribe an implementation > in some form > of state machine. A broader descriptive interpretation is > much more widely > useful. In this interpretation: > - The presentation of a statechart for a class says > nothing about its > implementation. The purpose of the statechart is to show > a plan of what > sequences of operations or usecases make sense. For > example, a statechart > of Person could show that when single, the operation of > marriage is > possible; and when married, the operation of divorce is > an option. > - There is no canonical statechart for any class: it's up > to the analyst/ > designer to decide what she wants to tell her readers. Multiple > statecharts > may be used to describe a class. For example, we could also > show the anesthetist's view of a Person's states: awake, > asleep or dead. > > < ... etc ... > > > You might want to read his complete description at page 6 of > his response. > > Regards, Jos > > _____________________________________________________ > Klasse Objecten tel : +31 (0)35 6037646 > Chalonhof 153 fax : +31 (0)35 6037647 > 3762 CT Soest email : J.Warmer@klasse.nl > The Netherlands internet: http://www.klasse.nl > protocol state machines". See p 189 in the semantics document. An excerpt from there: "One application area of state machines is in specifying object protocols, also known as object life cycles. A X-Sender: jwarmer@pop3.NL.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Tue, 11 Jan 2000 18:10:27 +0100 To: "Eran Gery" From: Jos Warmer Subject: RE: Questions for State Machine package Cc: In-Reply-To: <006201bf5b7d$8852a360$0100007f@potato.ilogix.co.il> References: <3.0.6.32.20000110145230.009194a0@pop3.NL.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: '+/!!:Z~!!KKRd9P*nd9 Eran, I have viewed a final state as a pseudo state, which means that the object will die (destroy itself, ..). If a final state is a real state, then an object is not destroyed as a consequence of going to the final state. However, within a final state there are no outgoing transitions and the object cannot handle events anymore. How does the object die ? It seems that it will stay forever in the final state..., or are there condituion under which it will die ? Jos At 05:15 PM 10-01-00 +0200, Eran Gery wrote: > > >> -----Original Message----- >> From: Jos Warmer [mailto:J.Warmer@klasse.nl] >> Sent: Monday, January 10, 2000 3:53 PM >> To: uml-rtf@omg.org >> Subject: Questions for State Machine package >> >> >> Hi there, >> >> I have two questions related to the State MAchine metamodel. >> Can anyone explain this ti me ? >> >> Regards, Jos >> ______________________________________________________________ >> ______________ >> ___ >> QUESTION 1 >> >> State Machines: >> >> Why is "FinalState" a separate metaclass ? >> >> It seems that a final state can be modeled as a kind of PseudoState >> (with PseudoStateKind = final). >> >> FinalState has no attributes of its own, and all >> associations inherited >> from State must be empty for a final state: >> - A final state cannot have an entry action >> - A final state cannot have an exit action >> - A final state cannot have an doActivity >> - A final state cannot have a deferrableEvent >> - A final state cannot have an internalTransition >> >> Could anybody explain the reason of existence for a >> FinalState metaclass ? > >In UML 1.2 that was indeed the case. Although finalState resembles a >pseudo state alot, there is one significant semantic difference: a final >state as oppose to other pseudo states is a real state it the sense that it >is not a transient node. All other pseodo states are transient nodes - >meaning that they are never a part of the active state configuration after a >run-to-completion. >A final state can be in the active state configuration for indefiniote >period, across indefinite number of RTC steps. >This is a major difference that justifies making the final state different >from a pseudo-state. > > > >> >> ______________________________________________________________ >> ______________ >> ___ >> QUESTION 2 >> >> State Machines >> >> The metaclass StateVertext, including its subclasses PseudoState, >> StubState and SyncState is not owned by a StateMachine. >> >> The associations from StateVertext to >> - container : CompositeState >> - outgoing : Transition >> - incoming : Tranision >> can all be empty. >> If they are all empty in a model, we do not know to which >> statemachine >> this StateVertex belongs. IS this the intention ? > >Obviously not... > >> >> Shouldn't there either be: >> - a rule that at least one of the above associations is not empty >> or >Indeed. The OCL should require that either the container is not empty unless >it is the top state. The top state is the state that (statemachine.top .eq. >state). > >Apropos, have you looked at other UML elements such as classes, operations >etc ? I doubt whether we force a well connected instance hierarchy across >the board. > > > >> - an explicit 'owns' association/aggregation between a >> StateMachine >> and StateVertex >> >> The same question applies to State, which can be >> 'stand-alone' as well. > > > > >> >> _____________________________________________________ >> Klasse Objecten tel : +31 (0)35 6037646 >> Chalonhof 153 fax : +31 (0)35 6037647 >> 3762 CT Soest email : J.Warmer@klasse.nl >> The Netherlands internet: http://www.klasse.nl >> > > > _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl X-Sender: genillou@dimail.epfl.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Tue, 11 Jan 2000 19:39:39 +0100 To: Jos Warmer , "Eran Gery" From: Guy Genilloud Subject: RE: Questions for State Machine package Cc: In-Reply-To: <3.0.6.32.20000111181027.00926100@pop3.NL.net> References: <006201bf5b7d$8852a360$0100007f@potato.ilogix.co.il> <3.0.6.32.20000110145230.009194a0@pop3.NL.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: 4):!!p38e9Eran, > >I have viewed a final state as a pseudo state, which means that >the object will die (destroy itself, ..). >If a final state is a real state, then an object is not destroyed >as a consequence of going to the final state. > >However, within a final state there are no outgoing transitions >and the object cannot handle events anymore. How does the object >die ? It seems that it will stay forever in the final state..., >or are there condituion under which it will die ? > >Jos Jos, here are my 2 cents worth. I hope they are useful to you. Objects have a property that they can be *reliably referenced*. CORBA IORs are reliable (at least, they are supposed to be, in the name of "referential integrity"). This means that if an object A has a reference x to another object X, then (within A) x will always denote X unless A affects another reference to x. Otherwise, we may speak of a violation of encapsulation. Is that clear? Now, let's address the deletion of X. The "referential integrity" of x should remain valid even after X is deleted or destroyed: x within A should always reference X somehow. At least, it should certainly not reference some other object. Somehow, an exception should be generated if A sends a message to a "dead" object. One way to do this would be to have the UML final state be a predefined state that generates the "I am dead" exception. Now, let's address the destruction/removal of objects. The rule should be: Only objects which are inactive and no longer referenced by other objects may be destroyed/removed... The above rules represent the "right thing" to do in the OO sense (as implied by the fundamental property of encapsulation). But not all OO programming languages do the right thing. This begs the question of what UML should do about those. Regards Guy -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) CH-1015 Lausanne, SWITZERLAND , tel: +41 21 693 46 57, fax: +41 21 693 66 10 X-Sender: jwarmer@pop3.NL.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 12 Jan 2000 10:25:07 +0100 To: Guy Genilloud From: Jos Warmer Subject: RE: Questions for State Machine package Cc: "Eran Gery" , In-Reply-To: <4.2.0.58.20000111191458.00be6830@dimail.epfl.ch> References: <3.0.6.32.20000111181027.00926100@pop3.NL.net> <006201bf5b7d$8852a360$0100007f@potato.ilogix.co.il> <3.0.6.32.20000110145230.009194a0@pop3.NL.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: NI;!!g\Vd92@id9WS^d9 Guy, At 07:39 PM 11-01-00 +0100, Guy Genilloud wrote: >At 18:10 11.01.00 +0100, Jos Warmer wrote: >here are my 2 cents worth. I hope they are useful to you. > >Objects have a property that they can be *reliably referenced*. CORBA IORs are >reliable (at least, they are supposed to be, in the name of "referential integrity"). > >This means that if an object A has a reference x to another object X, >then (within A) x will always denote X unless A affects another reference to x. >Otherwise, we may speak of a violation of encapsulation. >Is that clear? > >Now, let's address the deletion of X. >The "referential integrity" of x should remain valid even after X is deleted or destroyed: >x within A should always reference X somehow. At least, it should certainly not >reference some other object. > >Somehow, an exception should be generated if A sends a message to a "dead" object. >One way to do this would be to have the UML final state be a predefined state that >generates the "I am dead" exception. > Sounds interesting, but as of now the UML 1.3 (2.12.4) specifies that: FinalState When the final state is entered, its containing composite state is completed, which means that it satisfies the completion condition. If the containing state is the top state, the entire state machine terminates, implying the termination of the entity associated with the state machine. If the state machine specifies the behavior of a classifier, it implies th e of that instance. Thus, reaching a final state at the top of a statemachine will terminate the object. >Now, let's address the destruction/removal of objects. The rule should be: >Only objects which are inactive and no longer referenced by other objects may >be destroyed/removed... > >The above rules represent the "right thing" to do in the OO sense (as implied by the >fundamental property of encapsulation). > >But not all OO programming languages do the right thing. >This begs the question of what UML should do about those. > It does. >Regards > >Guy Regards, Jos _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl X-Sender: jwarmer@pop3.NL.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Wed, 12 Jan 2000 10:39:53 +0100 To: "Eran Gery" From: Jos Warmer Subject: RE: Questions for State Machine package Cc: In-Reply-To: <000601bf5c82$beadfa80$471c5ac2@potato.ilogix.co.il> References: <3.0.6.32.20000111181027.00926100@pop3.NL.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" X-UIDL: ]Fb!!Kf5e9-i@e9"hR!! Eran, I think that some of the confusion is coning from the fact that UML statecharts are viewed as describing actual implementations in the form of some statemachine. You might want to take a look at the RFI response of Alan Wills (Trireme) hwo requests that the commonly used 'descriptive interpretation' of statemachines should be explicitly included in the UML. From RFI Response Alan Wills / Trireme Statecharts - descriptive interpretation Currently, statecharts in UML prescribe an implementation in some form of state machine. A broader descriptive interpretation is much more widely useful. In this interpretation: - The presentation of a statechart for a class says nothing about its implementation. The purpose of the statechart is to show a plan of what sequences of operations or usecases make sense. For example, a statechart of Person could show that when single, the operation of marriage is possible; and when married, the operation of divorce is an option. - There is no canonical statechart for any class: it's up to the analyst/ designer to decide what she wants to tell her readers. Multiple statecharts may be used to describe a class. For example, we could also show the anesthetist's view of a Person's states: awake, asleep or dead. < ... etc ... > You might want to read his complete description at page 6 of his response. Regards, Jos _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl X-Sender: genillou@dimail.epfl.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Wed, 12 Jan 2000 17:46:38 +0100 To: Jos Warmer From: Guy Genilloud Subject: RE: Questions for State Machine package Cc: "Eran Gery" , In-Reply-To: <3.0.6.32.20000112102507.00923c30@pop3.NL.net> References: <4.2.0.58.20000111191458.00be6830@dimail.epfl.ch> <3.0.6.32.20000111181027.00926100@pop3.NL.net> <006201bf5b7d$8852a360$0100007f@potato.ilogix.co.il> <3.0.6.32.20000110145230.009194a0@pop3.NL.net> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: N8(e9T0C!!MK2!!36$!! At 10:25 12.01.00 +0100, Jos Warmer wrote: >Thus, reaching a final state at the top of a statemachine will terminate the >object. You are right. And UML says: "A terminate action results in self-destruction of an object." And elsewhere: "This means that the composite object is responsible for the creation and destruction of the parts. In implementation terms, it is responsible for their memory allocation." So, I make the following deductions: -- reaching a final state may yield to an object's destruction (say X) -- object destruction yields to memory deallocation -- the deallocated memory may be reallocated to a new object instance (say Y) -- if references are just pointers, then any reference to X has become a reference to Y, without any action by the objects who own these references in their states. -- UML LEAVES A HOLE IN OBJECT ENCAPSULATION Is this really the current state of affairs in UML 1.3? And if it is, shouldn't we do something about it? Personally, I don't think that object destruction should automatically lead to memory deallocation (at least one address position cannot be reused as long as it is still referenced)... Different languages do different things here, and some do the "right thing" with respect to object encapsulation. At the very least, UML should be compatible with those languages. Regards Guy From: Bran Selic To: "'Jos Warmer'" , Eran Gery Cc: uml-rtf@omg.org Subject: RE: Questions for State Machine package Date: Wed, 12 Jan 2000 22:17:49 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Z0?!!`M,!!CCIe9S&bd9 The semantics of existence (creation/termination) occur at a level that is distinct from the state machine itself -- this whole issue is being addressed in the action semantics submission. It would be wrong to address this issue in the context of state machines since the question of existence transcends state machines. As far as the state machine is concerned, when the final state in the top state is reached, it means that it will not receive or respond to any more events. In a broader context of UML semantics, it means that the thread of activity represented by the state machine specification is terminated (in case of active objects -- different rules apply for passive objects, but those have not been fully specified). Bran > -----Original Message----- > From: Jos Warmer [SMTP:J.Warmer@klasse.nl] > Sent: Tuesday, January 11, 2000 12:10 PM > To: Eran Gery > Cc: uml-rtf@omg.org > Subject: RE: Questions for State Machine package > > Eran, > > I have viewed a final state as a pseudo state, which means that > the object will die (destroy itself, ..). > If a final state is a real state, then an object is not destroyed > as a consequence of going to the final state. > > However, within a final state there are no outgoing transitions > and the object cannot handle events anymore. How does the object > die ? It seems that it will stay forever in the final state..., > or are there condituion under which it will die ? > > Jos > > At 05:15 PM 10-01-00 +0200, Eran Gery wrote: > > > > > >> -----Original Message----- > >> From: Jos Warmer [mailto:J.Warmer@klasse.nl] > >> Sent: Monday, January 10, 2000 3:53 PM > >> To: uml-rtf@omg.org > >> Subject: Questions for State Machine package > >> > >> > >> Hi there, > >> > >> I have two questions related to the State MAchine metamodel. > >> Can anyone explain this ti me ? > >> > >> Regards, Jos > >> ______________________________________________________________ > >> ______________ > >> ___ > >> QUESTION 1 > >> > >> State Machines: > >> > >> Why is "FinalState" a separate metaclass ? > >> > >> It seems that a final state can be modeled as a kind of > PseudoState > >> (with PseudoStateKind = final). > >> > >> FinalState has no attributes of its own, and all > >> associations inherited > >> from State must be empty for a final state: > >> - A final state cannot have an entry action > >> - A final state cannot have an exit action > >> - A final state cannot have an doActivity > >> - A final state cannot have a deferrableEvent > >> - A final state cannot have an internalTransition > >> > >> Could anybody explain the reason of existence for a > >> FinalState metaclass ? > > > >In UML 1.2 that was indeed the case. Although finalState resembles > a > >pseudo state alot, there is one significant semantic difference: a > final > >state as oppose to other pseudo states is a real state it the sense > that > it > >is not a transient node. All other pseodo states are transient > nodes - > >meaning that they are never a part of the active state > configuration > after a > >run-to-completion. > >A final state can be in the active state configuration for > indefiniote > >period, across indefinite number of RTC steps. > >This is a major difference that justifies making the final state > different > >from a pseudo-state. > > > > > > > >> > >> ______________________________________________________________ > >> ______________ > >> ___ > >> QUESTION 2 > >> > >> State Machines > >> > >> The metaclass StateVertext, including its subclasses > PseudoState, > >> StubState and SyncState is not owned by a StateMachine. > >> > >> The associations from StateVertext to > >> - container : CompositeState > >> - outgoing : Transition > >> - incoming : Tranision > >> can all be empty. > >> If they are all empty in a model, we do not know to which > >> statemachine > >> this StateVertex belongs. IS this the intention ? > > > >Obviously not... > > > >> > >> Shouldn't there either be: > >> - a rule that at least one of the above associations is not > empty > >> or > >Indeed. The OCL should require that either the container is not > empty > unless > >it is the top state. The top state is the state that > (statemachine.top > .eq. > >state). > > > >Apropos, have you looked at other UML elements such as classes, > operations > >etc ? I doubt whether we force a well connected instance hierarchy > across > >the board. > > > > > > > >> - an explicit 'owns' association/aggregation between a > >> StateMachine > >> and StateVertex > >> > >> The same question applies to State, which can be > >> 'stand-alone' as well. > > > > > > > > > >> > >> _____________________________________________________ > >> Klasse Objecten tel : +31 (0)35 6037646 > >> Chalonhof 153 fax : +31 (0)35 6037647 > >> 3762 CT Soest email : J.Warmer@klasse.nl > >> The Netherlands internet: http://www.klasse.nl > >> > > > > > > > > _____________________________________________________ > Klasse Objecten tel : +31 (0)35 6037646 > Chalonhof 153 fax : +31 (0)35 6037647 > 3762 CT Soest email : J.Warmer@klasse.nl > The Netherlands internet: http://www.klasse.nl From: Bran Selic To: "'Jos Warmer'" , Eran Gery Cc: uml-rtf@omg.org Subject: RE: Questions for State Machine package Date: Wed, 12 Jan 2000 22:23:26 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain; charset="iso-8859-1" X-UIDL: J];e9V,?!!@cN!!M'0!! In reply to: > -----Original Message----- > From: Jos Warmer [SMTP:J.Warmer@klasse.nl] > Sent: Wednesday, January 12, 2000 4:40 AM > To: Eran Gery > Cc: uml-rtf@omg.org > Subject: RE: Questions for State Machine package > > Eran, > > I think that some of the confusion is coning from the fact that UML > statecharts are viewed as describing actual implementations in the > form of some statemachine. [Bran Selic] I see no reason why this is the source of any confusion. The semantics of state machines in UML are defined in an operational manner (a common specification technique for defining semantics). This does not imply that implementations have to do it that way at all. > You might want to take a look at the RFI response of Alan Wills (Trireme) > hwo requests that the commonly used 'descriptive interpretation' of > statemachines should be explicitly included in the UML. > > From RFI Response Alan Wills / Trireme > > Statecharts - descriptive interpretation > > Currently, statecharts in UML prescribe an implementation in some form > of state machine. A broader descriptive interpretation is much more > widely > useful. In this interpretation: [Bran Selic] This is true, but that is because the current definition of state machines is incomplete: to date we have really only defined the semantics of state machines attached to active objects. Rather than define the "more general" semantics that Alan calls for, I think it is necessary to define the semantics of state machines for all the cases. I do not think that a universal general semantics would be all that useful. Bran From: Bran Selic To: "'Guy Genilloud'" , Jos Warmer Cc: Eran Gery , uml-rtf@omg.org Subject: RE: Questions for State Machine package Date: Wed, 12 Jan 2000 22:34:36 -0500 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2448.0) Content-Type: text/plain X-UIDL: S!O!!`^6e99R4!!5#l!! [Bran Selic] This whole discussion..... > So, I make the following deductions: > -- reaching a final state may yield to an object's destruction > (say X) > -- object destruction yields to memory deallocation > -- the deallocated memory may be reallocated to a new object > instance > (say Y) > -- if references are just pointers, then any reference to X has > become > a reference > to Y, without any action by the objects who own these > references in > their states. > -- UML LEAVES A HOLE IN OBJECT ENCAPSULATION [Bran Selic] ...is confused in that it mixes all kinds of semantic levels; from abstract semantics to technology-specific implementations. The fault is ours -- we made the mistake of talking about memory deallocation (a technology/implementation) in the context of state machines. This leaves readers with the impression that such issues are relevant (they are not at all relevant for defining the semantics of state machines, although they are certainly relevant for particular realizations of those semantics). Apologies for the confusion. > Is this really the current state of affairs in UML 1.3? [Bran Selic] Please do not view UML as a programming language. It's semantics leave room for one or more programming languages to be defined from it (e.g., using profiles); but as defined in 1.3, it is NOT a programming language. Bran X-Sender: genillou@dimail.epfl.ch X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Thu, 13 Jan 2000 11:32:14 +0100 To: Bran Selic , Jos Warmer From: Guy Genilloud Subject: RE: Questions for State Machine package Cc: Eran Gery , uml-rtf@omg.org In-Reply-To: Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" X-UIDL: =bXd9+*"e9Ll~!!FBM!! At 22:34 12.01.00 -0500, Bran Selic wrote: > [Bran Selic] > ...is confused in that it mixes all kinds of > semantic >levels; from abstract semantics to technology-specific > implementations. The >fault is ours -- we made the mistake of talking about memory > deallocation (a >technology/implementation) in the context of state machines. This > leaves >readers with the impression that such issues are relevant (they are > not at >all relevant for defining the semantics of state machines, although > they are >certainly relevant for particular realizations of those semantics). >Apologies for the confusion. [GG] I am glad you said this. Without checking, I'd say that UML 1.3 speaks of termination in the context of statemachine, object destruction in the context of a terminate action, and memory allocation in the context of creation/destruction. And it is naive when it talks of The question to be answered is: What is supposed to happen when an object A uses a reference x to interact (synchronously or asynchronously) with an objext X that terminated itself? The last thing that should happen is for A to end up interacting with an object Y it has never heard of... This is precisely what UML allows to happen now (by talking of memory allocation). As far as I know, UML is otherwise silent on the issue (???). > [Bran Selic] > Please do not view UML as a programming > language. It's >semantics leave room for one or more programming languages to be > defined >from it (e.g., using profiles); but as defined in 1.3, it is NOT a >programming language. [GG] I am quite happy to hear this. I certainly agree that UML 1.3 is not just a a programming language. But UML 1.3 IS a programming language WHEN it is used for 100% code generation. Otherwise, what do you think it is? I also agree that, with a lot of "good will" from the reader, UML is compatible with all OO programming languages, CORBA, components, relational databases schemas, conceptual modelling, business modelling, and whatever. Just speaking of programming languages, this raises several problems (data or no data, garbage collection or no garbage collection, strong identity or weak identity, novariance, covariance or contravariance, etc.). How can UML do "the right thing" for each language when they are many incompatibilities between OO programming languages. UML may take a different perspective and do "the right thing" in an OO sense. Right now, UML mostly does "the right thing" for C++. Quite a few people have said this before... UML will need a better mechanism than "good will" to deal with this issue. Profiles? Regards Guy -------------------------------------------------------------------- Dr. Guy Genilloud Institute for computer Communications and Applications (ICA) Swiss Federal Institute of Technology (EPFL) CH-1015 Lausanne, SWITZERLAND , tel: +41 21 693 46 57, fax: +41 21 693 66 10 X-Sender: jwarmer@pop3.NL.net X-Mailer: QUALCOMM Windows Eudora Light Version 3.0.6 (32) Date: Thu, 13 Jan 2000 21:48:11 +0100 To: "Eran Gery" From: Jos Warmer Subject: RE: Questions for State Machine package Cc: , "Guus Ramackers (E-mail)" In-Reply-To: <002f01be3eff$2690d0c0$471c5ac2@potato.ilogix.co.il> References: <3.0.6.32.20000112103953.009282f0@pop3.NL.net> Mime-Version: 1.0 Content-Transfer-Encoding: 8BIT Content-Type: text/plain; charset="iso-8859-1" X-UIDL: Q#sequence) in which the >operations of that Class can be invoked. The behavior of each of these >operations is defined by >an associated method, rather than through action expressions on >transitions". > >Eran. > > > > >> -----Original Message----- >> From: Jos Warmer [mailto:J.Warmer@klasse.nl] >> Sent: Wednesday, January 12, 2000 11:40 AM >> To: Eran Gery >> Cc: uml-rtf@omg.org >> Subject: RE: Questions for State Machine package >> >> >> Eran, >> >> I think that some of the confusion is coning from the fact that UML >> statecharts are viewed as describing actual implementations in the >> form of some statemachine. >> >> You might want to take a look at the RFI response of Alan >> Wills (Trireme) >> hwo requests that the commonly used 'descriptive interpretation' of >> statemachines should be explicitly included in the UML. >> >> From RFI Response Alan Wills / Trireme >> >> Statecharts - descriptive interpretation >> >> Currently, statecharts in UML prescribe an implementation >> in some form >> of state machine. A broader descriptive interpretation is >> much more widely >> useful. In this interpretation: >> - The presentation of a statechart for a class says >> nothing about its >> implementation. The purpose of the statechart is to show >> a plan of what >> sequences of operations or usecases make sense. For >> example, a statechart >> of Person could show that when single, the operation of >> marriage is >> possible; and when married, the operation of divorce is >> an option. >> - There is no canonical statechart for any class: it's up >> to the analyst/ >> designer to decide what she wants to tell her readers. Multiple >> statecharts >> may be used to describe a class. For example, we could also >> show the anesthetist's view of a Person's states: awake, >> asleep or dead. >> >> < ... etc ... > >> >> You might want to read his complete description at page 6 of >> his response. >> >> Regards, Jos >> >> _____________________________________________________ >> Klasse Objecten tel : +31 (0)35 6037646 >> Chalonhof 153 fax : +31 (0)35 6037647 >> 3762 CT Soest email : J.Warmer@klasse.nl >> The Netherlands internet: http://www.klasse.nl >> > > > _____________________________________________________ Klasse Objecten tel : +31 (0)35 6037646 Chalonhof 153 fax : +31 (0)35 6037647 3762 CT Soest email : J.Warmer@klasse.nl The Netherlands internet: http://www.klasse.nl protocol state machine view. What should be done, is a good description of the desired protocol state machine semantics. After that, we should either: - define both semantic interpretations as optional, i.e. the modeler needs to choose one. - make sure that the two semantics interpretations do not conflict. One (which ...?) _might_ be a specialization of the other. Regards, Jos At 04:15 PM 13-01-99 +0200, Eran Gery wrote: >Jos, >In general there's no clear border between "implementation" and >"specification", >but this is a philosophical debate. I agree that UML statechart provide a >complete imperative specification of the behavior rather than just the legal >sequences as proposed by Alan. > >That said, we've been fully aware that certain modelers wish to take the >abstract sequences approach, as coined by Guus as "protocol state machines". > >See p 189 in the semantics document. An excerpt from there: > >"One application area of state machines is in specifying object protocols, >also known as object OMG Issue 3202 Title: Another State machine issue Source: Klasse Objecten (Dr. Jos Warmer, j.warmer@klasse.nl) Summary: The metaclass StateVertext, including its subclasses PseudoState, StubState and SyncState is not owned by a StateMachine. The associations from StateVertext to - container : CompositeState - outgoing : Transition - incoming : Tranision can all be empty. If they are all empty in a model, we do not know to which statemachine this StateVertex belongs. IS this the intention ? Discussion: The issue described here is partially obsolete relative to the UML2.0 metamodel. The StateVertex is properly owned and can navigate back to its owning region. Disposition: closed, no change (resolved in UML2.0) >life cycles. A