New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
partial end-to-end flow specification #7
Comments
See oasate/osate2-core#675 for implementation. |
How can end_to_end_flow_identifier be used between two connection_identifiers? What's the meaning? So we can write |
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
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.
Now we still do not know how |
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. |
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. |
I just noticed in your example above (with the flow 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) |
If we won't dig into dicsussion of whether to use
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 You can use a Flows which you are talking about that are missing in SysML are |
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 One question raises. You are considering two extreme situations for start/end of 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 |
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:
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:
Proposed:
The text was updated successfully, but these errors were encountered: