Issue 7654: Messages to ports with only one connector (uml2-superstructure-ftf) Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: The semantics of Port says: > If there is a connector attached to only one side of a port, any > requests arriving at this port will terminate at this port. but it also says: > For a behavior port, the instance of the owning classifier will > handle requests arriving at this port (as specified in the behavior > of the classifier, see Chapter 13, Common Behaviors), if this > classifier has any behavior. And presumably for non-behavior ports, the message could be forwarded to the intefaces of the owning classifier. So the first statement above is incorrect, isn't it? Resolution: Revised Text: Actions taken: August 31, 2004: received issue Discussion: End of Annotations:===== eply-To: From: "Conrad Bock" To: "uml2ftf" Subject: Messages to ports with only one connector Date: Tue, 31 Aug 2004 09:48:01 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Composers, The semantics of Port says: > If there is a connector attached to only one side of a port, any > requests arriving at this port will terminate at this port. but it also says: > For a behavior port, the instance of the owning classifier will > handle requests arriving at this port (as specified in the behavior > of the classifier, see Chapter 13, Common Behaviors), if this > classifier has any behavior. And presumably for non-behavior ports, the message could be forwarded to the intefaces of the owning classifier. So the first statement above is incorrect, isn't it? Conrad To: Cc: "uml2ftf" Subject: Re: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 10:21:52 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 10:21:54, Serialize complete at 08/31/2004 10:21:54 Conrad, In reply: > The semantics of Port says: > > > If there is a connector attached to only one side of a port, any > > requests arriving at this port will terminate at this port. The term "terminate" means that it will not be relayed to any further destinations. If the thing at the other end of the port is a behavior then the message is taken over and processed by the behavior (eventuallY). If there is no behavior on the other side or another connector, the message just "runs out the end" and is lost. > but it also says: > > > For a behavior port, the instance of the owning classifier will > > handle requests arriving at this port (as specified in the behavior > > of the classifier, see Chapter 13, Common Behaviors), if this > > classifier has any behavior. > > And presumably for non-behavior ports, the message could be forwarded to > the intefaces of the owning classifier. No. See above. There is not path by which it can be forwarded -- the main point of connectors is to be explicit about communication channels and the connections that they establish. Implicit channels, such as you seem to be thinking of, defeat the whole purpose. > So the first statement above is > incorrect, isn't it? It is correct, although the term "terminate" is somewhat misleading and probably warrants a clarification. Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Messages to ports with only one connector Date: Tue, 31 Aug 2004 12:05:50 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > The term "terminate" means that it will not be relayed to any > further destinations. If the thing at the other end of the port > is a behavior then the message is taken over and processed by > the behavior (eventuallY). If there is no behavior on the other > side or another connector, the message just "runs out the end" > and is lost. > > And presumably for non-behavior ports, the message could be > > forwarded to the intefaces of the owning classifier. > > No. See above. There is not path by which it can be forwarded -- > the main point of connectors is to be explicit about > communication channels and the connections that they establish. > Implicit channels, such as you seem to be thinking of, defeat > the whole purpose. The message may be an operation call handled by method, with no classifier behavior involved. A port can forward an operation call it recieves to the owning classifier, can't it? Conrad To: Cc: "uml2ftf" Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 12:59:41 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 12:59:42, Serialize complete at 08/31/2004 12:59:42 > The message may be an operation call handled by method, with no > classifier behavior involved. A port can forward an operation call it > recieves to the owning classifier, can't it? Only if it is a behavior port. If it's not a behavior port, it can only forward things if there is a connector to forward it through. Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Messages to ports with only one connector Date: Tue, 31 Aug 2004 13:15:12 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > > The message may be an operation call handled by method, with no > > classifier behavior involved. A port can forward an operation > > call it recieves to the owning classifier, can't it? > Only if it is a behavior port. If it's not a behavior port, it can > only forward things if there is a connector to forward it through. OK, sounds like there should be a constraint that ports with one connector must be behavior ports. It's a strong limitation that ports can't pass methods calls to the owning object. Conrad To: Cc: "uml2ftf" Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 13:51:07 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 13:51:09, Serialize complete at 08/31/2004 13:51:09 > > > The message may be an operation call handled by method, with no > > > classifier behavior involved. A port can forward an operation > > > call it recieves to the owning classifier, can't it? > > > Only if it is a behavior port. If it's not a behavior port, it can > > only forward things if there is a connector to forward it through. > > OK, sounds like there should be a constraint that ports with one > connector must be behavior ports. It's a strong limitation that ports > can't pass methods calls to the owning object. No, that would be wrong. I may declare a port in some abstract class and only connect it to a part in a subclass -- this is one of the most common patterns. The subclass should not have to redefine the inherited port to be a non-behavior port. Bran To: Cc: "uml2ftf" Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 31 Aug 2004 15:29:39 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/31/2004 13:29:41, Serialize complete at 08/31/2004 13:29:41 Conrad, We'll have to check with Bran to be sure, but I think a port only "forwards" calls through a connector to another part in the owning classifier. "Conrad Bock" wrote on 08/31/2004 12:05:50 PM: > Bran, > > > The term "terminate" means that it will not be relayed to any > > further destinations. If the thing at the other end of the port > > is a behavior then the message is taken over and processed by > > the behavior (eventuallY). If there is no behavior on the other > > side or another connector, the message just "runs out the end" > > and is lost. > > > > And presumably for non-behavior ports, the message could be > > > forwarded to the intefaces of the owning classifier. > > > > No. See above. There is not path by which it can be forwarded -- > > the main point of connectors is to be explicit about > > communication channels and the connections that they establish. > > Implicit channels, such as you seem to be thinking of, defeat > > the whole purpose. > > The message may be an operation call handled by method, with no > classifier behavior involved. A port can forward an operation call it > recieves to the owning classifier, can't it? > > Conrad From: "Eran Gery" To: "'Jim Amsden'" , Cc: "'uml2ftf'" Subject: RE: Messages to ports with only one connector Date: Tue, 31 Aug 2004 23:47:45 +0300 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) Behavior ports activate behaviors directly on the owning classifier without having to forward them. You can have a class S with methods m1 and m2 and a behavior port P of type interface I providing m1 and m2. Any activation of m1 on the port would activate the method m1 of the classifier S. Note that S has no parts at all. -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, August 31, 2004 10:30 PM To: conrad.bock@nist.gov Cc: uml2ftf Subject: RE: Messages to ports with only one connector Conrad, We'll have to check with Bran to be sure, but I think a port only "forwards" calls through a connector to another part in the owning classifier. "Conrad Bock" wrote on 08/31/2004 12:05:50 PM: > Bran, > > > The term "terminate" means that it will not be relayed to any > > further destinations. If the thing at the other end of the port > > is a behavior then the message is taken over and processed by > > the behavior (eventuallY). If there is no behavior on the other > > side or another connector, the message just "runs out the end" > > and is lost. > > > > And presumably for non-behavior ports, the message could be > > > forwarded to the intefaces of the owning classifier. > > > > No. See above. There is not path by which it can be forwarded -- > > the main point of connectors is to be explicit about > > communication channels and the connections that they establish. > > Implicit channels, such as you seem to be thinking of, defeat > > the whole purpose. > > The message may be an operation call handled by method, with no > classifier behavior involved. A port can forward an operation call it > recieves to the owning classifier, can't it? > > Conrad To: "Eran Gery" Cc: conrad.bock@nist.gov, "'Jim Amsden'" , "'uml2ftf'" Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 17:07:26 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 17:07:28, Serialize complete at 08/31/2004 17:07:28 Well, I would argue that a behavior port forwards messages to the behavior, but that is mincing words more or less. More important to keep in mind that what makes a behavior port is that it involves some queueing, scheduling, and dispatching machinery, whereas non-behavior ports don't have any of that. Bran "Eran Gery" 08/31/2004 04:47 PM To "'Jim Amsden'" , cc "'uml2ftf'" Subject RE: Messages to ports with only one connector Behavior ports activate behaviors directly on the owning classifier without having to forward them. You can have a class S with methods m1 and m2 and a behavior port P of type interface I providing m1 and m2. Any activation of m1 on the port would activate the method m1 of the classifier S. Note that S has no parts at all. -----Original Message----- From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Tuesday, August 31, 2004 10:30 PM To: conrad.bock@nist.gov Cc: uml2ftf Subject: RE: Messages to ports with only one connector Conrad, We'll have to check with Bran to be sure, but I think a port only "forwards" calls through a connector to another part in the owning classifier. "Conrad Bock" wrote on 08/31/2004 12:05:50 PM: > Bran, > > > The term "terminate" means that it will not be relayed to any > > further destinations. If the thing at the other end of the port > > is a behavior then the message is taken over and processed by > > the behavior (eventuallY). If there is no behavior on the other > > side or another connector, the message just "runs out the end" > > and is lost. > > > > And presumably for non-behavior ports, the message could be > > > forwarded to the intefaces of the owning classifier. > > > > No. See above. There is not path by which it can be forwarded -- > > the main point of connectors is to be explicit about > > communication channels and the connections that they establish. > > Implicit channels, such as you seem to be thinking of, defeat > > the whole purpose. > > The message may be an operation call handled by method, with no > classifier behavior involved. A port can forward an operation call it > recieves to the owning classifier, can't it? > > Conrad From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Messages to ports with only one connector Date: Tue, 31 Aug 2004 16:25:11 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Dear all, compounded answers to various questions: > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Tuesday, August 31, 2004 8:48 AM > To: uml2ftf > Subject: Messages to ports with only one connector > 1. "terminate" > The semantics of Port says: > > > If there is a connector attached to only one side of a port, any > > requests arriving at this port will terminate at this port. > > but it also says: > > > For a behavior port, the instance of the owning classifier will > > handle requests arriving at this port (as specified in the behavior > > of the classifier, see Chapter 13, Common Behaviors), if this > > classifier has any behavior. > > And presumably for non-behavior ports, the message could be forwarded to > the intefaces of the owning classifier. So the first statement above is > incorrect, isn't it? > The formulation above is unfortunate, as it could be read the way you indicate. The intention is as you describe. If a non-behavior port has only one connector attached, the message will get lost. Alternatively, we could have said that any port that has only one connector attached is a behavior port... but we did not. 2. Behavior call vs. method > > The message may be an operation call handled by method, with no > classifier behavior involved. A port can forward an operation call it > recieves to the owning classifier, can't it? > There is no difference between an operation invocation or a signal sent. It is either forwarded on a connector, or goes to a behavior port (in which case the method of the classifier owning that port is called), or it is lost. > OK, sounds like there should be a constraint that ports with one > connector must be behavior ports. It's a strong limitation that ports > can't pass methods calls to the owning object. > There is no such limitation. Any message (signal or operation invocation/method call) that goes to a behavior port is addressed to the classifier owning that port. Reply-To: From: "Conrad Bock" To: "'uml2ftf'" Subject: RE: Messages to ports with only one connector Date: Thu, 2 Sep 2004 10:26:34 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, et al > [Bran] More important to keep in mind that what makes a behavior port > is that it involves some queueing, scheduling, and dispatching > machinery, whereas non-behavior ports don't have any of that. > [Eran] You can have a class S with methods m1 and m2 and a behavior > port P of type interface I providing m1 and m2. Any activation of m1 > on the port would activate the method m1 of the classifier S. > [Thomas] There is no difference between an operation invocation or a > signal sent. It is either forwarded on a connector, or goes to a > behavior port (in which case the method of the classifier owning that > port is called), or it is lost. I'd go with the last two above, if I'm understanding it right: an operation call to a behavior port can be handled by a method on the owning object, without going to the event queue or classifier behavior. So the text "if this classifier has any behavior" in: For a behavior port, the instance of the owning classifier will handle requests arriving at this port (as specified in the behavior of the classifier, see Chapter 13, Common Behaviors), if this classifier has any behavior. would be interpreted as potentially being a method. > > [Conrad] OK, sounds like there should be a constraint that ports > > with one connector must be behavior ports. It's a strong > > limitation that ports can't pass methods calls to the owning > > object. > [Bran] No, that would be wrong. I may declare a port in some abstract > class and only connect it to a part in a subclass -- this is one of > the most common patterns. The subclass should not have to redefine > the inherited port to be a non-behavior port. Then the constraint could be narrowed to concrete classes. Conrad To: Cc: "'uml2ftf'" Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 2 Sep 2004 10:32:28 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/02/2004 10:32:31, Serialize complete at 09/02/2004 10:32:31 > I'd go with the last two above, if I'm understanding it right: an > operation call to a behavior port can be handled by a method on the > owning object, without going to the event queue or classifier behavior. > So the text "if this classifier has any behavior" in: > > For a behavior port, the instance of the owning classifier will handle > requests arriving at this port (as specified in the behavior of the > classifier, see Chapter 13, Common Behaviors), if this classifier has > any behavior. > > would be interpreted as potentially being a method. methods still requires dispatching... Bran From: "Thomas Weigert" To: , "'uml2ftf'" Subject: RE: Messages to ports with only one connector Date: Thu, 2 Sep 2004 09:43:46 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Conrad, it is my understanding of the UML that the semantic of active classes is that they are managing the communications through the queue. Otherwise you would end up with well-known concurrency disasters. So, if by method call you mean bypassing the synchronization mechanisms implied by being an active class, the answer to your question should be "no". If by method you mean the invocation of a behavior specified by an operation in response to receiving the invocation event, the answer is "yes". Again, by definition, the active class is in control of how it responds to any communication. That is the defining difference between an active and a passive class. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, September 02, 2004 9:27 AM > To: 'uml2ftf' > Subject: RE: Messages to ports with only one connector > > > Bran, et al > > > [Bran] More important to keep in mind that what makes a behavior port > > is that it involves some queueing, scheduling, and dispatching > > machinery, whereas non-behavior ports don't have any of that. > > > [Eran] You can have a class S with methods m1 and m2 and a behavior > > port P of type interface I providing m1 and m2. Any activation of m1 > > on the port would activate the method m1 of the classifier S. > > > [Thomas] There is no difference between an operation invocation or a > > signal sent. It is either forwarded on a connector, or goes to a > > behavior port (in which case the method of the classifier owning that > > port is called), or it is lost. > > I'd go with the last two above, if I'm understanding it right: an > operation call to a behavior port can be handled by a method on the > owning object, without going to the event queue or classifier behavior. > So the text "if this classifier has any behavior" in: > > For a behavior port, the instance of the owning classifier will handle > requests arriving at this port (as specified in the behavior of the > classifier, see Chapter 13, Common Behaviors), if this classifier has > any behavior. > > would be interpreted as potentially being a method. > Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Messages to ports with only one connector Date: Thu, 2 Sep 2004 10:57:37 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > it is my understanding of the UML that the semantic of active classes > is that they are managing the communications through the queue. Agreed, though presumably a class doesn't need to be active to receive messages through ports, and even if that were so, the classifier behavior isn't necessarily involved if the message just invokes an operation. Regardless of these details, my original question is answered, I think: an operation call can arrive at a behavior port and be handled by a method on the owning object, without going to the classifier behavior. I can file an issue for a small clarification of wording on this. Conrad From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Messages to ports with only one connector Date: Thu, 2 Sep 2004 11:32:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Well, yes and no... 1. An operation invoked at a port can end up in a method call 2. The operation invocation at the port is first handled by the classifier behavior to ensure that synchronization issues are resolved. This leaves open the question of what happens if there is no classifier behavior... I guess an interpretation is possible that then a method is invoked directly. The other open issue is what would happen if the operation invoked is not handled in the classifier behavior.... again, an interpretation would be possible that would lead to a direct method invocation. Personally, I don't think the last two cases are intended. But we don't necessarily need to rule these out but could leave them as semantic variation points. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, September 02, 2004 9:58 AM > To: uml2ftf > Subject: RE: Messages to ports with only one connector > > > Thomas, > > > it is my understanding of the UML that the semantic of active classes > > is that they are managing the communications through the queue. > > Agreed, though presumably a class doesn't need to be active to receive > messages through ports, and even if that were so, the classifier > behavior isn't necessarily involved if the message just invokes an > operation. > > Regardless of these details, my original question is answered, I think: > an operation call can arrive at a behavior port and be handled by a > method on the owning object, without going to the classifier behavior. > I can file an issue for a small clarification of wording on this. > > Conrad Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Sep 2004 09:46:10 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Messages to ports with only one connector Again, by definition, the active class is in control of how it responds to any communication. That is the defining difference between an active and a passive class. That's clearly stated. Is this defining difference explicit and clear in the text? To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 2 Sep 2004 14:57:26 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/02/2004 14:57:27, Serialize complete at 09/02/2004 14:57:27 Yes it is. See the definition of "isActive". Bran Joaquin Miller 09/02/2004 12:46 PM Please respond to Joaquin Miller To UML Superstructure FTF cc Subject RE: Messages to ports with only one connector >Again, by definition, the active class is in control of how it responds to >any communication. That is the defining difference between an active and a >passive class. That's clearly stated. Is this defining difference explicit and clear in the text? Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Thu, 02 Sep 2004 17:28:43 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Messages to ports with only one connector [I guess this discussion is off topic, and not the subject of a current issue, right?] Yes it is. See the definition of "isActive". In UML2-Super.book.040829.pdf we find: "Attributes ". isActive: Boolean Determines whether an object specified by this class is active or not. If true, then the owning class is referred to as an active class. If false, then such a class is referred to as a passive class." That seems to define isActive as meaning: is active. ....... 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. Cordially, Joaquin >Again, by definition, the active class is in control of how it responds to >any communication. That is the defining difference between an active and a >passive class. That's clearly stated. Is this defining difference explicit and clear in the text? From: "Thomas Weigert" To: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: Messages to ports with only one connector Date: Thu, 2 Sep 2004 20:35:47 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) 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: Messages to ports with only one connector Date: Thu, 2 Sep 2004 19:37:51 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Messages to ports with only one connector Thread-Index: AcSRVuu0NadTe3qtSj2yotSXLM9FxAABYqNg From: "Karl Frank" To: "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" X-OriginalArrivalTime: 03 Sep 2004 02:37:52.0968 (UTC) FILETIME=[02E4B480:01C4915F] 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: "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" Subject: RE: Messages to ports with only one connector Date: Thu, 2 Sep 2004 21:48:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) 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: Messages to ports with only one connector Date: Fri, 3 Sep 2004 05:44:19 -0700 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: Messages to ports with only one connector Thread-Index: AcSRYRd5Rsq58Jx5SEqSktRAMs65owAUFoHQ From: "Karl Frank" To: "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" , X-OriginalArrivalTime: 03 Sep 2004 12:44:23.0393 (UTC) FILETIME=[BD46E510:01C491B3] Thomas: Your explanation makes it all fall into place. Too bad it isn't in the spec. The relevant part to understanding classifierBehavior appears to be the special role of StartBehaviorAction, where it is noted that it replaces StartStateMachine. - karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 10:49 PM To: Karl Frank; Thomas Weigert; UML Superstructure FTF; Joaquin Miller 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: "Karl Frank" , "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" , Subject: RE: Messages to ports with only one connector Date: Fri, 3 Sep 2004 07:45:00 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Karl, thanks. But I don't understand why you say that this explanation is not in the specification (other than the piece about my personal opinion regarding classifier behavior for passive objects). Everything I said is right out of the UML 2 doc. (If it is not in the specification, it should be...) Th. -----Original Message----- From: Karl Frank [mailto:Karl.Frank@borland.com] Sent: Friday, September 03, 2004 7:44 AM To: Thomas Weigert; UML Superstructure FTF; Joaquin Miller; conrad.bock@nist.gov Subject: RE: Messages to ports with only one connector Thomas: Your explanation makes it all fall into place. Too bad it isn't in the spec. The relevant part to understanding classifierBehavior appears to be the special role of StartBehaviorAction, where it is noted that it replaces StartStateMachine. - karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 10:49 PM To: Karl Frank; Thomas Weigert; UML Superstructure FTF; Joaquin Miller 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. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 03 Sep 2004 06:42:54 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Messages to ports with only one connector But I don't understand why you say that this explanation is not in the specification (other than the piece about my personal opinion regarding classifier behavior for passive objects). Everything I said is right out of the UML 2 doc. (If it is not in the specification, it should be...) We could have more clarity and specificity at the point where isActive is defined. The specification of isActive certainly says nothing about what it means to be an active class. No one will disagree with that. The text under Semantics for this version of Classifier does not do the job that Thomas has done in these messages. It makes no mention of a passive object. (Example: That text is consistent with this: On the other hand, the classifier behavior of a passive object may commence at some time after its creation. If the classifier behavior of a passive object completes, the object is not terminated.) -----Original Message----- 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: "Joaquin Miller" , "UML Superstructure FTF" Subject: RE: Messages to ports with only one connector Date: Fri, 3 Sep 2004 09:06:03 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Joaquin, I think it is ok for classifier not to explain this in more detail, as the explanation of what an active object is belongs in CommonBehavior. The section in classifier just points to that (not explicitly, as this section does not know about common behavior). Th. -----Original Message----- From: Joaquin Miller [mailto:jm-omg@sbcglobal.net] Sent: Friday, September 03, 2004 8:43 AM To: UML Superstructure FTF Subject: RE: Messages to ports with only one connector But I don't understand why you say that this explanation is not in the specification (other than the piece about my personal opinion regarding classifier behavior for passive objects). Everything I said is right out of the UML 2 doc. (If it is not in the specification, it should be...) We could have more clarity and specificity at the point where isActive is defined. The specification of isActive certainly says nothing about what it means to be an active class. No one will disagree with that. The text under Semantics for this version of Classifier does not do the job that Thomas has done in these messages. It makes no mention of a passive object. (Example: That text is consistent with this: On the other hand, the classifier behavior of a passive object may commence at some time after its creation. If the classifier behavior of a passive object completes, the object is not terminated.) -----Original Message----- 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. Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Fri, 03 Sep 2004 09:32:03 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Messages to ports with only one connector Thomas. Thanks. Sorry. I made a mistake in my message. When I wrote "this version of Classifier," i should have written "this version of Class." I meant the version of Class specified at 13.3.9 in Common Behavior I think it is ok for classifier not to explain this in more detail, as the explanation of what an active object is belongs in CommonBehavior. The section in classifier just points to that (not explicitly, as this section does not know about common behavior). -----Original Message----- We could have more clarity and specificity at the point where isActive is defined. The specification of isActive certainly says nothing about what it means to be an active class. No one will disagree with that. The text under Semantics for this version of Classifier does not do the job that Thomas has done in these messages. It makes no mention of a passive object. (Example: That text is consistent with this: On the other hand, the classifier behavior of a passive object may commence at some time after its creation. If the classifier behavior of a passive object completes, the object is not terminated.) -----Original Message----- 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.) To: "Karl Frank" Cc: conrad.bock@nist.gov, "Joaquin Miller" , "Thomas Weigert" , "UML Superstructure FTF" Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Sun, 5 Sep 2004 15:21:43 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/05/2004 15:22:01, Serialize complete at 09/05/2004 15:22:01 The definition of active object intentionally leaves out the notion of "thread of control" because that is extremely difficult ot define without getting technology specific. So, please do not use that as a defining feature. The defining features are: (a) the object executes a behavior following creation which it keeps executing until it is terminated and (b) while executing this behavior, it decides when to do "receive" actions. It's pretty simple really. Let's not invoke silly and needless references to "threads of control" (item (a) takes case of that). Here is what is written in 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. Regards Bran "Karl Frank" 09/03/2004 08:44 AM To "Thomas Weigert" , "UML Superstructure FTF" , "Joaquin Miller" , cc Subject RE: Messages to ports with only one connector Thomas: Your explanation makes it all fall into place. Too bad it isn't in the spec. The relevant part to understanding classifierBehavior appears to be the special role of StartBehaviorAction, where it is noted that it replaces StartStateMachine. - karl -------------------------------------------------------------------------------- From: Thomas Weigert [mailto:thomas.weigert@motorola.com] Sent: Thursday, September 02, 2004 10:49 PM To: Karl Frank; Thomas Weigert; UML Superstructure FTF; Joaquin Miller 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: "'Branislav Selic'" , "'Karl Frank'" Cc: , "'Joaquin Miller'" , "'UML Superstructure FTF'" Subject: RE: Messages to ports with only one connector Date: Sun, 5 Sep 2004 14:31:14 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2627 Agreed. As a definition what is quoted below is sufficient. Th. -----Original Message----- Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Sun, 05 Sep 2004 16:57:22 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Messages to ports with only one connector I'm with Jim R. We can easily drop isActive. The classifier behavior will remain. But I'll comment on this: ... The defining features [of active object] are: (a) the object executes a behavior following creation which it keeps executing until it is terminated and (b) while executing this behavior, it decides when to do "receive" actions. It's a clear definition. ... I am pretty sure this is defined in the spec. (a) yes, at 13.3.9 in UML2-Super.book.040829. (Notice that this suggests that (the class of) an active object has a classifier behavior, and so does 13.3.6, but neither requires that it does have one; nor do (a) and (b) require that an active object have a classifier behavior, and classifierBehavior is explicit that it need not have one. [13.3.5]) (b) No. Or maybe what is intended to be equivalent, but is not said as precisely: "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." [13.3.9] But: Does not any object decide when to do "receive" actions? (That is, the code (or implemented action language specification) of that object decides.) If so, then the definition would be much better without (b). Certainly, we are told: "When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved for later triggered effect." [13.3.5] This applies to all behaviored classifiers, even those without a classifier behavior, and even those without isActive true. ....... And then we have, also at 13.3.9, this: "A class may be designated as active, i.e., each of its instance having its own thread of control, or passive, i.e., each of its instance executing within the context of some other object" which may be silly and needless or extremely difficult to define without getting technology specific. Cordially, Joaquin To: Joaquin Miller Cc: UML Superstructure FTF Subject: RE: Messages to ports with only one connector X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Mon, 6 Sep 2004 17:10:12 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/06/2004 17:10:17, Serialize complete at 09/06/2004 17:10:17 > (a) yes, at 13.3.9 in UML2-Super.book.040829. > (Notice that this suggests that (the class of) an active object has > a classifier behavior, and so does 13.3.6, but neither requires that > it does have one; nor do (a) and (b) require that an active object > have a classifier behavior, and classifierBehavior is explicit that > it need not have one. [13.3.5]) Good point, these can be added. > (b) No. > Or maybe what is intended to be equivalent, but is not said as > precisely: "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." [13.3.9] > > But: Does not any object decide when to do "receive" actions? (That > is, the code (or implemented action language specification) of that > object decides.) If so, then the definition would be much better without (b). No, a passive object cannot execute a receive action since it has no event pool -- this would not be a well-formed model. Again, we could add some more constraints to clarify that. Removal of (b) would effectively make the current definition meaningless. > Certainly, we are told: "When an event occurrence is recognized by > an object that is an instance of a behaviored classifier, it may > have an immediate effect or the occurrence may be saved for later > triggered effect." [13.3.5] This applies to all behaviored > classifiers, even those without a classifier behavior, and even > those without isActive true. This needs some clarification. > ....... > > And then we have, also at 13.3.9, this: "A class may be designated > as active, i.e., each of its instance having its own thread of > control, or passive, i.e., each of its instance executing within the > context of some other object" which may be silly and needless or > extremely difficult to define without getting technology specific. Personally, I would eliminate all references to "thread of control", because this concept is even harder to define (and is not undefined anywhere) and because most people immediately and incorrectly assume that it means "process"). However, it was put in there to placate the ones who wanted that term -- such as the majority of folks here, who are so hung up on it. Joaquin has pointed out ways in which the spec can be tightened up and this is useful. However, as far as I can tell, there is nothing incorrect or problematic with what is there. Cheers...Bran > > Cordially, Joaquin Reply-To: Joaquin Miller X-Sender: jm-omg@sbcglobal.net@pop.sbcglobal.yahoo.com X-Mailer: QUALCOMM Windows Eudora Version 5.1 Date: Tue, 07 Sep 2004 08:49:46 -0700 To: UML Superstructure FTF From: Joaquin Miller Subject: RE: Messages to ports with only one connector > But: Does not any object decide when to do "receive" actions? (That is, the code (or implemented action language specification) of that object decides.) If so, then the definition would be much better without (b). No, a passive object cannot execute a receive action Since 'receive action' is not a UML 2 specified action, i'm inclined to take your word for that, but i'd like a better reason... since it has no event pool -- this would not be a well-formed model. ... nothing in the spec says that only active objects have a event pool. (Or i'm wrong about that. (That is, wrong about what the spec says: it's all i have to go on, and all some other folks will have.)) Cordially, Joaquin ------------------- Appendix ------------------------ "When an event occurrence is recognized by an object, it may have an immediate effect or the event may be saved in an event pool" "When an event occurrence is recognized by an object that is an instance of a behaviored classifier, it may have an immediate effect or the occurrence may be saved" "The object which is the context of the behavior manages the input pool holding the event occurrences to which a behavior may respond" "The event pool for the state machine is the event pool of the instance according to the behaviored context classifier, or the classifier owning the behavioral feature for which the state machine is a method." And once an object accepts an event, it is in full control of what happens after that.