saeaadl / aadlv3

Public area for discussion of new AADL V3 concepts and minor improvements
4 stars 0 forks source link

Wildcards in Property Assignment #11

Open smithdtyler opened 7 years ago

smithdtyler commented 7 years ago

I often find myself repeating property assignments that could easily be represented with a single wildcard. For example,

Actual_Processor_Binding => (reference (foodcourt)) applies to foodcourt.red, foodcourt.yellow, foodcourt.green;

Could be shortened to

Actual_Processor_Binding => (reference (foodcourt)) applies to foodcourt.*;

yoogx commented 7 years ago

(you may notice I'm picking when it comes to strong typing, ;-) )

what would be the rule if you extend a component and add a new component, e.g. foodcourt.black ? would you expect it to be part of the wildcard ? shall we warn about this side effect?

Beyond bindings, do you foresee any other usage? Note that we are revisiting bindings for v3, this could be addressed through other mechanisms with binding points.

I understand this is a lot to write, and some of my students complained in the past about this (and similarly about the verbosity of connections). But again it has an impact when it comes to extends/refinements that must be evaluated

smithdtyler commented 7 years ago

what would be the rule if you extend a component and add a new component, e.g. foodcourt.black ? would you expect it to be part of the wildcard ? shall we warn about this side effect?

I might be misinterpreting your example, but I think the wildcard would follow the existing conventions and rules for namespacing with extensions. Specifically, using the wildcard on an instance of the extension would include all subcomponents that could be accessed by name from a reference to the extension.

Example:

  processor implementation foodcourt.impl
    subcomponents
        red: virtual processor pizzaVirtualProcessor.impl;
        yellow: virtual processor pastaVirtualProcessor.impl;
  end foodcourt.impl;
  processor implementation foodcourt.supersize extends foodcourt.impl
    subcomponents
        black: virtual processor pizzaVirtualProcessor.impl;
  end foodcourt.supersize;

The following two are equivalent

  system implementation skyway.impl
    subcomponents
        foodcourt : processor foodcourt.supersize;
    properties
        Actual_Processor_Binding => (reference (foodcourt)) applies to foodcourt.red;
        Actual_Processor_Binding => (reference (foodcourt)) applies to foodcourt.yellow;
        Actual_Processor_Binding => (reference (foodcourt)) applies to foodcourt.black;
  end skyway.impl;
  system implementation skyway.impl
    subcomponents
        foodcourt : processor foodcourt.supersize;
    properties
        ---- * applies to all reachable (and applicable) subcomponents including
        ---- black, yellow, and red
        Actual_Processor_Binding => (reference (foodcourt)) applies to foodcourt.*;
  end skyway.impl;
yoogx commented 7 years ago

Your examples make sense, again the question (for which I have no answer, it is the reason why we have a committee, to discuss and then agree and ultimately vote) is:

Note that we have a mechanism already that emulates the ".*", through the inherit mechanism. If virtual processors foodcourt.<..> is bound to a given processor, then all its subcomponent will inherit from the value. That looks pretty close to what you have in mind. Would this help ?

smithdtyler commented 7 years ago

Note that we have a mechanism already that emulates the ".*", through the inherit mechanism. If processor foodcourt is bound to a given processor, then all its subcomponent will inherit from the value. That looks pretty close to what you have in mind. Would this help ?

That does help, but I'd rather not have to rely on inheritance.

If processor foodcourt is bound to a given processor

Is this a typo? This doesn't make sense to me.

yoogx commented 7 years ago

Hi, yes, I edited the typo, thanks

I understand you may not want to rely on inheritance. I assume discussion on wildcard is to be related to the discussion we have on configuration of systems.