EOModeller EOModeller
Sign in Get started
Notations

UML, the way an architect actually uses it.

EOModeller ships UML 2.5.1 as one of two first-class notations (the other is ArchiMate 3.1). This page is a working architect's view of what the support looks like: per-diagram coverage, the bits that turn out to be load-bearing in real work, and where EOModeller is genuinely strong versus where it competently matches the spec.

For an exhaustive feature-by-feature audit see the notation conformance page. The numbers below come from the same audit, restated as "what does this mean for the way you'll actually use it?"

The seven first-class diagram types

Coverage is "full" across the seven UML diagram types that gate v1.0. "Full" here means each metaclass the spec defines is implementable as a real element with its own renderer — not as a generic shape with a stereotype pasted on.

Class

The bread-and-butter diagram. EOModeller does the easy things — boxes with attribute and operation compartments, visibility markers, generalisation arrows — and the harder ones too: nested classifiers, generalisation sets, ball-and-socket interfaces, association classes, qualified associations, and n-ary associations. These are the elements most tools quietly drop. We don't.

Multiplicity bounds use the UML LiteralInteger / LiteralUnlimitedNatural pair, which means 0..*, 1..2, and 3 all round-trip through XMI without lossy reinterpretation.

Component

Components with ports, provided and required interfaces (rendered ball-and-socket or in component-detail form, the architect's choice), and assembly connectors. Stereotype profiles let the architect retrofit C4-style semantics on top of UML Components — see the "What about C4" section below.

Package

Nested packages, package import, package merge, profile applications. Packages are also the natural unit for XMI export (see the guide) — a nested package tree becomes nested packagedElement xmi:type="uml:Package" entries.

Use Case

Actors, subjects, «include» and «extend» relationships. Use-case diagrams in EOModeller play nicely with ArchiMate Business Actors when the architect needs to bridge the two notations on the same page.

Activity

Where the depth shows. EOModeller implements swimlanes; the full set of structured activity nodes (sequence, conditional, loop, expansion, interruptible region) with their semantics rendered correctly; pins on action boundaries; and clauses on conditional nodes. Activity is what most architects reach for when BPMN would be overkill but a text process description would be too vague.

State Machine

Composite states with nested regions; all UML pseudostates (initial, final, choice, junction, fork, join, deep-history, shallow-history, entry-point, exit-point, terminate); internal transitions; entry, exit, and do-activities. The state diagram surface in EOModeller is genuinely complete in a way that's rare even in commercial tools.

Sequence

The deepest UML coverage in the tool. Lifelines, combined fragments (alt, opt, par, loop, break, neg, critical, strict, weak, assert, consider, ignore), state invariants, continuations, coregions, gates, duration / time constraints, and local attributes on the interaction frame. The combined-fragment model in particular is implemented to spec — most tools simplify this surface in ways that produce diagrams the spec rejects.

The partial set

Four UML diagram types are "partial" at v1.0 — they work, with documented caveats:

  • Object — works via Class diagrams with an «instance» stereotype. A dedicated name : Classifier slot syntax is post-launch.
  • Composite Structure — Component + Port + Connector cover most cases. Collaborations and Roles are user-composed via stereotypes, not first-class.
  • Deployment — Nodes and Artifacts render. The «device» / «execution environment» stereotype gallery is user-authored; the 3D-box visual modulation isn't applied (flat rectangles instead).
  • Profile — Not a diagram type in EOModeller. Profile authoring lives in the Stereotype editor on the Property Panel.

Deferred to post-launch

Three diagram types are explicitly post-launch:

  • Communication — Sequence diagrams cover most use cases at launch; auto-sequence-numbering is the missing piece.
  • Timing — No timeline renderer.
  • Interaction Overview — Activity-flow embedding of Interaction frames isn't implemented.

What about C4?

C4 is not a notation EOModeller ships as a dedicated first-class type at launch. The C4 model — Context, Container, Component, Code — is implementable as UML Component diagrams with stereotypes:

  • Context diagrams use UML Components with «system» and «person» stereotypes for the software system and its users.
  • Container diagrams use UML Components with «container» stereotypes for the major deployable units.
  • Component diagrams use UML Components — same as you'd draw them in C4 — with «component» stereotypes for the internal building blocks.

This works in practice. The stereotype names match the C4 vocabulary; the visual renders match what C4 looks like in Structurizr; the XMI export carries the stereotype names so downstream tools can recognise C4 elements.

Architects who want strict C4 conventions with a tool that enforces them are well served by Structurizr. Architects who want a richer modelling environment that can produce C4-shaped diagrams alongside ArchiMate and other UML diagram types are well served by EOModeller. A dedicated C4 profile pack with the canonical stereotypes pre-seeded is planned post-launch.

What about XMI?

EOModeller exports UML 2.5.1 XMI 2.5.1 — the OMG standard interchange format — from a stable API endpoint. Round-tripping into reference UML tools like Sparx EA works for the seven first-class diagram types. The XMI export is designed specifically for code generation workflows: a curl pipeline + your transform. EOModeller doesn't ship a language mapping — your script, LLM, or templating engine produces the artefact your toolchain needs.

Things EOModeller does that most tools don't

Formality and detail as first-class diagram properties
A class diagram in EOModeller has a formality / detail position. The renderer modulates accordingly — sketchy borders at low formality, clean precise borders at high formality — and validation rules gate on the same position. The same diagram can start as a sketch and grow into a reference artefact without being redrawn.
Stereotype profiles as a first-class authoring surface
Profile authoring is a panel, not a hidden modal. The architect can extend the metaclass tree, add tagged-value schemas, and apply profiles per package. The same machinery handles built-in profiles (AWS, Azure) and user-authored ones.
Real-time co-editing
Multiple architects on the same diagram, no save-and-merge workflow. The op-log substrate handles convergence; the presence indicator shows who's looking at what. For two-to-ten teams, this is the kind of collaboration that turns review meetings into doing-the-work meetings.
Built on a principled metamodel
Under the surface, the UML and ArchiMate notations share a three-layer element model that distinguishes identity, representation, and instance. The same element can appear on multiple diagrams without being duplicated; cross-notation references work because the substrate is shared.

Where EOModeller is honest about being adequate, not exceptional

The Deployment diagram. UML's Deployment notation has rich semantics (devices, execution environments, communication paths) and a strong visual vocabulary (3D-box nodes). EOModeller renders Nodes and Artifacts correctly but leaves the visual richness as a v1.1 polish item. Architects whose primary work is deployment modelling may find this thin compared to dedicated infrastructure tools — and probably want to model that work in ArchiMate's Technology layer or via the cloud profile packs instead.

Object diagrams. The instance-of-classifier semantics work today via stereotypes but the syntax isn't first-class. Architects producing many object-snapshot diagrams may find the workflow more friction than a tool with native object-diagram support.

References