Issue 12418: GQAM Domain view inheritances (marte-ftf) Source: Universidad de Cantabria (Dr. Julio Medina, julio.medina(at)unican.es) Nature: Revision Severity: Critical Summary: In the GQAM Domain view GQAM::GQAM_Resources::CommunicationHost should inherit from GRM::ResourceTypes::CommunicationMedia, and GQAM::GQAM_Resources::ExecutionHost should inherit from GRM::ResourceTypes::ComputingResource. This said from a conceptual point of view, seems to indicate that also the corresponding elements in the profile should keep this inheritance relationship with the corresponding elements in GRM. The names of attributes should be consistent or at least related semantically to those in GRM. This may required some minor structural changes since in GQAM platform elements include semantics form various elements in GRM like for example the scheduler as well as the processing resource. Resolution: Include in GQAM::GQAM_Resources::CommunicationHost the inheritance from GRM::ResourceTypes::CommunicationMedia. And in GQAM::GQAM_Resources::ExecutionHost inheritance from GRM::ResourceTypes::ComputingResource. Correspondingly update the profile, making GQAM::GaExecHost inherit from GRM::ComputingResource, and GQAM::GaCommHost inherit from GRM::CommunicationMedia. According to issue 11835 already resolved in ballot 2, some attributes in GQAM::GaCommHost are now inherited from GRM::CommunicationMedia, these attributes are: o bandwidth: NFP_DataTxRate [0..1] capacity of the communication element when applicable. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. The only difference is in the name of the attribute "bandwith" which is called "capacity" in GQAM. Since both of them represent the same concept one of the two should prevail; "capacity" is preferred as it is more general. As mentioned, this impact previous resolution of issue 11835, and as a duplicated also issue 11842. Attributes schedPolicy and isPreemptible in SaExecutionHost and SaExecHost are now redundant since they are inherited transitively from Scheduler. Revised Text: (6) In section 15.3.2.4 add generalization o CommunicationMedia (from MARTE::GRM) (7) In section 15.3.2.4 remove the attributes: o capacity: NFP_DataTxRate [0..1] capacity of the communication element when applicable. o packetT: NFP_Duration [0..1] time to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. o blockT: NFP_Duration [0..1] time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum. o transmMode: MARTE_Library::MARTE_DataTypes::TransmModeKind [0..1] defines the transmission mode, one of the following values: {simplex, half-duplex, full-duplex}. (8) In section 15.3.2.7 add generalization o ComputingResource (from MARTE::GRM) (9) Change Figure 15.9 to show these inheritances as well as those from scheduler introduced in ballot1, and not to show the removed attributes. Use this: (10) In section F10.5 CommunicationHost add generalization o CommunicationMedia (from MARTE::GRM) (11) In section F.10.5 remove attributes: capacity, packetTime, blockingTime, and transmMode (12) In section F.10.8 ExecutionHost add generalization o ComputingResource (from MARTE::GRM) (13) Change Figure 15.5 to show these inheritances as well as those from scheduler introduced in ballot1, and not to show the removed attributes, use this: (14) Consistently with resolution of Issue 11835 change Figure 10.8 to show the attributes capacity, packetTime, blockingTime, and transmMode in the definition of the CommunicationMedia concept, use this: (15) Consistently with resolution of Issue 11835, in the bulleted paragraph aboveFigure 10.8, add a text presenting the attributes: Old Text: As shown in Figure 10.8, two kinds of CommunicationResources are defined. A communication media has an attribute for defining the size of the elements transmitted; as expected, this definition is related to the resource base clock. For example, if the communication media represents a bus, and the clock is the bus speed, "element size" would be the width of the bus, in bits. If the communication media represents a layering of protocols, "element size" would be the frame size of the uppermost protocol. A communication endpoint acts as a terminal for connecting to a communication media, and it is characterized by the size of the packet handled by the endpoint. This size may or may not correspond to the media element size. New Text: As shown in Figure 10.8, two kinds of CommunicationResources are defined. A communication media has an attribute for defining the size of the elements transmitted; as expected, this definition is related to the resource base clock. For example, if the communication media represents a bus, and the clock is the bus speed, "element size" would be the width of the bus, in bits. If the communication media represents a layering of protocols, "element size" would be the frame size of the uppermost protocol. It has also an attribute indicating the capacity of the communication element when it is applicable. For timing evaluations, it holds also the time it takes to transmit the element used as a communication quantum, usually called a packet, the size in bits of this quantum is described by the attribute elementSize. It may have also the specification of the time the communicationMedia is blocked and cannot transmit due to the transmission of one communication quantum, and the transmission mode available (simplex, half-duplex, or full-duplex). A communication endpoint acts as a terminal for connecting to a communication media, and it is characterized by the size of the packet handled by the endpoint. This size may or may not correspond to the media element size. (16) Consistently with resolution of Issue 11835 change Figure 10.14 to show the attributes capacity, packetT, blockT, and transmMode in the stereotype CommunicationMedia, use this: (17) In Section 10.3.2.4, on page 101, use "capacity" in this bullet phrase instead of "bandwith", which is the name used in issue 11835: o capacity: NFP_DataTxRate [0..1] capacity of the communication element when applicablelink. (18) Remove attributes schedPolicy and isPreemptible in section 16.3.2.5 (page 300) and in section F.11.5 (page 611), they are inherited from scheduler. (19) Accordingly change figure 16.6 by this: (20) And change Figure 16.9 by this: Actions taken: April 25, 2008: received issue February 17, 2010: closed issue Discussion: see ptc/2008-06-05 for revised figures End of Annotations:===== From: webmaster@omg.org Date: 25 Apr 2008 14:01:50 -0400 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Julio Medina Company: Universidad de Cantabria mailFrom: julio.medina@unican.es Notification: Yes Specification: GQAM Platform dependencies on GRM (Missing Inheritance and alignment of attribute names Section: GQAM FormalNumber: ptc/07-08-04 Version: Beta 1 RevisionDate: 04/25/2008 Page: 267 and others Nature: Revision Severity: Critical HTTP User Agent: Mozilla/4.0 (compatible; MSIE 7.0; Windows NT 5.1) Description In the GQAM Domain view GQAM::GQAM_Resources::CommunicationHost should inherit from GRM::ResourceTypes::CommunicationMedia, and GQAM::GQAM_Resources::ExecutionHost should inherit from GRM::ResourceTypes::ComputingResource. This said from a conceptual point of view, seems to indicate that also the corresponding elements in the profile should keep this inheritance relationship with the corresponding elements in GRM. The names of attributes should be consistent or at least related semantically to those in GRM. This may required some minor structural changes since in GQAM platform elements include semantics form various elements in GRM like for example the scheduler as well as the processing resource. Date: Tue, 6 May 2008 18:11:45 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: Julio Medina Cc: GERARD Sebastien 166342 , Bran Selic , marte-ftf@omg.org Subject: discussion of including 12418 in ballot3 The substance of this issue is not very great, as CommHost and ExecHost both inherit already from Processing Resource: CommHost would have an additional attribute elementSize CommHost would apply also to Connectors ExecHost would have an additonal attribute speedFactor. These seem to me to be non-controversial and possibly useful, so I would not object to including them. 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 Tue, 6 May 2008, Julio Medina wrote: I'd beg for two issues: 12418 -> add inheritance in gqam: QAM::GQAM_Resources::CommunicationHost should inherit from GRM::ResourceTypes::CommunicationMedia, and GQAM::GQAM_Resources::ExecutionHost should inherit from GRM::ResourceTypes::ComputingResource, this implies to align the attributes in ExecHost and CommHost with those comming from the corresponding processing resources and from scheduler (inserted in Ballot1 without aligning the attribute names) XXXXX -> change multiplicity from 0..1 to * in the association sharedResource from SaStep to SAM_Resources::SharedResource (see Figure 16.4 in SAM) can I? Cheers, Julio GERARD Sebastien 166342 wrote: I think it is possible, but people who want such ballot3 needs to express it very quickly : what issues should be included in this ballot3. --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org Before printing, think about the environment ------------------------------------------------------------------------ De : Bran Selic [mailto:bran.selic@gmail.com] Envoyé : mardi 6 mai 2008 16:27 À : Julio Medina Cc : GERARD Sebastien 166342; marte-ftf@omg.org Objet : Re: Telco of today I just spoke with Charles Andre, and he has some last-minute minor issues he would like to resolve before we close the FTF. I suspect that others may have similar issues. This is why I was proposing a possible quick 3rd ballot -- one that would only deal with minor clean-up issues of this type. It could be a short 1-week ballot period and the results could be relatively easily integrated into the final convenience document. Cheers...Bran On Tue, May 6, 2008 at 9:56 AM, Julio Medina > wrote: Hi Seb, Just a comment about closing the FTF labor. I have the idea that it will depend on the results of the ballot. If it happens to be any resolved issue voted NO by the majority, I imagine these should be re-categorized as "deferred" and a poll be realized among the partners to confirm them as such. It may be worth asking Juergen it this is the situation. If there is no such case i think there is no problem in start writing the final report and editing the spec. Cheers, Julio GERARD Sebastien 166342 wrote: Hi all, We do not finish to compile the vote results for ballot2, it should be available this afternoon CET, so I propose to cancel the telco for today and have one tomorrow (4 pm CET) in order to conclude the ballot2 and also the FTF at the same time. Agree? Séb --------------------------------------------- Dr. Sébastien Gérard Head of the Accord-UML research project CEA LIST/LISE Boîte courrier 65, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Open source UML2 Eclipse plug-in: www.papyrusuml.org > Before printing, think about the environment Date: Tue, 13 May 2008 10:58:16 -0400 (EDT) Subject: agree to including 12418 in ballot3 From: cmw@sce.carleton.ca To: "Julio Medina" Cc: "GERARD Sebastien 166342" , marte-ftf@omg.org, "Bran Selic" , "ESPINOZA Huascar 218344" User-Agent: SquirrelMail/1.4.11 Julio, as I told Seb I am travelling with limited access to email, however I just got in now, and looked at the resolution, I am ok with it. The figs for ch 15 are posted as a visio file on the wiki for ch 15, for another resolution. Murray > Yes, I plan to call him as soon as time gets reasonable to call, around > 9 am there (3 pm CET) > > In the meantime I will prepare the visio pictures, can you send me the > visio file with the GQAM figures please, I remember you did some of > them. I need concretely figure 15.5 and 15.9. > > Thanks > > GERARD Sebastien 166342 wrote: > >> You may have a phone call with him to converge may be ? >> >> --------------------------------------------- >> Dr. Sébastien Gérard >> >> Head of the Accord-UML research project >> CEA LIST/LISE >> Boîte courrier 65, GIF SUR YVETTE >> CEDEX, F-91191 France >> Phone/fax : +33 1 69 08 58 24 / 83 95 >> >> Open source UML2 Eclipse plug-in: www.papyrusuml.org >> >> >> Before printing, think about the environment >> >> -----Message d'origine----- >> De : Julio Medina [mailto:julio.medina@unican.es] >> Envoyé : mardi 13 mai 2008 10:18 >> À : GERARD Sebastien 166342 >> Cc : cmw@sce.carleton.ca; Bran Selic; ESPINOZA Huascar 218344 >> Objet : Re: discussion of including 12418 in ballot3 >> >> Thanks Seb, >> >> I have inserted the tentative resolution in the GRM wiki waiting for >> Murray's comments. >> Cheers, >> >> Julio >> >> GERARD Sebastien 166342 wrote: >> >>>OK: I propose to stop at 6 pm CET and start the voting period at >>> midnight CET. End of voting period for ballot 3 keeps unchanged. >>> >>>Ok? >>> >>>Séb >>> >>>--------------------------------------------- >>>Dr. Sébastien Gérard >>> >>>Head of the Accord-UML research project >>>CEA LIST/LISE >>>Boîte courrier 65, GIF SUR YVETTE >>>CEDEX, F-91191 France >>>Phone/fax : +33 1 69 08 58 24 / 83 95 >>> >>>Open source UML2 Eclipse plug-in: www.papyrusuml.org >>> >>> >>>Before printing, think about the environment >>>-----Message d'origine----- >>>De : Medina Pasaje, Julio Luis [mailto:julio.medina@unican.es] >>>Envoyé : mardi 13 mai 2008 07:19 >>>À : cmw@sce.carleton.ca >>>Cc : GERARD Sebastien 166342; Bran Selic; ESPINOZA Huascar 218344 >>>Objet : RE: discussion of including 12418 in ballot3 >>> >>>Hi Murray, >>> >>>I have respected at the maximum the way GQAM is now working, so there >>> are no sintactical changes. Only it will result a picture a bit bigger >>> due to the inheritances. (I still have to insert the text changes in the >>> domain view, but it is just a following of what I propose here and I >>> would like to send it soon) >>>I imagine you will see this a bit late, but I would prefer to have your >>> opinion before trying to promote a resolution. Please take a look at >>> this resolution to see if we may agree on it for ballot 3 (which is >>> today) >>> >>>Sebastien, would it be possible to wait some more hours until people in >>> the other side of the Atlantic have had time to react please? >>> >>> >>> support to launch the ballot a bit late today start the voting perion >>> >>>________________________________ >>> >>>De: Murray Woodside [mailto:cmw@sce.carleton.ca] >>>Enviado el: mié 07/05/2008 00:11 >>>Para: Medina Pasaje, Julio Luis >>>CC: GERARD Sebastien 166342; Bran Selic; marte-ftf@omg.org >>>Asunto: discussion of including 12418 in ballot3 >>> >>> >>> >>>The substance of this issue is not very great, as CommHost and ExecHost >>>both inherit already from Processing Resource: >>> >>>CommHost would have an additional attribute elementSize >>>CommHost would apply also to Connectors >>>ExecHost would have an additonal attribute speedFactor. >>> >>>These seem to me to be non-controversial and possibly useful, so I would >>>not object to including them. >>> >>>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 Tue, 6 May 2008, Julio Medina wrote: >>> >>> >>> >>>>I'd beg for two issues: >>>> >>>>12418 -> add inheritance in gqam: >>>> QAM::GQAM_Resources::CommunicationHost >>>>should inherit from GRM::ResourceTypes::CommunicationMedia, and >>>>GQAM::GQAM_Resources::ExecutionHost should inherit from >>>>GRM::ResourceTypes::ComputingResource, this implies to align the >>>> attributes >>>>in ExecHost and CommHost with those comming from the corresponding >>>> processing >>>>resources and from scheduler (inserted in Ballot1 without aligning the >>>>attribute names) >>>> >>>>XXXXX -> change multiplicity from 0..1 to * in the association >>>>sharedResource from SaStep to SAM_Resources::SharedResource (see Figure >>>> 16.4 >>>>in SAM) >>>> >>>>can I? >>>> >>>> >>>>Cheers, >>>> >>>>Julio >>>> >>>> >>>>GERARD Sebastien 166342 wrote: >>>> >>>> >>>>>I think it is possible, but people who want such ballot3 needs to >>>>> express >>>>>it very quickly : what issues should be included in this ballot3. >>>>> >>>>> >>>>> >>>>>--------------------------------------------- >>>>> >>>>>Dr. Sébastien Gérard >>>>> >>>>> >>>>>Head of the Accord-UML research project >>>>> >>>>>CEA LIST/LISE >>>>> >>>>>Boîte courrier 65, GIF SUR YVETTE >>>>> >>>>>CEDEX, F-91191 France >>>>> >>>>>Phone/fax : +33 1 69 08 58 24 / 83 95 >>>>> >>>>>Open source UML2 Eclipse plug-in: www.papyrusuml.org >>>>> >>>>> >>>>> >>>>>Before printing, think about the environment >>>>>------------------------------------------------------------------------ >>>>> >>>>>De : Bran Selic [mailto:bran.selic@gmail.com] >>>>>Envoyé : mardi 6 mai 2008 16:27 >>>>>À : Julio Medina >>>>>Cc : GERARD Sebastien 166342; marte-ftf@omg.org >>>>>Objet : Re: Telco of today >>>>> >>>>> >>>>>I just spoke with Charles Andre, and he has some last-minute minor >>>>> issues >>>>>he would like to resolve before we close the FTF. I suspect that >>>>> others may >>>>>have similar issues. This is why I was proposing a possible quick 3rd >>>>>ballot -- one that would only deal with minor clean-up issues of this >>>>> type. >>>>>It could be a short 1-week ballot period and the results could be >>>>>relatively easily integrated into the final convenience document. >>>>> >>>>>Cheers...Bran >>>>> >>>>>On Tue, May 6, 2008 at 9:56 AM, Julio Medina >>>>> wrote: >>>>> >>>>>Hi Seb, >>>>> >>>>>Just a comment about closing the FTF labor. >>>>>I have the idea that it will depend on the results of the ballot. If >>>>> it >>>>>happens to be any resolved issue voted NO by the majority, I imagine >>>>> these >>>>>should be re-categorized as "deferred" and a poll be realized among >>>>> the >>>>>partners to confirm them as such. It may be worth asking Juergen it >>>>> this is >>>>>the situation. >>>>> >>>>>If there is no such case i think there is no problem in start writing >>>>> the >>>>>final report and editing the spec. >>>>> >>>>>Cheers, >>>>> >>>>>Julio >>>>> >>>>>GERARD Sebastien 166342 wrote: >>>>> >>>>>Hi all, >>>>> >>>>>We do not finish to compile the vote results for ballot2, it should be >>>>>available this afternoon CET, so I propose to cancel the telco for >>>>> today >>>>>and have one tomorrow (4 pm CET) in order to conclude the ballot2 and >>>>> also >>>>>the FTF at the same time. >>>>> >>>>> Agree? >>>>> >>>>> Séb >>>>> >>>>> --------------------------------------------- >>>>> >>>>>Dr. Sébastien Gérard >>>>> >>>>>Head of the Accord-UML research project >>>>> >>>>>CEA LIST/LISE >>>>> >>>>>Boîte courrier 65, GIF SUR YVETTE >>>>> >>>>>CEDEX, F-91191 France >>>>> >>>>>Phone/fax : +33 1 69 08 58 24 / 83 95 >>>>> >>>>>Open source UML2 Eclipse plug-in: www.papyrusuml.org >>>>> > >>>>> >>>> >> >>>>> >>>>> >>>>> >>>>>Before printing, think about the environment >>>>> >>>>> >>>>> >>>> >>