Issue 6145: Action packaging (uml2-superstructure-ftf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Structured actions should depend on structured activities for variables. In general, actions should be in smaller packages to Resolution: see above Revised Text: Actions taken: August 30, 2003: received issue March 8, 2005: closed issue Discussion: See resolution of 7319. It introduces a separate package for actions requiring structured activities, and a basic actions package. End of Annotations:===== Name: Conrad Bock Company: NIST mailFrom: conrad.bock@nist.gov Nature: Revision Severity: Significant Subject: Action packaging Structured actions should depend on structured activities for Reply-To: From: "Conrad Bock" To: "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities Date: Sun, 9 May 2004 09:33:55 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi all, There are two issues here: - Packaging actions more finely (issue 6145) - Allowing vendors to define multiple, non-standard ways to coordinate actions that are redundant with the standard (Activities). Thomas is asking for the second under the guise of the first. Other comments below, Conrad Bran: > Our dependencies are all screwed up and do not follow a > natural semantically-ordered progression. This is issue 6145 (action packaging). Thomas' proposal is much more than that. Making an abstract Action that is separate from the Activities package means that vendors can define their own ways of connecting actions together. Thomas suggests this in his first message. So we would have multiple non-standard ways of coordinating actions that are redundant with the standard. > There is some common stuff underlying both actions and activities > that should be the foundation of both. I don't think either one is > the foundation of the other, Right, neither is more primitive: actions must be invoked and coordinated. > but, if I had to choose one, then actions -- being more primitive -- > would make the better foundation. Clearly, the current model of > activities, in all their gory glory, cannot be -- must not be -- the > foundation of other behaviors. That doesn't make sense. The foundation of behavior is a very tricky subject. You don't need all of activities, only BasicActivities, which was were we ended up after pulling in the things commonly used (flows, decisions, etc). Thomas: > The concept of action has nothing to do with ActivityNode. It is fundamental to actions that they are invoked. Actions are not useful unless they are given inputs and have a way of chaining outputs to inputs. have a standard way to do this. Making a separate actions package allows vendors to define their own. > Also, nobody is talking about reversing the clock here. Actually, during U2P you mentioned trying to chain together actions outside of activities and never came up with a proposal. This is just a throwback to that with no more preparation than you had before. > i. Interactions rely on actions alone, > as will state machines along the lines Eran is going right now. These need to thought through. In particular, how are actions invoked? What is the relation between activities and interactions (issue 6153: Interactions view of state machines/activities)? > You cannot use the time constraints without bringing in the > activities package. Didn't follow this. The time model doesn't require actions. > ii. It must be possible for profiles to leverage the action model > without bringing in all of activities. How will you prevent redundant, vendor-specified ways of invoking actions? > These are essential requirements that have not been completed. > Vendors who do not want to implement the activity model but want > to have the full interaction package including time constraints > are forced to implement the activities package. This is > unacceptable. The same is true if you want to use time > constraints on the state machines. > > If activities would have been structured more carefully, this > would be less of a problem. However, the BasicActivities package > is too much of a kitchen sink. > In addition, actions rely on StructuredActivities, for no apparent > reason. This is due to variables and is part of 6145 (action packaging). It doesn't require non-standard ways of coordinating actions. > a. Move some functionality of activities into actions as > explained earlier, or Not at all easy > b. Structure the activities package more carefully so as to not > force whole-scale import of unneeded metaclasses. Activities is already finely packaged. > Of course, this all worked much smoother when OutputPins were > ValueSpecifications (as in the earlier U2P model) rather than now > having that silly ValuePin addon... Oh well... That was the model that you never worked out. > Another possible change would be to break Activities into two > chapters.. A basic chapter, comprised of BasicActivities and > StructuredActivities, and a Complete chapter with the rest. It > is much easier to swallow that than the full glory of the > activites chapter. Of course, the dependencies should still be > reversed such that the actions are the foundation other packages > can leverage... This does not address the issue and makes the spec more complicated. Karl: > We would benefit in an RTF from any more info Thomas can offer > as to the use cases for modeling that he has in mind that could > be well served by disentangling Actions from Activities. A worked out proposal would be a good idea in the RTF. Joquin: > Remember, folks, that a change like this is a job for an FTF to do. > It is not in the scope of an RTF to turn the world upside down (or > right side up). The FTF shouldn't introduce such major new functionality, especially in a way that encourages vendors to make up their own semantics. From: "Thomas Weigert" To: , "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities Date: Sun, 9 May 2004 08:55:34 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Absolutely not. I don't think this type of strawman arguments are appropriate. It is a fact of the current model that anybody who wants to impose time constraints on arbitrary model elements using the simple time model must include all of BasicActivities and StructuredActivities, where they only want one actions. All I am proposing here is to invert the nonsensical arrangement of the package dependencies in the Activities chapter. Everywhere else in the UML we build up packages from primitive components so that other packages could also leverage these primitive components. Only the Activities package goes the opposite way and prevents any reuse of its primitive components. This is unacceptable even for the UML, but it makes matters worse for those who build profiles. It was a stated goal of the UML to support the development of profiles based on the UML, as by design the UML requires profiling. The activities chapter failed this goal in this respect. The frustrating thing is that it would be so simple to alleviate this huge usability issue. There are no technical obstacles, only emotional issues. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, May 09, 2004 8:34 AM > To: UML Superstructure FTF > Subject: RE: ,ac, ,av, Actions need to be independent from Activities > > > Hi all, > > There are two issues here: > > - Packaging actions more finely (issue 6145) > > - Allowing vendors to define multiple, non-standard ways to > coordinate actions that are redundant with the standard > (Activities). > > Thomas is asking for the second under the guise of the first. From: "Thomas Weigert" To: , "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities Date: Sun, 9 May 2004 08:59:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Incorrect. To use anything in Actions you need both BasicActivities and StructuredActivities. These packages have unnecessary elements in it if you are interested in actions only. It would be easy to split these elements out. What is even worse is that these are embedded in the activities chapter which is hard to read as it is due to its size. Finding what is relevant to the BasicActivities is not easy for any user, even those familiar with the subject matter. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, May 09, 2004 8:34 AM > To: UML Superstructure FTF > Subject: RE: ,ac, ,av, Actions need to be independent from Activities > > > > The foundation of behavior is a very tricky subject. You > don't need all > of activities, only BasicActivities, which was were we ended up after > pulling in the things commonly used (flows, decisions, etc). > > Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 May 2004 12:40:43 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,ac, ,av, Actions need to be independent from Activities For the first part of this message, kindly put aside practical considerations, and follow what i have to say about two things: theory and designs that feel good. I expect everyone, practical considerations aside, will agree with items 1 thru 3. If not, i trust i will hear about it. 1. The UML concept, Action, as proposed by Mellor, and adopted by OMG, is, should we want to use it in this way, a candidate for a primitive concept, which stands alone and can be used to build others. 2. It is possible instead, as the UML FAS under finalization now does, to take Activity as the starting point, and then define Action as a part of Activity. 3. Defining Action as a part of Activity does require that every action be found (as an executable activity node) in some activity. I suggest, and hope everyone will agree: 4a. If we take Action as an independent concept, then, through the wonders of our specification style, a box with the name, 'Action (from IntermediateActions)', can appear in BasicActivities. 4b. In that event, the only other change to the specification will be rewording the descriptions. 5. If we take Action as an independent concept, then, through the wonders of profiles, users of UML will be enabled to use UML Action in their particular style of behavior specification; if we don't, users are stuck inside Activity. .................... For the second part of this message, here are some questions: In practice: -------------- What are the practical advantages, for a user of UML, that favor saying that Activity is the foundation and Action is only a part of Activity? What is the intended effect of saying that Activity is the foundation and Action is only a part of Activity; what are we trying to accomplish by that? What damage is done to other packages of UML by allowing Action to stand alone? In theory: ----------- Doesn't it feel like solid theory and smell like good design to take Action as a fundamental concept, as the foundation for building all specifications of behavior; to let Activity be one use of Action? No disrespect intended to the solid work done on the Activities packages: Doesn't it feel like more-elaborate-than-necessary theory, doesn't it smell like not-the-cleanest-possible design to define Action ("the fundamental unit of behavior specification" [11.1]) as a particular kind of a node in Petri net ("an executable activity node" [12.3.1])? Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 09 May 2004 15:13:09 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,ac, ,av, Actions need to be independent from Activities [Joaquin] > Remember, folks, that a change like this is a job > for an FTF to do. > It is not in the scope of an RTF to turn the world upside down > (or right side up). [Conrad] The FTF shouldn't introduce such major new functionality, especially in a way that encourages vendors to make up their own semantics. As i tried to make clear in the message this is an excerpt from, my comment is simply an objection to the proposal that has been made, that this question should be deferred to an RTF. This is not a question that should be deferred to an RTF. Cordially, Joaquin To: Cc: "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 10 May 2004 17:53:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/10/2004 17:53:38, Serialize complete at 05/10/2004 17:53:38 After reviewing the contents of BasicActivities following Conrad's response, I must say that there is a lot less activity-specific stuff in that package than I had thought originally. So, I now better understand Conrad's point of view -- although I am not sure that the Petri-net-like formalism implied in this package is necessarily the best foundation for all the different forms of UML behavior that we want. Still, it is not unreasonable. Bran Reply-To: To: "Thomas Weigert" Cc: conrad.bock@nist.gov, "UML Superstructure FTF" Sensitivity: Subject: RE: ,ac, ,av, Actions need to be independent from Activities X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 10 May 2004 17:53:42 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/10/2004 17:53:47, Serialize complete at 05/10/2004 17:53:47 Thomas, I would like to analyze this problem as follows: (1) There are some elements in the various activities packages that actions depend on that really don't belong in any shared semantic layer (e.g., CentralBufferNode). However, after some inspection, it seems to me that there are not all that many such items; i.e., most of the stuff in these packages is indeed something that can be considered part of the general behavioral semantic base. In other words, they are meaningful for actions, state machines, activities, etc. (2) Another part of the problem is that some of these foundational things have the word "activity" in their package name and are contained in the overall Activities package. The solution to problem (1) is, as you say, a tricky one and would require some careful research to ensure that we only have the bare minimum required in the semantic foundation. But, as I said above, it seems that there are not too many of those and I am not convinced that we need to do anything about it at this point. The solution to problem (2) could be fixed with a bit of renaming and minor repackaging. That is, we could extract these packages into their own package outside of Activities and give them the proper names corresponding to their foundational role in the metamodel (which is equivalent, in my view, to what Infrastructure does for the structural side of things). Again, I am not convinced that this needs to be done right away, but, if someone comes up with a proposal, we could consider it. I think that this would solve your problem. Regards, Bran "Thomas Weigert" 05/09/2004 09:55 AM To , "UML Superstructure FTF" cc Subject RE: ,ac, ,av, Actions need to be independent from Activities Absolutely not. I don't think this type of strawman arguments are appropriate. It is a fact of the current model that anybody who wants to impose time constraints on arbitrary model elements using the simple time model must include all of BasicActivities and StructuredActivities, where they only want one actions. All I am proposing here is to invert the nonsensical arrangement of the package dependencies in the Activities chapter. Everywhere else in the UML we build up packages from primitive components so that other packages could also leverage these primitive components. Only the Activities package goes the opposite way and prevents any reuse of its primitive components. This is unacceptable even for the UML, but it makes matters worse for those who build profiles. It was a stated goal of the UML to support the development of profiles based on the UML, as by design the UML requires profiling. The activities chapter failed this goal in this respect. The frustrating thing is that it would be so simple to alleviate this huge usability issue. There are no technical obstacles, only emotional issues. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Sunday, May 09, 2004 8:34 AM > To: UML Superstructure FTF > Subject: RE: ,ac, ,av, Actions need to be independent from Activities > > > Hi all, > > There are two issues here: > > - Packaging actions more finely (issue 6145) > > - Allowing vendors to define multiple, non-standard ways to > coordinate actions that are redundant with the standard > (Activities). > > Thomas is asking for the second under the guise of the first. To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: ,ac, ,av, Actions need to be independent from Activities X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 10 May 2004 18:05:17 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/10/2004 18:05:23, Serialize complete at 05/10/2004 18:05:23 Joaquin, I think that you too are being misled by the term "activity" being used here when something more basic is implied. This more basic thing is something that can serve as the foundation of both actions and activities and, therefore, should not have had the term "activity" attached to it at all (the reason for this is mostly historical). The history of it goes like this: - when the action semantics were defined, a core foundation was defined for them that allowed modeling of both imperative and functional languages (that's the general part) - when activities were decoupled from state machines, they were based on a formalism that looked very similar to this foundational model of action semantics - this similarity was noticed and the two models were unified to have a common semantic base from which they could both spring forth independently of each other; unfortunately, the names of the packages were not changed to reflect the more general nature of these foundational concepts and they retained the 'activity' term. This is how I recall it. Bran Joaquin Miller 05/09/2004 03:40 PM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject RE: ,ac, ,av, Actions need to be independent from Activities For the first part of this message, kindly put aside practical considerations, and follow what i have to say about two things: theory and designs that feel good. I expect everyone, practical considerations aside, will agree with items 1 thru 3. If not, i trust i will hear about it. 1. The UML concept, Action, as proposed by Mellor, and adopted by OMG, is, should we want to use it in this way, a candidate for a primitive concept, which stands alone and can be used to build others. 2. It is possible instead, as the UML FAS under finalization now does, to take Activity as the starting point, and then define Action as a part of Activity. 3. Defining Action as a part of Activity does require that every action be found (as an executable activity node) in some activity. I suggest, and hope everyone will agree: 4a. If we take Action as an independent concept, then, through the wonders of our specification style, a box with the name, 'Action (from IntermediateActions)', can appear in BasicActivities. 4b. In that event, the only other change to the specification will be rewording the descriptions. 5. If we take Action as an independent concept, then, through the wonders of profiles, users of UML will be enabled to use UML Action in their particular style of behavior specification; if we don't, users are stuck inside Activity. .................... For the second part of this message, here are some questions: In practice: -------------- What are the practical advantages, for a user of UML, that favor saying that Activity is the foundation and Action is only a part of Activity? What is the intended effect of saying that Activity is the foundation and Action is only a part of Activity; what are we trying to accomplish by that? What damage is done to other packages of UML by allowing Action to stand alone? In theory: ----------- Doesn't it feel like solid theory and smell like good design to take Action as a fundamental concept, as the foundation for building all specifications of behavior; to let Activity be one use of Action? No disrespect intended to the solid work done on the Activities packages: Doesn't it feel like more-elaborate-than-necessary theory, doesn't it smell like not-the-cleanest-possible design to define Action ("the fundamental unit of behavior specification" [11.1]) as a particular kind of a node in Petri net ("an executable activity node" [12.3.1])? To: "Thomas Weigert" Cc: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 10 May 2004 18:12:09 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/10/2004 18:12:13, Serialize complete at 05/10/2004 18:12:13 Thomas, You said: > In addition, no new functionality is introduced by this suggestion. But, this suggestion changes the semantic foundation of actions. So, I am not sure that what you are saying is quite correct. Of course, it may be that you are unhappy with this semantic foundation -- although it is certainly more general with much more semantic richness and flexibility than starting off with something called 'action'. Perhaps, we can find a compromise here that allows those who dislike this foundation to have an escape: something along the lines of "primitive action", which would serve those who want to attach a different semantic foundation? I guess this is Conrad's second issue. However, if it gets us out of this controversy (which I see as being endless), perhaps that is a reasonable course of action (sorry about the pun ;-) Bran From: "Thomas Weigert" To: "Branislav Selic" , "Joaquin Miller" Cc: "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities Date: Mon, 10 May 2004 17:32:06 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, your construction of history is almost accurate... However, we did not complete the last step due to that Conrad wanted everything crammed into the activity chapter, for reasons, I believe, I don't feel is appropriate to go into here. NO COMMON SEMANTIC BASE WAS FORMED. Instead, one was declared to be the semantic base of the other, and in a ridiculously inverted way. The appropriate way to do this would have been to follow the line you describe below. There should be a common semantic base of both activities (for process modeling, work flow, etc.) and actions (for modeling of methods that are now done in programming languages and similar). Activities and Actions would inherit both from this semantic base. In addition, primitive actions need to be available from other packages (by primitive actions I mean the actions themselves, such as CallAction, SendAction, etc.). CommonBase would contain the foundation of the flow model. Actions combines CommonBase and PrimitiveActions. Activities adds the extra model elements and modifications to the flow semantics (streams, weights, etc.) as well as constructs such as partitions needed for Activity modeling. The appropriate package structure is shown below: -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, May 10, 2004 5:05 PM To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: ,ac, ,av, Actions need to be independent from Activities Joaquin, I think that you too are being misled by the term "activity" being used here when something more basic is implied. This more basic thing is something that can serve as the foundation of both actions and activities and, therefore, should not have had the term "activity" attached to it at all (the reason for this is mostly historical). The history of it goes like this: - when the action semantics were defined, a core foundation was defined for them that allowed modeling of both imperative and functional languages (that's the general part) - when activities were decoupled from state machines, they were based on a formalism that looked very similar to this foundational model of action semantics - this similarity was noticed and the two models were unified to have a common semantic base from which they could both spring forth independently of each other; unfortunately, the names of the packages were not changed to reflect the more general nature of these foundational concepts and they retained the 'activity' term. This is how I recall it. clip_image002.gif From: "Thomas Weigert" To: "Thomas Weigert" Cc: , "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities Date: Mon, 10 May 2004 17:40:35 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, I would appreciate if you would go back and reread the recent emails on this thread. I do not want to repeat again what already has been said. Contrary to what you suggest below, this is not just a big discussion about nothing. Your analysis fails at several grounds: 1. There is no shared semantic layer that could be referenced. Instead, actions have been jammed into the activity model. A shared semantic layer would have its own chapter and be reusable. It would not have to be carefully dug out from a 100+ page chapter more encompassing than my grandmothers kitchen sink. 2. You keep missing that access to the primitive actions (such as CallAction, SendSignalAction) without bringing in ANY of the flow model is critical for other behavioral elements and profile developers. 3. The naming is completely irrelevant. Whether it is called Activity or ActionSequence is of little concern. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, May 10, 2004 4:54 PM To: Thomas Weigert Cc: conrad.bock@nist.gov; UML Superstructure FTF Subject: RE: ,ac, ,av, Actions need to be independent from Activities Thomas, I would like to analyze this problem as follows: (1) There are some elements in the various activities packages that actions depend on that really don't belong in any shared semantic layer (e.g., CentralBufferNode). However, after some inspection, it seems to me that there are not all that many such items; i.e., most of the stuff in these packages is indeed something that can be considered part of the general behavioral semantic base. In other words, they are meaningful for actions, state machines, activities, etc. (2) Another part of the problem is that some of these foundational things have the word "activity" in their package name and are contained in the overall Activities package. The solution to problem (1) is, as you say, a tricky one and would require some careful research to ensure that we only have the bare minimum required in the semantic foundation. But, as I said above, it seems that there are not too many of those and I am not convinced that we need to do anything about it at this point. The solution to problem (2) could be fixed with a bit of renaming and minor repackaging. That is, we could extract these packages into their own package outside of Activities and give them the proper names corresponding to their foundational role in the metamodel (which is equivalent, in my view, to what Infrastructure does for the structural side of things). Again, I am not convinced that this needs to be done right away, but, if someone comes up with a proposal, we could consider it. To: "Thomas Weigert" Cc: conrad.bock@nist.gov, "Thomas Weigert" , "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Mon, 10 May 2004 18:58:35 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 05/10/2004 18:58:42, Serialize complete at 05/10/2004 18:58:42 Thomas, In reply: > I would appreciate if you would go back and reread the recent emails > on this thread. Actually, I did just that. And I sat down at took a careful look at parts of the spec I had only perused before. So, I am not quite talking through my hat. > I do not want to repeat again what already has been > said. Contrary to what you suggest below, this is not just a big > discussion about nothing. I did not say that it was about nothing. I do believe that we need to rearrange things and, in fact, I suggested two possible solutions that do that. One is a simple addition of something like "primitive action" and the other is a more extensive rearragement of packages (followed by a later even more extensive one where the chared foundation is rationalized). > Your analysis fails at several grounds: > > 1. There is no shared semantic layer that could be referenced. > Instead, actions have been jammed into the activity model. I think they are better separated than you may think. >From what I can see, the semantic foundation consists of BasicAcitivities, IntermediateActivities, and StructuredActivities. If we eliminate the word "Activities" from these package names (and some of the underlying metaclass names) and also take these things out from the overall Activities package -- I think we have the foundation that I am looking for. Or, at least, the start of one. > A shared > semantic layer would have its own chapter and be reusable. It would > not have to be carefully dug out from a 100+ page chapter more > encompassing than my grandmothers kitchen sink. Like I said, I think it's not as bad as you say. > 2. You keep missing that access to the primitive actions (such as > CallAction, SendSignalAction) without bringing in ANY of the flow > model is critical for other behavioral elements and profile developers. This is the part I disagree with -- although I did propose a compromise that allowed an alternative action model to be constructed that uses "primitive action" as the foundation. It seems to me that it is quite possible to have all the three packages included without a user seeing even a hint of something called "Activity" anywhere in their UML tool. This stuff is there to support the semantics of Actions, not Activities. OTOH, tool builders using a metamodel approach would definitely see these things, but they would need to anyway if they wanted to support the semantics of Actions. > 3. The naming is completely irrelevant. Whether it is called > Activity or ActionSequence is of little concern. I actually think that this is the biggest problem. If these packages had different names, such as BasicBehavior, IntermediateBehavior, and StructuredBehavior, I think there would be less to argue over. Cheers...Bran > -----Original Message----- > From: Branislav Selic [mailto:bselic@ca.ibm.com] > Sent: Monday, May 10, 2004 4:54 PM > To: Thomas Weigert > Cc: conrad.bock@nist.gov; UML Superstructure FTF > Subject: RE: ,ac, ,av, Actions need to be independent from Activities > > Thomas, > > I would like to analyze this problem as follows: > > (1) There are some elements in the various activities packages that > actions depend on that really don't belong in any shared semantic > layer (e.g., CentralBufferNode). However, after some inspection, it > seems to me that there are not all that many such items; i.e., most > of the stuff in these packages is indeed something that can be > considered part of the general behavioral semantic base. In other > words, they are meaningful for actions, state machines, activities, etc. > > (2) Another part of the problem is that some of these foundational > things have the word "activity" in their package name and are > contained in the overall Activities package. > > The solution to problem (1) is, as you say, a tricky one and would > require some careful research to ensure that we only have the bare > minimum required in the semantic foundation. But, as I said above, > it seems that there are not too many of those and I am not convinced > that we need to do anything about it at this point. > > The solution to problem (2) could be fixed with a bit of renaming > and minor repackaging. That is, we could extract these packages into > their own package outside of Activities and give them the proper > names corresponding to their foundational role in the metamodel > (which is equivalent, in my view, to what Infrastructure does for > the structural side of things). Again, I am not convinced that this > needs to be done right away, but, if someone comes up with a > proposal, we could consider it. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 10 May 2004 20:08:45 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: ,ac, ,av, Actions need to be independent from Activities I think that you too are being misled by the term "activity" being used here when something more basic is implied. Thanks, Bran. Your message copied below is illuminating. But, correct me if i am wrong, i appear also to be mislead by the fact that an action is specified to be a kind of an executable node (in an activity) [Figure 176]. If i understand the history, BasicBehaviors::Activity is not really activity. Right? If so, then the name is unfortunate. But in any case, an action is a kind of an executable node in a BasicActivities::activity (not in a BasicBehaviors::Activity). And i appear also to be mislead by the fact that BasicBehaviors::Activity and BasicActivities::Activity, are two ways to specify behavior, both distinct [Figure 312] from an interaction [Figure 326], or a state machine [Figure 354]. I do see the zeros on the black diamonds coming out of BasicActivities::Activity. Is that where we are hanging our hat? (I do also see that the activities in a state machine are BasicBehaviors::activities.) Cordially, Joaquin p.s. If i read the drawings correctly, there are no actions in an interaction [Figures 326 -331], except as part of the behavior of an execution occurrence, even though there is much discussion of actions at 14.3.4. It seems quite clear from the other drawings mentioned in the message above, that an action is not a behavior. (It is a node in one kind of behavior.) Branislav Selic wrote: Joaquin, I think that you too are being misled by the term "activity" being used here when something more basic is implied. This more basic thing is something that can serve as the foundation of both actions and activities and, therefore, should not have had the term "activity" attached to it at all (the reason for this is mostly historical). The history of it goes like this: - when the action semantics were defined, a core foundation was defined for them that allowed modeling of both imperative and functional languages (that's the general part) - when activities were decoupled from state machines, they were based on a formalism that looked very similar to this foundational model of action semantics - this similarity was noticed and the two models were unified to have a common semantic base from which they could both spring forth independently of each other; unfortunately, the names of the packages were not changed to reflect the more general nature of these foundational concepts and they retained the 'activity' term. This is how I recall it. Bran Joaquin Miller 05/09/2004 03:40 PM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject RE: ,ac, ,av, Actions need to be independent from Activities For the first part of this message, kindly put aside practical considerations, and follow what i have to say about two things: theory and designs that feel good. I expect everyone, practical considerations aside, will agree with items 1 thru 3. If not, i trust i will hear about it. 1. The UML concept, Action, as proposed by Mellor, and adopted by OMG, is, should we want to use it in this way, a candidate for a primitive concept, which stands alone and can be used to build others. 2. It is possible instead, as the UML FAS under finalization now does, to take Activity as the starting point, and then define Action as a part of Activity. 3. Defining Action as a part of Activity does require that every action be found (as an executable activity node) in some activity. I suggest, and hope everyone will agree: 4a. If we take Action as an independent concept, then, through the wonders of our specification style, a box with the name, 'Action (from IntermediateActions)', can appear in BasicActivities. 4b. In that event, the only other change to the specification will be rewording the descriptions. 5. If we take Action as an independent concept, then, through the wonders of profiles, users of UML will be enabled to use UML Action in their particular style of behavior specification; if we don't, users are stuck inside Activity. .................... For the second part of this message, here are some questions: In practice: -------------- What are the practical advantages, for a user of UML, that favor saying that Activity is the foundation and Action is only a part of Activity? What is the intended effect of saying that Activity is the foundation and Action is only a part of Activity; what are we trying to accomplish by that? What damage is done to other packages of UML by allowing Action to stand alone? In theory: ----------- Doesn't it feel like solid theory and smell like good design to take Action as a fundamental concept, as the foundation for building all specifications of behavior; to let Activity be one use of Action? No disrespect intended to the solid work done on the Activities packages: Doesn't it feel like more-elaborate-than-necessary theory, doesn't it smell like not-the-cleanest-possible design to define Action ("the fundamental unit of behavior specification" [11.1]) as a particular kind of a node in Petri net ("an executable activity node" [12.3.1])? Reply-To: From: "Conrad Bock" To: "UML Superstructure FTF" Subject: RE: ,ac, ,av, Actions need to be independent from Activities Date: Thu, 13 May 2004 17:11:11 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Actioneers, > [Joaquin] 1. The UML concept, Action, as proposed by Mellor, and > adopted by OMG, is, should we want to use it in this way, a candidate > for a primitive concept, which stands alone and can be used to build > others. An action is meaningless without a way to invoke it. Letting that be done in a vendor/profile-dependent way is not a good idea, see next. > 5. If we take Action as an independent concept, then, through the > wonders of profiles, users of UML will be enabled to use UML Action > in their particular style of behavior specification; if we don't, > users are stuck inside Activity. And they would reproduce ways the basic ways of controlling and passing data between actions that are already available in activities. It opens us up to serious fragmentation. > [Bran] After reviewing the contents of BasicActivities following > Conrad's response, I must say that there is a lot less activity-specific > stuff in that package than I had thought originally. And it's so basic that anything vendors and profilers come up with would be redundant with it. > [Thomas] i. Interactions rely on actions alone, as will state > machines along the lines Eran is going right now. I checked with Eran and all he's trying to is implement Figure 395 using uninterpreed actions and only Common Behavior. He can already do this using CommonBehavior::Activity, which has a text string for this purpose (or the new TextualBehavior if State Machines are changed to use Behavior). State machines uses Activity, not Action. As to the other packages: In interactions, the only dependence I can find is InteractionOccurrence on InputPin, and hardly any semantics is given for that. It says this is for actual arguments, but that isn't what pins are, so this part of the model needs to be rethought. SimpleTime defines some actions for reading time that probably should be put in a separate package. Like all actions, they need to be invoked, which is what activities do. > > there are two issues here: > > > > - Packaging actions more finely (issue 6145) > > > > - Allowing vendors to define multiple, non-standard ways to > > coordinate actions that are redundant with the standard > > (Activities). > > > > Thomas is asking for the second under the guise of the first. > Absolutely not. OK, perhaps you can tell me what your comments mean exactly: 1. > Each action independently has a well defined meaning. It starts when > there is data on its input pins and control flows (if any) and > produces values in its output pins. There are no flows needed to > understand an individual action. Ie, you want to put values in pins and take them off in some other way than activity flows. This isn't defined anywhere. Will vendors invent their own ways of invoking actions? 2. > Of course, this all worked much smoother when OutputPins were > ValueSpecifications (as in the earlier U2P model) rather than now > having that silly ValuePin addon... Oh well... This was an internal U2P activity workgroup proposal that you never worked out to connect actions together outside activities, to use to calculate value specifications. > To use anything in Actions you need both BasicActivities and > StructuredActivities. These packages have unnecessary elements in it if you > are interested in actions only. It would be easy to split these elements > out. That's a separate issue (6145). You don't need to remove Action from Activities to structure Actions properly. > The frustrating thing is that it would be so simple to alleviate this > huge usability issue. There are no technical obstacles, only > emotional issues. Clearly, given your adjectives like "jammed", "ridiculous", etc, this issue would probably disappear if you could answer the technical points and reduce the handwaving about semantic basis. Your proposals are even less worked out than during the U2P. variables. In general, actions should be in smaller packages to