Issue 15352: Figure 92: Specification (soaml-rtf) Source: SINTEF (Brian Elvesćter, brian.elvesater(at)sintef.no) Nature: Clarification Severity: Significant Summary: Same as issue 15333: Here <<specification>> is introduced and <<Participant>> is used on the implementation (realization). The relationship between <<specification>> and <<Participant>> is not clear to me in the specification. I would argue that a <<Participant>> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). Resolution: Revised Text: Actions taken: July 1, 2010: received issue Discussion: End of Annotations:===== s is issue # 15352 From: Brian Elvesær Figure 92: Specification Same as issue 15333: Here <> is introduced and <> is used on the implementation (realization). The relationship between <> and <> is not clear to me in the specification. I would argue that a <> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). To: Brian.Elvesater@sintef.no, soaml-ftf@omg.org Subject: Fw: issues 15352 SoaML specification and Participant X-KeepSent: A81967B8:B0CC7D64-8525775E:0043B8A1; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Mon, 12 Jul 2010 08:25:45 -0400 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 07/12/2010 06:25:46, Serialize complete at 07/12/2010 06:25:46 Brian, Think of a <> Participant like an Interface - something that declares the services that any realizing participant must provide and consume, and any behavioral constraints on how they should realize them. That is, a <>Participant is to realizing Participants as Interface is to Class. This is not SoaML specific but rather is defined in UML2. The purpose is to separate specification from implementation to reduce coupling. Jim Amsden, Senior Technical Staff Member Rational EA and ADC Tools 919-461-3689 ----- Forwarded by Jim Amsden/Raleigh/IBM on 07/12/2010 08:19 AM ----- From: Juergen Boldt To: issues@omg.org, soaml-ftf@omg.org Date: 07/08/2010 01:30 PM Subject: issues 15352 - 15354 -- SoaML issues (no RTF chartered) -------------------------------------------------------------------------------- This is issue # 15352 From: Brian Elvesær Figure 92: Specification Same as issue 15333: Here <> is introduced and <> is used on the implementation (realization). The relationship between <> and <> is not clear to me in the specification. I would argue that a <> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). =========================================================== This is issue # 15353 From: Brian Elvesær Figure 93: Interfaces Apply correct stereotypes to the interfaces. =========================================================== This is issue # 15354 From: Brian Elvesær Figure 96: Specification Same as issue 15333: Here <> is introduced and <> is used on the implementation (realization). The relationship between <> and <> is not clear to me in the specification. I would argue that a <> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org X-IronPort-AV: E=Sophos;i="4.55,192,1278280800"; d="png'150?scan'150,208,217,150";a="22587484" From: LONJON Antoine To: Jim Amsden CC: "Brian.Elvesater@sintef.no" , "soaml-ftf@omg.org" Date: Tue, 13 Jul 2010 11:21:14 +0200 Subject: RE: issues 15352 SoaML specification and Participant Thread-Topic: issues 15352 SoaML specification and Participant Thread-Index: AcshvYq7/085E9VRRxOlD4EkGkjqrwAqprYg Accept-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: acceptlanguage: en-US Jim, This intent is very clear : separate specification from implementation to reduce coupling But does it really requires specific types such as versus ? Isn.t this concept of .realization. rather a relationship between participants; more precisely, a specific kind of generalization relationship . called realization . where all parts of the realized participant must have counterparts in corresponding realizing participants (including behaviors). Indeed, any participant . whether concrete or not . could be used as a specification for other participants. Furthermore, all instances of realizing participants of are presumably also instance of their realized participant. For instance, the .Shipper Impl. of figure 40 in the SOAML document could also be a specification for a .Shipper Impl ++. . Instances of ShipperImpl++ are also instances of Shipper. This would also clarify the status of interface.. Interface is not a performer/participant. Nor instances of Shipper, ShipperImpl or ShipperImpl++ are instances of ShippingService. I see Interfaces as other kind of animals. They express communication relationships that type connections between participants (This is also why they are better expressed with collaboration models). As a summary, a response to Brian concern could be to look at the .specification/implementation. couple as a kind generalization relationship rather than specific types of participants.. Antoine From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, July 12, 2010 2:26 PM To: Brian.Elvesater@sintef.no; soaml-ftf@omg.org Subject: Fw: issues 15352 SoaML specification and Participant Brian, Think of a <> Participant like an Interface - something that declares the services that any realizing participant must provide and consume, and any behavioral constraints on how they should realize them. That is, a <>Participant is to realizing Participants as Interface is to Class. This is not SoaML specific but rather is defined in UML2. The purpose is to separate specification from implementation to reduce coupling. Jim Amsden, Senior Technical Staff Member Rational EA and ADC Tools 919-461-3689 ----- Forwarded by Jim Amsden/Raleigh/IBM on 07/12/2010 08:19 AM ----- From: Juergen Boldt To: issues@omg.org, soaml-ftf@omg.org Date: 07/08/2010 01:30 PM Subject: issues 15352 - 15354 -- SoaML issues (no RTF chartered) -------------------------------------------------------------------------------- This is issue # 15352 From: Brian Elvesær Figure 92: Specification Same as issue 15333: Here <> is introduced and <> is used on the implementation (realization). The relationship between <> and <> is not clear to me in the specification. I would argue that a <> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). =========================================================== This is issue # 15353 From: Brian Elvesær Figure 93: Interfaces Apply correct stereotypes to the interfaces. =========================================================== This is issue # 15354 From: Brian Elvesær Figure 96: Specification Same as issue 15333: Here <> is introduced and <> is used on the implementation (realization). The relationship between <> and <> is not clear to me in the specification. I would argue that a <> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -------------------------------------------------------------------------------- This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content. To: LONJON Antoine Cc: "Brian.Elvesater@sintef.no" , "soaml-ftf@omg.org" Subject: RE: issues 15352 SoaML specification and Participant X-KeepSent: D9262B43:C52C633A-8525775F:0045F886; type=4; name=$KeepSent X-Mailer: Lotus Notes Release 8.5.1 September 28, 2009 From: Jim Amsden Date: Tue, 13 Jul 2010 06:52:52 -0600 X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 8.5.1FP2|March 17, 2010) at 07/13/2010 06:52:55, Serialize complete at 07/13/2010 06:52:55 Antoine, Nice to hear from you. We miss you. Comments embedded below... Jim Amsden, Senior Technical Staff Member Rational EA and ADC Tools 919-461-3689 From: LONJON Antoine To: Jim Amsden/Raleigh/IBM@IBMUS Cc: "Brian.Elvesater@sintef.no" , "soaml-ftf@omg.org" Date: 07/13/2010 05:26 AM Subject: RE: issues 15352 SoaML specification and Participant -------------------------------------------------------------------------------- Jim, This intent is very clear : separate specification from implementation to reduce coupling But does it really requires specific types such as versus ? Isnât this concept of ârealizationâ rather a relationship between participants; more precisely, a specific kind of generalization relationship . calleed realization . where all parts of the realized particcipant must have counterparts in corresponding realizing participants (including behaviors). Exactly. a <> Participant, like an Interface, can't be instantiated. It must be realized by some Participant that can be instantiated. This could be an abstract Participant that has concrete subclasses. Indeed, any participant . whether concrete or nott . could be used as a specification for other participaants. Furthermore, all instances of realizing participants of are presumably also instance of their realized participant. For instance, the âShipper Implâ of figure 40 in the SOAML document could also be a specification for a âShipper Impl ++â . Instances of ShipperImpl++ are also instances of Shipper. The notion of <> Participant is a little different though. Its not intended to be instantiated, but can be used as a type for a part in an assembly. Any realizing participant can be substituted for the part, again just like Interface and Class. A <> Participant is kind of like an Interface that can have ports, provide and consume services, and have specifying behaviors. In your example, how would it be different if ShipperImpl++ realized <>Shipper? Generally component realization was intended to be between <> and <> components. This would also clarify the status of interfaceâ. Interface is not a performer/participant. Nor instances of Shipper, ShipperImpl or ShipperImpl++ are instances of ShippingService. I see Interfaces as other kind of animals. They express communication relationships that type connections between participants (This is also why they are better expressed with collaboration models). As a summary, a response to Brian concern could be to look at the âspecification/implementationâ couple as a kind generalization relationship rather than specific types of participants.. Antoine From: Jim Amsden [mailto:jamsden@us.ibm.com] Sent: Monday, July 12, 2010 2:26 PM To: Brian.Elvesater@sintef.no; soaml-ftf@omg.org Subject: Fw: issues 15352 SoaML specification and Participant Brian, Think of a <> Participant like an Interface - something that declares the services that any realizing participant must provide and consume, and any behavioral constraints on how they should realize them. That is, a <>Participant is to realizing Participants as Interface is to Class. This is not SoaML specific but rather is defined in UML2. The purpose is to separate specification from implementation to reduce coupling. Jim Amsden, Senior Technical Staff Member Rational EA and ADC Tools 919-461-3689 ----- Forwarded by Jim Amsden/Raleigh/IBM on 07/12/2010 08:19 AM ----- From: Juergen Boldt To: issues@omg.org, soaml-ftf@omg.org Date: 07/08/2010 01:30 PM Subject: issues 15352 - 15354 -- SoaML issues (no RTF chartered) -------------------------------------------------------------------------------- This is issue # 15352 From: Brian Elvesæter Figure 92: Specification Same as issue 15333: Here <> is introduced and <> is used on the implementation (realization). The relationship between <> and <> is not clear to me in the specification. I would argue that a <> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). =========================================================== This is issue # 15353 From: Brian Elvesæter Figure 93: Interfaces Apply correct stereotypes to the interfaces. =========================================================== This is issue # 15354 From: Brian Elvesæter Figure 96: Specification Same as issue 15333: Here <> is introduced and <> is used on the implementation (realization). The relationship between <> and <> is not clear to me in the specification. I would argue that a <> can be seen as a logical system component that represents a specification, which can be further decomposed into a set of Participants (in the case you want to specify lower-level/participant-level services architectures) or components (design of software components). Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org -------------------------------------------------------------------------------- This e-mail, including attachments, is confidential. It is intended solely for the addressees. If you are not a recipient, any use, copy or diffusion, even in part of this message is prohibited. Please delete it and notify the sender immediately. Since the integrity of this message cannot be guaranteed on the Internet, MEGA cannot be considered liable for its content.