Issue 7673: Active and passive (uml2-superstructure-ftf) Source: International Business Machines (Dr. James Rumbaugh, nobody) Nature: Uncategorized Issue Severity: Summary: I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. Resolution: Revised Text: Actions taken: September 3, 2004: received issue Discussion: End of Annotations:===== c: "Joaquin Miller" , "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" Subject: Active and passive X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Fri, 3 Sep 2004 12:41:50 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/03/2004 13:41:52, Serialize complete at 09/03/2004 13:41:52 I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that. From: "Thomas Weigert" To: "James E Rumbaugh" Cc: "Joaquin Miller" , "Karl Frank" , "UML Superstructure FTF" Subject: RE: Active and passive Date: Fri, 3 Sep 2004 14:48:50 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) I agree on (1)-(3). Regarding (4), any behavior can be described in a statemachine, be it on active or passive objects. The differentiating thing for statemachines, in my opinion, is (2). Th. -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Friday, September 03, 2004 2:42 PM To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that. Subject: RE: Active and passive Date: Mon, 6 Sep 2004 09:28:37 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Active and passive Thread-Index: AcSR7n0L9B/f8wk5SJmVQQN8hhPBhwB9E13g From: "Anders Ek" To: "James E Rumbaugh" , "Thomas Weigert" Cc: "Joaquin Miller" , "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" Many things in UML have a definition that is not defined in detail. .Active. and .passive. are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don.t define their precise semantics in UML. So I don.t agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that. From: Eran Gery To: Anders Ek , James E Rumbaugh , Thomas Weigert Cc: Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject: RE: Active and passive Date: Mon, 6 Sep 2004 13:46:50 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. .Active. and .passive. are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don.t define their precise semantics in UML. So I don.t agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that. image001.jpg image002.jpg Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Mon, 06 Sep 2004 10:12:29 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Active and passive Eran wrote: I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. Anders wrote: Many things in UML have a definition that is not defined in detail. Active and passive are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don t define their precise semantics in UML. So I don t agree that we should remove the concept. We can go along with this approach. But only if the current attempts at definition are removed. Cordially, Joaquin -----Original Message----- Jim R. wrote: I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 6 Sep 2004 16:56:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/06/2004 16:56:39, Serialize complete at 09/06/2004 16:56:39 I have not heard any objections to the definition that is currently in the spec that I cited yesterday. This definition has been there for almost two years and no no issue has been raised against this definition. So, let's leave it be and let's concentrate on issues that we really need to resolve. Bran Joaquin Miller 09/06/2004 01:12 PM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject RE: Active and passive Eran wrote: I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. Anders wrote: Many things in UML have a definition that is not defined in detail. Active and passive are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don t define their precise semantics in UML. So I don t agree that we should remove the concept. We can go along with this approach. But only if the current attempts at definition are removed. Cordially, Joaquin -----Original Message----- Jim R. wrote: I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. To: Eran Gery Cc: Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh , Thomas Weigert , UML Superstructure FTF Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 6 Sep 2004 16:59:05 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/06/2004 16:59:24, Serialize complete at 09/06/2004 16:59:24 There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as ..the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. ..Active.. and ..passive.. are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don..t define their precise semantics in UML. So I don..t agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] To: Branislav Selic Cc: Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Tue, 7 Sep 2004 10:21:38 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/07/2004 11:21:45, Serialize complete at 09/07/2004 11:21:45 This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. .Active. and .passive. are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don.t define their precise semantics in UML. So I don.t agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] Subject: RE: Active and passive Date: Tue, 7 Sep 2004 12:47:18 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Active and passive Thread-Index: AcSUVGgmsl+AqpJMRdG6VpZ7cW7YygAvX0GA From: "Karl Frank" To: "Branislav Selic" , Cc: "UML Superstructure FTF" X-OriginalArrivalTime: 07 Sep 2004 19:47:23.0073 (UTC) FILETIME=[7E65BB10:01C49513] Issue: included use case wrongly referred to as the including use case Section 16.3.5 Include (from UseCases) The Semantics section for Inlcude, page 603 in the 042808.pdf convenience document, says "An include relationship between two use cases means that the behavior defined in the including use case is included in the behavior of the base use case." For "including" read "included (or addition) " and for "base" read "base (or including)". The parenthetical "addition" is needed because this is the term used in the abstract syntax, which does not have "included" as a rolename. Likewise, the abstract syntax does not recognize a role called "base use case" but calls it the "includingCase". uses the term -------------------------------------------------------------------------------- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Monday, September 06, 2004 4:59 PM To: Eran Gery Cc: Anders Ek; Joaquin Miller; Karl Frank; James E Rumbaugh; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as .the object having its own thread of control..) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. .Active. and .passive. are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don.t define their precise semantics in UML. So I don.t agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] From: "Mellor, Stephen" To: James E Rumbaugh , Thomas Weigert Cc: Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Active and passive Date: Tue, 7 Sep 2004 18:36:00 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) Please do not take away the current definition of active/passive. It is one of my favorite examples That good enough motivation to fix it? :) -------------------------------------------------------------------------------- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: 2004-09-03, Friday 12:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that. ATT817227.jpg ATT817228.jpg From: Eran Gery To: James E Rumbaugh , Branislav Selic Cc: Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject: RE: Active and passive Date: Wed, 8 Sep 2004 12:56:45 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] ATT02300.jpg ATT02301.jpg Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Wed, 08 Sep 2004 08:26:28 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Active and passive Thanks, Eran. I just toss this out as a quick, and not dirty, solution in these, our last days. Leave isActive. Leave it as a Boolean flag. Clean up the definition, being as specific as possible. Then... Specify that the opposite of isActive is: is not active. In other words, drop passive object. This does not harm those folks who rely on passive object, certainly not those in whose philosophies any object that is not active is passive. This does require removing the attempts to define 'passive object.' I feel this change is easily accomplished, does no injury to the various schools of users, and is a valuable cleanup. Cordially, Joaquin At 02:56 AM 9/8/2004, Eran Gery wrote: Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] To: Eran Gery Cc: Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , James E Rumbaugh , Thomas Weigert , UML Superstructure FTF Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 8 Sep 2004 12:21:03 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/08/2004 12:21:01, Serialize complete at 09/08/2004 12:21:01 I don't think it is a valid question. Monitors can be implemented by either active or passive objects (I have seen both). From what I recall, the original definition from Hoare had them as passive objects. You can implement them with an active object whose classifier behavior consists of a loop in which the monitor is accepting and then responding to synchronizaiton requests. Bran Eran Gery 09/08/2004 05:56 AM To James E Rumbaugh , Branislav Selic/Ottawa/IBM@IBMCA cc Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02300.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02301.jpg" deleted by Branislav Selic/Ottawa/IBM] To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Wed, 8 Sep 2004 09:29:16 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/08/2004 10:29:22, Serialize complete at 09/08/2004 10:29:22 I think this is an excellent solution that accommodates all the examples posed. IsActive means that it has its own essential behavior (state machine, procedure, whatever) that starts automatically when the object is created (the StartOwnedBehaviorAction is really at a different level of modeling). Then also accept that any object may handle ordinary calls to ordinary operations if its class provides operations, and each execution of a called operation will be a new execution ("thread of control", but we don't define that term) that is concurrent with other calls AND with any "active" behavior. Active behavior and "passive" behavior are independent and may coexist. There is no need for an isPassive flag or for a definition of passive object. To answer Eran's question, I believe that a monitor (a "protected object" that synchronizes calls to it) must be considered an active object. The very act of synchronization implies that there is a piece of ongoing executable logic that is continually waiting for ONE event at a time and pushing others onto a queue to wait their turn. That's exactly the definition of a state machine! Of course, you don't have to IMPLEMENT an active object as a heavyweight process. That's where many people are getting confused. You can steal a ride on another process, which is what classical monitors do, but that's also how you can implement state machines, or, indeed, that's how heavyweight processes themselves are implemented in operating systems. Think of an active object as an ongoing execution that synchronizes multiple events, and you will get a better way to model computations than thinking in terms of operating system processes. Think of calls as spawning temporary one-time executions that run concurrently with each other and with active objects. - Jim Rumbaugh Joaquin Miller 09/08/2004 08:26 AM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject RE: Active and passive Thanks, Eran. I just toss this out as a quick, and not dirty, solution in these, our last days. Leave isActive. Leave it as a Boolean flag. Clean up the definition, being as specific as possible. Then... Specify that the opposite of isActive is: is not active. In other words, drop passive object. This does not harm those folks who rely on passive object, certainly not those in whose philosophies any object that is not active is passive. This does require removing the attempts to define 'passive object.' I feel this change is easily accomplished, does no injury to the various schools of users, and is a valuable cleanup. Cordially, Joaquin At 02:56 AM 9/8/2004, Eran Gery wrote: Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] From: Eran Gery To: Branislav Selic Cc: Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh , Thomas Weigert , UML Superstructure FTF Subject: RE: Active and passive Date: Wed, 8 Sep 2004 19:53:35 +0300 X-Mailer: Internet Mail Service (5.5.2656.59) Bran - Strogly disagree. I do not think you can say a monitor is a "passive" object, as it interferes with responses to communication similar to an active object. Clearly you can implement a monitor with an active object, but this is an over qualification. If we have two classifications only - then monitor is active. But I think we are missing a point by ignoring that special case Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, September 08, 2004 7:21 PM To: Eran Gery Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; James E Rumbaugh; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive I don't think it is a valid question. Monitors can be implemented by either active or passive objects (I have seen both). From what I recall, the original definition from Hoare had them as passive objects. You can implement them with an active object whose classifier behavior consists of a loop in which the monitor is accepting and then responding to synchronizaiton requests. Bran Eran Gery 09/08/2004 05:56 AM To James E Rumbaugh , Branislav Selic/Ottawa/IBM@IBMCA cc Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02300.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02301.jpg" deleted by Branislav Selic/Ottawa/IBM] ATT00663.jpg ATT00664.jpg To: Eran Gery Cc: Anders Ek , Branislav Selic , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Wed, 8 Sep 2004 11:09:45 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/08/2004 11:09:48 Eran, Why do you say that MODELING (not IMPLEMENTING) a monitor with an active object is an overqualification? It is because you assume that active object implies a particular heavyweight implementation technology. But if you regard it as a MODELING concept, then there is no problem. We need to stop thinking of modeling as visual programming. Modeling attempts to abstract important concepts without committing to a particular implementation. This is a good example. A monitor (and think about what that word means in ordinary language) is an active object that continually monitors some condition and provides a bottleneck for external requests. That is a good way to think about it and to model it. It's only a problem if you assume the word "active" means "expensive". We need to stop thinking of UML concepts as implying heavyweight implementations. Active is not necessarily operating system process; association is not necessarily set of tuples that must be searched; port is not necessarily a stand-alone implementation object. - Jim Rumbaugh Eran Gery 09/08/2004 09:53 AM To Branislav Selic cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Bran - Strogly disagree. I do not think you can say a monitor is a "passive" object, as it interferes with responses to communication similar to an active object. Clearly you can implement a monitor with an active object, but this is an over qualification. If we have two classifications only - then monitor is active. But I think we are missing a point by ignoring that special case Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, September 08, 2004 7:21 PM To: Eran Gery Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; James E Rumbaugh; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive I don't think it is a valid question. Monitors can be implemented by either active or passive objects (I have seen both). From what I recall, the original definition from Hoare had them as passive objects. You can implement them with an active object whose classifier behavior consists of a loop in which the monitor is accepting and then responding to synchronizaiton requests. Bran Eran Gery 09/08/2004 05:56 AM To James E Rumbaugh , Branislav Selic/Ottawa/IBM@IBMCA cc Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02300.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02301.jpg" deleted by Branislav Selic/Ottawa/IBM] ATT006631.jpg From: "Eran Gery" To: "'James E Rumbaugh'" Cc: "'Anders Ek'" , "'Branislav Selic'" , "'Joaquin Miller'" , "'Karl Frank'" , "'Thomas Weigert'" , "'UML Superstructure FTF'" Subject: RE: Active and passive Date: Wed, 8 Sep 2004 22:35:04 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Jim I agree UML is about abstractions.. I also agree if we have two types of classifications a monitor is rather an active thing not passive. This whole thing is based on how one wants to abstract things out... To me, at the abstract level I see 3 types. Note that at the abstract level, you will see that a monitor doesn't quite fit your definition - it does no commences any activity but synchronizes its call. Now you can say synchronizing calls is an activity, but from my point of view it isn't.... So I think we could benefit from this 3 value classification, but now we have two and I believe we are in agreement as far as modeling with these two types (Active/Passive). (hopefully you agree that Active = not Passive) Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Wednesday, September 08, 2004 8:10 PM To: Eran Gery Cc: Anders Ek; Branislav Selic; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Eran, Why do you say that MODELING (not IMPLEMENTING) a monitor with an active object is an overqualification? It is because you assume that active object implies a particular heavyweight implementation technology. But if you regard it as a MODELING concept, then there is no problem. We need to stop thinking of modeling as visual programming. Modeling attempts to abstract important concepts without committing to a particular implementation. This is a good example. A monitor (and think about what that word means in ordinary language) is an active object that continually monitors some condition and provides a bottleneck for external requests. That is a good way to think about it and to model it. It's only a problem if you assume the word "active" means "expensive". We need to stop thinking of UML concepts as implying heavyweight implementations. Active is not necessarily operating system process; association is not necessarily set of tuples that must be searched; port is not necessarily a stand-alone implementation object. - Jim Rumbaugh Eran Gery 09/08/2004 09:53 AM To Branislav Selic cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Bran - Strogly disagree. I do not think you can say a monitor is a "passive" object, as it interferes with responses to communication similar to an active object. Clearly you can implement a monitor with an active object, but this is an over qualification. If we have two classifications only - then monitor is active. But I think we are missing a point by ignoring that special case Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, September 08, 2004 7:21 PM To: Eran Gery Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; James E Rumbaugh; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive I don't think it is a valid question. Monitors can be implemented by either active or passive objects (I have seen both). From what I recall, the original definition from Hoare had them as passive objects. You can implement them with an active object whose classifier behavior consists of a loop in which the monitor is accepting and then responding to synchronizaiton requests. Bran Eran Gery 09/08/2004 05:56 AM To James E Rumbaugh , Branislav Selic/Ottawa/IBM@IBMCA cc Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02300.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02301.jpg" deleted by Branislav Selic/Ottawa/IBM] To: "Eran Gery" Cc: "'Anders Ek'" , "'Branislav Selic'" , "'Joaquin Miller'" , "'Karl Frank'" , "'Thomas Weigert'" , "'UML Superstructure FTF'" Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.2CF1 June 9, 2003 From: James E Rumbaugh Date: Wed, 8 Sep 2004 13:00:31 -0700 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 09/08/2004 14:00:36, Serialize complete at 09/08/2004 14:00:36 Eran, There is the concurrency attribute on BehavioralFeature with value 'guarded', which ensures that only one execution of an operation on an object may proceed at once, which handles the monitor case without having an ongoing activity in the object. Note that it can be set for each operation, so that some might be monitor-like and others might be fully concurrent. This seems more flexible than labeling the entire object active/passive/monitor. I am arguing that these are separable and compatible capabilities that are not mutually exclusive. (I would choose to think of a monitor as a small ongoing execution that is blocked most of the time, but there is often more than one way to model something.) So right now, as I see it, "active" is a property of a class (and of its instances). You can do both "passive" calls and "monitor" calls on an individual operation basis for any object, and some calls/signals are "active" because they go directly to the ongoing execution. (So I don't agree that active = no passive calls, because I believe an object can do both.) I think we actually have modeled it pretty well right now. - Jim Rumbaugh "Eran Gery" 09/08/2004 12:35 PM To James E Rumbaugh/Cupertino/IBM@IBMUS cc "'Anders Ek'" , "'Branislav Selic'" , "'Joaquin Miller'" , "'Karl Frank'" , "'Thomas Weigert'" , "'UML Superstructure FTF'" Subject RE: Active and passive Jim I agree UML is about abstractions.. I also agree if we have two types of classifications a monitor is rather an active thing not passive. This whole thing is based on how one wants to abstract things out... To me, at the abstract level I see 3 types. Note that at the abstract level, you will see that a monitor doesn't quite fit your definition - it does no commences any activity but synchronizes its call. Now you can say synchronizing calls is an activity, but from my point of view it isn't.... So I think we could benefit from this 3 value classification, but now we have two and I believe we are in agreement as far as modeling with these two types (Active/Passive). (hopefully you agree that Active = not Passive) Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Wednesday, September 08, 2004 8:10 PM To: Eran Gery Cc: Anders Ek; Branislav Selic; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Eran, Why do you say that MODELING (not IMPLEMENTING) a monitor with an active object is an overqualification? It is because you assume that active object implies a particular heavyweight implementation technology. But if you regard it as a MODELING concept, then there is no problem. We need to stop thinking of modeling as visual programming. Modeling attempts to abstract important concepts without committing to a particular implementation. This is a good example. A monitor (and think about what that word means in ordinary language) is an active object that continually monitors some condition and provides a bottleneck for external requests. That is a good way to think about it and to model it. It's only a problem if you assume the word "active" means "expensive". We need to stop thinking of UML concepts as implying heavyweight implementations. Active is not necessarily operating system process; association is not necessarily set of tuples that must be searched; port is not necessarily a stand-alone implementation object. - Jim Rumbaugh Eran Gery 09/08/2004 09:53 AM To Branislav Selic cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Bran - Strogly disagree. I do not think you can say a monitor is a "passive" object, as it interferes with responses to communication similar to an active object. Clearly you can implement a monitor with an active object, but this is an over qualification. If we have two classifications only - then monitor is active. But I think we are missing a point by ignoring that special case Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, September 08, 2004 7:21 PM To: Eran Gery Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; James E Rumbaugh; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive I don't think it is a valid question. Monitors can be implemented by either active or passive objects (I have seen both). From what I recall, the original definition from Hoare had them as passive objects. You can implement them with an active object whose classifier behavior consists of a loop in which the monitor is accepting and then responding to synchronizaiton requests. Bran Eran Gery 09/08/2004 05:56 AM To James E Rumbaugh , Branislav Selic/Ottawa/IBM@IBMCA cc Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02300.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02301.jpg" deleted by Branislav Selic/Ottawa/IBM] To: "Eran Gery" Cc: "'Anders Ek'" , "'Joaquin Miller'" , "'Karl Frank'" , "'James E Rumbaugh'" , "'Thomas Weigert'" , "'UML Superstructure FTF'" Subject: RE: Active and passive X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Wed, 8 Sep 2004 17:56:05 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/08/2004 17:56:29, Serialize complete at 09/08/2004 17:56:29 I really wish we would spend more time on immediate FTF issues. This discussion clearly belongs in an RTF -- there is not even a formal issue raised. I have no intention of making this a priority issue for ballot 26 -- nothing that has transpired recently convinced me otherwise. I would prefer to see some feedback on the current set of issues, such as the new events proposal. Eran, what is your view of this -- it looks like the kind of stuff that your tool should be concerned with. Regards, Bran "Eran Gery" 09/08/2004 03:35 PM To "'James E Rumbaugh'" cc "'Anders Ek'" , Branislav Selic/Ottawa/IBM@IBMCA, "'Joaquin Miller'" , "'Karl Frank'" , "'Thomas Weigert'" , "'UML Superstructure FTF'" Subject RE: Active and passive Jim I agree UML is about abstractions.. I also agree if we have two types of classifications a monitor is rather an active thing not passive. This whole thing is based on how one wants to abstract things out... To me, at the abstract level I see 3 types. Note that at the abstract level, you will see that a monitor doesn't quite fit your definition - it does no commences any activity but synchronizes its call. Now you can say synchronizing calls is an activity, but from my point of view it isn't.... So I think we could benefit from this 3 value classification, but now we have two and I believe we are in agreement as far as modeling with these two types (Active/Passive). (hopefully you agree that Active = not Passive) Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Wednesday, September 08, 2004 8:10 PM To: Eran Gery Cc: Anders Ek; Branislav Selic; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Eran, Why do you say that MODELING (not IMPLEMENTING) a monitor with an active object is an overqualification? It is because you assume that active object implies a particular heavyweight implementation technology. But if you regard it as a MODELING concept, then there is no problem. We need to stop thinking of modeling as visual programming. Modeling attempts to abstract important concepts without committing to a particular implementation. This is a good example. A monitor (and think about what that word means in ordinary language) is an active object that continually monitors some condition and provides a bottleneck for external requests. That is a good way to think about it and to model it. It's only a problem if you assume the word "active" means "expensive". We need to stop thinking of UML concepts as implying heavyweight implementations. Active is not necessarily operating system process; association is not necessarily set of tuples that must be searched; port is not necessarily a stand-alone implementation object. - Jim Rumbaugh Eran Gery 09/08/2004 09:53 AM To Branislav Selic cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Bran - Strogly disagree. I do not think you can say a monitor is a "passive" object, as it interferes with responses to communication similar to an active object. Clearly you can implement a monitor with an active object, but this is an over qualification. If we have two classifications only - then monitor is active. But I think we are missing a point by ignoring that special case Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, September 08, 2004 7:21 PM To: Eran Gery Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; James E Rumbaugh; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive I don't think it is a valid question. Monitors can be implemented by either active or passive objects (I have seen both). From what I recall, the original definition from Hoare had them as passive objects. You can implement them with an active object whose classifier behavior consists of a loop in which the monitor is accepting and then responding to synchronizaiton requests. Bran Eran Gery 09/08/2004 05:56 AM To James E Rumbaugh , Branislav Selic/Ottawa/IBM@IBMCA cc Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02300.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02301.jpg" deleted by Branislav Selic/Ottawa/IBM] From: "Mellor, Stephen" To: James E Rumbaugh , Eran Gery Cc: "'Anders Ek'" , "'Branislav Selic'" , "'Joaquin Miller'" , "'Karl Frank'" , "'Thomas Weigert'" , "'UML Superstructure FTF'" X-Mailer: Internet Mail Service (5.5.2653.19) Subject: RE: Active and passive Date: Wed, 8 Sep 2004 18:36:18 -0400 X-Mailer: Internet Mail Service (5.5.2653.19) In executable UML, we need the ability to have class with a state machine tat describes the behavior of each instance, and/or one that describes the behavior of the set of instances--and acts therefore as a monitor. It is perfectly reasonable then, for us, to have a seemingly passive class with an "assigner" state machine that mediates control across its instances. IOW, Jim's analysis--plus Joaquin's latest issue--is what we need. BTW, we say we have an 'active class' if there is _any_ state machine associated with it. -- stephen -------------------------------------------------------------------------------- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: 2004-09-08, Wednesday 13:01 To: Eran Gery Cc: 'Anders Ek'; 'Branislav Selic'; 'Joaquin Miller'; 'Karl Frank'; 'Thomas Weigert'; 'UML Superstructure FTF' Subject: RE: Active and passive Eran, There is the concurrency attribute on BehavioralFeature with value 'guarded', which ensures that only one execution of an operation on an object may proceed at once, which handles the monitor case without having an ongoing activity in the object. Note that it can be set for each operation, so that some might be monitor-like and others might be fully concurrent. This seems more flexible than labeling the entire object active/passive/monitor. I am arguing that these are separable and compatible capabilities that are not mutually exclusive. (I would choose to think of a monitor as a small ongoing execution that is blocked most of the time, but there is often more than one way to model something.) So right now, as I see it, "active" is a property of a class (and of its instances). You can do both "passive" calls and "monitor" calls on an individual operation basis for any object, and some calls/signals are "active" because they go directly to the ongoing execution. (So I don't agree that active = no passive calls, because I believe an object can do both.) I think we actually have modeled it pretty well right now. - Jim Rumbaugh "Eran Gery" 09/08/2004 12:35 PM To James E Rumbaugh/Cupertino/IBM@IBMUS cc "'Anders Ek'" , "'Branislav Selic'" , "'Joaquin Miller'" , "'Karl Frank'" , "'Thomas Weigert'" , "'UML Superstructure FTF'" Subject RE: Active and passive Jim I agree UML is about abstractions.. I also agree if we have two types of classifications a monitor is rather an active thing not passive. This whole thing is based on how one wants to abstract things out... To me, at the abstract level I see 3 types. Note that at the abstract level, you will see that a monitor doesn't quite fit your definition - it does no commences any activity but synchronizes its call. Now you can say synchronizing calls is an activity, but from my point of view it isn't.... So I think we could benefit from this 3 value classification, but now we have two and I believe we are in agreement as far as modeling with these two types (Active/Passive). (hopefully you agree that Active = not Passive) Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Wednesday, September 08, 2004 8:10 PM To: Eran Gery Cc: Anders Ek; Branislav Selic; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Eran, Why do you say that MODELING (not IMPLEMENTING) a monitor with an active object is an overqualification? It is because you assume that active object implies a particular heavyweight implementation technology. But if you regard it as a MODELING concept, then there is no problem. We need to stop thinking of modeling as visual programming. Modeling attempts to abstract important concepts without committing to a particular implementation. This is a good example. A monitor (and think about what that word means in ordinary language) is an active object that continually monitors some condition and provides a bottleneck for external requests. That is a good way to think about it and to model it. It's only a problem if you assume the word "active" means "expensive". We need to stop thinking of UML concepts as implying heavyweight implementations. Active is not necessarily operating system process; association is not necessarily set of tuples that must be searched; port is not necessarily a stand-alone implementation object. - Jim Rumbaugh Eran Gery 09/08/2004 09:53 AM To Branislav Selic cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Bran - Strogly disagree. I do not think you can say a monitor is a "passive" object, as it interferes with responses to communication similar to an active object. Clearly you can implement a monitor with an active object, but this is an over qualification. If we have two classifications only - then monitor is active. But I think we are missing a point by ignoring that special case Eran -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Wednesday, September 08, 2004 7:21 PM To: Eran Gery Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; James E Rumbaugh; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive I don't think it is a valid question. Monitors can be implemented by either active or passive objects (I have seen both). From what I recall, the original definition from Hoare had them as passive objects. You can implement them with an active object whose classifier behavior consists of a loop in which the monitor is accepting and then responding to synchronizaiton requests. Bran Eran Gery 09/08/2004 05:56 AM To James E Rumbaugh , Branislav Selic/Ottawa/IBM@IBMCA cc Anders Ek , Eran Gery , Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive Jim I repeat my question to Bran, which may suggest an object with behavior, which is not passive and not active. I refer to "protected" object, and object that can synchronize calls to it (exists in Ada95, also known as "monitor" in the literature). Is it active, passive or neither ? I say it is in-between. It is not active as it does NOT "commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object". Is it passive ? not according to common intuition. and does not really meet your "Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." definition. Also, the fact that an active object has "passive" operations does not make it passive. In other words, I think that an object that has an active "aspect" is active, period. I think it is a good idea to have one classification of "activeness". My recommendation is to have - Active - an object owning its own "thread of computation" - Guarded - an object with synchronization agenda - Passive - the object does not interfere with concurrency at all Eran -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: Tuesday, September 07, 2004 8:22 PM To: Branislav Selic Cc: Anders Ek; Eran Gery; Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive This is a good definition of active that does capture the normal intuition. I like it. I think we also need a definition of "passive" that says something like: "A passive object is an object that accepts messages, some or all of which may cause the initiation of a new, independent execution of some behavior possibly dependent on the message, object type, and object values. Unless otherwise specified, there may be multiple executions of the same or different behaviors for a given passive object." This is intended to cover normal operation calls as well as more general forms of messaging. The key thing is that, for a passive object, the executions are a result of the message, not a result of the object's creation. And now, the key observation is that the same object may be BOTH active and passive. This doesn't happen all the time, and it may not be something that happens in all programming languages (although active objects don't happen in most programming languages either), but it is something that is compatible with the UML model. The attempt to treat active and passive as alternatives rather than separate properties has caused most of the confusion. For example, passive operations may be needed to support reflective operations on active objects. So we would want BOTH isActive and isPassive. If an object is neither, then it is pure data with no OO operations. [This may not be allowed in some OO languages, but UML should not rule it out. For example, maybe a database might choose to regard some objects that way.] - Jim Rumbaugh Branislav Selic 09/06/2004 01:59 PM To Eran Gery cc Anders Ek , Joaquin Miller , Karl Frank , James E Rumbaugh/Cupertino/IBM@IBMUS, Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive There is nothing fluid about the definition of active object. Are my e-mails not getting through? Here it is again, straight from the spec: "An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as "the object having its own thread of control".) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated." Cheers, Bran Eran Gery 09/06/2004 06:46 AM To Anders Ek , James E Rumbaugh , Thomas Weigert cc Joaquin Miller , Karl Frank , Thomas Weigert , UML Superstructure FTF Subject RE: Active and passive I support Anders here, although I am aware that the definition of Active is very fluid as far as how people interpret it. However I believe we are starting to debate something for the upcoming RTF right ? The FTF is over for this I believe. -----Original Message----- From: Anders Ek [mailto:anders.ek@telelogic.se] Sent: Monday, September 06, 2004 10:29 AM To: James E Rumbaugh; Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: RE: Active and passive Many things in UML have a definition that is not defined in detail. 'Active' and 'passive' are two concepts that very useful in practise and UML now provides a standardized notation for them even if we don't define their precise semantics in UML. So I don't agree that we should remove the concept. /Anders -----Original Message----- From: James E Rumbaugh [mailto:rumbaugh@us.ibm.com] Sent: den 3 september 2004 21:42 To: Thomas Weigert Cc: Joaquin Miller; Karl Frank; Thomas Weigert; UML Superstructure FTF Subject: Active and passive I think the phrases "active" and "passive" just get in the way and we would be well advised to drop them from the specification. They seem to mean various things to different people. I think it would be better to state the following, primary (unlike "active" and "passive") properties of objects and their classes: 1. They may or may not have their own thread of control (this is often called "active" but why not be more direct?) 1a. Which may be single or possibly multiple (not sure if this is relevant) 1b. Which may start automatically or may be explicitly started (but why whom??) 2. They may or may not have a queue for incoming events (often associated with #1, but we can decide whether they are completely linke) 3. They may or may not support operations which, if called, create new executions with their own threads of control (this is often called "passive") 4. They may or may not have state machines (often associated with #1, but there seems some debate about whether that is necessary) Note that various combinations of these are possible, so an object could be both "active" and "passive". But those words are just too empty in themselves unless they are defined in terms of these other properties, and if we do that, why do we need the terms "active" and "passive" at all? The current specification has a lousy definition of the terms, one that is circular. - Jim Rumbaugh "Thomas Weigert" 09/02/2004 07:48 PM To "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" cc Subject RE: Messages to ports with only one connector By classifier behavior I refer to the Behavior referenced by BehavioredClassifier.classifierBehavior. This is a privileged behavior of a classifier, invoked typically when an instance of the classifier is created. Usually, when people speak of the state machine of a classifier, they mean this Behavior, not any of the other behaviors that may be associated with a classifier... A classifier behavior (as used above) is not equivalent to behavior owned by a classifier. Please look at the current figure 311 "Common Behavior". You will see that there is at most one classifier behavior, but a classifier may own many behaviors (methods). You are correct in saying that there are no directly stated restrictions on the classifier behavior of passive classes, as I also described below. However, there are implied constraints from the fact that a passive object does not have its own thread of control. And then, in practice, you will find that a typical constraint is that a passive object does not have classifier behavior (but as I said below, that is not enforced by the UML). Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Thursday, September 02, 2004 9:38 PM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas: The clearest differentiation of active/passive object is the one you give in your first paragraph, where the distinction turns on whether an object has its own thread of control. This is the UML 2 view of active object, which you have in 13.3.9: But in the last two paragraphs of your explanation below, about the "impact of classifier behavior", quite a bit of weight is put on classifier behavior, as if it were a special or differentiated form of behavior. It isn't, at least not in UML 2 super spec. At least, I cannot find anything in the spec that differentiates classifier behavior from behavior. In UML 2, the qualifier "classifier.." in "classifier behavior" seems to be redundant. Under Behavior, for example, 13.3.3, it appears that Behavior is equivalent to Classifier Behavior, which is equivalent to Behavior owned by a Classifier. For example: This gives us no way to differentiate active object from passive, since either may be an instance of a classifier that owns a behavior, no? But I am not saying there is no difference, you give a good one in the first paragraph. The difference just isn't about classifier behavior. - Karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 9:36 PM To: Joaquin Miller; UML Superstructure FTF Subject: RE: Messages to ports with only one connector Actually, for passive objects it is not true that "the points at which the object responds to communication from other objects is determined solely by the behavior of the active object". Quite the contrary... A passive object does not have its own thread of computation; it does nothing until it is invoked by some other object, then it does its thing, and then it returns and again does nothing. However, we were focusing on the impact of the classifier behavior. While you are right, a passive object might also have a state machine or classifier behavior, as it is not ruled out, I have never seen it used that way. In the profiles that I am familiar with which actually generate behavior from UML, passive objects never have classifier behavior. My understanding (not enforced by the UML specification) is that an active object has a queue and classifier behavior, and a passive object does not. In addition, active objects have their own thread of control. The latter being the defining characteristic, which does imply that the active object can synchronize requests to it. A passive object cannot do so, and so something else has to protect it from concurrent access and violations of integrity. Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Thursday, September 02, 2004 7:29 PM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector The semantics of 13.3.9 Class (from Communications, specialized) says: "The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object." But that is true of objects of every class, isn't it? I'm not sure what 'responds' is intended to mean here, but certainly an object of any class determines when it makes an answer to a communication, and whether it makes an answer. Objects of any class can have behavior specified by a state machine and any state machine can defer, ignore, or discard (and even lose) events (including receipt of signals). (There are two mentions of active object in 15 State Machines, but neither suggests that a not-active object can't defer or ignore events. There is no mention of active objects in the discussion of deferred events.) And once an object accepts an event, it is in full control of what happens after that.[attachment "image001.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "image002.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02300.jpg" deleted by Branislav Selic/Ottawa/IBM] [attachment "ATT02301.jpg" deleted by Branislav Selic/Ottawa/IBM] ATT1134339.jpg ATT006641.jpg