Embed Size (px)
DESCRIPTION
[Video link below] The single largest reason for user rejection of a language is how it looks. And let’s be honest, even most successful languages are pretty ugly – from the sea of angle brackets that is XML to the monochrome lines of UML. In this session we will look at how to design languages to make best use of the limited input, processing and output capabilities of the weakest link in software development: humans. Cognitive and empirical research has produced a number of results that are often surprising, always enlightening, yet all too rarely used. We will look at these results and examples of good and bad languages, both textual and graphical, focusing on their concrete syntax. Video from Code Generation 2012: http://www.infoq.com/presentations/Language-Design
Citation preview
etercnoConcrete xatnySyntax srettaMatters
Wo
rst
pra
ctic
es
Daniel Moody 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
Be
st P
ract
ice
s
[1] Alexander, C.W., Notes On The Synthesis Of Form. 1970, Boston, US: Harvard University Press. [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.
• 76 DSM cases • 15 years • 4 continents • several tools • 100 DSL creators • 3–300 modelers
what doesn’t work
Wo
rst
pra
ctic
es
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
Wo
rst
pra
ctic
es:
Co
nce
pt
Sou
rce
Tool: hammer nails Tool’s technical limitations dictate language 14%
Brain Power
Vision
Touch
Hearing
Smell
Taste
Bra
in P
ow
er
Sensory neurons
visual We have
brains
Bra
in P
ow
er s
e r i a l
Text
parallel parallel parallel parallel parallel parallel
Visual
Bra
in P
ow
er s
e r i a l
Text
parallel parallel parallel parallel parallel parallel
Visual
Bra
in P
ow
er
Perceptual vs.
Cognitive
Bra
in P
ow
er
Spot the odd one out!
Perceptual Popout M
oo
dy
TSE0
9
Bra
in P
ow
er
Spot the odd one out!
Perceptual Popout M
oo
dy
TSE0
9
Bra
in P
ow
er
Spot the odd one out!
Perceptual Popout M
oo
dy
TSE0
9
Bra
in P
ow
er
Spot the odd one out!
Perceptual Popout M
oo
dy
TSE0
9
Bra
in P
ow
er
Unique values
Perceptual Popout
Combinations >
Mo
od
y TS
E09
Bra
in P
ow
er
Does UML pop? M
oo
dy
SLE0
8
Line value End shape End value
Relationship Solid Dashed Diamond Open arrow Cross
Closed arrow Circle
Semi-circle None Black White
Aggregation
Association (navigable)
Association (non-navigable)
Association class
Composition
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
Notation, Notation, Notation
No
tati
on
, …
Domain Users
care deeply about notation!
“UI” for the language
Bra
in P
ow
er ≥ Form Content
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].
“
”
Mo
od
y TS
E09
Bra
in P
ow
er ≥ Concrete
syntax Abstract 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].
“
”
Mo
od
y TS
E09
No
tati
on
, …
Visual
Text
Projec-tion
Graph Matrix
Tree, Form, Table
Notation Types
No
tati
on
, …
Text
No
tati
on
, …
Graph
No
tati
on
, …
Matrix
Table Form Tree
No
tati
on
, … Projectional
No
tati
on
, …
Visual
Text
Projec-tion
Graph Matrix
Tree, Form, Table
Notation Types
Matrix
Tree, Form, Table
Project ion
No
tati
on
, …
Objects Text Graph
Partially Convertible
Parse
No
tati
on
, …
Matrix, Table
Text
Graph, Projection
Text
Text
Graph,Projecti
on
Graph, Projection
Matrix Table Form
Embeddable Partially
No
tati
on
, …
Graph, Projection
Text
Impedance Context switching Lossy Lost in space
Matrix
Tree, Form, Table
Project ion
No
tati
on
, …
Graph, Projection
Text
Impedance Context switching Lossy Lost in space
Matrix
Tree, Form, Table
Project ion
Graphical vs. Textual
A
B
C
Choices/Flow
Graphical G
rap
hic
al v
s. T
extu
al
X
E
F
G
H
Relationships
Graphical G
rap
hic
al v
s. T
extu
al
G H
I J
Timing
Graphical G
rap
hic
al v
s. T
extu
al
Gra
ph
ical
vs.
Tex
tual
In all other cases! Textual
=
Wo
rst
pra
ctic
e: n
ota
tio
n
Choosing wrong notation type because of blinkered view 7%
Predetermined Paradigm
Gra
ph
ical
vs.
Tex
tual
… CVS/SVN Integration … Diff/Merge … Tool Interchange … Copy/Paste
Real simple…
Gra
ph
ical
vs.
Tex
tual
- transparency of meaning - independence of parts - recursive application - narrow interfaces - manifestness of structure - locality and scope - procedures and parameters
C.A.R. Hoare: ? Hints on Programming Language Design
Gra
ph
ical
+ T
extu
al
Software flow diagram
1940s
LISP FORTRAN
ALGOL COBOL 1950s
Example: Medical mixing machine
Medical Mixing Machine
“take from the second cup 5 units with filter A and put 2 units to cup 6 and 3 units to cup 7 and then clean the needle”
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);
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);
Wo
rst
pra
ctic
es:
Co
nce
pt
Sou
rce
Too few/generic 21% Too many/specific 8% Language for 1 model 7%
Too generic/specific
Wo
rst
pra
ctic
e:
no
tati
on
Too simple/similar 25% Downright ugly 5%
Simplistic symbols
• Domain-specific, meaningful symbols
– Cf. intention-revealing names, syntax colouring
Version 1: first real DSM language
Graphical Syntax
No
tati
on
, …
Symbol should have
1:1 mapping to Domain concept
Mo
od
y TS
E09
No
tati
on
, …
Problem domain
Abstract syntax
Concrete syntax
Mo
od
y TS
E09
No
tati
on
, …
Symbol should
call to mind Domain concept
Mo
od
y TS
E09
No
tati
on
, …
Symbols should use
full range of visual variables
Bertin’s Semiology of Graphics
Mo
od
y TS
E09
No
tati
on
, …
«Person» «Laptop»
«Output» «Input»
No
tati
on
, …
«Person» «Laptop»
«Output» «Input»
pictogram > geometric > photo
Wo
rst
pra
ctic
e: n
ota
tio
n
Too simple/similar 25% Downright ugly 5%
Simplistic symbols
Wo
rst
pra
ctic
e: n
ota
tio
n Color & label not enough
No
tati
on
, …
Line: Saturated Fill: Near white
Text: Dark on light
LONG TEXTS
ARE NOT SO
READABLE
LIKE THIS
Model Integration
Best integration M
od
el I
nte
grat
ion
= No integration
language
^
Mo
de
l In
tegr
atio
n
… Logical structure … Sub-models … Max 20 elements each … Split 7±2 ways / level
Decomposition Mo
od
y TS
E09
Mo
de
l In
tegr
atio
n
… Top-level overview … Shows all sub-models … Shows sub-model links
Summary Model Mo
od
y TS
E09
Mo
de
l In
tegr
atio
n
… 2+ models on screen … Reduces memory load … User chooses … User positions
Side-by-side view Mo
od
y TS
E09
Mo
de
l In
tegr
atio
n
… Show referred objects … Real object or pointer … Use sparingly: coupling
Cross-model links Mo
od
y TS
E09
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);
Version 3: Support model reuse • Cf. GOSUB, functions
decomposition
Sub-model X
Integration Paradigm 1: String matching in files
• 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 M a
n a g e r e x t e n d s
E m p l o y e e . . .
D e v e l o p e r e x t e
n d s E m p l o y e e
c l a s s E m p l o y e e
. . . c l a s s M a
n a g e r e x t e n d s
E m p l o y e e . . .
D e v e l o p e r e x t e
n d s E m p l o y e e Mo
de
l In
tegr
atio
n
Integration Paradigm 2: Direct reference in repository • Works like objects in memory
• Efficient: Direct pointer
• Visible: See referrers
• Robust: Change once
– But less familiar!
Employee
Manager Developer
Mo
de
l In
tegr
atio
n
Employee
Manager Developer
Mo
de
l In
tegr
atio
n c l a s s E m p l o y e e
. . . c l a s s M a
n a g e r e x t e n d s
E m p l o y e e . . .
D e v e l o p e r e x t e
n d s E m p l o y e e
String matching
Direct reference
Integration Paradigms: Tool support for direct reference • Concrete syntax: view
• UI: edit
• Cross-model references: link
• Disk representation: load
view edit link load
Xtext
Mo
de
l In
tegr
atio
n
view edit link load
XText
EMF/GMF
DSL Tools
view edit link load
XText
EMF/GMF
DSL Tools
MPS
view edit link load
XText
EMF/GMF
DSL Tools
MPS
MetaEdit+
Integration Paradigms: Summary
• 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
Mo
de
l In
tegr
atio
n
Building Together
Single language, Multiple notations: Example
• Mobile apps
• UI display
• Control flow
Vie
wp
oin
ts
Single language, Different notation
• Metamodeler offers choice of concrete syntax
• No extra work for modeler
Vie
wp
oin
ts
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
Vie
wp
oin
ts
Single language, Different notation types
Vie
wp
oin
ts
Tool supports multiple editors on same underlying model
No extra work for metamodeler
(with good tools)
Modeler adds layout
Wo
srst
pra
ctic
e:
In U
se
Ignoring real-life process
of using language
42%
Wo
srst
pra
ctic
e:
In U
se Trying to model
like you coded
modeling != coding
Bu
ildin
g to
geth
er
... new processes
... new tools
but new material Same old problems
Old solutions don’t apply
modeling != coding
Bu
ildin
g to
geth
er Text easy, graphs hard
Diff + merge:
Multi-user editing: Text hard, graphs easy
modeling != coding
Mature Model Management, #cg2011
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
Version 4: Higher level domain concepts
• Make reusable chunks into types – Give types properties to parameterize reuse
• From:
• To:
Take Put Clean
Version 4: Reqs Model Code
“take from the second cup 5 units with filter A
put 2 units to cup 6
put 3 units to cup 7
then clean the needle”
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);
Modeling effort?
5 objects
4 relationship
7 properties
16 elements in total
17 objects
12 relationships
17 properties
46 elements in total
Modeling effort?
2 objects
2 relationships
3 properties
7 elements in total
17 objects
12 relationships
17 properties
46 elements in total
