Real-Time Uml Diagram Code Examples

Real-time systems are everywhere from automotive braking controllers to industrial automation and medical devices. When you're designing software that interacts with hardware, timing constraints, and concurrent processes, you need a way to map out the architecture before writing thousands of lines of embedded code. That's exactly where real-time UML diagram code examples become useful. They give you a textual, version-controllable way to model state machines, sequence flows, and component interactions specific to real-time applications.

What does "real-time UML" actually mean?

Real-time UML refers to using UML (Unified Modeling Language) to model systems where timing behavior matters. These aren't typical web apps or CRUD services. Real-time systems must respond to events within strict deadlines sometimes milliseconds. UML provides several diagram types that help engineers express these constraints: state machine diagrams for reactive behavior, sequence diagrams for timed message exchanges, and deployment diagrams for mapping software to hardware nodes.

When you write these diagrams as code (using textual notation), you can store them in Git, generate them in CI pipelines, and keep them synchronized with your source code. Tools like PlantUML, Mermaid, and others support this workflow directly.

Why would someone model real-time systems with UML code instead of a GUI tool?

There are a few practical reasons engineers prefer text-based UML for real-time projects:

Version control: Diagram code lives in the same repository as your C/C++ or Ada source files. Changes get reviewed in pull requests just like any other code.
Speed: Writing a state machine in PlantUML syntax is often faster than dragging and dropping boxes in a visual editor, especially once you know the syntax.
Automation: You can generate diagrams as part of your build process. If your architecture changes, the diagrams update automatically.
Diffability: Text-based diagrams produce readable diffs, so you can see exactly what changed between revisions.

If you're working on a team where multiple engineers contribute to system design, the text-based approach to UML documentation removes a lot of friction from collaboration.

What does a real-time state machine diagram look like in code?

State machine diagrams are one of the most common UML diagram types used in real-time systems. They describe how a system reacts to events by transitioning between states. Here's a PlantUML example modeling a simple traffic light controller with timing:

@startuml [] --> Red Red --> Green : timer_expired / start_timer(60s) Green --> Yellow : timer_expired / start_timer(10s) Yellow --> Red : timer_expired / start_timer(90s) state Red { --> Active Active : entry / set_red_light() Active : do / monitor_pedestrian_button() } state Green { --> Active Active : entry / set_green_light() } state Yellow { --> Active Active : entry / set_yellow_light() } @enduml

This example shows entry actions, do-activities, and timed transitions all concepts critical to real-time modeling. The timer_expired event represents a real-time constraint that the embedded system must handle.

Can you show a real-time sequence diagram with timing constraints?

Sequence diagrams in real-time systems often need to show not just what messages are exchanged, but when they must arrive. Here's a Mermaid diagram for a sensor polling scenario:

sequenceDiagram participant Controller participant Sensor participant Actuator Controller->>Sensor: read_temperature() activate Sensor Note right of Sensor: Must respond within 5ms Sensor-->>Controller: temp_value deactivate Sensor Controller->>Actuator: adjust_cooling(temp_value) activate Actuator Note left of Actuator: Execution deadline: 10ms Actuator-->>Controller: ack deactivate Actuator

The timing notes aren't just documentation in real projects, they map to actual system requirements that get verified through testing. For more context on how different diagram languages handle these scenarios, check out our comparison of advanced UML diagram languages.

How do you model concurrent processes in real-time UML?

Real-time systems frequently run multiple tasks simultaneously. UML activity diagrams and composite structure diagrams can express this parallelism in code. Here's a PlantUML activity diagram showing parallel sensor reads:

@startuml start :Initialize system; fork :Read temperature sensor; :Log temp_data; fork again :Read pressure sensor; :Log pressure_data; fork again :Read humidity sensor; :Log humidity_data; end fork :Process combined sensor_data; :Send to main controller; stop @enduml

The fork/end fork construct represents true concurrency. In real-time code, each fork branch would typically map to a separate RTOS task or thread with its own priority and stack allocation.

What common mistakes do people make with real-time UML diagrams?

Here are errors that show up frequently in real-time UML work:

Ignoring timing constraints in the model: If your sequence diagram doesn't show deadlines, it's missing the most important aspect of real-time design.
Over-complicating state machines: A state machine with 30+ states becomes unreadable. Break it into hierarchical substates or separate diagrams per subsystem.
Using the wrong diagram type: Class diagrams don't express temporal behavior well. For real-time systems, state machines and sequence diagrams are usually the right starting point.
Not updating diagrams as code changes: A stale diagram is worse than no diagram. If you choose a text-based approach, wire diagram generation into your CI pipeline.
Skipping deployment diagrams: In embedded systems, which software component runs on which processor matters. Deployment diagrams capture this mapping.

Which UML tool syntax works best for real-time diagrams?

PlantUML is the most mature option for real-time UML diagrams because it supports the widest range of diagram types including state machines with nested states, timing diagrams, and activity diagrams with fork/join. Mermaid works well for simpler sequence and flow diagrams but has more limited state machine support.

If you're deciding between these tools for your project, we cover the tradeoffs in detail in our real-time UML diagram code examples reference page.

How do real-time UML diagrams fit into an embedded development workflow?

A typical workflow looks like this:

Requirements capture: Identify timing constraints, response deadlines, and hardware interfaces from the system requirements document.
Architectural modeling: Create component and deployment diagrams showing how subsystems connect and which hardware they run on.
Behavioral modeling: Build state machines and sequence diagrams for each critical subsystem. Write these as code files.
Code generation or manual implementation: Some tools can generate skeleton C code from UML state machines. Others serve purely as documentation.
Verification: Use the diagrams during code review to confirm the implementation matches the design. Timing constraints in diagrams map to test cases.
Maintenance: When requirements change, update the diagram code alongside the implementation. Automated builds regenerate the visual output.

Quick checklist for writing real-time UML diagrams as code

✅ Choose PlantUML if you need state machines, timing diagrams, and deployment diagrams
✅ Always include timing annotations (deadlines, periods, timeouts) in sequence and state diagrams
✅ Use hierarchical states to keep complex state machines readable
✅ Store diagram source files in the same repository as your embedded source code
✅ Set up automated diagram rendering in your build or CI system
✅ Map each UML state machine to a corresponding implementation pattern (e.g., state table, switch-case, or event-driven framework)
✅ Review diagrams in pull requests alongside code changes
✅ Keep one diagram per subsystem don't try to model the entire system in a single diagram

Next step: Pick one subsystem from your current real-time project, write its state machine in PlantUML syntax, and commit it alongside the implementation code. You'll immediately see how having the design as a living, versioned artifact improves clarity during reviews and onboarding.