Added FEO feature architecture #1109
Conversation
Change-Id: I02acda06a40a14fdb88815f016459f40c97cc90b
|
The created documentation from the pull request is available at: docu-html |
There was a problem hiding this comment.
I thinks this mixes component and feature architecture a little bit. The goal of the feature architecture is to allocate the feature requirements towards the involved components, however the implementation behind the components would be expected in the component architecture.
From my point of view, the FEO feature consists of these high-level components:
- FEO
- Communication
- Logging
In the 1.0 I would extend the components with Time and potentially Trace, however these components will be part of FEO in the 0.5, therefore included in the component above.
The feature architecture should make it clear, which use-cases/requirements we allocate (additionally) to the IPC component that was already identified in the IPC Feature. In the end the IPC component needs to implement the requirements identified by the IPC feature, as well as the requirements identified in the FEO feature.
The architecture behind the FEO component is something that I would not expect in the Feature Architecture but the Component Architecture. I.e. Agents, Primary/Secondary Process, Scheduler, .... is something that is component implementation specific and driven by the requirements identified at feature level but should be detailed at the component level.
@armin-acn / @ramceb would you agree or do you see this differently? We discussed a similar situation in communication with @LittleHuba and ended up separating component architecture (later moved to the module repo) and feature architecture (staying in the main score repo).
There was a problem hiding this comment.
@qor-lb, I agree that my current proposal of feature architecture looks a bit like a component architecture, but it follows the feature request. The feature request talks about Agents, Primary/Secondary Process, Executor/Scheduler etc. Thus, the feature architecture needs to pick it up somehow.
In the proposal, I tried to show how these entities are related to each other according to the description in the feature architecture. If I would make it even more generic, there wouldn't be much left, I assume, but maybe you have a good idea.
However, I would not agree that the FEO feature consists of FEO, Communication, and Logging. Communication and Logging are their own features according to my understanding, and the FEO implementation will just use components they provide. But maybe I am somehow misunderstanding the concepts here.
There was a problem hiding this comment.
I would agree that we should have a feature architecture focusing on the behavior of the involved components on the (system) boundaries of the features and a component architecture depicting the interaction of the components.
| scheduler --> prim: ok | ||
|
|
||
| deactivate scheduler | ||
|
|
There was a problem hiding this comment.
The diagram depicts nicely the interaction with the user application.
We should add the logical interfaces of external components e.g. mw::com, mw::log. At least this is my understanding of https://eclipse-score.github.io/score/main/process/process_areas/architecture_design/architecture_concept.html#static-view.
Additionally it would be good to indicate the system boundaries of the features as it was is done in https://eclipse-score.github.io/score/pr-1109/features/communication/ipc/architecture/feature_architecture.html#static-architecture
There was a problem hiding this comment.
I would agree that we should have a feature architecture focusing on the behavior of the involved components on the (system) boundaries of the features and a component architecture depicting the interaction of the components.
| end note | ||
|
|
||
| end loop | ||
|
|
There was a problem hiding this comment.
This is by intention incomplete, correct?
For the failure analysis it would be good to have one complete cycle visible in the diagrams
| scheduler -> activity_1: shutdown() | ||
| activity_1 -> activity_1: shutdown | ||
| activity_1 --> scheduler: ready | ||
|
|
|
|
||
| Overview | ||
| -------- | ||
| The current implementation of the feature "FEO" (Fixed Execution Order Framework) consists of a main |
There was a problem hiding this comment.
Maybe we should describe here, what the feature should do even if this does not reflect the current implementations. We could add an own chapter "Limitations/Known Issues" which just reflects, what is not implemented yet.
originates from CR #131370