Concrete Syntax Matters

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.

Transcript

1. etercnoConcrete xatnySyntax srettaMatters
2. Worst practices 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 Best Practices [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.
3. • 76 DSM cases • 15 years • 4 continents • several tools • 100 DSL creators • 3–300 modelers  what doesn’t work Worst practices 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
4. Worst practices: Concept Source Tool: hammer  nails Tool’s technical limitations dictate language 14%
5. Brain Power
6. Vision Touch Hearing Smell Taste Brain Power Sensory neurons visual We have brains
7. Brain Power s e r i a l Text parallel parallel parallel parallel parallel parallel Visual
8. Brain Power s e r i a l Text parallel parallel parallel parallel parallel parallel Visual
9. Brain Power Perceptual vs. Cognitive
10. Brain Power Spot the odd one out! Perceptual Popout Moody TSE09
11. Brain Power Spot the odd one out! Perceptual Popout Moody TSE09
12. Brain Power Spot the odd one out! Perceptual Popout Moody TSE09
13. Brain Power Spot the odd one out! Perceptual Popout Moody TSE09
14. Brain Power Unique values Perceptual Popout Combinations > Moody TSE09
15. Brain Power Does UML pop? Moody SLE08 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
17. Notation, Notation, Notation
18. Notation, … Domain Users care deeply about notation! “UI” for the language
19. Brain Power ≥ 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]. “ ” Moody TSE09
20. Brain Power ≥ 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]. “ ” Moody TSE09
21. Notation, … Visual Text Projec- tion Graph Matrix Tree, Form, Table Notation Types
22. Notation, … Text
23. Notation, … Graph
24. Notation, … Matrix Table Form Tree
25. Notation, … Projectional
26. Notation, … Visual Text Projec- tion Graph Matrix Tree, Form, Table Notation Types
27. Matrix Tree, Form, Table Project ion Notation, … Objects Text Graph Partially Convertible Parse
28. Notation, … Matrix, Table Text Graph, Projection Text Text Graph, Projecti on Graph, Projection Matrix Table Form Embeddable Partially
29. Notation, … Graph, Projection Text Impedance Context switching Lossy Lost in space Matrix Tree, Form, Table Project ion
30. Notation, … Graph, Projection Text Impedance Context switching Lossy Lost in space Matrix Tree, Form, Table Project ion
32. Graphical vs. Textual
33. A B C Choices/Flow Graphical Graphical vs. Textual
34. X E F G H Relationships Graphical Graphical vs. Textual
35. G H I J Timing Graphical Graphical vs. Textual
36. Graphical vs. Textual In all other cases! Textual  =
37. Worst practice: notation Choosing wrong notation type because of blinkered view 7% Predetermined Paradigm
38. Why I love text
39. Graphical vs. Textual … CVS/SVN Integration … Diff/Merge … Tool Interchange … Copy/Paste Real simple…
41. When I love text ?
42. Graphical vs. Textual - 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
44. Why graphics love text
45. Graphical + Textual Dual Coding GPU CPU
46. Graphical + Textual Software flow diagram 1940s LISP FORTRAN ALGOL COBOL 1950s
47. Graphical + Textual 25 000 years Visual languages before writing
49. Example: Medical mixing machine
50. 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);
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 few/generic 21% Too many/specific 8% Language for 1 model 7% Too generic/specific
53. Worst practice: notation Too simple/similar 25% Downright ugly 5% Simplistic symbols
54. • Domain-specific, meaningful symbols – Cf. intention-revealing names, syntax colouring Version 1: first real DSM language
56. Graphical Syntax
57. Notation, … Symbol should have 1:1 mapping to Domain concept Moody TSE09
58. Notation, … Problem domain Abstract syntax Concrete syntax Moody TSE09
59. Notation, … Symbol should call to mind Domain concept Moody TSE09
60. Notation, … Symbols should use full range of visual variables Bertin’s Semiology of Graphics Moody TSE09
61. Notation, … «Person» «Laptop» «Output» «Input»
62. Notation, … «Person» «Laptop» «Output» «Input» pictogram > geometric > photo
63. Worst practice: notation Too simple/similar 25% Downright ugly 5% Simplistic symbols
64. Worst practice: notation Color & label not enough
65. Notation, … Line: Saturated Fill: Near white Text: Dark on light LONG TEXTS ARE NOT SO READABLE LIKE THIS
67. Model Integration
68. Best integration Model Integration = No integration language ^
69. Model Integration … Logical structure … Sub-models … Max 20 elements each … Split 7±2 ways / level Decomposition Moody TSE09
70. Model Integration … Top-level overview … Shows all sub-models … Shows sub-model links Summary Model Moody TSE09
71. Model Integration … 2+ models on screen … Reduces memory load … User chooses … User positions Side-by-side view Moody TSE09
72. Model Integration … Show referred objects … Real object or pointer … Use sparingly: coupling Cross-model links Moody TSE09
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 decomposition Sub-model X
76. 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 Model Integration
77. 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 Model Integration
78. Employee Manager Developer Model Integration 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
79. Integration Paradigms: Tool support for direct reference • Concrete syntax: view • UI: edit • Cross-model references: link • Disk representation: load view edit link load Xtext Model Integration 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+    
80. 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 Model Integration
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 • No extra work for modeler Viewpoints
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 Viewpoints Tool supports multiple editors on same underlying model No extra work for metamodeler (with good tools) Modeler adds layout
87. Wosrst practice: In Use Ignoring real-life process of using language 42%
88. Wosrst practice: In Use Trying to model like you coded modeling != coding
89. Building together ... new processes ... new tools but new material Same old problems Old solutions don’t apply modeling != coding
90. Building together Text easy, graphs hard Diff + merge: Multi-user editing: Text hard, graphs easy modeling != coding 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 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);
96. Modeling effort?  5 objects  4 relationship  7 properties  16 elements in total  17 objects  12 relationships  17 properties  46 elements in total
97. Modeling effort?  2 objects  2 relationships  3 properties  7 elements in total  17 objects  12 relationships  17 properties  46 elements in total