Modal Object Diagrams

While object diagrams (ODs) are widely used as a means to document object-oriented systems, they are expressively weak, as they are limited to describe specific possible snapshots of the system at hand. In this paper we introduce modal object diagrams (MODs), which extend the classical OD language with positive/negative and example/invariant modalities. The extended language allows the designer to specify not only positive example models but also negative examples, ones that the system should not allow, positive invariants, ones that all system’s snapshots should include, and negative invariants, ones that no system snapshot is allowed to include. Moreover, as a primary application of the extended language we provide a formal verification technique that decides whether a given class diagram satisfies (i.e., models) a multi-modal object diagrams specification. In case of a negative answer, the technique outputs relevant counterexample object models, as applicable. The verification is based on a reduction to Alloy. The ideas are implemented in a prototype Eclipse plug-in. Examples show the usefulness of the extended language in specifying structural requirements of object-oriented systems in an intuitive yet expressive way.

💡 Research Summary

The paper addresses a well‑known limitation of traditional Object Diagrams (ODs) in model‑driven development: they can only depict concrete snapshots of a system and cannot express negative scenarios or global structural constraints. To overcome this, the authors introduce Modal Object Diagrams (MODs), an extension of the classical OD notation that adds two orthogonal dimensions of modality: (1) polarity – positive (what may exist) versus negative (what must not exist), and (2) scope – example (a single concrete model) versus invariant (a property that must hold for all possible snapshots). Consequently, a MOD can contain positive examples, negative examples, positive invariants, and negative invariants, allowing designers to state requirements such as “objects of type A and B must never coexist”, “every snapshot must contain a link between C and D”, or “no snapshot may contain a cycle of length three”.

Formally, each modality is interpreted as a set of constraints. Positive examples assert the existence of at least one model satisfying the depicted structure; negative examples assert that no model satisfying that structure may exist. Positive invariants are universal constraints that every admissible model must satisfy, while negative invariants are universal prohibitions. By treating all four kinds of constraints uniformly as first‑order formulas, the satisfaction problem—whether a given class diagram (CD) models a MOD specification—can be reduced to a standard constraint‑solving task.

The core technical contribution is a verification pipeline that translates a MOD together with its target CD into an Alloy specification. Alloy’s SAT‑based analyzer then decides the satisfiability of the combined model. If the Alloy solver finds a solution, the MOD is satisfied by the CD; if not, the solver produces a counterexample model that explicitly violates one or more of the MOD’s constraints. This counterexample is presented back to the user, enabling rapid diagnosis of the design flaw.

To demonstrate practicality, the authors implemented an Eclipse plug‑in. The plug‑in provides a graphical editor for constructing MODs, a “Verify” command that performs the Alloy translation automatically, and a result view that visualizes success/failure and, in the failure case, the counterexample object diagram. Two case studies illustrate the expressive power of MODs. In the first, a requirement that “instances of classes X and Y must never appear together” cannot be captured by ordinary ODs; a MOD expresses this as a negative example, and the tool detects a violation in the CD. In the second, a global invariant that “every object must have a unique identifier” is modeled as a positive invariant; the verification confirms that the CD’s identifier attribute and its uniqueness constraint satisfy the invariant.

The paper’s contributions can be summarised as follows:

1. Language extension – introduction of positive/negative and example/invariant modalities, enabling concise expression of both permissive and prohibitive structural requirements.
2. Formal semantics and verification – a reduction of MOD satisfaction to Alloy, providing a sound and complete decision procedure that also yields concrete counterexamples.
3. Tool support – an Eclipse plug‑in that integrates MOD editing and automated verification into a familiar development environment.
4. Empirical validation – case studies that show how MODs capture requirements that are awkward or impossible to state with standard ODs, and how the verification uncovers design errors early in the development cycle.

Overall, Modal Object Diagrams enrich the UML modeling toolbox with a lightweight yet formally grounded notation for specifying and checking structural constraints. By coupling this notation with an automated Alloy‑based analysis, the approach bridges the gap between informal diagrammatic modeling and rigorous model checking, offering practitioners a practical means to improve design quality without abandoning familiar visual notations.