Issue 5705: Section 4, Page 4-4, Line 6. (uml-scheduling-ftf)
Source: The MathWorks (Mr. Alan Moore, alan.moore(at)mathworks.co.uk)
Nature: Uncategorized Issue
Severity: 
Summary: Suggest adding " In this case, the QoS characteristics and QoS value of descriptors and instance must be compatible". This addition tries to clarify that the annotations on classifier is a good technique to reuse the annotations but can create inconsistencies be-cause of inheritance (subclass and superclass have annotations incompatibles; the type of an instance in the scenarios is the superclass, but the class in exe-cution is the subclass). The same problem appears when the annotations are attached to interfaces (the interface and its implementations can have incon-sistent annotations and the real type of the instance, classified with the inter-face, is not known when we do the analysis).
Resolution: closed, no change
Revised Text: 
Actions taken:
October 24, 2002: received issue
September 24, 2004: closed issue
Discussion: 
I think that Miguel is confusing things here: section 4.1.1 describes the domain model that is defined independently of how it is mapped to UML stereotypes. Inserting the proposed sentence at the recommended point would not be particularly useful since it merely states the obvious: that instances conform to their class specification. The intent of the sentence is to propose a general statement on how to map from domain models to corresponding UML extensions. Since that is not the subject of this specification, I don't see a need for this at all. 

End of Annotations:=====
This is issue # 5705

Section 4, Page 4-4, Line 6. 

Suggest adding " In this case, the QoS characteristics and QoS value
of descriptors and instance must be compatible". This addition tries
to clarify that the annotations on classifier is a good technique to
reuse the annotations but can create inconsistencies be-cause of
inheritance (subclass and superclass have annotations incompatibles;
the type of an instance in the scenarios is the superclass, but the
class in exe-cution is the subclass). The same problem appears when
the annotations are attached to interfaces (the interface and its
implementations can have incon-sistent annotations and the real type
of the instance, classified with the inter-face, is not known when we
do the analysis).