Issue 15290: Ports (uml2-rtf) Source: Airbus Group (Mr. Yves Bernard, yves.bernard(at)airbus.com) Nature: Clarification Severity: Summary: We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? Resolution: Revised Text: Actions taken: June 15, 2010: received issue Discussion: End of Annotations:===== m: "BERNARD, Yves" To: "uml2-rtf@omg.org" CC: "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Date: Tue, 15 Jun 2010 13:00:16 +0200 Subject: About Ports Thread-Topic: About Ports Thread-Index: AcsMee+mTw7FsQSCSVar/ZP/9+rVGg== Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-OriginalArrivalTime: 15 Jun 2010 11:00:18.0348 (UTC) FILETIME=[F0F6E6C0:01CB0C79] Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. To: "BERNARD, Yves" Cc: Burkhart Roger M , Chris Paredis , "Bock, Conrad" , Eldad Palachi , Fredrick A Steiner , "Sawyer, George A (US SSA)" , "Watson, John" , Nerijus Jankevicius , "Nicolas F Rouquette (316A)" , Axel Reichwein , Robert Karban , "Friedenthal, Sanford" , "uml2-rtf@omg.org" Subject: Re: About Ports X-KeepSent: C2ED83DB:B80ECD3B-85257743:003DB278; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Tue, 15 Jun 2010 07:42:18 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 06/15/2010 05:42:20, Serialize complete at 06/15/2010 05:42:20 Yves, Comments embedded below. SoaML had to deal with many of these same issues. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "BERNARD, Yves" To: "uml2-rtf@omg.org" Cc: "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Date: 06/15/2010 07:05 AM Subject: About Ports -------------------------------------------------------------------------------- Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? SoaML took the position that a port defines the interaction point between the internals of the owning class, and the rest of the environment. As such, its features were used to define that interaction, and nothing else. That is, the behaviors of a port defined the valid interaction protocols that were permissible through that port. These protocols defined the valid order of operation invocations or message exchange patterns between the owning part and any other part connected through that port. Any behavior can be used including interactions, activities, state machines, protocol state machines or opaque behaviors. structural features of the port's type can be used to represent the roles played by the interacting parties. There have been suggestions that ports could also play other roles including message transformation, communication control and logging, or even reusable implementations of some operations. However, this creates confusion between the port and its owning classifier and commingles behaviors that specify protocols with other kinds of behaviors resulting in confusion about the role of a port. Some feel it is better to separate these concerns and use delegation to internal parts or the adapter and mediator patterns to implement active behaviors, and use ports only to define interactions. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? The interaction point semantics are somewhat under-specified. For example, it is possible, and in fact common, to use an Interface to type a Port. But a part typed by an interface cannot be instantiated. So it is not actually possible to create the interaction point without defining a class that realizes the interface, and using that to type the port (since there's no way to specify a compatible type for the interaction point). Such an interaction point wouldn't generally be needed if a delegation connector is used either. This is in need of work, and something we planned to address in the UML 2.5 specification simplification submission. It is possible that the interaction point is simply a virtual instance used to describe the semantics, and different PSM mappings may or may not actually create an interaction point. But if the port is only used to define a protocol, then the interaction point would only be involved in verification that the interactions that occur through the port adhere to the protocol specification. Whether this is done at all, or how it is accomplished would be up to a PSM mapping. How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? In SoaML, they define what the valid interactions are. UML2 provides other mechanisms for defining these interactions that are not used by SoaML. A Port can be typed by an Interface that has a ProtocolStateMachine. This is inadequate though because it only defines one side of the interaction, not a conversation between the parties, or even simple callback functions. A Connector can have a contract which can be used to define the valid interactions that can occur across the connector. However, this puts the protocol on the connector, not the ports which doesn't make sense. It would mean that a classes representing consumers and providers of the capabilities exposed through the port cannot express the rules for using or implementing those capabilities. That has to be defined by the contract for the connector. Different connectors could have different contracts which could be incompatible with the expected protocols at the ports. Also, there is no connection between the parts of the Behavior used to define the contract, and the connector ends in order to formally define the interactions. This probably also needs work. One possible use of the Connector contract would be to instantiate a particular interaction between parts. That is, the protocols defined by the ports may support some variability that can be instantiated by a particular contract that is compatible with the protocol defined by the ports. For example, the ports could specify a range of permissible nonfunctional characteristics such as payment for the service while the connector contract could specify a specific negotiated prices within the payment range for a particular use of the service. Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. Subject: RE : About Ports Date: Tue, 15 Jun 2010 17:11:35 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About Ports Thread-Index: AcsMee+mTw7FsQSCSVar/ZP/9+rVGgAIhAvk From: "CUCCURU Arnaud" To: "BERNARD, Yves" , Cc: "Bock, Conrad" , "Burkhart Roger M" , "Friedenthal, Sanford" , "Nerijus Jankevicius" , "Robert Karban" , "Eldad Palachi" , "Chris Paredis" , "Axel Reichwein" , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , "Fredrick A Steiner" , "Watson, John" , "GERARD Sebastien 166342" X-OriginalArrivalTime: 15 Jun 2010 15:11:36.0275 (UTC) FILETIME=[0C1BFA30:01CB0C9D] Hi Yves, all, Regarding your last question ("How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed?"), we have written a few ideas about that in the article in attachment. In the section 4 (Explicit port behaviors), we have tried to show how the typing mechanism of UML ports could be exploited to indirectly encapsulate behaviors inside ports. The behavior example here is for resolving a semantic variation point, but other use cases could also be considered. Cheers, Arnaud. -------- Message d'origine-------- De: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Date: mar. 15/06/2010 13:00 À uml2-rtf@omg.org Cc: Bock, Conrad; Burkhart Roger M; Friedenthal, Sanford; Nerijus Jankevicius; Robert Karban; Eldad Palachi; Chris Paredis; Axel Reichwein; Nicolas F Rouquette (316A); Sawyer, George A (US SSA); Fredrick A Steiner; Watson, John Objet : About Ports Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? Thanks, Yves The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. models2008_paperid_115.pdf DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=Iowkut+ukRjTHvuo3RvATTmbpZU1+3gIgMEhkvJV9fg=; b=un922lHZEQ+GWij+ibZnfffqeZRLtxuFue7FzA2MuwgQ2UvI5n4amRAzXsPlj0Vj1w P73roVG1q7B/FZ9dHmNOVK/L2ZvEDlJDCotBYPJc5/zs+b3ziPg1lGubjtERe3kskFZa cjjbJ3TuM/Q5qf3n2kfpLmZSvTUf/j8cGUwj0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=cCE4Y8CYn/jX2MxMXfkgun7z0aX4nXHZBgjxQ4R0yWBtEbcyk/bqmEs0SJuiSi3Cvw Qwyu8bUERDNj+RAx02ClNETRzLE0IEUgmc4O70Ty/iDw1IdxPtYR+hUkiq9IbYnWsVhy fsCPO7YskmnsFIqfda6m45Di7/t4hAmiDgvIM= Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 15 Jun 2010 12:50:46 -0400 X-Google-Sender-Auth: H7jLnrmvnTpBMhikQpnNq8EUeBU Subject: Re: About Ports To: "BERNARD, Yves" Cc: "uml2-rtf@omg.org" , "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Since I was involved in the definition of the port mechanism in UML, I will comment on those semantics rather than SysML port semantics. However, in principle, SysML should have inherited those semantics for standard ports. Comments embedded below: On Tue, Jun 15, 2010 at 7:00 AM, BERNARD, Yves wrote: Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? [bvs] Unfortunately, we did a poor job of explaining this in the spec (my fault in part, but my excuse was that I was not the primary author). The port concept in UML originated from two different sources and we decided to support both. Where we screwed up was that we did not clearly identify the two paradigms, which are mutually exclusive, so that people often use some type of unanticipated combination of the two. [bvs] In SDL (one of the paradigms supported), ports are not objects, but merely routing/interaction points. For this case, and for this case only, we allowed modelers the option of defining the type of the port to be the same as the type of the provided interface. Note that this is a very specific interpretation of the "type" concept. Note that, since, in this case ports are not objects, it is possible to type them with an interface, even though interfaces are not instantiable. [bvs] The other model of ports came from UML-RT, in which ports are actually run-time objects that can be manipulated by the behavior of the composite classifier (provided that they are behavior ports, of course). For that case, and for that case only, the type of the port was intended to be a special system-defined type, that realized the provided interface(s) of the port. For example, in UML-RT, one could send a message through a behavior port by invoking a special "send" operation of the port, or defer an incoming message by invoking a "defer" operation. For this reason, ports were allowed to have a behavior, but that behavior was system-defined and not (intended to be) under control of the modeler. [bvs] As I said, we did not clearly explain or delineate these two mutually exclusive use cases, so people naturally came up with mixed cases -- which has caused no end of confusion. Thus, some proposals allowed ports to include modeler-defined behavior, which, is not only unnecessary but also confusing (because it complicates the process of message handling, which, in those cases, becomes a distributed responsibility of the port and the behavior). If additional message processing is required, one simply needs to insert a part after the port that does the necessary function. Having two different mechanisms for handling messages (in ports AND behaviors) just adds complexity. Based on the KISS principle, ports should be treated just like the pins on a chip, passive things that simply relay information from one side to the other. However, the cat was out of the bag, and it seems that folks just cannot resist the idea of taking advantage of this "opportunity". I strongly advise against it. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? [bvs] See above comment. Cheers...Bran To: Bran Selic Cc: bran.selic@gmail.com, Burkhart Roger M , Chris Paredis , "Bock, Conrad" , Eldad Palachi , Fredrick A Steiner , "Sawyer, George A (US SSA)" , "Watson, John" , Nerijus Jankevicius , "Nicolas F Rouquette (316A)" , Axel Reichwein , Robert Karban , "Friedenthal, Sanford" , "uml2-rtf@omg.org" , "BERNARD, Yves" Subject: Re: About Ports X-KeepSent: 4371899B:CDE9E9F9-85257743:005E59C5; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Tue, 15 Jun 2010 13:14:35 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 06/15/2010 11:14:37, Serialize complete at 06/15/2010 11:14:37 Note that neither of the cases Bran mentions below cover how SoaML uses the ports, although the routing/interaction point is close. The difference is that SoaML supports the definition of complex interactions that involve both provided and required interfaces, and protocols that describe valid sequences of messages and operation calls. SoaML did this because UML Interface could not have behaviors or provide interfaces and was therefore insufficient for defining the service interaction. In SoaML, a ServiceInterface is a class, but it is not intended to be instantiated. Its really just an interface that supports provided and required interfaces, protocols and nested ports. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: "BERNARD, Yves" Cc: "uml2-rtf@omg.org" , "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Date: 06/15/2010 12:54 PM Subject: Re: About Ports Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- Since I was involved in the definition of the port mechanism in UML, I will comment on those semantics rather than SysML port semantics. However, in principle, SysML should have inherited those semantics for standard ports. Comments embedded below: On Tue, Jun 15, 2010 at 7:00 AM, BERNARD, Yves wrote: Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? [bvs] Unfortunately, we did a poor job of explaining this in the spec (my fault in part, but my excuse was that I was not the primary author). The port concept in UML originated from two different sources and we decided to support both. Where we screwed up was that we did not clearly identify the two paradigms, which are mutually exclusive, so that people often use some type of unanticipated combination of the two. [bvs] In SDL (one of the paradigms supported), ports are not objects, but merely routing/interaction points. For this case, and for this case only, we allowed modelers the option of defining the type of the port to be the same as the type of the provided interface. Note that this is a very specific interpretation of the "type" concept. Note that, since, in this case ports are not objects, it is possible to type them with an interface, even though interfaces are not instantiable. [bvs] The other model of ports came from UML-RT, in which ports are actually run-time objects that can be manipulated by the behavior of the composite classifier (provided that they are behavior ports, of course). For that case, and for that case only, the type of the port was intended to be a special system-defined type, that realized the provided interface(s) of the port. For example, in UML-RT, one could send a message through a behavior port by invoking a special "send" operation of the port, or defer an incoming message by invoking a "defer" operation. For this reason, ports were allowed to have a behavior, but that behavior was system-defined and not (intended to be) under control of the modeler. [bvs] As I said, we did not clearly explain or delineate these two mutually exclusive use cases, so people naturally came up with mixed cases -- which has caused no end of confusion. Thus, some proposals allowed ports to include modeler-defined behavior, which, is not only unnecessary but also confusing (because it complicates the process of message handling, which, in those cases, becomes a distributed responsibility of the port and the behavior). If additional message processing is required, one simply needs to insert a part after the port that does the necessary function. Having two different mechanisms for handling messages (in ports AND behaviors) just adds complexity. Based on the KISS principle, ports should be treated just like the pins on a chip, passive things that simply relay information from one side to the other. However, the cat was out of the bag, and it seems that folks just cannot resist the idea of taking advantage of this "opportunity". I strongly advise against it. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? [bvs] See above comment. Cheers...Bran Subject: RE: About Ports Date: Tue, 15 Jun 2010 13:26:12 -0400 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: About Ports thread-index: AcsMqzI9Jvzpg7K+Rc+y2lDSF1D36QAAs5vw From: "Cory Casanave" To: "Bran Selic" , "BERNARD, Yves" Cc: , "Bock, Conrad" , "Burkhart Roger M" , "Friedenthal, Sanford" , "Nerijus Jankevicius" , "Robert Karban" , "Eldad Palachi" , "Chris Paredis" , "Axel Reichwein" , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , "Fredrick A Steiner" , "Watson, John" Bran, I would like to suggest paradigm 3, which is probably your .unintended. one: That ports are interactive parts of a system. For example, when you say .talk to Joe in A/P about that. or .place your order on the web site. you are referring an external actor to an actor that is part of the composite system to handle that interaction. From an external point of view we don.t care how the .whole system. handles that interaction. But, it is frequently an independent actor in its own right that is handling that interaction on behalf of the whole. That behavior may be simple (routing) or complex. In some cases the behavior of that actor-part may be derived (creating your scenario 2) or fully delegated (scenario 3) but it may also have its own independently specified behavior for that interaction (scenario 3). So all of these scenarios are about the implementation, not the external contract. The delegation, where an interface of a port becomes an interface of the whole, is not, in my way of thinking, natural at all . in most cases the delegate would be an internal part and the whole would not have any interfaces at all . it seems like this idea of having the whole have all of the interfaces of the ports is one possible OO implementation but not really the design intent. Based on what the UML specification says all of these interpretations are reasonable, regardless of the original intent. The other .messy. part of ports as pure boundary objects without behavior is that they don.t differentiate an internal and external contract. To the inside of the object the interfaces provided/used should be the inverse of those on the outside. It is unfortunate that an otherwise understandable and useful concept has gotten so confused. -Cory -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Tuesday, June 15, 2010 12:51 PM To: BERNARD, Yves Cc: uml2-rtf@omg.org; Bock, Conrad; Burkhart Roger M; Friedenthal, Sanford; Nerijus Jankevicius; Robert Karban; Eldad Palachi; Chris Paredis; Axel Reichwein; Nicolas F Rouquette (316A); Sawyer, George A (US SSA); Fredrick A Steiner; Watson, John Subject: Re: About Ports Since I was involved in the definition of the port mechanism in UML, I will comment on those semantics rather than SysML port semantics. However, in principle, SysML should have inherited those semantics for standard ports. Comments embedded below: On Tue, Jun 15, 2010 at 7:00 AM, BERNARD, Yves wrote: Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? [bvs] Unfortunately, we did a poor job of explaining this in the spec (my fault in part, but my excuse was that I was not the primary author). The port concept in UML originated from two different sources and we decided to support both. Where we screwed up was that we did not clearly identify the two paradigms, which are mutually exclusive, so that people often use some type of unanticipated combination of the two. [bvs] In SDL (one of the paradigms supported), ports are not objects, but merely routing/interaction points. For this case, and for this case only, we allowed modelers the option of defining the type of the port to be the same as the type of the provided interface. Note that this is a very specific interpretation of the "type" concept. Note that, since, in this case ports are not objects, it is possible to type them with an interface, even though interfaces are not instantiable. [bvs] The other model of ports came from UML-RT, in which ports are actually run-time objects that can be manipulated by the behavior of the composite classifier (provided that they are behavior ports, of course). For that case, and for that case only, the type of the port was intended to be a special system-defined type, that realized the provided interface(s) of the port. For example, in UML-RT, one could send a message through a behavior port by invoking a special "send" operation of the port, or defer an incoming message by invoking a "defer" operation. For this reason, ports were allowed to have a behavior, but that behavior was system-defined and not (intended to be) under control of the modeler. [bvs] As I said, we did not clearly explain or delineate these two mutually exclusive use cases, so people naturally came up with mixed cases -- which has caused no end of confusion. Thus, some proposals allowed ports to include modeler-defined behavior, which, is not only unnecessary but also confusing (because it complicates the process of message handling, which, in those cases, becomes a distributed responsibility of the port and the behavior). If additional message processing is required, one simply needs to insert a part after the port that does the necessary function. Having two different mechanisms for handling messages (in ports AND behaviors) just adds complexity. Based on the KISS principle, ports should be treated just like the pins on a chip, passive things that simply relay information from one side to the other. However, the cat was out of the bag, and it seems that folks just cannot resist the idea of taking advantage of this "opportunity". I strongly advise against it. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? [bvs] See above comment. Cheers...Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=IBotrqFDOwlYH9OHfpVNFVy/XCKXjeWeqmJAANU+OJk=; b=Im8sKOo5Ha1RqckSTRPOPCdAstg8zG6/jbUwNCAUJaOhV6TaPQftpQkkJ7bu+YwogK geD3do9VYoKtiRom/1HKXXr02hBukXbmxiKkXb7Ehf4sqWtpUewdNSme/H+0km6r8sV8 c21fmM4BTfY2ATxFMCMFesfkzH8NAd94gXwiU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=DfAA5zFIdN/7p+dDfnOIs+/CZXl9vNB79s+yug0kjsV9BH5DYNr0+VLNDQ0e5wbJZV bwvsBDf/pZzXm5dui3okwO94bV2pjcwIaOz6PekOVROGa3wO82zu/y7vLzV2Iv877/aB e04jEmeon3muqHozds93wOSy2ZmOx0th5ydXc= Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 15 Jun 2010 16:22:01 -0400 X-Google-Sender-Auth: nAh3ZzCyyHufbycw8Wt0JbhIyFM Subject: Re: About Ports To: Cory Casanave Cc: "BERNARD, Yves" , uml2-rtf@omg.org, "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Cory, I really don't understand why you folks want to make things more complicated than they need to be. As I said, the simplest paradigm is to treat them like the pins of a chip. Anything more complicated can be handled by other means already provided in UML. If you want "interactive parts" then use parts -- that's what they are for. I don't like the idea of having two kinds of parts: "regular parts" and "port parts". Why have two different concepts that do the same thing? Let me use an analogy: There is a very good reason why we do not consider adding user-defined behaviors to the pins of UML actions or the parameters of UML activities -- it just complicates things. If you want some special handling, then simply create a composite activity that includes a nested action (or activity) that performs whatever special application-specific handling you need. My apologies, Cory, but I am unconvinced by your arguments here. Cheers, Bran On Tue, Jun 15, 2010 at 1:26 PM, Cory Casanave wrote: Bran, I would like to suggest paradigm 3, which is probably your .unintended. one: That ports are interactive parts of a system. For example, when you say .talk to Joe in A/P about that. or .place your order on the web site. you are referring an external actor to an actor that is part of the composite system to handle that interaction. From an external point of view we don.t care how the .whole system. handles that interaction. But, it is frequently an independent actor in its own right that is handling that interaction on behalf of the whole. That behavior may be simple (routing) or complex. In some cases the behavior of that actor-part may be derived (creating your scenario 2) or fully delegated (scenario 3) but it may also have its own independently specified behavior for that interaction (scenario 3). So all of these scenarios are about the implementation, not the external contract. The delegation, where an interface of a port becomes an interface of the whole, is not, in my way of thinking, natural at all . in most cases the delegate would be an internal part and the whole would not have any interfaces at all . it seems like this idea of having the whole have all of the interfaces of the ports is one possible OO implementation but not really the design intent. Based on what the UML specification says all of these interpretations are reasonable, regardless of the original intent. The other .messy. part of ports as pure boundary objects without behavior is that they don.t differentiate an internal and external contract. To the inside of the object the interfaces provided/used should be the inverse of those on the outside. It is unfortunate that an otherwise understandable and useful concept has gotten so confused. -Cory -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Tuesday, June 15, 2010 12:51 PM To: BERNARD, Yves Cc: uml2-rtf@omg.org; Bock, Conrad; Burkhart Roger M; Friedenthal, Sanford; Nerijus Jankevicius; Robert Karban; Eldad Palachi; Chris Paredis; Axel Reichwein; Nicolas F Rouquette (316A); Sawyer, George A (US SSA); Fredrick A Steiner; Watson, John Subject: Re: About Ports Since I was involved in the definition of the port mechanism in UML, I will comment on those semantics rather than SysML port semantics. However, in principle, SysML should have inherited those semantics for standard ports. Comments embedded below: On Tue, Jun 15, 2010 at 7:00 AM, BERNARD, Yves wrote: Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? [bvs] Unfortunately, we did a poor job of explaining this in the spec (my fault in part, but my excuse was that I was not the primary author). The port concept in UML originated from two different sources and we decided to support both. Where we screwed up was that we did not clearly identify the two paradigms, which are mutually exclusive, so that people often use some type of unanticipated combination of the two. [bvs] In SDL (one of the paradigms supported), ports are not objects, but merely routing/interaction points. For this case, and for this case only, we allowed modelers the option of defining the type of the port to be the same as the type of the provided interface. Note that this is a very specific interpretation of the "type" concept. Note that, since, in this case ports are not objects, it is possible to type them with an interface, even though interfaces are not instantiable. [bvs] The other model of ports came from UML-RT, in which ports are actually run-time objects that can be manipulated by the behavior of the composite classifier (provided that they are behavior ports, of course). For that case, and for that case only, the type of the port was intended to be a special system-defined type, that realized the provided interface(s) of the port. For example, in UML-RT, one could send a message through a behavior port by invoking a special "send" operation of the port, or defer an incoming message by invoking a "defer" operation. For this reason, ports were allowed to have a behavior, but that behavior was system-defined and not (intended to be) under control of the modeler. [bvs] As I said, we did not clearly explain or delineate these two mutually exclusive use cases, so people naturally came up with mixed cases -- which has caused no end of confusion. Thus, some proposals allowed ports to include modeler-defined behavior, which, is not only unnecessary but also confusing (because it complicates the process of message handling, which, in those cases, becomes a distributed responsibility of the port and the behavior). If additional message processing is required, one simply needs to insert a part after the port that does the necessary function. Having two different mechanisms for handling messages (in ports AND behaviors) just adds complexity. Based on the KISS principle, ports should be treated just like the pins on a chip, passive things that simply relay information from one side to the other. However, the cat was out of the bag, and it seems that folks just cannot resist the idea of taking advantage of this "opportunity". I strongly advise against it. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? [bvs] See above comment. Cheers...Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=+m3B67Xw1g4RL4wNP4xVy69GdJAjt++Jyu/rZ2CqM3Y=; b=xrETUp8VUTOn+jFIs9IY1HctYsWVdYSMefQYbuIsc+TPvG5Ch7ybh9xYNvTSbk5RxB 4nSPtHwSkRC129L5+A8gNJpD72t74u8qrUqfewZMYIBhVjMFeYxFsF8hLXJDfgurKrJ9 2FFsNGHrmcmKl/jb4Zcr2LoB4qqVanCjkpITM= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=p25HXY1LFTxwAvgeVBCx6+yda7ixUTOcHSk3XEHZeyD12c8SI8EVdwDV50gtWYb1nd t/VvVvWgvjU2Qbvntq4NuNGKpq91bJcHo9/oNQxx7fZzR/BnhyLet/FK4DKK/0eh0MDc SHZJ2UkuAVvq+mV12Spk2uZaxIRq02NzkU8NA= Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 15 Jun 2010 16:24:09 -0400 X-Google-Sender-Auth: sb-oI9guo8h3XbCyLWacHLk9zY8 Subject: Re: About Ports To: Jim Amsden Cc: Burkhart Roger M , Chris Paredis , "Bock, Conrad" , Eldad Palachi , Fredrick A Steiner , "Sawyer, George A (US SSA)" , "Watson, John" , Nerijus Jankevicius , "Nicolas F Rouquette (316A)" , Axel Reichwein , Robert Karban , "Friedenthal, Sanford" , "uml2-rtf@omg.org" , "BERNARD, Yves" Jim, I don't see that the SoA model is incompatible with either of the two port paradigms you mentioned. It seems orthogonal to me. Bran On Tue, Jun 15, 2010 at 1:14 PM, Jim Amsden wrote: Note that neither of the cases Bran mentions below cover how SoaML uses the ports, although the routing/interaction point is close. The difference is that SoaML supports the definition of complex interactions that involve both provided and required interfaces, and protocols that describe valid sequences of messages and operation calls. SoaML did this because UML Interface could not have behaviors or provide interfaces and was therefore insufficient for defining the service interaction. In SoaML, a ServiceInterface is a class, but it is not intended to be instantiated. Its really just an interface that supports provided and required interfaces, protocols and nested ports. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: Bran Selic To: "BERNARD, Yves" Cc: "uml2-rtf@omg.org" , "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Date: 06/15/2010 12:54 PM Subject: Re: About Ports Sent by: bran.selic@gmail.com -------------------------------------------------------------------------------- Since I was involved in the definition of the port mechanism in UML, I will comment on those semantics rather than SysML port semantics. However, in principle, SysML should have inherited those semantics for standard ports. Comments embedded below: On Tue, Jun 15, 2010 at 7:00 AM, BERNARD, Yves wrote: Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? [bvs] Unfortunately, we did a poor job of explaining this in the spec (my fault in part, but my excuse was that I was not the primary author). The port concept in UML originated from two different sources and we decided to support both. Where we screwed up was that we did not clearly identify the two paradigms, which are mutually exclusive, so that people often use some type of unanticipated combination of the two. [bvs] In SDL (one of the paradigms supported), ports are not objects, but merely routing/interaction points. For this case, and for this case only, we allowed modelers the option of defining the type of the port to be the same as the type of the provided interface. Note that this is a very specific interpretation of the "type" concept. Note that, since, in this case ports are not objects, it is possible to type them with an interface, even though interfaces are not instantiable. [bvs] The other model of ports came from UML-RT, in which ports are actually run-time objects that can be manipulated by the behavior of the composite classifier (provided that they are behavior ports, of course). For that case, and for that case only, the type of the port was intended to be a special system-defined type, that realized the provided interface(s) of the port. For example, in UML-RT, one could send a message through a behavior port by invoking a special "send" operation of the port, or defer an incoming message by invoking a "defer" operation. For this reason, ports were allowed to have a behavior, but that behavior was system-defined and not (intended to be) under control of the modeler. [bvs] As I said, we did not clearly explain or delineate these two mutually exclusive use cases, so people naturally came up with mixed cases -- which has caused no end of confusion. Thus, some proposals allowed ports to include modeler-defined behavior, which, is not only unnecessary but also confusing (because it complicates the process of message handling, which, in those cases, becomes a distributed responsibility of the port and the behavior). If additional message processing is required, one simply needs to insert a part after the port that does the necessary function. Having two different mechanisms for handling messages (in ports AND behaviors) just adds complexity. Based on the KISS principle, ports should be treated just like the pins on a chip, passive things that simply relay information from one side to the other. However, the cat was out of the bag, and it seems that folks just cannot resist the idea of taking advantage of this "opportunity". I strongly advise against it. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? [bvs] See above comment. Cheers...Bran From: "BERNARD, Yves" To: Bran Selic , Cory Casanave CC: "uml2-rtf@omg.org" , "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Date: Wed, 16 Jun 2010 12:02:34 +0200 Subject: RE: About Ports Thread-Topic: About Ports Thread-Index: AcsMyH94UN/+qfm+RGGPHoSDs7CMPAAaL5iw Accept-Language: fr-FR, en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: fr-FR, en-US X-OriginalArrivalTime: 16 Jun 2010 10:02:36.0511 (UTC) FILETIME=[0BF63EF0:01CB0D3B] Bran, According to the discussion I.ve had so far on this subject, my feeling is that the main reasons that leads people to use a port instead of a part is: 1. The graphical notation: some want to represent on the boundary the part that are .directly involved. in interactions with the outside world (despite the fact that this criterion is rather subjective) 2. As defined currently in the UML specification (subtype of Property), we are forced to admit that they are parts... However, from my point of view all the patterns describe below . including the one of UML-RT port . are achievable using a combination of behaviored parts (or peers) and .SDL like. ports. This approach would have the advantage to simplify the semantics without reducing our ability to model a particular scenario. I think that a .SDL like. port could perfectly be a direct subtype of StructuralFeature to avoid any confusion with parts or even .UML-RT like. ports. Another point I would like to underline is that UML clearly links ports to the (OO) concept of .encapsulation.. When encapsulation is not required, ports are useless and only add complexity to the models. As suggested by Jim, I believe that it would be a good idea to clarify this part of the specification for UML 2.5. Juergen has proposed to give an issue number for it. Yves De : bran.selic@gmail.com [mailto:bran.selic@gmail.com] De la part de Bran Selic Envoyé mardi 15 juin 2010 22:22 À: Cory Casanave Cc : BERNARD, Yves; uml2-rtf@omg.org; Bock, Conrad; Burkhart Roger M; Friedenthal, Sanford; Nerijus Jankevicius; Robert Karban; Eldad Palachi; Chris Paredis; Axel Reichwein; Nicolas F Rouquette (316A); Sawyer, George A (US SSA); Fredrick A Steiner; Watson, John Objet : Re: About Ports Cory, I really don't understand why you folks want to make things more complicated than they need to be. As I said, the simplest paradigm is to treat them like the pins of a chip. Anything more complicated can be handled by other means already provided in UML. If you want "interactive parts" then use parts -- that's what they are for. I don't like the idea of having two kinds of parts: "regular parts" and "port parts". Why have two different concepts that do the same thing? Let me use an analogy: There is a very good reason why we do not consider adding user-defined behaviors to the pins of UML actions or the parameters of UML activities -- it just complicates things. If you want some special handling, then simply create a composite activity that includes a nested action (or activity) that performs whatever special application-specific handling you need. My apologies, Cory, but I am unconvinced by your arguments here. Cheers, Bran On Tue, Jun 15, 2010 at 1:26 PM, Cory Casanave wrote: Bran, I would like to suggest paradigm 3, which is probably your .unintended. one: That ports are interactive parts of a system. For example, when you say .talk to Joe in A/P about that. or .place your order on the web site. you are referring an external actor to an actor that is part of the composite system to handle that interaction. From an external point of view we don.t care how the .whole system. handles that interaction. But, it is frequently an independent actor in its own right that is handling that interaction on behalf of the whole. That behavior may be simple (routing) or complex. In some cases the behavior of that actor-part may be derived (creating your scenario 2) or fully delegated (scenario 3) but it may also have its own independently specified behavior for that interaction (scenario 3). So all of these scenarios are about the implementation, not the external contract. The delegation, where an interface of a port becomes an interface of the whole, is not, in my way of thinking, natural at all . in most cases the delegate would be an internal part and the whole would not have any interfaces at all . it seems like this idea of having the whole have all of the interfaces of the ports is one possible OO implementation but not really the design intent. Based on what the UML specification says all of these interpretations are reasonable, regardless of the original intent. The other .messy. part of ports as pure boundary objects without behavior is that they don.t differentiate an internal and external contract. To the inside of the object the interfaces provided/used should be the inverse of those on the outside. It is unfortunate that an otherwise understandable and useful concept has gotten so confused. -Cory -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Tuesday, June 15, 2010 12:51 PM To: BERNARD, Yves Cc: uml2-rtf@omg.org; Bock, Conrad; Burkhart Roger M; Friedenthal, Sanford; Nerijus Jankevicius; Robert Karban; Eldad Palachi; Chris Paredis; Axel Reichwein; Nicolas F Rouquette (316A); Sawyer, George A (US SSA); Fredrick A Steiner; Watson, John Subject: Re: About Ports Since I was involved in the definition of the port mechanism in UML, I will comment on those semantics rather than SysML port semantics. However, in principle, SysML should have inherited those semantics for standard ports. Comments embedded below: On Tue, Jun 15, 2010 at 7:00 AM, BERNARD, Yves wrote: Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? [bvs] Unfortunately, we did a poor job of explaining this in the spec (my fault in part, but my excuse was that I was not the primary author). The port concept in UML originated from two different sources and we decided to support both. Where we screwed up was that we did not clearly identify the two paradigms, which are mutually exclusive, so that people often use some type of unanticipated combination of the two. [bvs] In SDL (one of the paradigms supported), ports are not objects, but merely routing/interaction points. For this case, and for this case only, we allowed modelers the option of defining the type of the port to be the same as the type of the provided interface. Note that this is a very specific interpretation of the "type" concept. Note that, since, in this case ports are not objects, it is possible to type them with an interface, even though interfaces are not instantiable. [bvs] The other model of ports came from UML-RT, in which ports are actually run-time objects that can be manipulated by the behavior of the composite classifier (provided that they are behavior ports, of course). For that case, and for that case only, the type of the port was intended to be a special system-defined type, that realized the provided interface(s) of the port. For example, in UML-RT, one could send a message through a behavior port by invoking a special "send" operation of the port, or defer an incoming message by invoking a "defer" operation. For this reason, ports were allowed to have a behavior, but that behavior was system-defined and not (intended to be) under control of the modeler. [bvs] As I said, we did not clearly explain or delineate these two mutually exclusive use cases, so people naturally came up with mixed cases -- which has caused no end of confusion. Thus, some proposals allowed ports to include modeler-defined behavior, which, is not only unnecessary but also confusing (because it complicates the process of message handling, which, in those cases, becomes a distributed responsibility of the port and the behavior). If additional message processing is required, one simply needs to insert a part after the port that does the necessary function. Having two different mechanisms for handling messages (in ports AND behaviors) just adds complexity. Based on the KISS principle, ports should be treated just like the pins on a chip, passive things that simply relay information from one side to the other. However, the cat was out of the bag, and it seems that folks just cannot resist the idea of taking advantage of this "opportunity". I strongly advise against it. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? [bvs] See above comment. Cheers...Bran This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. To: "BERNARD, Yves" Cc: Burkhart Roger M , Chris Paredis , "Bock, Conrad" , Cory Casanave , Eldad Palachi , Fredrick A Steiner , "Sawyer, George A (US SSA)" , "Watson, John" , Nerijus Jankevicius , "Nicolas F Rouquette (316A)" , Axel Reichwein , Robert Karban , "Friedenthal, Sanford" , Bran Selic , "uml2-rtf@omg.org" Subject: RE: About Ports X-KeepSent: 5D71AD03:AFDAD7B7-85257744:0043BCC4; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Wed, 16 Jun 2010 08:22:47 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 06/16/2010 06:22:50, Serialize complete at 06/16/2010 06:22:50 Yes, we can clarify the intention of ports in UML 2.5 - but the RFP specifically restricts changes to the underlying metamodel. That will come next, after we have a better idea what we actually have now. Jim Amsden, Senior Technical Staff Member Rational Enterprise Architecture Management 919-461-3689 From: "BERNARD, Yves" To: Bran Selic , Cory Casanave Cc: "uml2-rtf@omg.org" , "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Date: 06/16/2010 06:07 AM Subject: RE: About Ports -------------------------------------------------------------------------------- Bran, According to the discussion Iâve had so far on this subject, my feeling is that the main reasons that leads people to use a port instead of a part is: 1. The graphical notation: some want to represent on the boundary the part that are âdirectly involvedâ in interactions with the outside world (despite the fact that this criterion is rather subjective) 2. As defined currently in the UML specification (subtype of Property), we are forced to admit that they are parts... However, from my point of view all the patterns describe below . including the one of UML-RT port . are achichievable using a combination of behaviored parts (or peers) and âSDL likeâ ports. This approach would have the advantage to simplify the semantics without reducing our ability to model a particular scenario. I think that a âSDL likeâ port could perfectly be a direct subtype of StructuralFeature to avoid any confusion with parts or even âUML-RT likeâ ports. Another point I would like to underline is that UML clearly links ports to the (OO) concept of âencapsulationâ. When encapsulation is not required, ports are useless and only add complexity to the models. As suggested by Jim, I believe that it would be a good idea to clarify this part of the specification for UML 2.5. Juergen has proposed to give an issue number for it. Yves De : bran.selic@gmail.com [mailto:bran.selic@gmail.com] De la part de Bran Selic Envoyé : mardi 15 juin 2010 22:22 Ã : Cory Casanave Cc : BERNARD, Yves; uml2-rtf@omg.org; Bock, Conrad; Burkhart Roger M; Friedenthal, Sanford; Nerijus Jankevicius; Robert Karban; Eldad Palachi; Chris Paredis; Axel Reichwein; Nicolas F Rouquette (316A); Sawyer, George A (US SSA); Fredrick A Steiner; Watson, John Objet : Re: About Ports Cory, I really don't understand why you folks want to make things more complicated than they need to be. As I said, the simplest paradigm is to treat them like the pins of a chip. Anything more complicated can be handled by other means already provided in UML. If you want "interactive parts" then use parts -- that's what they are for. I don't like the idea of having two kinds of parts: "regular parts" and "port parts". Why have two different concepts that do the same thing? Let me use an analogy: There is a very good reason why we do not consider adding user-defined behaviors to the pins of UML actions or the parameters of UML activities -- it just complicates things. If you want some special handling, then simply create a composite activity that includes a nested action (or activity) that performs whatever special application-specific handling you need. My apologies, Cory, but I am unconvinced by your arguments here. Cheers, Bran On Tue, Jun 15, 2010 at 1:26 PM, Cory Casanave wrote: Bran, I would like to suggest paradigm 3, which is probably your âunintendedâ one: That ports are interactive parts of a system. For example, when you say âtalk to Joe in A/P about thatâ or âplace your order on the web siteâ you are referring an external actor to an actor that is part of the composite system to handle that interaction. From an external point of view we donât care how the âwhole systemâ handles that interaction. But, it is frequently an independent actor in its own right that is handling that interaction on behalf of the whole. That behavior may be simple (routing) or complex. In some cases the behavior of that actor-part may be derived (creating your scenario 2) or fully delegated (scenario 3) but it may also have its own independently specified behavior for that interaction (scenario 3). So all of these scenarios are about the implementation, not the external contract. The delegation, where an interface of a port becomes an interface of the whole, is not, in my way of thinking, natural at all . in most cases the delegate would bbe an internal part and the whole would not have any interfaces at all . it seems like this idea of having the whole have all of the interfaces of the ports is one possible OO implementation but not really the design intent. Based on what the UML specification says all of these interpretations are reasonable, regardless of the original intent. The other âmessyâ part of ports as pure boundary objects without behavior is that they donât differentiate an internal and external contract. To the inside of the object the interfaces provided/used should be the inverse of those on the outside. It is unfortunate that an otherwise understandable and useful concept has gotten so confused. -Cory -------------------------------------------------------------------------------- From: bran.selic@gmail.com [mailto:bran.selic@gmail.com] On Behalf Of Bran Selic Sent: Tuesday, June 15, 2010 12:51 PM To: BERNARD, Yves Cc: uml2-rtf@omg.org; Bock, Conrad; Burkhart Roger M; Friedenthal, Sanford; Nerijus Jankevicius; Robert Karban; Eldad Palachi; Chris Paredis; Axel Reichwein; Nicolas F Rouquette (316A); Sawyer, George A (US SSA); Fredrick A Steiner; Watson, John Subject: Re: About Ports Since I was involved in the definition of the port mechanism in UML, I will comment on those semantics rather than SysML port semantics. However, in principle, SysML should have inherited those semantics for standard ports. Comments embedded below: On Tue, Jun 15, 2010 at 7:00 AM, BERNARD, Yves wrote: Folks, We have a debate about the concept of Port in the SysML RTF and I would like to get your opinion about some points because we have divergent interpretations of the UML specification. Since a port can be typed by a class, what about the properties and the owned behavior(s) defined for that class? [bvs] Unfortunately, we did a poor job of explaining this in the spec (my fault in part, but my excuse was that I was not the primary author). The port concept in UML originated from two different sources and we decided to support both. Where we screwed up was that we did not clearly identify the two paradigms, which are mutually exclusive, so that people often use some type of unanticipated combination of the two. [bvs] In SDL (one of the paradigms supported), ports are not objects, but merely routing/interaction points. For this case, and for this case only, we allowed modelers the option of defining the type of the port to be the same as the type of the provided interface. Note that this is a very specific interpretation of the "type" concept. Note that, since, in this case ports are not objects, it is possible to type them with an interface, even though interfaces are not instantiable. [bvs] The other model of ports came from UML-RT, in which ports are actually run-time objects that can be manipulated by the behavior of the composite classifier (provided that they are behavior ports, of course). For that case, and for that case only, the type of the port was intended to be a special system-defined type, that realized the provided interface(s) of the port. For example, in UML-RT, one could send a message through a behavior port by invoking a special "send" operation of the port, or defer an incoming message by invoking a "defer" operation. For this reason, ports were allowed to have a behavior, but that behavior was system-defined and not (intended to be) under control of the modeler. [bvs] As I said, we did not clearly explain or delineate these two mutually exclusive use cases, so people naturally came up with mixed cases -- which has caused no end of confusion. Thus, some proposals allowed ports to include modeler-defined behavior, which, is not only unnecessary but also confusing (because it complicates the process of message handling, which, in those cases, becomes a distributed responsibility of the port and the behavior). If additional message processing is required, one simply needs to insert a part after the port that does the necessary function. Having two different mechanisms for handling messages (in ports AND behaviors) just adds complexity. Based on the KISS principle, ports should be treated just like the pins on a chip, passive things that simply relay information from one side to the other. However, the cat was out of the bag, and it seems that folks just cannot resist the idea of taking advantage of this "opportunity". I strongly advise against it. Does the interaction point that instantiates the port has slots to hold runtime values of the properties defined by its type or does it only refer to values held by the instance of its owner (or by a instance of its environment)? How ownedbehaviors defined by the type of the port may impact the way interactions at that port are managed? [bvs] See above comment. Cheers...Bran This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other than the addressee. Access to this e-mail by anyone else is unauthorised. If you are not the intended recipient, please notify Airbus immediately and delete this e-mail. Airbus cannot accept any responsibility for the accuracy or completeness of this e-mail as it has been sent over public networks. If you have any concerns over the content of this message or its Accuracy or Integrity, please contact Airbus immediately. All outgoing e-mails from Airbus are checked using regularly updated virus scanning software but you should take whatever measures you deem to be appropriate to ensure that this message and any attachments are virus free. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:sender:received :in-reply-to:references:from:date:x-google-sender-auth:message-id :subject:to:cc:content-type; bh=2tFHLlMVkQDIGGTDi2Efi28b0eDrewT1ediBuVE+IZU=; b=ru0DjC6IEnz5tZ8PyKCzhvsrrtnpCzIf2KwW5jAlXLI4iBwrzVljlrz5gdA7BG51FU znh6zn3y2OExUXZ2i6lUruWFkLyF+JjMb3QKmPFoBhf6NW9PPdbzf9dBYgB/RzGocGql eF4YqcPY469rbfyByH4MC7QT1eghrfN7vVVnk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; b=P2KQJ1Op5MXZElxMagVJWCI8mZqpsKOIZybMYJW2j0azaZIu4W8Ns93h1GYte3VNNm NCetZjcvbw5C5oWtACULfhULqgjg2aIWpCaWfl+WMl3y5DnEikLqJqGidYARIkKrB/fb mZwRPma2+e8TS1OWyZCUW8jo1XE4uIaZf+0uY= Sender: bran.selic@gmail.com From: Bran Selic Date: Wed, 16 Jun 2010 14:40:26 -0400 X-Google-Sender-Auth: Iqme6d0VzZYo8905fOM7_-VpI6A Subject: Re: About Ports To: "BERNARD, Yves" Cc: Cory Casanave , "uml2-rtf@omg.org" , "Bock, Conrad" , Burkhart Roger M , "Friedenthal, Sanford" , Nerijus Jankevicius , Robert Karban , Eldad Palachi , Chris Paredis , Axel Reichwein , "Nicolas F Rouquette (316A)" , "Sawyer, George A (US SSA)" , Fredrick A Steiner , "Watson, John" Thanks, Yves. Comments below: On Wed, Jun 16, 2010 at 6:02 AM, BERNARD, Yves wrote: Bran, According to the discussion I.ve had so far on this subject, my feeling is that the main reasons that leads people to use a port instead of a part is: 1. The graphical notation: some want to represent on the boundary the part that are .directly involved. in interactions with the outside world (despite the fact that this criterion is rather subjective) 2. As defined currently in the UML specification (subtype of Property), we are forced to admit that they are parts... [bvs] I believe that you are right on both counts. In my view, neither of these justifies the extra complexity introduced by a more "sophisticated" model of ports. One thing that I have learned from my OMG experience is that clever people (and the OMG has more than its share) actually thrive on on identifying nuances, which, invariably, lead to added complexity. I am sure that someone will explain to me why "boundary parts" have advantages over a simple delegation connector from a port to an internal part. This is precisely the type of approach that gave us UML, with all its glory. [bvs] Finding the right measure in language design is truly an art, and there are very who have mastered it, but many more who believe that they have. However, from my point of view all the patterns describe below . including the one of UML-RT port . are achievable using a combination of behaviored parts (or peers) and .SDL like. ports. This approach would have the advantage to simplify the semantics without reducing our ability to model a particular scenario. I think that a .SDL like. port could perfectly be a direct subtype of StructuralFeature to avoid any confusion with parts or even .UML-RT like. ports. [bvs] I agree. Actually, what you've described is, in essence, what we had in UML-RT. There we distinguished between "relay ports" (analogous to your "SDL-like" ports) and "behaviour ports" (what you refer to as "UML-RT ports"). In UML 2, however, the decision was made to distinguish, instead, between connectors and so-called "delegation connectors". I am pretty sure now that this was a mistake. But, the real mistake was not being clear in the specification. Another point I would like to underline is that UML clearly links ports to the (OO) concept of .encapsulation.. When encapsulation is not required, ports are useless and only add complexity to the models. [bvs] Actually, this was another point of contention during the initial drafts, based on what people mean by "encapsulation". To be clear, the primary purpose of ports is to achieve decoupling between the internals and the externals of an object, such that it becomes possible for an object to distinguish between different external collaborations without having to refer explicitly to such collaborators. Depending on your point of view, you can equate encapsulation with decoupling or not. For me, encapuslation has to do with information hiding, which is not quite the same thing (in my mind) as decoupling. But -- there you go: an example of the kind of nuance that OMG people love to discuss. As suggested by Jim, I believe that it would be a good idea to clarify this part of the specification for UML 2.5. Juergen has proposed to give an issue number for it. [bvs] Agreed. Cheers...Bran