As discussed by Moody [236], visual representations of models can be more effective than textual representations, because they can tap into the capabilities of the powerful human visual system. In particular, he argues that diagrams are believed to convey information more effectively, concisely and precisely than textual language, and the information is more likely to be remembered. Visual notations are also particularly important when communicating with end-users and customers.
Depending on the requirements of the artefacts, visual modelling can range from strictly formal approaches – visual models can be exactly as formal and structured as textual models [236] – to informal approaches as used by individual designers. UML models are intended to be drawn by hand, as communication was thought to be more important than automation (and therefore precision). However, recent revisions of UML have focused on improving its architecture and formalism in order to support software integration and reasoning [188].
Visual representations can be particularly powerful when applied to the domain of model-driven development, as visual representations are themselves models. The combination of a domain-specific language and an accompanying visual representation can be termed as adomain-specific visual lan- guage, as defined by Grundy et al. [137]. This visual language can be defined from a metamodel specification with a certain level of automation [308]. However, when developing a visual language for the representation of a model, it is important to document the rationale and design decisions used [236,137].
There are situations where visual modelling may not be appropriate, and a textual representation would be better. Vlissides and Linton [329] argue that graphical models are best for domain-specific languages, rather than general-purpose languages. Graphical languages generally lackefficiency of expression; that is, it is generally very difficult to visually design a complex algorithm [308]. Fi- nally, without the support of a graphical modelling environment or framework, the implementation of a visual modelling language is often more difficult than the implementation of a textual modelling language.
3.4.1 Visual Metaphors
Ametaphor is a linguistic device where one or more words for a concept are used outside their con- ventional meaning, to express asimilar concept [201]. Metaphors are very popular in software de- velopment8, in particularinterface metaphorsfor user interface design, andsystem metaphorsfor the development of the software system. These metaphors reduce the mental load for developers, and im- prove the accessibility of the system [278]. Metaphors can also apply to visual modelling as avisual metaphor; that is, a metaphor used to relate a visual representation of a model instance with a foreign concept.
Barr et al. [20] expand on the work of Lakoff and Johnson [201] to propose a taxonomy of interface metaphors. This taxonomy includesorientational, ontological, and structuralmetaphors. Structural metaphors – those that deal more directly with physical objects in the real world – are particularly prominent in user interface design [20]. For example, the “desktop metaphor”, which represents files within a file system as objects on an actual desk, is an instance of a structural metaphor.
8The Rational Unified Process does not use termmetaphoras a linguistic device, but as a short story that replaces the notion of system architecture [273].
3.4 Visual Modelling 59
3.4.2 Visual Metaphors in Existing Models
Existing visual modelling languages already use visual metaphors in their design and implementation, and this thesis will discuss some of the metaphors identified in WebML and UWE. Each of the WebML models represented visually has a particular visual metaphor, although the WebML specification does not define these metaphors directly. The WebML hypertext model, for example, appears to follow the visual metaphor ofa web application is the flow of data, because the relationships between content units are expressed as a flow.
Some papers on WebML claim that each content unit in the model uses a visual metaphor; for example, Di Martino et al. describe that “theMultiMapUnit is a visual metaphor for a map viewer able to render both vector and raster data arranged in layers” [76, pg. 2]. According to the definition ofvisual metaphorin this thesis, this is not a visual metaphor, because their description only defines the visual representation of therenderedunit, andnotthe visual representation of the unit itself within a model instance.
Each model of UWE also has a particular visual metaphor, although these metaphors are also not explicitly discussed. Many UWE models are extensions of existing UML models – such as class di- agrams and activity diagrams – so these models reuse their existing metaphors. On the other hand, some UWE models use entirely new metaphors; for example, thenavigation structuremodel repre- sents the web application using the metaphor ofweb application navigation using states and menus
[192]. Since UWE reuses common visual metaphors (from UML), it is easier for new users to pick up and understand these models, and it also promotes sharing these models with users who already understand the metaphors of UML. It would therefore be beneficial for a modelling language to reuse existing visual metaphors where appropriate.
3.4.3 Visual Modelling Software
While visual models can be drawn by hand and exchanged manually, software can be used as part of the process. Visual modelling software is a strictly optional component of model-driven approaches, but it can improve the efficiency of model design and development, and the quality of communication with other end-users. These editors, sometimes calledgraphical object editors, allow a user to ma- nipulate the graphical representations of model instances directly [329]. Visual modelling software has already been discussed in depth by existing literature [329,236,286]; a range of existing visual modelling frameworks is discussed later in Section6.3.
Since these visual editors provide interactive representations of an underlying model instance, these editors map naturally to the model-driven development approach advocated in this thesis. Since different graphical editor instances often share similar functionality – such as printing, layout and shape types – metamodels may be used to simplify the implementation of a model-driven graphical editor. Thesemodel-driven graphical modelling environments are represented as a model instance, and translated using model transformations into the source code of the final graphical editor.
3.4.4 Visual Notation
For instances of a modelling language to be represented visually, a corresponding visual notation needs to be designed, either formally or informally. The development of visual representations for modelling languages is a very large research area, and is not the main focus of this research; a full discussion on existing research into visual notations is therefore well outside the scope of this thesis. However,
Variable Power Capacity Horizontal position (x) Interval 10–15 Vertical position (y) Interval 10–15
Size Interval 20
Brightness Ordinal 6–7
Colour Nominal 7–10
Texture Nominal 2–5
Shape Nominal Unlimited
Orientation Nominal 4
Table 3.3: Information encoding capacity of different visual variables, adapted from Moody [236, pg. 770]
this section will briefly discuss some related literature on the design of effective visual notations for modelling languages.
Notation Information Capacity
To evaluate the effectiveness of a visual notation, Moody [236] proposes measuringcognitive effec- tiveness through the systematic evaluation of a number of notation variables. By measuring these variables in a quantitative way, the effectiveness of two similar visual notations can be effectively compared, and this section will discuss two of these approaches.
The first approach –ontological analysis– measures the effectiveness of mapping the visual no- tation to the underlying model instance. In particular, four detrimental anomalies are identified, with respect to a desirable one-to-one mapping between constructs and notation [236, pg. 759]:
1. Construct deficit, a model concept does not have a corresponding visual notation; 2. Construct redundancy, multiple visual notations can represent a single model concept; 3. Construct overload, a visual notation can represent multiple model concepts; and 4. Construct excess, a visual notation does not represent any model concepts.
The second approach focuses on measuring the information capacity of a visual element with respect to a number of different visual variables, each of which have a particular information capacity. For example, Moody argues that we can distinguish between an unlimited number of element shapes, but we can only distinguish between a few element textures. The capacity of various visual variables as discussed by Moody are illustrated in Table3.3; in particular,powerrepresents the highest level of measurement that can be encoded, andcapacityrepresents the number of perceptible steps.
Cognitive Dimensions Framework
Thecognitive dimensionsframework proposed by Green and Petre [133] defines thirteen dimensions for the subjective evaluation of user interfaces. This framework may be used to evaluate the usability of visual modelling languages, as illustrated by the evaluation of the View Mapping Language (VML) by Grundy et al. [138]. A summary of these thirteen dimensions is provided in AppendixH.