Omg issue Number

OMG Issue No: 11765

Title: [NFP: Profile]. Fig 8.4 (statisticalQualifier and Direction as stereotype attributes of <>)

Source:

Commissariat a l Energie Atomique-CEA/LIST (Mr. Huascar Espinoza, [e-mail])

Summary:

[NFP: Profile]. Fig 8.4 shows a domain model for NFP declaration. In this domain model, the NFP concept has to attributes (statisticalQualifier + direction). However, these two attributes do not appear in the corresponding Stereotype: <> (Fig. 8-5). Section 8.3.2.1 justifies this by saying: “the attributes of NFP, statistical qualifier and direction, are implemented in the library of NFP Types”. However, it could be useful to allow stereotype users to define these two parameters at the NFP declaration stage (and not only at the value specification stage). On the other hand, the current mechanism to define these two parameters at the NFP declaration stage (default values of NFPs), is not strict enough, as users can modify default values. So, I propose to put this two attributes (statisticalQualifier + direction) in the <> stereotype.

Resolution:

If we adopt these two attributes for the ‘Nfp’ stereotype, there may exist some issues regarding to consistency and duplication of information. Indeed, statisticalQualifier and direction would be able to be specified in ‘Nfp’ and in the value specification too (e.g., maxLatency= (value=5, unit=ms, statQ=max)).

Another question that rises is why other qualifiers would not able to be specified in ‘Nfp’ attributes (e.g., source) in the same way.

In order to keep consistency and to avoid confusions between the domain model and profile definition, both ‘statisticalQualifier’ and ‘direction‘ attributes of the ‘NFP’ metaclass are removed from the domain model.

This means that the proposal to include these two attributes in the stereotype definition is not accepted. However, for comprehensibility, they are removed from the domain model.

Revised Text:

-In section 8.2.4, remove the entire second paragraph:

“NFP elements enclose two basic attributes: statistical qualifier and direction. Both have…”

-In the same section (8.2.4), change the entire sixth paragraph:

“Examples of qualifiers are measurement precision and value source (see NFP Types Library in Section 8.3.3.1). Source is…”

By a new paragraph:

“Examples of qualifiers are statisticalQualifier, direction, value source, measurement precision and (see NFP Types Library in Section 8.3.3.1). A statisticalQualifier indicates the type of statistical measure of a given property (e.g., maximum, minimum, mean, percentile, distribution). The direction attribute (i.e., increasing or decreasing) defines the type of the quality order relation in the allowed value domain of NFPs. Indeed, this allows multiple instances of NFP values to be compared with the relation “higher-quality-than” in order to identify what value represents the higher quality or importance. Source is a peculiarity of non-functional properties associated with the origin of specifications. Precision is the degree of refinement in the instruments and methods used to obtain a result.”

-Change Fig. 8.4 with this one:

Figure 8.4 - Domain Model of NFP Declaration

-In Section 8.3.2.1 Nfp (description of the Nfp stereotype), remove the following text from the first paragraph:

“..Note, however, that the attributes of NFP, statistical qualifier and direction, are implemented in the library of NFP Types. The goal is to allow users modifying these attributes at value specification level.”

-In Section 8.3.3.1, page 42, remove the following text from both, the ‘statQ’ and ‘dir’ semantic description:

“This qualifier is defined in the domain model as an attribute of an NFP. We define it here as an NFP_Type attribute to be able to specify it as a default value in a NFP, as well as a part of the NFP value itself.”

-In Section F.2.10 (Domain Class Description for NFP), remove the ‘Attribute’ subsection:

“Attributes

• direction: DirectionKind [0..1] direction attribute (i.e., increasing or decreasing) defines the type of quality order relation in the allowed value domain of NFPs. This allows multiple instances of NFP values to be compared wit the relation "higher-quality-than" in order to identify what value represents the higher quality or importance.

• statisticalQualifier: StatisticalQualifierKind [0..1] statistical qualifier indicates the type of "statistical" measure of a given property (e.g., maximum, minimum, mean, percentile, distribution).”

Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11766

Title: [Time] Fig. 9.29

Source:

Commissariat a l Energie Atomique-CEA/LIST (Mr. Huascar Espinoza, [e-mail])


Summary:

[Time] Fig. 9.29 refers to the Enumeration type ‘EventKind’. The formal definition of EventKind is an annex (Annex D). I’d suggest to show this definition in Fig 9.29 for a faster comprehensibility of the provided stereotypes.

Resolution:

This is easy to do, but I guess that this suggestion may apply to many diagrams. In the chapter time (for instance),

• 
  Fig. 9.26 refers to TimeStandardKind,
  
• 
  Fig. 9.27 refers to TimeInterpretationKind
  
• 
  Fig. 9.28 refers to TimeInterpretationKind
  
• 
  Fig. 2.29 refers to EventKind
  

My question is: do we systematically include in UML extension diagrams the used enumerations and mention in the associated text that the enumeration is part of a library given in Annex D?

Revised Text:

Para 9.3.1.4

Old:

TimedObservation is an abstract stereotype of TimedInstantObservation and TimedDurationObservation. It allows time expressions to refer to either in a common way. As a TimedElement, a TimedObservation makes reference to clocks. The optional obsKind attribute may specify the kind of the observed event(s).

Figure 9.29 - UML extensions for Time modeling (4)

New:

TimedObservation is an abstract stereotype of TimedInstantObservation and TimedDurationObservation. It allows time expressions to refer to either in a common way. As a TimedElement, a TimedObservation makes reference to clocks. The optional obsKind attribute may specify the kind of the observed event(s). The Enumeration EventKind is part of the TimeTypesLibrary (Annex D.3.1).



Figure 9.29 - UML extensions for Time modeling (4)

Disposition: Resolved