MARTE — GRM: Domain Model

[GRM: Domain Model] A number of GRM domain concepts make it hard to understand and use. These mainly relate to its mapping with the UML profile and its refinement in the HRM, SRM and analysis profiles: a) Figures 10.3 and 10.4 illustrate the ‘resource’ concept as two kinds of entities: an instance (ResourceInstance) and a classifier (Resource). This separation is not explained and is not used along the remaining parts of the spec. I.e., all the associated or specialized concepts are related to ‘Resource’. Also, the profile only defines a ‘Resource’ stereotype. Furthermore, NFPs are only associated with ‘Resource’. What about NFPs related to ResourceInstances? ? I’d suggest to remove the ResourceInstance concept, as conceptually, has not any relevance, and create confussion. b) Fig. 10-13 introduces the concepts of ‘ResourceUsage’, ‘UsageTypedAmount’, which inherits from ‘ResourceAmount’. However, at UML profile definition level, only <<ResourceUsage>> is provided, by using the attributes of UsageTypedAmount (from the domain model). I’d suggest to harmonize both, domain model and profile. c) A double inheritance of ‘ComputingResource’ from ‘Resource’ has been defined (Fig. 10.6 and, Fig. 10.11 through ‘ProcessingResource’). I’d suggest to remove one of them. d) GRM attempts to be a generic framework for modelling resources. However, some of the attributes seems too specific and not useful when specializing this package (e.g., HRM & SRM). For instance, ‘packetSize’ in ‘CommunicationEndPoint’ (Fig. 10-8) is related to specific kinds of protocols. ‘speedFactor’ in ‘ProcessingResource’ is an analysis-specific parameters.

a) Instances and Classifiers are consubstantial to UML and their role in
MARTE are explained in the CoreElements Chapter. The instances are
there to illustrate the finite nature of resources. No change.
b) UML View is an utilitarian mapping of the domain model, and in this case
the harmonization is already included in the constraints that describe the
rules for the utilization of resourceUsage. No change.
c) Double inheritance is neither conceptually nor practically a problem. No
change.
d) Very few attributes have been defined, but all of them are optional and do
not jeopardize the conceptual and architectural role of the stereotypes in
GRM. No change
Disposition: Closed, no change