Unit 11

Summative assessment: System implementation

Summative assessment reflection

This assignment required building a Python-based simulation of a humanoid robot working in a restaurant environment. The robot had to interact with other system components, such as tables, a kitchen, and an orchestrator. The implementation followed the structure defined earlier during the design phase, using object-oriented principles and a modular approach. Automated tests were also required to check system behavior and help ensure correctness during development.

The implementation mostly followed the initial design, with only minor changes. These were mainly caused by Python’s language features or the need to make data flow more clear. Most of the changes involved adding helper methods to simplify interactions between objects and make data easier to access. This also made testing and simulation more straightforward. One example was the decision to process the task queue manually instead of automatically. This made the system’s behavior easier to follow and better suited the goal of building a simulation.

While the system did not include any particularly difficult parts, I had to think carefully about how the orchestrator would handle incoming requests. Separating the queue handling into two steps — queuing and processing — was not part of the original design but helped make the logic more clear and modular. This led to the introduction of separate methods in several classes and made it easier to simulate delayed execution, as would happen in a real system.

The overall system structure remained close to what was planned during the design phase. I didn’t need to change any core components, which shows that the early modeling was mostly accurate. The small adjustments, like adding billing helpers or changes to task handling, were based on practical needs during development and didn’t affect the system’s main structure.

One of the most useful parts of this phase was the use of automated tests. While the tests were first added to meet assignment requirements, they quickly became important for checking that new changes didn’t break existing logic. They also acted as documentation and made it easier to update or refactor the code later. Unlike static diagrams, the tests remained up to date and executable, and helped confirm that the system worked as expected.

This phase showed that lightweight, code-based tools like tests can often take the role of formal UML diagrams. They are easier to maintain, provide direct feedback, and are closely tied to the actual code. Overall, the implementation phase confirmed the initial design and showed the value of building modular components and supporting them with strong test coverage.