Issue 15261: MARTE, sterotype <<assign>>, (marte-rtf) Source: (, ) Nature: Clarification Severity: Minor Summary: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <<trace>>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models. (2) We could reuse <<assign>> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability. In this solution, stereotype <<assign>> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <<assign>> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <<assign>> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <<assign>>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the ”Safe, reliable and adapted transportation” program (PREDIT) of the “Agence Nationale pour la Recherche”. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Resolution: Revised Text: Actions taken: May 20, 2010: received issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: cancila@gmail.com Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. X-IronPort-AV: E=Sophos;i="4.53,272,1272837600"; d="scan'208,217";a="63172692" Date: Thu, 20 May 2010 18:34:23 +0200 From: Frederic Mallet User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; fr; rv:1.9.1.9) Gecko/20100317 Thunderbird/3.0.4 To: marte-rtf@omg.org Subject: Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: cancila@gmail.com Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: issue 15261 -- MARTE RTF issue Date: Thu, 20 May 2010 19:00:32 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: issue 15261 -- MARTE RTF issue Thread-Index: Acr4OmKWaSfZ3e46Q7C7B3HdukdtSgAA2/5g From: "GERARD Sebastien 166342" To: "Frederic Mallet" Cc: , "daniela cancila" , "Bran Selic" X-OriginalArrivalTime: 20 May 2010 17:00:33.0414 (UTC) FILETIME=[F5CEBA60:01CAF83D] Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:mime-version:received:in-reply-to :references:from:date:message-id:subject:to:cc:content-type; bh=7ZITAICpaaswNwmMXjZ/7dibFQCfyhVNmUXj9WnVnBI=; b=uZv0m5eDwh4popocvoE4L1oEqHpdsQ/gfX6P0C7wMF/ONbLLq6tHs8eIMtucU49FQR PbhoeEuQWhBlaDWVW1eS+f2VH18AsCFozXDB1hGWn3vjKn6vTNVDTg0SwDTOMoMZMmNN sh5pNGhy8M8lSI07Qa+cXOFHwv2Rzm45sW124= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; b=OU6irIOwhn8yIHrpwveKZ02u8UI7jrxeUdD94lCc+bUmxD3qe8TSW8P5Dja5Oh+cR6 7rTr7SQMkYMfmYLTHXmPqCxob9xfjPxC/u8m74Ws7hIP/7ZGod9nADGZneZ+Mz1uU6Ww XiLUM6FNuHZ/hlWxYagdw/+jjjnu8MS5T8VZI= From: Bran Selic Date: Thu, 20 May 2010 15:15:22 -0400 Subject: Re: issue 15261 -- MARTE RTF issue To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org, daniela cancila , "sebastien.gerard" Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Date: Fri, 21 May 2010 00:20:00 -0400 From: "Chonoles, Michael J" Subject: RE: issue 15261 -- MARTE RTF issue (SysML Trace usage) To: Bran Selic , "Frederic.Mallet@sophia.inria.fr" , "sysml-rtf@omg.org" Cc: "marte-rtf@omg.org" , daniela cancila , "sebastien.gerard" Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4UPM0FZjEPn32ReO78gUyVuOmsgAS1Mog Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) ­ thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage ­ thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Rouquette, Nicolas F (316A)" To: "Chonoles, Michael J" CC: Bran Selic , "Frederic.Mallet@sophia.inria.fr" , "sysml-rtf@omg.org" , "marte-rtf@omg.org" , daniela cancila , "sebastien.gerard" Date: Thu, 20 May 2010 22:20:21 -0700 Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4pU+pnWm5OPOmQLuLzeq42al5BA== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Date: Fri, 21 May 2010 01:39:44 -0400 From: "Chonoles, Michael J" Subject: RE: issue 15261 -- MARTE RTF issue (SysML Trace usage) To: "Rouquette, Nicolas F (316A)" Cc: Bran Selic , "Frederic.Mallet@sophia.inria.fr" , "sysml-rtf@omg.org" , "marte-rtf@omg.org" , daniela cancila , "sebastien.gerard" Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4pU+pnWm5OPOmQLuLzeq42al5BAAAl3eA Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: A bit long, and a bit complicated. Are you saying that «trace» is available in SysML for non requirements purposes, but only because of the order of the spec publication and that it would not be when UML 2.4 is done? Michael From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 1:20 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org From: "Rouquette, Nicolas F (316A)" To: "Chonoles, Michael J" CC: Bran Selic , "Frederic.Mallet@sophia.inria.fr" , "sysml-rtf@omg.org" , "marte-rtf@omg.org" , daniela cancila , "sebastien.gerard" Date: Thu, 20 May 2010 23:22:19 -0700 Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4rfgzJvuEY5raSvecfdco8u9BbQ== Accept-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: acceptlanguage: en-US X-Source-IP: altvirehtstap01.jpl.nasa.gov [128.149.137.72] X-Source-Sender: nicolas.f.rouquette@jpl.nasa.gov X-AUTH: Authorized Michael, <> was/is/should be available in SysML 1.0, 1.1, 1.2, 1.3. The difference is that if you care about the pedantic details of where it comes from, then here are the differences: SysML 1.0/1.1: <> is documented in UML and referenced in SysML but the reference is unresolved. SysML 1.2: <> is documented in UML and defined in SysML; no unresolved references. SysML 1.3: <> is documented, defined & published in UML; no duplication; no unresolved references. - Nicolas. On May 20, 2010, at 10:39 PM, Chonoles, Michael J wrote: A bit long, and a bit complicated. Are you saying that «trace» is available in SysML for non requirements purposes, but only because of the order of the spec publication and that it would not be when UML 2.4 is done? Michael From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 1:20 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Date: Fri, 21 May 2010 02:24:27 -0400 From: "Chonoles, Michael J" Subject: RE: issue 15261 -- MARTE RTF issue (SysML Trace usage) To: "Rouquette, Nicolas F (316A)" Cc: Bran Selic , "Frederic.Mallet@sophia.inria.fr" , "sysml-rtf@omg.org" , "marte-rtf@omg.org" , daniela cancila , "sebastien.gerard" Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4rfgzJvuEY5raSvecfdco8u9BbQAADsPA Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Thanks, I do care, though I care more about the usability of the language From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 2:22 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Michael, <> was/is/should be available in SysML 1.0, 1.1, 1.2, 1.3. The difference is that if you care about the pedantic details of where it comes from, then here are the differences: SysML 1.0/1.1: <> is documented in UML and referenced in SysML but the reference is unresolved. SysML 1.2: <> is documented in UML and defined in SysML; no unresolved references. SysML 1.3: <> is documented, defined & published in UML; no duplication; no unresolved references. - Nicolas. On May 20, 2010, at 10:39 PM, Chonoles, Michael J wrote: A bit long, and a bit complicated. Are you saying that «trace» is available in SysML for non requirements purposes, but only because of the order of the spec publication and that it would not be when UML 2.4 is done? Michael From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 1:20 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: TR: issue 15261 -- MARTE RTF issue (SysML Trace usage) Date: Fri, 21 May 2010 15:06:16 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: thread-topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4th+RMp27OP+1Sr69vlVDVQKZ/AAMCy8A From: "GERARD Sebastien 166342" To: , Cc: "daniela cancila" X-OriginalArrivalTime: 21 May 2010 13:06:17.0749 (UTC) FILETIME=[66643450:01CAF8E6] FYI. Cheers. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : daniela cancila [mailto:cancila@gmail.com] Envoyé vendredi 21 mai 2010 09:21 À: Chonoles, Michael J Cc : Rouquette, Nicolas F (316A); Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; GERARD Sebastien 166342 Objet : Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Dear all, thank you for taking care the issue. As Nicola has well justified, we cannot use <> from SysML. We propose the following solution: MARTE sterotype <>: either (a) should provide additional enumeration literals for these two attributes of <> (i.e. .kind. and .nature.) or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. In attachment, you can have a short note where I briefly discuss the industrial context, the problem, analysis, current solutions, the best solution (to change MARTE). Please, feel free to contact me for further information. Best regards, Daniela On Fri, May 21, 2010 at 8:24 AM, Chonoles, Michael J wrote: Thanks, I do care, though I care more about the usability of the language From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 2:22 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Michael, <> was/is/should be available in SysML 1.0, 1.1, 1.2, 1.3. The difference is that if you care about the pedantic details of where it comes from, then here are the differences: SysML 1.0/1.1: <> is documented in UML and referenced in SysML but the reference is unresolved. SysML 1.2: <> is documented in UML and defined in SysML; no unresolved references. SysML 1.3: <> is documented, defined & published in UML; no duplication; no unresolved references. - Nicolas. On May 20, 2010, at 10:39 PM, Chonoles, Michael J wrote: A bit long, and a bit complicated. Are you saying that «trace» is available in SysML for non requirements purposes, but only because of the order of the spec publication and that it would not be when UML 2.4 is done? Michael From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 1:20 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Issue_15261_DanielaCancila.pdf Date: Fri, 21 May 2010 10:52:01 -0400 From: "Chonoles, Michael J" Subject: RE: issue 15261 -- MARTE RTF issue (SysML Trace usage) To: GERARD Sebastien 166342 , "sysml-rtf@omg.org" , "marte-rtf@omg.org" Cc: daniela cancila , Juergen Boldt Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4th+RMp27OP+1Sr69vlVDVQKZ/AAMCy8AAAOglRA= Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: It seems to this is as much a MARTE issue as a SysML issues in that the problem Daniela points out . mapping of a general model to a safety model (and similar) is a concern in both languages. Should a new issue also be made in SysML? In any case, I would propose a jointly viable solution Michael From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Friday, May 21, 2010 9:06 AM To: sysml-rtf@omg.org; marte-rtf@omg.org Cc: daniela cancila Subject: TR: issue 15261 -- MARTE RTF issue (SysML Trace usage) FYI. Cheers. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : daniela cancila [mailto:cancila@gmail.com] Envoyé vendredi 21 mai 2010 09:21 À: Chonoles, Michael J Cc : Rouquette, Nicolas F (316A); Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; GERARD Sebastien 166342 Objet : Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Dear all, thank you for taking care the issue. As Nicola has well justified, we cannot use <> from SysML. We propose the following solution: MARTE sterotype <>: either (a) should provide additional enumeration literals for these two attributes of <> (i.e. .kind. and .nature.) or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. In attachment, you can have a short note where I briefly discuss the industrial context, the problem, analysis, current solutions, the best solution (to change MARTE). Please, feel free to contact me for further information. Best regards, Daniela On Fri, May 21, 2010 at 8:24 AM, Chonoles, Michael J wrote: Thanks, I do care, though I care more about the usability of the language From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 2:22 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Michael, <> was/is/should be available in SysML 1.0, 1.1, 1.2, 1.3. The difference is that if you care about the pedantic details of where it comes from, then here are the differences: SysML 1.0/1.1: <> is documented in UML and referenced in SysML but the reference is unresolved. SysML 1.2: <> is documented in UML and defined in SysML; no unresolved references. SysML 1.3: <> is documented, defined & published in UML; no duplication; no unresolved references. - Nicolas. On May 20, 2010, at 10:39 PM, Chonoles, Michael J wrote: A bit long, and a bit complicated. Are you saying that «trace» is available in SysML for non requirements purposes, but only because of the order of the spec publication and that it would not be when UML 2.4 is done? Michael From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 1:20 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Subject: RE: issue 15261 -- MARTE RTF issue (SysML Trace usage) Date: Fri, 21 May 2010 17:56:59 +0200 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4th+RMp27OP+1Sr69vlVDVQKZ/AAMCy8AAAOglRAAAc/mwA== From: "Huascar Espinoza" To: "Chonoles, Michael J" , "GERARD Sebastien 166342" , , Cc: "daniela cancila" , "Juergen Boldt" X-ESI-MailScanner-Information: Please contact the ISP for more information X-ESI-MailScanner: Found to be clean X-ESI-MailScanner-SpamCheck: not spam (whitelisted), SpamAssassin (score=-2.888, required 3, autolearn=not spam, AWL 0.11, BAYES_00 -3.00) X-MailScanner-From: huascar.espinoza@esi.es X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id o4LFwwAc015484 Hi all, It seems to me that the required relationship is a simple link between two model elements that specify the same concept but from different viewpoints. The MARTE::Allocation semantics (assign, allocate, and allocated) are very specific to the "application" and "platform" concepts, and it may be confusing to use them for the Daniela's problem. I guess that the required concept already exist in UML, as described below. Abstraction Description An abstraction is a relationship that relates two elements or sets of elements that represent the same concept at different levels of abstraction or from different viewpoints. Semantics Depending on the specific stereotype of Abstraction, the mapping may be formal or informal, and it may be unidirectional or bidirectional. Abstraction has predefined stereotypes (such as «derive», «refine», and «trace») that are defined in the Standard Profiles clause. If an Abstraction element has more than one client element, the supplier element maps into the set of client elements as a group. For example, an analysis-level class might be split into several design-level classes. The situation is similar if there is more than one supplier element. Just my opinion Regards, Huascar ________________________________ De: Chonoles, Michael J [mailto:michael.j.chonoles@lmco.com] Enviado el: vie 21/05/2010 16:52 Para: GERARD Sebastien 166342; sysml-rtf@omg.org; marte-rtf@omg.org CC: daniela cancila; Juergen Boldt Asunto: RE: issue 15261 -- MARTE RTF issue (SysML Trace usage) It seems to this is as much a MARTE issue as a SysML issues in that the problem Daniela points out - mapping of a general model to a safety model (and similar) is a concern in both languages. Should a new issue also be made in SysML? In any case, I would propose a jointly viable solution Michael From: GERARD Sebastien 166342 [mailto:Sebastien.GERARD@cea.fr] Sent: Friday, May 21, 2010 9:06 AM To: sysml-rtf@omg.org; marte-rtf@omg.org Cc: daniela cancila Subject: TR: issue 15261 -- MARTE RTF issue (SysML Trace usage) FYI. Cheers... Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d'Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment ________________________________ De : daniela cancila [mailto:cancila@gmail.com] Envoyé vendredi 21 mai 2010 09:21 À: Chonoles, Michael J Cc : Rouquette, Nicolas F (316A); Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; GERARD Sebastien 166342 Objet : Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Dear all, thank you for taking care the issue. As Nicola has well justified, we cannot use <> from SysML. We propose the following solution: MARTE sterotype <>: either (a) should provide additional enumeration literals for these two attributes of <> (i.e. 'kind' and 'nature') or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. In attachment, you can have a short note where I briefly discuss the industrial context, the problem, analysis, current solutions, the best solution (to change MARTE). Please, feel free to contact me for further information. Best regards, Daniela On Fri, May 21, 2010 at 8:24 AM, Chonoles, Michael J wrote: Thanks, I do care, though I care more about the usability of the language From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 2:22 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Michael, <> was/is/should be available in SysML 1.0, 1.1, 1.2, 1.3. The difference is that if you care about the pedantic details of where it comes from, then here are the differences: SysML 1.0/1.1: <> is documented in UML and referenced in SysML but the reference is unresolved. SysML 1.2: <> is documented in UML and defined in SysML; no unresolved references. SysML 1.3: <> is documented, defined & published in UML; no duplication; no unresolved references. - Nicolas. On May 20, 2010, at 10:39 PM, Chonoles, Michael J wrote: A bit long, and a bit complicated. Are you saying that «trace» is available in SysML for non requirements purposes, but only because of the order of the spec publication and that it would not be when UML 2.4 is done? Michael From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 1:20 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here's the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d'Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment ________________________________ De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the "Safe, reliable and adapted transportation" program (PREDIT) of the "Agence Nationale pour la Recherche". Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org [] ********************************** DISCLAIMER ******************************* This message may contain confidential, proprietary or legally privileged information. If you are not the intended recipient of this message, please notify it to the sender and delete without resending or backing it, as it is legally prohibited. ********************************** AVISO LEGAL ****************************** Este mensaje puede contener informacióonfidencial, en propiedad o legalmente protegida. Si usted no es el destinatario, le rogamos lo comunique al remitente y proceda a borrarlo, sin reenviarlo ni conservarlo, ya que su uso no autorizado estárohibido legalmente. ****************************************************************************** Date: Fri, 21 May 2010 12:07:08 -0400 From: "Chonoles, Michael J" Subject: RE: issue 15261 -- MARTE RTF issue (SysML Trace usage) To: daniela cancila Cc: "Rouquette, Nicolas F (316A)" , Bran Selic , "Frederic.Mallet@sophia.inria.fr" , "sysml-rtf@omg.org" , "marte-rtf@omg.org" , "sebastien.gerard" Thread-Topic: issue 15261 -- MARTE RTF issue (SysML Trace usage) Thread-Index: Acr4/yB/ikd8V5LjSs+RMxvypzGqHAAAGYJQ Accept-Language: en-US acceptlanguage: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: Daniela, I don.t see why necessarily that you can.t use trace from UML, other than it.s usually the vaguest relationship. Trace from SysML appears to be exactly the same as the UML one, there is not restriction to reqts. However, that may be sufficient reason not to use trace. However, I strongly recommend that you solve this together with SysML. And not to go off independently Micahel From: daniela cancila [mailto:cancila@gmail.com] Sent: Friday, May 21, 2010 3:21 AM To: Chonoles, Michael J Cc: Rouquette, Nicolas F (316A); Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Dear all, thank you for taking care the issue. As Nicola has well justified, we cannot use <> from SysML. We propose the following solution: MARTE sterotype <>: either (a) should provide additional enumeration literals for these two attributes of <> (i.e. .kind. and .nature.) or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. In attachment, you can have a short note where I briefly discuss the industrial context, the problem, analysis, current solutions, the best solution (to change MARTE). Please, feel free to contact me for further information. Best regards, Daniela On Fri, May 21, 2010 at 8:24 AM, Chonoles, Michael J wrote: Thanks, I do care, though I care more about the usability of the language From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 2:22 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) Michael, <> was/is/should be available in SysML 1.0, 1.1, 1.2, 1.3. The difference is that if you care about the pedantic details of where it comes from, then here are the differences: SysML 1.0/1.1: <> is documented in UML and referenced in SysML but the reference is unresolved. SysML 1.2: <> is documented in UML and defined in SysML; no unresolved references. SysML 1.3: <> is documented, defined & published in UML; no duplication; no unresolved references. - Nicolas. On May 20, 2010, at 10:39 PM, Chonoles, Michael J wrote: A bit long, and a bit complicated. Are you saying that «trace» is available in SysML for non requirements purposes, but only because of the order of the spec publication and that it would not be when UML 2.4 is done? Michael From: Rouquette, Nicolas F (316A) [mailto:nicolas.f.rouquette@jpl.nasa.gov] Sent: Friday, May 21, 2010 1:20 AM To: Chonoles, Michael J Cc: Bran Selic; Frederic.Mallet@sophia.inria.fr; sysml-rtf@omg.org; marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue (SysML Trace usage) In short, <> is available; however, the explanation is a bit long. SysML defines several stereotypes that specialize what in the SysML specification is called <> (see Fig 16.1 in SysML 1.2) In SysML 1.0 and 1.1, the SysML profile defined Trace as a specialization of UML's StandardProfileL2::Trace. However, this was "dangling" reference because the OMG has not yet published UML's StandardProfileL2/3 including UML 2.3 just published this week. For SysML 1.2, I felt very strongly that a normative artifact like SysML1.2's profile should reference/depend only on published, normative artifacts from the OMG. Since both UML 2.3 & SysML 1.2 had been voted on in 2009, Andrew Watson said that the only way to retroactively publishing UML's StandardProfileL2/3 would be to file an urgent issue -- e.g., UML 2.3.1 -- but this would cost us an extra cycle and delay UML 2.4. So, as a compromise, the UML 2.4 & SysML 1.3 RTFs agreed to publish SysML 1.2 where the normative SYsML profile includes a definition of a <> stereotype just as it is described in the UML spec. This enabled us to define a normative profile for SysML 1.2 that references UML4SysML-metamodel, a normative artifact that, in turn, only depends on published, normative UML 2.3 artifacts, i.e., Superstructure & Infrastructure. For UML 2.4, we will be finally provide the StandardProfileL2/3 as normative artifacts so that we can normatively specialize these stereotypes, incl. Trace, in SysML1.3. - Nicolas. On May 20, 2010, at 9:20 PM, Chonoles, Michael J wrote: Bran, while the SysML spec explicitly calls out the use of «trace» for requirement relationships, it does mention the use of a UML-like use of «trace», which leads me to believe that it is still available. Here.s the quote from section A.2 Guidelines · SysML provides the capability to represent a document using the UML 2 standard stereotype «document» applied to the artifact model element. Properties of the artifact can capture information about the document. Use a «trace» abstraction to relate the document to model elements. The document can represent text that is contained in the related model elements. Michael From: Bran Selic [mailto:bran.selic@gmail.com] Sent: Thursday, May 20, 2010 3:15 PM To: Frederic.Mallet@sophia.inria.fr Cc: marte-rtf@omg.org; daniela cancila; sebastien.gerard Subject: Re: issue 15261 -- MARTE RTF issue Hi Frederic, I am partly behind this. Namely, in some work that we are doing at CEA, we need to have a trace relationship between an element in a fault tree diagram (a specialized diagram used by safety engineers), to an element in an architecture diagram. Daniela investigated which UML or MARTE concept could be used as the base for this type of trace relationship and <> came closest. This is based on the philosophy behind the SysML <>, which, after all, was the inspiration for <> (but without the problems that <> has). Namely, in SysML, allocate was intended to be used for a wide variety of things, including things such as various semantic connections between elements. (NB: The "trace" relationship in SysML is used exclusively for tracing to requirements, so it did not fit the bill.) However, <> has the problem that it is really specialized for deployment, with parameters such as "nature" and "kind", neither of which particularly make sense for the purpose we intend. So, the first part of the proposal was to "restore" <> to its more general form by making its "nature" and "kind" attributes optional. (Note that, Daniela is planning on creating a special subclass of the Assign stereotype, possibly with attributes that make more sense for this application -- but the "nature" and "kind" attributes, being mandatory, get in the way and have to be given some default values that do not make sense in this case. By making them optional, she can add an OCL constraint that states that the multiplicities of these two attributes are always zero.) A different approach would have been to add new kinds of allocation kinds and natures by defining new enumeration literals, but that looks like it will make these enumeration types a real mish-mash of semantically unconnected possibilities. Hope this makes sense. I am sure Daniela's note will clarify things further. Cheers...Bran On Thu, May 20, 2010 at 1:00 PM, GERARD Sebastien 166342 wrote: Hi, I copy Daniela directly in order she can explain herself. Séstien. Dr. Séstien Gérd Head of MDD for DRES research project CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE) Boî courrier 94, GIF SUR YVETTE CEDEX, F-91191 France Phone/fax : +33 1 69 08 58 24 / 83 95 Leader of the Eclipse Component Papyrus (The UML2 Graphical Modeler): www.papyrusuml.org http://www.eclipse.org/modeling/mdt/?project=papyrus Before printing, think about the environment -------------------------------------------------------------------------------- De : Frederic Mallet [mailto:Frederic.Mallet@sophia.inria.fr] Envoyé jeudi 20 mai 2010 18:34 À: marte-rtf@omg.org Objet : Re: issue 15261 -- MARTE RTF issue Hi alloc_wg, Does somebody understand what is behind that ? Daniela Cancila proposes three solutions (which I roughly understand) but I do not understand what the problem is. >>Informal matching between a safety element and an architectural element. ???????? I do not understand which attributes should become optional in solution (a). Regards, Frederic Le 20/05/2010 17:07, Juergen Boldt a éit : From: webmaster@omg.org Date: 20 May 2010 10:18:16 -0400 To: Subject: Issue/Bug Report ******************************************************************************* Name: Daniela Cancila Company: Sherpa Engineering mailFrom: [SG > ] Notification: Yes Specification: MARTE Section: 11, section 11.3.2.7 FormalNumber: ptc/2009-05-15 (XMI), ptc/2009-05-16 (model library XMI) [OMG Document Number: formal/2009-11-02] Version: 1.0 RevisionDate: November 2009 Page: 140/738 Title: MARTE, sterotype <>, Nature: Clarification Severity: Minor test: 3qw8 B1: Report Issue Description: problem: Informal matching between a safety element and an architectural element. analysis: (1) We could introduce a new stereotype from a scratch (e.g. by extending <>) for the specific need. Its main advantage is to be optimally studied to the problem at hand. The price to pay is a new stereotype (with similar semantics to the standard ones) thus potentially increasing the cost for interfacing models. (2) We could reuse <> stereotype. The main drawback is a semantic overlapping with the original MARTE stereotype. However, the main advantage is that we reduce the number of concepts that a (safety) designer should manage thus potentially increasing in usability. In this solution, stereotype <> must have: kind = hybrid and nature = spatialDistribution. In order to do it, we are forced to generalized stereotype <> with a new stereotype with fixed values for both ''kind'' and ''nature'' proposed solution (by Bran Selic): (a) provide additional enumeration literals for these two attributes of <> or (b) make them optional by changing their multiplicity from [1] to [0..1]. Note that these are not mutually exclusive choices and it might make sense to realize them both. Making these attributes optional will certainly improve on the generality of <>, so that it can be used to model other types of "allocation" relationships project: IMOFIS project of the System@tic Paris R´egion Cluster. It is sponsored by the .Safe, reliable and adapted transportation. program (PREDIT) of the .Agence Nationale pour la Recherche.. Impact on the Industrial Context: The development of critical systems involves the interplay of many different disciplines and, therefore, becomes particularly complex. In this context, the industrial and academic communities are paying increasing attention to safety issues. The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture. Juergen Boldt Director, Member Services Object Management Group 140 Kendrick St Building A Suite 300 Needham, MA 02494 USA tel: +1 781 444 0404 x 132 fax: +1 781 444 0320 email: juergen@omg.org www.omg.org Error! Filename not specified. From: GERARD Sebastien 166342 To: Bran Selic CC: "marte-rtf@omg.org" Subject: MARTE 1.2 RTF: issue 15261 Thread-Topic: MARTE 1.2 RTF: issue 15261 Thread-Index: AcyCqdJ3b2n8xZRPSLaA4FW/qpuJEg== Date: Tue, 4 Oct 2011 15:25:18 +0000 Accept-Language: fr-FR, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.106] x-tm-as-product-ver: SMEX-10.0.0.4152-6.800.1017-18424.006 x-tm-as-result: No--46.374200-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Hi Bran, It seems (reading the issue) that you have been involved somewhere in this issue: http://www.omg.org/issues/marte-rtf.html#Issue15261 Frankly, reading the issue I do not really understand the issue and so it is difficult to infer a solution. Do you have an idea? Thanks, Cheers. Sé ------------------------------------------------------------------------------------------------------------------------------------------------ Sésten Gérd CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE), Point Courrier 94, Gif-sur-Yvette, F-91191 France www.eclipse.org/papyrus DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:from:date :x-google-sender-auth:message-id:subject:to:cc:content-type; bh=WF57SScoRaYsdkyVCnmEa9QKCmiptbPZ54XUWxCV7rQ=; b=shy2/HFi4OOQwnooxA9S5ohrQl8Ff0rnFcfO69HXP7TfVMcIMvoF3KrbplLWml9jJl CqIxVtreEnR0NbyUu+jskbaMHR/8Vsac9oIw0IQxrrRLv9fpNpWH1WWpwcHGQXhJajrc xh3djuK0vY5FO5BiU5ykcYp29mJgXFZK3YBCU= Sender: bran.selic@gmail.com From: Bran Selic Date: Tue, 4 Oct 2011 17:40:59 -0400 X-Google-Sender-Auth: VNoENktFJDftaBeIQvaF0vWE2EE Subject: Re: MARTE 1.2 RTF: issue 15261 To: GERARD Sebastien 166342 Cc: "marte-rtf@omg.org" Funny, I don't recall providing this feedback on the issue. In fact, my suggestion, as explained in the issue text, does not solve their problem. It seems that I was recommending was that we should make the <> stereotype more general, allowing it to handle cases where, for example, the concept of "nature" may not even make sense. OTOH, what these folks seem to want is the opposite: to specialize <> such that its two attributes, "kind" and "nature", always have the same value. They would like to do this without defining a new stereotype. Of course, this is possible and does not require any change to MARTE, but it does require the addition of a constraint on <>, which, in turn, requires a new profile (albeit a trivial one, containing just that one constraint). Alternatively, they could include this constraint in their application model -- although that would have to be done in every individual model. To summarize, there are really two issues here, only one of which has been formally raised. My suggestion was really to deal with the implicit issue that <> is too narrowly defined. I suppose I could raise that issue, but it would certainly be outside the scope of the RTF. So, I suggest we bypass it for now. The second, "official" issue is the one raised by the submitters. For this, I think we need not do anything, but simply provide the solution I described in the paragraph above. Cheers...Bran On Tue, Oct 4, 2011 at 11:25 AM, GERARD Sebastien 166342 wrote: Hi Bran, It seems (reading the issue) that you have been involved somewhere in this issue: http://www.omg.org/issues/marte-rtf.html#Issue15261 Frankly, reading the issue I do not really understand the issue and so it is difficult to infer a solution. Do you have an idea? Thanks, Cheers. Sé ------------------------------------------------------------------------------------------------------------------------------------------------ Sésten Gérd CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE), Point Courrier 94, Gif-sur-Yvette, F-91191 France www.eclipse.org/papyrus -- Cheers...Bran Content-Type: image/png; name="image001.png" Content-ID: X-Attachment-Id: d2700b4e3ce17de2_0.1 From: GERARD Sebastien 166342 To: Bran Selic CC: "marte-rtf@omg.org" Subject: RE: MARTE 1.2 RTF: issue 15261 Thread-Topic: MARTE 1.2 RTF: issue 15261 Thread-Index: AcyCqdJ3b2n8xZRPSLaA4FW/qpuJEgAI7gCAACRylYA= Date: Wed, 5 Oct 2011 13:05:11 +0000 Accept-Language: fr-FR, en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-originating-ip: [132.166.88.106] x-tm-as-product-ver: SMEX-10.0.0.4152-6.800.1017-18426.002 x-tm-as-result: No--52.021100-8.000000-31 x-tm-as-user-approved-sender: No x-tm-as-user-blocked-sender: No Hi Bran, Thanks for the feedback. I have uploaded a closed no change resolution proposal on the wiki according to this feedback. Cheers. Séstien. ------------------------------------------------------------------------------------------------------------------------------------------------ Sésten Gérd CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE), Point Courrier 94, Gif-sur-Yvette, F-91191 France www.eclipse.org/papyrus De : bran.selic@gmail.com [mailto:bran.selic@gmail.com] De la part de Bran Selic Envoyé mardi 4 octobre 2011 23:41 À: GERARD Sebastien 166342 Cc : marte-rtf@omg.org Objet : Re: MARTE 1.2 RTF: issue 15261 Funny, I don't recall providing this feedback on the issue. In fact, my suggestion, as explained in the issue text, does not solve their problem. It seems that I was recommending was that we should make the <> stereotype more general, allowing it to handle cases where, for example, the concept of "nature" may not even make sense. OTOH, what these folks seem to want is the opposite: to specialize <> such that its two attributes, "kind" and "nature", always have the same value. They would like to do this without defining a new stereotype. Of course, this is possible and does not require any change to MARTE, but it does require the addition of a constraint on <>, which, in turn, requires a new profile (albeit a trivial one, containing just that one constraint). Alternatively, they could include this constraint in their application model -- although that would have to be done in every individual model. To summarize, there are really two issues here, only one of which has been formally raised. My suggestion was really to deal with the implicit issue that <> is too narrowly defined. I suppose I could raise that issue, but it would certainly be outside the scope of the RTF. So, I suggest we bypass it for now. The second, "official" issue is the one raised by the submitters. For this, I think we need not do anything, but simply provide the solution I described in the paragraph above. Cheers...Bran On Tue, Oct 4, 2011 at 11:25 AM, GERARD Sebastien 166342 wrote: Hi Bran, It seems (reading the issue) that you have been involved somewhere in this issue: http://www.omg.org/issues/marte-rtf.html#Issue15261 Frankly, reading the issue I do not really understand the issue and so it is difficult to infer a solution. Do you have an idea? Thanks, Cheers. Sé ------------------------------------------------------------------------------------------------------------------------------------------------ Sésten Gérd CEA LIST, Laboratoire d.Ingéerie dirigépar les modès pour les Systès Embarqué(LISE), Point Courrier 94, Gif-sur-Yvette, F-91191 France www.eclipse.org/papyrus -- Cheers...Bran The resolution of the open issue improves the integration of safety analyses in a model-based engineering approach, where MARTE is used to specify a subset of the architecture.