Six parts on design before code: UML from use cases through to behaviour, then the alternative data models. And every diagram here was executed or measured for real, including a bug that running it exposed in the order of the checks.
📘6 parts🧪diagrams executed and measured🌓light and dark🌍Arabic and English
Why this guide?
The modeling workshops teach you the diagrams' notation. This guide teaches you what they expose: which question each one answers, and which bug it catches before the code.
How to read it
Each part opens with the prerequisites, then the concepts, then the figures, then an executed exercise with real output. The first four parts build one library system, so read them in order.
Cards and questions
Each part ends with flashcards you flip by clicking, multiple-choice questions, and five “check your understanding” questions with hidden answers. Use them before you say “I get it”.
A warning
The diagrams here are not for a report. Every diagram in this guide was either turned into code and run, or measured with a number, because a diagram that is never tested becomes silently wrong.
The track map
The six parts are not independent: the first four build one library system, and the last two ask “how do we store it?”. A dashed line means “this idea carries over there”.
StartKey idea
The order of the parts and the idea each one carries forward.
UML notation is memorised in an hour and forgotten. These three stay, and they are what separates an engineer who designs from an implementer who guesses:
StartOutcome
The transferable skills from these six parts.
The one rule that ties all six togetherDo not decide without evidence. In modelling, the evidence is a rule written in words backing every line you draw; in behaviour, it is a run that exposes a wrong order; in data, it is a number measured on your own data rather than an article about another company. Every part of this guide replaces an opinion with evidence.