MARTE 1.2 RTF Avatar
  1. OMG Issue

MARTE12_ — Coherency between active resource of MARTE and active class in UML

  • Key: MARTE12_-2
  • Legacy Issue Number: 16224
  • Status: closed  
  • Source: Commissariat a l Energie Atomique-CEA ( Dr. Sebastien Gerard)
  • Summary:

    In GRM, a Resource may be active. MARTE needs to specify the relationship(coherency) between an active resource and and active class.

  • Reported: MARTE 1.1 — Wed, 11 May 2011 04:00 GMT
  • Disposition: Resolved — MARTE 1.2
  • Disposition Summary:

    Accept changes

    Before stating the resolution taken, let us have here a summary of the discussion held:
    >>Sebastien Gerard:
    This issue is about the relationship between UML active class and the concept of active resource as defined in GRM.
    An active class is defined in UML (clause 13.3.8) as:
    “An active object is an object that, as a direct consequence of its creation, commences to execute its classifier behavior, and does not cease until either the complete behavior is executed or the object is terminated by some external object. (This is sometimes referred to as “the object having its own thread of control.”) The points at which an active object responds to communications from other objects is determined solely by the behavior of the active object and not by the invoking object. If the classifier behavior of an active object completes, the object is terminated.”

    In GRM, the concept of Resource owns an attribute named isActive which definition is following:
    “If true it indicates that the resource has an initial behavior associated that allows it to possibly perform its services autonomously or by the triggering and animation of behaviors on others.”

    Semantics seems to be equivalent, but the stereotype Resource extend Classifier and not only class, meaning that any kind of classifier can be active.
    Question: are we sure that it make sense for <<resource>> to extend Classifier and not only Class?
    What are the other know use cases of using this stereotype on other classifiers than Class?
    >>Bran Selic:
    Good point. The notion of "isActive" was intentionally restricted to objects (as the definiton states). It seems inappropriate and inconsistent with UML semantics for MARTE to extend that to classifiers in general. Note that, in principle at least, profiles should exist solely within the confines of UML semantics (stretchable as they may be).
    >>Julio Medina:
    Regarding the consideration of active resources beyond "classes" I recall the fact that very frequently we use the SchedulableResources (threads, processes and so on) as targets of steps not only through allocation relationships or direct association, but also by using directly scenarios (activity diagrams or sequence charts). And a very graphical mean to express this allocation is by using swimlanes (partitions), activities, or lifelines instead of classes. [Schedulable resources are a kind of resources with isActive always true].
    This happens because the means schedulability analysis has to cope with complexity is by demanding the designer for depicting worst case scenarios, instead of only behaviors. I understand that we can force the modeler to always define new (utilitarian) objects or classes for this purpose in what we call the platform model (which is good from a methodological point of view), but there is a significant expressiveness in defining this relationships by directly locating the steps in these scenario based diagrams. Also, this easies the expression of dynamic creation/destruction of threads.
    I do not see why this extension would conflict with the limited view of active class that was originally in UML. I actually think that profiles are precisely to extend the semantics available through UML though keeping its original design intents working. Of course, as I mentioned, from a methodological point of view this restriction is not that bad and in practical terms (just by chance) the tools we have already made are currently not relying on these capabilities of MARTE, but I think this is an unnecessary limitation, and there might be many other practitioners that use them.

    >>Murray Woodside
    We use SchedulableResource this way all the time in performance analysis too. However putting isActive on the objects (the instances) works well... conceivably the same class could be passive in some instances and active in others (though I have never seen this).

    >>Bran Selic:
    Julio, If I understood you correctly, you want to be able to imply the notion of active objects without being forced to actually model the object itself. This is because for some purposes, such as schedulability analysis, it was not necessary to have the explicit object in the model – it saved time and effort. We used this method a lot in the original SPT profile. I think it is useful, but, unless it is properly documented, people will simply not know about it and will not take advantage of the capability – we learned this from the SPT experience.
    My suggestion then is to keep things as they are, but that you provide at least an example in the spec for how to use this capability. Without that, the issue may be brought up again.

    >>Sébastien Gerard:
    I agree with the proposal of Bran. Julio, can you provide this example?

    Summary:
    So the way of making its use consistent with UML will be let to the user with the assistance of an additional example that is here provided.
    The resolution is then to add an example of how to model platform active elements like schedulableResources without defining them as objects or classes, but doing it directly as elements of behavioral models. This example is inserted at the end of the SAM Chapter.

  • Updated: Wed, 19 Dec 2018 16:37 GMT
  • Attachments: