-
Notifications
You must be signed in to change notification settings - Fork 22
rename relations for SysML compatibility #618
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
base: main
Are you sure you want to change the base?
Changes from 1 commit
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -54,14 +54,14 @@ Requirements | |
| .. needtable:: Overview of Feature Requirements | ||
| :style: table | ||
| :columns: title;id | ||
| :filter: search("feat_arch_sta__archdes$", "fulfils_back") | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. You have to change also the process description and process requirements. Not only the links. For example in the meta model picture.
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @aschemmel-tech , is that part of your PR #621? |
||
| :filter: search("feat_arch_sta__archdes$", "satisfies_back") | ||
| :colwidths: 70,30 | ||
|
|
||
|
|
||
| .. needtable:: Overview of Feature Requirements | ||
| :style: table | ||
| :columns: title;id | ||
| :filter: search("feat_arch_sta__archdes$", "fulfils_back") | ||
| :filter: search("feat_arch_sta__archdes$", "satisfies_back") | ||
| :colwidths: 70,30 | ||
|
|
||
|
|
||
|
|
@@ -80,24 +80,17 @@ The live feature architecture template snippets are maintained in the | |
|
|
||
| .. code-block:: rst | ||
|
|
||
| .. feat:: Feature Name | ||
| :id: feat__feature_name | ||
| :security: YES | ||
| :safety: ASIL_B | ||
| :status: invalid | ||
| :includes: logic_arc_int__feature_name__interface_name1 | ||
|
|
||
| General Feature Description | ||
|
|
||
| .. feat_arc_sta:: Feature Static View | ||
| :id: feat_arc_sta__feature_name__static_view | ||
| :security: YES | ||
| :safety: ASIL_B | ||
| :status: invalid | ||
| :fulfils: feat_req__feature_name__some_title | ||
| :satisfies: feat_req__feature_name__some_title | ||
| :includes: logic_arc_int__feature_name__interface_name1 | ||
| :belongs_to: feat__feature_name | ||
|
|
||
| General Feature Description | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
|
|
@@ -114,7 +107,7 @@ Dynamic Architecture | |
| :security: YES | ||
| :safety: ASIL_B | ||
| :status: invalid | ||
| :fulfils: feat_req__feature_name__some_title | ||
| :satisfies: feat_req__feature_name__some_title | ||
| :belongs_to: feat__feature_name | ||
|
|
||
| Put here a sequence diagram | ||
|
|
@@ -129,7 +122,7 @@ Logical Interfaces | |
| :security: YES | ||
| :safety: ASIL_B | ||
| :status: invalid | ||
| :fulfils: feat_req__feature_name__some_title | ||
| :satisfies: feat_req__feature_name__some_title | ||
|
|
||
| General Interface Description | ||
|
|
||
|
|
||
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -123,8 +123,22 @@ The feature architecture contain the following views: | |
| Static View | ||
| ----------- | ||
|
|
||
| The first viewpoint is named as *feature architecture*. It displays the SW Components within the SW modules (= dependable elements) which are required to realize the feature including their interactions. Also the *logical interfaces* and the interaction between the feature and the user are included in this view. On this architectural level the feature requirements shall be allocated. A full rendered example for the static architecture is maintained in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| The first viewpoint is named as *feature architecture*. It displays the SW Components within the SW modules (= dependable elements) which are required to realize the feature including their interactions. Also the *logical interfaces* and the interaction between the feature and the user are included in this view. On this architectural level the feature requirements shall be allocated. An example for the static architecture is shown here: | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. As previous comment, we do not use directives from the development meta model in process description, examples are now in module_template
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. currently there is no example in the module_template, but I agree we should leave this untouched because it is already how it should be in the future. |
||
|
|
||
| .. feat_arc_sta:: Feature 1 Architecture | ||
| :id: feat_arc_sta__example_feature__feature_1 | ||
| :security: YES | ||
| :safety: QM | ||
| :status: valid | ||
| :includes: logic_arc_int__example_feature__archex_logical_interface_1, logic_arc_int__example_feature__archex_logical_interface_2 | ||
| :satisfies: feat_req__example_feature__archdes_example_req | ||
| :belongs_to: feat__example_feature | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
|
|
||
| {{ draw_feature(need(), needs) }} | ||
|
|
||
| In all views, the components which are marked as ASIL_B related are drawn with red borders. | ||
|
|
||
|
|
@@ -150,8 +164,20 @@ See :ref:`uml_diagram_selection` in guideline for further information about the | |
| Interface View | ||
| -------------- | ||
|
|
||
| On the feature level only *logical interfaces* shall be displayed. This means that only logical names shall be provided for both the interface and the operations within. Those *logical interfaces* shall be connected to component interfaces on the module view. A rendered logical-interface example is maintained in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| On the feature level only *logical interfaces* shall be displayed. This means that only logical names shall be provided for both the interface and the operations within. Those *logical interfaces* shall be connected to component interfaces on the module view. | ||
|
|
||
| .. logic_arc_int:: Logical Interface 1 | ||
| :id: logic_arc_int__example_feature__archcon_logical_interface_1 | ||
| :security: YES | ||
| :safety: ASIL_B | ||
| :status: valid | ||
| :satisfies: feat_req__example_feature__archdes_example_req | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
|
|
||
| {{ draw_interface(need(), needs) }} | ||
|
|
||
| SW Module View | ||
| ============== | ||
|
|
@@ -171,8 +197,19 @@ Static View | |
|
|
||
| The *component architecture* describes the implementation of the functionalities in a white-box view. It describes the internal structure of SW components and their decomposition. It provides a more detailed information concerning the respective interfaces of a component. If a SW component interacts with a different component it is also included via a *use* relationship in the diagram. An example of the *component architecture* is displayed here: | ||
|
|
||
| A full rendered component-architecture example is maintained in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| .. comp_arc_sta:: Component 1 Static View | ||
| :id: comp_arc_sta__example_feature__archdes_component_concept_1 | ||
| :status: valid | ||
| :safety: ASIL_B | ||
| :security: NO | ||
| :satisfies: comp_req__example_feature__archex_example_req | ||
| :belongs_to: comp__component_example_1 | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
|
|
||
| {{ draw_component(need(), needs) }} | ||
|
|
||
| The decomposition is optional and relies on the complexity of the component. Thus there is no graphic representation required for it. | ||
| In all views the components which are marked as ASIL_B related are drawn in red color. | ||
|
|
@@ -197,8 +234,21 @@ Following scenarios should be included: | |
| Interface View | ||
| -------------- | ||
|
|
||
| The component interface view shows the actual interfaces of the component. Also links to their corresponding logical interfaces are displayed in this view. A rendered component-interface example is maintained in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| The component interface view shows the actual interfaces of the component. Also links to their corresponding logical interfaces are displayed in this view: | ||
|
|
||
| .. real_arc_int:: Component Interface 1 | ||
| :id: real_arc_int__example_feature__archdes_component_interface_1 | ||
| :status: valid | ||
| :safety: ASIL_B | ||
| :security: NO | ||
| :satisfies: comp_req__example_feature__archex_example_req | ||
| :language: cpp | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
|
|
||
| {{ draw_interface(need(), needs)}} | ||
|
|
||
| Platform View | ||
| ============= | ||
|
|
@@ -421,8 +471,29 @@ Here are some excerpts of UML diagrams made from the requirements of that file. | |
| Feature Architecture | ||
| ^^^^^^^^^^^^^^^^^^^^ | ||
|
|
||
| The following section links to the rendered feature example that is now maintained in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| The following section is an example, how an `Feature <https://eclipse-score.github.io/score/main/features/index.html>`_ looks like and how the architecture of an Feature is described. Please note that components with an "ASIL_B" safety rating are highlighted with red borders in the diagram (e.g., "Component 1"). | ||
|
|
||
| .. feat:: Feature Name | ||
| :id: feat__feature_name_example | ||
| :security: YES | ||
| :safety: ASIL_B | ||
| :status: invalid | ||
| :includes: logic_arc_int__example_feature__archex_logical_interface_1 | ||
|
|
||
| .. feat_arc_sta:: Feature Static Architecture View - Rendered Example | ||
| :id: feat_arc_sta__example_feature__archdes_getstrt | ||
| :security: YES | ||
| :safety: QM | ||
| :status: valid | ||
| :includes: logic_arc_int__example_feature__archex_logical_interface_1, logic_arc_int__example_feature__archex_logical_interface_2 | ||
| :satisfies: feat_req__example_feature__archdes_example_req | ||
| :belongs_to: feat__example_feature | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
|
|
||
| {{ draw_feature(need(), needs) }} | ||
|
|
||
| .. code-block:: rst | ||
|
|
||
|
|
@@ -440,7 +511,7 @@ The following section links to the rendered feature example that is now maintain | |
| :safety: QM | ||
| :status: valid | ||
| :includes: logic_arc_int__example_feature__archex_logical_interface_1, logic_arc_int__example_feature__archex_logical_interface_2 | ||
| :fulfils: feat_req__example_feature__archdes_example_req | ||
| :satisfies: feat_req__example_feature__archdes_example_req | ||
| :belongs_to: feat__example_feature | ||
|
|
||
| .. needarch:: | ||
|
|
@@ -454,8 +525,19 @@ Component Architecture | |
|
|
||
| The following section is an example, how an component looks like and how the detail design of an component is described. Please note that components with an "ASIL_B" safety rating are highlighted with red borders in the diagram (e.g., "Component 1"). | ||
|
|
||
| The rendered component examples are maintained in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| .. comp_arc_sta:: Component Static View - Rendered Example | ||
| :id: comp_arc_sta__example_feature__component_getstrt | ||
| :status: valid | ||
| :safety: ASIL_B | ||
| :security: NO | ||
| :satisfies: comp_req__example_feature__archex_example_req | ||
| :belongs_to: comp__component_example_1 | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
|
|
||
| {{ draw_component( need(), needs ) }} | ||
|
|
||
| .. code-block:: rst | ||
|
|
||
|
|
@@ -464,7 +546,7 @@ The rendered component examples are maintained in the | |
| :status: valid | ||
| :safety: ASIL_B | ||
| :security: NO | ||
| :fulfils: comp_req__example_feature__archex_example_req | ||
| :satisfies: comp_req__example_feature__archex_example_req | ||
| :belongs_to: comp__component_component_getstrt | ||
|
|
||
| .. needarch:: | ||
|
|
@@ -506,8 +588,20 @@ Besides storing the output it is also possible to display the generated PlantUML | |
|
|
||
| Debug example for component architecture: | ||
|
|
||
| See the rendered debug example in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| .. comp_arc_sta:: Component Static View - Rendered Debug Example | ||
| :id: comp_arc_sta__example_feature__component_getstrt_debug | ||
| :status: valid | ||
| :safety: ASIL_B | ||
| :security: NO | ||
| :satisfies: comp_req__example_feature__archex_example_req | ||
| :belongs_to: comp__component_example_1 | ||
|
|
||
| .. needarch:: | ||
| :scale: 50 | ||
| :align: center | ||
| :debug: | ||
|
|
||
| {{ draw_component( need(), needs ) }} | ||
|
|
||
| .. _manual_addition_uml: | ||
|
|
||
|
|
@@ -525,7 +619,8 @@ To make *needuml* work we have to replace the *need()* call with a different fun | |
| :status: valid | ||
| :safety: ASIL_B | ||
| :security: NO | ||
| :uses: logic_arc_int__example_feature__archcon_logical_interface_1 | ||
| :uses: logic_arc_int__example_feature__archex_logical_interface_1 | ||
| :satisfies: comp_req__example_feature__archex_example_req | ||
| :belongs_to: comp__component_component_manual_getstrt | ||
|
|
||
| .. needuml:: | ||
|
|
@@ -535,8 +630,22 @@ To make *needuml* work we have to replace the *need()* call with a different fun | |
| } | ||
| CM -> LI1: EXTRA_LINKAGE_MANUALLY_ADDED | ||
|
|
||
| See the rendered manual-edit example in the | ||
| `module template documentation <https://eclipse-score.github.io/module_template/main/>`__. | ||
| .. comp_arc_sta:: Component Architecture Static View - Rendered Example Manually Edited | ||
| :id: comp_arc_sta__example_feature__component_manual_getstrt | ||
| :status: valid | ||
| :safety: ASIL_B | ||
| :security: NO | ||
| :uses: logic_arc_int__example_feature__archex_logical_interface_1 | ||
| :satisfies: comp_req__example_feature__archex_example_req | ||
| :belongs_to: comp__component_example_1 | ||
|
|
||
| .. needarch:: | ||
|
|
||
| {{ draw_component( needs.get('comp__component_example_1'), needs ) }} | ||
|
|
||
| component "Component Manual" as CM { | ||
| } | ||
| CM -> logic_arc_int__example_feature__archex_logical_interface_1: EXTRA_LINKAGE_MANUALLY_ADDED | ||
|
|
||
| You can add any layout or additional configuration you want before you call the *draw_xyz*. | ||
|
|
||
|
|
||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for contribution, but it seems your change request are due to special tool requirements. This is not in scope with our concept. We discussed that already with @aschemmel-tech Please get in contact
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
My understanding was that we are fine if SysML 2.0 use of the terms is still the same:
In my understanding "derived" relationship for requirements is still part of SysML 2.0: see https://www.omg.org/spec/SysML/2.0/Language/PDF section "9.6 Requirement Derivation Domain Library" or Figure 70 description. "Refinement" seems not to be requirement specific.
Also see https://www.omg.org/spec/SysML/2.0/Transformation/PDF : 7.8.8.3.1 DeriveReqt_Mapping "A SysML::Requirements::DeriveReqt relationship is mapped to a SysML v2 DerivationConnections::Derivation model library element."
"Satisfy" relationship also still part of SysML 2.0: See e.g. 7.21.1 Requirements Overview: "A design solution must satisfy the requirement and all of its member requirements and constraints to be a valid solution." or 7.21.4 Satisfy Requirement Usages
Also see https://www.omg.org/spec/SysML/2.0/Transformation/PDF : 7.8.8.3.22 Satisfy_Mapping "A SysML::Requirements::Satisfy relationship is mapped to a SysML v2 SatisfyRequirementUsage."
It is not a special tool requirement, it is just how we have configured our tooling (codebeamer and trlc) by using requirement attributes which conform to UML 1.x