Using Alloy to model-check visual design notations

This paper explores the process of validation for the abstract syntax of a graphical notation. We define an unified specification for five of the UML diagrams used by the Discovery Method and, in this document, we illustrate how diagrams can be represented in Alloy and checked against our specification in order to know if these are valid under the Discovery notation.

💡 Research Summary

The paper presents a systematic approach to formally validate the abstract syntax of visual design notations, focusing on five UML diagram types employed by the Discovery Method (class, object, state, activity, and sequence diagrams). Recognizing that UML, while widely used, lacks a rigorous formal definition for many of its diagrammatic constructs, the authors propose a unified specification that captures the essential structural and semantic constraints of these diagrams.

The core of the methodology is the translation of this unified specification into the Alloy modeling language. Each diagram element—such as classes, attributes, inheritance links, objects, states, transitions, activities, and messages—is represented as an Alloy signature, while relationships and constraints are encoded as relations and facts. For example, a class is modeled with a signature that includes a set of attributes and an optional single superclass, enforcing the single‑inheritance rule through a fact. Objects are linked to their defining classes, and state machines are expressed with explicit start and end states for each transition, ensuring that every transition is well‑formed. Activity and sequence diagrams are similarly captured using nodes and message ordering relations.

Once the meta‑model is encoded, concrete diagram instances are expressed as Alloy facts. The authors then formulate desired properties—such as “every class must have at least one attribute” or “no cyclic inheritance is allowed”—as Alloy assertions. The Alloy Analyzer, which employs a SAT‑based search, exhaustively explores the space of possible instances and reports counter‑examples whenever a property is violated. This automatic counter‑example generation enables designers to detect subtle inconsistencies that are often missed during manual review.

A notable contribution is the concept of a “unified specification.” Rather than treating each diagram type in isolation, the authors integrate all five diagram specifications into a single Alloy model. This integration permits cross‑diagram consistency checks; for instance, it can verify that associations defined in the class diagram are faithfully reflected in the object diagram, or that state transitions correspond to messages in the sequence diagram. Such cross‑validation is difficult to achieve with traditional, diagram‑specific validation tools.

The paper validates the approach through a series of case studies. The authors manually translate sample diagrams—some intentionally containing errors—into Alloy code and run the Analyzer. Errors such as cyclic inheritance, objects instantiated from undefined classes, missing initial states in state machines, and contradictory message ordering in sequence diagrams are all detected quickly, with counter‑examples pinpointing the exact offending elements. Performance measurements show that models containing 30–40 elements are checked within seconds, while larger models (over 100 elements) can take several minutes, highlighting the scalability limits inherent to SAT‑based model checking.

The authors acknowledge several limitations. First, the translation from graphical diagrams to Alloy text is currently manual, introducing a potential source of error and limiting practicality. They suggest developing automated transformation tools as future work. Second, the SAT‑solver’s exponential growth in search space means that very large or highly connected models may become infeasible to check without additional abstraction or decomposition strategies. Third, Alloy’s textual nature does not directly support visual diagram editing, so integration with existing UML modeling environments would be required for seamless adoption.

In the discussion, the paper positions its contribution within the broader landscape of model‑driven engineering. Compared to other formal methods (e.g., OCL constraints, Z notation, or theorem provers), Alloy offers a lightweight yet expressive platform that can be quickly prototyped and provides concrete counter‑examples, which are valuable for debugging. The unified specification approach also opens the door to extending the methodology to other visual notations such as SysML, BPMN, or domain‑specific modeling languages.

In conclusion, the study demonstrates that Alloy can serve as an effective engine for model‑checking visual design notations, enabling early detection of design flaws, ensuring consistency across multiple diagram types, and improving overall model quality. By formalizing the abstract syntax of UML diagrams and providing a concrete, automated verification workflow, the authors contribute a practical toolset that bridges the gap between informal visual modeling and rigorous formal analysis. Future research directions include automating the diagram‑to‑Alloy transformation, optimizing the verification process for large‑scale models, and exploring integration with mainstream modeling tools to bring formal validation into everyday software design practice.