Issue 13126: using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines (marte-ftf) Source: (, ) Nature: Revision Severity: Significant Summary: From my point of view using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines in its "Domain view", §11.2, p117. According to 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 applications and plateforms are considered to be independant. 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, unchanged in v2.2 beta 1) Then, I suggest to change the UML representation 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. It's can be achieved, for instance, by the specialization of the Classifier metaclass, instead of the Dependency metaclass Resolution: Allocation is meant to be very general. Application elements are allocated to an execution platform (software or hardware), functionality is allocated to processes, processes are allocated to a virtual machine, and resources may be allocated to resource pools, just for some examples. What allocation is doing in these cases is imposing structure on a less structured system. For generality, alternative allocations should be possible. If only a single allocation is possible then the potential of MDE is thrown away. In particular, allocation does not always imply a dependency. Moreover, when a dependency is created, the client of this dependency is modified to refer to the dependency. This can be a problem when allocating read_only elements. The metaclasses Relationship or DirectedRelationship fit better. However, these metaclasses are abstract and there is currently no concrete specialization in UML that would not induced a specific semantics compatible with the broad acception of allocation intended in MARTE. Consequently, the issue should be solved in UML by introducing a new metaclass. It should be discussed with the SysML community given the relationship explicitly stated in the MARTE specification between the MARTE allocation and its SysML counterpart. However, to have an short term solution, we have decided to propose something that is not entirely satisfactory but would work with read_only elements, be usable in very general cases, require few tool adaptations and would have a minimal impact on SysML, with which we want to maintain compatibilities. This is done by adding the stereotype Assign that extends the metaclass Comment, while preserving the stereotype Allocate to maintain compatibility with the current SysML approach. The Assign stereotype is an alternative UML representation of the Allocation metaclass, defined in the domain model, but without the underlying semantics of the Abstraction metaclass. Note that the optional body property of the Comment meta-class can be used to provide the justification of the assignment Revised Text: see ptc/2009-05-12 pages 329 - 333 Actions taken: November 26, 2008: received issue October 16, 2009: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 26 Nov 2008 06:07:47 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Yves BERNARD Company: Airbus mailFrom: yves.bernard@airbus.com Notification: Yes Specification: A UML Profile for MARTE Section: 11.3 FormalNumber: ptc/2008-06-09 Version: Beta 2 RevisionDate: June 2008 Page: 118-121 Nature: Revision Severity: Significant HTTP User Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727) Description From my point of view using a simple Dependency to model an allocation relationship doesn't match with the allocation concept MARTE defines in its "Domain view", §11.2, p117. According to 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 applications and plateforms are considered to be independant. 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, unchanged in v2.2 beta 1) Then, I suggest to change the UML representation 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. It's can be achieved, for instance, by the specialization of the Classifier metaclass, instead of the Dependency metaclass. X-IronPort-AV: E=Sophos;i="4.33,749,1220220000"; d="scan'208";a="20209895" Date: Thu, 11 Dec 2008 01:02:56 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: marte-ftf@omg.org CC: "BERNARD, Yves" Subject: [alloc_wg] Issue 13126 Hi alloc_wg, We agreed during MARTE FTF that we do not need to stick to SysML allocation at all costs and we also agreed that an allocation was not a dependency (and consequently not an Abstraction). -Several possibilities : 1. modify the stereotype Allocation to extend Relationship instead of Abstraction. 2. modify the stereotype Allocation to extend Class instead of Abstraction and enforce with OCL constraints the use of dependencies from the extended class and the allocated elements. In that case, how to tell the suppliers from the customers. 3. Use a ClassAssociation 4. On the model of ClassAssociation, invent something that does not exist in UML that is between Class and Dependency (a DependencyClass) 5. Use a composite structure or a Collaboration to represent the allocation. Then we do not need a specific stereotype any longer and we rather need a methodological note to explain how to denote an allocation with a Collaboration. In any cases, we need to propose a graphical notation for the allocation because one of the good point in SysML allocation is that it is intuitive, simple and easy to use. If we end up in a very complex mechanism nobody will even want to use it and people will turn to SysML to deal with the allocation. So whoever has a proposition is welcome to show it to us so we can assess pros and cons. Regards, Frédéric. Subject: Re: [alloc_wg] Issue 13126 From: Pierre Boulet To: Frederic Mallet Cc: marte-ftf@omg.org, "BERNARD, Yves" Organization: LIFL - USTL Date: Thu, 11 Dec 2008 10:23:47 +0100 X-Mailer: Evolution 2.24.2 X-Greylist: Sender DNS name whitelisted, not delayed by milter-greylist-2.0.2 (mx1.univ-lille1.fr [193.49.225.19]); Thu, 11 Dec 2008 10:23:55 +0100 (CET) X-USTL-MailScanner-Information: Please contact the ISP for more information X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: pierre.boulet@lifl.fr X-Spam-Status: No Hi all, please remember that the RSM annex extends the allocation... We will discuss it internaly and comment on this question in a few days. The current solution suits us quite well but some of the proposals of Frédéric could be as convenient. Regards, Pierre. Le jeudi 11 décembre 2008 à 01:02 +0100, Frederic Mallet a écrit : Hi alloc_wg, We agreed during MARTE FTF that we do not need to stick to SysML allocation at all costs and we also agreed that an allocation was not a dependency (and consequently not an Abstraction). -Several possibilities : 1. modify the stereotype Allocation to extend Relationship instead of Abstraction. 2. modify the stereotype Allocation to extend Class instead of Abstraction and enforce with OCL constraints the use of dependencies from the extended class and the allocated elements. In that case, how to tell the suppliers from the customers. 3. Use a ClassAssociation 4. On the model of ClassAssociation, invent something that does not exist in UML that is between Class and Dependency (a DependencyClass) 5. Use a composite structure or a Collaboration to represent the allocation. Then we do not need a specific stereotype any longer and we rather need a methodological note to explain how to denote an allocation with a Collaboration. In any cases, we need to propose a graphical notation for the allocation because one of the good point in SysML allocation is that it is intuitive, simple and easy to use. If we end up in a very complex mechanism nobody will even want to use it and people will turn to SysML to deal with the allocation. So whoever has a proposition is welcome to show it to us so we can assess pros and cons. Regards, Frédéric. -- Pr. Pierre Boulet +33 609081811 smime1.p7s X-IronPort-AV: E=Sophos;i="4.36,206,1228086000"; d="scan'208";a="18332899" Date: Thu, 11 Dec 2008 20:39:11 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Bran Selic CC: marte-ftf@omg.org, "BERNARD, Yves" Subject: Re: [alloc_wg] Issue 13126 Hi Bran, I was actually pushing for not diverging from SysML because the main reason why MARTE allocation is what it is comes from previous commitments to converge with SysML. The reason for not considering the allocation as a dependency is that we want to consider ways to define several possible allocations of the same application to different execution platforms and have different applications allocated separately to the same execution platform. So, fundamentally the application and the execution platform are independent since a change in the execution platform should not impact the applications allocated but only the way there are allocated (the allocation itself). However, the execution cost or even the ability to execute the application highly depends on the execution platform. If we define allocations separately we should be able to combine them in something like an allocation context where all non functional properties are put together and are available for analysis. Concerning the convergence with SysML, Sébastien(s) have presented the lambda project to the SysML DSIG and we have put a slide in the presentation specifically about the allocation. SysML guys did agree on the interest of MARTE proposal on the need to work on the allocation to make it more powerful. We have to think about a way to make these changes in a non disruptive manner. However, if we are to do something about allocation, we probably need to do it by the end of the FTF, before tool vendors start to implement anything. Since the agenda is the same for MARTE FTF and SysML RTF we should try to have an agreement in both communities. My e-mail intent was just to launch the discussion. I surely do not claim to have a solution and we should listen to possible improvements and see their benefits before dismissing them. If no solution is proposed then we will keep as it is with all the drawbacks. Frédéric. Bran Selic a écrit : I am curious why you decided that allocation was not a dependency. In the old SPT profile we first decided to model deployment using a dependency because the software is definitely dependent on the hardware for its execution. Second, we then chose to use abstraction because (1) the software could be viewed as an abstraction of the underlying hardware that realizes it (ultimately, the only thing that has real physical existence is hardware) and (2) in UML the Abstraction concept comes with a convenient "mapping" attribute, which can be used to specify various tecnical details of deployment. However, of much more concern to me is that this decision increases the divergence between SysML and MARTE and I believe quite strongly that we should be headed in the opposite direction -- even if it comes at the expense of some loss of expressive power (which I doubt). If we want MARTE to be used, we must make some pragmatic decisions that have to do with making it less troublesome. Since I fully expect people to use SysML and MARTE together, any divergence between them will cause problems that may encourage users to choose one or the other but not both. So, if the reason for this decision is based on some theological subtlety about the interpretation of "dependency" or "abstraction" (which are defned vaguely enough in UML that it is practically meaningless to discuss such refined subtleties), I strongly urge you to reconsider. If, OTOH, there are other reasons for this, I am interested to know what they are. Cheers...Bran On Wed, Dec 10, 2008 at 7:02 PM, Frederic Mallet > wrote: Hi alloc_wg, We agreed during MARTE FTF that we do not need to stick to SysML allocation at all costs and we also agreed that an allocation was not a dependency (and consequently not an Abstraction). -Several possibilities : 1. modify the stereotype Allocation to extend Relationship instead of Abstraction. 2. modify the stereotype Allocation to extend Class instead of Abstraction and enforce with OCL constraints the use of dependencies from the extended class and the allocated elements. In that case, how to tell the suppliers from the customers. 3. Use a ClassAssociation 4. On the model of ClassAssociation, invent something that does not exist in UML that is between Class and Dependency (a DependencyClass) 5. Use a composite structure or a Collaboration to represent the allocation. Then we do not need a specific stereotype any longer and we rather need a methodological note to explain how to denote an allocation with a Collaboration. In any cases, we need to propose a graphical notation for the allocation because one of the good point in SysML allocation is that it is intuitive, simple and easy to use. If we end up in a very complex mechanism nobody will even want to use it and people will turn to SysML to deal with the allocation. So whoever has a proposition is welcome to show it to us so we can assess pros and cons. Regards, Frédéric. Subject: RE: [alloc_wg] Issue 13126 Date: Fri, 12 Dec 2008 12:26:45 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: [alloc_wg] Issue 13126 thread-index: AclbXR4pgyZj/3OiTxuX3cDkJ+UWzQA34sWA From: "BERNARD, Yves" To: "Bran Selic" , "Frederic Mallet" Cc: X-OriginalArrivalTime: 12 Dec 2008 11:26:46.0172 (UTC) FILETIME=[842F1DC0:01C95C4C] Hello Bran, May be I can say few words about it because I'm guilty for having initiate this request, I'm afraid... ;o) The first point is that we the relationships we need cannot be limited to the hardware/software allocation but should must be more generic to deal with the logical vs physical allocation. Let's consider that, according to the EIA-632, a physical solution is one concrete realization (among others) of a logical solution. There is no justification to make the element of the logical solution dependent from the element of the physical one. We could even say that the dependency (if any) should be in the opposite direction. On the other hand, most of the time, elements that will be assembled to build the physical solution have been designed before "our" logical solution. Then, obviously, we cannot say that those physical elements depend on the logical ones. Note that this not only a dialectical issue: in the industrial context, models are shared between several developpers who need to work concurrently on distinct parts. That "teamwork" should be organized according to the dependencies between the miscellaneous parts of the models. The reason is that: "a dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements" (ptc/2008-05-05 , p63). More, creating artificial dependencies on the elements of the physical solution might have the undesirable side effect to imply the physical design to precede the logical design what is the opposite of the EIA-632 recommendation. In the real world we first try to think about a logical solution (or at least we should...), then we investigate to know if this logical solution can be implemented according to the state of the art of the technology and to various other constraints. The more the targeted system is simple and the more designer is experienced, the more he can do it in his mind but I believe the process is always the same. For each abstract element of the logical solution we try to find in a concrete element that can play the same role. We're looking for a kind of mapping: it has nothing to do with dependency. It "matches" or it doesn't match. Possibly we build new concrete elements to match. Possibly we modify our logical solution to (re)use existing concrete components. Then if any modification is made either on the logical or on the physical elements, it's not the element(s) on the other side of the allocation that should first be impacted, but the "mapping": the allocation itself. Cheers, Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : jeudi 11 décembre 2008 07:53 À : Frederic Mallet Cc : marte-ftf@omg.org; BERNARD, Yves Objet : Re: [alloc_wg] Issue 13126 I am curious why you decided that allocation was not a dependency. In the old SPT profile we first decided to model deployment using a dependency because the software is definitely dependent on the hardware for its execution. Second, we then chose to use abstraction because (1) the software could be viewed as an abstraction of the underlying hardware that realizes it (ultimately, the only thing that has real physical existence is hardware) and (2) in UML the Abstraction concept comes with a convenient "mapping" attribute, which can be used to specify various tecnical details of deployment. However, of much more concern to me is that this decision increases the divergence between SysML and MARTE and I believe quite strongly that we should be headed in the opposite direction -- even if it comes at the expense of some loss of expressive power (which I doubt). If we want MARTE to be used, we must make some pragmatic decisions that have to do with making it less troublesome. Since I fully expect people to use SysML and MARTE together, any divergence between them will cause problems that may encourage users to choose one or the other but not both. So, if the reason for this decision is based on some theological subtlety about the interpretation of "dependency" or "abstraction" (which are defned vaguely enough in UML that it is practically meaningless to discuss such refined subtleties), I strongly urge you to reconsider. If, OTOH, there are other reasons for this, I am interested to know what they are. Cheers...Bran On Wed, Dec 10, 2008 at 7:02 PM, Frederic Mallet wrote: Hi alloc_wg, We agreed during MARTE FTF that we do not need to stick to SysML allocation at all costs and we also agreed that an allocation was not a dependency (and consequently not an Abstraction). -Several possibilities : 1. modify the stereotype Allocation to extend Relationship instead of Abstraction. 2. modify the stereotype Allocation to extend Class instead of Abstraction and enforce with OCL constraints the use of dependencies from the extended class and the allocated elements. In that case, how to tell the suppliers from the customers. 3. Use a ClassAssociation 4. On the model of ClassAssociation, invent something that does not exist in UML that is between Class and Dependency (a DependencyClass) 5. Use a composite structure or a Collaboration to represent the allocation. Then we do not need a specific stereotype any longer and we rather need a methodological note to explain how to denote an allocation with a Collaboration. In any cases, we need to propose a graphical notation for the allocation because one of the good point in SysML allocation is that it is intuitive, simple and easy to use. If we end up in a very complex mechanism nobody will even want to use it and people will turn to SysML to deal with the allocation. So whoever has a proposition is welcome to show it to us so we can assess pros and cons. Regards, Frédéric. 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-Orig: [12.43.172.229] X-Authentication-Warning: predictableresponse.com: predicta owned process doing -bs From: "Lonnie VanZandt" To: "'BERNARD, Yves'" , "'Bran Selic'" , "'Frederic Mallet'" Cc: Subject: RE: [alloc_wg] Issue 13126 Date: Fri, 12 Dec 2008 11:24:08 -0700 Organization: Predictable Response Consulting, LLC X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclbXR4pgyZj/3OiTxuX3cDkJ+UWzQA34sWAABH3V6A= Bran, Yves, Nerijus also pointed out a very practical issue with the implementation of Allocation as the addition of a relationship between the source and the target elements: establishing the relationship requires that the source and target elements be modified to add the roles and to add the derived /allocatedTo and /allocatedFrom attributes. However, if either source or target element is a member of a read-only package then one cannot create the Allocation relationship. (I have myself encountered this problem in practice and had to .break. the read-only access in order to establish the allocations I sought.) An independent element with references to the source and target (such as a Class with uni-directional associations to those elements) allows one to express the relationship without modifying either source or target. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, December 12, 2008 4:27 AM To: Bran Selic; Frederic Mallet Cc: marte-ftf@omg.org Subject: RE: [alloc_wg] Issue 13126 Hello Bran, May be I can say few words about it because I'm guilty for having initiate this request, I'm afraid... ;o) The first point is that we the relationships we need cannot be limited to the hardware/software allocation but should must be more generic to deal with the logical vs physical allocation. Let's consider that, according to the EIA-632, a physical solution is one concrete realization (among others) of a logical solution. There is no justification to make the element of the logical solution dependent from the element of the physical one. We could even say that the dependency (if any) should be in the opposite direction. On the other hand, most of the time, elements that will be assembled to build the physical solution have been designed before "our" logical solution. Then, obviously, we cannot say that those physical elements depend on the logical ones. Note that this not only a dialectical issue: in the industrial context, models are shared between several developpers who need to work concurrently on distinct parts. That "teamwork" should be organized according to the dependencies between the miscellaneous parts of the models. The reason is that: "a dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements" (ptc/2008-05-05 , p63). More, creating artificial dependencies on the elements of the physical solution might have the undesirable side effect to imply the physical design to precede the logical design what is the opposite of the EIA-632 recommendation. In the real world we first try to think about a logical solution (or at least we should...), then we investigate to know if this logical solution can be implemented according to the state of the art of the technology and to various other constraints. The more the targeted system is simple and the more designer is experienced, the more he can do it in his mind but I believe the process is always the same. For each abstract element of the logical solution we try to find in a concrete element that can play the same role. We're looking for a kind of mapping: it has nothing to do with dependency. It "matches" or it doesn't match. Possibly we build new concrete elements to match. Possibly we modify our logical solution to (re)use existing concrete components. Then if any modification is made either on the logical or on the physical elements, it's not the element(s) on the other side of the allocation that should first be impacted, but the "mapping": the allocation itself. Cheers, Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : jeudi 11 décembre 2008 07:53 À : Frederic Mallet Cc : marte-ftf@omg.org; BERNARD, Yves Objet : Re: [alloc_wg] Issue 13126 I am curious why you decided that allocation was not a dependency. In the old SPT profile we first decided to model deployment using a dependency because the software is definitely dependent on the hardware for its execution. Second, we then chose to use abstraction because (1) the software could be viewed as an abstraction of the underlying hardware that realizes it (ultimately, the only thing that has real physical existence is hardware) and (2) in UML the Abstraction concept comes with a convenient "mapping" attribute, which can be used to specify various tecnical details of deployment. However, of much more concern to me is that this decision increases the divergence between SysML and MARTE and I believe quite strongly that we should be headed in the opposite direction -- even if it comes at the expense of some loss of expressive power (which I doubt). If we want MARTE to be used, we must make some pragmatic decisions that have to do with making it less troublesome. Since I fully expect people to use SysML and MARTE together, any divergence between them will cause problems that may encourage users to choose one or the other but not both. So, if the reason for this decision is based on some theological subtlety about the interpretation of "dependency" or "abstraction" (which are defned vaguely enough in UML that it is practically meaningless to discuss such refined subtleties), I strongly urge you to reconsider. If, OTOH, there are other reasons for this, I am interested to know what they are. Cheers...Bran On Wed, Dec 10, 2008 at 7:02 PM, Frederic Mallet wrote: Hi alloc_wg, We agreed during MARTE FTF that we do not need to stick to SysML allocation at all costs and we also agreed that an allocation was not a dependency (and consequently not an Abstraction). -Several possibilities : 1. modify the stereotype Allocation to extend Relationship instead of Abstraction. 2. modify the stereotype Allocation to extend Class instead of Abstraction and enforce with OCL constraints the use of dependencies from the extended class and the allocated elements. In that case, how to tell the suppliers from the customers. 3. Use a ClassAssociation 4. On the model of ClassAssociation, invent something that does not exist in UML that is between Class and Dependency (a DependencyClass) 5. Use a composite structure or a Collaboration to represent the allocation. Then we do not need a specific stereotype any longer and we rather need a methodological note to explain how to denote an allocation with a Collaboration. In any cases, we need to propose a graphical notation for the allocation because one of the good point in SysML allocation is that it is intuitive, simple and easy to use. If we end up in a very complex mechanism nobody will even want to use it and people will turn to SysML to deal with the allocation. So whoever has a proposition is welcome to show it to us so we can assess pros and cons. Regards, Frédéric. 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.36,212,1228086000"; d="scan'208";a="18385884" Date: Fri, 12 Dec 2008 20:19:36 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.18 (Windows/20081105) To: Lonnie VanZandt CC: "'BERNARD, Yves'" , "'Bran Selic'" , marte-ftf@omg.org Subject: Re: [alloc_wg] Issue 13126 Lonnie VanZandt a écrit : Bran, Yves, Nerijus also pointed out a very practical issue with the implementation of Allocation as the addition of a relationship between the source and the target elements: establishing the relationship requires that the source and target elements be modified to add the roles and to add the derived /allocatedTo and /allocatedFrom attributes. However, if either source or target element is a member of a read-only package then one cannot create the Allocation relationship. (I have myself encountered this problem in practice and had to .break. the read-only access in order to establish the allocations I sought.) I think this is both a methological and tool implementation point of view (that does not mean to me that it is not or less important). - Concerning the implementation view: with Eclipse-based implementations, applying a stereotype to an element does not modify the element itself and the annotation is put separately in the repository. NoMagic and possibly Artisan SW seems to have made other choices. I do not think this is precisely defined in the UML specification itself. - Concerning the methological view: If instead of allocating the actual element, you use composite structure diagrams then when the allocation is performed only the part is affected and not the actual element. This is also a solution to solve the dependency problem. If we can enforce the use of composite structure or usages (or instances?) when applying allocations then only the usage or the part would be dependent or modified and not the actual application or platform. Frederic. X-Orig: 71-215-75-131.hlrn.qwest.net [71.215.75.131] X-Authentication-Warning: predictableresponse.com: predicta owned process doing -bs From: "Lonnie VanZandt" To: "'Frederic Mallet'" Cc: "'BERNARD, Yves'" , "'Bran Selic'" , Subject: RE: [alloc_wg] Issue 13126 Date: Sat, 13 Dec 2008 15:17:25 -0700 Organization: Predictable Response Consulting, LLC X-Mailer: Microsoft Office Outlook 12.0 Thread-Index: AclcjpV+BUArOLFhRReiJwsDFg49UAAB6sgA X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id mBDMGvd4016461 However, the stereotype extends a Dependency Association Relationship and the construction of that element, prior to application of the Alloc stereotype does modify the source and target elements. Yes? Also, a Composite Structure Diagram would require that the target Class/Block have the source Class/Block as a Part property. Do you mean a Collaboration Diagram where the interactions of Instances are modeled? -----Original Message----- From: Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Sent: Friday, December 12, 2008 12:20 PM To: Lonnie VanZandt Cc: 'BERNARD, Yves'; 'Bran Selic'; marte-ftf@omg.org Subject: Re: [alloc_wg] Issue 13126 Lonnie VanZandt a écrit : > > Bran, Yves, > > Nerijus also pointed out a very practical issue with the > implementation of Allocation as the addition of a relationship between > the source and the target elements: establishing the relationship > requires that the source and target elements be modified to add the > roles and to add the derived /allocatedTo and /allocatedFrom > attributes. However, if either source or target element is a member of > a read-only package then one cannot create the Allocation > relationship. (I have myself encountered this problem in practice and > had to .break. the read-only access in order to establish the > allocations I sought.) > I think this is both a methological and tool implementation point of view (that does not mean to me that it is not or less important). - Concerning the implementation view: with Eclipse-based implementations, applying a stereotype to an element does not modify the element itself and the annotation is put separately in the repository. NoMagic and possibly Artisan SW seems to have made other choices. I do not think this is precisely defined in the UML specification itself. - Concerning the methological view: If instead of allocating the actual element, you use composite structure diagrams then when the allocation is performed only the part is affected and not the actual element. This is also a solution to solve the dependency problem. If we can enforce the use of composite structure or usages (or instances?) when applying allocations then only the usage or the part would be dependent or modified and not the actual application or platform. Frederic. 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=zDBzvMMQes6l/RyHfCPhcedOjdjB5LVNfhbZBYgs4i0=; b=qx+HGGqPwzVcQMcp03Fr9wjM1HSwZi+HmCCrvySngvP1ioFBy4+ASVr17Xu8FeipCp iqYC9xCdz/3ixhGulJBc7F5je81K+JEJt3cxQSykEV49PSpcBj6keHPYlQwWvDYPw89F y4fG5my5VsMrW/sIziG5gI41Ey92baFh7B22o= 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=V8Q8lJPg70BQi0Jl6Povw955614zTaxatzedk4180kLFfpOQo0prZ2tcfDFdn1Fuve H1lckXkgnxI2Rqg1LwAptKC3XsjfG14ZQWgBiY21l8xeakSu6QMlaARY1tta1ukEbj23 L2thTKwLS/0ADLcRfqNEzD9di7EIcn+B/zHKo= Date: Sun, 14 Dec 2008 09:18:17 -0500 From: "Bran Selic" To: "Lonnie VanZandt" Subject: Re: [alloc_wg] Issue 13126 Cc: "BERNARD, Yves" , "Frederic Mallet" , marte-ftf@omg.org Thank you, gentlemen, for your feedback. Still, I am not sure I agree with the arguments raised. The practical problem that Nerijus has raised is a general UML problem that was recognized before and there is an issue in the UML list that raises this very point. The problem needs to be fixed in UML and having the MARTE FTF propose a solution to the UML RTF, will help everyone. Yves' point, on the other hand, seems to hinge on a very specific (and very precise) interpretation of the semantics of UML Dependency. However, as I said before, the current semantics of Dependency are much broader than that and, as far as I am concerned, leave a lot of leeway for interpretation (an unfortunate characteristic of much of UML). Cheers...Bran On Fri, Dec 12, 2008 at 1:24 PM, Lonnie VanZandt wrote: Bran, Yves, Nerijus also pointed out a very practical issue with the implementation of Allocation as the addition of a relationship between the source and the target elements: establishing the relationship requires that the source and target elements be modified to add the roles and to add the derived /allocatedTo and /allocatedFrom attributes. However, if either source or target element is a member of a read-only package then one cannot create the Allocation relationship. (I have myself encountered this problem in practice and had to "break" the read-only access in order to establish the allocations I sought.) An independent element with references to the source and target (such as a Class with uni-directional associations to those elements) allows one to express the relationship without modifying either source or target. From: BERNARD, Yves [mailto:Yves.Bernard@airbus.com] Sent: Friday, December 12, 2008 4:27 AM To: Bran Selic; Frederic Mallet Cc: marte-ftf@omg.org Subject: RE: [alloc_wg] Issue 13126 Hello Bran, May be I can say few words about it because I'm guilty for having initiate this request, I'm afraid... ;o) The first point is that we the relationships we need cannot be limited to the hardware/software allocation but should must be more generic to deal with the logical vs physical allocation. Let's consider that, according to the EIA-632, a physical solution is one concrete realization (among others) of a logical solution. There is no justification to make the element of the logical solution dependent from the element of the physical one. We could even say that the dependency (if any) should be in the opposite direction. On the other hand, most of the time, elements that will be assembled to build the physical solution have been designed before "our" logical solution. Then, obviously, we cannot say that those physical elements depend on the logical ones. Note that this not only a dialectical issue: in the industrial context, models are shared between several developpers who need to work concurrently on distinct parts. That "teamwork" should be organized according to the dependencies between the miscellaneous parts of the models. The reason is that: "a dependency signifies a supplier/client relationship between model elements where the modification of the supplier may impact the client model elements" (ptc/2008-05-05 , p63). More, creating artificial dependencies on the elements of the physical solution might have the undesirable side effect to imply the physical design to precede the logical design what is the opposite of the EIA-632 recommendation. In the real world we first try to think about a logical solution (or at least we should...), then we investigate to know if this logical solution can be implemented according to the state of the art of the technology and to various other constraints. The more the targeted system is simple and the more designer is experienced, the more he can do it in his mind but I believe the process is always the same. For each abstract element of the logical solution we try to find in a concrete element that can play the same role. We're looking for a kind of mapping: it has nothing to do with dependency. It "matches" or it doesn't match. Possibly we build new concrete elements to match. Possibly we modify our logical solution to (re)use existing concrete components. Then if any modification is made either on the logical or on the physical elements, it's not the element(s) on the other side of the allocation that should first be impacted, but the "mapping": the allocation itself. Cheers, Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : jeudi 11 décembre 2008 07:53 À : Frederic Mallet Cc : marte-ftf@omg.org; BERNARD, Yves Objet : Re: [alloc_wg] Issue 13126 I am curious why you decided that allocation was not a dependency. In the old SPT profile we first decided to model deployment using a dependency because the software is definitely dependent on the hardware for its execution. Second, we then chose to use abstraction because (1) the software could be viewed as an abstraction of the underlying hardware that realizes it (ultimately, the only thing that has real physical existence is hardware) and (2) in UML the Abstraction concept comes with a convenient "mapping" attribute, which can be used to specify various tecnical details of deployment. However, of much more concern to me is that this decision increases the divergence between SysML and MARTE and I believe quite strongly that we should be headed in the opposite direction -- even if it comes at the expense of some loss of expressive power (which I doubt). If we want MARTE to be used, we must make some pragmatic decisions that have to do with making it less troublesome. Since I fully expect people to use SysML and MARTE together, any divergence between them will cause problems that may encourage users to choose one or the other but not both. So, if the reason for this decision is based on some theological subtlety about the interpretation of "dependency" or "abstraction" (which are defned vaguely enough in UML that it is practically meaningless to discuss such refined subtleties), I strongly urge you to reconsider. If, OTOH, there are other reasons for this, I am interested to know what they are. Cheers...Bran On Wed, Dec 10, 2008 at 7:02 PM, Frederic Mallet wrote: Hi alloc_wg, We agreed during MARTE FTF that we do not need to stick to SysML allocation at all costs and we also agreed that an allocation was not a dependency (and consequently not an Abstraction). -Several possibilities : 1. modify the stereotype Allocation to extend Relationship instead of Abstraction. 2. modify the stereotype Allocation to extend Class instead of Abstraction and enforce with OCL constraints the use of dependencies from the extended class and the allocated elements. In that case, how to tell the suppliers from the customers. 3. Use a ClassAssociation 4. On the model of ClassAssociation, invent something that does not exist in UML that is between Class and Dependency (a DependencyClass) 5. Use a composite structure or a Collaboration to represent the allocation. Then we do not need a specific stereotype any longer and we rather need a methodological note to explain how to denote an allocation with a Collaboration. In any cases, we need to propose a graphical notation for the allocation because one of the good point in SysML allocation is that it is intuitive, simple and easy to use. If we end up in a very complex mechanism nobody will even want to use it and people will turn to SysML to deal with the allocation. So whoever has a proposition is welcome to show it to us so we can assess pros and cons. Regards, Frédéric. 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:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=yfcE4T+QM/K6altIM1W5MGDHkfhxB59AxSmxbcRyOOE=; b=LYfxnxu7MaRGoqrOu3TioEcNE6/65OvrrXlFhtzLhKEr4MYk1OrBfSANu6ZeS6zeSl j+nwIBzZGttNYXRjZQDRWH2CQjKSmNhgoQyBpykhXgbN1XNzB+3iUJzDbS6aJDoscwx0 GBp0PjhQOSn6hZAvuyXtjnPL1rJs4iZp2cpQ0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=AVzJ+5355JqixG+K6ADXxkjsUVaQqB+ZKrc9le2aaRgYwoX30IpdIfg7M/dOL+3+Xn bRfUGl7zAT9rdlVfFpsnfAoh613IykdzDkpHHnmC+W6rhpAQ5KZuJObDAI2c14W66Ju4 yfZrp7LUgGm0nwIg2yDCRn46wlre+psqALa1I= Date: Tue, 3 Mar 2009 18:24:12 -0500 Subject: Re: [alloc_wg] Issue 13126 From: Bran Selic To: Frederic Mallet Cc: marte-ftf Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=fhtHL1f2JIrPFa14ITqjjLPeQfaT0WxbNScnH4B103CdV46qkZVm5SiJXr0k+EUHk9rSrt9RIxqEoUe3SFwGW8OlvFRgjiViYFT+wzdYZEj4EfeyYkP9W4gS/fZn9IutIevejoAIB1AOUVIFtodLmQVWPk2QtspyWVJ38VdCkgo=; X-YMail-OSG: sv74_F8VM1mgKOxBiUwMkUABU6QhFgNgR_7xcf_hP60Dm6eLK6j6sidCCdeAkzdCpmBR1uuwfaQT7QWSVPZcpd.poqOtOEGZXCst5xc6A3ldAWJp5lrRUiKUkS_O5t3eyyAWJNzwt7BcE_2ZBBXINxs.BeqALNIIulFIv7N3z0vNvSe5xlhvcffYh4VYXyhaJJG4ehDIPzOJI40yAzHHg9Q5xIzHXXI0AotgItH88mTnpCxfwZsaZ6reuWGf1I0rmkvujRX.713rDIM- X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Tue, 3 Mar 2009 16:14:49 -0800 (PST) From: Mark Gerhardt Subject: Re: [alloc_wg] Issue 13126 To: Bran Selic , Frederic Mallet Cc: marte-ftf , Peter Kortmann Peter Kortmann and I have been discussing allocation and related topics very recently. The consequence of an allocation of an executing task instance to a CPU platform introduces a dependency of its execution time upon the CPU clock speed and memory size. Any constraints upon the task execution instance like deadline, for example, indirectly and partially constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the isolation between platform and application but are part of a relevant performance-oriented decomposition allocation process. In this sense allocation is really implementation binding rather than partial assignment of the total constraints. Since OMG and the MARTE document both strive for method and design process independence, it seems inappropriate to become immersed in the complexity of this set of allocation-related issues. Comments? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 -------------------------------------------------------------------------------- From: Bran Selic To: Frederic Mallet Cc: marte-ftf Sent: Tuesday, March 3, 2009 3:24:12 PM Subject: Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=trbEYjVkjoZLWsGZ3OcRkVJkS+sATYZKNCfiNgEBb0s=; b=dB2F1XItOnN22DfnaCUCc0JiztEyr8yPgxGl5YuJZgNIvFBmVRHNu9rACMfHaISxby SlGOcv7uhxHIPSYRl99QMbgK3JYnkt6/S6Drk5pHj6PS1wZUzr8G81amTzQ7gXnewkkk /PTr4AwxpYxS+K7WtjI+Qp1Y1Vy4eHIqgj60I= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=q6dnl+Sti47TdawVjAyAJYI0/PTT7L86tuWP8QYwupczWaYWdh1YAIAsWLYjvcPbID UZ35bnVh/N4F6Kf47c9fNVsnca1Vr9Ay1dwAkR76WJ+h7w5PcMEOKWCIKnoE+lLtf7/1 IoTk78aJQl08nNBAjNLsaLjRxReWTCw3mA5rE= Date: Tue, 3 Mar 2009 19:59:47 -0500 Subject: Re: [alloc_wg] Issue 13126 From: Bran Selic To: Mark Gerhardt Cc: Frederic Mallet , marte-ftf , Peter Kortmann Thanks, Mark. I agree that the platform imposes constraints on the software that it runs and it is quite important to design with these in mind in many cases. In fact, I have written and published a number of papers precisely on this topic and with that very message. (In fact, I really detest the term PIM for that reason. However, a PIM is not something that is normally allocated to a platform anyway, that should be either the PSM or the software itself.) However, my concern was that using Constraint to model allocation is really a stretch. You may specify explicit constraints on both the platform and the application model, but I don't think you should do this using the allocation concept. These constraints should be defined independently of any allocation. I am not sure if this addresses any of your points, though. Cheers..Bran On Tue, Mar 3, 2009 at 7:14 PM, Mark Gerhardt wrote: Peter Kortmann and I have been discussing allocation and related topics very recently. The consequence of an allocation of an executing task instance to a CPU platform introduces a dependency of its execution time upon the CPU clock speed and memory size. Any constraints upon the task execution instance like deadline, for example, indirectly and partially constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the isolation between platform and application but are part of a relevant performance-oriented decomposition allocation process. In this sense allocation is really implementation binding rather than partial assignment of the total constraints. Since OMG and the MARTE document both strive for method and design process independence, it seems inappropriate to become immersed in the complexity of this set of allocation-related issues. Comments? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 -------------------------------------------------------------------------------- From: Bran Selic To: Frederic Mallet Cc: marte-ftf Sent: Tuesday, March 3, 2009 3:24:12 PM Subject: Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. Subject: RE : [alloc_wg] Issue 13126 Date: Wed, 4 Mar 2009 09:40:26 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alloc_wg] Issue 13126 Thread-Index: AcmcV0lTfuWtvoq5R9WCGHvweg/yDwATIbOF From: "ESPINOZA Huascar 218344" To: "Bran Selic" , "Frederic Mallet" Cc: "marte-ftf" X-OriginalArrivalTime: 04 Mar 2009 08:40:28.0561 (UTC) FILETIME=[DEF00010:01C99CA4] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n248dETQ015766 Hi Bran, Som comments in line below... Huascar ________________________________ De: Bran Selic [mailto:bran.selic@gmail.com] Date: mer. 04/03/2009 00:24 À: Frederic Mallet Cc: marte-ftf Objet : Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. HE--> We definitevely agree. Furthermore, I'd expect to have the same base stereotype (Allocate) in MARTE, including the same attributes. This is not happening now. The MARTE::Allocate includes additional attributes specific to MARTE. I better practice would be to specialize the base concept (if required) for MARTE. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. HE--> From a semantic viewpoint, I agree and was arguing this to the Allocation work group. However, I'm not sure from the syntactic viewpoint. The fact that creating a UML::Dependency automatically creates the information in the Client side, could have some impact, e.g., when the Client side (model) is read-only, and should not be impacted by Allocations. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. HE--> This is the best solution (UML::DirectedRelationship would be better), however this is a question for me. How the UML profile mechanism deals with the extensions of "abstract" metaclasses?? It seems to be not possible! I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=eNLB/CNicWzKWCipcHMFCCIU+ArNI09zt76rZzXjO0U=; b=bSGYToltntlcdqBf+WX9QOATB+w+ZBtxdRT82G7V239/aMT0mapEbPclDxg5PmPUuq XbH3GSYeOmpNT3MY/XRc1FG/0ET91FJ7wNtABghoPym8n6wwC3W8YcBcm3SiSVysTfUf LANAAMbLx6G6KmKVNZMSvLSj0nx9goiXCj7EI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=bFt+kAYO+9VK5T7u8n/Zn8yvbuvrjRosPEygxRODY7tVbXCZoVLABvNRudn751FJi6 Eovp4UTTUKpzwfzNuIv2Ed9s5t00x2ZjifqhXNfKxLuFd48v6SZPZoWQlXfRWGkIxuc5 26TDY+1C0RQwzoR3+D6r4qf/d1hV+1DA93RzA= Date: Wed, 4 Mar 2009 06:46:19 -0500 Subject: Re: RE : [alloc_wg] Issue 13126 From: Bran Selic To: ESPINOZA Huascar 218344 Cc: Frederic Mallet , marte-ftf I don't see why it should not be possible to extend an abstract metaclass. In fact, I seem to recall some stereotypes (I forget in which profiles), tha textend Element. I am almost certain that we used this capability in SPT. The semantics were that it applied to all sub-(meta)classes. However, this may be another issue to clarify with the UML 2 RTF (which, of course, will create a long and indefinite discussion). I still remain unconvinced that Constraint is the best solution. Cheers...Bran On Wed, Mar 4, 2009 at 3:40 AM, ESPINOZA Huascar 218344 wrote: Hi Bran, Som comments in line below... Huascar ________________________________ De: Bran Selic [mailto:bran.selic@gmail.com] Date: mer. 04/03/2009 00:24 À: Frederic Mallet Cc: marte-ftf Objet : Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. HE--> We definitevely agree. Furthermore, I'd expect to have the same base stereotype (Allocate) in MARTE, including the same attributes. This is not happening now. The MARTE::Allocate includes additional attributes specific to MARTE. I better practice would be to specialize the base concept (if required) for MARTE. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. HE--> From a semantic viewpoint, I agree and was arguing this to the Allocation work group. However, I'm not sure from the syntactic viewpoint. The fact that creating a UML::Dependency automatically creates the information in the Client side, could have some impact, e.g., when the Client side (model) is read-only, and should not be impacted by Allocations. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. HE--> This is the best solution (UML::DirectedRelationship would be better), however this is a question for me. How the UML profile mechanism deals with the extensions of "abstract" metaclasses?? It seems to be not possible! I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. Subject: RE: RE : [alloc_wg] Issue 13126 Date: Wed, 4 Mar 2009 13:08:00 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: RE : [alloc_wg] Issue 13126 Thread-Index: AcmcvtZIqUWupeTTQIeYUYQ/4puHuwAAoxtA From: "ESPINOZA Huascar 218344" To: "Bran Selic" Cc: "Frederic Mallet" , "marte-ftf" X-OriginalArrivalTime: 04 Mar 2009 12:08:01.0495 (UTC) FILETIME=[DD76EE70:01C99CC1] I.d say that if the issue of extending abstract metaclasses can be clarified, there is no any issue. Form my point of view, it.s clear for me that DirectedRelationship is the right metaclass to extend. Would we need to ask for clarification in the UML RTF? Thank you, Huascar -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mercredi 4 mars 2009 12:46 À : ESPINOZA Huascar 218344 Cc : Frederic Mallet; marte-ftf Objet : Re: RE : [alloc_wg] Issue 13126 I don't see why it should not be possible to extend an abstract metaclass. In fact, I seem to recall some stereotypes (I forget in which profiles), tha textend Element. I am almost certain that we used this capability in SPT. The semantics were that it applied to all sub-(meta)classes. However, this may be another issue to clarify with the UML 2 RTF (which, of course, will create a long and indefinite discussion). I still remain unconvinced that Constraint is the best solution. Cheers...Bran On Wed, Mar 4, 2009 at 3:40 AM, ESPINOZA Huascar 218344 wrote: Hi Bran, Som comments in line below... Huascar ________________________________ De: Bran Selic [mailto:bran.selic@gmail.com] Date: mer. 04/03/2009 00:24 À: Frederic Mallet Cc: marte-ftf Objet : Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. HE--> We definitevely agree. Furthermore, I'd expect to have the same base stereotype (Allocate) in MARTE, including the same attributes. This is not happening now. The MARTE::Allocate includes additional attributes specific to MARTE. I better practice would be to specialize the base concept (if required) for MARTE. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. HE--> From a semantic viewpoint, I agree and was arguing this to the Allocation work group. However, I'm not sure from the syntactic viewpoint. The fact that creating a UML::Dependency automatically creates the information in the Client side, could have some impact, e.g., when the Client side (model) is read-only, and should not be impacted by Allocations. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. HE--> This is the best solution (UML::DirectedRelationship would be better), however this is a question for me. How the UML profile mechanism deals with the extensions of "abstract" metaclasses?? It seems to be not possible! I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. Subject: RE: [alloc_wg] Issue 13126 Date: Wed, 4 Mar 2009 13:21:44 -0000 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: [alloc_wg] Issue 13126 Thread-Index: AcmcZIv2hmbDBHWoSPWdkEZSM8T4uQAZxRlA From: "Stolz, Marty" To: "Bran Selic" , "Mark Gerhardt" Cc: "Frederic Mallet" , "marte-ftf" , "Peter Kortmann" Hello Everyone, I also share this concern and I spoke to the UPDM group and they told me that they have found a way to reuse profiles and sub profiles to ensure consistency between the different teams. They would be happy to talk with us and show us what they have discovered and implemented. If this sounds like it may be helpful please let me know and I will be glad to set up some times for the meeting during the next OMG meeting. Thanks Marty Marty Stolz Field Engineer Manager T: +01 508 341-4479 F: +44 (0)1242 229 301 marty.stolz@ArtisanSoftwareTools.com www.ArtisanSoftwareTools.com CONFIDENTIAL: The information in this message is confidential and may be legally privileged. It is intended solely for the addressee(s). Access to this message by anyone else is unauthorized. If you are not the intended recipient, any disclosure, copying, or distribution of the message, or any action or omission taken by you in reliance on it, is prohibited and may be unlawful. Please immediately contact the sender if you have received this message in error. Thank you. -------------------------------------------------------------------------------- From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Tuesday, March 03, 2009 8:00 PM To: Mark Gerhardt Cc: Frederic Mallet; marte-ftf; Peter Kortmann Subject: Re: [alloc_wg] Issue 13126 Thanks, Mark. I agree that the platform imposes constraints on the software that it runs and it is quite important to design with these in mind in many cases. In fact, I have written and published a number of papers precisely on this topic and with that very message. (In fact, I really detest the term PIM for that reason. However, a PIM is not something that is normally allocated to a platform anyway, that should be either the PSM or the software itself.) However, my concern was that using Constraint to model allocation is really a stretch. You may specify explicit constraints on both the platform and the application model, but I don't think you should do this using the allocation concept. These constraints should be defined independently of any allocation. I am not sure if this addresses any of your points, though. Cheers..Bran On Tue, Mar 3, 2009 at 7:14 PM, Mark Gerhardt wrote: Peter Kortmann and I have been discussing allocation and related topics very recently. The consequence of an allocation of an executing task instance to a CPU platform introduces a dependency of its execution time upon the CPU clock speed and memory size. Any constraints upon the task execution instance like deadline, for example, indirectly and partially constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the isolation between platform and application but are part of a relevant performance-oriented decomposition allocation process. In this sense allocation is really implementation binding rather than partial assignment of the total constraints. Since OMG and the MARTE document both strive for method and design process independence, it seems inappropriate to become immersed in the complexity of this set of allocation-related issues. Comments? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 -------------------------------------------------------------------------------- From: Bran Selic To: Frederic Mallet Cc: marte-ftf Sent: Tuesday, March 3, 2009 3:24:12 PM Subject: Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. __________ Information from ESET NOD32 Antivirus, version of virus signature database 3906 (20090303) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 3907 (20090304) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com X-IronPort-AV: E=Sophos;i="4.38,301,1233529200"; d="scan'208";a="23846379" Date: Wed, 04 Mar 2009 14:23:10 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: Bran Selic CC: marte-ftf , Yves.Bernard@airbus.com Subject: Re: [alloc_wg] Issue 13126 Bran, Bran Selic a écrit : Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. People were convinced by the proposal. I think mainly because it was doing very little changes, that the constraint had to be here somewhere anyway (because it is implied by the allocation) and because in the end the visual representation would not change. If the discussion is still open, here are a few thoughts: I was about to write a draft resolution, but the discussion is still open, of course. - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. We are very well aware of that, this is why we attempted to reduce the impact as much as possible. Nevertheless, we had thought of several possible solutions and wanted to reduce the possibilities before trying to convince other people. The next step is to discuss with SysML RTF. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. The domain view is supposed to describe that. May be we need to revise it. Here is a summary: - There are two kinds of elements : application and executionPlatform. Some people do not like this terminology but we could not agree on one that was satisfactory for everybody. Some prefer to speak about logical vs. physical. - We want to design both independently with a Y-chart approach. - At a very abstract level, we have on the logical side (application) a PIM and an abstract description of the platform on the other side. For early validations, we need to make an allocation at this stage. - Then, we separately refine each side to get to a stage where we have a PSM and a concrete description of the platform. After each refinement step, we want to refine also the allocation relationship with results from the various analyzes. Even though at the final stages I would agree on having a dependency I think that we do not want to have a dependency at the early stages and definitely not between the PIM and the abstract platform representation. Plus, the dependency modifies the client and at several times (also during SysML RTF) it was mentioned that this was an issue when we try to allocate *read_only* elements. It was also bothering people from Airbus and Zeligsoft. The former have lots of troubles due to that with their dependency analysis tools. The latter attempted to go around by defining a methodology that would reduce the possibilities to use allocation. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. What we agreed on is that the allocation implies constraints that state the cost of the allocation, in terms of time, power, area, ... A first proposition was to use, as a base class for Allocate, something neutral like a Classifier or a Package and build some dependencies from this classifier to the application and to the executionPlatform. That proposition would have required lots of modifications and would have resulted in something heavy to implement, with a very different look that the one everyone expect. We did consider using an Relationship as a base class but we stepped back since in mathematics a (direct) relationship implies a dependency. I must admit that by reading again the UML specification, the UML Relationship (and also DirectedRelationship) seems to be much more general than that since UML explicitly states that it has no semantics at all and no graphical notation. I would strongly urge that this be coordinated with the SysML RTF. Can we agree on the use case I described above (and which is supposed to reflect the domain view of Allocation) within MARTE before involving SysML RTF ? If we end up choosing DirectedRelationship instead of Constraint, then they should not be any problem with SysML. If SysML RTF does not want to modify allocation, their allocation would just be more specific than MARTE allocation. I hope we can converge before the 14th so we can add a resolution in the last ballot. I do not think there is any urgency for the SysML agenda since, the SysML 2 in under way. Frédéric. X-IronPort-AV: E=Sophos;i="4.38,301,1233529200"; d="scan'208";a="23846921" Date: Wed, 04 Mar 2009 14:32:22 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: Bran Selic CC: ESPINOZA Huascar 218344 , marte-ftf Subject: Re: RE : [alloc_wg] Issue 13126 I totally agree that there is no problem to extend an abstract metaclass. However, when in the end you need to apply the stereotype, you need to find a element (instance of concrete metaclass). If we choose DirectedRelationship as a base class. Then we can apply the stereotype "Allocate" to any "DirectedRelationship". That means we have to choose a concrete element of one of these types : Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, Extend, Generalization, Include, InformationFlow, InterfaceRealization, Manifestation, PackageImport, PackageMerge, ProfileApplication, ProtocolConformance, Realization, Substitution, TemplateBinding, Usage We can use OCL constraints to restrict the use of that, but what concrete subclasses should we select ? Dependency ? Frédéric. Bran Selic a écrit : I don't see why it should not be possible to extend an abstract metaclass. In fact, I seem to recall some stereotypes (I forget in which profiles), tha textend Element. I am almost certain that we used this capability in SPT. The semantics were that it applied to all sub-(meta)classes. However, this may be another issue to clarify with the UML 2 RTF (which, of course, will create a long and indefinite discussion). I still remain unconvinced that Constraint is the best solution. Cheers...Bran Date: Wed, 4 Mar 2009 10:01:42 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Frederic Mallet cc: Bran Selic , marte-ftf , Yves.Bernard@airbus.com Subject: Re: [alloc_wg] Issue 13126 User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Allocation is unfortunately a much more general concept than allocating an application to a platform. Functionality is allocated to processes, processes are allocated to a virtual machine, and resources may be allocated to resource pools, just for some examples. What allocation is doing in these cases is imposing structure on a less structured system. For generality, alternative allocations should be possible. If only a single allocation is possible then the potential of MDE is thrown away. Then it is essential that the allocation should cleanly factor out of the desicription before allocation... so that alternative allocations can be considered. To me this suggests that a relationship fits better. If it is a dependency, it is an introduced dependency conditional on the allocation. And the constraints due to allocation are results of the dependency, not the allocation itself. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Frederic Mallet wrote: Bran, Bran Selic a écrit : Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. People were convinced by the proposal. I think mainly because it was doing very little changes, that the constraint had to be here somewhere anyway (because it is implied by the allocation) and because in the end the visual representation would not change. If the discussion is still open, here are a few thoughts: I was about to write a draft resolution, but the discussion is still open, of course. - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. We are very well aware of that, this is why we attempted to reduce the impact as much as possible. Nevertheless, we had thought of several possible solutions and wanted to reduce the possibilities before trying to convince other people. The next step is to discuss with SysML RTF. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. The domain view is supposed to describe that. May be we need to revise it. Here is a summary: - There are two kinds of elements : application and executionPlatform. Some people do not like this terminology but we could not agree on one that was satisfactory for everybody. Some prefer to speak about logical vs. physical. - We want to design both independently with a Y-chart approach. - At a very abstract level, we have on the logical side (application) a PIM and an abstract description of the platform on the other side. For early validations, we need to make an allocation at this stage. - Then, we separately refine each side to get to a stage where we have a PSM and a concrete description of the platform. After each refinement step, we want to refine also the allocation relationship with results from the various analyzes. Even though at the final stages I would agree on having a dependency I think that we do not want to have a dependency at the early stages and definitely not between the PIM and the abstract platform representation. Plus, the dependency modifies the client and at several times (also during SysML RTF) it was mentioned that this was an issue when we try to allocate *read_only* elements. It was also bothering people from Airbus and Zeligsoft. The former have lots of troubles due to that with their dependency analysis tools. The latter attempted to go around by defining a methodology that would reduce the possibilities to use allocation. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. What we agreed on is that the allocation implies constraints that state the cost of the allocation, in terms of time, power, area, ... A first proposition was to use, as a base class for Allocate, something neutral like a Classifier or a Package and build some dependencies from this classifier to the application and to the executionPlatform. That proposition would have required lots of modifications and would have resulted in something heavy to implement, with a very different look that the one everyone expect. We did consider using an Relationship as a base class but we stepped back since in mathematics a (direct) relationship implies a dependency. I must admit that by reading again the UML specification, the UML Relationship (and also DirectedRelationship) seems to be much more general than that since UML explicitly states that it has no semantics at all and no graphical notation. I would strongly urge that this be coordinated with the SysML RTF. Can we agree on the use case I described above (and which is supposed to reflect the domain view of Allocation) within MARTE before involving SysML RTF ? If we end up choosing DirectedRelationship instead of Constraint, then they should not be any problem with SysML. If SysML RTF does not want to modify allocation, their allocation would just be more specific than MARTE allocation. I hope we can converge before the 14th so we can add a resolution in the last ballot. I do not think there is any urgency for the SysML agenda since, the SysML 2 in under way. Frédéric. X-IronPort-AV: E=Sophos;i="4.38,301,1233529200"; d="scan'208";a="23854710" Date: Wed, 04 Mar 2009 16:27:46 +0100 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.19 (Windows/20081209) To: cmw@sce.carleton.ca CC: Bran Selic , marte-ftf , Yves.Bernard@airbus.com Subject: Re: [alloc_wg] Issue 13126 That is exactly why I said the vocabulary application/executionPlatform was problematic. I may agree with your general definition of allocation but in that case my questions are : When you modify the processes, do you necessarily modify the functionality ? When you modify the virtual machines, do you necessarily modify the processes ? When you modify the resource pools, do you necessarily modify the resources themselves ? Because this is exactly what is implied by a dependency ! A relationship fits better but as I said a Relationship (or a DirectedRelationship) is an abstract metaclass and when you apply your stereotype, you need a concrete element. The candidates for DirectedRelationship are : Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, Extend, Generalization, Include, InformationFlow, InterfaceRealization, Manifestation, PackageImport, PackageMerge, ProfileApplication, ProtocolConformance, Realization, Substitution, TemplateBinding, Usage Which one of these would you choose to represent any of the allocation you described ? I agree that the constraint is only implied by the allocation but using a dependency has some drawbacks and is not satisfactory. Using a constraint is not plainly satisfactory but has a minimal impact. What we really need is either a new metaclass (not with a profile) or making DirectedRelationship concrete (not with a Profile). Frédéric. Murray Woodside a écrit : Allocation is unfortunately a much more general concept than allocating an application to a platform. Functionality is allocated to processes, processes are allocated to a virtual machine, and resources may be allocated to resource pools, just for some examples. What allocation is doing in these cases is imposing structure on a less structured system. For generality, alternative allocations should be possible. If only a single allocation is possible then the potential of MDE is thrown away. Then it is essential that the allocation should cleanly factor out of the desicription before allocation... so that alternative allocations can be considered. To me this suggests that a relationship fits better. If it is a dependency, it is an introduced dependency conditional on the allocation. And the constraints due to allocation are results of the dependency, not the allocation itself. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Date: Wed, 4 Mar 2009 10:51:24 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Frederic Mallet cc: Bran Selic , marte-ftf , Yves.Bernard@airbus.com Subject: Re: [alloc_wg] Issue 13126 User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) I think an allocation would be a new kind of relationship. Many of the candidatesw you list are relationships between an entity, and a transformation or different version of itself (e.g. abstraction, realization)... allocation is quite different from that. It is an introduced relationship rather than an intrinsic relationship, I think. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Frederic Mallet wrote: That is exactly why I said the vocabulary application/executionPlatform was problematic. I may agree with your general definition of allocation but in that case my questions are : When you modify the processes, do you necessarily modify the functionality ? When you modify the virtual machines, do you necessarily modify the processes ? When you modify the resource pools, do you necessarily modify the resources themselves ? Because this is exactly what is implied by a dependency ! A relationship fits better but as I said a Relationship (or a DirectedRelationship) is an abstract metaclass and when you apply your stereotype, you need a concrete element. The candidates for DirectedRelationship are : Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, Extend, Generalization, Include, InformationFlow, InterfaceRealization, Manifestation, PackageImport, PackageMerge, ProfileApplication, ProtocolConformance, Realization, Substitution, TemplateBinding, Usage Which one of these would you choose to represent any of the allocation you described ? I agree that the constraint is only implied by the allocation but using a dependency has some drawbacks and is not satisfactory. Using a constraint is not plainly satisfactory but has a minimal impact. What we really need is either a new metaclass (not with a profile) or making DirectedRelationship concrete (not with a Profile). Frédéric. Murray Woodside a écrit : Allocation is unfortunately a much more general concept than allocating an application to a platform. Functionality is allocated to processes, processes are allocated to a virtual machine, and resources may be allocated to resource pools, just for some examples. What allocation is doing in these cases is imposing structure on a less structured system. For generality, alternative allocations should be possible. If only a single allocation is possible then the potential of MDE is thrown away. Then it is essential that the allocation should cleanly factor out of the desicription before allocation... so that alternative allocations can be considered. To me this suggests that a relationship fits better. If it is a dependency, it is an introduced dependency conditional on the allocation. And the constraints due to allocation are results of the dependency, not the allocation itself. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Subject: Re: [alloc_wg] Issue 13126 From: Pierre Boulet To: Frederic Mallet Cc: Bran Selic , marte-ftf , Yves.Bernard@airbus.com Organization: LIFL - USTL Date: Wed, 04 Mar 2009 16:56:14 +0100 X-Mailer: Evolution 2.24.3 X-MailScanner-ID: n24Ft8HC020088 X-USTL-MailScanner: Found to be clean X-USTL-MailScanner-From: pierre.boulet@lifl.fr X-Spam-Status: No Fréderic, thanks for this proposal. I strongly support it. It has the added benefit of allowing to allocate Elements instead of NamedElements and to easily (graphically) support multiple from or to elements (we need that). Regards, Pierre. Le mercredi 04 mars 2009 à 14:23 +0100, Frederic Mallet a écrit : Bran, Bran Selic a écrit : > Thanks for sending this, Frederic. I am definitely curious about the > conclusions reached, if any, on this proposal. Unfortunately, the > MARTE telecons occur at 2 in the morning for me, so I cannot attend. People were convinced by the proposal. I think mainly because it was doing very little changes, that the constraint had to be here somewhere anyway (because it is implied by the allocation) and because in the end the visual representation would not change. > If the discussion is still open, here are a few thoughts: I was about to write a draft resolution, but the discussion is still open, of course. > - One of the objectives of using the current model was to retain > consistency with the SysML profile. There is strong evidence that many > people want to use the two together. Unless this change is > synchronized with the SysML RTF, we will add to compatibility issues > between the two profiles. I really think that would not be a good thing. We are very well aware of that, this is why we attempted to reduce the impact as much as possible. Nevertheless, we had thought of several possible solutions and wanted to reduce the possibilities before trying to convince other people. The next step is to discuss with SysML RTF. > - Perhaps we need to define allocation more precisely before we make > any decisions. What are the use cases in which we want to use > "allocate" in our models. For example, I don't understand what it > means to allocate a PIM to a platform, so I don't see this as a > relevant argument against using dependency. The domain view is supposed to describe that. May be we need to revise it. Here is a summary: - There are two kinds of elements : application and executionPlatform. Some people do not like this terminology but we could not agree on one that was satisfactory for everybody. Some prefer to speak about logical vs. physical. - We want to design both independently with a Y-chart approach. - At a very abstract level, we have on the logical side (application) a PIM and an abstract description of the platform on the other side. For early validations, we need to make an allocation at this stage. - Then, we separately refine each side to get to a stage where we have a PSM and a concrete description of the platform. After each refinement step, we want to refine also the allocation relationship with results from the various analyzes. Even though at the final stages I would agree on having a dependency I think that we do not want to have a dependency at the early stages and definitely not between the PIM and the abstract platform representation. Plus, the dependency modifies the client and at several times (also during SysML RTF) it was mentioned that this was an issue when we try to allocate *read_only* elements. It was also bothering people from Airbus and Zeligsoft. The former have lots of troubles due to that with their dependency analysis tools. The latter attempted to go around by defining a methodology that would reduce the possibilities to use allocation. > - I must admit that using Constraint to model allocation, regardless > of its precise meaning that we may yet need to agree on, seems to me > to be a real stretch of the notion of constraint. Perhaps we can place > the stereotype base class higher in the metamodel. For example, we can > think of using the abstract metaclass Relationship, which strikes me > as general enough to fit almost any definition we could come up with. What we agreed on is that the allocation implies constraints that state the cost of the allocation, in terms of time, power, area, ... A first proposition was to use, as a base class for Allocate, something neutral like a Classifier or a Package and build some dependencies from this classifier to the application and to the executionPlatform. That proposition would have required lots of modifications and would have resulted in something heavy to implement, with a very different look that the one everyone expect. We did consider using an Relationship as a base class but we stepped back since in mathematics a (direct) relationship implies a dependency. I must admit that by reading again the UML specification, the UML Relationship (and also DirectedRelationship) seems to be much more general than that since UML explicitly states that it has no semantics at all and no graphical notation. > I would strongly urge that this be coordinated with the SysML RTF. Can we agree on the use case I described above (and which is supposed to reflect the domain view of Allocation) within MARTE before involving SysML RTF ? If we end up choosing DirectedRelationship instead of Constraint, then they should not be any problem with SysML. If SysML RTF does not want to modify allocation, their allocation would just be more specific than MARTE allocation. I hope we can converge before the 14th so we can add a resolution in the last ballot. I do not think there is any urgency for the SysML agenda since, the SysML 2 in under way. Frédéric. -- Pr. Pierre Boulet +33 609081811 smime.p7s Subject: RE: [alloc_wg] Issue 13126 Date: Wed, 4 Mar 2009 17:48:06 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alloc_wg] Issue 13126 Thread-Index: Acmc4RVKw/YGbtjWSumbnTx5Q3IbbgABY7qQ From: "BERNARD, Yves" To: , "Frederic Mallet" Cc: "Bran Selic" , "marte-ftf" X-OriginalArrivalTime: 04 Mar 2009 16:48:07.0629 (UTC) FILETIME=[FEB377D0:01C99CE8] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n24GkeKF015790 Hello, I agree that allocation a new kind of relationship. The point is that - as pointed out by Frédéric - the "right" meta-class doesn't exist so far in UML and we're not able to add it in a profile. Nevertheless, we definitly need to be able to specify allocation without adding any dependencies between allocated elements. That's our point. As already said, we have studied and discussed several candidates. None of them is the perfect one, all of them have drawbacks, including the choice of the abstract meta-class (Directed)Relationship because all the concrete classes that could be actually used would add undesirable semantics to our "allocations". If we agree that: "the allocation implies constraints that state the cost of the allocation, in terms of time, power, area, ...", then "Constraint" is not a so bad choice, I think. Cheers, 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 -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : mercredi 4 mars 2009 16:51 À : Frederic Mallet Cc : Bran Selic; marte-ftf; BERNARD, Yves Objet : Re: [alloc_wg] Issue 13126 I think an allocation would be a new kind of relationship. Many of the candidatesw you list are relationships between an entity, and a transformation or different version of itself (e.g. abstraction, realization)... allocation is quite different from that. It is an introduced relationship rather than an intrinsic relationship, I think. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Frederic Mallet wrote: > That is exactly why I said the vocabulary application/executionPlatform was > problematic. > > I may agree with your general definition of allocation but in that case my > questions are : > When you modify the processes, do you necessarily modify the functionality ? > When you modify the virtual machines, do you necessarily modify the processes > ? > When you modify the resource pools, do you necessarily modify the resources > themselves ? > > Because this is exactly what is implied by a dependency ! > > A relationship fits better but as I said a Relationship (or a > DirectedRelationship) is an abstract metaclass and when you apply your > stereotype, you need a concrete element. The candidates for > DirectedRelationship are : > > Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, > Extend, Generalization, Include, InformationFlow, InterfaceRealization, > Manifestation, PackageImport, PackageMerge, ProfileApplication, > ProtocolConformance, Realization, Substitution, TemplateBinding, Usage > > Which one of these would you choose to represent any of the allocation you > described ? > > I agree that the constraint is only implied by the allocation but using a > dependency has some drawbacks and is not satisfactory. > Using a constraint is not plainly satisfactory but has a minimal impact. > What we really need is either a new metaclass (not with a profile) or making > DirectedRelationship concrete (not with a Profile). > > Frédéric. > > Murray Woodside a écrit : >> Allocation is unfortunately a much more general concept than allocating an >> application to a platform. Functionality is allocated to processes, >> processes are allocated to a virtual machine, and resources may be >> allocated to resource pools, just for some examples. What allocation is >> doing in these cases is imposing structure on a less structured system. >> >> For generality, alternative allocations should be possible. If only a >> single allocation is possible then the potential of MDE is thrown away. >> Then it is essential that the allocation should cleanly factor out of the >> desicription before allocation... so that alternative allocations can be >> considered. >> >> To me this suggests that a relationship fits better. If it is a dependency, >> it is an introduced dependency conditional on the allocation. And the >> constraints due to allocation are results of the dependency, not the >> allocation itself. >> >> >> Murray Woodside >> >> Distinguished Research Professor >> Dept of Systems and Computer Engineering, >> Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. >> (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca >> (http://www.sce.carleton.ca/faculty/woodside.html) >> > 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: Wed, 04 Mar 2009 18:06:20 +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: cmw@sce.carleton.ca CC: Frederic Mallet , Bran Selic , marte-ftf , Yves.Bernard@airbus.com Subject: Re: [alloc_wg] Issue 13126 X-OriginalArrivalTime: 04 Mar 2009 17:08:30.0708 (UTC) FILETIME=[D7B68340:01C99CEB] X-imss-version: 2.053 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.6.1016(16500.000) X-imss-scores: Clean:74.92881 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 yesterday's telco I was in favor of using constraint as a base for allocation mainly because there is no other mechanism to introduce in UML a modelling element that uses other models (modeling elements) as instances of what they separately mean, and expresses something with them that is only in the expresive scope of the expression itself, not changing the meaning of the referenced models (modeling elements). Just as we use words with their respective meanings to say things that have a different meaning. I may agree on using relationship if there would be anyway of expressing "introduced relationship" instead of "intrinsic relationship" as they have been called by Murray. This "introduced relationship" would have to belong to the expresive scope of the container of the instances of the modelling elements there referenced. Examples of this scopes are now the analysisContext in gqam/pam/sam, the called "views" in one of the optional requirements of the MARTE RFP (and in issue 11883 [NFP wiki]) and more recently the configuration "mode" in the speculative solutions for issue 11764 [NFP wiki] (in the spirit of linking with AADL) These are sort of gramatical modelling spaces to express something different with the modelling elements referenced. I may be trying to get something that is probably already in QVT or MOF but that must be somewhere available in UML. Considering that for embedded systems designers, Allocation is the basis for (1)design space exploration, (2)resource usage, performance and timing assurance, and finally (3) deployment and configuration specification; I think that the very basic capability required of an Allocation mechanism in MARTE is the ability to be easily configured and used by means of the VSL variables and expressions, and I think that extending constraint (particularly NFP constraint) this is achievable. I am not totally aware of the discussions in the SySML Task Force but I guess they might be also looking for such flexibility in the management of modelling intents. A link between Allocation, its ends (to and from allocated elements) as variables, and the "context" in which it is declared might be also usefully fixed in the standard, but I wont advocate for it, particularly considering the time we have, the evolving level of maturity of this topics in the community, and the implications on related standards. Best regards, Julio Murray Woodside wrote: I think an allocation would be a new kind of relationship. Many of the candidatesw you list are relationships between an entity, and a transformation or different version of itself (e.g. abstraction, realization)... allocation is quite different from that. It is an introduced relationship rather than an intrinsic relationship, I think. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Frederic Mallet wrote: That is exactly why I said the vocabulary application/executionPlatform was problematic. I may agree with your general definition of allocation but in that case my questions are : When you modify the processes, do you necessarily modify the functionality ? When you modify the virtual machines, do you necessarily modify the processes ? When you modify the resource pools, do you necessarily modify the resources themselves ? Because this is exactly what is implied by a dependency ! A relationship fits better but as I said a Relationship (or a DirectedRelationship) is an abstract metaclass and when you apply your stereotype, you need a concrete element. The candidates for DirectedRelationship are : Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, Extend, Generalization, Include, InformationFlow, InterfaceRealization, Manifestation, PackageImport, PackageMerge, ProfileApplication, ProtocolConformance, Realization, Substitution, TemplateBinding, Usage Which one of these would you choose to represent any of the allocation you described ? I agree that the constraint is only implied by the allocation but using a dependency has some drawbacks and is not satisfactory. Using a constraint is not plainly satisfactory but has a minimal impact. What we really need is either a new metaclass (not with a profile) or making DirectedRelationship concrete (not with a Profile). Frédéric. Murray Woodside a écrit : Allocation is unfortunately a much more general concept than allocating an application to a platform. Functionality is allocated to processes, processes are allocated to a virtual machine, and resources may be allocated to resource pools, just for some examples. What allocation is doing in these cases is imposing structure on a less structured system. For generality, alternative allocations should be possible. If only a single allocation is possible then the potential of MDE is thrown away. Then it is essential that the allocation should cleanly factor out of the desicription before allocation... so that alternative allocations can be considered. To me this suggests that a relationship fits better. If it is a dependency, it is an introduced dependency conditional on the allocation. And the constraints due to allocation are results of the dependency, not the allocation itself. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) Date: Wed, 04 Mar 2009 20:03:24 +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: cmw@sce.carleton.ca CC: Frederic Mallet , Bran Selic , marte-ftf , Yves.Bernard@airbus.com Subject: Re: [alloc_wg] Issue 13126 X-OriginalArrivalTime: 04 Mar 2009 19:05:38.0844 (UTC) FILETIME=[34CEF5C0:01C99CFC] X-imss-version: 2.053 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.6.1016(16500.001) X-imss-scores: Clean:78.62159 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) (I am sorry if you have received this message already, but my mail manager has not been working very well this afternoon... so I prefer to sent it again just in case... thanks.) In yesterday's telco I was in favor of using constraint as a base for allocation mainly because there is no other mechanism to introduce in UML a modeling element that uses other models (modeling elements) as instances of what they separately mean, and expresses something with them that is only in the expressive scope of the expression itself, not changing the meaning of the referenced models (modeling elements). Just as we use words with their respective meanings to say things that have a different meaning. I may agree on using relationship if there would be anyway of expressing "introduced relationship" instead of "intrinsic relationship" as they have been called by Murray. This "introduced relationship" would have to belong to the expressive scope of the container of the instances of the modeling elements there referenced. Examples of this scopes are now the analysisContext in gqam/pam/sam, the called "views" in one of the optional requirements of the MARTE RFP (and in issue 11883 [NFP wiki]) and more recently the configuration "mode" in the speculative solutions for issue 11764 [NFP wiki] (in the spirit of linking with AADL) These are sort of grammatical modeling spaces to express something different with the modeling elements referenced. I may be trying to get something that is probably already in QVT or MOF but that must be somewhere available in UML. Considering that for embedded systems designers, Allocation is the basis for (1)design space exploration, (2)resource usage, performance and timing assurance, and finally (3) deployment and configuration specification; I think that the very basic capability required of an Allocation mechanism in MARTE is the ability to be easily configured and used by means of the VSL variables and expressions, and I think that extending constraint (particularly NFP constraint) this is achievable. I am not totally aware of the discussions in the SySML Task Force but I guess they might be also looking for such flexibility in the management of modeling intents. A link between Allocation, its ends (to and from allocated elements) as variables, and the "context" in which it is declared might be also usefully fixed in the standard, but I wont advocate for it, particularly considering the time we have, the evolving level of maturity of this topics in the community, and the implications on related standards. Best regards, Julio Murray Woodside wrote: I think an allocation would be a new kind of relationship. Many of the candidatesw you list are relationships between an entity, and a transformation or different version of itself (e.g. abstraction, realization)... allocation is quite different from that. It is an introduced relationship rather than an intrinsic relationship, I think. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Frederic Mallet wrote: That is exactly why I said the vocabulary application/executionPlatform was problematic. I may agree with your general definition of allocation but in that case my questions are : When you modify the processes, do you necessarily modify the functionality ? When you modify the virtual machines, do you necessarily modify the processes ? When you modify the resource pools, do you necessarily modify the resources themselves ? Because this is exactly what is implied by a dependency ! A relationship fits better but as I said a Relationship (or a DirectedRelationship) is an abstract metaclass and when you apply your stereotype, you need a concrete element. The candidates for DirectedRelationship are : Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, Extend, Generalization, Include, InformationFlow, InterfaceRealization, Manifestation, PackageImport, PackageMerge, ProfileApplication, ProtocolConformance, Realization, Substitution, TemplateBinding, Usage Which one of these would you choose to represent any of the allocation you described ? I agree that the constraint is only implied by the allocation but using a dependency has some drawbacks and is not satisfactory. Using a constraint is not plainly satisfactory but has a minimal impact. What we really need is either a new metaclass (not with a profile) or making DirectedRelationship concrete (not with a Profile). Frédéric. Murray Woodside a écrit : Allocation is unfortunately a much more general concept than allocating an application to a platform. Functionality is allocated to processes, processes are allocated to a virtual machine, and resources may be allocated to resource pools, just for some examples. What allocation is doing in these cases is imposing structure on a less structured system. For generality, alternative allocations should be possible. If only a single allocation is possible then the potential of MDE is thrown away. Then it is essential that the allocation should cleanly factor out of the desicription before allocation... so that alternative allocations can be considered. To me this suggests that a relationship fits better. If it is a dependency, it is an introduced dependency conditional on the allocation. And the constraints due to allocation are results of the dependency, not the allocation itself. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=IKM7T4LVGE+f32HvZ1YoBz054d1J00BrAWDGinDNw2ZgqURXErYQep5uJthOqblM+BesPrl4nRgTWkT54l/1AcksZf5XF5GO75OTlo+EMU4i0B+F4O/6DOBI7wdtDJ6b0D488ZK9Q6EZwq7FlkxbszetZGuMZ7/CXVZPfnrrqxo=; X-YMail-OSG: Dr25unkVM1le3IU7II2F5VWVPubW8DdyE97wrsnTu.GQoTJHCbV1ODjRUUR4cOl_NiCCCR1u681W8nTOCCAh0RGpbA7kTg49eMiGMN_dAUtD6XoBC0kmEUlIVXxpnFqEBKzVdXYhGwmg1scmuaQYZXrra8OJ8ddXBFJ7Uwgtab32fLrLfblm9G3OLXrQdqSzIRtyteboXw19qRtx1QbUXU5Sglu4Qmte5WreyItFWNzJGaSD9gvG94X5Vd2s8P3G6hBm2a4GiepiwSg- X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Wed, 4 Mar 2009 14:21:29 -0800 (PST) From: Mark Gerhardt Subject: Re: [alloc_wg] Issue 13126 To: Bran Selic Cc: Frederic Mallet , marte-ftf , Peter Kortmann Bran, Thanks for the feedback. In the current draft, there is an example of a conditional within a property annotation which sets the clock speed based upon the value of utilization (fig 8.10). This seems like a dynamic implementation of constraints through a conditional property expression. . In fact, the this actually represents an implementation choice and the selection of "different" platform instances. The choices involving characterizing constraints, allocation, conditional properties, and dependencies between the architecture parts seems to be closely bound to the development and decomposition process being used. My understanding is that specific choices about this type of issue is intended to be outside the scope of the MARTE specification. Is this his correct? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 -------------------------------------------------------------------------------- From: Bran Selic To: Mark Gerhardt Cc: Frederic Mallet ; marte-ftf ; Peter Kortmann Sent: Tuesday, March 3, 2009 4:59:47 PM Subject: Re: [alloc_wg] Issue 13126 Thanks, Mark. I agree that the platform imposes constraints on the software that it runs and it is quite important to design with these in mind in many cases. In fact, I have written and published a number of papers precisely on this topic and with that very message. (In fact, I really detest the term PIM for that reason. However, a PIM is not something that is normally allocated to a platform anyway, that should be either the PSM or the software itself.) However, my concern was that using Constraint to model allocation is really a stretch. You may specify explicit constraints on both the platform and the application model, but I don't think you should do this using the allocation concept. These constraints should be defined independently of any allocation. I am not sure if this addresses any of your points, though. Cheers..Bran On Tue, Mar 3, 2009 at 7:14 PM, Mark Gerhardt wrote: Peter Kortmann and I have been discussing allocation and related topics very recently. The consequence of an allocation of an executing task instance to a CPU platform introduces a dependency of its execution time upon the CPU clock speed and memory size. Any constraints upon the task execution instance like deadline, for example, indirectly and partially constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the isolation between platform and application but are part of a relevant performance-oriented decomposition allocation process. In this sense allocation is really implementation binding rather than partial assignment of the total constraints. Since OMG and the MARTE document both strive for method and design process independence, it seems inappropriate to become immersed in the complexity of this set of allocation-related issues. Comments? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 -------------------------------------------------------------------------------- From: Bran Selic To: Frederic Mallet Cc: marte-ftf Sent: Tuesday, March 3, 2009 3:24:12 PM Subject: Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=OdW/hLRdLLs6PZRysW8TDk/z9VbjfdE3fhCF/+wJ4OE=; b=HUACXhBllbPR25uw+VhmsFGwj5sYFpatnTtp1aaQqyXhdU3O6WLZyMytanhWkFyviV Io5Rl/pxBr4Eq3dCuLuMm2UKbLTHWueAn/1z2R2B43bIUk2MT5jj9wqaA8BfFoqUkyfv sI53cb/QF5l9AhVPsP+F6KcsU5ERDgbSl+sgE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=O0m9EN9bCVovYrjMA8OxHNNvWij90BYS7LOuif654ioJbN6XlgeeHe7rHoH7faCPmV a1W28pRsIcdrNYloA2IAPD3sz2k8q4eR1lT6GhnC0ulggne4bJ4kKsWX8Vjj2PjSidKl +ydkkuGkLhMX3NMarvhYPIkCh+T6LZW9OC38U= Date: Wed, 4 Mar 2009 17:50:01 -0500 Subject: Re: [alloc_wg] Issue 13126 From: Bran Selic To: "BERNARD, Yves" Cc: cmw@sce.carleton.ca, Frederic Mallet , marte-ftf Just to point out that it is not against OMG rules for one specification to recommend a change in another specification on which it depends -- even for an FTF. If we agree that something is missing in UML, it is possible to propose a resolution that recommends a change in UML. This, of course, needs to be coordinated with the UML RTF, but I suspect this one will not be too problematic -- no one likes the current deployment model. Perhaps we can fix two problems with one stone? Bran On Wed, Mar 4, 2009 at 11:48 AM, BERNARD, Yves wrote: Hello, I agree that allocation a new kind of relationship. The point is that - as pointed out by Frédéric - the "right" meta-class doesn't exist so far in UML and we're not able to add it in a profile. Nevertheless, we definitly need to be able to specify allocation without adding any dependencies between allocated elements. That's our point. As already said, we have studied and discussed several candidates. None of them is the perfect one, all of them have drawbacks, including the choice of the abstract meta-class (Directed)Relationship because all the concrete classes that could be actually used would add undesirable semantics to our "allocations". If we agree that: "the allocation implies constraints that state the cost of the allocation, in terms of time, power, area, ...", then "Constraint" is not a so bad choice, I think. Cheers, 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 -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : mercredi 4 mars 2009 16:51 À : Frederic Mallet Cc : Bran Selic; marte-ftf; BERNARD, Yves Objet : Re: [alloc_wg] Issue 13126 I think an allocation would be a new kind of relationship. Many of the candidatesw you list are relationships between an entity, and a transformation or different version of itself (e.g. abstraction, realization)... allocation is quite different from that. It is an introduced relationship rather than an intrinsic relationship, I think. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Frederic Mallet wrote: > That is exactly why I said the vocabulary application/executionPlatform was > problematic. > > I may agree with your general definition of allocation but in that case my > questions are : > When you modify the processes, do you necessarily modify the functionality ? > When you modify the virtual machines, do you necessarily modify the processes > ? > When you modify the resource pools, do you necessarily modify the resources > themselves ? > > Because this is exactly what is implied by a dependency ! > > A relationship fits better but as I said a Relationship (or a > DirectedRelationship) is an abstract metaclass and when you apply your > stereotype, you need a concrete element. The candidates for > DirectedRelationship are : > > Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, > Extend, Generalization, Include, InformationFlow, InterfaceRealization, > Manifestation, PackageImport, PackageMerge, ProfileApplication, > ProtocolConformance, Realization, Substitution, TemplateBinding, Usage > > Which one of these would you choose to represent any of the allocation you > described ? > > I agree that the constraint is only implied by the allocation but using a > dependency has some drawbacks and is not satisfactory. > Using a constraint is not plainly satisfactory but has a minimal impact. > What we really need is either a new metaclass (not with a profile) or making > DirectedRelationship concrete (not with a Profile). > > Frédéric. > > Murray Woodside a écrit : >> Allocation is unfortunately a much more general concept than allocating an >> application to a platform. Functionality is allocated to processes, >> processes are allocated to a virtual machine, and resources may be >> allocated to resource pools, just for some examples. What allocation is >> doing in these cases is imposing structure on a less structured system. >> >> For generality, alternative allocations should be possible. If only a >> single allocation is possible then the potential of MDE is thrown away. >> Then it is essential that the allocation should cleanly factor out of the >> desicription before allocation... so that alternative allocations can be >> considered. >> >> To me this suggests that a relationship fits better. If it is a dependency, >> it is an introduced dependency conditional on the allocation. And the >> constraints due to allocation are results of the dependency, not the >> allocation itself. >> >> >> Murray Woodside >> >> Distinguished Research Professor >> Dept of Systems and Computer Engineering, >> Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. >> (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca >> (http://www.sce.carleton.ca/faculty/woodside.html) >> > 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: Wed, 4 Mar 2009 19:51:49 -0500 (EST) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Mark Gerhardt cc: Bran Selic , Frederic Mallet , marte-ftf , Peter Kortmann Subject: Re: [alloc_wg] Issue 13126 User-Agent: Alpine 2.00 (LFD 1167 2008-08-23) Mark, I think this is going even beyond allocation to run-time management. Specification of adaptive flexible systems requires a high-level adaptation functionality that modifies the lower level. Another example is mobile code which may be downloaded into a wireless platform, or executed in a base station, depending on bandwidth and mobile power considerations. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Mark Gerhardt wrote: Bran, Thanks for the feedback. In the current draft, there is an example of a conditional within a property annotation which sets the clock speed based upon the value of utilization (fig 8.10). This seems like a dynamic implementation of constraints through a conditional property expression. . In fact, the this actually represents an implementation choice and the selection of "different" platform instances. The choices involving characterizing constraints, allocation, conditional properties, and dependencies between the architecture parts seems to be closely bound to the development and decomposition process being used. My understanding is that specific choices about this type of issue is intended to be outside the scope of the MARTE specification. Is this his correct? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 __________________________________________________________________________________________________________ From: Bran Selic To: Mark Gerhardt Cc: Frederic Mallet ; marte-ftf ; Peter Kortmann Sent: Tuesday, March 3, 2009 4:59:47 PM Subject: Re: [alloc_wg] Issue 13126 Thanks, Mark. I agree that the platform imposes constraints on the software that it runs and it is quite important to design with these in mind in many cases. In fact, I have written and published a number of papers precisely on this topic and with that very message. (In fact, I really detest the term PIM for that reason. However, a PIM is not something that is normally allocated to a platform anyway, that should be either the PSM or the software itself.) However, my concern was that using Constraint to model allocation is really a stretch. You may specify explicit constraints on both the platform and the application model, but I don't think you should do this using the allocation concept. These constraints should be defined independently of any allocation. I am not sure if this addresses any of your points, though. Cheers..Bran On Tue, Mar 3, 2009 at 7:14 PM, Mark Gerhardt wrote: Peter Kortmann and I have been discussing allocation and related topics very recently. The consequence of an allocation of an executing task instance to a CPU platform introduces a dependency of its execution time upon the CPU clock speed and memory size. Any constraints upon the task execution instance like deadline, for example, indirectly and partially constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the isolation between platform and application but are part of a relevant performance-oriented decomposition allocation process. In this sense allocation is really implementation binding rather than partial assignment of the total constraints. Since OMG and the MARTE document both strive for method and design process independence, it seems inappropriate to become immersed in the complexity of this set of allocation-related issues. Comments? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 __________________________________________________________________________________________________________ From: Bran Selic To: Frederic Mallet Cc: marte-ftf Sent: Tuesday, March 3, 2009 3:24:12 PM Subject: Re: [alloc_wg] Issue 13126 Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot attend. If the discussion is still open, here are a few thoughts: - One of the objectives of using the current model was to retain consistency with the SysML profile. There is strong evidence that many people want to use the two together. Unless this change is synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I really think that would not be a good thing. - Perhaps we need to define allocation more precisely before we make any decisions. What are the use cases in which we want to use "allocate" in our models. For example, I don't understand what it means to allocate a PIM to a platform, so I don't see this as a relevant argument against using dependency. - I must admit that using Constraint to model allocation, regardless of its precise meaning that we may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we can place the stereotype base class higher in the metamodel. For example, we can think of using the abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we could come up with. I would strongly urge that this be coordinated with the SysML RTF. Cheers...Bran On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: Hi all, Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". We are planning to discuss that now during the teleconference. Frédéric. DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=KFQsoZiGgiE6eJ+wcM+XO2OFIWIAv+SQ3Tbcpb2Drdll1HeaiGDUSzt1PXIUWtOoFo6xEzJ4GLnbBxq5QWErTjCA4YDkVsHtEdfAA22gwz+DePVhWXtUJtevUZx9TwxPMts+gyucv557xwvlsf+tDZ1VyyBW0ZYDIFv2VOKcOoU=; X-YMail-OSG: z5f.yQ0VM1kCVlvTQKNE47Z29gLosYGC0vkso5y7CcbFaJR40h0x.FYPap02oEttj.d.yjN.DzZeYzDKvPF3GSgQ3.AGN0bBeBUm2R9hflkYeBDwwlNszvZRGMWwmJosfNGgB0vTBzcFLCf5oXqlD6G8JkX.8mqVgD5FgJdBCWrd3GvxwRi4VIBgLESDgqGoEb3MIwmpK2odAaoPfCneEWzBdWPmRYO8K9mupz7ixQBmfogSMWnpYw2IsA1ldfBL80894srKkBfnyfpJW0g- X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Wed, 4 Mar 2009 21:42:32 -0800 (PST) From: Mark Gerhardt Subject: Re: [alloc_wg] Issue 13126 To: cmw@sce.carleton.ca Cc: Bran Selic , Frederic Mallet , marte-ftf , Peter Kortmann Murray, This need not be a dynamic adaptive system, but rather a pre-construction allocation constrained design choice used only within the architecture process. The resulting system could be simplistically static. That's part of the point. Should fig 8.10 be changed to a less controversial example? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 -------------------------------------------------------------------------------- From: Murray Woodside To: Mark Gerhardt Cc: Bran Selic ; Frederic Mallet ; marte-ftf ; Peter Kortmann Sent: Wednesday, March 4, 2009 4:51:49 PM Subject: Re: [alloc_wg] Issue 13126 Mark, I think this is going even beyond allocation to run-time management. Specification of adaptive flexible systems requires a high-level adaptation functionality that modifies the lower level. Another example is mobile code which may be downloaded into a wireless platform, or executed in a base station, depending on bandwidth and mobile power considerations. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Mark Gerhardt wrote: > Bran, > > Thanks for the feedback. > > In the current draft, there is an example of a conditional within a property annotation which sets the > clock speed based upon the value of utilization (fig 8.10). This seems like a dynamic implementation of > constraints through a conditional property expression. . In fact, the this actually represents an > implementation choice and the selection of "different" platform instances. > > The choices involving characterizing constraints, allocation, conditional properties, and dependencies > between the architecture parts seems to be closely bound to the development and decomposition process > being used. > > My understanding is that specific choices about this type of issue is intended to be outside the scope of > the MARTE specification. Is this his correct? > ________________________________ > Mark Gerhardt > gerhmark@pacbell.net > (650)208-3994 > > __________________________________________________________________________________________________________ > From: Bran Selic > To: Mark Gerhardt > Cc: Frederic Mallet ; marte-ftf ; Peter Kortmann > > Sent: Tuesday, March 3, 2009 4:59:47 PM > Subject: Re: [alloc_wg] Issue 13126 > > Thanks, Mark. I agree that the platform imposes constraints on the software that it runs and it is quite > important to design with these in mind in many cases. In fact, I have written and published a number of > papers precisely on this topic and with that very message. (In fact, I really detest the term PIM for that > reason. However, a PIM is not something that is normally allocated to a platform anyway, that should be > either the PSM or the software itself.) > > However, my concern was that using Constraint to model allocation is really a stretch. You may specify > explicit constraints on both the platform and the application model, but I don't think you should do this > using the allocation concept. These constraints should be defined independently of any allocation. > > I am not sure if this addresses any of your points, though. > > Cheers..Bran > > On Tue, Mar 3, 2009 at 7:14 PM, Mark Gerhardt wrote: > Peter Kortmann and I have been discussing allocation and related topics very recently. The > consequence of an allocation of an executing task instance to a CPU platform introduces a > dependency of its execution time upon the CPU clock speed and memory size. Any constraints > upon the task execution instance like deadline, for example, indirectly and partially > constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the > isolation between platform and application but are part of a relevant performance-oriented > decomposition allocation process. > > In this sense allocation is really implementation binding rather than partial assignment of > the total constraints. Since OMG and the MARTE document both strive for method and design > process independence, it seems inappropriate to become immersed in the complexity of this set > of allocation-related issues. > > Comments? > ________________________________ > Mark Gerhardt > gerhmark@pacbell.net > (650)208-3994 > > __________________________________________________________________________________________________________ > From: Bran Selic > To: Frederic Mallet > Cc: marte-ftf > Sent: Tuesday, March 3, 2009 3:24:12 PM > Subject: Re: [alloc_wg] Issue 13126 > > Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on > this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot > attend. > > If the discussion is still open, here are a few thoughts: > > - One of the objectives of using the current model was to retain consistency with the SysML profile. > There is strong evidence that many people want to use the two together. Unless this change is > synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I > really think that would not be a good thing. > > - Perhaps we need to define allocation more precisely before we make any decisions. What are the use > cases in which we want to use "allocate" in our models. For example, I don't understand what it > means to allocate a PIM to a platform, so I don't see this as a relevant argument against using > dependency. > > - I must admit that using Constraint to model allocation, regardless of its precise meaning that we > may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we > can place the stereotype base class higher in the metamodel. For example, we can think of using the > abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we > could come up with. > > I would strongly urge that this be coordinated with the SysML RTF. > > Cheers...Bran > > On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: > Hi all, > Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". > We are planning to discuss that now during the teleconference. > > Frédéric. > > > > >Subject: RE : [alloc_wg] Issue 13126 Date: Thu, 5 Mar 2009 06:59:25 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alloc_wg] Issue 13126 Thread-Index: AcmdVUB8Aa+CYYyJQHOF+TrIGpTDUAAAI6A+ From: "ESPINOZA Huascar 218344" To: "Mark Gerhardt" , Cc: "Bran Selic" , "Frederic Mallet" , "marte-ftf" , "Peter Kortmann" X-OriginalArrivalTime: 05 Mar 2009 05:59:27.0762 (UTC) FILETIME=[8B10CF20:01C99D57] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n255w9x5031976 Hi Mark, That example represents a run time scenario indeed. The example shows how VSL may support the expression of non-functional aspects, and its intent it to cover both design time expressions, but also the modelling of QoS contracts or other aspects that can be handled at run time (e.g., in reconfigurable embedded systems that manage resources assignation at run time according to load demand, real-time contraints, and run-time resource usage). While we stressed the use of NFPs for the purposes of quantitative analysis, some approaches may use this framework to provide support for the description of non-functional aspects in run-time infrastructures. Also, VSL annotations would allow the system infrastructure to take into account the NFP contracts (i.e., required-offered relationships) between component interfaces. What is out of the scope of MARTE is to describe how this non-functional expressions will be implemented in specific middleware infrastructures. Regards, Huascar ________________________________ De: Mark Gerhardt [mailto:gerhmark@pacbell.net] Date: jeu. 05/03/2009 06:42 À: cmw@sce.carleton.ca Cc: Bran Selic; Frederic Mallet; marte-ftf; Peter Kortmann Objet : Re: [alloc_wg] Issue 13126 Murray, This need not be a dynamic adaptive system, but rather a pre-construction allocation constrained design choice used only within the architecture process. The resulting system could be simplistically static. That's part of the point. Should fig 8.10 be changed to a less controversial example? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 ________________________________ From: Murray Woodside To: Mark Gerhardt Cc: Bran Selic ; Frederic Mallet ; marte-ftf ; Peter Kortmann Sent: Wednesday, March 4, 2009 4:51:49 PM Subject: Re: [alloc_wg] Issue 13126 Mark, I think this is going even beyond allocation to run-time management. Specification of adaptive flexible systems requires a high-level adaptation functionality that modifies the lower level. Another example is mobile code which may be downloaded into a wireless platform, or executed in a base station, depending on bandwidth and mobile power considerations. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Mark Gerhardt wrote: > Bran, > > Thanks for the feedback. > > In the current draft, there is an example of a conditional within a property annotation which sets the > clock speed based upon the value of utilization (fig 8.10). This seems like a dynamic implementation of > constraints through a conditional property expression. . In fact, the this actually represents an > implementation choice and the selection of "different" platform instances. > > The choices involving characterizing constraints, allocation, conditional properties, and dependencies > between the architecture parts seems to be closely bound to the development and decomposition process > being used. > > My understanding is that specific choices about this type of issue is intended to be outside the scope of > the MARTE specification. Is this his correct? > ________________________________ > Mark Gerhardt > gerhmark@pacbell.net > (650)208-3994 > > __________________________________________________________________________________________________________ > From: Bran Selic > To: Mark Gerhardt > Cc: Frederic Mallet ; marte-ftf ; Peter Kortmann > > Sent: Tuesday, March 3, 2009 4:59:47 PM > Subject: Re: [alloc_wg] Issue 13126 > > Thanks, Mark. I agree that the platform imposes constraints on the software that it runs and it is quite > important to design with these in mind in many cases. In fact, I have written and published a number of > papers precisely on this topic and with that very message. (In fact, I really detest the term PIM for that > reason. However, a PIM is not something that is normally allocated to a platform anyway, that should be > either the PSM or the software itself.) > > However, my concern was that using Constraint to model allocation is really a stretch. You may specify > explicit constraints on both the platform and the application model, but I don't think you should do this > using the allocation concept. These constraints should be defined independently of any allocation. > > I am not sure if this addresses any of your points, though. > > Cheers..Bran > > On Tue, Mar 3, 2009 at 7:14 PM, Mark Gerhardt wrote: > Peter Kortmann and I have been discussing allocation and related topics very recently. The > consequence of an allocation of an executing task instance to a CPU platform introduces a > dependency of its execution time upon the CPU clock speed and memory size. Any constraints > upon the task execution instance like deadline, for example, indirectly and partially > constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the > isolation between platform and application but are part of a relevant performance-oriented > decomposition allocation process. > > In this sense allocation is really implementation binding rather than partial assignment of > the total constraints. Since OMG and the MARTE document both strive for method and design > process independence, it seems inappropriate to become immersed in the complexity of this set > of allocation-related issues. > > Comments? > ________________________________ > Mark Gerhardt > gerhmark@pacbell.net > (650)208-3994 > > __________________________________________________________________________________________________________ > From: Bran Selic > To: Frederic Mallet > Cc: marte-ftf > Sent: Tuesday, March 3, 2009 3:24:12 PM > Subject: Re: [alloc_wg] Issue 13126 > > Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on > this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot > attend. > > If the discussion is still open, here are a few thoughts: > > - One of the objectives of using the current model was to retain consistency with the SysML profile. > There is strong evidence that many people want to use the two together. Unless this change is > synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I > really think that would not be a good thing. > > - Perhaps we need to define allocation more precisely before we make any decisions. What are the use > cases in which we want to use "allocate" in our models. For example, I don't understand what it > means to allocate a PIM to a platform, so I don't see this as a relevant argument against using > dependency. > > - I must admit that using Constraint to model allocation, regardless of its precise meaning that we > may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we > can place the stereotype base class higher in the metamodel. For example, we can think of using the > abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we > could come up with. > > I would strongly urge that this be coordinated with the SysML RTF. > > Cheers...Bran > > On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: > Hi all, > Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". > We are planning to discuss that now during the teleconference. > > Frédéric. > > > > > DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=s1024; d=pacbell.net; h=X-YMail-OSG:Received:X-Mailer:References:Date:From:Subject:To:Cc:MIME-Version:Content-Type:Message-ID; b=mMbWVPiXCk06o6UZVo6q5TH8ANsRiMaLGGMdQtyo5nZ0oDJikdmGRDMwpDkkePhOA1ctT0XWkEqLbos/dJ9DXwjBGuZzovumYbE09g3ZTNwsaHRbrXDgWFz+CLc9zX9/2loL7sqecu5wDY12pC+fYUHSMVtOkqRXcciOn15eLVQ=; X-YMail-OSG: KD1doR4VM1l25RirTM.EfTID0ROITszgmy5frqbVOWkm.y_TFDu_Y5_yLTARk5wUOe8ScntGM0UXvYDgMMVMJ3hMXU61ex2rfHpsl9I3UZq4tr_GrHPlez5jtnbN4YJY9meqUYmGzX7hTaDvxYfOF6AiU59sBJKKxJGXVnCR4vyiSUkKKmFstFS7n7EB50nBvtTXJLhIUnHjfr_jfee.539AUfcQ.9bPlM9ivY1DZuelmU1VoN.1SYp9VVaYErGoyNKhoaKhIAxae.vu318- X-Mailer: YahooMailRC/1155.45 YahooMailWebService/0.7.260.1 Date: Wed, 4 Mar 2009 22:01:23 -0800 (PST) From: Mark Gerhardt Subject: Re: [alloc_wg] Issue 13126 -more thoughts To: cmw@sce.carleton.ca Cc: Bran Selic , Frederic Mallet , marte-ftf , Peter Kortmann Murray, Upon further reflection, if the intent was to make the system adaptive dynamically, then the decision for evaluating the condition to change the clock speed would need an event triggering specification, and binding to an execuatble thread instance which made this decision and changed he property and its effect. Without such a trigger, I assumed that the conditional was to be used by the architect and not by the system itself. Does such a choice need characterization? When is the condition in the property to be evaluated??? ________________________________ Mark Gerhardt gerhmark@pacbell.net (650)208-3994 -------------------------------------------------------------------------------- From: Murray Woodside To: Mark Gerhardt Cc: Bran Selic ; Frederic Mallet ; marte-ftf ; Peter Kortmann Sent: Wednesday, March 4, 2009 4:51:49 PM Subject: Re: [alloc_wg] Issue 13126 Mark, I think this is going even beyond allocation to run-time management. Specification of adaptive flexible systems requires a high-level adaptation functionality that modifies the lower level. Another example is mobile code which may be downloaded into a wireless platform, or executed in a base station, depending on bandwidth and mobile power considerations. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Mark Gerhardt wrote: > Bran, > > Thanks for the feedback. > > In the current draft, there is an example of a conditional within a property annotation which sets the > clock speed based upon the value of utilization (fig 8.10). This seems like a dynamic implementation of > constraints through a conditional property expression. . In fact, the this actually represents an > implementation choice and the selection of "different" platform instances. > > The choices involving characterizing constraints, allocation, conditional properties, and dependencies > between the architecture parts seems to be closely bound to the development and decomposition process > being used. > > My understanding is that specific choices about this type of issue is intended to be outside the scope of > the MARTE specification. Is this his correct? > ________________________________ > Mark Gerhardt > gerhmark@pacbell.net > (650)208-3994 > > __________________________________________________________________________________________________________ > From: Bran Selic > To: Mark Gerhardt > Cc: Frederic Mallet ; marte-ftf ; Peter Kortmann > > Sent: Tuesday, March 3, 2009 4:59:47 PM > Subject: Re: [alloc_wg] Issue 13126 > > Thanks, Mark. I agree that the platform imposes constraints on the software that it runs and it is quite > important to design with these in mind in many cases. In fact, I have written and published a number of > papers precisely on this topic and with that very message. (In fact, I really detest the term PIM for that > reason. However, a PIM is not something that is normally allocated to a platform anyway, that should be > either the PSM or the software itself.) > > However, my concern was that using Constraint to model allocation is really a stretch. You may specify > explicit constraints on both the platform and the application model, but I don't think you should do this > using the allocation concept. These constraints should be defined independently of any allocation. > > I am not sure if this addresses any of your points, though. > > Cheers..Bran > > On Tue, Mar 3, 2009 at 7:14 PM, Mark Gerhardt wrote: > Peter Kortmann and I have been discussing allocation and related topics very recently. The > consequence of an allocation of an executing task instance to a CPU platform introduces a > dependency of its execution time upon the CPU clock speed and memory size. Any constraints > upon the task execution instance like deadline, for example, indirectly and partially > constrains allowable CPU speeds and memory sizes, albeit indirectly. Such concerns blur the > isolation between platform and application but are part of a relevant performance-oriented > decomposition allocation process. > > In this sense allocation is really implementation binding rather than partial assignment of > the total constraints. Since OMG and the MARTE document both strive for method and design > process independence, it seems inappropriate to become immersed in the complexity of this set > of allocation-related issues. > > Comments? > ________________________________ > Mark Gerhardt > gerhmark@pacbell.net > (650)208-3994 > > __________________________________________________________________________________________________________ > From: Bran Selic > To: Frederic Mallet > Cc: marte-ftf > Sent: Tuesday, March 3, 2009 3:24:12 PM > Subject: Re: [alloc_wg] Issue 13126 > > Thanks for sending this, Frederic. I am definitely curious about the conclusions reached, if any, on > this proposal. Unfortunately, the MARTE telecons occur at 2 in the morning for me, so I cannot > attend. > > If the discussion is still open, here are a few thoughts: > > - One of the objectives of using the current model was to retain consistency with the SysML profile. > There is strong evidence that many people want to use the two together. Unless this change is > synchronized with the SysML RTF, we will add to compatibility issues between the two profiles. I > really think that would not be a good thing. > > - Perhaps we need to define allocation more precisely before we make any decisions. What are the use > cases in which we want to use "allocate" in our models. For example, I don't understand what it > means to allocate a PIM to a platform, so I don't see this as a relevant argument against using > dependency. > > - I must admit that using Constraint to model allocation, regardless of its precise meaning that we > may yet need to agree on, seems to me to be a real stretch of the notion of constraint. Perhaps we > can place the stereotype base class higher in the metamodel. For example, we can think of using the > abstract metaclass Relationship, which strikes me as general enough to fit almost any definition we > could come up with. > > I would strongly urge that this be coordinated with the SysML RTF. > > Cheers...Bran > > On Tue, Mar 3, 2009 at 10:05 AM, Frederic Mallet wrote: > Hi all, > Concerning issue 13126, we are proposing a modification to the stereotype "Allocate". > We are planning to discuss that now during the teleconference. > > Frédéric. > > > > >Subject: RE: [alloc_wg] Issue 13126 Date: Thu, 5 Mar 2009 08:34:35 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [alloc_wg] Issue 13126 Thread-Index: AcmdG426SPMrdUdVSg6P214zpanCigARSA+Q From: "BERNARD, Yves" To: "Bran Selic" Cc: , "Frederic Mallet" , "marte-ftf" X-OriginalArrivalTime: 05 Mar 2009 07:34:36.0504 (UTC) FILETIME=[D5BDB580:01C99D64] In the absolute, it would be my prefered solution but I worry about the delay, not to mention that tool vendors will probably be relunctant to support a modification of the UML meta-model. Then, once this modification will be accepted, we will still have to wait for the alignment of the MARTE and SysML specifications and for the corresponding implementation in the tools... I don't say we must not do that but I do think we need temporary solution that is both relevant and low-cost, waiting for the "right" one. My opinion is that the "constraint-based" proposal is convenient from this point of view. Cheers, Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mercredi 4 mars 2009 23:50 À : BERNARD, Yves Cc : cmw@sce.carleton.ca; Frederic Mallet; marte-ftf Objet : Re: [alloc_wg] Issue 13126 Just to point out that it is not against OMG rules for one specification to recommend a change in another specification on which it depends -- even for an FTF. If we agree that something is missing in UML, it is possible to propose a resolution that recommends a change in UML. This, of course, needs to be coordinated with the UML RTF, but I suspect this one will not be too problematic -- no one likes the current deployment model. Perhaps we can fix two problems with one stone? Bran On Wed, Mar 4, 2009 at 11:48 AM, BERNARD, Yves wrote: Hello, I agree that allocation a new kind of relationship. The point is that - as pointed out by Frédéric - the "right" meta-class doesn't exist so far in UML and we're not able to add it in a profile. Nevertheless, we definitly need to be able to specify allocation without adding any dependencies between allocated elements. That's our point. As already said, we have studied and discussed several candidates. None of them is the perfect one, all of them have drawbacks, including the choice of the abstract meta-class (Directed)Relationship because all the concrete classes that could be actually used would add undesirable semantics to our "allocations". If we agree that: "the allocation implies constraints that state the cost of the allocation, in terms of time, power, area, ...", then "Constraint" is not a so bad choice, I think. Cheers, 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 -----Message d'origine----- De : Murray Woodside [mailto:cmw@sce.carleton.ca] Envoyé : mercredi 4 mars 2009 16:51 À : Frederic Mallet Cc : Bran Selic; marte-ftf; BERNARD, Yves Objet : Re: [alloc_wg] Issue 13126 I think an allocation would be a new kind of relationship. Many of the candidatesw you list are relationships between an entity, and a transformation or different version of itself (e.g. abstraction, realization)... allocation is quite different from that. It is an introduced relationship rather than an intrinsic relationship, I think. Murray Woodside Distinguished Research Professor Dept of Systems and Computer Engineering, Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca (http://www.sce.carleton.ca/faculty/woodside.html) On Wed, 4 Mar 2009, Frederic Mallet wrote: > That is exactly why I said the vocabulary application/executionPlatform was > problematic. > > I may agree with your general definition of allocation but in that case my > questions are : > When you modify the processes, do you necessarily modify the functionality ? > When you modify the virtual machines, do you necessarily modify the processes > ? > When you modify the resource pools, do you necessarily modify the resources > themselves ? > > Because this is exactly what is implied by a dependency ! > > A relationship fits better but as I said a Relationship (or a > DirectedRelationship) is an abstract metaclass and when you apply your > stereotype, you need a concrete element. The candidates for > DirectedRelationship are : > > Abstraction, ComponentRealization, Dependency, Deployment, ElementImport, > Extend, Generalization, Include, InformationFlow, InterfaceRealization, > Manifestation, PackageImport, PackageMerge, ProfileApplication, > ProtocolConformance, Realization, Substitution, TemplateBinding, Usage > > Which one of these would you choose to represent any of the allocation you > described ? > > I agree that the constraint is only implied by the allocation but using a > dependency has some drawbacks and is not satisfactory. > Using a constraint is not plainly satisfactory but has a minimal impact. > What we really need is either a new metaclass (not with a profile) or making > DirectedRelationship concrete (not with a Profile). > > Frédéric. > > Murray Woodside a écrit : >> Allocation is unfortunately a much more general concept than allocating an >> application to a platform. Functionality is allocated to processes, >> processes are allocated to a virtual machine, and resources may be >> allocated to resource pools, just for some examples. What allocation is >> doing in these cases is imposing structure on a less structured system. >> >> For generality, alternative allocations should be possible. If only a >> single allocation is possible then the potential of MDE is thrown away. >> Then it is essential that the allocation should cleanly factor out of the >> desicription before allocation... so that alternative allocations can be >> considered. >> >> To me this suggests that a relationship fits better. If it is a dependency, >> it is an introduced dependency conditional on the allocation. And the >> constraints due to allocation are results of the dependency, not the >> allocation itself. >> >> >> Murray Woodside >> >> Distinguished Research Professor >> Dept of Systems and Computer Engineering, >> Carleton University, 1125 Colonel By Drive, Ottawa K1S 5B6, Canada. >> (613)-520-5721.....fax (613)-520-5727....cmw@sce.carleton.ca >> (http://www.sce.carleton.ca/faculty/woodside.html) >> > 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:mime-version:received:date:message-id:subject :from:to:cc:content-type; bh=LQVQO/sSr+nlhSe1zt+X7g2qD9WdzlIzsVANrTf4R8c=; b=VKZYNkptnuTtVm2WnsAcpcS00XhdOiG7fRqxfHIrAJbWhQ18dW18LRRCbvxiZV4lM6 cvp4EmjjboIZZXQ5Uc+jWsknEMiOY69XFtzwCNaOc8Kxf1t5f/MK6N4L6t96KEd3NdDY XMf7+gG78GjRE9DahR2Hlnj9N22HEZ6mkhq6Y= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:date:message-id:subject:from:to:cc:content-type; b=cnlJ01jLhDS7lPrefGeWz0aASgCOJTUfluWpggowkYp4Ap+/zWELDXqE9kV/zs0fQZ cSVl1isNzEtp1CpBJHCHeeNrDS459JoIJsBacBqUQ8/P2T4PSaaNkxxiHag9mIDQMFrP tALejRota9oZ6jc3ZkIiTZxZVAGQ2a25j8cM4= Date: Wed, 1 Apr 2009 22:25:51 -0400 Subject: Problems with resolution to issue 13126 From: Bran Selic To: GERARD Sebastien 166342 Cc: marte-ftf My apologies for raising this after the deadline for the formal discussion period for ballot 3 has expired, but, in reviewing the resolution for issue 13126 (changing the base class for the Allocate stereotype), I am still bothered by the current proposalve. We can certainly stretch the interpretation of the word "constraint" but it really has a very contrived feel to it. Furthermore, from the point of view of the UML metamodel Constraint does not seem like a good fit as a base class, since it has two key properties, constraintedElement and specification, which do not seem to be used at all for Allocate. (NB: if the argument is that an allocation "constrains" the allocated elements in some way, why wasn't the constrainedElement property of Constraint used?). Note that the multiplicity for specification (a kind of ValueSpecification) is 1, which means that a value has to be supplied for Allocations -- but I could not find any suggestion in the resolution on what value to provide here. (It seems, at the very least, that the current proposal is incomplete.) My suggestion is, that in the absence of what we really need in the UML metamodel (i.e., either making DirectedRelationship concrete or providing a new UML metaclass (I prefer the former)), why don't we use PackageableElement instead? (I was also thinking of using RedefineableElement since I can conceive of situations where we may want to override a particular allocation, but, it turns out that RedefineableElement is not a kind of PackageableElement, which would cause problems). Would it be possible to defer this resolution for one more ballot to discuss this issue, especially given the problem of what to do with Constraint::specification? Cheers...Bran Subject: RE: Problems with resolution to issue 13126 Date: Thu, 2 Apr 2009 09:18:45 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with resolution to issue 13126 Thread-Index: AcmzOl17+fkIkgXkTTWlVPxSF2jNPwAKMUMg From: "GERARD Sebastien 166342" To: "marte-ftf" X-OriginalArrivalTime: 02 Apr 2009 07:18:46.0154 (UTC) FILETIME=[42DACEA0:01C9B363] Hi all, if everyone agree I can transfert it from ballot 3 ro ballot 4. This way we have two more weeks for finalizing the issue. Fred do you agree? -------------------------------------------------------------------------------- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : jeudi 2 avril 2009 04:26 À : GERARD Sebastien 166342 Cc : marte-ftf Objet : Problems with resolution to issue 13126 My apologies for raising this after the deadline for the formal discussion period for ballot 3 has expired, but, in reviewing the resolution for issue 13126 (changing the base class for the Allocate stereotype), I am still bothered by the current proposalve. We can certainly stretch the interpretation of the word "constraint" but it really has a very contrived feel to it. Furthermore, from the point of view of the UML metamodel Constraint does not seem like a good fit as a base class, since it has two key properties, constraintedElement and specification, which do not seem to be used at all for Allocate. (NB: if the argument is that an allocation "constrains" the allocated elements in some way, why wasn't the constrainedElement property of Constraint used?). Note that the multiplicity for specification (a kind of ValueSpecification) is 1, which means that a value has to be supplied for Allocations -- but I could not find any suggestion in the resolution on what value to provide here. (It seems, at the very least, that the current proposal is incomplete.) My suggestion is, that in the absence of what we really need in the UML metamodel (i.e., either making DirectedRelationship concrete or providing a new UML metaclass (I prefer the former)), why don't we use PackageableElement instead? (I was also thinking of using RedefineableElement since I can conceive of situations where we may want to override a particular allocation, but, it turns out that RedefineableElement is not a kind of PackageableElement, which would cause problems). Would it be possible to defer this resolution for one more ballot to discuss this issue, especially given the problem of what to do with Constraint::specification? Cheers...Bran X-IronPort-AV: E=Sophos;i="4.39,312,1235948400"; d="scan'208";a="37704102" Date: Thu, 02 Apr 2009 09:51:22 +0200 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: GERARD Sebastien 166342 CC: marte-ftf , bran.selic@gmail.com Subject: Re: Problems with resolution to issue 13126 Bran, Sébastien, No problem to delay to ballot 4. Nevertheless they were some intent to use the specification field to describe the constraint itself. In the domain view, we explicitely state that when we allocate something the 'clocks' (activation conditions) on each side are constrained. The first intent was to put a clock constraint in there. Then, people (mainly from NFP) have mentioned that probably other (non functional) properties could also be constrained in the same way. That is why we moved to a NfpConstraint instead of a ClockConstraint. In the examples, I wanted to put some constraints but I did not dare to keep the message simple because I would have put the constraints in CCSL which is only described much later. For instance in example 11.7 when allocating a cpu to a processor we want to say either that the clocks are identical (in CCSL, cpu = processor) or that at least the cpu clock is a sub clock of the processor clock (in CCSL, cpu isSubclockOf processor). The same thing happens when you allocate a thread on a process. (thread isSublockOf process), which means that the CPU time allocated to the process must be shared between all threads. This is also the meaning implied by the temporalScheduling attribute. Another example is when you allocate a process to two processors (p1, p2), you may want to say something like that (process isSubClockOf (p1 union p2)), which means that the process can use the union of the processing power of p1 and p2, must not more. When you have nothing to say, you can say something like (a # b), this is most of the time the case for spatial distributions. Its that latter case, we want to state the the area (or the memory or the energy) is to be shared amongst all the allocated elements. The other interest I saw with Constraint was that there was nothing to do to implement it correctly. With PackageableElement, any of those things could become an allocation: Abstraction, Activity, Actor, AnyReceiveEvent, Artifact, Association, AssociationClass, Behavior, BehavioredClassifier, CallEvent, ChangeEvent, Class, Classifier, Collaboration, CommunicationPath, Component, ComponentRealization, Constraint, CreationEvent, DataType, Dependency, Deployment, DeploymentSpecification, DestructionEvent, Device, Duration, DurationConstraint, DurationInterval, DurationObservation, EncapsulatedClassifier, Enumeration, EnumerationLiteral, Event, ExecutionEnvironment, ExecutionEvent, Expression, Extension, FunctionBehavior, GeneralizationSet, InformationFlow, InformationItem, InstanceSpecification, InstanceValue, Interaction, InteractionConstraint, Interface, InterfaceRealization, Interval, IntervalConstraint, LiteralBoolean, LiteralInteger, LiteralNull, LiteralSpecification, LiteralString, LiteralUnlimitedNatural, Manifestation, MessageEvent, Model, Node, Observation, OpaqueBehavior, OpaqueExpression, Package, PrimitiveType, Profile, ProtocolStateMachine, Realization, ReceiveOperationEvent, ReceiveSignalEvent, SendOperationEvent, SendSignalEvent, Signal, SignalEvent, StateMachine, Stereotype, StringExpression, StructuredClassifier, Substitution, TimeConstraint, TimeEvent, TimeExpression, TimeInterval, TimeObservation, Type, Usage, UseCase, ValueSpecification In that case, it would probably be simpler to choose one of these (like Package, which was previously suggested). The problems being that this will be: - difficult to implement since currently most of tools do not allow adding packages everywhere. It is also the case for PackageableElement, what PackageableElement would you choose in a StateMachine, or in a Activity. The only one that might fit seems to be OpaqueBehavior ? - difficult to convince people to represent a Package with a dashed arrow line - difficult to convince people that a UseCase, TimeConstraint, CallEvent are allocations. Unless we restrict it to apply only to pure PackageableElement and not any of its specializations. Ready to start the discussion, Frédéric. GERARD Sebastien 166342 a écrit : Hi all, if everyone agree I can transfert it from ballot 3 ro ballot 4. This way we have two more weeks for finalizing the issue. Fred do you agree? ------------------------------------------------------------------------ *De :* Bran Selic [mailto:bran.selic@gmail.com] *Envoyé :* jeudi 2 avril 2009 04:26 *À :* GERARD Sebastien 166342 *Cc :* marte-ftf *Objet :* Problems with resolution to issue 13126 My apologies for raising this after the deadline for the formal discussion period for ballot 3 has expired, but, in reviewing the resolution for issue 13126 (changing the base class for the Allocate stereotype), I am still bothered by the current proposalve. We can certainly stretch the interpretation of the word "constraint" but it really has a very contrived feel to it. Furthermore, from the point of view of the UML metamodel Constraint does not seem like a good fit as a base class, since it has two key properties, /constraintedElement/ and /specification/, which do not seem to be used at all for Allocate. (NB: if the argument is that an allocation "constrains" the allocated elements in some way, why wasn't the /constrainedElement/ property of Constraint used?). Note that the multiplicity for /specification/ (a kind of ValueSpecification) is 1, which means that a value has to be supplied for Allocations -- but I could not find any suggestion in the resolution on what value to provide here. (It seems, at the very least, that the current proposal is incomplete.) My suggestion is, that in the absence of what we really need in the UML metamodel (i.e., either making DirectedRelationship concrete or providing a new UML metaclass (I prefer the former)), why don't we use PackageableElement instead? (I was also thinking of using RedefineableElement since I can conceive of situations where we may want to override a particular allocation, but, it turns out that RedefineableElement is not a kind of PackageableElement, which would cause problems). Would it be possible to defer this resolution for one more ballot to discuss this issue, especially given the problem of what to do with /Constraint::specification/? Cheers...Bran DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=C9O2YGB+j5kOeEhCZKol4zmoSIO81OkGArazoCvrtnM=; b=lKtAcu1A+BIc4kphrEzvy5W8uN3pibBskGzWbkjXBo/e1FIMNEBPq3DZ4YKkKjP6Ua NsGbYcCSg2J5tigIYdkse+S0GmVbdTXujMl7NVz849uRhcTgYpliH0J4qjJu9Xiomjb5 I0e7ILTx4fg4+XOTOFu12QwmDCoGWsO34CUXU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=l1Jkv/CvDUF6+Ipi4GKU1M8Bikym/wt9BnE1lKTuU1lJQEYSGDDHK94phG8Iq59oeN DiI1DL3tnNqSY6WD3tvMr+aOP7JPISR0D05UrUH095N9jK2tgeoZ+NdDISmu69m8V6V5 AfyKcrfK4PKVTFaqswlJaJZ2dwQXFvgmRTLbY= Date: Thu, 2 Apr 2009 21:59:45 -0400 Subject: Re: Problems with resolution to issue 13126 From: Bran Selic To: Frederic Mallet Cc: GERARD Sebastien 166342 , marte-ftf Frederic, Comments below: On Thu, Apr 2, 2009 at 3:51 AM, Frederic Mallet wrote: Bran, Sébastien, No problem to delay to ballot 4. Thanks for your understanding. Let's see what we can do in the next couple of days with this. Nevertheless they were some intent to use the specification field to describe the constraint itself. Perhaps then, this could be added to your proposal? As it stands, it is unclear what this field is for, since it currently sounds like a constraint without a specification. In the domain view, we explicitely state that when we allocate something the 'clocks' (activation conditions) on each side are constrained. My apologies, but I am confused. What do clocks have to do with allocation? Are you talking about some special type of allocation? The first intent was to put a clock constraint in there. Then, people (mainly from NFP) have mentioned that probably other (non functional) properties could also be constrained in the same way. That is why we moved to a NfpConstraint instead of a ClockConstraint. The proposed resolution explicitly states that "we do not claim that an allocation is a constraint". From the above, you seem to be saying that it is. In the examples, I wanted to put some constraints but I did not dare to keep the message simple because I would have put the constraints in CCSL which is only described much later. For instance in example 11.7 when allocating a cpu to a processor we want to say either that the clocks are identical (in CCSL, cpu = processor) or that at least the cpu clock is a sub clock of the processor clock (in CCSL, cpu isSubclockOf processor). Again, I am confused by the mention of clocks on what I view as a much more general problem. I can see clocks being relevant in some types of allocation but not all. What am I missing? The same thing happens when you allocate a thread on a process. (thread isSublockOf process), which means that the CPU time allocated to the process must be shared between all threads. This is also the meaning implied by the temporalScheduling attribute. Another example is when you allocate a process to two processors (p1, p2), you may want to say something like that (process isSubClockOf (p1 union p2)), which means that the process can use the union of the processing power of p1 and p2, must not more. When you have nothing to say, you can say something like (a # b), this is most of the time the case for spatial distributions. Its that latter case, we want to state the the area (or the memory or the energy) is to be shared amongst all the allocated elements. This sounds like a generalization that may be of interest, but can you describe it more precisely? It is certainly useful to be able to add information to an allocation, providing some additional characteristics. (In fact, this is precisely why we chose Abstraction as the base class for allocation in SPT. However, as pointed out in the issue itself, Abstraction has the problem that it changes the client.) The other interest I saw with Constraint was that there was nothing to do to implement it correctly. Well, it seems that you have to provide something for specification at least. So, in a sense, the problem is being passed to the modeler, who may have no clue what value to put in there. With PackageableElement, any of those things could become an allocation: Abstraction, Activity, Actor, AnyReceiveEvent, Artifact, Association, AssociationClass, Behavior, BehavioredClassifier, CallEvent, ChangeEvent, Class, Classifier, Collaboration, CommunicationPath, Component, ComponentRealization, Constraint, CreationEvent, DataType, Dependency, Deployment, DeploymentSpecification, DestructionEvent, Device, Duration, DurationConstraint, DurationInterval, DurationObservation, EncapsulatedClassifier, Enumeration, EnumerationLiteral, Event, ExecutionEnvironment, ExecutionEvent, Expression, Extension, FunctionBehavior, GeneralizationSet, InformationFlow, InformationItem, InstanceSpecification, InstanceValue, Interaction, InteractionConstraint, Interface, InterfaceRealization, Interval, IntervalConstraint, LiteralBoolean, LiteralInteger, LiteralNull, LiteralSpecification, LiteralString, LiteralUnlimitedNatural, Manifestation, MessageEvent, Model, Node, Observation, OpaqueBehavior, OpaqueExpression, Package, PrimitiveType, Profile, ProtocolStateMachine, Realization, ReceiveOperationEvent, ReceiveSignalEvent, SendOperationEvent, SendSignalEvent, Signal, SignalEvent, StateMachine, Stereotype, StringExpression, StructuredClassifier, Substitution, TimeConstraint, TimeEvent, TimeExpression, TimeInterval, TimeObservation, Type, Usage, UseCase, ValueSpecification In that case, it would probably be simpler to choose one of these (like Package, which was previously suggested). How about Comment as a temporary solution until UML is fixed? I realize, this is conceptually as bad a semantic fit as Constraint, but which at least does not have the forced specification problem. It also has the advantage that its annotatedElement attribute can be specialized for the "from" and "to" parameters. The problems being that this will be: - difficult to implement since currently most of tools do not allow adding packages everywhere. It is also the case for PackageableElement, what PackageableElement would you choose in a StateMachine, or in a Activity. The only one that might fit seems to be OpaqueBehavior ? - difficult to convince people to represent a Package with a dashed arrow line - difficult to convince people that a UseCase, TimeConstraint, CallEvent are allocations. Unless we restrict it to apply only to pure PackageableElement and not any of its specializations. Ready to start the discussion, I see two possible alternatives at this time: (1) Supplement the current proposal with additional information on how to deal with Constraint::specification for the Allocation stereotype (perhaps using the generalization that you were hinting at) or (2) Use some obscure metaclass, such as Comment, as the base class for the Allocation stereotype. Cheers...Bran Subject: RE: Problems with resolution to issue 13126 Date: Fri, 3 Apr 2009 09:04:19 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with resolution to issue 13126 Thread-Index: Acmz/+/u0FHjpS6bQWWKFqOabdbYKAAKnZBg From: "BERNARD, Yves" To: "Bran Selic" , "Frederic Mallet" Cc: "GERARD Sebastien 166342" , "marte-ftf" X-OriginalArrivalTime: 03 Apr 2009 07:06:23.0165 (UTC) FILETIME=[B2696ED0:01C9B42A] Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves -----Message d'origine----- De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : vendredi 3 avril 2009 04:00 À : Frederic Mallet Cc : GERARD Sebastien 166342; marte-ftf Objet : Re: Problems with resolution to issue 13126 Frederic, Comments below: On Thu, Apr 2, 2009 at 3:51 AM, Frederic Mallet wrote: Bran, Sébastien, No problem to delay to ballot 4. Thanks for your understanding. Let's see what we can do in the next couple of days with this. Nevertheless they were some intent to use the specification field to describe the constraint itself. Perhaps then, this could be added to your proposal? As it stands, it is unclear what this field is for, since it currently sounds like a constraint without a specification. In the domain view, we explicitely state that when we allocate something the 'clocks' (activation conditions) on each side are constrained. My apologies, but I am confused. What do clocks have to do with allocation? Are you talking about some special type of allocation? The first intent was to put a clock constraint in there. Then, people (mainly from NFP) have mentioned that probably other (non functional) properties could also be constrained in the same way. That is why we moved to a NfpConstraint instead of a ClockConstraint. The proposed resolution explicitly states that "we do not claim that an allocation is a constraint". From the above, you seem to be saying that it is. In the examples, I wanted to put some constraints but I did not dare to keep the message simple because I would have put the constraints in CCSL which is only described much later. For instance in example 11.7 when allocating a cpu to a processor we want to say either that the clocks are identical (in CCSL, cpu = processor) or that at least the cpu clock is a sub clock of the processor clock (in CCSL, cpu isSubclockOf processor). Again, I am confused by the mention of clocks on what I view as a much more general problem. I can see clocks being relevant in some types of allocation but not all. What am I missing? The same thing happens when you allocate a thread on a process. (thread isSublockOf process), which means that the CPU time allocated to the process must be shared between all threads. This is also the meaning implied by the temporalScheduling attribute. Another example is when you allocate a process to two processors (p1, p2), you may want to say something like that (process isSubClockOf (p1 union p2)), which means that the process can use the union of the processing power of p1 and p2, must not more. When you have nothing to say, you can say something like (a # b), this is most of the time the case for spatial distributions. Its that latter case, we want to state the the area (or the memory or the energy) is to be shared amongst all the allocated elements. This sounds like a generalization that may be of interest, but can you describe it more precisely? It is certainly useful to be able to add information to an allocation, providing some additional characteristics. (In fact, this is precisely why we chose Abstraction as the base class for allocation in SPT. However, as pointed out in the issue itself, Abstraction has the problem that it changes the client.) The other interest I saw with Constraint was that there was nothing to do to implement it correctly. Well, it seems that you have to provide something for specification at least. So, in a sense, the problem is being passed to the modeler, who may have no clue what value to put in there. With PackageableElement, any of those things could become an allocation: Abstraction, Activity, Actor, AnyReceiveEvent, Artifact, Association, AssociationClass, Behavior, BehavioredClassifier, CallEvent, ChangeEvent, Class, Classifier, Collaboration, CommunicationPath, Component, ComponentRealization, Constraint, CreationEvent, DataType, Dependency, Deployment, DeploymentSpecification, DestructionEvent, Device, Duration, DurationConstraint, DurationInterval, DurationObservation, EncapsulatedClassifier, Enumeration, EnumerationLiteral, Event, ExecutionEnvironment, ExecutionEvent, Expression, Extension, FunctionBehavior, GeneralizationSet, InformationFlow, InformationItem, InstanceSpecification, InstanceValue, Interaction, InteractionConstraint, Interface, InterfaceRealization, Interval, IntervalConstraint, LiteralBoolean, LiteralInteger, LiteralNull, LiteralSpecification, LiteralString, LiteralUnlimitedNatural, Manifestation, MessageEvent, Model, Node, Observation, OpaqueBehavior, OpaqueExpression, Package, PrimitiveType, Profile, ProtocolStateMachine, Realization, ReceiveOperationEvent, ReceiveSignalEvent, SendOperationEvent, SendSignalEvent, Signal, SignalEvent, StateMachine, Stereotype, StringExpression, StructuredClassifier, Substitution, TimeConstraint, TimeEvent, TimeExpression, TimeInterval, TimeObservation, Type, Usage, UseCase, ValueSpecification In that case, it would probably be simpler to choose one of these (like Package, which was previously suggested). How about Comment as a temporary solution until UML is fixed? I realize, this is conceptually as bad a semantic fit as Constraint, but which at least does not have the forced specification problem. It also has the advantage that its annotatedElement attribute can be specialized for the "from" and "to" parameters. The problems being that this will be: - difficult to implement since currently most of tools do not allow adding packages everywhere. It is also the case for PackageableElement, what PackageableElement would you choose in a StateMachine, or in a Activity. The only one that might fit seems to be OpaqueBehavior ? - difficult to convince people to represent a Package with a dashed arrow line - difficult to convince people that a UseCase, TimeConstraint, CallEvent are allocations. Unless we restrict it to apply only to pure PackageableElement and not any of its specializations. Ready to start the discussion, I see two possible alternatives at this time: (1) Supplement the current proposal with additional information on how to deal with Constraint::specification for the Allocation stereotype (perhaps using the generalization that you were hinting at) or (2) Use some obscure metaclass, such as Comment, as the base class for the Allocation stereotype. 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 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: Problems with resolution to issue 13126 Date: Fri, 3 Apr 2009 11:55:02 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with resolution to issue 13126 Thread-Index: Acm0OYLtF0P1q4xqR8GplxkCTXfdZgAB/HDQ From: "BERNARD, Yves" To: "Frederic Mallet" Cc: "Bran Selic" , "GERARD Sebastien 166342" , "marte-ftf" X-OriginalArrivalTime: 03 Apr 2009 09:55:02.0932 (UTC) FILETIME=[42435540:01C9B442] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n339tQx7007619 Oh sorry ! I wrote "Element" but I had "Comment" in mind, of course !... So, we are in-line. -----Message d'origine----- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé : vendredi 3 avril 2009 10:52 À : BERNARD, Yves Cc : Bran Selic; GERARD Sebastien 166342; marte-ftf Objet : Re: Problems with resolution to issue 13126 Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : > Hello, > > I have to admit that using Element as base class could have some > noticeable advantages. Frédéric, remember our discussion: we have > indeed identified some cases where there will actually be no > constraint and then where {true} should be used as constraint > specification. > > Using an extension it would be possible to have optional > NFP_Constraints, only when required. > > Cheers, > > Yves 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: Problems with resolution to issue 13126 Date: Fri, 3 Apr 2009 12:05:22 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with resolution to issue 13126 Thread-Index: Acm0PAJWrnEJZvKJThedWdQDsUgmbQAB6olQ From: "BERNARD, Yves" To: Sébastien Demathieu , "Frederic Mallet" , "Bran Selic" , "marte-ftf" Cc: "GERARD Sebastien 166342" X-OriginalArrivalTime: 03 Apr 2009 10:05:22.0685 (UTC) FILETIME=[B3AA22D0:01C9B443] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id n33A5O4E023767 Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : > Element is not a good choice, I would prefer Comment in that case. > Everything (anything) is an Element whereas there are no > specialization of Comment. > Again we have to think about what are the concrete element we will use > in the end. > The second question is are we going to be able to use that with > current tools easily or do we need to wait (6 months, 1 year, for ever) > until tool vendors decided to implement it our way. With Comment, its > looks immediate to me, as with Constraint. > > For Bran, > I was not saying that the allocation is a constraint, but I am saying > (and so is the domain view of MARTE) that allocations > imply constraints. Either that is true or we can cut Chapter 11 out of > MARTE specification. We have distinguished two kinds > of allocation, there are probably others, none have been mentioned > during discussions. TemporalScheduling when, e.g., a thread > is allocated to a process, or a process to a processor. > SpatialDistribution when, e.g., a registerbank is allocated into a > address space > or a memory ... > In all cases, such allocations have a cost, i.e., they imply > constraints. When a process is allocated to a processor, it must share > the CPU > with other processes. When a registerbank is allocated it must share > the memory space. When a processor is allocated to a board, it > has his share of the energy production. > > Between comment with implied constraints and constraint, I think > comment might be a better choice. For allowing no specification (which > should not be the general case, nor the most common case) and allowing > several constraints. > > > Frédéric > > BERNARD, Yves a écrit : >> Hello, >> >> I have to admit that using Element as base class could have some >> noticeable advantages. Frédéric, remember our discussion: we have >> indeed identified some cases where there will actually be no >> constraint and then where {true} should be used as constraint >> specification. >> >> Using an extension it would be possible to have optional >> NFP_Constraints, only when required. >> >> Cheers, >> >> Yves > 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: Problems with resolution to issue 13126 Date: Fri, 3 Apr 2009 14:04:00 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with resolution to issue 13126 Thread-Index: Acm0UY7C30+4hWmNRY+a4aBHgjoZKwAAR8aA From: "BERNARD, Yves" To: Sébastien Demathieu Cc: "Frederic Mallet" , "Bran Selic" , "marte-ftf" , "GERARD Sebastien 166342" X-OriginalArrivalTime: 03 Apr 2009 12:04:00.0692 (UTC) FILETIME=[4653CF40:01C9B454] Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 13:44 À : BERNARD, Yves Cc : Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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.39,318,1235948400"; d="scan'208";a="37783298" Date: Fri, 03 Apr 2009 10:52:24 +0200 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: "BERNARD, Yves" CC: Bran Selic , GERARD Sebastien 166342 , marte-ftf Subject: Re: Problems with resolution to issue 13126 Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves X-IronPort-AV: E=Sophos;i="4.39,338,1235948400"; d="scan'208";a="38052732" Date: Tue, 07 Apr 2009 18:49:02 +0200 From: Frederic Mallet User-Agent: Thunderbird 2.0.0.21 (Windows/20090302) To: GERARD Sebastien 166342 CC: Bran Selic , marte-ftf , "BERNARD, Yves" , Sébastien Demathieu Subject: Re: Problems with resolution to issue 13126 The last proposition was to adopt Comment as a base class but there were no further discussions. I can modify the proposed resolution accordingly if no one objects. Frédéric. GERARD Sebastien 166342 a écrit : Hi Frederic, Could you tell me what is the status for this issue? Do you have reached a consensus and is everybody agree on a common resolution? Thanks, Cheers. Sébastien. ------------------------------------------------------------------------ *De :* BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Envoyé :* vendredi 3 avril 2009 14:04 *À :* Sébastien Demathieu *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* RE: Problems with resolution to issue 13126 Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- *De :* Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] *Envoyé :* mercredi 3 juin 2009 13:44 *À :* BERNARD, Yves *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=nM/gy4vnf9Qg933Z6xQdA6iKYSgM85kn6BRBaC4oD3M=; b=UXoqWvzOuvRMu4eq6Ba/oY3TuqqN9vfrOspapksuEQ70A0tSTVt1QzTZO9NfNcXpad UOf4M/ez8VOnlEBIKtgvN6SEK4SAVtJ9rqN4Isit3v0O7NA+5XTTW933+LTvJnzon1fM aSvdb+O0l4ZBRyXUb0Mnp0ZP2wDLlMThAvZpY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=BHcp4MMxUME2iH+Qo8s8HQ8N5dOB4bQOVfr4NEs4G/lX4pLD1nvxhZYsx5yxkh7HuL nSix7R6f/pYT3FlVy6wq4XYOUBwP3hWKE6cZFM24jFdq/Nh3IgAuX9LKXnd+yH/iVC74 91Ajf6uGZRaP7p4Vaf+bf3z3wVxvimIC/VCxw= Date: Tue, 7 Apr 2009 17:38:13 -0400 Subject: Re: Problems with resolution to issue 13126 From: Bran Selic To: Frederic Mallet Cc: GERARD Sebastien 166342 , marte-ftf , "BERNARD, Yves" , Sébastien Demathieu It seems like the least offensive of a set of bad choices so no objection from me. However, at the same time that we provide a resolution, I suggest that we raise an issue for the UML 2 RTF to resolve. We can also propose some possible resolutions, which might include: (1) make DirectedRelationship concrete rather than abstract (this requires a corresponding notation proposal as well) (2) add a new kind of DirectedRelationship for our purposes (this might run into conflicts with the existing Deployment model in UML) Note that both of these may be considered out of scope for an RTF, so we should probably also ask for this capability in the UML 3 RFI that Steve Cook is working on. Cheers...Bran On Tue, Apr 7, 2009 at 12:49 PM, Frederic Mallet wrote: The last proposition was to adopt Comment as a base class but there were no further discussions. I can modify the proposed resolution accordingly if no one objects. Frédéric. GERARD Sebastien 166342 a écrit : Hi Frederic, Could you tell me what is the status for this issue? Do you have reached a consensus and is everybody agree on a common resolution? Thanks, Cheers. Sébastien. ------------------------------------------------------------------------ *De :* BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Envoyé :* vendredi 3 avril 2009 14:04 *À :* Sébastien Demathieu *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* RE: Problems with resolution to issue 13126 Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- *De :* Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] *Envoyé :* mercredi 3 juin 2009 13:44 *À :* BERNARD, Yves *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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: Wed, 08 Apr 2009 08:41:37 +0200 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: Frederic Mallet CC: GERARD Sebastien 166342 , Bran Selic , marte-ftf , "BERNARD, Yves" Subject: Re: Problems with resolution to issue 13126 Hi Fréderic, Sorry, but I still think that Comment is not the relevant base class for allocations. See rationale below. Sébastien Frederic Mallet a écrit : The last proposition was to adopt Comment as a base class but there were no further discussions. I can modify the proposed resolution accordingly if no one objects. Frédéric. GERARD Sebastien 166342 a écrit : Hi Frederic, Could you tell me what is the status for this issue? Do you have reached a consensus and is everybody agree on a common resolution? Thanks, Cheers. Sébastien. ------------------------------------------------------------------------ *De :* BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Envoyé :* vendredi 3 avril 2009 14:04 *À :* Sébastien Demathieu *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* RE: Problems with resolution to issue 13126 Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- *De :* Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] *Envoyé :* mercredi 3 juin 2009 13:44 *À :* BERNARD, Yves *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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. sebastien.demathieu.vcf DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:cc:content-type; bh=1HWvbH7qf7RWb1grBBoKFftii52Qyb7mj3pKCEqbenE=; b=TjUQfTmzY5cyejxT6fSrLq9npdbzpBFogERFjw1XbyGiT6S40mZtF8jPooG2jNGgwM gZEdqi2kelOTQqAo1fz8KbhfgYrgdn4cR9ToUr+VnXYlVvYBrFzSZIIGxWLF6qsm5lTn t8tS/CmxS3usD1Qc8iyD9IIxWPSS8BuE9sLnI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=hf79OwtPfT2FNPazIZA6Qa8beGilI594LtwZ7ftNPkJxi8dQBV3WPbpui4P4hWFE3Q famHc1n3YMRHVuDUspsf8zmuoRp7FD4nCTQ9FxyhJH3yu/riwVaB6ho2iEsb6T53TA81 FEZICIrRvnVlRFtvTbmHJM6Lpoz7i4/jtV43Q= Date: Wed, 8 Apr 2009 05:07:12 -0400 Subject: Re: Problems with resolution to issue 13126 From: Bran Selic To: Sébastien Demathieu Cc: Frederic Mallet , GERARD Sebastien 166342 , marte-ftf , "BERNARD, Yves" Sebastien, I fully understand your unhappiness with using Comment. So, if you have an alternative, please provide one. If you are still thinking of using Constraint, please make sure you explain what to do with the attributes "inherited" from Constraint, such as "specification" (which has a multiplicity of 1). My primary concern with the previous proposal is that it did not specify what was to be done with them. Cheers...Bran 2009/4/8 Sébastien Demathieu Hi Fréderic, Sorry, but I still think that Comment is not the relevant base class for allocations. See rationale below. Sébastien Frederic Mallet a écrit : The last proposition was to adopt Comment as a base class but there were no further discussions. I can modify the proposed resolution accordingly if no one objects. Frédéric. GERARD Sebastien 166342 a écrit : Hi Frederic, Could you tell me what is the status for this issue? Do you have reached a consensus and is everybody agree on a common resolution? Thanks, Cheers. Sébastien. ------------------------------------------------------------------------ *De :* BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Envoyé :* vendredi 3 avril 2009 14:04 *À :* Sébastien Demathieu *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* RE: Problems with resolution to issue 13126 Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- *De :* Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] *Envoyé :* mercredi 3 juin 2009 13:44 *À :* BERNARD, Yves *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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: Wed, 08 Apr 2009 17:56:38 +0200 From: =?ISO-8859-4?Q?S=E9bastien_Demathieu?= Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: Bran Selic CC: Frederic Mallet , GERARD Sebastien 166342 , marte-ftf , "BERNARD, Yves" Subject: Re: Problems with resolution to issue 13126 Bran, all, Given that we do not have a relevant base metaclass that fits the semantics of allocation, I would suggest not to chose right now, or at least not to chose a single metaclass. That means either: - chosing a very general metaclass : e.g. Element, PackageableElement for which several concrete subclasses fit. - defering this issue until we get a broader consensus. In any case (using Comment, using PackageableElement, leaving as is) we will not have a definitive solution in the context of this FTF. If we chose Comment, it will enlarge the gap between SysML and MARTE, which is a negative-side effect that we do not support. Sébastien Bran Selic a écrit : Sebastien, I fully understand your unhappiness with using Comment. So, if you have an alternative, please provide one. If you are still thinking of using Constraint, please make sure you explain what to do with the attributes "inherited" from Constraint, such as "specification" (which has a multiplicity of 1). My primary concern with the previous proposal is that it did not specify what was to be done with them. Cheers...Bran 2009/4/8 Sébastien Demathieu Hi Fréderic, Sorry, but I still think that Comment is not the relevant base class for allocations. See rationale below. Sébastien Frederic Mallet a écrit : The last proposition was to adopt Comment as a base class but there were no further discussions. I can modify the proposed resolution accordingly if no one objects. Frédéric. GERARD Sebastien 166342 a écrit : Hi Frederic, Could you tell me what is the status for this issue? Do you have reached a consensus and is everybody agree on a common resolution? Thanks, Cheers. Sébastien. ------------------------------------------------------------------------ *De :* BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Envoyé :* vendredi 3 avril 2009 14:04 *À :* Sébastien Demathieu *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* RE: Problems with resolution to issue 13126 Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- *De :* Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] *Envoyé :* mercredi 3 juin 2009 13:44 *À :* BERNARD, Yves *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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. sebastien.demathieu1.vcf Subject: RE: Problems with resolution to issue 13126 Date: Wed, 8 Apr 2009 18:07:05 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: Problems with resolution to issue 13126 Thread-Index: Acm4Yp6QG7IrrLrLQNqFjThqbYwrIAAAVeeg From: "GERARD Sebastien 166342" To: Sébastien Demathieu , "Bran Selic" Cc: "Frederic Mallet" , "marte-ftf" , "BERNARD, Yves" X-OriginalArrivalTime: 08 Apr 2009 16:07:06.0152 (UTC) FILETIME=[10012280:01C9B864] I would advocate to have a better solution than the current one if oissible (and it seems it is) even if it is not the ideal one. The ideal one will come next step. -------------------------------------------------------------------------------- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 8 avril 2009 17:57 À : Bran Selic Cc : Frederic Mallet; GERARD Sebastien 166342; marte-ftf; BERNARD, Yves Objet : Re: Problems with resolution to issue 13126 Bran, all, Given that we do not have a relevant base metaclass that fits the semantics of allocation, I would suggest not to chose right now, or at least not to chose a single metaclass. That means either: - chosing a very general metaclass : e.g. Element, PackageableElement for which several concrete subclasses fit. - defering this issue until we get a broader consensus. In any case (using Comment, using PackageableElement, leaving as is) we will not have a definitive solution in the context of this FTF. If we chose Comment, it will enlarge the gap between SysML and MARTE, which is a negative-side effect that we do not support. Sébastien Bran Selic a écrit : Sebastien, I fully understand your unhappiness with using Comment. So, if you have an alternative, please provide one. If you are still thinking of using Constraint, please make sure you explain what to do with the attributes "inherited" from Constraint, such as "specification" (which has a multiplicity of 1). My primary concern with the previous proposal is that it did not specify what was to be done with them. Cheers...Bran 2009/4/8 Sébastien Demathieu Hi Fréderic, Sorry, but I still think that Comment is not the relevant base class for allocations. See rationale below. Sébastien Frederic Mallet a écrit : The last proposition was to adopt Comment as a base class but there were no further discussions. I can modify the proposed resolution accordingly if no one objects. Frédéric. GERARD Sebastien 166342 a écrit : Hi Frederic, Could you tell me what is the status for this issue? Do you have reached a consensus and is everybody agree on a common resolution? Thanks, Cheers. Sébastien. ------------------------------------------------------------------------ *De :* BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Envoyé :* vendredi 3 avril 2009 14:04 *À :* Sébastien Demathieu *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* RE: Problems with resolution to issue 13126 Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- *De :* Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] *Envoyé :* mercredi 3 juin 2009 13:44 *À :* BERNARD, Yves *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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: Wed, 08 Apr 2009 18:17:01 +0200 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: GERARD Sebastien 166342 CC: Bran Selic , Frederic Mallet , marte-ftf , "BERNARD, Yves" Subject: Re: Problems with resolution to issue 13126 Sébastien, Agreed on the principle to have a better solution that the current one if possible. The question is: is using Comment a better solution given its side-effects? Sébastien GERARD Sebastien 166342 a écrit : I would advocate to have a better solution than the current one if oissible (and it seems it is) even if it is not the ideal one. The ideal one will come next step. -------------------------------------------------------------------------------- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 8 avril 2009 17:57 À : Bran Selic Cc : Frederic Mallet; GERARD Sebastien 166342; marte-ftf; BERNARD, Yves Objet : Re: Problems with resolution to issue 13126 Bran, all, Given that we do not have a relevant base metaclass that fits the semantics of allocation, I would suggest not to chose right now, or at least not to chose a single metaclass. That means either: - chosing a very general metaclass : e.g. Element, PackageableElement for which several concrete subclasses fit. - defering this issue until we get a broader consensus. In any case (using Comment, using PackageableElement, leaving as is) we will not have a definitive solution in the context of this FTF. If we chose Comment, it will enlarge the gap between SysML and MARTE, which is a negative-side effect that we do not support. Sébastien Bran Selic a écrit : Sebastien, I fully understand your unhappiness with using Comment. So, if you have an alternative, please provide one. If you are still thinking of using Constraint, please make sure you explain what to do with the attributes "inherited" from Constraint, such as "specification" (which has a multiplicity of 1). My primary concern with the previous proposal is that it did not specify what was to be done with them. Cheers...Bran 2009/4/8 Sébastien Demathieu Hi Fréderic, Sorry, but I still think that Comment is not the relevant base class for allocations. See rationale below. Sébastien Frederic Mallet a écrit : The last proposition was to adopt Comment as a base class but there were no further discussions. I can modify the proposed resolution accordingly if no one objects. Frédéric. GERARD Sebastien 166342 a écrit : Hi Frederic, Could you tell me what is the status for this issue? Do you have reached a consensus and is everybody agree on a common resolution? Thanks, Cheers. Sébastien. ------------------------------------------------------------------------ *De :* BERNARD, Yves [mailto:Yves.Bernard@airbus.com] *Envoyé :* vendredi 3 avril 2009 14:04 *À :* Sébastien Demathieu *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* RE: Problems with resolution to issue 13126 Agree. Starting with something like DirectedRelationship has been evocated. I think it's the way to go, but we need a concrete meta-class, what is out of the RTF scope. -----Message d'origine----- *De :* Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] *Envoyé :* mercredi 3 juin 2009 13:44 *À :* BERNARD, Yves *Cc :* Frederic Mallet; Bran Selic; marte-ftf; GERARD Sebastien 166342 *Objet :* Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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. sebastien.demathieu2.vcf Date: Wed, 03 Jun 2009 11:10:14 +0200 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: Frederic Mallet , "BERNARD, Yves" , Bran Selic , marte-ftf CC: GERARD Sebastien 166342 Subject: Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves sebastien.demathieu3.vcf Date: Wed, 03 Jun 2009 13:44:26 +0200 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: "BERNARD, Yves" CC: Frederic Mallet , Bran Selic , marte-ftf , GERARD Sebastien 166342 Subject: Re: Problems with resolution to issue 13126 No problem. But I keep thinking that using a more general metaclass than Comment (e.g. Element, PackageableElement) would avoid us enforcing something that will most likely change in the future versions of the standard. Thanks, Sébastien BERNARD, Yves a écrit : Sorry for the "noise" Sébastien. There was a an error in my mail. My point is to consider Bran's proposal to use Comment instead of Constraint as the base class. Element would be worst than PackageableElement... Yves -----Message d'origine----- De : Sébastien Demathieu [mailto:sebastien.demathieu@thalesgroup.com] Envoyé : mercredi 3 juin 2009 11:10 À : Frederic Mallet; BERNARD, Yves; Bran Selic; marte-ftf Cc : GERARD Sebastien 166342 Objet : Re: Problems with resolution to issue 13126 All, I second Yves' proposal. The use of Element would address today the issue that has been raised while facilitating transition to a more adapted, concrete metaclass in the future. Note that this notion of allocation is shared among several OMG specifications, such as SysML. Similar issues have been raised in the SysML and UML RTF. We can contribute to the definition of a solution at a UML level. Meanwhile, we propose a solution in MARTE that does not conflict with the other specifications. Thanks, Sébastien Frederic Mallet a écrit : Element is not a good choice, I would prefer Comment in that case. Everything (anything) is an Element whereas there are no specialization of Comment. Again we have to think about what are the concrete element we will use in the end. The second question is are we going to be able to use that with current tools easily or do we need to wait (6 months, 1 year, for ever) until tool vendors decided to implement it our way. With Comment, its looks immediate to me, as with Constraint. For Bran, I was not saying that the allocation is a constraint, but I am saying (and so is the domain view of MARTE) that allocations imply constraints. Either that is true or we can cut Chapter 11 out of MARTE specification. We have distinguished two kinds of allocation, there are probably others, none have been mentioned during discussions. TemporalScheduling when, e.g., a thread is allocated to a process, or a process to a processor. SpatialDistribution when, e.g., a registerbank is allocated into a address space or a memory ... In all cases, such allocations have a cost, i.e., they imply constraints. When a process is allocated to a processor, it must share the CPU with other processes. When a registerbank is allocated it must share the memory space. When a processor is allocated to a board, it has his share of the energy production. Between comment with implied constraints and constraint, I think comment might be a better choice. For allowing no specification (which should not be the general case, nor the most common case) and allowing several constraints. Frédéric BERNARD, Yves a écrit : Hello, I have to admit that using Element as base class could have some noticeable advantages. Frédéric, remember our discussion: we have indeed identified some cases where there will actually be no constraint and then where {true} should be used as constraint specification. Using an extension it would be possible to have optional NFP_Constraints, only when required. Cheers, Yves 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. sebastien.demathieu5.vcf