Issue 7620: Coupling between StateMachines and Activities (uml2-rtf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: 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. Resolution: Disposition: Deferred to UML 2.4 RTF Revised Text: Actions taken: August 4, 2004: received issue Discussion: This is deferred for the same reasons as 6114. Due to lack of time, the RTF/FTF agrees that the following are problems that need fixing, but decided to defer their resolution to a future RTF working on this specification. End of Annotations:===== c: uml2-superstructure-ftf@omg.org Subject: Coupling between StateMachines and Activities X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 4 Aug 2004 14:47:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/04/2004 14:47:12, Serialize complete at 08/04/2004 14:47:12 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, Reply-To: From: "Conrad Bock" To: Subject: RE: Coupling between StateMachines and Activities Date: Fri, 6 Aug 2004 14:49:20 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > Apologies for the ill-chosen term. Likewise for my pressing "send" too quickly. > > Sure, and the action/activity separation was alot of work, too. We > > could done it "pragmatically" by referring to activities by their names > > from actions. > > Well, we snuck that one in just under the wire. But there is no > hope of getting the unpackaging of state machines done in this > FTF cycle. I think you will agree with that. I would, but then w can just defer. > It's a lot more work than the action/activity separation, and it has > a lot more folks who care about it (at present -- it will change for > sure in the future). That part I wouldn't agree with, but it's another matter. Activities are one of the fundamental parts of the BPM and SyML work. > > No, they need it synchronized with the state machine of the object. If > > the state is deleted, or changes names, the object node needs to be > > updated. We could of course replace all references to model elements > > with strings, and force vendors to search and match names to do this > > sort of updating, but that isn't how we do it. We use direct > > references. > > I can't comment on that since you know that user base a lot > better than I. What percentage of users use both state machines > and activities at the same time in this tightly-coupled way? The modeling of orders often has states, and it's a desginer's choice whether to model the order as a state machine. BPMers generally take the process approach, of course, but we shouldn't prevent synchronization with state models. > I think that in this type of detailed discussion, my main point > is getting lost: there is a distinct advantage in not coupling > different behavioral formalisms. In fact, one of the first > things we did in UML 2 was try to separate state machines from > activity graphs, so it is somewhat ironic that we are now > advocating to do precisely that. I appreciate the irony, actually, which is why I would like to address it by making a special kind of type that included constraints, including constraints on state. This could be used generally, not just in activities, to define reusable types for attributes, parameter, etc. > > OK, then my recommendation will be to defer it. > > ...which will, of course, lead to the problem I was trying to > avoid. But, from your replies, it appears to me that this is not > a point on which you are willing to compromise. We'll just have > to vote on it, I guess. That's what voting is for. Again, sorry for the too-quick replies. Conrad Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 06 Aug 2004 14:06:03 -0700 To: From: Joaquin Miller Subject: RE: Coupling between StateMachines and Activities Cc: > There is a distinct advantage in not coupling > different behavioral formalisms. In fact, one of the first > things we did in UML 2 was try to separate state machines from > activity graphs, so it is somewhat ironic that we are now > advocating to do precisely that. I appreciate the irony, actually, which is why I would like to address it by making a special kind of type that included constraints, including constraints on state. This could be used generally, not just in activities, to define reusable types for attributes, parameter, etc. If we were to define state as it is defined in 3C UML, or something along those lines, then it will be trivial to specify activities and state machines independently. (If the question is: would we then want two subtypes, one for state machines and one for activities, the answer is: No, we would not want that. If, on the other hand, the question is: would we then need two subtypes, one for state machines and one for activities, that's a technical question we would have to look at. My feeling is that the answer is: No, we would not need those: we can define state independently of both activities and state machines, in a way that is suitable for both and also for other uses.) I feel this fits with both what Bran writes above and what Conrad writes there. Cordially, Joaquin Bran