Example: Detailed Design#
Launch Manager Detailed Design
|
status: draft
security: NO
safety: ASIL_B
|
||||
Detailed Design for Component: Launch Manager#
Description#
Example:
component is split into two units unit1 and unit2 based on single responsibility principle.
unit2 is injected to unit1 one via dependency injection for testability.
Rationale Behind Decomposition into Units#
Note
Reason for split into multiple units could be- - Based on design principles like SOLID,DRY etc - Based on design pattern’s etc.
Static Diagrams for Unit Interactions#
A static view provides an overview of the units and their relationships using
UML 2.0 notations (e.g. class diagrams, component diagrams). Use .. uml::
or .. image:: directives to include the diagram.
Dynamic Diagrams for Unit Interactions (optional)#
A dynamic view illustrates how the units within a component interact over their interfaces to fulfill a specific use case or functionality. It is optional when the component’s behaviour is straightforward and can be understood from the static view and interface documentation alone.
Use standard UML behavioural diagrams (sequence diagrams, state machine diagrams)
with .. uml:: or .. image:: directives.
Units within the Component#
The relationship between a unit and its parent component is established implicitly through the file path. Each component has its own directory, and units residing within that directory belong to it. The unit’s attributes and behaviour are documented in the source code itself. A separate static diagram per unit is not required.
Interface documentation of a software unit is part of the source code (e.g. public API headers, trait definitions, or documented function signatures).
Example:
unit1: implements the main logic (see source code for details)
unit2: injected into unit1 via dependency injection for testability