Issue 6114: State extension (uml2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: State should be an extension of type rather than object node. Resolution: Disposition: Deferred to UML 2.4 RTF Revised Text: Actions taken: August 30, 2003: received issue February 20, 2015: closed issue Discussion: Discussion This issue has already been resolved by, or no longer applies to, the UML 2.5 Beta 1 specification. Disposition: Closed - No Change End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: State extension From: "Thomas Weigert" To: "Branislav Selic" , Cc: Subject: RE: Coupling between StateMachines and Activities Date: Wed, 4 Aug 2004 14:08:50 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Good suggestion... Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 04, 2004 1:47 PM To: conrad.bock@nist.gov Cc: uml2-superstructure-ftf@omg.org Subject: Coupling between StateMachines and Activities Conrad, As I was reading through the text of issue 6114 it dawned on me that there is a needless and problematic coupling between state machines and activities. Namely, in figure 187, there is an association from ObjectNode to State, presumably to deal with the old "object in state" idea. This is similar to the coupling that was attempted but rejected in the Interactions chapter. While it may look attractive to have a formal link to the idea of State from state machines, there are two serious problems that make this much more trouble than it's worth: (1) The notion of "object state" -- as seen by users/manipulators of that object -- could be completely different from the implementation state of that object. This is the old principle of hiding implementation. Viewed from the outside, an invoice object may be in the "Paid" state, but this does not necessarily mean that the object has such a state in its implementation. In fact, there is no guarantee that the implementation will be based on state machines at all. Of course, you can say that this is a reference to some kind of external state machine view of an object -- which sounds reasonable, but here is where the second problem comes in: (2) State in the UML 2.0 spec comes with a sh..load of baggage: in effect, the whole state machine kit and caboodle. It's not very modular, and, unless you use profiles to shear away all the stuff that you don't want (which is about 99% of state machines machinery), you will force vendors who innocently just want to support the simple idea of "object in state" to implement all of state machines. Like I say, the feature doesn't look worth it. Let your State concept be a simple name. My guess is that most users who want to use this feature don't even want to know what a state machine is (the concept of states is not necessarily linked to state machines!). So, my suggestion is that in figure 187, you simply provide a subclass of ObjectNode called ObjectInState and give it a "stateName" attribute and you will get what 95% of your users want. Tying state machines to activities for that one little feature seems overkill. Regards, Bran Reply-To: From: "Conrad Bock" To: Subject: RE: Coupling between StateMachines and Activities Date: Wed, 4 Aug 2004 16:16:44 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > As I was reading through the text of issue 6114 it dawned on me that > there is a needless and problematic coupling between state machines > and activities. Namely, in figure 187, there is an association from > ObjectNode to State, presumably to deal with the old "object in > state" idea. This is similar to the coupling that was attempted but > rejected in the Interactions chapter. It is accepted practice for activities. > (1) The notion of "object state" -- as seen by > users/manipulators of that object -- could be completely > different from the implementation state of that object. Sure, but this refers to the public view of the object's state. > (2) State in the UML 2.0 spec comes with a sh..load of baggage: > in effect, the whole state machine kit and caboodle. That's a packaging issue, which Steve M filed an issue on. > Like I say, the feature doesn't look worth it. Let your State > concept be a simple name. My guess is that most users who want > to use this feature don't even want to know what a state machine > is (the concept of states is not necessarily linked to state machines!). > > So, my suggestion is that in figure 187, you simply provide a > subclass of ObjectNode called ObjectInState and give it a > "stateName" attribute and you will get what 95% of your users > want. Tying state machines to activities for that one little > feature seems overkill. Referencing metaclasses by name is not a good idea. I'd say 95% is a how many users would not want it. If the propblem can't be fixed properly now, then defer it. Feel free to reassign it to activities. Conrad To: Cc: uml2-superstructure-ftf@omg.org Subject: RE: Coupling between StateMachines and Activities X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 4 Aug 2004 16:49:26 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/04/2004 16:49:26, Serialize complete at 08/04/2004 16:49:26 > > As I was reading through the text of issue 6114 it dawned on me that > > there is a needless and problematic coupling between state machines > > and activities. Namely, in figure 187, there is an association from > > ObjectNode to State, presumably to deal with the old "object in > > state" idea. This is similar to the coupling that was attempted but > > rejected in the Interactions chapter. > > It is accepted practice for activities. I don't understand: it is accepted practice in activities to introduce tight coupling? > > (1) The notion of "object state" -- as seen by > > users/manipulators of that object -- could be completely > > different from the implementation state of that object. > > Sure, but this refers to the public view of the object's state. But, tell me if I'm wrong: My guess is that most people want to put the name of a state on here and that's it. I think that many of them don't even want to know about the state machine that's behind the name. My experience with business modeling, for instance, is that people are very much aware of the notion of state, but not of state machines. This is because the state machine in most cases is simply a linear progression from one state to another with, possibly, one exception state. However, my point is not that they don't necessarily need state machines, but that those who don't need them shouldn't have to get them by default. > > (2) State in the UML 2.0 spec comes with a sh..load of baggage: > > in effect, the whole state machine kit and caboodle. > > That's a packaging issue, which Steve M filed an issue on. That's a cop out. The "packaging issue" is going to take a long time to resolve but the consequences of your choice here are going to be immediate with long-term negative consequences. I am looking for a pragmatic tradeoff. > > Like I say, the feature doesn't look worth it. Let your State > > concept be a simple name. My guess is that most users who want > > to use this feature don't even want to know what a state machine > > is (the concept of states is not necessarily linked to state machines!). > > > > So, my suggestion is that in figure 187, you simply provide a > > subclass of ObjectNode called ObjectInState and give it a > > "stateName" attribute and you will get what 95% of your users > > want. Tying state machines to activities for that one little > > feature seems overkill. > > Referencing metaclasses by name is not a good idea. I'd say 95% is a > how many users would not want it. Sorry, there must be some miscommunication here. I was not suggesting that the "stateName" be a reference to a metaclass, but simply a string that is the name of the application object state. > If the propblem can't be fixed properly now, then defer it. Feel free > to reassign it to activities. The issue is already assigned to Activities. I only spotted it as part of my overall review of remaining unresolved issues. I would much prefer to resolve it now, because of the negative effects of the way it currently is. I think that it is a very bad idea to couple our high-level behavioral formalisms -- especially for something so lightweight as this. Please reconsider. Thanks...Bran Date: Wed, 04 Aug 2004 17:06:29 -0400 From: Jishnu Mukerji Organization: Hewlett-Packard SGBU/MSO User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.6) Gecko/20040113 X-Accept-Language: en-us, en To: Branislav Selic Cc: conrad.bock@nist.gov, uml2-superstructure-ftf@omg.org Subject: Re: Coupling between StateMachines and Activities +1 I generally agree with Bran's position such as I understand it, on this one. Jishnu. Branislav Selic wrote: > > As I was reading through the text of issue 6114 it dawned on me that > > there is a needless and problematic coupling between state machines > > and activities. Namely, in figure 187, there is an association from > > ObjectNode to State, presumably to deal with the old "object in > > state" idea. This is similar to the coupling that was attempted but > > rejected in the Interactions chapter. > > It is accepted practice for activities. I don't understand: it is accepted practice in activities to introduce tight coupling? > > (1) The notion of "object state" -- as seen by > > users/manipulators of that object -- could be completely > > different from the implementation state of that object. > > Sure, but this refers to the public view of the object's state. But, tell me if I'm wrong: My guess is that most people want to put the name of a state on here and that's it. I think that many of them don't even want to know about the state machine that's behind the name. My experience with business modeling, for instance, is that people are very much aware of the notion of state, but not of state machines. This is because the state machine in most cases is simply a linear progression from one state to another with, possibly, one exception state. However, my point is not that they don't necessarily need state machines, but that those who don't need them shouldn't have to get them by default. > > (2) State in the UML 2.0 spec comes with a sh..load of baggage: > > in effect, the whole state machine kit and caboodle. > > That's a packaging issue, which Steve M filed an issue on. That's a cop out. The "packaging issue" is going to take a long time to resolve but the consequences of your choice here are going to be immediate with long-term negative consequences. I am looking for a pragmatic tradeoff. > > Like I say, the feature doesn't look worth it. Let your State > > concept be a simple name. My guess is that most users who want > > to use this feature don't even want to know what a state machine > > is (the concept of states is not necessarily linked to state machines!). > > > > So, my suggestion is that in figure 187, you simply provide a > > subclass of ObjectNode called ObjectInState and give it a > > "stateName" attribute and you will get what 95% of your users > > want. Tying state machines to activities for that one little > > feature seems overkill. > > Referencing metaclasses by name is not a good idea. I'd say 95% is a > how many users would not want it. Sorry, there must be some miscommunication here. I was not suggesting that the "stateName" be a reference to a metaclass, but simply a string that is the name of the application object state. > If the propblem can't be fixed properly now, then defer it. Feel free > to reassign it to activities. The issue is already assigned to Activities. I only spotted it as part of my overall review of remaining unresolved issues. I would much prefer to resolve it now, because of the negative effects of the way it currently is. I think that it is a very bad idea to couple our high-level behavioral formalisms -- especially for something so lightweight as this. Please reconsider. Thanks...Bran State should be an extension of type rather than object node.