Omg issue Number

Disposition: Resolved

OMG Issue No: 11660

Title: N/A

Source:

CEA-List (Arnaud Cuccuru, [e-mail])}

Summary:

In figure 11.4, MessagePort is represented as an abstract class (“italic”). According to the description written in the spec, there is no particular reason to do that. This class should be represented as a concrete class.

Resolution:

Update Figure 11.4 to represent MessagePort as a concrete class (no italic).

Revised Text:

Replace Figure 11.4, page 119 by the Figure below:

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11661

Title: Section: 11.2.1

Source:

CEA-List (Arnaud Cuccuru, [e-mail])

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
  
  • 
    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.”
    
  • 
    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
  
  • 
    remove the descriptions of the literals “in”, “out”, “inout”
    
  • 
    replace the description of the literal “required” by “used to model that an operation or a signal reception is required”
    
  • 
    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
  
  • 
    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”
    
  • 
    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
  
  • 
    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);”

• 
  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):
  

Disposition: Resolved