Omg issue Number

Disposition: Resolved

OMG Issue No: 12428

Title: wrong multiplicity in sharedResources required for a SaStep

Source:

Universidad de Cantabria (Dr. Julio Medina, [e-mail])

Summary:

This might be an editorial issue since it is correct in section F but not in SAM. In the association sharedResource from SaStep to SAM_Resources::SharedResource (see Figure 16.4, page 289 in SAM)change multiplicity from 0..1 to * , This is correct and well explained in the Domain description in Annex F (Section F.11.3 page 609) but Figure 16.4 and the description in sections 16.3.2.3 and probably 16.3.2.8 must be adjusted..

Resolution:

The resolution of this issue makes consistent the domain and UML views of SAM in the aspect of sharedResources linked to steps. It complements resolution of Issue 11778 stating consistently that a SaStep may require multiple passive shared resources to be locked during its execution.

First it is necessary to change from 0..1 to * the multiplicity in the association sharedResource that exists between SaStep and SAM_Resources::SharedResource in Figure 16.4, page 289 in the domain view of SAM. Then align the profile correspondingly by correcting the pictures in Figure 16.7 or Figure 16.9, and insert the description of the association as it is in Section F.11.3 page 609 in the description of the stereotype SaStep in page 298. In the GRM domain view it is necessary also to change to 0..* the multiplicity of MARTE::GRM::ResourceUsages::ResourceUsage.usedResources so that it may admit incomplete definitions of usages. For consistency it is convenient also to extend the multiplicity of requiredAmount to 0..*.

Revised Text:

21. 
    Modify Figure 16.4, page 289 consistently with the resolution of issue 11778 so that the multiplicity 0..1 in the association sharedResource becomes *:

    New Figure:

    
    
    
    

22. 
    Change Figure16.7 with:
    

23. 
    Consistently with the resolution of Issue 11778, in the associations of SaStep in section 16.3.2.3 use the text :
    

sharedRes: SaSharedResource [*] {subsets GRM::ResourceUsage.usedResources} set of shared resources that will be locked during the execution of this step.

24. 
    Consistently with the resolution of Issue 11778, in the associations of SaStep in section F.11.3 use the text :
    

sharedResource: SharedResource [*] {subsets GRM::ResourceUsages::ResourceUsage. usedResources} set of shared resources that will be locked during the execution of this step.

25. 
    In section F.4.27 (page 526) change to 0..* the multiplicity of MARTE::GRM::ResourceUsages::ResourceUsage.usedResources and MARTE::GRM::ResourceUsages::ResourceUsage.requiredAmount
    

26. 
    Change Figure 10.13 by this:
    

Disposition: Resolved

Disposition: Deferred

OMG Issue No: 11411

Title: attribute “SwSchedulableResource does not inherit from GRM::SchedulableResource stereotype”

Source:

Thales: Sébastien Demathieu, [e-mail]

Summary:

The GRM packages defines a <> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <>. However, there is no direct link between these two stereotypes. GRM::SchedulableResource directly specializes GRM::Resource, while SRM::SwSchedulableResource specializes SRM::SwConcurencyResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar name, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

Discussion:

The link between both is its semantics...., which is expressed in the domain view. Same thing happens in issue 11412.

 
The stereotypes just happen to be not strongly related (by inheritance i.e.) because they are used for different purposes. SRM is basically attached to its usage to create OS utilitarian model libraries, GRM stuff if used to architect the problem and analysed/verify the problem and the solutions. Hence the links are to be provided when necessary by the semantics-aware transformations among tools that deal with both worlds

Resolution:

The adequate solution is to make SwSchedulableResource inherit from SchedulableResource, which simplifies the annotations the user needs to do, or simply close the issue. But it has caused some polemics, see issue 11856 (synchronization between GRM, SRM, HRM and Analysis). For this reason, this issue is deferred.

Revised Text:
Disposition: Deferred

Disposition: Deferred

OMG Issue No: 11412

Title: attribute “SwMutualExclusionResource does not inherit from GRM::MutualExclusionResource stereotype”

Source:

Thales: Sébastien Demathieu, [e-mail]

Summary:

The GRM package defines a <> stereotype. The SRM package, which is presented as a specialization of GRM to model software resources, defines a stereotype with a similar name: <>. However, there is no direct link between these two stereotypes. GRM::MutualExclusionResource directly specializes GRM::Resource, while SRM::SwMutualExclusionResource specializes SRM::SwSynchronizationResource, which specializes SRM::SwResource, which specializes GRM::Resource. Stereotypes have quite similar names, which may think of related concepts. However, their use and their related stereotype attributes are quite different.

Discussion:

The link between both is its semantics...., which is expressed in the domain view. Same thing happens in issue 11411.

 
The stereotypes just happen to be not strongly related (by inheritance i.e.) because they are used for different purposes. SRM is basically attached to its usage to create OS utilitarian model libraries, GRM stuff if used to architect the problem and analysed/verify the problem and the solutions. Hence the links are to be provided when necessary by the semantics-aware transformations among tools that deal with both worlds

Resolution:

The adequate solution is to make SwMutualExclusionResource inherit from MutualExclusionResource, which simplifies the annotations the user needs to do, or simply close the issue. But it has caused some polemics, see issue 11856 (synchronization between GRM, SRM, HRM and Analysis). For this reason, this issue is deferred.

Revised Text:
Disposition: Deferred