Issue 11856: MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part (marte-rtf) Source: ESEO (Dr. Jerome Delatour, jerome.delatour(at)eseo.fr) Nature: Uncategorized Issue Severity: Summary: A simplification of GRM should be envisaged. GRM defines too many detailled concepts (for instance the Scheduler which seems more appropriate in the SRM package), these concepts could be defined in SRM or HRM package or even in SAM package. The way to define different types of services need to be aligned between GRM, SRM and HRM. Resolution: With respect to the status of the FTF, the resolution of this issue would need too much time to be resolved in an efficient and satisfying form. So, I (Sébastien Gérard from CEA LIST) propose to defer it. Disposition: Deferred This issue has been resolved by resolutions to issues 11411 and 11412. A brief modification is necessary in the introduction of GRM to comprise it as generic for also analysis and design. A brief text is to be added to the Introduction of GRM to emphasize its a role of foundation for the analysis packages (GQAM, SAM and PAM) and the DRM (SRM and HRM). Revised Text: Section 10.1, page 85, add to the two elements bulleted list a third item with the following text: • Providing foundational modeling constructs that are later refined to support design (SRM & HRM) as well as analysis (GQAM, SAM & PAM) models. Actions taken: December 21, 2007: received issue January 14, 2011: closed issue Discussion: Discussion: There are two different opinions regarding the proposed re-structuring the concepts in the profile. In the opinion of ESEO: As mentioned for instance in issues 11411 and 11412, regarding GRM and SRM in particular, redundancy emerges between GRM concepts and packages depending on it (SRM, HRM but also SAM and GQAM). The same concept could be redefined twice, and this redefinition will let the designer express the same idea in different MARTE meta-classes (or stereotypes). In addition to a problem of consistency, there is a problem of readability and understanding for the designer. Behind this issue, it is the central role given to GRM and the way Analysis models (GQAM and SAM) and XRM (GRM, SRM and HRM) elements are related which could be discussed. It's not certain that a clear consensus or agreement is reached on this central role of GRM. A broader discussion is needed in order to reach a consensus. Different approaches for resolving this issue are possible. More time is needed to make a better analysis of the advantages/default and change impacts of each one. For theses reasons, this issue is deferred. In the opinion of UC: As mentioned in Issues 11411 and 11412 regarding GRM and SRM in particular, they may get significant "synchronization" by simply including in the SRM stereotypes the inheritance from the corresponding in GRM, but they do not have to be forced to stay totally "synchronized" since they are meant for different purposes, and use and promote very different modeling styles. GRM goes for architectural models that can provide and be extended to lead easily to analysis of the basic NFPs, while the main concern in the current flavor of SRM is to enable easier platform independence through model transformations. Even considering these different modeling intents in the two subprofiles, avoiding inheritance at the profile level seems to indicate that it is due to a matter of purism more than to a technical reason. In response to the issue : (a) GRM is not that complex considering that it must provide the minimum additional elements to UML to deal with design at the architectural level, as well as foundations for design and analysis, design for platform and application oriented models, and finally the hardware and software aspects of the platform. The suggestion to reduce it means probably not comprehension of this multifaceted role, or the implicit assumption that all these different aspects have totally nothing in common, which is wrong. They share the absolute necessity to have at the minimum the capability of being able to do evaluations of a system feasibility even at the very basic level against its non functional properties, and at least its timing properties. (b) For this reason, there must be aspects like scheduling in GRM. The concept of scheduler is crucial for almost all of the mentioned chapters (exception made of HRM probably). The attributes on it are the very basic ones to get the minimal capabilities to say something of the system feasibility in the context of the large majority of applications. Even particular techniques that model explicitly the behavior of the scheduler require this concept at this level of description. Along this discussion, one week before the start of the voting period, this issue has been pushed to create a polemic enough to deserve further attention. More even considering that making such a coarse change in the structure of the standard may require a very deep reformulation. In the opinion of UC this issue should be closed. A better alignment between the different models inside MARTE may be gotten, but restructuring it in the way it seems to be proposed will require a significant number of methodological choices, which may be good for one application or modeling style but not for others. This is a different alternative for standardization, and may lead to a new RFP, in which a concrete number of industrial applications, with their corresponding development styles, analysis techniques, and certification requirements, find precise modeling methodologies and tool support. This may require a per-domain response. Anyway in order to give the community the possibility to elaborate on all these, it has been deferred at this time. Resolution: Defer the issue so that a wider discussion may lead to consensus. Revised Text: Disposition: Deferred End of Annotations:===== ubject: Issue on MARTE Profile : Synchronisation between SRM, GRM, HRM and analysis part User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/23.0.60 (gnu/linux) X-Face: "Yr?`qn'Vpo%>>`}Gy8,f:(+Rl6^?R,GN#zvzc-=!s[3F@B^c8wY >tT(f=vhHfp><3JC4`[fVA|u9LfIKAWic;iTjC(c`$)>yH}/-eU&%M\mG^n>QC*lut$wIgG_ Organization: ESEO X-Home-Page: http://www.eseo.fr/ From: jerome.delatour@eseo.fr Date: Fri, 21 Dec 2007 16:06:45 +0100 X-OriginalArrivalTime: 21 Dec 2007 15:06:44.0313 (UTC) FILETIME=[196ADC90:01C843E3] X-Greylist: Sender is SPF-compliant, not delayed by milter-greylist-3.0 (mail.eseo.fr [172.16.0.6]); Fri, 21 Dec 2007 16:06:44 +0100 (CET) A simplification of GRM should be envisaged. GRM defines too many detailled concepts (for instance the Scheduler which seems more appropriate in the SRM package), these concepts could be defined in SRM or HRM package or even in SAM package. The way to define different types of services need to be aligned between GRM, SRM and HRM. Jérôme Delatour ESEO -- ESEO, Equipe de recherche TRAME 4, rue Merlet de la Boulaye BP 30926 - 49009 Angers cedex 01, France www.eseo.fr/~jdelatour Tel : (33).2.41.86.67.90 From: jerome.delatour@eseo.fr To: Julio Medina Cc: Laurent Rioux , marte-ftf@omg.org Subject: Re: GRM Organization: ESEO User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) X-Face: "Yr?`qn'Vpo%>>`}Gy8,f:(+Rl6^?R,GN#zvzc-=!s[3F@B^c8wY >tT(f=vhHfp><3JC4`[fVA|u9LfIKAWic;iTjC(c`$)>yH}/-eU&%M\mG^n>QC*lut$wIgG_ X-Home-Page: http://www.eseo.fr/ Date: Sat, 26 Apr 2008 09:34:08 +0200 X-OriginalArrivalTime: 26 Apr 2008 07:34:09.0178 (UTC) FILETIME=[EA2857A0:01C8A76F] Hi, I disagree with the explanation given in GRM 11856. In my opinion, it reflects too much the Julio's point of view (mainly in the "concrete part") and minor this issue despite the fact that there are other issues with GQAM and SAM related to the "too detailed GRM" characteristic. I would prefer a less partisan explanation, stating the fact that there isn't a consensus for now, and telling that this issue is deferred in order to let space for further discussion about the role given to GRM and the way Analysis model (GQAM and SAM) and XRM (GRM,SRM and HRM) model element are related. Regards, Jerome PS : More details I will prepare a document in june on this aspect. I disagree with the given description (in the issue 11856) of the SRM role : It's not only a mechanism to be RTOS independent, it's, as its name indicate (Software Resource Model) and as the MARTE text explains , the package where software entities like "thread, process, scheduler..." are described. The fact that there are mechanisms in order to describe RTOS API is just an advantage (not a main objective). If the role of SRM has changed, we need at least to change some explanations in the SRM chapter. During the writing of MARTE, GRM grows more and more. For the domain I know (SRM), GRM had more and more described the software part. For instance, GRM had described part which were already in SRM, for keeping coherency we delete these parts in SRM. It was perhaps a good thing (or perhaps not), but I advocate for a discussion on this aspect (advantages and defaults of this approach). I have the feeling that the same thing occur with SAM, HRM and GQAM. Perhaps, it is interesting to have a larger discussion on this aspect. Julio Medina writes: > Explanation about deferring issue 11856 has been added to the wiki > > Julio > > Laurent Rioux wrote: > >> Julio, >> >> >> >> Please attach a word doc to all issues (even the issue is deferred, >> you have to explain why) GRM/11 856 >> >> >> >> Laurent >> -- ESEO, Equipe de recherche TRAME 4, rue Merlet de la Boulaye BP 30926 - 49009 Angers cedex 01, France www.eseo.fr/~jdelatour Tel : (33).2.41.86.67.90 Fax : (33).2.41.87.99.27 Date: Thu, 1 May 2008 10:13:13 -0400 (EDT) From: Murray Woodside Reply-To: cmw@sce.carleton.ca To: jerome.delatour@eseo.fr Cc: ESPINOZA Huascar 218344 , Julio Medina , marte-ftf@omg.org, Laurent Rioux , wask@omg.org Subject: Re: RE : Additional Issue for GQAM: GQAM Platform dependencies on GRM (MissingInheritance and alignment of attribute names) Jerome, All alignment between modeling and analysis should be through the core. I do not agree in principle with this proposed change. When one comes to analysis this dependence can be established, if there is a problem. 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 Sat, 26 Apr 2008, jerome.delatour@eseo.fr wrote: Hi, I agree Huascar, and why not include this issue in the 11856 (Synch SRM GRM HRM & Analysis) ? Jérôme "ESPINOZA Huascar 218344" writes: Julio, You propose to take a recently posted issue and put it as deferred. What is the goal here? All issues after the 22 december deadline and that not were treated are deferred issues. I cannot see the value to include it in the ballot. Is there some objective I missed? Cheers, Huascar ________________________________ De: Julio Medina [mailto:julio.medina@unican.es] Date: ven. 25/04/2008 20:19 À: Murray Woodside; marte-ftf@omg.org; Laurent Rioux Cc: wask@omg.org Objet : Additional Issue for GQAM: GQAM Platform dependencies on GRM (MissingInheritance and alignment of attribute names) Hi Murray, Laurent Fred Waskievicz will be probably soon posting an issue that I have just added through the web page. It deals with the misssing inheritance in CommunicationHost from CommunicationResource in GRM and ExecutionHost from ComputingResource. The importance of this issue is that there is no semantic link between these concepts through processingResource, and also that some issues deferred from RTMoCC related to attributes in CommunicationMedia shall be aligned and probably import the terminology from GQAM in order to have consistency along both design and analysis. Once we have the number would you be so kind as inserting it as deferred in the wiki and in ballot2 please. For convenience I include here the description sent for the issue: 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. Thanks, Julio -- ESEO, Equipe de recherche TRAME 4, rue Merlet de la Boulaye BP 30926 - 49009 Angers cedex 01, France www.eseo.fr/~jdelatour Tel : (33).2.41.86.67.90 Fax : (33).2.41.87.99.27 Fax : (33).2.41.87.99.27