Towards the principled design of software engineering diagrams.
Diagrammatic specification, modelling and programming languages are increasingly prevalent in software engineering and, it is often claimed, provide natural representations which permit of intuitive reasoning. A desirable goal of software engineering is the rigorous justification of such reasoning, yet many formal accounts of diagrammatic languages confuse or destroy any natural reading of the diagrams. Hence they cannot be said to be intuitive. The answer, we feel, is to examine seriously the meaning and accuracy of the terms natural and intuitive in this context. This paper highlights, and illustrates by means of examples taken from industrial practice, an ongoing research theme of the authors. We take a deeper and more cognitively informed consideration of diagrams which leads us to a more natural formal underpinning that permits (i) the formal justification of informal intuitive arguments, without placing the onus of formality upon the engineer constructing the argument; and (ii) a principled approach to the identification of intuitive (and counter-intuitive) features of diagrammatic languages.
INTRODUCTION
Diagrammatic representations - and attempts to formalise
them - are an area of increasing attention
in modern software engineering. Visual specification
and modelling languages, most notably UML [21], and
domain-specific programming languages [15, 24] typically
have a strong diagrammatic flavour; software
architecture description languages (ADLs) and diagrams
[1, 2, 25] further add claims being of "natural"
and "intuitive" ways of thinking about (software) sys-
tems. Many such grand claims are made that diagrams
are "how we naturally think about systems". Yet, even
if we accept this as being at least partly true (and it is
clearly a debatable issue) it begs the questions of: what
kinds of diagrams are intuitive; why are they the natural
way to think about systems; and - most importantly for
the purposes of this paper - do the formal accounts typically
provided for such diagrammatic languages succeed
in accurately capturing whatever it is that is natural
and intuitive about such representations?
Taking seriously the assertion that diagrams are useful
because they are intuitive (well matched to meaning)
and natural (directly capture this well matched mean-
ing), then for any formal underpinning of diagrams in
software engineering to be truly useful it must therefore
reflect these intuitive and natural aspects of diagrams.
In this paper we demonstrate that such an approach is
feasible as well as desirable.
We commence in the next section with a review of the
critical issues in a theory of diagrammatic representa-
tion. In Section 3 we present a typical diagrammatic
software language, taken from industrial embedded control
software, to motivate and illustrate a more detailed
exploration of our concepts of natural and intuitive.
Section 4 then presents an simple formalisation of this
language. The use of formal methods is often advised
or required in the provision of evidence of desirable system
properties, yet in practice the application of such
methods is undeniably di#cult. In Section 5 we illustrate
how our approach provides a formal underpinning
of natural (previously informal) reasoning, in which the
onus of formality lies not with the engineer constructing
the argument, but with the designer of the original no-
tation. Section 6 illustrates that our general approach
also naturally permits the identification of questionable
or counter-intuitive features in diagrams. We conclude
with a summary of the major issues raised and an indication
of directions for future research.
Studies such as [5, 30, 33] have indicated that the
most e#ective representations are those which are well
matched to what they represent, in the context of particular
reasoning tasks. For the purposes of this paper
we assert that an "intuitive" representation is one which
is well matched. Furthermore, we assert that whether
a representation is "natural" concerns how it achieves
its intuitive matching; and (certain classes of) diagrammatic
representations are particularly good at naturally
matching their intuitive interpretations. Clearly, these
two assertions beg the questions of how such natural
matching are achieved and what are the intuitive meanings
which an e#ective representation matches.
Natural Representation in Diagrams
Previous studies have typically examined two di#er-
ing dimensions through which diagrammatic representations
"naturally" embody semantic information. Firstly
logical analyses such as [3, 12, 26, 27, 28] have examined
the inherent constraints of diagrams (topological, geo-
metric, spatial and so forth) to explicate their computational
benefits. The second dimension which has been
studied (particularly from an HCI perspective) concerns
features and properties which impact upon the cognition
of the user [4, 7, 16, 19, 29].
Recently a careful examination [9] of analogies (and dis-
analogies) between typical text-based languages and diagrammatic
languages has sought to unify the above
two dimensions of "naturalness". The examination was
quite revealing about both similarities and di#erences
in the textual and diagrammatic cases. One primary
di#erence with diagrams is that they may capture semantic
information in a very direct way. That is to
say, intrinsic features in the diagram, such as spatial
layout, directly capture aspects of the meaning of the
diagram. An understanding of how diagrams naturally
capture such aspects permits us next to consider what
specific information should be captured for a diagram
to be truly intuitive.
Intuitive Meaning in Diagrams
The decomposition in [9] of issues in how diagrams capture
information permitted the identification, in a subsequent
study [11], of the fundamental issues relating
to the e#ectiveness of visual and diagrammatic representations
for communication and reasoning tasks. As
indicated above, an e#ective representation is one which
is well matched to what it represents. That is, an in-
tuitive, or well matched, representation is one which
clearly captures the key features of the represented artifact
and furthermore simplifies various desired reasoning
tasks.
It has been demonstrated in [7, 20, 22] that pragmatic
features of diagrammatic representations (termed "sec-
ondary notations" by Green [6]) significantly influence
their interpretation. A particular concern of the exploration
of [11] was the importance of accounting for such
pragmatic aspects of diagrams in considering when they
are well matched.
Wait
Move
Start
Brake
Halt
true
Alarm
Checks
ChkFault
Fault
level=FloorCall
Stopped
Ready
Fault

Figure

1: Example SFC diagram (lift controller).
ING
A concrete application of our work is to the formalisation
of diagrammatic (graph-based) languages for industrial
embedded control software. This commonly occurring
class of systems spans many di#erent domains
(e.g. automotive, process control, ASIC design, mobile
telephony) and is a very common component of critical
systems. We have formalised various sub-languages
of Programmable Logic Controllers (PLC's [14, 17]) and
concentrate here on the PLC sub-language of Sequential
Function Charts (SFCs), which present a control-flow
view of an embedded controller.
The diagrammatic representation of SFCs is illustrated
in

Figure

1 and consists of elements of two distinct
kinds: rectangular boxes called steps and thick horizontal
lines called transitions. In such diagrams, no elements
of the same kind may be linked directly. Each
step is labelled by an identifier and may have an associated
action, and each transition carries a boolean
condition. The SFC of Figure 1 is a simplified lift controller
, adapted from a teaching example of "good"
SFC design from [17].
SFCs exhibit a rich control-flow behaviour. At any given
time, each step can be either active or inactive and the
set of all active steps defines the current state of the
system. A step remains active until one of its successor
1 "elevator" controller, for American readers
transition conditions evaluates to "true", thereby passing
control to the step(s) targeted by the links emanating
from that transition. The double horizontal lines
introduce and conclude sections of the diagram which
execute concurrently with each other.
Diagrams: Direct Representations
The term "visual representation" has, at times, been
taken to be synonymous with "diagram". However, consider
a textual representation, for example a propositional
logic sentence such as "p and (not q or r)". This,
if we are to be precise, is also an example of a visual
representation. After all, the symbols in this sentence
are expressed to the reader's visual sense (as ink marks
on a page), not to their senses of touch or hearing, as
would be the case with braille or speech for example.
There is, however, a significant di#erence between certain
of the visual symbols of Figure 1 and those of this
propositional sentence. The di#erence is that certain of
the symbols in Figure 1 exhibit intrinsic properties, and
these properties directly correspond to properties in the
represented domain.
Consider that the reader of an SFC diagram can instantly
distinguish step and transition elements. They
are represented by quite distinct visual tokens (rectan-
gles and lines respectively) which clearly belong to different
categories, in a manner obviously not matched by
the textual tokens of the above propositional logic sen-
tence. Furthermore, the SFC of Figure 1 follows a convention
common to many such graph-based notations
by laying out sequences of steps in a top-down fashion
(leaving aside the issue of loops for the moment). Thus
a reader can also instantly see that the step "Brake" will
be preceded by "Wait" and "Move" steps, as these steps
appear above it in the diagram. These aspects of SFC
diagrams are both examples of the direct representation
of semantic information.
Thus, in general certain diagrammatic notations and relations
may be directly semantically interpreted. This
directness may be exploited by the semantics of diagrams
in a systematic way. Such "systematicity" is
not exclusively the preserve of diagrammatic representa-
tions, but - with their potential for direct interpretation
diagrams have a head start over sentential representations
in the systematicity stakes. However, to understand
what makes diagrams e#ective, we must consider
their interpretation by humans more generally. Studies
have shown that what we describe next as pragmatic aspects
of diagrams, play a significant role in typical uses
of successful diagrammatic languages.
Pragmatics in Diagrams
In linguistic theories of human communication, developed
initially for written text or spoken dialogues, theories
of "pragmatics" seek to explain how conventions
and patterns of language use carry information over and
above the literal truth value of sentences. For example,
in the discourse:
1. (a) The lone ranger jumped on his horse and rode
into the sunset.
(b) The lone ranger rode into the sunset and
jumped on his horse.
(1a)'s implicature is that the jump happened first, followed
by the riding. By contrast, (1b)'s implicature
is that riding preceded jumping. In both (1a) and
(1b), implicatures go beyond the literal truth conditional
meaning. For instance, all that matters for the
truth of a complex sentence of the form P and Q is
that both P and Q be true; the order of mention of
the components is irrelevant. Pragmatics, thus, helps
to bridge the gap between truth conditions and "real"
meaning. This concept applies equally well to the use
of diagrammatic languages in practice. Indeed, there is
a recent history of work which draws parallels between
pragmatic phenomena which occur in natural language,
and for which there are established theories, and phenomena
occurring in diagrammatic languages [9, 18, 20].
Studies of digital electronics engineers using CAD systems
for designing the layout of computer circuits
demonstrated that the most significant di#erence between
novices and experts is in the use of layout to
capture domain information [23]. In such circuit diagrams
the layout of components is not specified as being
semantically significant. Nevertheless, experienced
designers exploit layout to carry important information
by grouping together components which are functionally
related. By contrast, certain diagrams produced by
novices were considered poor because they either failed
to use layout or, in particularly "awful" examples, were
especially confusing through their mis-use of the common
layout conventions adopted by the experienced en-
gineers. The correct use of such conventions is thus seen
as a significant characteristic distinguishing expert from
novice users. These conventions, termed "secondary no-
tations" in [23], are shown in [20] to correspond directly
with the graphical pragmatics of [18].
A straightforward example of the use of such pragmatic
features may be readily observed in the SFC diagram
of

Figure

1. While this diagram is a simplified version
of the SFC from [17], nevertheless we have retained the
layout of that original SFC, and note that it carries important
information concerning the application being
represented. The main body of the SFC of Figure 1
is conceptually partitioned into the three regions illustrated
in the following outline:
F
A
Region N is concerned with normal operation, A is an
alarm-raising component and F performs fault detection
(e.g. action "Checks" monitors the state of the lift
and raises the boolean signal "Fault" whenever a fault
occurs).
More recent studies of the users of various other diagrammatic
languages, notably visual programming lan-
guages, have highlighted similar usage of graphical pragmatics
[22]. A major conclusion of this collection of
studies is that the correct use of pragmatic features,
such as layout in graph-based notations, is a significant
contributory factor in the comprehensibility, and hence
usability, of these representations.
Diagrammatic Reasoning: SFC Example
One of the major tasks that SFC notations intend to
support is the inference (by system designers) of which
sequences of states may the system exhibit. Desirable
such sequences are formulated in terms of system prop-
erties, prominent among which are safety properties.
For instance, appropriate for our lift controller is property
Safe expressed as: "Assuming no faults, the lift
always stops before the next call is attended."
Example 1 The diagram of Figure 1 exhibits property
Safe because: (1) Once the main loop is entered, the
assumption of fault-freeness implies that control is retained
within the loop; and (2) the loop forms a single
path from step "Move" to itself that includes condition
"Stopped".
Crucial to part (2) of this argument is the observation
that paths in the diagram correspond semantically to
temporal orderings of events: if only a single path exists
from any current step A to step B and condition t
appears along the path, the next activation of B must
be preceded by an occurrence of t.
A desirable software engineering goal is to support the
formalisation of informal arguments, such as the above.
We argue that for a formalisation to be e#ective, as with
an e#ective diagrammatic representation, it should accurately
structure those aspects of the represented artifact
which are pertinent to the required reasoning tasks.
For example, essential to the informal argument in the
preceding example is the ability to focus precisely on
the part of the diagram which is responsible for property
Safe. That is, focusing on the loop and excluding
the alarm-raising and fault-checking parts of the dia-
gram. A formalisation which does not readily permit
a similar structuring, will clearly be less e#ective than
one which does.
Consider that there are numerous, less direct ways of
capturing the semantics of SFCs; a common one being to
enumerate all possible states of the SFC in a transition
system [31].
Example 2 A transition system modelling the behaviour
of the lift controller has as states all reachable
sets of steps. Its transitions are possible combinations
(i.e. sets) of conditions. A small part of this transition
system is given below (with step names truncated
to their initials):
{S} Ready
Floor.
Fault
zz#
{Floor. ,Fault}
. {W,CF} {M,C}
level.
Fault
""
{level. ,Fault} #
{M,CF} .
{B, CF}
Stopped
OO
{B, C}
Fault
This resulting transition system is typical of a formalisation
which obscures the structure necessary to the
informal argument of Example 1. This is because paths
in the transition system result from the interweaving
of events belonging to several concurrent components
in the SFC. In contrast to the informal argument of
Example 1, when arguing properties such as Safe on
the model of Example 2 it is generally hard to exclude
behaviour originating in parts of the system which are
otherwise unrelated to the property in question. While
it could be argued that this is hardly a problem for small
SFCs, the size of a transition system grows rapidly with
the number of concurrent components in the SFC.
Supporting Intuitive Reasoning
A significant determiner of what makes a particular representation
e#ective is that it should simplify various
reasoning tasks. Any formalisation of the semantics of
such a representation must therefore ensure that such
reasoning tasks are equally easy in it. One benefit that
certain diagrammatic representations o#er to support
this is the potential to directly capture pertinent aspects
of the represented artifact (whether this be a concrete
artifact or some abstract concept). As we have seen,
this "directness" is typically an intrinsic feature of di-
agrams; determining which aspects of the represented
artifact are "pertinent" requires that we consider pragmatic
as well as syntactic aspects of representations.
For example, the operation of the lift controller in our
example is conceptually partitioned into three modes:
of normal, alarm-raising and fault checking behaviour.
The layout of the SFC diagram of Figure 1 is such that,
for any given step or transition, membership of one these
modes is represented as membership of an identifiable
region of the graph (one of the regions N , A or F above).
Thus, a conceptual aspect of the artifact (membership
of some behavioural mode) is directly captured by a representing
relation in the diagram with matching logical
properties (membership of a spatial region in the plane).
Note that, in this case as with the expert designers of
CAD diagrams and visual programs studied in [23, 22],
it is the pragmatic features of the diagram (layout being
chosen so as to suggest conceptual regions) which
are exploited to carry this information. Indeed, in the
original SFC diagram from [17], of which our example
is a simplification, these regions were strikingly well de-
lineated. We outline next a formal description of SFC
diagrams which reflects both their direct and pragmatic
features, leading to a formal underpinning of intuitive
arguments such as the one for the Safe property illustrated
above.
Let S and T be the sets of all step identifiers and transition
conditions respectively. One way of describing the
structure (and layout) of SFC diagrams is to construct
an algebra of "diagram expressions", in which each expression
denotes a particular way of decomposing a diagram
[10].
To begin with, let the atomic diagrams
and
be denoted s and t respectively (where s # S and t #
T). Also, write # and # respectively for the branching
elements
and
In introducing the operations of the algebra, it is facilitative
to visualise each diagram expression D as an
"abstract" diagram:
defined whenever the number of connections emanating
from the bottom of D equals that of connections entering
juxtaposes D and D # with D
on the left. Two further operations are defined:  D,
resulting in
and [D] resulting in
In writing SFC expressions, we shall assume  to have
higher precedence than ;
and# to have the least precedence

The main body of our example may now be expressed
as
where:
(level . ; Brake;
A # Fault; Alarm
and 1 denotes a vertical line. Examining the original
SFC, one can now see how the expressions N , A and F
correspond to the regions identified at the end of Section
3. Finally, the expression for the entire controller
is:
Algebraic methods of diagram description, such as the
one just outlined, may be called analytic (a term originally
due to McCarthy) as they emphasise a decompositional
view of diagrams. When carefully designed,
such descriptions are generally simpler (more abstract)
than synthetic ones, e.g. those based on graph gram-
mars, and naturally lend themselves to the analysis of
diagrams from a semantic or logical standpoint.
Almost every non-trivial diagram may be decomposed
in a variety of ways, thus allowing multiple semantic
interpretations and also multiple routes for constructing
reasoning arguments based on the diagram. Some
semantic and logical analysis of software diagrams is
therefore required, not only to ensure consistency of
interpretations, but also to validate many commonly
occurring reasoning arguments. Viewing, as we do,
formalisation as a means to the validation of informal
(or semi-formal) reasoning practices emphasises formal
analysis as a tool of the notation designer, not as an
imposition on the user.
The provision of rigorous evidence of desirable properties
in software systems is a required, but highly costly
activity in many domains; especially those in which
products are subject to regulation or certification (e.g.
safety-critical systems). While the use of formal methods
in supplying such evidence is often recommended or
mandated (e.g. SEMSPLC guidelines [13], MOD guidelines
[32]), their practical application remains undeniably
di#cult. This is largely because most formal methods
rely on intimate knowledge and explicit manipulation
of some underlying, generic model and are typically
less concerned with user-oriented representations. Thus,
given a system expressed as diagram d and a property
traditional approaches typically consist in: (1) obtaining
some behavioural model M(d) of d, such as a
function, a transition system, etc.; (2) formalising p as
a formula #(p) in some suitable logic; and (3) verifying
whether M(d) |= #(p), i.e. whether the model satisfies
the formula.
By contrast, many informal or semi-formal arguments
appeal directly to domain-specific features of a system's
representation to gain remarkable simplicity. Neverthe-
less, the elevation of such arguments to a level admissible
as rigorous evidence requires their formal underpinning
and justification by logical means.
Roughly speaking, our approach attempts to substitute
structural (i.e. algebraic) models of diagrams for behavioural
models in step (1) above. If, for instance,
D(d) is an algebraic expression denoting an (actual)
SFC diagram d, and formula #(p) expresses a property,
the reasoning problem (step (3) above) is reformulated
as D(d) |= #(p). In terms of our example property Safe
and the main body of our lift controller:
LiftBody |= #(Safe) . (1)
Continuing with our illustration, property Safe may be
expressed as a temporal formula [31]. Let, for instance,
A(Stopped
where A(#) is interpreted as "always # 1 B# 2 as "# 1
before "implies". What is important here
is not the precise definitions of A and B in our crude
formalisation. Rather, we aim to illustrate the overall
structure of the formula, #, where # expresses an
assumption about the computation (here "always not
Fault") and # expresses a commitment of the system.
The implicit inferential "short-cuts" in the informal argument
of Example 1 may now be formalised, and thus
justified, by means of inference rules. For instance, one
rule views concurrency as the conjunction of the com-
ponents' respective properties:
Rule 1: If D |= # and D # , then
[D#
Another rule eliminates part of a diagram which is inaccessible
under given assumptions:
Rule 2: If D |= A(# and t #, then
Starting with goal (1), equivalently written as
and applying Rule 1 yields sub-goals  N ; A |= #(Safe)
and F |= true, the second of which is trivial. By Rule
2, applied to the definitions of A and #(Safe), we now
discard the alarm-raising component to concentrate on
the part precisely responsible for our property:  N |=
#(Safe).
The soundness of rules such as those above must eventually
be established wrt. some behavioural model. This
obligation, however, lies not with the user, but once-
and-for-all with the developers of the diagrammatic notation

6 DISTURBING DIAGRAM FEATURES
A further benefit of our approach relates to the over-all
design of diagrammatic languages. The rigorous examination
of how the concepts of "natural" and "intu-
itive" relate to diagrams, paves the way to the principled
identification of specific features which contravene
these concepts. Thus far, we have concentrated on the
core features of SFC diagrams. In pursuit of our goal
to demonstrate formal analysis as a tool in the design
of software engineering diagrams, we shall briefly introduce
an extra feature, subject it to semantic analysis
and examine the insights resulting from this analysis.
The semantic model associated with SFCs is that of
(labelled) Petri nets, a concept widely used and well
understood in the domain, and the basic SFC notation
is highly suggestive of this association. Unfortunately,
the definition of SFCs in [14] abounds with extensions
which forcefully violate this analogy. One such exten-
sion, called action qualification, permits certain actions
to be "set active" by some step and continue to be invoked
following the step's deactivation. Such actions
will remain active either indefinitely or until they are
explicitly "reset" by a step elsewhere in the diagram.
This mechanism of action-step association is visualised
by attaching an oblong box to a step as follows:
Step
where Q is a "qualifier". Of the many qualifiers permit-
ted, here we look at "N" (usually omitted and standing
for "normal") and "S", "R" (standing for "set" and "re-
set"). An example of an SFC diagram making use of this
feature is given in Figure 2.
To describe both SFC diagrams and nets in a uniform
way we shall, following [8], think of each as a collection
of "objects" and relations among them. (Notation:
Given relation R we write (x, y, z) # R if objects x, y
and z are related via R.)
Under this view, one abstraction of the SFC diagram
in Fig. 2 has objects s 1 , . , s 5 , A, B, C,
responding to the steps, actions and transitions). The
relations in this abstraction capture links and action-
step associations. Relation L is such that (x, y) # L
A
R
A
p3
p6
A

Figure

2: SFC diagram and its corresponding net.
i# a directed link exists from x to y in the diagram
(e.g.
For each type (S, R or N) of qualifier there is a binary
relation Q such that (x, a) # Q i# x is a step associated
with a via Q. So, for example,
us call this abstraction D
as it captures all that we regard as essential about the
diagram.
The labelled-net semantics of our example diagram is
given (also diagrammatically!) in Fig. 2. Each place in
the net is labelled with zero or more actions and the
abstraction P associated with the net has objects for
the places, transitions and labels. Its relations are F ,
corresponding to the "flow" of the net (i.e. (x, y) # F
i# a single directed link exists from object x to object
place p is labelled with
action a.
We now proceed to evaluate the degree of correspondence
between the abstractions modelling the diagram
and its semantics. A mapping m from abstraction W to
abstraction W # maps the objects of W to those of W #
and also the relations in W to relations in W # . Such
a mapping is called a homomorphism if for every relation
R which holds between objects x, y, . in W , the
corresponding relation m(R) in W # holds between the
corresponding objects m(x), m(y), .
Consider now a situation where an abstraction W adequately
captures everything which is deemed relevant in
a diagram, whereas W # captures the relevant aspects of
the artifact represented by the diagram. What does the
existence of a homomorphism h from W # to W signify?
In part, it tells us that every relation in the artifact
which we regard as important has a corresponding relation
in the diagram. Moreover, it tells us that every
(first-order) logical statement about the relations in W #
translates to a statement about W which holds if the
original does in W # .
Returning to our running example, let us derive from D
a slightly higher abstraction, having the same objects
and relation L as D but only one additional relation
This abstraction, which we call U , provides
partial information about a user's interpretation of the
SFC diagram. In particular, G contains exactly those
action-step associations which are explicitly guaranteed
in the diagram, and thus hold in all semantic interpretations
which respect the meaning of qualifiers. Thus,
for example, (s 4 , G as this association depends on
the history of the computation leading to s 4 .
One now observes that there can be no homomorphism
from P to U , as every candidate should map both p 4
and p 5 to s 4 and (p 5 , G. We
are forced to conclude that an important semantic re-
lation, that of which actions are invoked in each mode
of the system, is not systematically visualised. This introduces
complications in reasoning and suggests that
the introduction of the "S" and "R" qualifiers poorly
integrates with the core notation.
Using an elementary semantic analysis, we have thus
shown how some questionably convenient features of
IEC SFCs can introduce a seriously dangerous mismatch
between a user's intuitive interpretation of the graphical
representation and its actual semantics. In the presence
of such features, knowledge of the global structure of
the SFC may be required before overall behaviour can
be inferred from the behaviours of the currently active
steps. Such knowledge may be extremely hard to establish
accurately about large diagrams.
7 CONCLUSIONS AND FUTURE WORK
This paper has presented an overview of an ongoing re-search
theme of the authors. The use of diagrams and
diagrammatic languages has become increasingly prevalent
in software engineering, with claims of their natural
"intuitiveness" being typical. We have summarised the
primary findings of a deeper and more cognitively informed
examination of these proclaimed benefits. These
findings indicate that a more considered approach than
is common is required, if the formalisation of such diagrammatic
languages is to successfully provide equally
natural and intuitive support for their practical use.
The benefits of such a more considered approach have
been illustrated through examination of the industry
standard language of SFCs (Sequential Function
Charts) for embedded controllers. Consideration of
which features of this language are natural and intuitive
guided the design of a simple formalisation which,
as we have shown, supports the validation of typical informal
arguments concerning desirable system proper-
ties. Furthermore, we have argued that such validation,
and its formal details, is best seen as the responsibility
of the designer of the language, rather than of the user
(engineer) who constructs the informal argument.
At present we are exploring and extending our approach
in the following areas:
. the development of a more concrete framework for
exploring the connection between semantics of diagrammatic
languages and their form: both the
natural encoding of semantic properties by features
of the language, and the implications that features
carry of intuitive semantic meaning;
. the broader application of our approach: to other
PLC languages, to other domain specific languages
and - more generally - to specification and modelling
languages;
. the exploration of tool support: both specifically
for the design of diagrams in specific languages
(such as SFCs) and more generally for the design
and exploration of novel diagrammatic languages.
A further benefit of our approach is that it paves the
way towards a principled exploration of specific features
of diagrammatic languages, permitting ready identification
of potentially dangerous, misleading, or otherwise
counter-intuitive features. As diagrammatic languages
become more commonplace in software engineering -
whether for design, modelling, or programming - the
need for a sound basis for the design of such languages
becomes ever more pressing. A basis which will serve
to guide the design of diagrammatic languages which
benefit from rigorous formality, without sacrificing their
intrinsic intuitiveness and appeal. The work reviewed
in this paper provides a foundation upon which such a
basis may be developed.



--R

Formalizing style to understand descriptions of software archi- tecture
A formal basis for architectural connection.
logic.

VPLs and novice program comprehen- sion: How do di#erent languages compare? In 15th IEEE Symposium on Visual Languages (VL'99)
Cognitive dimensions of notations.
Usability analysis of visual programming environments: a 'cognitive di- mensions' framework.
On the isomorphism
Theories of diagrammatic reasoning: distinguishing component problems.
Formalising pragmatic features of graph-based notations

Towards a model theory of Venn diagrams.
Institute of Electrical Engineers.
IEC 1131-3: Programmable Controllers - Part3: Programming Languages

Why a diagram is (sometimes) worth ten thousand words.
Programming Industrial Control Systems Using IEC 1131-3
Avoiding unwanted conversational implicature in text and graphics.
Visual language the- ory: Towards a human-computer interaction per- spective
Grice for graphics: pragmatic implicature in network diagrams.
OMG ad/99-06-08 (Part
Why looking isn't always seeing: Readership skills and graphical programming.
Requirements of graphical notations for professional users: electronics CAD systems as a case study.

Formulations and formalisms in software architecture.
Operational constraints in diagrammatic reasoning.
Derivative meaning in graphical representations.

A cognitive theory of graphical and linguistic reasoning: logic and im- plementation
Image and language in human reasoning: a syllogistic illustration.

UK Ministry of Defence.
Representations in distributed cognitive tasks.
--TR
Cognitive dimensions of notations
Modal and temporal logics
Why looking isn''t always seeing
Formalizing style to understand descriptions of software architecture
A formal basis for architectural connection
Operational constraints in diagrammatic reasoning
Situation-theoretic account of valid reasoning with Venn diagrams
Towards a model theory of Venn diagrams
Visual language theory
On the isomorphism, or lack of it, of representations
Diagrammatic Reasoning
Theories of Diagrammatic Reasoning
Derivative Meaning in Graphical Representations
Formalizing Pragmatic Features of Graph-Based Notations
VPLs and Novice Program Comprehension

--CTR
Helen C. Purchase , Ray Welland , Matthew McGill , Linda Colpoys, Comprehension of diagram syntax: an empirical study of entity relationship notations, International Journal of Human-Computer Studies, v.61 n.2, p.187-203, August 2004
Helen C. Purchase , Linda Colpoys , Matthew McGill , David Carrington , Carol Britton, UML class diagram syntax: an empirical study of comprehension, Proceedings of the 2001 Asia-Pacific symposium on Information visualisation, p.113-120, December 01, 2001, Sydney, Australia
software diagrams;programmable logic controllers;diagrammatic languages