Omg issue Number


Disposition: Resolved OMG Issue No: 11862



Yüklə 1,11 Mb.
səhifə25/44
tarix24.11.2017
ölçüsü1,11 Mb.
#32756
1   ...   21   22   23   24   25   26   27   28   ...   44

Disposition: Resolved

OMG Issue No: 11862


Title: attribute “Add short rationale in section 10.3”

Source:

THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)



Summary:

In introduction of section 10.3, a short rationale should be given to explain which meta-classes are extended (in relation with section 7.3 on classifiers and instances).



Resolution:

Add a paragraph after the one in the introduction of section 10.3 explaining the application of the rule in section 7.3 to the extended metaclasses.


Revised Text:


  1. Add the following paragraph in the introduction of section 10.3, just after the one in there.

“In order to get the maximum flexibility in the ways of applying the proposed stereotypes, most of the UML elements extended, are extended by the generic stereotype Resource. Then, through inheritance the large majority of stereotypes in GRM may extend elements like Property, InstanceSpecification, Classifier, Lifeline, and ConnectableElement. In particular, they might be applied for example to Classifiers, as well as to InstanceSpecifications of those very same Classifiers. In this case it is worth to consider the rules describe in section 7.3 for the usage of a stereotype in such situation. According to this rule when a stereotype is applied on an instance, the value of the attributes not explicitly assigned in the annotation of the instance are taken in principle from the defaults in the profile stereotype definition, but they might have to be taken from the annotation of the same stereotype on its corresponding classifier, which may have overwrote them, making effective with it the classifier nature of the annotation.”



Disposition: Resolved

Disposition: Resolved

OMG Issue No: 11863


Title: concept of refinement

Source:

THALES (Mr. Sebastien Demathieu, sebastien.demathieu@thalesgroup.com)



Summary:

Does the concept of refinement only apply to clock refinement? My first impression is that this concept may apply to other NFPs. In any case, this needs to be clarified.



Resolution:

There is agreement to extend the Refinement to any kind of NFP constraints. Issue 11864 required to use the same name in the domain model and in the UML representation so we chose NFPRefine for the name.

The resolution replaces every occurrence of ClockRefine by NFPRefine. It also replaces the association to Time::ClockConstraint by an association to NFPs::NfpConstraint. In the domain model, the metaclass Refinement is associated to NFP_Constraint instead of ClockConstraint.

The second constraint is removed since it was assuming all constraints were ClockConstraint.



Revised Text:

In section 12.2, page 138, change figure 12.2, into:



In section 12.2, page 137, change text:

Figure 12.1 shows a general view of allocation, while Figure 12.2 shows the refinement relations. Allocations are annotated with NfpConstraints as built from the NFP section of this document and refinement are more precisely annotated with ClockConstraints as defined in the Time Model section (chapter 9). Allocations provide links between independent models, while refinement/abstraction works by changing the focus on an underlying similar structure.

Into:


Figure 12.1 shows a general view of allocation, while Figure 12.2 shows the refinement relations. Both the Allocations and the refinement are annotated with NFP_Constraints as built from the NFP section. Time constraints can also be associated since the metaclass NFP_Constraints is a generalization of the metaclass ClockConstraint defined in the Time Model section (chapter 9). Allocations provide links between independent models, while refinement/abstraction works by changing the focus on an underlying similar structure.

In section 12.2, page 138, change text:

Time::ClockConstraint specializes NFP_Annotations::NfpConstraint, using such constraints provides time links between the clients and the suppliers.

Into:


The refinement process generally involves the definition of additional constraints to precise links between the general element and the refined ones. For instance, one may want to specify how the time bases relates, how the bandwidth (or power consumption …) is spread amongst refined elements. The association with some NFPs::NFP_Annotations::NfpConstraint is a provision for defining such links.

In section 12.3.1, page 140, change figure 12.6, into:



In section 12.3.1, page 140, change text:

Concerning the refinement we also think it is important to emphasize the fact that the refinement process implies some additional constraints that mostly concern clocks as defined in the Time Model package.

into:


Concerning the refinement we also think it is important to emphasize the fact that the refinement process implies some additional constraints. It could be ClockConstraints to relate clocks at the different abstraction level or any other NfpConstraint.

Replace section 12.3.2.7 by:



12.3.2.7 NfpRefine (from Alloc)

The stereotype NfpRefine maps the domain element Refinement (section F.6.5) denoted in Annex F.

NfpRefine is a dependency based on UML::Dependency. It is a mechanism for associating one abstract model element to refined model elements. It is a provision for grouping elements. The refinement process implies some additional constraints between the abstract element and the refined elements.

When several application model elements are to be collectively allocated to execution platform elements they should first be grouped using the dependency NfpRefine. Some NfpConstraints, like for instance ClockConstraint, should be associated with this dependency to specify relations between the general element and the refined ones.



Extensions

• Dependency (from Dependencies).



Associations

• constraints: NFPs::NfpConstraint [*] The set of constraints implied by the refinement.



Constraints

[1] A single dependency NfpRefine shall have only one client (from), but may have one or many suppliers (to).



context NfpRefine

inv: base_Dependency.from->size()=1 and base_Dependency.to->size()>=1

Notation

The relationship NfpRefine is a dashed line with an open arrow head. The arrow points in the direction of the refinement. In other words, the directed line points “from” the element being refined “to” the elements that are the refined elements.

In section F.6.5 subsection Associations, page 544, insert the following association at the end of the list:

• constraints: NFPs::NFP_Annotation::NFP_Constraint [*] The set of constraints implied by the refinement.



Disposition: Resolved


Yüklə 1,11 Mb.

Dostları ilə paylaş:
1   ...   21   22   23   24   25   26   27   28   ...   44




Verilənlər bazası müəlliflik hüququ ilə müdafiə olunur ©muhaz.org 2024
rəhbərliyinə müraciət

gir | qeydiyyatdan keç
    Ana səhifə


yükləyin