Issue 11875: Relationship between Alloc::Allocation and SRM::EntryPoint (marte-ftf) Source: THALES (Mr. Sebastien Demathieu, sebastien.demathieu(at)thalesgroup.com) Nature: Clarification Severity: Significant Summary: Relationship between Alloc::Allocation and SRM::EntryPoint should be clarified (maybe a generalization relationship?) Resolution: SRM::EntryPoint shloud specialized the Alloc::Allocation stereotype. Revised Text: Figure 14.5 Old: New: Figure 14.25 Old : New : Stereotype Description section to update : Old : This stereotype matches to the domain concept, EntryPoint, defined on page Erreur ! Signet non défini.. Extensions ? Dependency (from UML::Classes::Kernel). ? BehavioralFeature (UML::Classes::Kernel). New : This stereotype matches to the domain concept, EntryPoint, defined on page "To define". Generalizations · Allocate (from Alloc) on page "to define". Class Description section to update : Old : Generalizations ? ModelElement New : Generalizations ? Allocation (from Allocations) Actions taken: December 21, 2007: received issue February 17, 2010: closed issue Discussion: see ptc/2008-06-05 for revised text (graphics) End of Annotations:===== m: webmaster@omg.org Date: 21 Dec 2007 14:36:50 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Sébastien Demathieu Company: Thales mailFrom: sebastien.demathieu@thalesgroup.com Notification: Yes Specification: UML profile for MARTE Section: 14 FormalNumber: 07-08-04 Version: Beta 1 RevisionDate: 08/2007 Page: 181 Nature: Clarification Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.11) Gecko/20071127 Firefox/2.0.0.11 Description Relationship between Alloc::Allocation and SRM::EntryPoint should be clarified (maybe a generalization relationship?) Date: Thu, 06 Mar 2008 11:03:19 +0100 From: Julio Medina 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: Frédéric THOMAS Cc: fmallet@i3s.unice.fr, Sébastien Demathieu , marte-ftf@omg.org Subject: Re: [MARTE] issue 11875 X-OriginalArrivalTime: 06 Mar 2008 10:03:20.0339 (UTC) FILETIME=[4E65DE30:01C87F71] X-imss-version: 2.050 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:5.0.1023(15770.003) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:2 S:2 R:2 (0.0000 0.0000) In my opinion Fred, it is clearly the allocate concept NOT the refinement. Cheers, Julio Frédéric THOMAS wrote: Hi frédéric, I am dealing with the issue 11875 (http://www.omg.org/issues/marte-ftf.open.html#Issue11875) which leads to clarrify the relationship between the Alloc::Allocate stereotype and the SRM::EntryPoint one. The EntryPoint stereotype is used for linking a concurrent resource instance to the sequential actions which must be executed in its execution context. I describe in MARTE the EntryPoint stereotype because I need to reference the behavioralFeature and to describe the entryPoint parameters passed to the behavior (see attached picture as an example). To answer this issue, I was thinking to specialize the Allocate stereotype with the EntryPoint one. Nervetheless, I am wondering wether I must sepcialize either the "Allocate" concept or the "Refinement" concept. Do you have any suggestions ? Thanks, Frédéric -- Frédéric THOMAS Service Outils Logiciels CEA-List Saclay, Bât 451, p. 32A 91191 Gif sur yvette Cedex FRANCE Tel : 01 69 08 17 75 Subject: [Issue 11875] About Allocation direction... Date: Wed, 4 Jun 2008 15:32:57 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Issue 11875] About Allocation direction... Thread-Index: AcjGR4AH3WoDvb8wQYebE+ze8d3oQg== From: "BERNARD, Yves" To: X-OriginalArrivalTime: 04 Jun 2008 13:32:57.0869 (UTC) FILETIME=[805E23D0:01C8C647] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m54DZ5QC005462 Hello, >From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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. Date: Thu, 05 Jun 2008 07:53:04 +1000 From: Darren R C KELLY User-Agent: Thunderbird 2.0.0.0 (X11/20070326) To: "BERNARD, Yves" Cc: marte-ftf@omg.org, Fredrick A Steiner , Burkhart Roger M , Nerijus Jankevicius Subject: Re: [Issue 11875] About Allocation direction... X-Virus-Scanned: ClamAV 0.91.2/7366/Thu Jun 5 03:03:12 2008 on mail.nomagicasia.com X-Virus-Status: Clean X-Spam-Status: No, score=-98.1 required=5.0 tests=AWL,BAYES_50,HTML_MESSAGE, MIME_HTML_ONLY,RCVD_IN_PBL,RDNS_NONE,USER_IN_WHITELIST autolearn=no version=3.2.3 X-Spam-Checker-Version: SpamAssassin 3.2.3 (2007-08-08) on mail.nomagicasia.com Hi Yves, This has been identified as a problem with the SysML1.0 Allocate/Allocated, too. (I've CCed some people who have been recently involved in such discussions, and I also caught your recent discussions on the SysML Forum regarding Requirement 'SatisfiedBy-relation'). SysML1.0 15.3.2.2 Allocated(from Allocations): /allocatedTo:NamedElement[*] /allocatedFrom:NamedElement[*] If the dependant element to which other elements are allocated is read-only one has a problem; even though the /allocatedFrom can be computed on-the-fly, the <> can't be applied. Compare with the SysML 16.3.2.3 Requirement: . /satisfiedBy: NamedElement [*] Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier. . /verifiedBy: NamedElement [*] Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier. Since the /satisfiedBy is derived, it can be computed on-the-fly for a readonly-element. >From http://school.nomagic.com/node/519: A callout has been used to display the otherwise hidden stereotype, <> on block AlsoAllocatedTo. Note callouts is an extremely useful feature for UML and SysML and all modelling, it offers orthogonal access to nearly any model information, and is of enormous educational value. I am a great fan of callouts. Visit also: http://www.omg.org/issues/sysml-rtf.html#12146 "Wrong ends of Allocate relationship used in Allocated definition" http://school.nomagic.com/node/449 & http://school.nomagic.com/node/451 Includes a detailed analysis of direction in SysML Allocate and the UML2 relationships it builds on regards, Darren -------------------------------------------------------------------------------- There is BTW a precedent for confusion about the direction of relationships where abstraction is involved in a process. The UML2 ComponentRealization subsets are in the opposite sense from the Realization subsets: http://www.omg.org/issues/issue11008.txt "ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation)" http://www.omg.org/issues/issue9119.txt "In a component realization, the direction of the dependency is reversed" There is a detailed analysis of the UML2.1.2 spec of ComponentRealization here, including my "proof" that the UML2 specification self-contradictory on the matter: http://school.nomagic.com/ComponentRealization It seems that one justification for the subset swap in ComponentRealization is to handle read-only module cases like one encounters for allocations. (Even if the "swap is justified", the UML2.1.2 spec is demonstrably unclear.) Glad for feedback on this related matter from ComponentRealization authors/specifiers here. -------------------------------------------------------------------------------- BERNARD, Yves wrote: Hello, >From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! Subject: RE: [Issue 11875] About Allocation direction... Date: Mon, 9 Jun 2008 11:01:43 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Issue 11875] About Allocation direction... Thread-Index: AcjGjR5ItXFOrXxwTu+H1Ugf2oib8ADfR3UA From: "BERNARD, Yves" To: "Darren R C KELLY" Cc: , "Fredrick A Steiner" , "Burkhart Roger M" , "Nerijus Jankevicius" X-OriginalArrivalTime: 09 Jun 2008 09:01:44.0532 (UTC) FILETIME=[70C4B940:01C8CA0F] Hi Darren, According to an "application/platform" approach the simple fact that one of the element involved in the allocation owns this relationship is - by itself - a problem. The application part is the description of the need and, as such, should be "platform independant". The concept of "platform" includes the idea of genericity and reusability and then should not have a dependency - either explicit or implicit - to any specific application even. That's why, from my point of view, the allocations should be considered as an upper layer that shall not be "intrusive" neither in the application model nor in the platform ones. Then we could say (and i do !) that a "product" is defined by the allocation of an application (logical model) over a set of elements provided by a platform (physical model). * About "Wrong ends of Allocate relationship used in Allocated definition" (which is #11501 and not #12146 ;o) ). The current SysML specification is the right one if you considere the actual meaning of a dependency and not only the graphical symbol. A dependency indicates that the element that is pointed by the arrow provides the specification for the element on the opposite side. That's why the former is called "server" and the latter "client". Then, the specifcation is indeed provided (allocated) TO the client and FROM the server. The arrow is in the opposite direction because it indicates the dependency relationship at not the "flow" of information. Best regards, Yves -----Message d'origine---- De : Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Envoyé : mercredi 4 juin 2008 23:53 À : BERNARD, Yves Cc : marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : Re: [Issue 11875] About Allocation direction... Hi Yves, This has been identified as a problem with the SysML1.0 Allocate/Allocated, too. (I've CCed some people who have been recently involved in such discussions, and I also caught your recent discussions on the SysML Forum regarding Requirement 'SatisfiedBy-relation'). SysML1.0 15.3.2.2 Allocated(from Allocations): /allocatedTo:NamedElement[*] /allocatedFrom:NamedElement[*] If the dependant element to which other elements are allocated is read-only one has a problem; even though the /allocatedFrom can be computed on-the-fly, the <> can't be applied. Compare with the SysML 16.3.2.3 Requirement: . /satisfiedBy: NamedElement [*] Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier. . /verifiedBy: NamedElement [*] Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier. Since the /satisfiedBy is derived, it can be computed on-the-fly for a readonly-element. From http://school.nomagic.com/node/519: A callout has been used to display the otherwise hidden stereotype, <> on block AlsoAllocatedTo. Note callouts is an extremely useful feature for UML and SysML and all modelling, it offers orthogonal access to nearly any model information, and is of enormous educational value. I am a great fan of callouts. Visit also: http://www.omg.org/issues/sysml-rtf.html#12146 "Wrong ends of Allocate relationship used in Allocated definition" http://school.nomagic.com/node/449 & http://school.nomagic.com/node/451 Includes a detailed analysis of direction in SysML Allocate and the UML2 relationships it builds on regards, Darren -------------------------------------------------------------------------------- There is BTW a precedent for confusion about the direction of relationships where abstraction is involved in a process. The UML2 ComponentRealization subsets are in the opposite sense from the Realization subsets: http://www.omg.org/issues/issue11008.txt "ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation)" http://www.omg.org/issues/issue9119.txt "In a component realization, the direction of the dependency is reversed" There is a detailed analysis of the UML2.1.2 spec of ComponentRealization here, including my "proof" that the UML2 specification self-contradictory on the matter: http://school.nomagic.com/ComponentRealization It seems that one justification for the subset swap in ComponentRealization is to handle read-only module cases like one encounters for allocations. (Even if the "swap is justified", the UML2.1.2 spec is demonstrably unclear.) Glad for feedback on this related matter from ComponentRealization authors/specifiers here. -------------------------------------------------------------------------------- BERNARD, Yves wrote: Hello, >From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! 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 then 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: [Issue 11875] About Allocation direction... Date: Mon, 9 Jun 2008 12:11:46 +0200 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [Issue 11875] About Allocation direction... Thread-Index: AcjGjR5ItXFOrXxwTu+H1Ugf2oib8ADfR3UAAAJfTnAAAVh6IA== From: "BERNARD, Yves" To: "GERARD Sebastien 166342" , "Darren R C KELLY" Cc: , "Fredrick A Steiner" , "Burkhart Roger M" , "Nerijus Jankevicius" X-OriginalArrivalTime: 09 Jun 2008 10:11:47.0361 (UTC) FILETIME=[39D98910:01C8CA19] +1 Perfect for me ! :o) Yves -----Message d'origine----- De : GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Envoyé : lundi 9 juin 2008 12:01 À : BERNARD, Yves; Darren R C KELLY Cc : marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : RE: [Issue 11875] About Allocation direction... I do understand this point of view and may share it I also think we should consider the allocation as an orthogonal model of both the application model and the platform model. If we go in this direction, Allocate should not be a relationship but a classifier element. And we could foresee to have new concept we could call it, AllocationSpecification. This latter may own a set of dependencies stereotyped «allocatedFrom» and a set of dependencies stereotype «allocatedTo». Regards, Sébastien. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment -------------------------------------------------------------------------------- De : BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Envoyé : lundi 9 juin 2008 11:02 À : Darren R C KELLY Cc : marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : RE: [Issue 11875] About Allocation direction... Hi Darren, According to an "application/platform" approach the simple fact that one of the element involved in the allocation owns this relationship is - by itself - a problem. The application part is the description of the need and, as such, should be "platform independant". The concept of "platform" includes the idea of genericity and reusability and then should not have a dependency - either explicit or implicit - to any specific application even. That's why, from my point of view, the allocations should be considered as an upper layer that shall not be "intrusive" neither in the application model nor in the platform ones. Then we could say (and i do !) that a "product" is defined by the allocation of an application (logical model) over a set of elements provided by a platform (physical model). * About "Wrong ends of Allocate relationship used in Allocated definition" (which is #11501 and not #12146 ;o) ). The current SysML specification is the right one if you considere the actual meaning of a dependency and not only the graphical symbol. A dependency indicates that the element that is pointed by the arrow provides the specification for the element on the opposite side. That's why the former is called "server" and the latter "client". Then, the specifcation is indeed provided (allocated) TO the client and FROM the server. The arrow is in the opposite direction because it indicates the dependency relationship at not the "flow" of information. Best regards, Yves -----Message d'origine---- De : Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Envoyé : mercredi 4 juin 2008 23:53 À : BERNARD, Yves Cc : marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : Re: [Issue 11875] About Allocation direction... Hi Yves, This has been identified as a problem with the SysML1.0 Allocate/Allocated, too. (I've CCed some people who have been recently involved in such discussions, and I also caught your recent discussions on the SysML Forum regarding Requirement 'SatisfiedBy-relation'). SysML1.0 15.3.2.2 Allocated(from Allocations): /allocatedTo:NamedElement[*] /allocatedFrom:NamedElement[*] If the dependant element to which other elements are allocated is read-only one has a problem; even though the /allocatedFrom can be computed on-the-fly, the <> can't be applied. Compare with the SysML 16.3.2.3 Requirement: . /satisfiedBy: NamedElement [*] Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier. . /verifiedBy: NamedElement [*] Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier. Since the /satisfiedBy is derived, it can be computed on-the-fly for a readonly-element. From http://school.nomagic.com/node/519: A callout has been used to display the otherwise hidden stereotype, <> on block AlsoAllocatedTo. Note callouts is an extremely useful feature for UML and SysML and all modelling, it offers orthogonal access to nearly any model information, and is of enormous educational value. I am a great fan of callouts. Visit also: http://www.omg.org/issues/sysml-rtf.html#12146 "Wrong ends of Allocate relationship used in Allocated definition" http://school.nomagic.com/node/449 & http://school.nomagic.com/node/451 Includes a detailed analysis of direction in SysML Allocate and the UML2 relationships it builds on regards, Darren -------------------------------------------------------------------------------- There is BTW a precedent for confusion about the direction of relationships where abstraction is involved in a process. The UML2 ComponentRealization subsets are in the opposite sense from the Realization subsets: http://www.omg.org/issues/issue11008.txt "ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation)" http://www.omg.org/issues/issue9119.txt "In a component realization, the direction of the dependency is reversed" There is a detailed analysis of the UML2.1.2 spec of ComponentRealization here, including my "proof" that the UML2 specification self-contradictory on the matter: http://school.nomagic.com/ComponentRealization It seems that one justification for the subset swap in ComponentRealization is to handle read-only module cases like one encounters for allocations. (Even if the "swap is justified", the UML2.1.2 spec is demonstrably unclear.) Glad for feedback on this related matter from ComponentRealization authors/specifiers here. -------------------------------------------------------------------------------- BERNARD, Yves wrote: Hello, >From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! 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 then 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. 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 then 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:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=uLIQW+FcNYrMzDeZcR9tRuh+vCeyqNYbYBsHd1yRTgA=; b=WWfvVGOMXElL4nDvbG6QptJwL8WK2YbhFe5z8ZipGsx31vdh8luv0JZyxk/K1EGxNO sxfzUpE1StaS2EVTGue+pXzEeXeiGuly6WMkOugdn3cA3RdJDY7ytjJzbr7XNPJswIih +SOOCvCZ9EdSyPzCcroiIICHYzYZh8qhAPZWc= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=svTK+wzyWV3Ew0qIRY+4jeoPtIsrax1oJnVsbvNMGT/oTJ/NImMQtaojfhBQSoBea2 ONJzn6obBpOosXSTTJvg198ug5+GeWPA2zgWFptkyVvVa9mfZe5534B1Guw8TocmWces PakI6iIzXtovoPl1Hf6bZeUGAhdslNcXkiCp8= Date: Mon, 9 Jun 2008 09:35:01 -0400 From: "Bran Selic" To: "BERNARD, Yves" Subject: Re: [Issue 11875] About Allocation direction... Cc: "Darren R C KELLY" , marte-ftf@omg.org, "Fredrick A Steiner" , "Burkhart Roger M" , "Nerijus Jankevicius" Note that, formally, the allocation dependency is not owned by either its source or destination, but by the package in which it is defined. So, ownership of the allocation dependency is not the issue. The issue is whether or not the application model or the platform model are modified in any way as a result of the application and whether it matters. It is quite reasonable to argue that an application that is allocated is not the same as the unallocated application, implying that it is OK to change the application model when this happens. One way of dealing with this is to use package merge when specifying the allocation. The package in which the allocation is defined would then import the platform model and merge in the application model, adding allocation dependencies from the application to the platform. This would leave the original models unaffected by those not interested in this particular allocation. I have not thought this all the way through, so there may be flaws in this solution, but I thought I'd throw it into the argument, in case it helps. Cheers...Bran On Mon, Jun 9, 2008 at 5:01 AM, BERNARD, Yves wrote: Hi Darren, According to an "application/platform" approach the simple fact that one of the element involved in the allocation owns this relationship is - by itself - a problem. The application part is the description of the need and, as such, should be "platform independant". The concept of "platform" includes the idea of genericity and reusability and then should not have a dependency - either explicit or implicit - to any specific application even. That's why, from my point of view, the allocations should be considered as an upper layer that shall not be "intrusive" neither in the application model nor in the platform ones. Then we could say (and i do !) that a "product" is defined by the allocation of an application (logical model) over a set of elements provided by a platform (physical model). * About "Wrong ends of Allocate relationship used in Allocated definition" (which is #11501 and not #12146 ;o) ). The current SysML specification is the right one if you considere the actual meaning of a dependency and not only the graphical symbol. A dependency indicates that the element that is pointed by the arrow provides the specification for the element on the opposite side. That's why the former is called "server" and the latter "client". Then, the specifcation is indeed provided (allocated) TO the client and FROM the server. The arrow is in the opposite direction because it indicates the dependency relationship at not the "flow" of information. Best regards, Yves -----Message d'origine---- De : Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Envoyé : mercredi 4 juin 2008 23:53 À : BERNARD, Yves Cc : marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : Re: [Issue 11875] About Allocation direction... Hi Yves, This has been identified as a problem with the SysML1.0 Allocate/Allocated, too. (I've CCed some people who have been recently involved in such discussions, and I also caught your recent discussions on the SysML Forum regarding Requirement 'SatisfiedBy-relation'). SysML1.0 15.3.2.2 Allocated(from Allocations): /allocatedTo:NamedElement[*] /allocatedFrom:NamedElement[*] If the dependant element to which other elements are allocated is read-only one has a problem; even though the /allocatedFrom can be computed on-the-fly, the <> can't be applied. Compare with the SysML 16.3.2.3 Requirement: . /satisfiedBy: NamedElement [*] Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier. . /verifiedBy: NamedElement [*] Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier. Since the /satisfiedBy is derived, it can be computed on-the-fly for a readonly-element. From http://school.nomagic.com/node/519: A callout has been used to display the otherwise hidden stereotype, <> on block AlsoAllocatedTo. Note callouts is an extremely useful feature for UML and SysML and all modelling, it offers orthogonal access to nearly any model information, and is of enormous educational value. I am a great fan of callouts. Visit also: http://www.omg.org/issues/sysml-rtf.html#12146 "Wrong ends of Allocate relationship used in Allocated definition" http://school.nomagic.com/node/449 & http://school.nomagic.com/node/451 Includes a detailed analysis of direction in SysML Allocate and the UML2 relationships it builds on regards, Darren -------------------------------------------------------------------------------- There is BTW a precedent for confusion about the direction of relationships where abstraction is involved in a process. The UML2 ComponentRealization subsets are in the opposite sense from the Realization subsets: http://www.omg.org/issues/issue11008.txt "ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation)" http://www.omg.org/issues/issue9119.txt "In a component realization, the direction of the dependency is reversed" There is a detailed analysis of the UML2.1.2 spec of ComponentRealization here, including my "proof" that the UML2 specification self-contradictory on the matter: http://school.nomagic.com/ComponentRealization It seems that one justification for the subset swap in ComponentRealization is to handle read-only module cases like one encounters for allocations. (Even if the "swap is justified", the UML2.1.2 spec is demonstrably unclear.) Glad for feedback on this related matter from ComponentRealization authors/specifiers here. -------------------------------------------------------------------------------- BERNARD, Yves wrote: Hello, >From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! 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 then 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: [Issue 11875] About Allocation direction... Date: Mon, 9 Jun 2008 17:21:17 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [Issue 11875] About Allocation direction... Thread-Index: AcjKNaCbnlqzzZR5SVGLu3zyawQHqAAAZ9yA From: "BERNARD, Yves" To: "Bran Selic" Cc: "Darren R C KELLY" , , "Fredrick A Steiner" , "Burkhart Roger M" , "Nerijus Jankevicius" X-OriginalArrivalTime: 09 Jun 2008 15:21:18.0567 (UTC) FILETIME=[7726AF70:01C8CA44] Yes, i should'nt have use the word "owns", you're right. My point is that no direct dependency shall exist between the application and the platform, no mater who owns them. I 've to analyse your proposition based on model merges. What do you exactly mean when you say that "an application that is allocated is not the same as the unallocated application"? From your point of view, what are the differencies between them : only the allocation relationships or more? In the first case our propositions are very closed, except that you considere that the allocation effect is not "symetric" in a sens where only the application side should be affected. However, i think we could have a similar justification for an "allocated platform". In the second case, do you mean that the application shall be "adapted" to be allocated to the platform? And what about the opposite? Cheers. Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : lundi 9 juin 2008 15:35 À : BERNARD, Yves Cc : Darren R C KELLY; marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : Re: [Issue 11875] About Allocation direction... Note that, formally, the allocation dependency is not owned by either its source or destination, but by the package in which it is defined. So, ownership of the allocation dependency is not the issue. The issue is whether or not the application model or the platform model are modified in any way as a result of the application and whether it matters. It is quite reasonable to argue that an application that is allocated is not the same as the unallocated application, implying that it is OK to change the application model when this happens. One way of dealing with this is to use package merge when specifying the allocation. The package in which the allocation is defined would then import the platform model and merge in the application model, adding allocation dependencies from the application to the platform. This would leave the original models unaffected by those not interested in this particular allocation. I have not thought this all the way through, so there may be flaws in this solution, but I thought I'd throw it into the argument, in case it helps. Cheers...Bran On Mon, Jun 9, 2008 at 5:01 AM, BERNARD, Yves wrote: Hi Darren, According to an "application/platform" approach the simple fact that one of the element involved in the allocation owns this relationship is - by itself - a problem. The application part is the description of the need and, as such, should be "platform independant". The concept of "platform" includes the idea of genericity and reusability and then should not have a dependency - either explicit or implicit - to any specific application even. That's why, from my point of view, the allocations should be considered as an upper layer that shall not be "intrusive" neither in the application model nor in the platform ones. Then we could say (and i do !) that a "product" is defined by the allocation of an application (logical model) over a set of elements provided by a platform (physical model). * About "Wrong ends of Allocate relationship used in Allocated definition" (which is #11501 and not #12146 ;o) ). The current SysML specification is the right one if you considere the actual meaning of a dependency and not only the graphical symbol. A dependency indicates that the element that is pointed by the arrow provides the specification for the element on the opposite side. That's why the former is called "server" and the latter "client". Then, the specifcation is indeed provided (allocated) TO the client and FROM the server. The arrow is in the opposite direction because it indicates the dependency relationship at not the "flow" of information. Best regards, Yves -----Message d'origine---- De : Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com] Envoyé : mercredi 4 juin 2008 23:53 À : BERNARD, Yves Cc : marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : Re: [Issue 11875] About Allocation direction... Hi Yves, This has been identified as a problem with the SysML1.0 Allocate/Allocated, too. (I've CCed some people who have been recently involved in such discussions, and I also caught your recent discussions on the SysML Forum regarding Requirement 'SatisfiedBy-relation'). SysML1.0 15.3.2.2 Allocated(from Allocations): /allocatedTo:NamedElement[*] /allocatedFrom:NamedElement[*] If the dependant element to which other elements are allocated is read-only one has a problem; even though the /allocatedFrom can be computed on-the-fly, the <> can't be applied. Compare with the SysML 16.3.2.3 Requirement: . /satisfiedBy: NamedElement [*] Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier. . /verifiedBy: NamedElement [*] Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier. Since the /satisfiedBy is derived, it can be computed on-the-fly for a readonly-element. From http://school.nomagic.com/node/519: A callout has been used to display the otherwise hidden stereotype, <> on block AlsoAllocatedTo. Note callouts is an extremely useful feature for UML and SysML and all modelling, it offers orthogonal access to nearly any model information, and is of enormous educational value. I am a great fan of callouts. Visit also: http://www.omg.org/issues/sysml-rtf.html#12146 "Wrong ends of Allocate relationship used in Allocated definition" http://school.nomagic.com/node/449 & http://school.nomagic.com/node/451 Includes a detailed analysis of direction in SysML Allocate and the UML2 relationships it builds on regards, Darren -------------------------------------------------------------------------------- There is BTW a precedent for confusion about the direction of relationships where abstraction is involved in a process. The UML2 ComponentRealization subsets are in the opposite sense from the Realization subsets: http://www.omg.org/issues/issue11008.txt "ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation)" http://www.omg.org/issues/issue9119.txt "In a component realization, the direction of the dependency is reversed" There is a detailed analysis of the UML2.1.2 spec of ComponentRealization here, including my "proof" that the UML2 specification self-contradictory on the matter: http://school.nomagic.com/ComponentRealization It seems that one justification for the subset swap in ComponentRealization is to handle read-only module cases like one encounters for allocations. (Even if the "swap is justified", the UML2.1.2 spec is demonstrably unclear.) Glad for feedback on this related matter from ComponentRealization authors/specifiers here. -------------------------------------------------------------------------------- BERNARD, Yves wrote: Hello, >From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! 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 then 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. 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 then 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. Date: Thu, 12 Jun 2008 13:17:44 +0200 From: Julio Medina 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: "BERNARD, Yves" Cc: Bran Selic , Darren R C KELLY , marte-ftf@omg.org, Fredrick A Steiner , Burkhart Roger M , Nerijus Jankevicius Subject: Views and Re: [Issue 11875] About Allocation direction... X-OriginalArrivalTime: 12 Jun 2008 11:19:46.0568 (UTC) FILETIME=[387C6080:01C8CC7E] X-imss-version: 2.051 X-imss-result: Passed X-imss-scanInfo: M:P L:E SM:0 X-imss-tmaseResult: TT:0 TS:0.0000 TC:00 TRN:0 TV:5.5.1026(15966.006) X-imss-scores: Clean:99.90000 C:2 M:3 S:5 R:5 X-imss-settings: Baseline:1 C:1 M:2 S:2 R:2 (0.0000 0.0000) Hi All, Bran, Just a couple of reflections on this subject. A model that represents an application allocated to a platform is "saying" something new, lets say a system. This new thing is neither the application nor the platform, but an expression of "instances" of both. A merge operation that may reflect the new nature of the merged models may be necessary. What is missing probably in this utilization of models is the concept of "model instance". Please do not confuse with the model of instances which deals with whatever the user has modelled inside its particular modelling domain. The usage of this "model instances" shall be consistent with what in any analysis context is meant as a "situation" or concern to evaluate (deal with, reflect, etc.), called a "View" in some cases. In particular each instance of the model may have different "values" (groups of annotations) of the same profile or profiles, leading to different "versions" of the model, each with all its dimensions comprised. A mechanism to represent and store this "annotated model-instances" in a standard way is absolutely necessary to use different (NFP) analysis tools (and probably different techniques) over a common base model (lets say the not-annotated functional model). About now in UML it is possible to "apply" and "de-apply" a profile over a model and have this annotations stored with it, but it is not possible to have a collection (or collections) of different "applications (usages) of a profile" stored with the model. I do not know if this extent is considered a concern in the current practice with SySML, but as far as I see the exploitation of the analysis capabilities of MARTE, it is. I am sorry if I have deviated your attention from the original point you had, but probably in the future conceptualizations of UML these two aspects (model-instances and profile-application-instances) would have to be managed together. Regards, Julio Medina BERNARD, Yves wrote: Yes, i should'nt have use the word "owns", you're right. My point is that no direct dependency shall exist between the application and the platform, no mater who owns them. I 've to analyse your proposition based on model merges. What do you exactly mean when you say that "an application that is allocated is not the same as the unallocated application"? From your point of view, what are the differencies between them : only the allocation relationships or more? In the first case our propositions are very closed, except that you considere that the allocation effect is not "symetric" in a sens where only the application side should be affected. However, i think we could have a similar justification for an "allocated platform". In the second case, do you mean that the application shall be "adapted" to be allocated to the platform? And what about the opposite? Cheers. Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : lundi 9 juin 2008 15:35 À : BERNARD, Yves Cc : Darren R C KELLY; marte-ftf@omg.org; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : Re: [Issue 11875] About Allocation direction... Note that, formally, the allocation dependency is not owned by either its source or destination, but by the package in which it is defined. So, ownership of the allocation dependency is not the issue. The issue is whether or not the application model or the platform model are modified in any way as a result of the application and whether it matters. It is quite reasonable to argue that an application that is allocated is not the same as the unallocated application, implying that it is OK to change the application model when this happens. One way of dealing with this is to use package merge when specifying the allocation. The package in which the allocation is defined would then import the platform model and merge in the application model, adding allocation dependencies from the application to the platform. This would leave the original models unaffected by those not interested in this particular allocation. I have not thought this all the way through, so there may be flaws in this solution, but I thought I'd throw it into the argument, in case it helps. Cheers...Bran On Mon, Jun 9, 2008 at 5:01 AM, BERNARD, Yves > wrote: Hi Darren, According to an "application/platform" approach the simple fact that one of the element involved in the allocation owns this relationship is - by itself - a problem. The application part is the description of the need and, as such, should be "platform independant". The concept of "platform" includes the idea of genericity and reusability and then should not have a dependency - either explicit or implicit - to any specific application even. That's why, from my point of view, the allocations should be considered as an upper layer that shall not be "intrusive" neither in the application model nor in the platform ones. Then we could say (and i do !) that a "product" is defined by the allocation of an application (logical model) over a set of elements provided by a platform (physical model). * About "Wrong ends of Allocate relationship used in Allocated definition" (which is #11501 and not #12146 ;o) ). The current SysML specification is the right one if you considere the actual meaning of a dependency and not only the graphical symbol. A dependency indicates that the element that is pointed by the arrow provides the specification for the element on the opposite side. That's why the former is called "server" and the latter "client". Then, the specifcation is indeed provided (allocated) TO the client and FROM the server. The arrow is in the opposite direction because it indicates the dependency relationship at not the "flow" of information. Best regards, Yves -----Message d'origine---- De : Darren R C KELLY [mailto:drdarrenkelly@nomagicasia.com ] Envoyé : mercredi 4 juin 2008 23:53 À : BERNARD, Yves Cc : marte-ftf@omg.org ; Fredrick A Steiner; Burkhart Roger M; Nerijus Jankevicius Objet : Re: [Issue 11875] About Allocation direction... Hi Yves, This has been identified as a problem with the SysML1.0 Allocate/Allocated, too. (I've CCed some people who have been recently involved in such discussions, and I also caught your recent discussions on the SysML Forum regarding Requirement 'SatisfiedBy-relation'). SysML1.0 15.3.2.2 Allocated(from Allocations): /allocatedTo:NamedElement[*] /allocatedFrom:NamedElement[*] If the dependant element to which other elements are allocated is read-only one has a problem; even though the /allocatedFrom can be computed on-the-fly, the <> can't be applied. Compare with the SysML 16.3.2.3 Requirement: . /satisfiedBy: NamedElement [*] Derived from all elements that are the client of a «satisfy» relationship for which this requirement is a supplier. . /verifiedBy: NamedElement [*] Derived from all elements that are the client of a «verify» relationship for which this requirement is a supplier. Since the /satisfiedBy is derived, it can be computed on-the-fly for a readonly-element. From http://school.nomagic.com/node/519: A callout has been used to display the otherwise hidden stereotype, <> on block AlsoAllocatedTo. Note callouts is an extremely useful feature for UML and SysML and all modelling, it offers orthogonal access to nearly any model information, and is of enormous educational value. I am a great fan of callouts. Visit also: * http://www.omg.org/issues/sysml-rtf.html#12146 "Wrong ends of Allocate relationship used in Allocated definition" * http://school.nomagic.com/node/449 & http://school.nomagic.com/node/451 Includes a detailed analysis of direction in SysML Allocate and the UML2 relationships it builds on regards, Darren ------------------------------------------------------------------------ There is BTW a precedent for confusion about the direction of relationships where abstraction is involved in a process. The UML2 ComponentRealization subsets are in the opposite sense from the Realization subsets : * http://www.omg.org/issues/issue11008.txt "ComponentRealization incorrectly subsets supplier to define realizing Classifiers (implementation)" * http://www.omg.org/issues/issue9119.txt "In a component realization, the direction of the dependency is reversed" There is a detailed analysis of the UML2.1.2 spec of ComponentRealization here, including my "proof" that the UML2 specification self-contradictory on the matter: * http://school.nomagic.com/ComponentRealization It seems that one justification for the subset swap in ComponentRealization is to handle read-only module cases like one encounters for allocations. (Even if the "swap is justified", the UML2.1.2 spec is demonstrably unclear.) Glad for feedback on this related matter from ComponentRealization authors/specifiers here. ------------------------------------------------------------------------ BERNARD, Yves wrote: Hello, From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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. -- Dr Darren R C Kelly, BSc, PhD No Magic Inc., Expert Advisor, Science, Engineering, and Education Phone: +61 (2) 9386 0090 Mobile: +61 (2) 405 029 008 Post: PO Box 1816, Bondi Junction, NSW 1355, Australia Magicdraw UML: Architecture made simple ! 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 then 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. 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 then 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. X-IronPort-AV: E=Sophos;i="4.27,631,1204498800"; d="scan'208";a="13878235" Date: Thu, 12 Jun 2008 15:21:22 +0200 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.14 (Windows/20080421) To: "BERNARD, Yves" Cc: marte-ftf@omg.org, Fredrick A Steiner , Burkhart Roger M , Nerijus Jankevicius , Darren R C KELLY Subject: Re: [Issue 11875] About Allocation direction... Hello Yves, In MARTE Domain View we have insisted on the duality Allocation/Refinement. In my view, at some point the application and execution platform are independent (Platform-Independent Model - PIM). Then you have to refine each of them separately so they can match. At the end of the refinement, you get a platform-specific model (PSM) and you can allocate the application on the execution platform. When we perform the allocation we give cost values (time, power consumption budgets). These costs affects the application analysis, which can be very different for different allocations. Even though we chose Dependency to be compliant with SysML, it does not seem a bad idea. Using the refinement relationship is a soft way to do a "merge" while still keeping the different refinement levels separate. However I agree with you when you say that allocation is neither part of the application nor part of the execution platform. This should be clear with Fig 12.7, where you have three separate models and allocation comes as an orthogonal mechanism. Concerning, the use of classes to represent allocations (as raised by Sébastien), using Class is always an alternative. You can represent anything with classes. But classes are very complex in UML (due to the numerous package merges) and it is difficult to anticipate consequences. Finally, concerning the read-only problem raised by Darren. I am not sure this is really a problem unless I misunderstood his point or unless it is an implementation specific problem. The "/allocatedTo" and "/allocatedFrom" properties are owned by the stereotype, not the stereotyped element. In the repository itself, changing an allocation should have no direct effect at all neither on the clients nor on the suppliers. It only change the stereotype "instances", which have no reason to be "read_only". In the end, I do not think any of this has to do with "Allocation direction". There really was an inconsistence in the specification (In MARTE and SysML). Whatever the choosen direction convention, some part of the text was saying the contrary of the previous part. See resolutions for details. We can have a different issue(s) for the interesting questions raised in this discussion. Regards, Frédéric Mallet. BERNARD, Yves a écrit : Hello, From my point of view the main issue is that using a simple Dependency to model an allocation relationship simply doesn't match with the allocation concept MARTE defines in its "Domain view", §12.2. In this domain view, it's clear that creating an allocation doesn't create any dependency between allocation ends, what is actually what we need in MDA like approaches where the application is considered to be independant of the platform. However, the official definition of the UML "Dependency" metaclass states that : "A dependency is a relationship that signifies that a single or a set of model elements requires other model elements for their specification or implementation. " (formal/2007-11-02 , §7.3.12, p62) Then, I suggest to change the UML reprensentation of the allocation concept so that it really complies to the domain view, that is : if an element of one end of the allocation is modified only the allocation itself should be impacted and not the elements(s) on the other end. Best regards, Yves BERNARD Avionic Engineering Research Leader AIRBUS France EDYYAI - Engineering, PM & Avionics Research Phone: 33 (0)5 67 19 45 32 Fax: 33 (0)5 61 93 08 83 The information in this e-mail is confidential. The contents may not be disclosed or used by anyone other then 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:received:message-id:date:from:to :subject:cc:in-reply-to:mime-version:content-type:references; bh=74ml5EH6E/b0c2QgSOF2KBkCrqn2H8qPIVqmFTaQr+Q=; b=VOBWWj//zqCmN77egsdO4G8bnQYBESCYjIGk77Pki+oTdzbO12sfpwfhKcUoGrfmpa TNTWKgXsI66bogzpsXfSdf2qvAp42bonk3yt3T57i9XU9RLC9iSRmdofkElI7zmNswce lqfoYgpa0TLCmM7mIkBiJAjsFTa9sYYNCzbLY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:cc:in-reply-to:mime-version :content-type:references; b=qjtNYZhUqXu24/7XgVhIdovCe7CgWqruEbuDzgaubaRbXD8G6gza7CMlCTnXfdfRRB yFusLbxnJSOpqvY+9bz4MsvfYGTFlhvcaNnysonUvFkpy0CBP/WPEQmDBVAAojtj0f2t DHuySU+ZJS1cTpY65E7RgR+78nzKAElwTxOzc= Date: Sat, 14 Jun 2008 21:16:06 -0400 From: "Bran Selic" To: "Julio Medina" Subject: Re: Views and Re: [Issue 11875] About Allocation direction... Cc: "BERNARD, Yves" , "Darren R C KELLY" , marte-ftf@omg.org, "Fredrick A Steiner" , "Burkhart Roger M" , "Nerijus Jankevicius" Thanks, Julio. Further comments below: On Thu, Jun 12, 2008 at 7:17 AM, Julio Medina wrote: Hi All, Bran, Just a couple of reflections on this subject. A model that represents an application allocated to a platform is "saying" something new, lets say a system. This new thing is neither the application nor the platform, but an expression of "instances" of both. Excellent point, Julio. In fact, this is probably best represented by a collaboration (or instance model -- although I don't like those), that contains roles comprising parts of the application model and the platform with allocations between them A merge operation that may reflect the new nature of the merged models may be necessary. I don't think any more that it is necessary. What is missing probably in this utilization of models is the concept of "model instance". Please do not confuse with the model of instances which deals with whatever the user has modelled inside its particular modelling domain. I don't think that anything is missing -- see comment above. The usage of this "model instances" shall be consistent with what in any analysis context is meant as a "situation" or concern to evaluate (deal with, reflect, etc.), called a "View" in some cases. In particular each instance of the model may have different "values" (groups of annotations) of the same profile or profiles, leading to different "versions" of the model, each with all its dimensions comprised. In SPT analysis contexts were represented by collaborations. I see no reason why we would do it differently. Cheers...Bran