This is fairly easy, intuitive, top-down method of software solution design.
Plan of forming Algorithm, a solution:
1. Understand & Precise what we wish to do,
1.1. Name a 'problem' and / or 'solution' properly,
1.2. We can use OOA Domains Modelling,
1.3. We can explore & learn basics of Domain Theory by performing Research: from books, films, the Internet, Courses, etc.,
1.4. Basics of Domain Theory let us know topic enough to talk well with experts if neccessary,
2. Plan the 'solution', perhaps writing it down, either as algorithmic steps, or model's parts to be used in these steps,
2.1. Identify things to do as parts of 'solution' that need to be done to achieve desired result,
2.2. For each of identified parts, repeat the whole process, naming 'subproblems' or 'partial solutions'.
Realization & Implementation.
Once we have Algorithm, we can:
- implement each of the 'solution parts',
- abstract & simplify similar parts, creating reusable components,
- integrate reusable components into the working solution(-s),
- document contracts.
Use of Packages In Java, perhaps in other languages as well.
Packages are containers for software building blocks, classes.
From classess, objects can be instantiated, 'assembled' into graphs and 'configured' with an 'initial state', to form working, running applications.
Each of such assemblies / configurations is a different application, with different version numbers and different behaviors.
Changes in classes between versions imply different assembly, therefore a different version.
Packages have 'qualified names', for example: 'car.engine.model', which might imply that:
- package is responsible car engine's model.
- that a car engine's model is a 'partial solution' for the 'car engine' functionality, and 'car engine' is a 'partial solution' for the 'car' functionality.
Every 'class' used in a 'partial solution' should belong to a package used for the 'partial solution'.
When the same package is used in many places, it should be renamed, abstracted and moved somewhere outside of a 'partial solution'.
Object Model Decomposition & Analysis.
Application, a Graph of Objects can be decomposed and painted as a Model, preferably precisely showing fields & methods (strategy in case of Stitie Machine), with dependencies visible, perhaps with initial state shown as well.
Then this Graphical Model can be examined & analysed.
After analysis, further abstraction & simplyfing, or corrections can be done.
There are Modelling Languages such as UML, particularly with Class Diagrams & Object Diagrams, which can be used here, i think.
This can be done using Petri Nets.
In case of Stitie Space, Stitie Machines at Odd & Even coords can represent Places & Transitions appropriately.
Protocol modelling can be realized using a Tree.
Source: My experience, , Wikipedia.
See also: Objects, Classes, Modelling, Object Relationships Modelling & Analysis.