Software design · UML
Systems designed before they were built.
Interactive UML class models created in Lucidchart - the prototype phase of applications later implemented in Java and C#. Every document below can be explored in place: pan, zoom and read the constraints where they were written.
- My role
- Sole author
- Tool
- Lucidchart
- Documents
- 4 embedded models
- Implemented in
- Java & C#
Why modelling matters
The cheapest place to find a design flaw
A class model forces the hard decisions early: who owns what, which relationships are one-to-many, what lives and dies together, and which rules the system must never break. Changing an answer on a diagram costs minutes; changing it after implementation costs days.
The documents on this page are working artefacts, not decoration. They carry constraint notes, multiplicities, generalisation sets and open questions exactly as they were written during design. That is what UML is for me: a thinking tool first - it makes vague ideas precise enough to argue with - and a communication tool second, giving a team one shared picture of the system before anyone commits code to a structure that might be wrong.
Design document 01
Scientific Research Project Management System
An analytical class model for managing scientific research: projects with budgets and lifecycle statuses, experiments with ordered data records, publications, labs and specialisations, and a participant hierarchy of researchers, experiment supervisors and technicians joined through an association class that carries roles and join dates.
Constraint notes document the business rules directly on the diagram - attribute ranges, name-length limits, generalisation sets marked disjoint or complete, and an ordered collection. This design was later developed into a working C# application, which makes it the clearest example here of a model doing its job: the hard decisions were made on paper first.
Open in Lucidchart - opens in a new tabDesign document 02
Fantasy Game Manager
A class design for a command-line fantasy game manager. Characters are composed of stats, optional mounts, skills and known spells; character specialisations extend a shared base class; spells aggregate effects and compose their mana costs.
The model works through composition against aggregation - which parts share their owner's lifecycle and which can exist independently - alongside static members, derived attributes and class-level operations.
Open in Lucidchart - opens in a new tabDesign document 03
Flight Reservation System
A reservation domain covering planes, airports, flights, reservations, tickets and passengers, with personal data factored into person and address classes. An employee hierarchy separates pilots, flight attendants and ground staff, and employment forms are modelled alongside baggage handling.
The interesting problems are relational: a flight connects a plane, two airports, a crew and its passengers, and a reservation must hold seat, status and ticket pricing together without duplicating any of them.
Open in Lucidchart - opens in a new tabDesign document 04
Orders with Overlapping Roles
A design study built around one idea: a user who can be a client and a worker at the same time. Overlapping generalisation and interface inheritance keep both roles first-class, account statuses model the user lifecycle, and an order pipeline runs from abstract products down to shipments with transport modes and shipping zones.
It doubles as a catalogue of inheritance techniques - overlapping sets, interfaces, abstract classes and enumerated roles - each used where it fits rather than one mechanism forced everywhere.
Open in Lucidchart - opens in a new tabHow I model
Four diagram types, four questions
Each UML diagram type answers a different question about a system. Used together during the prototype phase, they turn an idea into something a team can review, criticise and build.
01
Use-case diagrams
Scope first: who the actors are, what the system must do for them, and what stays out.
02
Class diagrams
Structure: entities, associations, multiplicity, lifecycle ownership and the constraints the code must honour.
03
Activity diagrams
Flow: decisions, parallel paths and the order in which work actually happens.
04
Component diagrams
Boundaries: how the system splits into modules and where the interfaces between them sit.
The same practice carries into my project work: modelling systems before implementation is how Haardon's documentation and my application designs started, and it is the discipline I bring to team projects.
Design first