Towards Overcoming Deficiencies in Constraint Diagrams Gem Stapleton and Aidan Delaney Visual Modelling Group University of Brighton Brighton, UK {g.e.stapleton,a.j.delaney}@brighton.ac.uk Abstract The constraint diagram language was designed to be used in conjunction with the Unified Modelling Language (UML), primarily for placing formal constraints on soft- ware models. In particular, constraint diagrams play a sim- ilar role to the textual Object Constraint Language in that they can be used for specifying system invariants and opera- tion contracts in the context of a UML model. Constraint di- agrams can also be used independently of the UML. In this paper, we illustrate a range of counter-intuitive features of constraint diagrams and highlight some (potential) expres- siveness limitations. We propose a generalized version of the constraint diagram language that overcomes the illus- trated counter-intuitive features and limitations. 1 Introduction Visual languages play an important role in the design and implementation of software. For example, the Unified Mod- elling Language (UML) is now an industry standard visual notation designed specifically for use by software engineers and is used throughout the software development process, from capturing domain requirements through to implemen- tation. Under some circumstances (such as in a safety criti- cal environment; see, for example, [14]) it is desirable, per- haps even essential, to produce formal models of software. In part, such application areas serve to motivate the need for the precise specification of the UML at both a syntactic and semantic level; the pUML group was set up with this goal in mind [13]. Part of the creation of a formal model is likely to in- volve specifying constraints such as system invariants and operation contracts which, within the UML, is achieved by using the Object Constraint Language (OCL). The OCL is the only purely textual part of the UML and, therefore, does not fit with the UML’s diagrammatic theme. In order to overcome this restriction to using a textual notation for en- forcing these types of constraint, Kent introduced constraint diagrams [8] which are designed to complement the visual components of the UML but which can also be used inde- pendently of the UML. In figure 1 there is a constraint diagram which expresses an invariant that we might wish to place on a video rental store system: every member can only borrow films that are in the collections of the stores which they have joined. The semantics of constraint diagrams will be explained more fully later, but the asterisk is a universal quantifier, the ar- rows allow us to make statements about binary relations and the closed curves represent sets (or classes). M e m b e r S t o r e F i l m j o i n e d c a n B o r r o w c o l l e c t i o n Figure 1. A constraint diagram. At first glance, constraint diagrams appear intuitive and, perhaps, unambiguous, but it was not until a formalization of their semantics was attempted that a range of ambigu- ities were noticed [5]. Indeed, only when a formalization was eventually obtained [3] did the complexity of inter- preting these diagrams become apparent. We shall demon- strate that, whilst in many examples constraint diagrams are a very intuitive notation (in terms of being, borrow- ing a phrase from [7], “well-matched to meaning”), there are many situations where their intuitiveness breaks down. Quoting from [7] Studies such as [6, 11, 15] have indicated that the most effective representations are those which are well-matched to what they represent, in the con- text of particular reasoning tasks. We argue that, in the context of placing formal con-