partial end-to-end flow specification

[reteprelief]

Issue: There is a need to describe data flows between components before any details regarding their implementation is available. Right now an end to end flow have to reference a connection, but the connection could not be available yet. For example, we would like to define an end to end flow and to attach latency requirement to it, and then to use it as an input for the tool that will generate an architecture model satisfying to all requirements. So, we need to be able to have such a model:

system implementation sys.impl
   subcomponents
     a : process A;
     b : process B;
   flows
     fl : end to end flow a.out_flow -> b.in_flow;
 end sys.impl;

Proposed correction: do not require to have the complete end to end flow and let people redeclare the flow. In this case syntax of end_to_end_flow_spec can be updated as follows. Existing:

end_to_end_flow_spec ::=
   defining_end_to_end_flow_identifier : end to end flow start_subcomponent_flow_or_etef_identifier
   { -> connection_identifier
   -> flow_path_subcomponent_flow_or_etef_identifier } +
   [ { ( property_association } + } ]
   [ in_modes_and_transitions ] ;

Proposed:

end_to_end_flow_spec ::=
   defining_end_to_end_flow_identifier : end to end flow start_subcomponent_flow_or_etef_identifier
   [ { -> connection_identifier ->
   flow_path_subcomponent_flow_or_etef_identifier } *
   -> connection_identifier ]
   -> end_subcomponent_flow_or_etef_identifier
   [ { ( property_association } + } ]
   [ in_modes_and_transitions ]

[reteprelief]

See oasate/osate2-core#675 for implementation.

[buzden]

How can end_to_end_flow_identifier be used between two connection_identifiers? What's the meaning? So we can write source -> conn1 -> etef1 -> conn2 -> sink but actually those conn1 and conn2 would not be connected to etef1 since it is an end to end flow.

[buzden]

The mush better feature would be allowing to use end to end flow identifier where connection identifier is expected at the moment. This would allow to declare end to end flows trough partially defined connections (i.e. the reason of this general issue).

I mean a situation where you have

system S
features
  inp: in event data port;
  outp: out event data port;
end S;

system SFilter extends S
flows
  mainflow: flow inp -> outp;
end SFilter;

system Containing
end Containing;

system implementation Containing.impl
subcomponents
  s1: system S;
  s2: system S;
flows
  etef12: end to end flow s1.outp -> s2.inp;
end Containing.impl

At this moment we know that there is a flow between s1.outp and s2.inp but we do not know how this would be implemented yet.

Consider now the following refinement.

system implementation Containing.ref extends Containing.impl
subcomponents
  s2: refined to system SFilter;
  s3: system S;
flows
  etef23: end to end flow s2.outp -> s3.inp;
end Containing.ref

Now we still do not know how etef12 and etef23 would be implemented but we want to say that there is a flow end to end flow s1.outp -> etef12 -> s2.mainflow -> etef23 -> s3.inp but we have no ability to do this because we have to use connections to define non-trivial end to end flows.

[reteprelief]

An end to end flow starts with a subcomponent and ends with a subcomponent. So if you include such an end to end flow as a subflow in another end to end flow, the connection receding the etef being inserted leads to the first compponent, while the connection out of the etef conencts to the last component in the etef.

[reteprelief]

End-to-end flows are defined inside implementations. This means that if we place a requirement on such a flow it is on the implementation of the component. In other words the flow is internal to the component. Flows that are externally observable are captured by flow specs with flow implementations elaborating them. Given that we are specifying requirements on flow inside in an implementation: Question 1: Does it have an externally observable effect? Only if the etef is included in a flow implementation? Question 2: When you define the etef spec, i.e., only the end points, does the user flesh out the flow by simply editing in place after having added the other subcomponents and connections? Or does the user flesh them out by a refined to specification? Question 1:

[reteprelief]

I just noticed in your example above (with the flow etef23: end to end flow s2.outp -> s3.inp; you equate a flow with a connection. That;'s the SysML definition of a flow - a flow between a component's output and another component's input. In AADL that is a connection. In AADL a flow specification is an abstraction of a flow between a component's input and its output - SysML does not have the equivalent.

In your example you seems to suggest that you want to replace a connection from the original starting point to the end point with a "connection" that is a sequence of connections between subcomponents. There is a separate request from Steve Vestal to be able to replace connections by others (see saeaadl/aadlv3#6)

[buzden]

In your example you seems to suggest that you want to replace a connection from the original starting point to the end point with a "connection" that is a sequence of connections between subcomponents.

If we won't dig into dicsussion of whether to use flow or connection notion, exactly yes, you are right, I was talking about such kind of replacement.

you equate a flow with a connection

Well, actually my point of view is that there is no much difference between them if we are talking about end to end flows.

Every out feature can form a flow source, every in feature can form a flow sink. You can use flows (including sources and sinks) as beginning and ending of the end to end flow. So, every connection actually can be represented as an end to end flow.

You can use a flow path as the start or end of the end to end flow, but semantics of this is not really clear to me (I can't understand how the whole flow path can start some end to end flow; I feel that still some feature or flow sink/flow source should do this). Nevertheless, any flow path at some point starts from some feature and ends at some feature. So, finally, any end to end flow can be actually represented by one or several connections between features.

Flows which you are talking about that are missing in SysML are flow specifications and flow implementations but I wasn't talking about them. But the main idea is that connections replacing (refining) other connections whould make end to end flow notion to be useless.

[buzden]

I realized that you've changed in the 2.2 draft legality rules 10.3(L2) and 10.3(L3) about start and end identifiers for end to end flow. I can't find any issue here about this and I don't remember where it was discussed. But taking this into account, end to end flow starting or ending at a whole subcomponent cannot be represented as a connection, so my previous idea of uselessness of end to end flow notion having replaceable connections is not right.

One question raises. You are considering two extreme situations for start/end of end to end flow: a concrete one with flow sink/flow source and an abstract one, when we have no particular feature defined, only a subcomponent. First of all, what is the meaning of the second variant? What I can imagine is that you are trying to say that any feature of a subcomponent can be used for this flow; so it can be considered like having a flow source/flow sink of this end to end flow set to somewhat like subcomponent.any.

As far as I understand, the main goal of such specification of flows is security analysis (with ability to analyze abstract models, e.g. with not enough features yet). Don't you think, that it will be important to consider middle situations between "concrete feature of the subcomponent" and "any feature of the subcomponent"? For example, we want to say that some responsible flow can use only trusted features a or b and nothing more (i.e. subcomponent.{a, b} instead of subcomponent.any). Or to say that some responsible flow can use any feature except untructed feature c (i.e. subcomponent.(any but {c}) instead of subcomponent.any). This means that simple "subcomponent or flow source or flow path" for the start of end to end flow (as it is suggested in the draft) would be not enough to express such kind of properties.