Issue 7650: Bidirectional messages to a port object (uml2-superstructure-ftf) Source: NIST (Mr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Uncategorized Issue Severity: Summary: How do required and provided interfaces on a port support messages from both inside and outside the composite? Messages to a port object sent from the inside of the containing composite must be declared in the required interface of the port object, but usually messages sent to an object must also be declared in the provided interfaces. Is there a special case for ports? Didn't see anything in the spec explaining this. Resolution: Revised Text: Actions taken: August 31, 2004: received issue Discussion: End of Annotations:===== eply-To: From: "Conrad Bock" To: "uml2ftf" Subject: Bidirectional messages to a port object Date: Tue, 31 Aug 2004 10:42:48 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Composers, Porters, et al, How do required and provided interfaces on a port support messages from both inside and outside the composite? Messages to a port object sent from the inside of the containing composite must be declared in the required interface of the port object, but usually messages sent to an object must also be declared in the provided interfaces. Is there a special case for ports? Didn't see anything in the spec explaining this. Conrad To: Cc: "uml2ftf" Subject: Re: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 11:29:28 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 11:29:31, Serialize complete at 08/31/2004 11:29:31 Conrad, As usual, you are reading more into this stuff than was intended -- although that often provides useful insight. >From your question, you seem to be viewing a port class as a regular user-defined class. It's not -- or, to be precise, it was never intended to be. First of all, note that a port does not necessarily have to be an object at all, since for some formalisms (such as SDL) it is merely an "interaction point" equivalent to some kind of selector id. In those cases, there is no type associated with the port. Alternatively, if the port is an object, the behavior of this class is fully determined by the constraints imposed on that port by (a) UML semantics and (b) the specifics of how the port is used. These include the interfaces that it must support, how it transfers messages back and forth, etc. It was never intended for modelers to specify the behavior or the structure of a port class since they are derived -- although the possibility is not excluded (probably an overgeneralization). Again, it may be that these special semantics are not very well stated in the spec. Cheers...Bran "Conrad Bock" 08/31/2004 10:42 AM Please respond to conrad.bock To "uml2ftf" cc Subject Bidirectional messages to a port object Composers, Porters, et al, How do required and provided interfaces on a port support messages from both inside and outside the composite? Messages to a port object sent from the inside of the containing composite must be declared in the required interface of the port object, but usually messages sent to an object must also be declared in the provided interfaces. Is there a special case for ports? Didn't see anything in the spec explaining this. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Tue, 31 Aug 2004 12:25:33 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, Eran, Thanks for the clarifications. Replies below. I think if there are special cases for the use of interfaces at ports, they should be stated in the spec. Conrad > [Eran] I am not sure I understood your last comment "if there is no > port object". The port object is a runtime thing which conceptually > is always there. > [Bran] The first statement that you cite does sound wrong if you read > it literally. But, it comes from the view that a port, being an > integral part of its owning class, is not really differentiated from > the class. Ports do not make sense on their own, really. > From your question, you seem to be viewing a port class as a regular > user-defined class. It's not -- or, to be precise, it was never > intended to be. > First of all, note that a port does not necessarily have to be an > object at all, since for some formalisms (such as SDL) it is merely > an "interaction point" equivalent to some kind of selector id. In > those cases, there is no type associated with the port. I understand a port may be sort of ephemeral, and this is supported by allowing the multiplicity to have a lower bound of zero, but there is quite a bit of text that describes them in explicit object terms: When an instance of a classifier is created, instances corresponding to each of its ports are created and held in the slots specified by the ports, in accordancy with its multiplicity. ... A link from that instance to the instance of the owning classifier is created through which communication is forwarded to the instance of the owning classifier or through which the owning classifier communicates with its environment. The interaction point object must be an instance of a classifier that realizes the provided interfaces of the port. If the port was typed by an interface, the classifier typing the interaction point object realizes that interface. If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port. > Alternatively, if the port is an object, the behavior of this class > is fully determined by the constraints imposed on that port by (a) > UML semantics and (b) the specifics of how the port is used. These > include the interfaces that it must support, how it transfers > messages back and forth, etc. I figured this would be the case, but then an outgoing message would need to be declared as both: - a provided interface on the port class, to accept mesages from inside the composite - a required interface on the port class, to declare to the environment that the class is expecting the environment to accept the message. The problem is also reflected in the following constraint: [1] The required interfaces of a port must be provided by elements to which the port is connected. which doesn't distinguish ports connected from the inside and outside. > It was never intended for modelers to specify the behavior or the > structure of a port class since they are derived -- although the > possibility is not excluded (probably an overgeneralization). Don't the required and provided interfaces of a port need to be declared with uses/realizes dependencies on the port class? The spec says this in the description of Port::required/provided: provided: Interface This association is derived from the interfaces realized by the type of the port or by the type of the port, if the port was typed by an interface. required: Interface This association is derived as the set of interfaces required by the type of the port or its supertypes. The above associations can't be derived from the interfaces on the owning classifier, since an interface may be provided on one port and required on another. To: Cc: "uml2ftf" Subject: RE: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 13:45:44 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 13:45:47, Serialize complete at 08/31/2004 13:45:47 > I understand a port may be sort of ephemeral, and this is supported by > allowing the multiplicity to have a lower bound of zero, but there is > quite a bit of text that describes them in explicit object terms: Indeed, the text occasionally shows a bias towards the object case that can be misleading. Those areas of text probably need to be reworked to also deal with the case of a non-object port.(I cannot speak for that side of things, someone from the SDL camp should.) > > Alternatively, if the port is an object, the behavior of this class > > is fully determined by the constraints imposed on that port by (a) > > UML semantics and (b) the specifics of how the port is used. These > > include the interfaces that it must support, how it transfers > > messages back and forth, etc. > > I figured this would be the case, but then an outgoing message would > need to be declared as both: > > - a provided interface on the port class, to accept mesages from inside > the composite > > - a required interface on the port class, to declare to the environment > that the class is expecting the environment to accept the message. The business of ports ahaving an "inside" and an "outside" has already been raised as an issue. Unfortunately, when the model of ports was decided, this very useful way of looking at ports (my opinion) was discarded. Instead, the notion of a "delegation" connectors was introduced. The idea was that the compatibility rules for delegation connectors would be different than for regular connectors. However, at some point, delegation connectors disappeared from the composites chapter (I don't know why), resulting in a few consistency problems such as the one you point out: > The problem is also reflected in the following constraint: > > [1] The required interfaces of a port must be provided by elements to > which the port is connected. > > which doesn't distinguish ports connected from the inside and outside. I believe that there is an issue raised against this constraint that has not been resolved. > > It was never intended for modelers to specify the behavior or the > > structure of a port class since they are derived -- although the > > possibility is not excluded (probably an overgeneralization). > > Don't the required and provided interfaces of a port need to be declared > with uses/realizes dependencies on the port class? Of course they have to be declared (you take me so literally sometimes). What I meant was that users never have to specify the implementation of a port class, just the things that constrain it (e.g., its required and provided interfaces, whether it is a behavior port or not, etc.). Cheers...Bran To: Cc: "uml2ftf" Subject: Re: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 31 Aug 2004 15:01:14 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/31/2004 13:01:17, Serialize complete at 08/31/2004 13:01:17 A behavior in a class can be invoked from anywhere, either inside the class or outside. An interface and/or port is only required if there is a desire to separate the specification or client view of a behavior from the class that implements it. "Conrad Bock" wrote on 08/31/2004 10:42:48 AM: > > Composers, Porters, et al, > > How do required and provided interfaces on a port support messages from > both inside and outside the composite? Messages to a port object sent > from the inside of the containing composite must be declared in the > required interface of the port object, but usually messages sent to an > object must also be declared in the provided interfaces. Is there a > special case for ports? Didn't see anything in the spec explaining > this. > > Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Tue, 31 Aug 2004 15:31:19 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > > I understand a port may be sort of ephemeral, and this is supported by > > allowing the multiplicity to have a lower bound of zero, but there is > > quite a bit of text that describes them in explicit object terms: > > Indeed, the text occasionally shows a bias towards the object > case that can be misleading. Those areas of text probably need > to be reworked to also deal with the case of a non-object > port.(I cannot speak for that side of things, someone from the > SDL camp should.) It's more than the text, because provided and required interfaces can only be distinguished by the dependencies to a class supporting them. So the port must be typed by class in most cases, rather than an interface, and these cases have different capabilities: The interaction point object must be an instance of a classifier that realizes the provided interfaces of the port. If the port was typed by an interface, the classifier typing the interaction point object realizes that interface. If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port. I guess implementations that don't have port objects can make a port class and interface, but have multiplicity lower of zero (too bad you can't set the upper to zero). Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Tue, 31 Aug 2004 16:15:57 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > The business of ports having an "inside" and an "outside" has > already been raised as an issue. Unfortunately, when the model > of ports was decided, this very useful way of looking at ports > (my opinion) was discarded. Instead, the notion of a > "delegation" connectors was introduced. The idea was that the > compatibility rules for delegation connectors would be different > than for regular connectors. However, at some point, delegation > connectors disappeared from the composites chapter (I don't know > why), resulting in a few consistency problems such as the one > you point out: It's in the component chapter, but doesn't address inside/outside views of ports, just ports as relays. BTW, I notice the ball and socket joining notation: -----o)----- is only defined in components, even though it would be handy generally. Do you remember why it isn't for generic composites? Conrad To: Cc: "uml2ftf" Subject: RE: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 16:18:24 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 16:18:27, Serialize complete at 08/31/2004 16:18:27 > It's more than the text, because provided and required interfaces can > only be distinguished by the dependencies to a class supporting them. It doesn't say that in the metamodel. All it says is that a port can have provided and required interfaces. It does not say that a port must be an object. A Port is a Property, which is a kind of StructuralFeature, which is a kind of TypedElement -- but note that typed elements may not necessarily have a Type! So, a port can be a property without a type. > So the port must be typed by class in most cases, This does not follow at all (see above). I don't understand what you mean by "most cases". How do you determine the numbers involved? > rather than an > interface, In fact, ports cannot be typed by an Interface because they cannot be instantiated. The "provided" interfaces of a port are not the types of the port. > and these cases have different capabilities: > > The interaction point object must be an instance of a classifier that > realizes the provided interfaces of the port. If the port was typed by > an interface, the classifier typing the interaction point object > realizes that interface. If the port was typed by a class, the > interaction point object will be an instance of that class. The latter > case allows elaborate specification of the communication over a > port. For example, it may describe that communication is filtered, > modified in some way, or routed to other parts depending on its > contents as specified by the classifier that types the port. Actually, the last two sentences were inserted on my insistence -- I guess it serves me right to get it thrown back at me. This was to make it easier to understand why ports should be objects (you may recall that in the original version, ports were not even kinds of Property). Most of that pertained to certain "meta-capabilities" such as asking a port to keep a log of messages it sends/receives. Of course, people are reading into it much more than was intended. No one can blame them. I guess you can blame me. > I guess implementations that don't have port objects can make a port > class and interface, but have multiplicity lower of zero (too bad you > can't set the upper to zero). i really don't understand what multiplicity has to do with it. can you clarify? Thanks...Bran To: Cc: "uml2ftf" Subject: RE: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Tue, 31 Aug 2004 16:42:34 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 08/31/2004 16:42:36, Serialize complete at 08/31/2004 16:42:36 > It's in the component chapter, but doesn't address inside/outside views > of ports, just ports as relays. It does address the issue. Something has to make up for the chirality (sidedness) of the inside-outside situation. You can do it either by recognizing that ports have two faces or by saying that the connectors on the inside and outside are different. > BTW, I notice the ball and socket joining notation: > > -----o)----- > > is only defined in components, even though it would be handy generally. > Do you remember why it isn't for generic composites? Start of flame: If you ask me, the ball and socket notation is a mistake because it can be highly misleading. The implication of a ball-and-socket combination is that it represents a connector. However, the problems with it are: (1) It only works for "pure" situations where one side does all the providing and the other all the requiring. However, in many real-world systems, the dependency works in both directions. If you show multiple such ball-and-socket combinations between two parts, you will not know whether this implies one or more connectors. (2) Even with just one ball-and-socket, you do not know if there are multiple connectors between the two ends. The problem is that connectors are instance-based things, representing individual links. The lollipop and the satellite dish, OTOH, represent classifier relationships (usage and implementation dependencies between classifiers). Using classifier relationships to represent instance-like things doesn't work as the above points indicate. My suggestion is to stay away from this notation, but everyone thinks that it is neat and it's everywhere now. That one is not my fault. End of flame Bran To: Cc: "uml2ftf" Subject: RE: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.2CF2 July 23, 2003 From: Jim Amsden Date: Tue, 31 Aug 2004 20:17:05 -0400 X-MIMETrack: Serialize by Router on D03NM119/03/M/IBM(Release 6.51HF338 | June 21, 2004) at 08/31/2004 18:17:09, Serialize complete at 08/31/2004 18:17:09 Ports can be typed by interfaces in collaborations and/or <> components. This provides part of the contract between clients and implementors. A collaboration use in an implementing classifier or <> component must provide a class for the port that provides and requires the same interfaces, and provides behaviors for any specification operations of provided interfaces. Such behaviors could be implemented by delegating through a connector to other parts of the implementing classifier, but there are no specific metamodel constructs for this pattern. "Conrad Bock" 08/31/2004 03:31 PM Please respond to conrad.bock To "uml2ftf" cc Subject RE: Bidirectional messages to a port object Bran, > > I understand a port may be sort of ephemeral, and this is supported by > > allowing the multiplicity to have a lower bound of zero, but there is > > quite a bit of text that describes them in explicit object terms: > > Indeed, the text occasionally shows a bias towards the object > case that can be misleading. Those areas of text probably need > to be reworked to also deal with the case of a non-object > port.(I cannot speak for that side of things, someone from the > SDL camp should.) It's more than the text, because provided and required interfaces can only be distinguished by the dependencies to a class supporting them. So the port must be typed by class in most cases, rather than an interface, and these cases have different capabilities: The interaction point object must be an instance of a classifier that realizes the provided interfaces of the port. If the port was typed by an interface, the classifier typing the interaction point object realizes that interface. If the port was typed by a class, the interaction point object will be an instance of that class. The latter case allows elaborate specification of the communication over a port. For example, it may describe that communication is filtered, modified in some way, or routed to other parts depending on its contents as specified by the classifier that types the port. I guess implementations that don't have port objects can make a port class and interface, but have multiplicity lower of zero (too bad you can't set the upper to zero). Conrad Reply-To: From: "Desfray" To: "'Branislav Selic'" , Cc: "'uml2ftf'" Subject: RE: Bidirectional messages to a port object Date: Wed, 1 Sep 2004 10:21:48 +0200 X-Mailer: Microsoft Outlook CWS, Build 9.0.6604 (9.0.2911.0) X-Virus-Scanned: by amavisd-new at softeam.com >>> If you ask me, the ball and socket notation is a mistake because it can be highly misleading... I share the concerns about the ambiguous notation. Wouldn't it be worth to raise an issue on this aspect. I beleive that if we work on ambiguous examples, that problem can be solved by amending the notation(not discarding because it wouldn't be understood by the users). ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 31 août 2004 22:43 À : conrad.bock@nist.gov Cc : uml2ftf Objet : RE: Bidirectional messages to a port object > It's in the component chapter, but doesn't address inside/outside views > of ports, just ports as relays. It does address the issue. Something has to make up for the chirality (sidedness) of the inside-outside situation. You can do it either by recognizing that ports have two faces or by saying that the connectors on the inside and outside are different. > BTW, I notice the ball and socket joining notation: > > -----o)----- > > is only defined in components, even though it would be handy generally. > Do you remember why it isn't for generic composites? Start of flame: If you ask me, the ball and socket notation is a mistake because it can be highly misleading. The implication of a ball-and-socket combination is that it represents a connector. However, the problems with it are: (1) It only works for "pure" situations where one side does all the providing and the other all the requiring. However, in many real-world systems, the dependency works in both directions. If you show multiple such ball-and-socket combinations between two parts, you will not know whether this implies one or more connectors. (2) Even with just one ball-and-socket, you do not know if there are multiple connectors between the two ends. The problem is that connectors are instance-based things, representing individual links. The lollipop and the satellite dish, OTOH, represent classifier relationships (usage and implementation dependencies between classifiers). Using classifier relationships to represent instance-like things doesn't work as the above points indicate. My suggestion is to stay away from this notation, but everyone thinks that it is neat and it's everywhere now. That one is not my fault. End of flame Bran Date: Wed, 01 Sep 2004 21:01:14 +0200 From: Birger Møller-Pedersen User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 Netscape/7.1 (ax) X-Accept-Language: en-us, en To: Philippe.Desfray@softeam.fr CC: "'Branislav Selic'" , conrad.bock@nist.gov, "'uml2ftf'" Subject: Re: Bidirectional messages to a port object X-MailScanner-Information: This message has been scanned for viruses/spam. Contact postmaster@uio.no if you have questions about this scanning X-UiO-MailScanner: No virus found X-UiO-Spam-info: not spam, SpamAssassin (score=-3.881, required 12, HTML_20_30 0.47, HTML_FONTCOLOR_BLUE 0.10, HTML_MESSAGE 0.00, HTML_TITLE_EMPTY 0.54, UIO_MAIL_IS_INTERNAL -5.00) ... had it even been 'pin' and 'socket' - I have never seen any ball fitting into a socket. For some reason it was never even considered to use graphics that would obviously indicate the direction of signal/calls, like e.g. arrowheads pointing inwards/outwards or both ways. /birger Desfray wrote: >>> If you ask me, the ball and socket notation is a mistake because it can be highly misleading... I share the concerns about the ambiguous notation. Wouldn't it be worth to raise an issue on this aspect. I beleive that if we work on ambiguous examples, that problem can be solved by amending the notation(not discarding because it wouldn't be understood by the users). ==================================== Philippe Desfray VP for R&D - SOFTEAM Tel: (33) 01 53968400 Fax: (33) 01 53968401 144 Av. des champs Elysées 75008 PARIS www.softeam.com www.objecteering.com -----Message d'origine----- De : Branislav Selic [mailto:bselic@ca.ibm.com] Envoyé : mardi 31 août 2004 22:43 À : conrad.bock@nist.gov Cc : uml2ftf Objet : RE: Bidirectional messages to a port object > It's in the component chapter, but doesn't address inside/outside views > of ports, just ports as relays. It does address the issue. Something has to make up for the chirality (sidedness) of the inside-outside situation. You can do it either by recognizing that ports have two faces or by saying that the connectors on the inside and outside are different. > BTW, I notice the ball and socket joining notation: > > -----o)----- > > is only defined in components, even though it would be handy generally. > Do you remember why it isn't for generic composites? Start of flame: If you ask me, the ball and socket notation is a mistake because it can be highly misleading. The implication of a ball-and-socket combination is that it represents a connector. However, the problems with it are: (1) It only works for "pure" situations where one side does all the providing and the other all the requiring. However, in many real-world systems, the dependency works in both directions. If you show multiple such ball-and-socket combinations between two parts, you will not know whether this implies one or more connectors. (2) Even with just one ball-and-socket, you do not know if there are multiple connectors between the two ends. The problem is that connectors are instance-based things, representing individual links. The lollipop and the satellite dish, OTOH, represent classifier relationships (usage and implementation dependencies between classifiers). Using classifier relationships to represent instance-like things doesn't work as the above points indicate. My suggestion is to stay away from this notation, but everyone thinks that it is neat and it's everywhere now. That one is not my fault. End of flame Bran -- Birger Møller-Pedersen Department of Informatics, University of Oslo P.O. Box 1080 Blindern N-0316 Oslo, Norway Tel: +47 22 85 24 37 (office) Tel: +47 918 27 27 9 (mobile) http://folk.uio.no/birger Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Thu, 2 Sep 2004 10:26:24 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > > It's more than the text, because provided and required interfaces can > > only be distinguished by the dependencies to a class supporting them. > > It doesn't say that in the metamodel. All it says is that a port can > have provided and required interfaces. It does not say that a port > must be an object. A Port is a Property, which is a kind of > StructuralFeature, which is a kind of TypedElement -- but note that > typed elements may not necessarily have a Type! So, a port can be a > property without a type. The port must have a type, because the required/provided relations from Port to Interface are derived from the type of the port. As far as I can tell (please correct me), only the uses/realizes dependencies from the type of the port to interfaces distinguish provided from required. So even applications that do not instantiate the port type at runtime need to have a port type. > In fact, ports cannot be typed by an Interface because they cannot be > instantiated. The "provided" interfaces of a port are not the types > of the port. There doesn't need to be a port object at runtime, because messages can be sent to the owning object and refer to the port in the user model, using the InvocationAction extensions in composite structure (see Figure 101 of the 040829 PDF). > > [Conrad] and these cases have different capabilities: > > > > The interaction point object must be an instance of a classifier that > > realizes the provided interfaces of the port. If the port was typed by > > an interface, the classifier typing the interaction point object > > realizes that interface. If the port was typed by a class, the > > interaction point object will be an instance of that class. The latter > > case allows elaborate specification of the communication over a > > port. For example, it may describe that communication is filtered, > > modified in some way, or routed to other parts depending on its > > contents as specified by the classifier that types the port. > Actually, the last two sentences were inserted on my insistence > -- I guess it serves me right to get it thrown back at me. This > was to make it easier to understand why ports should be objects > (you may recall that in the original version, ports were not > even kinds of Property). Most of that pertained to certain > "meta-capabilities" such as asking a port to keep a log of > messages it sends/receives. Of course, people are reading into > it much more than was intended. No one can blame them. I guess > you can blame me. It's good you put those sentence in, because some applications might need the "heavyweight" capabilitie4s. But they don't need to use them, see below. > > I guess implementations that don't have port objects can make a port > > class and interface, but have multiplicity lower of zero (too bad you > > can't set the upper to zero). > > i really don't understand what multiplicity has to do with it. > can you clarify? The port property has multiplicities, and the lower bound can be zero. This supports "lightweight" implementations that hagve no port object at runtime, using the extended invocation actions. Conrad Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Thu, 2 Sep 2004 10:46:54 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > > It's in the component chapter, but doesn't address inside/outside views > > of ports, just ports as relays. > > It does address the issue. Something has to make up for the > chirality (sidedness) of the inside-outside situation. You can > do it either by recognizing that ports have two faces or by > saying that the connectors on the inside and outside are different. The component chapter doesn't directly chirality (nice word), at least, it doesn't explicitly mention that a port may receive messages from inside the owning object that are only declared on the required interfaces. This means the port object is "providing" the required interface to the internals of the owning object. The closest it gets is the constraints on Connector, as specialized. These are confusing, because they seem to assume, as you mentioned about ball/socket, that ports are unidirectional, using phrases like "provided ports", "required ports". In any case, even if the components chapter addressed chirality , it isn't in the composite chapter. > If you ask me, the ball and socket notation is a mistake because > it can be highly misleading. The implication of a > ball-and-socket combination is that it represents a connector. > However, the problems with it are: > > (1) It only works for "pure" situations where one side does all > the providing and the other all the requiring. However, in many > real-world systems, the dependency works in both directions. If > you show multiple such ball-and-socket combinations between two > parts, you will not know whether this implies one or more > connectors. > (2) Even with just one ball-and-socket, you do not know if there > are multiple connectors between the two ends. You can use more than one set of ball/socket between the same two parts. > The problem is that connectors are instance-based things, > representing individual links. The lollipop and the satellite > dish, OTOH, represent classifier relationships (usage and > implementation dependencies between classifiers). Using > classifier relationships to represent instance-like things > doesn't work as the above points indicate. I'd say the joined ball/socket map to multiple things in the metamodel. That might be more difficult for vendors to implement, but it seems natural from a user point of view. Justaposition is a valid graphical characteristic that can haave semantics intent. Conrad To: Cc: "uml2ftf" Subject: RE: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Thu, 2 Sep 2004 10:57:38 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/02/2004 10:57:41, Serialize complete at 09/02/2004 10:57:41 > The port must have a type, because the required/provided relations from > Port to Interface are derived from the type of the port. As far as I > can tell (please correct me), only the uses/realizes dependencies from > the type of the port to interfaces distinguish provided from required. > So even applications that do not instantiate the port type at runtime > need to have a port type. Good point, this may be an issue. Thomas will have to clarify, but my understanding was that the way to distinguish between a port that requires an object and one that does not is by the absence of the port type. Perhaps, the idea was that in the SDL variant (which does not require an object), the port does not result in a slot at run time? (This would make it different from other Properties and I'm not sure that's a good idea.) > > In fact, ports cannot be typed by an Interface because they cannot be > > instantiated. The "provided" interfaces of a port are not the types > > of the port. > > There doesn't need to be a port object at runtime, because messages can > be sent to the owning object and refer to the port in the user model, > using the InvocationAction extensions in composite structure (see Figure > 101 of the 040829 PDF). I understand that the port does not have to exist but does the slot? We need Thomas to explain his intent here. We may also need an issue to be raised -- if nothing else, one of clarity. Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Thu, 2 Sep 2004 11:20:28 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Bran, > > The port must have a type, because the required/provided relations from > > Port to Interface are derived from the type of the port. As far as I > > can tell (please correct me), only the uses/realizes dependencies from > > the type of the port to interfaces distinguish provided from required. > > So even applications that do not instantiate the port type at runtime > > need to have a port type. > > Good point, this may be an issue. Thomas will have to clarify, > but my understanding was that the way to distinguish between a > port that requires an object and one that does not is by the > absence of the port type. Perhaps, the idea was that in the SDL > variant (which does not require an object), the port does not > result in a slot at run time? (This would make it different from > other Properties and I'm not sure that's a good idea.) I thought the multiplicity of the port property would have zero lower bound, and I guess it requires OCL to constrain maximum number of port objects to zero, since UML won't support a zero upper bound. > > There doesn't need to be a port object at runtime, because messages can > > be sent to the owning object and refer to the port in the user model, > > using the InvocationAction extensions in composite structure > > (see Figure 101 of the 040829 PDF). > > I understand that the port does not have to exist but does the > slot? We need Thomas to explain his intent here. We may also > need an issue to be raised -- if nothing else, one of clarity. Slots are only in the instance model. There is no requirement to have "runtime slots", a model compiler does not need to generate them if the properties will never have values at runtime anyway. Conrad From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Thu, 2 Sep 2004 23:08:33 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Some corrections to below... 1. The type of the port is essential in telling us what the provided interfaces are, as these are either (i) the interfaces realized by the type of the port (if the port was typed by a class or similar) or (ii) the type of the port (if the port was typed by an interface). Note that the type of the port does NOT specify the classifier that will instantiate the port. The port semantics is described in terms of such object, but a real implementation need only behave this way, not be exactly that way. Typically there would not be such object. 2. Ports can be typed by interfaces, which means that this interface is the provided interface of the port. 3. The multiplicity of a port does not tell us anything about a port object. It tells us how many interaction points a classifier has. Please forget about this port object this thread is talking about. When you interact with a classifier through a port, you will never know whether the implementation realizes the interaction point using a port object or not. The type of the port is telling us what the port does during that interaction (e.g., manipulate the communicated data in some way when passing it along, filter the data, or route it in a particular way). However, we do not address the port object (if there is one) or interact with it in any particular way. We do not have any identity of that port object, if there is one. Note that the port gives us a reference to the owning classifier which is unique to this interaction point. But we reference the owning classifier not a "port object". Again, the semantics of port is written in terms of an object mediating the interaction of the port. However, the system only needs to behave as specified. You will never know whether there is such an object or not. Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, September 02, 2004 9:26 AM > To: uml2ftf > Subject: RE: Bidirectional messages to a port object > > > Bran, > > > > It's more than the text, because provided and required interfaces can > > > only be distinguished by the dependencies to a class supporting them. > > > > It doesn't say that in the metamodel. All it says is that a port can > > have provided and required interfaces. It does not say that a port > > must be an object. A Port is a Property, which is a kind of > > StructuralFeature, which is a kind of TypedElement -- but note that > > typed elements may not necessarily have a Type! So, a port can be a > > property without a type. > > The port must have a type, because the required/provided relations from > Port to Interface are derived from the type of the port. As far as I > can tell (please correct me), only the uses/realizes dependencies from > the type of the port to interfaces distinguish provided from required. > So even applications that do not instantiate the port type at runtime > need to have a port type. > > > In fact, ports cannot be typed by an Interface because they cannot be > > instantiated. The "provided" interfaces of a port are not the types > > of the port. > > There doesn't need to be a port object at runtime, because messages can > be sent to the owning object and refer to the port in the user model, > using the InvocationAction extensions in composite structure (see Figure > 101 of the 040829 PDF). > > > > > [Conrad] and these cases have different capabilities: > > > > > > The interaction point object must be an instance of a > classifier that > > > realizes the provided interfaces of the port. If the port was typed > by > > > an interface, the classifier typing the interaction point object > > > realizes that interface. If the port was typed by a class, the > > > interaction point object will be an instance of that class. The > latter > > > case allows elaborate specification of the communication over a > > > port. For example, it may describe that communication is filtered, > > > modified in some way, or routed to other parts depending on its > > > contents as specified by the classifier that types the port. > > > Actually, the last two sentences were inserted on my insistence > > -- I guess it serves me right to get it thrown back at me. This > > was to make it easier to understand why ports should be objects > > (you may recall that in the original version, ports were not > > even kinds of Property). Most of that pertained to certain > > "meta-capabilities" such as asking a port to keep a log of > > messages it sends/receives. Of course, people are reading into > > it much more than was intended. No one can blame them. I guess > > you can blame me. > > It's good you put those sentence in, because some applications might > need the "heavyweight" capabilitie4s. But they don't need to use them, > see below. > > > > I guess implementations that don't have port objects can make a port > > > class and interface, but have multiplicity lower of zero (too bad you > > > can't set the upper to zero). > > > > i really don't understand what multiplicity has to do with it. > > can you clarify? > > The port property has multiplicities, and the lower bound can be zero. > This supports "lightweight" implementations that hagve no port object at > runtime, using the extended invocation actions. > > Conrad > From: "Thomas Weigert" To: , "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Thu, 2 Sep 2004 23:25:56 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) Boy, I have not heard that term since chemistry class.... brings back bad memories... Anyway, I would have loved to use the notion of "sidedness" or chirality to explain ports, but unfortunately, the components chapter got into the way. All the good concepts were wasted there (such as delegation), so the wording in the internal structure chapter is sometimes clunky. One thing you need to be careful about when thinking about connectors. Anything we say about provided or required interfaces is always from the view of the outside of an object. There is nothing that is provided or required to the inside of the object by a port. You will further find that I was forced to remove just about any constraint there is regarding drawing of connectors as there are already widely different implementations. So all the constraints are pushed in a semantic variation point that defines what it means for two connectable elements to be "compatible". Note that it is really easy to come up with constraints when speaking about connected elements at the "same level", or what components call "assembly connectors". There is much disagreement on what the constraints are on delegation or the reverse. If you do want to define constraints on the delegation case, you need to ask yourself what you are trying to achieve. Most people use ports to establish the API of a classifier, so that you can implement its inside with complete disregard for the environment the resultant object might be embedded. As long as the environment follows the API, the object will work as advertised. So what rules do you need to ensure such? (i) on delegation, is it necessary that the part be able to handle the communication? (ii) in the reverse direction, is it necessary that the part only send communication specified in the required interface of the owning classifier? Different profiles differ in how they answer these questions. Compatibility rules in the case of delegation typically come in the form of relationships between the provided and required interfaces at the port of the classifier and the provided and required interfaces at its part (or the part on this part). Th. > -----Original Message----- > From: Conrad Bock [mailto:conrad.bock@nist.gov] > Sent: Thursday, September 02, 2004 9:47 AM > To: uml2ftf > Subject: RE: Bidirectional messages to a port object > > > Bran, > > > > It's in the component chapter, but doesn't address > inside/outside views > > > of ports, just ports as relays. > > > > It does address the issue. Something has to make up for the > > chirality (sidedness) of the inside-outside situation. You can > > do it either by recognizing that ports have two faces or by > > saying that the connectors on the inside and outside are different. > > The component chapter doesn't directly chirality (nice word), at least, > it doesn't explicitly mention that a port may receive messages from > inside the owning object that are only declared on the required > interfaces. This means the port object is "providing" the required > interface to the internals of the owning object. The closest it gets is > the constraints on Connector, as specialized. These are confusing, > because they seem to assume, as you mentioned about ball/socket, that > ports are unidirectional, using phrases like "provided ports", "required > ports". > > In any case, even if the components chapter addressed chirality , it > isn't in the composite chapter. > > > If you ask me, the ball and socket notation is a mistake because > > it can be highly misleading. The implication of a > > ball-and-socket combination is that it represents a connector. > > However, the problems with it are: > > > > (1) It only works for "pure" situations where one side does all > > the providing and the other all the requiring. However, in many > > real-world systems, the dependency works in both directions. If > > you show multiple such ball-and-socket combinations between two > > parts, you will not know whether this implies one or more > > connectors. > > > (2) Even with just one ball-and-socket, you do not know if there > > are multiple connectors between the two ends. > > You can use more than one set of ball/socket between the same two > parts. > > > The problem is that connectors are instance-based things, > > representing individual links. The lollipop and the satellite > > dish, OTOH, represent classifier relationships (usage and > > implementation dependencies between classifiers). Using > > classifier relationships to represent instance-like things > > doesn't work as the above points indicate. > > I'd say the joined ball/socket map to multiple things in the metamodel. > That might be more difficult for vendors to implement, but it seems > natural from a user point of view. Justaposition is a valid graphical > characteristic that can haave semantics intent. > > Conrad > From: "Thomas Weigert" To: "Branislav Selic" , Cc: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Thu, 2 Sep 2004 23:28:21 -0500 X-Mailer: Microsoft Outlook IMO, Build 9.0.6604 (9.0.2911.0) As I explained earlier, a port typically would have a type. However, this implies nothing about whether there will be a run-time object in an implementation or not, as you cannot interact directly with the port object, if there is one. The semantics of port is given in terms of a port object that is always created, but that has no bearing on whether an implementation will actually do so. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Thursday, September 02, 2004 9:58 AM To: conrad.bock@nist.gov Cc: uml2ftf Subject: RE: Bidirectional messages to a port object > The port must have a type, because the required/provided relations from > Port to Interface are derived from the type of the port. As far as I > can tell (please correct me), only the uses/realizes dependencies from > the type of the port to interfaces distinguish provided from required. > So even applications that do not instantiate the port type at runtime > need to have a port type. Good point, this may be an issue. Thomas will have to clarify, but my understanding was that the way to distinguish between a port that requires an object and one that does not is by the absence of the port type. Perhaps, the idea was that in the SDL variant (which does not require an object), the port does not result in a slot at run time? (This would make it different from other Properties and I'm not sure that's a good idea.) > > In fact, ports cannot be typed by an Interface because they cannot be > > instantiated. The "provided" interfaces of a port are not the types > > of the port. > > There doesn't need to be a port object at runtime, because messages can > be sent to the owning object and refer to the port in the user model, > using the InvocationAction extensions in composite structure (see Figure > 101 of the 040829 PDF). I understand that the port does not have to exist but does the slot? We need Thomas to explain his intent here. We may also need an issue to be raised -- if nothing else, one of clarity. Bran Reply-To: From: "Conrad Bock" To: "uml2ftf" Subject: RE: Bidirectional messages to a port object Date: Fri, 3 Sep 2004 11:55:43 -0400 X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) Thomas, > Note that the type of the port does NOT specify the classifier that > will instantiate the port. If type of the port is a concrete class, I can't see how the above can be true. A port is a property, and unless there is a special rule for ports, the port objects, which are values of the port property, are instances of the type. > 3. The multiplicity of a port does not tell us anything about a port > object. It tells us how many interaction points a classifier has. Presumably you meant how many port objects can be values of the port property at runtime, because the number of interaction points of the entire owning classifier can't be determined by the multiplicity of a single port. > Please forget about this port object this thread is talking > about. When you interact with a classifier through a port, you will > never know whether the implementation realizes the interaction point > using a port object or not. Only if you use the extension to invocation actions in the composite structure chapter. Otherwise, an invocation action can still send a message directly to the port object, if it exists. Presumably the effect is the same in either case, and the advantage of using the extended invocation action is that it insulates the user's action model from whether the port object exists or not. > The type of the port is telling us what the port does during that > interaction (e.g., manipulate the communicated data in some way when > passing it along, filter the data, or route it in a particular way). > However, we do not address the port object (if there is one) or > interact with it in any particular way. We do not have any identity > of that port object, if there is one. In your particular implementations and methodology. Ports are properties and can have addressable objects as values like any other. These are the "heavyweight" implementations where the port keep state, like counting the number of messages, and other functionality as described in the spec. > Note that the port gives us a reference to the owning classifier > which is unique to this interaction point. But we reference the > owning classifier not a "port object". The M levels are mixed up above. The reference from port to owning classifier is in the user model as an instance of the UML metamodel. The port object is a runtime value of the port as property and to navigate from that object to the owning object at runtime requires an association. To: Cc: "uml2ftf" Subject: RE: Bidirectional messages to a port object X-Mailer: Lotus Notes Release 6.0.1CF1 March 04, 2003 From: Branislav Selic Date: Sun, 5 Sep 2004 15:22:00 -0400 X-MIMETrack: Serialize by Router on D25ML01/25/M/IBM(Release 6.0.2CF2|July 23, 2003) at 09/05/2004 15:22:06, Serialize complete at 09/05/2004 15:22:06 Conrad, When ports were defined, they were meant for a "particular implementation and methodology" (as you put it). Going beyond that may be a good thing to do, but it is very dangerous to do this without understanding the consequences. It seems to me that you have a different "implementation and method" in mind when you say that you can send directly to a port. I think that such interpretations and generalizations should be handeld by an RTF or, even better, by an RFP. This is not a question of better or worse, but before we go beyond original design intent, we should understand the consequences. Taking advantage of possible loopholes beyond original design intent is a well-known and dangerous practice in software. Regards, Bran "Conrad Bock" 09/03/2004 11:55 AM Please respond to conrad.bock To "uml2ftf" cc Subject RE: Bidirectional messages to a port object Thomas, > Note that the type of the port does NOT specify the classifier that > will instantiate the port. If type of the port is a concrete class, I can't see how the above can be true. A port is a property, and unless there is a special rule for ports, the port objects, which are values of the port property, are instances of the type. > 3. The multiplicity of a port does not tell us anything about a port > object. It tells us how many interaction points a classifier has. Presumably you meant how many port objects can be values of the port property at runtime, because the number of interaction points of the entire owning classifier can't be determined by the multiplicity of a single port. > Please forget about this port object this thread is talking > about. When you interact with a classifier through a port, you will > never know whether the implementation realizes the interaction point > using a port object or not. Only if you use the extension to invocation actions in the composite structure chapter. Otherwise, an invocation action can still send a message directly to the port object, if it exists. Presumably the effect is the same in either case, and the advantage of using the extended invocation action is that it insulates the user's action model from whether the port object exists or not. > The type of the port is telling us what the port does during that > interaction (e.g., manipulate the communicated data in some way when > passing it along, filter the data, or route it in a particular way). > However, we do not address the port object (if there is one) or > interact with it in any particular way. We do not have any identity > of that port object, if there is one. In your particular implementations and methodology. Ports are properties and can have addressable objects as values like any other. These are the "heavyweight" implementations where the port keep state, like counting the number of messages, and other functionality as described in the spec. > Note that the port gives us a reference to the owning classifier > which is unique to this interaction point. But we reference the > owning classifier not a "port object". The M levels are mixed up above. The reference from port to owning classifier is in the user model as an instance of the UML metamodel. The port object is a runtime value of the port as property and to navigate from that object to the owning object at runtime requires an association. Conrad From: "Thomas Weigert" To: "'Branislav Selic'" , Cc: "'uml2ftf'" Subject: RE: Bidirectional messages to a port object Date: Sun, 5 Sep 2004 16:55:13 -0500 X-Mailer: Microsoft Outlook, Build 10.0.2627 I agree with Bran. The design of ports and internal structures is based on real tool experience of over 10 years, in at least three tools and widely used methodologies. It is also vetted against many years of academic experience in architectural modeling. Any changes to the original design should be based on practical experience, supported by issues arriving in building tools. Regarding "sending to ports".... The design of the spec does not provide for sending to ports (that was the intention behind the original idea of not having ports be subclasses of properties). Instead, the semantics of ports clearly states that the ports provide an alternative address for the owning classifier. It explains this by presenting a semantics of port objects, but does not require (or suggests) such implementation. Th. -----Original Message----- From: Branislav Selic [mailto:bselic@ca.ibm.com] Sent: Sunday, September 05, 2004 2:22 PM To: conrad.bock@nist.gov Cc: uml2ftf Subject: RE: Bidirectional messages to a port object Conrad, When ports were defined, they were meant for a "particular implementation and methodology" (as you put it). Going beyond that may be a good thing to do, but it is very dangerous to do this without understanding the consequences. It seems to me that you have a different "implementation and method" in mind when you say that you can send directly to a port. I think that such interpretations and generalizations should be handeld by an RTF or, even better, by an RFP. This is not a question of better or worse, but before we go beyond original design intent, we should understand the consequences. Taking advantage of possible loopholes beyond original design intent is a well-known and dangerous practice in software. Regards, Bran "Conrad Bock" 09/03/2004 11:55 AM Please respond to conrad.bock To "uml2ftf" cc Subject RE: Bidirectional messages to a port object Thomas, > Note that the type of the port does NOT specify the classifier that > will instantiate the port. If type of the port is a concrete class, I can't see how the above can be true. A port is a property, and unless there is a special rule for ports, the port objects, which are values of the port property, are instances of the type. > 3. The multiplicity of a port does not tell us anything about a port > object. It tells us how many interaction points a classifier has. Presumably you meant how many port objects can be values of the port property at runtime, because the number of interaction points of the entire owning classifier can't be determined by the multiplicity of a single port. > Please forget about this port object this thread is talking > about. When you interact with a classifier through a port, you will > never know whether the implementation realizes the interaction point > using a port object or not. Only if you use the extension to invocation actions in the composite structure chapter. Otherwise, an invocation action can still send a message directly to the port object, if it exists. Presumably the effect is the same in either case, and the advantage of using the extended invocation action is that it insulates the user's action model from whether the port object exists or not. > The type of the port is telling us what the port does during that > interaction (e.g., manipulate the communicated data in some way when > passing it along, filter the data, or route it in a particular way). > However, we do not address the port object (if there is one) or > interact with it in any particular way. We do not have any identity > of that port object, if there is one. In your particular implementations and methodology. Ports are properties and can have addressable objects as values like any other. These are the "heavyweight" implementations where the port keep state, like counting the number of messages, and other functionality as described in the spec. > Note that the port gives us a reference to the owning classifier > which is unique to this interaction point. But we reference the > owning classifier not a "port object". The M levels are mixed up above. The reference from port to owning classifier is in the user model as an instance of the UML metamodel. The port object is a runtime value of the port as property and to navigate from that object to the owning object at runtime requires an association. Conrad Conrad