mirror of
https://github.com/azaion/gps-denied-onboard.git
synced 2026-04-23 08:06:37 +00:00
Oleksandr Bezdieniezhnykh
66360d255e
update tutorial with 3. implementation phase add implementation commands
51 lines
2.3 KiB
Markdown
51 lines
2.3 KiB
Markdown
# decompose
|
|
|
|
## The problem description
|
|
`@docs/00_problem/problem_description.md`.
|
|
|
|
## Data samples
|
|
Located here: `@docs/00_problem/input_data`. They are for reference only, yet it is examples from the real data.
|
|
|
|
## Restrictions for the input data
|
|
`@docs/00_problem/restrictions.md`.
|
|
|
|
## Acceptance criteria for the output of the system:
|
|
`@docs/00_problem/acceptance_criteria.md`.
|
|
|
|
## Existing solution:
|
|
`@docs/01_solution/solution_draft.md`
|
|
|
|
## Role
|
|
You are a professional software architect
|
|
|
|
## Task
|
|
- Read problem description and solution draft, analyze it thoroughly
|
|
- Decompose a complex system solution to the components with proper communications between them, so that system would solve the problem.
|
|
- Think about components and its interaction
|
|
- For each component investigate and analyze in a great detail its requirements. If additional components are needed, like data preparation, create them
|
|
- Solution draft could be incomplete, so add all necessary components to meet acceptance criteria and restrictions
|
|
- When you've got full understanding of how exactly each component will interact with each other, create components
|
|
|
|
## Output
|
|
- Store description of each component to the file `docs/02_components/[##]_[component_name]/[##]._component_[component_name].md` with the next structure:
|
|
- Component Name
|
|
- Detailed description
|
|
- API methods, for each method:
|
|
- Name
|
|
- Detailed description
|
|
- Which component/system will use this method
|
|
- Input
|
|
- Output
|
|
- Description of input and output data in case if it not obvious
|
|
- Test cases for the method
|
|
- Integration tests for the component if needed.
|
|
- Non-functional tests for the component if needed.
|
|
- Store Extensions and Helpers to support functionality across multiple components to a separate folder `docs/02_components/helpers`.
|
|
- Generate draw.io components diagram shows relations between components.
|
|
|
|
## Notes
|
|
- Strongly follow Single Responsibility Principle during creation of components.
|
|
- Follow dumb code - smart data principle. Do not overcomplicate
|
|
- Components should be semantically coherents. Do not spread similar functionality across multiple components
|
|
- Do not put any code yet, only names, input and output.
|
|
- Ask as many questions as possible to clarify all uncertainties. |