MARTE 1.0b2 FTF Avatar
  1. OMG Issue

MARTE — GRM: Domain Model

  • Key: MARTE-58
  • Legacy Issue Number: 11768
  • Status: closed  
  • Source: Fundacion Tecnalia Research and Innovation ( Huascar Espinoza)
  • Summary:

    [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.

  • Reported: MARTE 1.0b1 — Fri, 7 Dec 2007 05:00 GMT
  • Disposition: Resolved — MARTE 1.0b2
  • Disposition Summary:

    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

  • Updated: Fri, 6 Mar 2015 20:58 GMT