Issue 11661: Section: 11.2.1 (marte-ftf) Source: Commissariat a l Energie Atomique-CEA (Dr. Arnaud Cuccuru, arnaud.cuccuru(at)cea.fr) Nature: Enhancement Severity: Significant Summary: In the UML, a “Provided or Required” direction is implicitly associated to Signals that are exposed on the ports of a structured class or component (via the provided or required interfaces of the port). For UML consistency purpose, the “direction” attributes of SignalFeature and MessagePort should be typed by an enumeration like BFeatureKind (which is defined in the UML representation section), only with PROVIDED and REQUIRED enumeration literals. In other words, the DirectionKind enumeration (with enumeration literals IN, OUT and INOUT) should be reserved to FlowPorts, and used only to type “direction” attributes of FlowPort and FlowProperties classes. Resolution: Proceed with suggested resolution in the profile definition and the domain model. Related issues: 11666, 11551 Revised Text: 1) Domain model · On page 119, replace the current Figure 11.4 by the following one: · On page 120, replace "SignalSpecifications have a set of SignalFeatures defining published (out) and consumed (in) signals, which are specified by the direction attribute. Particularly, atomic message ports (attribute isAtomic to true) cannot require and provide services. If the direction value of an atomic message ports is "in" (resp. "out"), it "consumes" (resp. "produces") one and only one signal. If the value is inout, the atomic message port is able to consume and publish event occurrences of the referenced signal." By "SignalSpecifications have a set of SignalFeatures defining published (required) and consumed (provided) signals, which are specified by the direction attribute. Particularly, atomic message ports (attribute isAtomic to true) cannot require and provide services. If the kind value of an atomic message ports is "provided" (resp. "required"), it "consumes" (resp. "produces") one and only one signal." · On Annex F.5.11, page 535, remove "(or signal specification)" from the DirectionKind description · On Annex F.5.11, page 535, add a description of BFeatureKind (currently missing the Beta 1) : BFeatureKind BFeatureKind is an enumeration, which literals specify the kind of behavioral features related to message ports. Literals - provided: the behavioral feature is provided by the port of the the owning entity. - required: the behavioral feature is provided by the port of the the owning entity. · On Annex F.5.11, page 539 o In the attributes section, replace "direction: DirectionKind [0..1] direction of the port when the later is not atomic." By "kind: BFeatureKind [0..1] kind of the port when the later is not atomic." o In the semantics section, replace "The "direction" attribute indicates whether the port has provided (in), required (out) or both (inout) services." By "The "kind" attribute indicates whether the port has provided or required services or signal receptions". 2) Profile · On page 121, replace the current Figure 11.6 by the following one: · On page 121, section 11.3.2.1 o remove the descriptions of the literals "in", "out", "inout" o replace the description of the literal "required" by "used to model that an operation or a signal reception is required" o replace the description of the literal "provided" by "used to model that an operation or a signal reception is provided" · On page 122, section 11.3.2.2, Notation section, replace "When applying the stereotype using its iconographical or shape forms, following icons are proposed: for BFeatureSpecifcation with kind = in; for BFeatureSpecifcation with kind = out; for BFeatureSpecifcation with kind = inout; for BFeatureSpecifcation with kind = required; for BFeatureSpecifcation with kind = provided; for BFeatureSpecifcation with kind = reqpro. Figure 11.7 describes an example using different graphical forms applying UML stereotypes." By "When applying the stereotype using its iconographical or shape forms, following icons are proposed: for BFeatureSpecification with kind = required, when all the features contained in the interface are signal receptions; for BFeatureSpecification with kind = provided, when all the features contained in the interface are signal receptions; for BFeatureSpecification with kind = required, when all the features contained in the interface are operations; for BFeatureSpecification with kind = provided, when all the features contained in the interface are operations; Figure 11.7 describes an example using different graphical forms applying UML stereotypes." · On page 123, section 11.3.2.4 o replace "If kind is in, out or inout, the BehavioralFeature will be a Reception while if kind is required or provided, it is expected to be an Operation." by "If kind is required it is expected to be a required operation or signal reception while if kind is provided, it is expected to be a provided operation or signal reception" o remove the following constraint from the definition of FlowBFeature "[1] If kind is in, out or inout, the extended BehavioralFeature has to be a Reception." "[2] If kind is required or provided, the extended BehavioralFeature has to be an Operation" · On page 128, section 11.3.2.9, remove constraint "[5] If a port is atomic, valid values for kind are only in, out or inout." · On page 128, section 11.3.2.9, Notation section o replace "When a message port is atomic, the following graphical notation may used: for one port consuming signal occurrences according to its type (i.e. direction value set to in); for one port producing signal occurrences according to its type (i.e. direction value set to out); for one port consuming and producing signal occurrences according to its type (i.e. direction value set to inout)." By "When a message port is atomic, the following graphical notation may used: for one port consuming signal occurrences according to its type (i.e. kind set to provided); for one port producing signal occurrences according to its type (i.e. kind set to required);" o replace Figure 11.13 by the figure below 3) Examples · On page 130, replace "The former port is an atomic port and its direction is set to out" by "The former port is an atomic port and its kind is set to required" (merges with resolution 11551) · Replace Figure 11.16, page 131 by the following figure (merges with resolution 11551): · Replace Figure 11.17, page 131 by the following figure (merges with resolution 11551): Actions taken: November 20, 2007: received issue February 17, 2010: closed issue Discussion: End of Annotations:===== m: webmaster@omg.org Date: 20 Nov 2007 09:54:20 -0500 To: Subject: Issue/Bug Report -------------------------------------------------------------------------------- Name: Arnaud Cuccuru Company: Commissariat a l Energie Atomique - CEA/LIST mailFrom: arnaud.cuccuru@cea.fr Notification: Yes Specification: A UML Profile for MARTE Section: 11.2.1 FormalNumber: ptc/07-08-04 Version: Beta 1 RevisionDate: 04/08/07 Page: 119-120 Nature: Enhancement Severity: Significant HTTP User Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1) Gecko/20061010 Firefox/2.0 Description In the UML, a .Provided or Required. direction is implicitly associated to Signals that are exposed on the ports of a structured class or component (via the provided or required interfaces of the port). For UML consistency purpose, the .direction. attributes of SignalFeature and MessagePort should be typed by an enumeration like BFeatureKind (which is defined in the UML representation section), only with PROVIDED and REQUIRED enumeration literals. In other words, the DirectionKind enumeration (with enumeration literals IN, OUT and INOUT) should be reserved to FlowPorts, and used only to type .direction. attributes of FlowPort and FlowProperties classes. Date: Fri, 07 Mar 2008 10:31:28 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: GERARD Sebastien 166342 , marte-ftf@omg.org Subject: Comment on issue 11661 (GCM) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m279avZb018756 Sébastien, Issue 11661 (http://www.omg.org/issues/marte-ftf.open.html#Issue11661) asks for distinguising the "provided / required" litterals, used for message port only (i.e. operation and signals) from the "in / out / inout" litterrals, used for flow port only. I tend to agree with the proposed resolution, given that it is compatible with the UML terminology. However, in the issue Excel spreadsheet you sent, one can read the following comment attached to this issue : "Needs to be discussed to fix the vocabulary." Please can you let us know what you had in mind? Thanks, Sébastien Date: Mon, 17 Mar 2008 16:02:26 +0100 From: Sébastien Demathieu Organization: Thales Research & Technology User-Agent: Thunderbird 1.5.0.9 (Windows/20061207) To: GERARD Sebastien 166342 Cc: marte-ftf@omg.org Subject: Re: Comment on issue 11661 (GCM) X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id m2HF4tUm005780 Sébastien, Please can you let me know what you think about it? Many thanks! Sébastien Sébastien Demathieu a écrit : Sébastien, Issue 11661 (http://www.omg.org/issues/marte-ftf.open.html#Issue11661) asks for distinguising the "provided / required" litterals, used for message port only (i.e. operation and signals) from the "in / out / inout" litterrals, used for flow port only. I tend to agree with the proposed resolution, given that it is compatible with the UML terminology. However, in the issue Excel spreadsheet you sent, one can read the following comment attached to this issue : "Needs to be discussed to fix the vocabulary." Please can you let us know what you had in mind? Thanks, Sébastien