Requirement that an implementation must implement every flow spec

[stevevestal]

The standard says "10.2 Flow Implementations (1) Component implementations must provide an implementation for each flow specification." Is there a reason for this restriction?

The use case is that I have a type with a flow specification, then I declare an implementation for that type that is intended to be extended later with a second implementation that adds additional detail, including the specific flow path. I cannot declare a place-holder flow implementation, since flow implementations cannot be refined other than changes to property association values.

It is acceptable to declare a subcomponent with a classifier having only a type and no implementation, and to declare flows through a flow path of that subcomponent. In the event the classifier did specify an implementation, and the flow path specification did not have a flow path implementation, seems like the behavior would be the same w.r.t. flows through that subcomponent flow path.

Latency budget analysis is an example analysis that one would like to be able to repeatedly perform as a model is elaborated during development by adding detail incrementally.

[reteprelief]

Steve, The rule is not stated clearly. It should say that of a component has subcomponents then the flow spec should have a flow implementation. For leaf components a flow spec should be sufficient. Peter

From: stevevestal [mailto:notifications@github.com] Sent: Monday, October 7, 2019 10:28 AM To: saeaadl/aadlv2.2 aadlv2.2@noreply.github.com Cc: Subscribed subscribed@noreply.github.com Subject: [saeaadl/aadlv2.2] Requirement that an implementation must implement every flow spec (#41)

The standard says "10.2 Flow Implementations (1) Component implementations must provide an implementation for each flow specification." Is there a reason for this restriction?

The use case is that I have a type with a flow specification, then I declare an implementation for that type that is intended to be extended later with a second implementation that adds additional detail, including the specific flow path. I cannot declare a place-holder flow implementation, since flow implementations cannot be refined other than changes to property association values.

It is acceptable to declare a subcomponent with a classifier having only a type and no implementation, and to declare flows through a flow path of that subcomponent. In the event the classifier did specify an implementation, and the flow path specification did not have a flow path implementation, seems like the behavior would be the same w.r.t. flows through that subcomponent flow path.

Latency budget analysis is an example analysis that one would like to be able to repeatedly perform as a model is elaborated during development by adding detail incrementally.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/saeaadl/aadlv2.2/issues/41?email_source=notifications&email_token=AAFXHODDHO6FD7E67KNQCULQNNBPBA5CNFSM4I6FKFJKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HQCUDMA, or mute the threadhttps://github.com/notifications/unsubscribe-auth/AAFXHOB2MIACYCUBBALBINLQNNBPBANCNFSM4I6FKFJA.

[stevevestal]

Below is an example. By both the literal and "should say" interpretation, isn't this illegal? Nevertheless, OSATE accepts it and seems to do what I would like. It allows me to defer specifying a flow implementation until an extension of PSource.Impl, but use of either the abstract or the concrete versions results in reasonable flows being created in the instance file. (This is the best work-around I can think of now, given that flow refinement features are not strong enough to specify an alternative routing in an extension.)

My concern is that I would do this in models, and then someone would file a ticket on OSATE that would cause this "bug" to be "fixed." Unless there is some lurking complication in doing so, the simpler thing would be for the standards committee to say this is OK.

process PSource
    features
        pout: out feature;
    flows
        fsrc: flow source pout;
end PSource;

process implementation PSource.Impl
    subcomponents
        t: thread;
           -- Flow source fsrc is specified but not implemented.
end PSource.Impl;

thread ThreadComponent
    features
        pout: out feature;
end ThreadComponent;

process implementation PSource.Child extends PSource.Impl
    subcomponents
        t: refined to thread ThreadComponent;
    connections
        t_con: feature t.pout -> pout;
    flows
        fsrc: flow source t -> t_con -> pout;
end PSource.Child;

[lwrage]

Even though the sentence in question sounds like a legality rule it is not listed as one. That's why there is no check in OSATE.

[stevevestal]

Unless someone objects, then, I'll just consider this a clarification of the standard.

[yoogx]

In Toulouse, we agreed

[stevevestal]

I recommend the committee state that 10.2 is removed, that condition is not required (and this behavior is not a bug in OSATE). The comment made on Jan 27 says it was agreed in the Toulouse meeting.

[jjhugues]

After discussion with Lutz, propose

"10.2 Flow Implementations (1) Component implementations may provide one or more implementations for each flow specification."