The document discusses the construction of visual notations in software engineering, emphasizing the importance of notation form and content on cognitive effectiveness. It outlines various worst practices in domain-specific modeling, such as choosing inappropriate notation types and neglecting user comprehension. The document also highlights the significance of visual representation and cognitive processing in modeling tasks.

1. etercnoConcrete
xatnySyntax
srettaMatters

2. Daniel Moody
The “Physics” of Notations:
Towards a Scientific Basis for Constructing
Visual Notations in Software Engineering,
IEEE Transactions on Software Engineering,
Best Practices
Vol. 35, No. 5, November-December 2009
[1] Alexander, C.W., Notes On The Synthesis Of Form.
1970, Boston, US: Harvard University Press.
Worst practices
[2] Avison, D.E. and G. Fitzgerald, Information
Systems Development: Methodologies, Techniques
and Tools (3rd edition). 2003, Oxford, United
Kingdom: Blackwell Scientific.
.......
[150] Zhang, J., The Nature of External
Representations in Problem Solving. Cognitive
Science, 1997. 21(2): p. 179-217.
[151] Zhang, J. and D.A. Norman, Representations in
Distributed Cognitive Tasks. Cognitive Science, 1994.

3. Worst Practices for Domain-Specific Modeling
Steven Kelly, Risto Pohjonen
IEEE Software, vol. 26, no. 4, pp. 22-29, July/Aug. 2009
Free from: www.metacase.com/stevek.html
• 76 DSM cases
• 15 years
• 4 continents
• several tools
• 100 DSL creators
Worst practices
• 3–300 modelers
 what doesn’t work

4. Tool: hammer  nails
Worst practices: Concept Source
Tool’s technical limitations
dictate language 14%

5. Brain Power

6. We have
visual
brains
Touch
Brain Power
Hearing
Vision
Smell
Taste
Sensory neurons

7. Text Visual
s parallel
e parallel
Brain Power
r parallel
i parallel
a parallel
l parallel

8. Text Visual
s parallel
e parallel
Brain Power
r parallel
i parallel
a parallel
l parallel

9. Perceptual
vs.
Brain Power
Cognitive

10. Perceptual Popout
Moody TSE09
Brain Power
Spot the
odd one out!

11. Perceptual Popout
Moody TSE09
Brain Power
Spot the
odd one out!

12. Perceptual Popout
Moody TSE09
Brain Power
Spot the
odd one out!

13. Perceptual Popout
Moody TSE09
Brain Power
Spot the
odd one out!

14. Perceptual Popout
Moody TSE09
Brain Power
Unique values
> Combinations

15. Does UML pop?
Moody SLE08
Line value End shape End value
Open Closed Semi-
Relationship Solid Dashed Diamond arrow Cross arrow Circle circle None Black White
Aggregation
Association (navigable)
Association (non-navigable)
Association class
Composition
Brain Power
Constraint
Dependency
Generalisation
Generalisation set
Interface (provided)
Interface (required)
N-ary association
Note reference
Package
Package merge
Package import (public)
Package import (private)
Realization
Substitution
Usage

17. Notation, Notation, Notation

18. Domain Users
care deeply
Notation, …
about notation!
“UI” for the language

19. Moody TSE09
Form ≥ Content
Brain Power
“ research in diagrammatic reasoning shows that the
form of representations has an equal, if not greater,
influence on cognitive effectiveness as their content
[68, 122, 151].
”

20. Moody TSE09
Concrete ≥ Abstract
Brain Power
syntax syntax
“
apparently minor changes in visual appearance
can have dramatic impacts on understanding and
problem solving performance [19, 68, 103, 122]...
especially by novices [53, 56, 57, 79, 93, 106, 107].
”

21. Notation Types
Text
Tree,
Projec-
Form,
tion
Notation, …
Table
Visual
Matrix Graph

22. Notation, … Text

23. Notation, … Graph

24. Notation, … Matrix
Tree Table Form

25. Notation, … Projectional

26. Notation Types
Text
Tree,
Projec-
Form,
tion
Notation, …
Table
Visual
Matrix Graph

27. Partially Convertible
Graph Objects Text
Parse
Notation, …
Matrix
Tree,
Form,
Table
Project
ion

28. Partially Embeddable
Graph,
Projection
Text
Graph,
Text Projecti
on
Notation, …
Graph, Matrix,
Projection Table
Matrix
Table Text
Form

29. Graph,
Projection
Impedance
Text
Context
switching
Notation, …
Matrix
Tree,
Form,
Lossy
Table
Project
ion
Lost in space

30. Graph,
Projection
Impedance
Text
Context
switching
Notation, …
Matrix
Tree,
Form,
Lossy
Table
Project
ion
Lost in space

32. Graphical vs. Textual

33. Graphical vs. Textual Graphical
A
B
C
Choices/Flow

34. Graphical vs. Textual Graphical
E
H X F
G
Relationships

35. Graphical vs. Textual
G
Graphical
H
I
Timing
J

36. Graphical vs. Textual
Textual
In all other cases!
=

37. Worst practice: notation
Predetermined
Paradigm
Choosing wrong notation
type because of
blinkered view 7%

38. Why I love text

39. Graphical vs. Textual
Real simple…
… CVS/SVN Integration
… Diff/Merge
… Tool Interchange
… Copy/Paste

41. When I love text
?

42. ?
Graphical vs. Textual
C.A.R. Hoare:Hints on Programming Language Design
- transparency of meaning
- independence of parts
- recursive application
- narrow interfaces
- manifestness of structure
- locality and scope
- procedures and parameters

44. Why graphics love text

45. Graphical + Textual
GPU
Dual Coding
CPU

46. Software
flow diagram
Graphical + Textual
LISP
FORTRAN
ALGOL
1940s COBOL
1950s

47. Graphical + Textual
Visual languages
25 000 years
before writing

49. Example:
Medical mixing machine

50. Medical Mixing Machine
“take from the second cup 01 move(-3); filt(1); suck(5);
5 units with filter A and 02 move(4); filt(0); blow(2);
put 2 units to cup 6 03 move(1); blow(3);
and 3 units to cup 7 and 04 move(-3); suck(30);
then clean the needle” 05 move(1); blow(30);

51. Version 0: Unitype Modelling Language
Straight mapping of text DSL to graphical
move(-3);
filt(1);
suck(5);
move(4);
filt(0);
blow(2);
move(1);
blow(3);
move(-3);
suck(30);
move(1);
blow(30);

52. Worst practices: Concept Source
Too generic/specific
Too few/generic 21%
Too many/specific 8%
Language for 1 model 7%

53. Simplistic symbols
Worst practice: notation
Too simple/similar 25%
Downright ugly 5%

54. Version 1: first real DSM language
• Domain-specific, meaningful symbols
– Cf. intention-revealing names, syntax colouring

56. Graphical Syntax

57. Moody TSE09
Symbol should have
1:1 mapping
Notation, …
to Domain concept

58. Problem Abstract Concrete
Moody TSE09
domain syntax syntax
Notation, …

59. Moody TSE09
Symbol should
call to mind
Notation, …
Domain concept

60. Symbols should use
full range
Moody TSE09
of visual variables
Notation, …
Bertin’s Semiology of Graphics

61. «Person» «Laptop»
«Output» «Input»
Notation, …

62. «Person» «Laptop»
«Output» «Input»
pictogram > geometric > photo
Notation, …

63. Worst practice: notation
Simplistic symbols
Too simple/similar 25%
Downright ugly 5%

64. Color & label not enough
Worst practice: notation

65. Line: Saturated
Fill: Near white
Text: Dark on light
Notation, …
LONG TEXTS
ARE NOT SO
READABLE
LIKE THIS

67. Model Integration

68. language
Best integration
^
Model Integration
=
No integration

69. Moody TSE09
Decomposition
Model Integration
… Logical structure
… Sub-models
… Max 20 elements each
… Split 7±2 ways / level

70. Moody TSE09
Summary Model
Model Integration
… Top-level overview
… Shows all sub-models
… Shows sub-model links

71. Moody TSE09
Side-by-side view
Model Integration
… 2+ models on screen
… Reduces memory load
… User chooses
… User positions

72. Moody TSE09
Cross-model links
Model Integration
… Show referred objects
… Real object or pointer
… Use sparingly: coupling

73. Version 2: Logical grouping
• Collect logical groups of code into visual chunks
– Cf. commented code regions, GOTO
move(-3);
filt(1);
suck(5);
}
move(4);
filt(0);
blow(2);
}
move(1);
blow(3); }
move(-3);
suck(30);
move(1);
blow(30);
}

74. Version 3: Support model reuse
• Cf. GOSUB, functions
Sub-model X
decomposition

76. Integration Paradigm 1:
String matching in files
Model Integration
• Strings are 1-dimensional character arrays
• Look for same sequence, “E”, “m”, “p” etc.
– Or UUID, unique identifier in XML
• Inefficient, hard to see, fragile
– but familiar!
c l a s s E m p l o y e e
. . . c l a s s Ma
n a g e r e x t e n d s
Em p l o y e e . . .
D e v e l o p e r e x t e
n d s Emp l o y e e

77. Integration Paradigm 2:
Direct reference in repository
Model Integration
• Works like objects in memory
• Efficient: Direct pointer
• Visible: See referrers
• Robust: Change once
– But less familiar!
Employee
Manager Developer

78. String matching
c l a s s E m p l o y e e
. . . c l a s s Ma
Model Integration
n a g e r e x t e n d s
Em p l o y e e . . .
D e v e l o p e r e x t e
n d s Emp l o y e e
Direct reference
Employee
Manager Developer

79. Integration Paradigms:
Tool support for direct reference
Model Integration
• Concrete syntax: view
• UI: edit
• Cross-model references: link
• Disk representation: load
view edit link load
XText
Xtext
EMF/GMF  
DSL Tools  
MPS  
MetaEdit+    

80. Integration Paradigms:
Summary
Model Integration
• We need both!
– But tools often only offer strings
• Use direct references whenever possible
– Make most important references visible
• Use string matching if you need indirection
– Deliberately break into exchangeable modules

82. Building Together

83. Single language,
Multiple notations: Example
• Mobile apps
• UI display
• Control flow
Viewpoints

84. Single language,
Different notation
• Metamodeler
offers choice of
concrete syntax
Viewpoints
• No extra work for
modeler

85. Single language,
Different tool behaviour
• View & edit only what is relevant / allowed
• Generally UI for one user is subset of other
– No extra work for modeler
Viewpoints

86. Single language,
Different notation types
Tool supports multiple editors
on same underlying model
No extra work for metamodeler
(with good tools)
Viewpoints
Modeler adds layout

87. Ignoring
real-life process
Wosrst practice: In Use
of using language
42%

88. Trying to model
Wosrst practice: In Use
like you coded
modeling != coding

89. modeling != coding
Same old problems
but new material
Building together
Old solutions don’t apply
... new processes
... new tools

90. modeling != coding
Diff + merge:
Text easy, graphs hard
Building together
Multi-user editing:
Text hard, graphs easy
Mature Model Management, #cg2011

92. Notation literature
• Blackwell, A., Metaphor in diagrams, Ph.D. Thesis, University of Cambridge,
September 1998. www.cl.cam.ac.uk/~afb21/
• Hoare, C.A.R., Hints on Programming Language Design, Stanford AI Lab, MEMO
AIM-224, http://www.cs.berkeley.edu/~necula/cs263/handouts/hoarehints.pdf
• Kelly, S., Tolvanen, J-P., Domain-Specific Modeling, http://dsmbook.com
• Miller, George A., The Magical Number Seven, Plus or Minus Two Psychological
Review, 63, 81-97. 1956, psychclassics.yorku.ca/Miller/
• Moody, Daniel, van Hillegersberg, Jos, Evaluating the Visual Syntax of UML, D.
Gašević, R. Lämmel, and E. Van Wyk (Eds.): SLE 2008, LNCS 5452, pp. 16–34,
Springer-Verlag Berlin Heidelberg 2009,
http://books.google.fi/books?id=mFy3MXJKLBgC&pg=PA16
• Moody, Daniel, The “Physics” of Notations: Towards a Scientific Basis for
Constructing Visual Notations in Software Engineering, IEEE Transactions on
Software Engineering, Vol. 35, No. 5, November-December 2009,
http://www.ajilon.com.au/en-AU/news/Documents/News_PDFs/
100528_Dr_Daniel_Moody_Software_Engineering_Keynote.pdf

94. Version 4: Higher level domain concepts
• Make reusable chunks into types
– Give types properties to parameterize reuse
• From:
• To:
Take Put Clean

95. Version 4: Reqs  Model  Code
“take from the put 2 put 3 then clean
second cup 5 units to units to the needle”
units with filter A cup 6 cup 7
01 move(-3); filt(1); suck(5);
02 move(4); filt(0); blow(2);
03 move(1); blow(3);
04 move(-3); suck(30);
05 move(1); blow(30);

96. Modeling effort?
 17 objects  5 objects
 12 relationships  4 relationship
 17 properties  7 properties
 46 elements in total  16 elements in total

97. Modeling effort?
 17 objects  2 objects
 12 relationships  2 relationships
 17 properties  3 properties
 46 elements in total  7 elements in total