Issue 6902: UML 2 Super / General / Idenitfy sections specifying run-time semantics (uml2-superstructure-ftf) Source: Simula Research Laboratory (Mr. Bran Selic, selic(at)acm.org) Nature: Uncategorized Issue Severity: Summary: The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections. Resolution: see above Revised Text: Actions taken: January 15, 2004: received issue March 8, 2005: closed issue Discussion: Insert the following text after the last paragraph of section 6.2. 6.3 On the Run-Time Semantics of UML The purpose of this section of the document is to provide a very high- level view of the run-time semantics of UML and to point out where the various elements of that view are covered in the spec. The term “run-time” is used to refer to the execution environment. Run-time semantics, therefore, are specified as a mapping of modeling concepts into corresponding program execution phenomena. There are, of course, other semantics relevant to UML specifications, such as the repository semantics, that is, how a UML model behaves in a model repository. However, those semantics are really part of the definition of the MOF. Still, it is worth remarking that not every concept in UML models a run-time phenomenon (e.g., the “package” concept). 6.3.1 The Basic Premises There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called “active” objects (see definition on page 387). This includes behaviors, which are objects in UML 2, which can be active and coordinate other behaviors. The second is that UML behavioral semantics only deal with event-driven, or discrete, behaviors. However, UML does not dictate the amount of time between events, which can be as small as needed by the application, for example, when simulating continuous behaviors. 6.3.2 The Semantics Architecture Fig. 1 identifies the key semantic areas covered by the current standard and how they relate to each other. The items in the upper layers depend on the items in the lower layers but not the other way around. (Note that the struc ture of metamodel package dependencies is somewhat similar to the dependency structure indicated here. However, they are not the same and should be distinguished. This is because package dependencies specify repository dependencies not necessarily run-time dependencies.) Fig. 1. A schematic of the UML semantic areas and their dependencies At the highest level of abstraction, it is possible to distinguish three distinct composite layers of semantic definitions. The foundational layer is struc tural. This reflects the premise that there is no disembodied behavior in UML – all behavior is the consequence of the actions of structural entities. The next layer is behavioral and provides the foundation for the semantic description of all the higher- level behavioral formalisms (the term “behavioral formalism” refers to a formalized framework for describing behavior, such as state machines, Petri nets, data flow graphs, etc.). This layer, represented by the shaded box in Fig. 1, is the behavioral semantic base and consists of three separate sub-areas arranged into two sub- layers. The bottom sub- layer consists of the inter-object behavior base, which deals with how structural entities communicate with each other, and the intra-object behavior base, which addresses the behavior occurring within structural entities. The actions sub- layer is placed on top of these two. It defines the semantics of individual actions. Actions are the fundamental units of behavior in UML and are used to define fine-grained behaviors. Their resolution and expressive power are comparable to the executable instructions in traditional programming languages. Actions in this sub- layer are available to any of the higher- level formalisms to be used for describing detailed behaviors. The topmost layer in the semantics hierarchy defines the semantics of the higher-level behavioral formalisms of UML: activities, state machines, and interactions. Other behavioral formalisms may be added to this layer in the future. 6.3.3 The Basic Causality Model The “causality model” is a specification how things happen at run time and is described in detail in the Common Behaviors chapter on page 369. It is briefly summarized here for convenience, using the example depicted in the communication diagram in Fig. 2. The example shows two independent and possibly concurrent threads of causally chained interactions. The first, identified by the thread prefix ’A’ consists of a sequence of events that commence with activeObject-1 sending signal s1 to activeObject-2. In turn, activeObject-2 responds by invoking operation op1( ) on passiveObject-1 after which it sends signal s2 to activeObject- 3. The second thread, distinguished by the thread prefix ‘B’, starts with activeObject-4 invoking operation op2( ) on passiveObject-1. The latter responds by executing the method that realizes this operation in which it sends signal s3 to activeObject-2. The causality model is quite straightforward: objects respond to messages that are generated by objects executing communication actions. When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. The dispatching method by which a particular behavior is associated with a given message depends on the higher- level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). Fig. 2. Example illustrating the basic causality model of UML The causality model also subsumes behaviors invoking each other and passing information to each other through arguments to parameters of the invoked behavior, as enabled by CallBehaviorAction (see definition on page ??EDITOR). This purely “procedural” or “process” model can be used by itself or in conjunction with the object-oriented model of the previous example. 6.3.4 Semantics Descriptions in the Specification The general causality model is described in the introductory part of chapter 13 (CommonBehaviors) and also, in part, in the introduction to chapter 14 (Interactions) and the section on Interaction (14.3.7) and Message (14.3.14) The structural foundations are mostly covered in two chapters. The elementary level is mostly covered in chapter 7, where the root concepts of UML are specified. In particular, the sections on InstanceSpecifications (section 7.7 of the FAS), Classes and Associations (section 7.11), and Features (section 7.9). The composites level is described primarily in chapter 9 (Composite Structures), with most of the information related to semantics contained in sections 9.3.12 (Property concept) and 9.3.13 (StructuredClassifier). In addition, the introduction to this chapter contains a high- level view of some aspects of composite structures. The relationship between structure and behavior and the general properties of the Behavior concept, which are at the core of the behavioral base are described in CommonBehaviors (in the introduction to chapter 13 and in section 13.3.3 in particular). Inter-object behavior is covered in three separate chapters. The basic semantics of communications actions are described in the introduction to chapter 11 (Actions) and, in more detail, in the sections describing the specific actions. These can potentially be used by an object on itself, so can be inter- or intra-object . The read/write actions can also be used to by one object to access others objects, so are potentially inter- or intra-object. These actions can be used by any of the behavior formalisms in UML, so all are potentially inter-object behaviors. However, the interactions diagram is designed specifically to highlight interobject behavior, under its concept of message. These are defined in the Interactions chapter (sections 14.3.14 and 14.3.15), while the concepts of events and triggers are defined in the Communications package of CommonBehaviors (chapter 13). Event occurrences are defined in section 14.3.3 of the Interactions chapter. The other two behavior formalisms can be translated to interactions when they use inter-object actions. All the behavior formalisms are potentially intra-object, if they are specified to be executed by and access only one object. However, state machines are designed specifically to model the state of a single object and respond to events arriving at that object. Activities can be used in a similar way, but also highlight input and output dependency between behaviors, which may reside in multiple objects. Interactions are potentially intra-object, but generally not designed for that purpose. The various shared actions and their semantics are described in chapter 11. Finally, the higher- level behavioral formalisms are each described in their own chapters: Activities in chapter 12, Interactions in chapter 14, and State Machines in chapter 15. End of Annotations:===== ubject: UML 2 Super / General / Idenitfy sections specifying run-time semantics X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: Branislav Selic Date: Thu, 15 Jan 2004 12:03:30 -0500 X-MIMETrack: Serialize by Router on D25ML05/25/M/IBM(Release 6.0.2CF1|June 9, 2003) at 01/15/2004 12:03:31, Serialize complete at 01/15/2004 12:03:31 The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections. Bran Selic Distinguished Engineer IBM Rational Software To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: UML Run-time semantics: resolution proposal for ballot 22 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 2 Aug 2004 18:11:17 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/02/2004 18:11:31 Several months ago, I promised tha I would write a section in the spec that would identify clearly where the various sections that describe the run-time semantics of UML are located. This was raised as an issue (6902) and the attachment contains my proposed resolution to this. It attempts to do two things: (1) Identifies the key semantic domains of UML and their mutual relationships and (2) maps the above to specific sections of the Superstructure spec I realize that something like this can be contentious, but I felt that it was important to include this in the document for a variety of reasons. In addition to the obvious pedagogical ones, there is the problem of dispelling the inaccurate statement that have been plaguing our work that UML has little or no semantics or that what it has is without rhyme or reason. So, I am sure all of you will have your own view of this, and, like medieval scholastics, we could spend many, many months discussing the finer points of this and neve reach agreement. But, i don't plan to. Either people will feel comfortable with the broad outlines specified in this resolution (suggestions on improvements to style and minor improvements to content are more than welcome), or I will simply chuck it all and defer the resolution to an RTF. That is, I do not plan to spend much more time on this issue beyond what I have done already. Specifically, if you want to argue theology with me, forget it. Write your own resolution and I will withdraw mine. Cheers, Bran OMG Issue No.6902.040802.doc OMG Issue No: 6902 Title: UML 2 Super / General / Idenitfy sections specifying run-time semantics Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections. Discussion: Insert the following text after the last paragraph of section 6.2. 6.3 On the Run-Time Semantics of UML Due to its primary role as a reference, this specification is structured according to subject area, within which the relevant concepts are (usually) sorted in alphabetical order (see section 6.3.1 for an explanation of this format). While this organization is convenient for tool implementers and researchers interested in the finer points of individual modeling concepts, it is certainly not conducive for pedagogical purposes. In particular, it has been noted that it is very difficult to gain a high-level understanding of UML semantics merely from reading the fragmented .semantics. subsections attached to most modeling concept descriptions. The purpose of this section of the document is to provide a very high-level view of the run-time semantics of UML and to map out where the various elements of that view are covered in the spec. The term .run-time. is used to refer to the execution environment. Run-time semantics, therefore, are specified as a mapping of modeling concepts into corresponding program execution phenomena. There are, of course, other semantics relevant to UML specifications, such as the repository semantics, that is, how a UML model behaves in a model repository. However, those semantics are really part of the definition of the MOF. Still, it is worth remarking that not every concept in UML models a run-time phenomenon (e.g., the .package. concept). 6.3.1 The Basic Premises There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called .active. objects (see definition on page 387). The second is that UML behavioral semantics only deal with event-driven, or discrete, behaviors. This means that continuous behaviors, such as found in many physical systems, are not supported. To be sure, this capability is not precluded, and it is likely that extensions will be defined to provide it. 6.3.2 The Semantics Architecture Fig. 1 identifies the key semantics domains covered by the current standard and how they relate to each other. The items in the upper layers depend on the items in the lower layers but not the other way around. (Note that the structure of metamodel package dependencies is somewhat similar to the dependency structure indicated here. However, they are not the same and should be distinguished. This is because package dependencies specify repository dependencies not necessarily run-time dependencies.) Fig. 1. A schematic of the UML semantics domains and their dependencies At the highest level of abstraction, it is possible to distinguish three distinct composite layers of semantic domains. The foundational layer is structural. This reflects the premise that there is no disembodied behavior in UML . all behavior is the consequence of the actions of structural entities. The next layer is behavioral and provides the foundation for the semantic description of all the higher-level behavioral formalisms (the term .behavioral formalism. (e.g., state machines, Petri nets, data flow graphs) refers to a formalized paradigm for describing certain categories of behavior). This layer, represented by the shaded box in Fig. 1, is the behavioral semantic base and consists of three separate sub-areas arranged into two sub-layers. The bottom sub-layer consists of the inter-object behavior base, which deals with how structural entities communicate with each other, and the intra-object behavior base, which addresses the behavior occurring within structural entities. The actions sub-layer is placed on top of these two. It defines the semantics of individual actions. Actions are the fundamental units of behavior in UML and are used to define fine-grained behaviors. Their resolution and expressive power are comparable to the executable instructions in traditional programming languages. Actions in this sub-layer are available to any of the higher-level formalisms to be used for describing detailed behaviors. The topmost layer in the semantics hierarchy defines the semantics of the higher-level behavioral formalisms of UML: activities, state machines, and interactions. Other behavioral formalisms may be added to this layer in the future. 6.3.3 The Basic Causality Model The .causality model. is a specification how things happen at run time and is described in detail in the Common Behaviors chapter on page 369. It is briefly summarized here for convenience, using the example depicted in the collaboration diagram in Fig. 2. The example shows two independent and possibly concurrent threads of causally chained interactions. The first, identified by the thread prefix .A. consists of a sequence of events that commence with ActiveObject-1 sending signal s1 to ActiveObject-2. In turn, ActiveObject-2 responds by invoking operation op1( ) on PasiveObject-1 after which it sends signal s2 to ActiveObject-3. The second thread, distinguished by the thread prefix .B., starts with ActiveObject-4 invoking operation op2( ) on PasiveObject-1. The latter responds by executing the method that realizes this operation in which it sends signal s3 to ActiveObject-2. The causality model is quite straightforward: objects respond to messages that are generated by objects executing communication actions. When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. The dispatching method by which a particular behavior is associated with a given message depends on the higher-level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). Fig. 2. Example illustrating the basic causality model of UML In the course of executing its behavior, an object may send messages to other objects, and so on. Note that the term .message. is used here in a generic sense to cover both synchronous and asynchronous communications. In fact, a synchronous communication (call) requires two messages. First is the message from the source to the target identifying the operation to be invoked as well as the values of any arguments. This is followed by a reply message from the target back to the calling object that includes values to be returned to the caller. Because the call is synchronous, the caller is suspended until the reply is received. 6.3.4 Mapping to the UML 2.0 Specification The general causality model is described in the introductory part of chapter 13 (CommonBehaviors) and also, in part, in the introduction to chapter 14 (Interactions) and the section on Interaction (14.3.7) and Message (14.3.14) The structural foundations are mostly covered in two chapters. The elementary level is mostly covered in chapter 7, where the root concepts of UML are specified. In particular, the sections on InstanceSpecifications (section 7.7 of the FAS), Classes and Associations (section 7.11), and Features (section 7.9). The composites level is described primarily in chapter 9 (Composite Structures), with most of the information related to semantics contained in sections 9.3.12 (Property concept) and 9.3.13 (StructuredClassifier). In addition, the introduction to this chapter contains a high-level view of some aspects of composite structures. The relationship between structure and behavior and the general properties of the Behavior concept, which are at the core of the Behavioral Base are described in CommonBehaviors (in the introduction to chapter 13 and in section 13.3.3 in particular). Inter-object behavior is covered in three separate chapters. The basic semantics of communications actions are described in the introduction to chapter 11 (Actions) and, in more detail, in the sections describing the specific actions (sections 11.3.1, 11.3.2, 11.3.6, 11.3.7, 11.3.8, 11.3.9, 11.3.18, 11.3.37, 11.3.38, 11.3.39). The concepts related to messages are defined in the Interactions chapter (sections 14.3.14 and 14.3.15), while the concepts of events and triggers are defined in the Communications package of CommonBehaviors (chapter 13). Event occurrences are defined in section 14.3.3) of the Interactions chapter. The basic notion of actions, in the intra-object behavior base, is defined in the introduction to the Activities chapter (chapter 12) and in the section on the Action concept itself (12.3.1). The semantics of flows and nodes mechanisms are also described in the Activities chapter (sections 12.3.2, 12.3.3, 12.3.4, 12.3.6, 12.3.12, 12.3.13, 12.3.15,12.3.17, 12.3.21, 12.3.22, 12.3.23, 12.3.24, 12.3.25, 12.3.27, 12.3.29, 12.3.32, 12.3.34, 12.3.37, 12.3.40). The various shared actions and their semantics are described in chapter 11. Finally, the higher-level behavioral formalisms are each described in their own chapters: Activities in chapter 12, Interactions in chapter 14, and State Machines in chapter 15. Disposition: Resolved From: "Thomas Weigert" To: "Branislav Selic" , Cc: Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 Date: Tue, 3 Aug 2004 00:07:23 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, I think the proposed section is a good idea, as it gives the reader a kind of roadmap on where to find the behavioral semantics of UML. I realize you did not want any criticism :-) but please consider these constructive suggestions: 1. In section 6.3.2, you use the term "semantic domain" several times, but I believe that you are using this term incorrectly. The semantic domain is whatever you map the constructs of your language into to define the meaning of those constructs. For example, in the SDL specification, the semantic domain are evolving algebras (ASM); I have seen semantics of Lisp that used mathematical objects such as functions as its semantic domain. I don't think this is what you are referring to. I think you are using this term to mean layers of explication of the semantics. I think "language layer" would be a better term, or if you really need to use "semantic", then take "semantic layer" (albeit this seems more unclear, as it sounds like a technical term but has no clear explanation). But basically, I think, you are saying that the UML is organized in layers: at the bottom you have structural aspects, upon which behavioral primitives sit (such as the actions and the basic mechanisms of interaction as described in common behavior), upon which behavioral sublanguages are built (such as activities or state machines). 2. Delete the first paragraph in 6.3. The second paragraph states the purpose of this section succinctly. There is no need to apologize about the organization of the specification. 3. Change the title of 6.3.4 to "Roadmap to the UML 2.0 Specification" as there really is no mapping that takes place. Lets reserve that term for the relationship between kinds of things (such as the notation and the metamodel) or the metamodel and the semantic domain. You are describing where in the specification I can find relevant explanations. 4. The diagram in Fig 2 is not a collaboration diagram. We changed the name to "Communication diagram". Further, the use of the vertical bar notation to indicate active parts in the collaboration depicted by the communication diagram is not legal. I think it is a good idea, but currently you can only show notation for active classes, and active objects (shown as instance values). Your syntax of showing parts using the same notation is a good idea and a natural consequence of the notation. I have submitted an issue suggesting this notation enhancement, but as of right now, this is not legal syntax. Cheers, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, August 02, 2004 5:11 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: UML Run-time semantics: resolution proposal for ballot 22 Several months ago, I promised tha I would write a section in the spec that would identify clearly where the various sections that describe the run-time semantics of UML are located. This was raised as an issue (6902) and the attachment contains my proposed resolution to this. It attempts to do two things: (1) Identifies the key semantic domains of UML and their mutual relationships and (2) maps the above to specific sections of the Superstructure spec I realize that something like this can be contentious, but I felt that it was important to include this in the document for a variety of reasons. In addition to the obvious pedagogical ones, there is the problem of dispelling the inaccurate statement that have been plaguing our work that UML has little or no semantics or that what it has is without rhyme or reason. So, I am sure all of you will have your own view of this, and, like medieval scholastics, we could spend many, many months discussing the finer points of this and neve reach agreement. But, i don't plan to. Either people will feel comfortable with the broad outlines specified in this resolution (suggestions on improvements to style and minor improvements to content are more than welcome), or I will simply chuck it all and defer the resolution to an RTF. That is, I do not plan to spend much more time on this issue beyond what I have done already. Specifically, if you want to argue theology with me, forget it. Write your own resolution and I will withdraw mine. Cheers, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 3 Aug 2004 08:09:13 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/03/2004 08:09:15, Serialize complete at 08/03/2004 08:09:15 Thank you, Thomas. I am not against criticism, but against the idea of spending a lot of time arguing about this resolution. Your comments are indeed the constructive comments that I was hoping for. I used "semantic areas" initially but then changed it to "domains" without thinking of the reserved meaning of that term. I will change it. As for the notation, I am not sure that it is not legal. I don't recall that it says explicitly that it is not. Besides, this is an instance diagram -- not a collaboration/communication diagram as I had wrongly stated. Will fix. Cheers, Bran "Thomas Weigert" 08/03/2004 01:07 AM To Branislav Selic/Ottawa/IBM@IBMCA, cc Subject RE: UML Run-time semantics: resolution proposal for ballot 22 Bran, I think the proposed section is a good idea, as it gives the reader a kind of roadmap on where to find the behavioral semantics of UML. I realize you did not want any criticism :-) but please consider these constructive suggestions: 1. In section 6.3.2, you use the term "semantic domain" several times, but I believe that you are using this term incorrectly. The semantic domain is whatever you map the constructs of your language into to define the meaning of those constructs. For example, in the SDL specification, the semantic domain are evolving algebras (ASM); I have seen semantics of Lisp that used mathematical objects such as functions as its semantic domain. I don't think this is what you are referring to. I think you are using this term to mean layers of explication of the semantics. I think "language layer" would be a better term, or if you really need to use "semantic", then take "semantic layer" (albeit this seems more unclear, as it sounds like a technical term but has no clear explanation). But basically, I think, you are saying that the UML is organized in layers: at the bottom you have structural aspects, upon which behavioral primitives sit (such as the actions and the basic mechanisms of interaction as described in common behavior), upon which behavioral sublanguages are built (such as activities or state machines). 2. Delete the first paragraph in 6.3. The second paragraph states the purpose of this section succinctly. There is no need to apologize about the organization of the specification. 3. Change the title of 6.3.4 to "Roadmap to the UML 2.0 Specification" as there really is no mapping that takes place. Lets reserve that term for the relationship between kinds of things (such as the notation and the metamodel) or the metamodel and the semantic domain. You are describing where in the specification I can find relevant explanations. 4. The diagram in Fig 2 is not a collaboration diagram. We changed the name to "Communication diagram". Further, the use of the vertical bar notation to indicate active parts in the collaboration depicted by the communication diagram is not legal. I think it is a good idea, but currently you can only show notation for active classes, and active objects (shown as instance values). Your syntax of showing parts using the same notation is a good idea and a natural consequence of the notation. I have submitted an issue suggesting this notation enhancement, but as of right now, this is not legal syntax. Cheers, Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, August 02, 2004 5:11 PM To: uml2-superstructure-ftf@omg.org Cc: mu2i-ftf@omg.org Subject: UML Run-time semantics: resolution proposal for ballot 22 Several months ago, I promised tha I would write a section in the spec that would identify clearly where the various sections that describe the run-time semantics of UML are located. This was raised as an issue (6902) and the attachment contains my proposed resolution to this. It attempts to do two things: (1) Identifies the key semantic domains of UML and their mutual relationships and (2) maps the above to specific sections of the Superstructure spec I realize that something like this can be contentious, but I felt that it was important to include this in the document for a variety of reasons. In addition to the obvious pedagogical ones, there is the problem of dispelling the inaccurate statement that have been plaguing our work that UML has little or no semantics or that what it has is without rhyme or reason. So, I am sure all of you will have your own view of this, and, like medieval scholastics, we could spend many, many months discussing the finer points of this and neve reach agreement. But, i don't plan to. Either people will feel comfortable with the broad outlines specified in this resolution (suggestions on improvements to style and minor improvements to content are more than welcome), or I will simply chuck it all and defer the resolution to an RTF. That is, I do not plan to spend much more time on this issue beyond what I have done already. Specifically, if you want to argue theology with me, forget it. Write your own resolution and I will withdraw mine. Cheers, Bran From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 Date: Tue, 3 Aug 2004 10:13:41 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) The notation for properties does not provide for showing the vertical "active" bars, albeit I think that this is a good idea. While a profile could extend the notation this way, we should not, in the specification, take such liberty (we should only use "official" notation). Changing the diagram to an instance diagram would be good, but you need to show the name string underlined to make this clear. Further, to show messages between instances these need to be associated to connectors per the metamodel for message. So you are back to having to have them parts. I think you would be best served to (i) currently show this as a communication diagram and remove the vertical bars or (ii) show it as instance diagram and remove the messages (or use information flows). If you go with (i) we could quickly add this notational improvement. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 03, 2004 7:09 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 As for the notation, I am not sure that it is not legal. I don't recall that it says explicitly that it is not. Besides, this is an instance diagram -- not a collaboration/communication diagram as I had wrongly stated. Will fix. To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, "Thomas Weigert" , uml2-superstructure-ftf@omg.org Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 3 Aug 2004 12:15:32 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/03/2004 12:15:33 > The notation for properties does not provide for showing the > vertical "active" bars, albeit I think that this is a good idea. > While a profile could extend the notation this way, we should not, > in the specification, take such liberty (we should only use > "official" notation). I would like to point out that there is no complete "official" notation specification of UML. We only have fragments of that specification. There is still an outstanding OMG work item to define a complete formal concrete syntax of UML. Which means that there is a fair amount of syntax that remains unsaid. One liberal interpretation of this is that whatever is not explicitly disallowed in the UML syntax is allowed. So, the fact that the notation does not bar the use of active bars in sequence diagrams to me means that they are allowed. However, to avoid the controversy, I have changed the diagram to a communication diagram. I have also incorporated most of Thomas' suggestions with the result as per attached document. > Changing the diagram to an instance diagram would be good, but you > need to show the name string underlined to make this clear. Further, > to show messages between instances these need to be associated to > connectors per the metamodel for message. So you are back to having > to have them parts. You just pointed out that it is impossible to show an interaction involving instances. This is a serious defect in UML that should be rectified (in the next round, please). That is, a Lifline should be associated either with a part or an instance specification. Any other suggestions on how to improve the wording of this resolution? Bran OMG Issue No.6902.040803.doc OMG Issue No: 6902 Title: UML 2 Super / General / Idenitfy sections specifying run-time semantics Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections. Discussion: Insert the following text after the last paragraph of section 6.2. 6.3 On the Run-Time Semantics of UML The purpose of this section of the document is to provide a very high-level view of the run-time semantics of UML and to point out where the various elements of that view are covered in the spec. The term .run-time. is used to refer to the execution environment. Run-time semantics, therefore, are specified as a mapping of modeling concepts into corresponding program execution phenomena. There are, of course, other semantics relevant to UML specifications, such as the repository semantics, that is, how a UML model behaves in a model repository. However, those semantics are really part of the definition of the MOF. Still, it is worth remarking that not every concept in UML models a run-time phenomenon (e.g., the .package. concept). 6.3.1 The Basic Premises There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called .active. objects (see definition on page 387). The second is that UML behavioral semantics only deal with event-driven, or discrete, behaviors. This means that continuous behaviors, such as found in many physical systems, are not supported. To be sure, this capability is not precluded, and it is likely that extensions will be defined to provide it. 6.3.2 The Semantics Architecture Fig. 1 identifies the key semantic areas covered by the current standard and how they relate to each other. The items in the upper layers depend on the items in the lower layers but not the other way around. (Note that the structure of metamodel package dependencies is somewhat similar to the dependency structure indicated here. However, they are not the same and should be distinguished. This is because package dependencies specify repository dependencies not necessarily run-time dependencies.) Fig. 1. A schematic of the UML semantic areas and their dependencies At the highest level of abstraction, it is possible to distinguish three distinct composite layers of semantic definitions. The foundational layer is structural. This reflects the premise that there is no disembodied behavior in UML . all behavior is the consequence of the actions of structural entities. The next layer is behavioral and provides the foundation for the semantic description of all the higher-level behavioral formalisms (the term .behavioral formalism. refers to a formalized framework for describing behavior, such as state machines, Petri nets, data flow graphs, etc.). This layer, represented by the shaded box in Fig. 1, is the behavioral semantic base and consists of three separate sub-areas arranged into two sub-layers. The bottom sub-layer consists of the inter-object behavior base, which deals with how structural entities communicate with each other, and the intra-object behavior base, which addresses the behavior occurring within structural entities. The actions sub-layer is placed on top of these two. It defines the semantics of individual actions. Actions are the fundamental units of behavior in UML and are used to define fine-grained behaviors. Their resolution and expressive power are comparable to the executable instructions in traditional programming languages. Actions in this sub-layer are available to any of the higher-level formalisms to be used for describing detailed behaviors. The topmost layer in the semantics hierarchy defines the semantics of the higher-level behavioral formalisms of UML: activities, state machines, and interactions. Other behavioral formalisms may be added to this layer in the future. 6.3.3 The Basic Causality Model The .causality model. is a specification how things happen at run time and is described in detail in the Common Behaviors chapter on page 369. It is briefly summarized here for convenience, using the example depicted in the communication diagram in Fig. 2. The example shows two independent and possibly concurrent threads of causally chained interactions. The first, identified by the thread prefix .A. consists of a sequence of events that commence with activeObject-1 sending signal s1 to activeObject-2. In turn, activeObject-2 responds by invoking operation op1( ) on passiveObject-1 after which it sends signal s2 to activeObject-3. The second thread, distinguished by the thread prefix .B., starts with activeObject-4 invoking operation op2( ) on passiveObject-1. The latter responds by executing the method that realizes this operation in which it sends signal s3 to activeObject-2. The causality model is quite straightforward: objects respond to messages that are generated by objects executing communication actions. When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. The dispatching method by which a particular behavior is associated with a given message depends on the higher-level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). Fig. 2. Example illustrating the basic causality model of UML 6.3.4 Semantics Descriptions in the Specification The general causality model is described in the introductory part of chapter 13 (CommonBehaviors) and also, in part, in the introduction to chapter 14 (Interactions) and the section on Interaction (14.3.7) and Message (14.3.14) The structural foundations are mostly covered in two chapters. The elementary level is mostly covered in chapter 7, where the root concepts of UML are specified. In particular, the sections on InstanceSpecifications (section 7.7 of the FAS), Classes and Associations (section 7.11), and Features (section 7.9). The composites level is described primarily in chapter 9 (Composite Structures), with most of the information related to semantics contained in sections 9.3.12 (Property concept) and 9.3.13 (StructuredClassifier). In addition, the introduction to this chapter contains a high-level view of some aspects of composite structures. The relationship between structure and behavior and the general properties of the Behavior concept, which are at the core of the behavioral base are described in CommonBehaviors (in the introduction to chapter 13 and in section 13.3.3 in particular). Inter-object behavior is covered in three separate chapters. The basic semantics of communications actions are described in the introduction to chapter 11 (Actions) and, in more detail, in the sections describing the specific actions (sections 11.3.1, 11.3.2, 11.3.6, 11.3.7, 11.3.8, 11.3.9, 11.3.18, 11.3.37, 11.3.38, 11.3.39). The concepts related to messages are defined in the Interactions chapter (sections 14.3.14 and 14.3.15), while the concepts of events and triggers are defined in the Communications package of CommonBehaviors (chapter 13). Event occurrences are defined in section 14.3.3 of the Interactions chapter. The basic notion of actions, in the intra-object behavior base, is defined in the introduction to the Activities chapter (chapter 12) and in the section on the Action concept itself (12.3.1). The semantics of flows and nodes mechanisms are also described in the Activities chapter (sections 12.3.2, 12.3.3, 12.3.4, 12.3.6, 12.3.12, 12.3.13, 12.3.15,12.3.17, 12.3.21, 12.3.22, 12.3.23, 12.3.24, 12.3.25, 12.3.27, 12.3.29, 12.3.32, 12.3.34, 12.3.37, 12.3.40). The various shared actions and their semantics are described in chapter 11. Finally, the higher-level behavioral formalisms are each described in their own chapters: Activities in chapter 12, Interactions in chapter 14, and State Machines in chapter 15. Disposition: Resolved From: "Thomas Weigert" To: "Branislav Selic" Cc: , Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 Date: Tue, 3 Aug 2004 12:22:54 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) A lifeline in an interaction represents connectable elements which are instance like things. I think it makes sense that interactions are limited to be between connectable elements, as they are always within a context. You can have an interaction between any arbitrary instance, just create a collaboration where that instance plays a role. (A tool could do that automatically.) However, a lot of thought went into establishing that framework.... there are no interactions between disembodied instances per the specification. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 03, 2004 11:16 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 You just pointed out that it is impossible to show an interaction involving instances. This is a serious defect in UML that should be rectified (in the next round, please). That is, a Lifline should be associated either with a part or an instance specification. To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 3 Aug 2004 13:45:32 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/03/2004 13:45:33, Serialize complete at 08/03/2004 13:45:33 The problem is that I cannot show recorded traces (for example). That is, I may want to show an interaction in which the lifeline labels are underlined. It sounds like a perfectly reasonable thing to do without having to go through some gymnastics. Bran Selic IBM Distinguished Engineer IBM Rational Software 770 Palladium Drive Kanata, Ontario, Canada K2V 1C8 ph.: (613) 591-7915 fax: (613) 599-3912 e-mail: bselic@ca.ibm.com "Thomas Weigert" 08/03/2004 01:22 PM To Branislav Selic/Ottawa/IBM@IBMCA cc , Subject RE: UML Run-time semantics: resolution proposal for ballot 22 A lifeline in an interaction represents connectable elements which are instance like things. I think it makes sense that interactions are limited to be between connectable elements, as they are always within a context. You can have an interaction between any arbitrary instance, just create a collaboration where that instance plays a role. (A tool could do that automatically.) However, a lot of thought went into establishing that framework.... there are no interactions between disembodied instances per the specification. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Tuesday, August 03, 2004 11:16 AM To: Thomas Weigert Cc: mu2i-ftf@omg.org; Thomas Weigert; uml2-superstructure-ftf@omg.org Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 You just pointed out that it is impossible to show an interaction involving instances. This is a serious defect in UML that should be rectified (in the next round, please). That is, a Lifline should be associated either with a part or an instance specification. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 03 Aug 2004 11:14:40 -0700 To: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org From: Joaquin Miller Subject: RE: UML Run-time semantics: resolution proposal for ballot 22 Architects must be able to identify specific items in a specification. Going through the detour of creating a role just for a particular object isn't just inconvenient. It results in an incorrect spec. It is not that my new system must connect to some object in a particular legacy role, it must connect to a specific legacy subsystem. And, in order to explain to the programmers how to interact with that specific subsystem, i, quite reasonably, want to use interaction diagrams Of course, if i am restricted to using a role, and i am asked: can't you use OCL or a text comment to specify that there is only one object that can play this role, i have to answer: Yes. But i get to add: But i don't want to. I want to use an object, er, instanceSpecification of a class, in the diagram. The same object i use elsewhere in the model to represent that particular legacy subsystem. That's what InstanceSpecification is for. Role has a different purpose. Cordially, Joaquin Date: Tue, 03 Aug 2004 21:21:05 +0200 From: Birger Mųller-Pedersen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Joaquin Miller CC: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: UML Run-time semantics: resolution proposal for ballot 22 X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-5, required 12, UIO_MAIL_IS_INTERNAL -5.00) By their very nature, InstanceSpecifications representing subsystem instances have a context in terms of the system having these subsystem instances. However, I am not sure that the metamodel for InstanceSpecification has the machinery for expressing this. /birger Joaquin Miller wrote: Architects must be able to identify specific items in a specification. Going through the detour of creating a role just for a particular object isn't just inconvenient. It results in an incorrect spec. It is not that my new system must connect to some object in a particular legacy role, it must connect to a specific legacy subsystem. And, in order to explain to the programmers how to interact with that specific subsystem, i, quite reasonably, want to use interaction diagrams Of course, if i am restricted to using a role, and i am asked: can't you use OCL or a text comment to specify that there is only one object that can play this role, i have to answer: Yes. But i get to add: But i don't want to. I want to use an object, er, instanceSpecification of a class, in the diagram. The same object i use elsewhere in the model to represent that particular legacy subsystem. That's what InstanceSpecification is for. Role has a different purpose. Cordially, Joaquin -- Birger Mųller-Pedersen Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo, Norway Tel: +47 22 85 24 37 (office) Tel: +47 918 27 27 9 (mobile) http://folk.uio.no/birger Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Mon, 9 Aug 2004 15:08:59 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, Bran, > [Thomas] But the activities that execute are active objects, in > virtue of them being instances of classes! Please see the > metamodel. Honestly, I don't understand the argument. I think this is > just about names. What Bran is writing is just as much true of > procedural programming as of object-oriented programming. Even if we say an instance of an activity (let's call it A) is an active object, which isn't in the spec currently, if that activity calls another acitivity (B), there is no message passing between active objects that causes this. The activity class B is instantiated and its execution begins. The instance of activity A doesn't call an operation or send a signal. Isn't that right? > P.S. I am just as eager to ensure the ability to use procedural > programming only, without OO concepts. But I think the text proposed > does not interfere with that. Per above, Figure 2 in the resolution give a causality model that can't apply to procedural programming, or process modeling. > [Bran to Jim O] However, implicit in that model is that there is some > physical agency or agencies (e.g., a computer, or a person, or an > executing program) that will be executing that behavior. > (NB: this does not imply that such objects have to be present in the > model itself - it is perfectly valid to define models that do not > explicitly contain active objects.) The text: The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called "active" objects (see definition on page 387). Says "actions executed by" which sounds like the model has actions, and the active object is an instance of a class that has isActive = true. We could find a more neutral wording, but the causality model makes it completely clear that calling a behavior with CallBehaviorAction has no semantics in UML, because no messages are sent. Conrad From: "Thomas Weigert" To: , , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Mon, 9 Aug 2004 14:12:25 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) How can this not be in the spec? By definition, an activity is a class, therefore, the instance of an activity is an object. This is clarified in common behavior for the case where the activity is its own context. On your second question, of course, there is no message passing to cause the invocation of activity B. Neither does this happen when an object creates another object. I really am missing why you are worried. I am not trying to be obstinate. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Monday, August 09, 2004 2:09 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: Draft of ballot 22 -- Please review (6902, runtime > semantics) > > > Thomas, Bran, > > > [Thomas] But the activities that execute are active objects, in > > virtue of them being instances of classes! Please see the > > metamodel. Honestly, I don't understand the argument. I think this is > > just about names. What Bran is writing is just as much true of > > procedural programming as of object-oriented programming. > > Even if we say an instance of an activity (let's call it A) is an active > object, which isn't in the spec currently, if that activity calls > another acitivity (B), there is no message passing between active > objects that causes this. The activity class B is instantiated and its > execution begins. The instance of activity A doesn't call an operation > or send a signal. Isn't that right? > Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Mon, 9 Aug 2004 15:17:27 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, One more comment on the runtime semantics: > The basic notion of actions, in the intra-object behavior base, is > defined in the introduction to the Activities chapter (chapter 12) > and in the section on the Action concept itself (12.3.1). The > semantics of flows and nodes mechanisms are also described in the > Activities chapter (sections 12.3.2, 12.3.3, 12.3.4, 12.3.6, > 12.3.12, 12.3.13, 12.3.15,12.3.17, 12.3.21, 12.3.22, 12.3.23, > 12.3.24, 12.3.25, 12.3.27, 12.3.29, 12.3.32, 12.3.34, 12.3.37, > 12.3.40). Activities can be inter-object, the overview of section 12 is noncommital on that. Activities only give a precedence order for other behaviors that can reside on one or many objects. For example, Figure 1 of http://www.jot.fm/issues/issue_2004_07/column4 can be an abstraction of various message-passing pattern between objects, as shown in Figures 11 and 12. Would have thought state machines were an intra-object behavior model. Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Mon, 9 Aug 2004 15:43:28 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > How can this not be in the spec? By definition, an activity is a class, > therefore, the instance of an activity is an object. Right, but not necessary an active object, which the runtime semantics says is the the source of all behavior (see other comments in previous mail on that). > On your second question, of course, there is no message passing to > cause the invocation of activity B. Neither does this happen when an > object creates another object. I really am missing why you are > worried. Because the causality model, which "is a specification how things happen at run time", says there is: objects respond to messages that are generated by objects executing communication actions. When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. The dispatching method by which a particular behavior is associated with a given message depends on the higher-level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). How would this cover an application just uses activities with CallBehaviorAction and read/write actions? Conrad To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 9 Aug 2004 17:55:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/09/2004 17:55:36, Serialize complete at 08/09/2004 17:55:36 Conrad, As I said, I really would prefer not to argue about the finer points of this. If you have an alternative proposal or a revision of my proposal, I will welcome it. If not, I will try to accommodate as much of your concerns as I can and will then put it up for vote. It seems to me that the discussion is getting down to very fine distinctions, most of which were intentionally avoided in the write up. Bran "Conrad Bock" 08/09/2004 03:43 PM Please respond to conrad.bock To , cc Subject RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Thomas, > How can this not be in the spec? By definition, an activity is a class, > therefore, the instance of an activity is an object. Right, but not necessary an active object, which the runtime semantics says is the the source of all behavior (see other comments in previous mail on that). > On your second question, of course, there is no message passing to > cause the invocation of activity B. Neither does this happen when an > object creates another object. I really am missing why you are > worried. Because the causality model, which "is a specification how things happen at run time", says there is: objects respond to messages that are generated by objects executing communication actions. When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. The dispatching method by which a particular behavior is associated with a given message depends on the higher-level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). How would this cover an application just uses activities with CallBehaviorAction and read/write actions? Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Tue, 10 Aug 2004 11:23:05 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > As I said, I really would prefer not to argue about the finer points > of this. If you have an alternative proposal or a revision of my > proposal, I will welcome it. If not, I will try to accommodate as > much of your concerns as I can and will then put it up for vote. Not so fine for the procedural modelers, since the current text is very OO. See attached for proposed edits. I also couldn't tell that was intended by inter-object and intra-object base, since any action can be used by an object on itself or other objects. So the layers are just structural and behavioral, with behavior broken into actions and the formalisms. Conrad issueresolution-6902-runtimesemantics.doc OMG Issue No: 6902 Title: UML 2 Super / General / Idenitfy sections specifying run-time semantics Source: International Business Machines (Mr. Bran Selic, bselic@ca.ibm.com) Summary: The sections of the spec that describe the run-time semantics of UML are scattered throughout the document and not clearly identified. There should be at least some convenient guide in the document that would help locate those sections. Discussion: Insert the following text after the last paragraph of section 6.2. 6.3 On the Run-Time Semantics of UML The purpose of this section of the document is to provide a very high-level view of the run-time semantics of UML and to point out where the various elements of that view are covered in the spec. The term .run-time. is used to refer to the execution environment. Run-time semantics, therefore, are specified as a mapping of modeling concepts into corresponding program execution phenomena. There are, of course, other semantics relevant to UML specifications, such as the repository semantics, that is, how a UML model behaves in a model repository. However, those semantics are really part of the definition of the MOF. Still, it is worth remarking that not every concept in UML models a run-time phenomenon (e.g., the .package. concept). 6.3.1 The Basic Premises There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actions of objects. This includes the behavior objects, because behaviors are classes in UML 2. Some of these objects are called .active. (see definition on page 387). The second is that UML behavioral semantics only deal with behaviors that can be given a discrete semantics, although this includes continuous behaviors that can be reduced to discrete semantics by infinitesimals. 6.3.2 The Semantics Architecture Fig. 1 identifies the key semantic areas covered by the current standard and how they relate to each other. The items in the upper layers depend on the items in the lower layers but not the other way around. (Note that the structure of metamodel package dependencies is somewhat similar to the dependency structure indicated here. However, they are not the same and should be distinguished. This is because package dependencies specify repository dependencies not necessarily run-time dependencies.) Fig. 1. A schematic of the UML semantic areas and their dependencies At the highest level of abstraction, it is possible to distinguish three distinct composite layers of semantic definitions. The foundational layer is structural. This reflects the premise that all behavior is the consequence of the actions of structural entities, taking into account that behavior is also represented structurally in UML 2. The next layer is behavioral and has two parts: a foundation for the semantic description of all the higher-level behavioral formalisms (the term .behavioral formalism. refers to a formalized framework for describing behavior, such as state machines, Petri nets, data flow graphs, etc.), and the behavior formalisms themselves. This layer, represented by the shaded box in Fig. 1, is the behavioral part of UML and consists of two sub-areas arranged into two sub-layers. The bottom sub-layer consists of the actions, which deals with how structural entities communicate with each other, and the intra-object behavior base, which addresses the behavior occurring within structural entities. The actions sub-layer is placed on top of these two. It defines the semantics of individual actions. Actions are the fundamental units of behavior in UML and are used to define fine-grained elements of behaviors. They can be used for inter-object and intra-objects purposes. Their resolution and expressive power are comparable to the executable instructions in traditional programming languages. Actions in this sub-layer are available to any of the higher-level formalisms to be used for describing detailed behaviors. The topmost layer in the semantics hierarchy defines the semantics of the higher-level behavioral formalisms of UML: activities, state machines, and interactions. Other behavioral formalisms may be added to this layer in the future. 6.3.3 The Basic Causality Model The .causality model. and is described in detail in the Common Behaviors chapter on page 369. It is briefly summarized here for convenience, using the example depicted in the communication diagram in Fig. 2. This example addresses focuses on signal passing between objects, but can be generalized to operation invocation. It shows two independent and possibly concurrent threads of causally chained interactions. The first, identified by the thread prefix .A. consists of a sequence of events that commence with activeObject-1 sending signal s1 to activeObject-2. In turn, activeObject-2 responds by invoking operation op1( ) on passiveObject-1 after which it sends signal s2 to activeObject-3. The second thread, distinguished by the thread prefix .B., starts with activeObject-4 invoking operation op2( ) on passiveObject-1. The latter responds by executing the method that realizes this operation in which it sends signal s3 to activeObject-2. The causality model in this example is quite straightforward: objects respond to messages that are generated by objects executing communication actions. When these messages arrive, the receiving objects eventually respond by executing the behavior that is matched to that message. The dispatching method by which a particular behavior is associated with a given message depends on the higher-level formalism used and is not defined in the UML specification (i.e., it is a semantic variation point). Fig. 2. Example illustrating the basic causality model of UML Another example covered by the causality model is behaviors invoking each other and passing information to each other without messages or intervening objects, as enabled by CallBehaviorAction (see definition on page ??EDITOR). Since behaviors are classes in UML 2, the invocation of a behavior corresponds to creating an instance of the behavior representing an execution of it. This purely .procedural. or .process. model can be used in by itself or in conjunction with the object-oriented model of the previous example. 6.3.4 Semantics Descriptions in the Specification The general causality model is described in the introductory part of chapter 13 (CommonBehaviors) and also, in part, in the introduction to chapter 14 (Interactions) and the section on Interaction (14.3.7) and Message (14.3.14) The structural foundations are mostly covered in two chapters. The elementary level is mostly covered in chapter 7, where the root concepts of UML are specified. In particular, the sections on InstanceSpecifications (section 7.7 of the FAS), Classes and Associations (section 7.11), and Features (section 7.9). The composites level is described primarily in chapter 9 (Composite Structures), with most of the information related to semantics contained in sections 9.3.12 (Property concept) and 9.3.13 (StructuredClassifier). In addition, the introduction to this chapter contains a high-level view of some aspects of composite structures. The relationship between structure and behavior and the general properties of the Behavior concept, which are at the core of the behavioral base are described in CommonBehaviors (in the introduction to chapter 13 and in section 13.3.3 in particular). This includes behaviors as classes. Inter-object behavior is covered in three chapters. The basic semantics of communications actions are described in the introduction to chapter 11 (Actions) and, in more detail, in the sections describing the specific actions. These can potentially be used by an object on itself, so are not necessarily inter-object (sections 11.3.1, 11.3.2, 11.3.6, 11.3.7, 11.3.8, 11.3.9, 11.3.18, 11.3.37, 11.3.38, 11.3.39). The read/write actions can also be used to by one object to access others objects, so are potentially inter-object. These actions can be used by any of the behavior formalisms in UML, so all are potentially inter-object behaviors. However, the interactions diagram is designed specifically to highlight inter-object behavior, under its concept of message. These are defined in the Interactions chapter (sections 14.3.14 and 14.3.15), while the concepts of events and triggers are defined in the Communications package of CommonBehaviors (chapter 13). Event occurrences are defined in section 14.3.3 of the Interactions chapter. The other two behavior formalisms can be translated to interactions when they use inter-object actions. All the behavior formalisms are potentially intra-object, if they are specified to be executed by and access only one object. However, state machines are designed specifically to model the state of a single object and respond to events arriving at that object. Activities can be used in a similar way, but also highlight input and output dependency between behaviors, which may reside in multiple objects. Interactions are potentially intra-object, but generally not designed for that purpose.The basic notion of actions, in the intra-object behavior base, is defined in the introduction to the Activities chapter (chapter 12) and in the section on the Action concept itself (12.3.1). The semantics of flows and nodes mechanisms are also described in the Activities chapter (sections 12.3.2, 12.3.3, 12.3.4, 12.3.6, 12.3.12, 12.3.13, 12.3.15,12.3.17, 12.3.21, 12.3.22, 12.3.23, 12.3.24, 12.3.25, 12.3.27, 12.3.29, 12.3.32, 12.3.34, 12.3.37, 12.3.40). The various shared actions and their semantics are described in chapter 11. Finally, the higher-level behavioral formalisms are each described in their own chapters: Activities in chapter 12, Interactions in chapter 14, and State Machines in chapter 15. Disposition: Resolved Date: Tue, 10 Aug 2004 16:58:23 +0100 From: Guus Ramackers Organization: Oracle Corporation User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: conrad.bock@nist.gov CC: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Draft of ballot 22 -- Please review (6902, runtime semantics) Conrad, I think these are useful clarifications. Thanks, Guus Conrad Bock wrote: Bran, > As I said, I really would prefer not to argue about the finer points > of this. If you have an alternative proposal or a revision of my > proposal, I will welcome it. If not, I will try to accommodate as > much of your concerns as I can and will then put it up for vote. Not so fine for the procedural modelers, since the current text is very OO. See attached for proposed edits. I also couldn't tell that was intended by inter-object and intra-object base, since any action can be used by an object on itself or other objects. So the layers are just structural and behavioral, with behavior broken into actions and the formalisms. Conrad -- __________________________________________________________ Guus Ramackers Product Manager UML and Web Services, Oracle JDeveloper Tools group e-mail: guus.ramackers@oracle.com 520 Oracle Parkway, TVP work: +44-(0)1189-245101 Reading RG6 1RA, UK fax: +44-(0)1189-245148 User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Tue, 10 Aug 2004 12:30:37 -0400 Subject: Re: Draft of ballot 22 -- Please review (6902, runtime semantics) From: James Odell To: , IMO, Conrad's revisions provide a beneficial contribution to Bran's excellent resolution for issue 6902. -Jim O On 8/10/04 11:23 AM, "Conrad Bock" indited: > > Bran, > >> As I said, I really would prefer not to argue about the finer points >> of this. If you have an alternative proposal or a revision of my >> proposal, I will welcome it. If not, I will try to accommodate as >> much of your concerns as I can and will then put it up for vote. > > Not so fine for the procedural modelers, since the current text is very > OO. > > See attached for proposed edits. I also couldn't tell that was intended > by inter-object and intra-object base, since any action can be used by > an object on itself or other objects. So the layers are just structural > and behavioral, with behavior broken into actions and the formalisms. > > Conrad To: James Odell Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: Re: Draft of ballot 22 -- Please review (6902, runtime semantics) X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 10 Aug 2004 12:41:12 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/10/2004 12:41:17, Serialize complete at 08/10/2004 12:41:17 I wish I could agree with you, Jim, but I find that Conrad has completely changed more or less everything I tried to say. I'll be back with more detailed comments, but it looks like this thing is headed for the deferral bin. Bran James Odell 08/10/2004 12:30 PM To , cc Subject Re: Draft of ballot 22 -- Please review (6902, runtime semantics) IMO, Conrad's revisions provide a beneficial contribution to Bran's excellent resolution for issue 6902. -Jim O On 8/10/04 11:23 AM, "Conrad Bock" indited: > > Bran, > >> As I said, I really would prefer not to argue about the finer points >> of this. If you have an alternative proposal or a revision of my >> proposal, I will welcome it. If not, I will try to accommodate as >> much of your concerns as I can and will then put it up for vote. > > Not so fine for the procedural modelers, since the current text is very > OO. > > See attached for proposed edits. I also couldn't tell that was intended > by inter-object and intra-object base, since any action can be used by > an object on itself or other objects. So the layers are just structural > and behavioral, with behavior broken into actions and the formalisms. > > Conrad From: "Thomas Weigert" To: , , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Wed, 11 Aug 2004 01:15:43 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) While not perfect, I think Bran's earlier draft was better in that it stayed at an abstraction level above these details, while not ruling out what Conrad is trying to say. I don't think that Conrad's rewrite is helpful; keep in mind, this is just a high-level introductory section. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Tuesday, August 10, 2004 10:23 AM > To: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org > Subject: RE: Draft of ballot 22 -- Please review (6902, runtime > semantics) > > > > Bran, > > > As I said, I really would prefer not to argue about the finer points > > of this. If you have an alternative proposal or a revision of my > > proposal, I will welcome it. If not, I will try to accommodate as > > much of your concerns as I can and will then put it up for vote. > > Not so fine for the procedural modelers, since the current text is very > OO. > > See attached for proposed edits. I also couldn't tell that was intended > by inter-object and intra-object base, since any action can be used by > an object on itself or other objects. So the layers are just structural > and behavioral, with behavior broken into actions and the formalisms. > > Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Wed, 11 Aug 2004 10:29:38 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, et al, > While not perfect, I think Bran's earlier draft was better in that it > stayed at an abstraction level above these details, while not ruling > out what Conrad is trying to say. The only people knowing that it doesn't rule out procedural/process modeling would be the authors. Attached is an updated version sent to Bran yesterday. I left the figure as is, with inter/intra, but it's unclear what these map to in the metamodel. I would replace them with Common Behavior, which is required for the some of the actions anyway, and better reflects the package structure. Conrad issueresolution-6902-runtimesemantics2.doc Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) Date: Wed, 11 Aug 2004 14:44:52 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Presumably this would need to be updated for packaging in 7319 (it seems to be partially). I figure: Basic Level should include BasicActions, and FundamentalActivities. (The description of Basic Level includes BasicActions, but it isn't in Figure 2, and Table 2 shows it in Intermediate. Table 1 has FundamentalActivities already, but it isn't in Figure 2). Intermediate Level should include StructuredActions. (Table 3 has StructuredActions in Complete, but it should be at the same level as StructuredActivities. It isn't in Figure 3). There's a typo in Figure 3: InvocationActions => IntermediateActions. Conrad To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 22 -- Please review (6902, runtime semantics) X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 11 Aug 2004 15:54:50 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/11/2004 15:54:51, Serialize complete at 08/11/2004 15:54:51 > Presumably this would need to be updated for packaging in 7319 (it seems > to be partially). I figure: > > Basic Level should include BasicActions, and FundamentalActivities. > (The description of Basic Level includes BasicActions, but it isn't > in Figure 2, and Table 2 shows it in Intermediate. Table 1 has > FundamentalActivities already, but it isn't in Figure 2). OK. This one wasn't clear because there was repackaging. The discrepancy is a bug. I'll fix both. > Intermediate Level should include StructuredActions. > (Table 3 has StructuredActions in Complete, but it should be at the > same level as StructuredActivities. It isn't in Figure 3). OK. > There's a typo in Figure 3: InvocationActions => IntermediateActions. No typo. InvocationActions are from CompositeStructures. IntermediateActions are missing from Figure 3. Will fix. Thanks, Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review Date: Fri, 6 Aug 2004 14:16:08 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Hi Bran, Sorry to read this late, but I have strong objections to the resolution of 6902 (Identify sections specifying run-time semantics). It elevates the object-centered viewpoint over the process view necessary for systems engineeting and business process modeling. In particular, these statements are problematic: The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called "active" objects (see definition on page 387). This means that continuous behaviors, such as found in many physical systems, are not supported. It is possible in UML to define nothing but activity models and classes that only have attributes. The activity models execute without active objects, which is the point of CallInvocationEvent. This is absolutely critical to systems engineering and business process models. I understand behaviors are objects, which is the escape hatch on this, but it needs to be drawn much more clearly, especially in the causality model. Also behaviors can be invoked continuously and provide continuous output. Please give this one another week for discussion, to get input from the process-focused users of UML. Thanks, To: Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 22 -- Please review X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 14:47:08 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 14:47:11, Serialize complete at 08/06/2004 14:47:11 OK, I can withdraw, but before I do, please comment on the following: This write up does not contradict what you said: of course you can define just activity models. What it is saying is that, at run time, behavior is the result of the actions of active objects. The model does not have to include any active objects -- they are implicit. (Behavior does not just happen, some structural agency has to perform it.) If I added this explanation, would you consider it acceptable? Note that this semantic view is also in CommonBehavior and we are not going to change that in a week. I would appreciate if you could respond to this before 6 pm EDT -- if possible. Cheers...Bran "Conrad Bock" 08/06/2004 02:16 PM Please respond to conrad.bock To , cc Subject RE: Draft of ballot 22 -- Please review Hi Bran, Sorry to read this late, but I have strong objections to the resolution of 6902 (Identify sections specifying run-time semantics). It elevates the object-centered viewpoint over the process view necessary for systems engineeting and business process modeling. In particular, these statements are problematic: The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called "active" objects (see definition on page 387). This means that continuous behaviors, such as found in many physical systems, are not supported. It is possible in UML to define nothing but activity models and classes that only have attributes. The activity models execute without active objects, which is the point of CallInvocationEvent. This is absolutely critical to systems engineering and business process models. I understand behaviors are objects, which is the escape hatch on this, but it needs to be drawn much more clearly, especially in the causality model. Also behaviors can be invoked continuously and provide continuous output. Please give this one another week for discussion, to get input from the process-focused users of UML. Thanks, Conrad To: conrad.bock@nist.gov Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 22 -- Please review X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 14:59:18 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 14:59:19, Serialize complete at 08/06/2004 14:59:19 Conrad, Here is the proposed added explanation (in italics for emphasis), tell me what you think: There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called ā..activeā.¯ objects (see definition on page 387). (NB: this does not imply that such objects have to be present in the model itself . it is perfectly valid to define models tthat do not explicitly contain active objects.) The second is that UML behavioral semantics only deal with event-driven, or discrete, behaviors. This means that continuous behaviors, such as found in many physical systems, are not supported. To be sure, this capability is not precluded, and it is likely that extensions will be defined to provide it. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/06/2004 02:47 PM To cc mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject RE: Draft of ballot 22 -- Please review OK, I can withdraw, but before I do, please comment on the following: This write up does not contradict what you said: of course you can define just activity models. What it is saying is that, at run time, behavior is the result of the actions of active objects. The model does not have to include any active objects -- they are implicit. (Behavior does not just happen, some structural agency has to perform it.) If I added this explanation, would you consider it acceptable? Note that this semantic view is also in CommonBehavior and we are not going to change that in a week. I would appreciate if you could respond to this before 6 pm EDT -- if possible. Cheers...Bran "Conrad Bock" 08/06/2004 02:16 PM Please respond to conrad.bock To , cc Subject RE: Draft of ballot 22 -- Please review Hi Bran, Sorry to read this late, but I have strong objections to the resolution of 6902 (Identify sections specifying run-time semantics). It elevates the object-centered viewpoint over the process view necessary for systems engineeting and business process modeling. In particular, these statements are problematic: The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called "active" objects (see definition on page 387). This means that continuous behaviors, such as found in many physical systems, are not supported. It is possible in UML to define nothing but activity models and classes that only have attributes. The activity models execute without active objects, which is the point of CallInvocationEvent. This is absolutely critical to systems engineering and business process models. I understand behaviors are objects, which is the escape hatch on this, but it needs to be drawn much more clearly, especially in the causality model. Also behaviors can be invoked continuously and provide continuous output. Please give this one another week for discussion, to get input from the process-focused users of UML. Thanks, Conrad Reply-To: From: "Conrad Bock" To: , Subject: RE: Draft of ballot 22 -- Please review Date: Fri, 6 Aug 2004 15:00:25 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > OK, I can withdraw Would appreciate it, since I'm "off" today. Will make it a priority to provide more concrete suggestions next week. > This write up does not contradict what you said: of course you > can define just activity models. What it is saying is that, at > run time, behavior is the result of the actions of active > objects. The model does not have to include any active objects > -- they are implicit. (Behavior does not just happen, some > structural agency has to perform it.) Might be OK, but I'm concerned the subtlety will be lost by readers who are experts in process-centered domains. > If I added this explanation, would you consider it acceptable? > Note that this semantic view is also in CommonBehavior and we > are not going to change that in a week. Actually, Thomas and I put in a couple wording adjustments in the FAS to at least make the process centered view allowed, if not so obvious. I would like Common Behavior to be clearer about this, but saying it twice, especially at the front of the document under such a broad-sounding title, raises the urgency to clarify it. Conrad User-Agent: Microsoft-Entourage/10.1.4.030702.0 Date: Fri, 06 Aug 2004 15:24:30 -0400 Subject: FW: Draft of ballot 22 -- Please review From: James Odell To: Bran, I have a two issues about your statements on this tread: 1) It seems like you might be restricting your view of activity diagrams by using a state-machine oriented viewpoint Am not sure this is possible or necessary. From a business modeling viewpoint, this is certainly not the case.IMO. Under your semantics (as I understand them), a business process defined purely in terms of activities would not have semantics. 2) Am not sure that .all behavior in a modeled system is ultimately caused by actions executed by so-called .active. objects. There are no "active" objects in communication. Cheers, Jim ------ Forwarded Message From: Branislav Selic Date: Fri, 6 Aug 2004 14:59:18 -0400 To: conrad.bock@nist.gov Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Draft of ballot 22 -- Please review Conrad, Here is the proposed added explanation (in italics for emphasis), tell me what you think: There are two fundamental premises regarding the nature of UML semantics. The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called .active. objects (see definition on page 387). (NB: this does not imply that such objects have to be present in the model itself . it is perfectly valid to define models that do not explicitly contain active objects.) The second is that UML behavioral semantics only deal with event-driven, or discrete, behaviors. This means that continuous behaviors, such as found in many physical systems, are not supported. To be sure, this capability is not precluded, and it is likely that extensions will be defined to provide it. Bran Branislav Selic/Ottawa/IBM@IBMCA 08/06/2004 02:47 PM To cc mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject RE: Draft of ballot 22 -- Please review OK, I can withdraw, but before I do, please comment on the following: This write up does not contradict what you said: of course you can define just activity models. What it is saying is that, at run time, behavior is the result of the actions of active objects. The model does not have to include any active objects -- they are implicit. (Behavior does not just happen, some structural agency has to perform it.) If I added this explanation, would you consider it acceptable? Note that this semantic view is also in CommonBehavior and we are not going to change that in a week. I would appreciate if you could respond to this before 6 pm EDT -- if possible. Cheers...Bran "Conrad Bock" 08/06/2004 02:16 PM Please respond to conrad.bock To , cc Subject RE: Draft of ballot 22 -- Please review Hi Bran, Sorry to read this late, but I have strong objections to the resolution of 6902 (Identify sections specifying run-time semantics). It elevates the object-centered viewpoint over the process view necessary for systems engineeting and business process modeling. In particular, these statements are problematic: The first is the assumption that all behavior in a modeled system is ultimately caused by actions executed by so-called "active" objects (see definition on page 387). This means that continuous behaviors, such as found in many physical systems, are not supported. It is possible in UML to define nothing but activity models and classes that only have attributes. The activity models execute without active objects, which is the point of CallInvocationEvent. This is absolutely critical to systems engineering and business process models. I understand behaviors are objects, which is the escape hatch on this, but it needs to be drawn much more clearly, especially in the causality model. Also behaviors can be invoked continuously and provide continuous output. Please give this one another week for discussion, to get input from the process-focused users of UML. Thanks, Conrad ------ End of Forwarded Message To: James Odell Cc: uml2-superstructure-ftf@omg.org Subject: Re: FW: Draft of ballot 22 -- Please review X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Fri, 6 Aug 2004 15:59:13 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/06/2004 15:59:15, Serialize complete at 08/06/2004 15:59:15 Jim In reply: > 1) It seems like you might be restricting your view of activity > diagrams by using a state-machine oriented viewpoint Am not sure > this is possible or necessary. From a business modeling viewpoint, > this is certainly not the case.IMO. Under your semantics (as I > undderstand them), a business process defined purely in terms of > activities would not have semantics. No, I am not saying that at all. You can most definitely define a business process or any activity without ever mentioning an object even once. I tried to make that clear with my added text. However, implicit in that model is that there is some physical agency or agencies (e.g., a computer, or a person, or an executing program) that will be executing that behavior. That is how the world is, and I can't help that. > 2) Am not sure that ā..all behavior in a modeled system is ultimately > caused by actions executed by so-called ā..activeā.¯ objectsā.. There are > no "active" objects in communication. I am sorry, Jim, but I don't understand what you are saying here. Communication takes place between active objects -- how can it be otherwise? If there are no objects involved, who is communicating with what? Note that active objects do not have to be computer-based things. I took great pains in producing a definition that is not technology based (notice, for instance, that the word "thread" never appears in the definition of an active object). I do want to say, however, that this is precisely the kind of discussion I was afraid of. When I proposed the resolution, I stipulated that I will not get drawn into a theoretical discussion, because there are no winners in such fruitless discussions (just look at the very impressive and very deep discussions that rise up every now and then on the ADTF mailing list). If people want to make constructive suggestions to my resolution -- as Conrad said he would try to do -- I am more than happy to go along. Otherwise, I will simply defer the issue until God comes down to Earth and reveals the Truth. However, I think it would be a shame to defer, since the document sorely needs a section like that, since it has been wrongly maligned as not containing any semantics. An up front section like this, was intended to dispel that misunderstanding. Regards...Bran From: "Thomas Weigert" To: , , Subject: RE: Draft of ballot 22 -- Please review Date: Sun, 8 Aug 2004 13:43:20 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) But the activities that execute are active objects, in virtue of them being instances of classes! Please see the metamodel. Honestly, I don't understand the argument. I think this is just about names. What Bran is writing is just as much true of procedural programming as of object-oriented programming. Th. P.S. I am just as eager to ensure the ability to use procedural programming only, without OO concepts. But I think the text proposed does not interfere with that. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Friday, August 06, 2004 1:16 PM > To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org > Subject: RE: Draft of ballot 22 -- Please review > > > Hi Bran, > > Sorry to read this late, but I have strong objections to the resolution > of 6902 (Identify sections specifying run-time semantics). It elevates > the object-centered viewpoint over the process view necessary for > systems engineeting and business process modeling. In particular, these > statements are problematic: > > The first is the assumption that all behavior in a modeled system is > ultimately caused by actions executed by so-called "active" objects > (see definition on page 387). > > This means that continuous behaviors, such as found in many physical > systems, are not supported. > > It is possible in UML to define nothing but activity models and classes > that only have attributes. The activity models execute without active > objects, which is the point of CallInvocationEvent. This is absolutely > critical to systems engineering and business process models. I > understand behaviors are objects, which is the escape hatch on this, but > it needs to be drawn much more clearly, especially in the causality > model. Also behaviors can be invoked continuously and provide continuous > output. > > Please give this one another week for discussion, to get input from the > process-focused users of UML. > > Thanks, > > Conrad From: "Thomas Weigert" To: "Branislav Selic" , , Subject: RE: Ballot 24 resolutions from Bran Date: Wed, 18 Aug 2004 22:29:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, comments so far.... 6395: This solution is not complete. If you want something to be redefinable, you also need to establish the redefinition context as well as add an association that redefines "redefinedElement". However, the resolution itself is inappropriate, I believe. There is a reason why Trigger is not redefinable: The souce state/trigger tuple uniquely identifies a transition. So redefining the Trigger would mean to redefine the transition. Thus you should just redefine the transition directly, by changing the Trigger, for example. There would be no point in redefining the Trigger itself. 6440: I personally think that the issuer raises a legitimate concern that many users will struggle with. The additions afforded by Component should just be available to StructuredClasses::Classes. This duplication of capability is more than confusing. 6902: In 6.3.3, there is a paragraph in black saying something about the causality model. The phrasing needs to clarified to make sure that the passing of information between behaviors in this manner is through the arguments passed by the invocation. As it stands now it reads as if two behaviors could wantonly exchange information during execution without sending messages. Any such information exchange that does not rely on the message exchange discussed in the basic causality model can only be through the parameters (or global variables). 6988: The use of "We may also represent..." is inappropriate wording for the specification. Use something like "An execution occurrence may also be represented by ...." instead. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 18, 2004 9:54 PM To: uml2-superstructure-ftf@omg.org; mu2i-ftf@omg.org Subject: Ballot 24 resolutions from Bran Attached, please find proposals for 24 issue resolutions for ballot 24 (rhymes nicely, doesn't it?) Many of them are deferrals, but some of them are real resolutions. They cover a range of areas including classes, state machines, components, interactions, and "general" stuff. Since some of them were originally assigned to other FTF members, please have a look at them, just in case you are working on a resolution to the same issue. Regards, Bran To: "Thomas Weigert" Cc: mu2i-ftf@omg.org, uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 resolutions from Bran X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 18 Aug 2004 23:50:05 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/18/2004 23:50:07, Serialize complete at 08/18/2004 23:50:07 Thanks, Thomas. Feedback embedded below: > 6395: This solution is not complete. If you want something to be > redefinable, you also need to establish the redefinition context as > well as add an association that redefines "redefinedElement". > > However, the resolution itself is inappropriate, I believe. There is > a reason why Trigger is not redefinable: The souce state/trigger > tuple uniquely identifies a transition. So redefining the Trigger > would mean to redefine the transition. Thus you should just redefine > the transition directly, by changing the Trigger, for example. There > would be no point in redefining the Trigger itself. There seems something wrong with the reasoning here: a transition is a model element that has identity. Redefining one of its "features" in a subclass does not change its identity. The purpose of redefinition is to maximize reuse. (Anyways, I'll think about this one a bit more -- I'm not thinking straight any more.) > 6440: I personally think that the issuer raises a legitimate concern > that many users will struggle with. The additions afforded by > Component should just be available to StructuredClasses::Classes. > This duplication of capability is more than confusing. Personally, I agree with you -- I do not see much value in the extra capabilities that components add. However, this is an argument that was prolonged and rather bitter and not one we will ever resolve by ourselves (the market will). I also believe that the folks who raised the issue, were not aware of the inheritance relationship between these two. What would you suggest? > 6902: In 6.3.3, there is a paragraph in black saying something about > the causality model. The phrasing needs to clarified to make sure > that the passing of information between behaviors in this manner is > through the arguments passed by the invocation. As it stands now it > reads as if two behaviors could wantonly exchange information during > execution without sending messages. Any such information exchange > that does not rely on the message exchange discussed in the basic > causality model can only be through the parameters (or global variables). What you have there is Cornad's last revision. I have no more energy or time to work on this, so I just put it out for comment. If people feel that it is busted, I will pull it and defer it until kingdom come. I am quite disappointed with how this one turned out. > 6988: The use of "We may also represent..." is inappropriate wording > for the specification. Use something like "An execution occurrence > may also be represented by ...." instead. Actually I agree with you. However, the colloquial "we" is used throughout this chapter and fixing it in this one place only makes it inconsistent. The problem of idiosyncratic writing and formatting styles is endemic throughout the spec. Thanks...Bran From: "Thomas Weigert" To: "Branislav Selic" , "Thomas Weigert" Cc: , Subject: RE: Ballot 24 resolutions from Bran Date: Wed, 18 Aug 2004 23:11:58 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Bran, please see below... -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, August 18, 2004 10:50 PM To: Thomas Weigert Cc: mu2i-ftf@omg.org; uml2-superstructure-ftf@omg.org Subject: RE: Ballot 24 resolutions from Bran Thanks, Thomas. Feedback embedded below: > 6395: This solution is not complete. If you want something to be > redefinable, you also need to establish the redefinition context as > well as add an association that redefines "redefinedElement". > > However, the resolution itself is inappropriate, I believe. There is > a reason why Trigger is not redefinable: The souce state/trigger > tuple uniquely identifies a transition. So redefining the Trigger > would mean to redefine the transition. Thus you should just redefine > the transition directly, by changing the Trigger, for example. There > would be no point in redefining the Trigger itself. There seems something wrong with the reasoning here: a transition is a model element that has identity. Redefining one of its "features" in a subclass does not change its identity. The purpose of redefinition is to maximize reuse. (Anyways, I'll think about this one a bit more -- I'm not thinking straight any more.) Probably no great harm is done in making this redefinable, albeit I cannot quite see the application. However, if you decide to, you will have to add the associations described in the first paragraph, otherwise it does not work. > 6440: I personally think that the issuer raises a legitimate concern > that many users will struggle with. The additions afforded by > Component should just be available to StructuredClasses::Classes. > This duplication of capability is more than confusing. Personally, I agree with you -- I do not see much value in the extra capabilities that components add. However, this is an argument that was prolonged and rather bitter and not one we will ever resolve by ourselves (the market will). I also believe that the folks who raised the issue, were not aware of the inheritance relationship between these two. What would you suggest? Yes, this is a difficult question. I noticed that at least one of the popular UML text books got this all confused, so I worry about the user. Maybe a "Defer"? Your call. > 6902: In 6.3.3, there is a paragraph in black saying something about > the causality model. The phrasing needs to clarified to make sure > that the passing of information between behaviors in this manner is > through the arguments passed by the invocation. As it stands now it > reads as if two behaviors could wantonly exchange information during > execution without sending messages. Any such information exchange > that does not rely on the message exchange discussed in the basic > causality model can only be through the parameters (or global variables). What you have there is Cornad's last revision. I have no more energy or time to work on this, so I just put it out for comment. If people feel that it is busted, I will pull it and defer it until kingdom come. I am quite disappointed with how this one turned out. I understand your frustration. How about changing the first sentence following Fig. 2 to "The causality model also subsumes behaviors invoking each other and passing information to each other through arguments to parameters of the invoked behavior, as enabled by CallBehaviorAction (see page XXX)." > 6988: The use of "We may also represent..." is inappropriate wording > for the specification. Use something like "An execution occurrence > may also be represented by ...." instead. Actually I agree with you. However, the colloquial "we" is used throughout this chapter and fixing it in this one place only makes it inconsistent. The problem of idiosyncratic writing and formatting styles is endemic throughout the spec. I see. You are right. Making this one change is just a drop in the bucket... Thanks...Bran Reply-To: From: "Conrad Bock" To: , Subject: RE: Ballot 24 draft Date: Fri, 20 Aug 2004 13:04:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Comments on ballot 24 below. Conrad - 4932 (Starting state machine) Typo: replace "filter" with "filer". - 5979 (The description of DataType is plainly wrong in the specification) Typo: "considered the be the same". I assume the Figure 41 example will be included in the final document, even though it isn't in the resolution? The removal of presentation options and style guidelines is a separate issue isn't it? - 6171 (Operation) The new text should refer to Generalization::isSubstitutable, rather than say issues of substitutability are out of scope. - 6616 (UML Superstructure FTF : isRoot property disappeared) The resolution says that isRoot can be derived from whether a classifier has supertypes. This is incorrect, because isRoot is a record for modeler intent that no supertypes will be defined for the classifier. It is analogous to isLeaf, which declares there will be no subtypes, so compilers can optimize message passing into function invocation. I don't mind that isRoot was removed, but the issue should not say it is derivable. - 6902 (Identify sections specifying run-time semantics) Thanks for the update on this. Combined with Jim R's much improved description of events in common behavior, this will be OK for process modelers. (Since the separation of inter- and intra-object is not reflected much in actions and behaviors, it still seems a little confusing, but we don't have time for another update). Typo: "TThese". - 6975 (missing illustrations of graphical paths for create and destroy message) The issues asks for examples, not new notation. That seems reasonable, so this one can be deferred. - 7219 (Operations and derived attributes) One of the roles of FTF/RTF's is to answer questions, even if there is no change. If there is not time to answer these, they can be deferred. - 7438 (Section: 12.3.3) The resolution is incorrect (this should have been assigned to Activities). Here is the resolution: "Connectors are purely notational and have no name. The name displayed is the name of the edge. This is stated by the first sentence under Figure 207. However, there may be an issue that edges are not contained by ownedMember, to be restricted by the Activity namespace, but this requires more discussion to resolve."