Domain Specific Languages for Business Users Jos Warmer, Independent jos.warmer@openmodeling.nl www.openmodeling.nl
Sheet 2 Background Experience Business DSLs Insurance Product Modeling (structure) Pattern matching expressions Insurance Mathematics Insurance Product Modeling Technologies used Eclipse EMF + Graphiti + CDO JetBrains MPS
Sheet 3 Business Versus Technical DSL Business DSL Technical DSL
Sheet 4 Business DSLs Bridges business IT gap Uses business terminology Formal enough tot automate No interpretation differences between business and IT Fast time tot market Business in the driving seat But... Business users are used to Word, Excel, natural language, pictures, etc. etc.... Typical tools for technical DSLs do not neccesarily fit E.g. Xtext or other textual parsing based DSL toolkits
Sheet 5 Notation Notation is crucial!! Business users are reluctant to use unnatural notation... but delighted to use the right notation! E.g. insurance formulae Combine typical language notation with forms, buttons, sliders, tables, etc. Distinction between language and app disappears
Sheet 6 We are not programmers 40: BON07 = IF INVBA < 0 THEN Premio * valba ELSE 0 50: VAR = IF CATV=P1.AND. INFWP[01]<=7000000 THEN L ELSE IF CATV=P1.AND. INFWP[01]>7000000 THEN B ELSE IF CATV=P2 THEN M ELSE IF CATV=P3 THEN C ELSE IF CATV=P4 THEN P 60: PREMIO = PREMIO + BON07 70: FLAG = IF NMES>999 THEN 157
Sheet 7 We are not programmers CASE WHEN INVBA < 0 BON07 = Premio * valba OTHERWISE BON07 = 0 CASE WHEN CATV=P1.AND. INFWP[01]<=7000000 VAR = L WHEN CATV=P1.AND. INFWP[01]>7000000 VAR = B WHEN CATV=P2 VAR = M WHEN CATV=P3 VAR = C WHEN CATV=P4 VAR = P PREMIO = PREMIO + BON07
We are not programmers Sheet 8
Sheet 9 Notation and Editing: Programmers versus Business users
Sheet 10 Structured or Free-form Programmers dislike structure. Prefer plain text and a parser to tell them what is wrong Copy-paste: Manually try to select semantically meaningfull pieces of text like e.g. a variable declaration, an if statement, a condition in an if, one or more method parameters, etc.
Sheet 11 Structured or Free-form Business People like structure. Structured editing can only create correct input Typing text and hoping you do it right makes little sense Copy-paste selects semantically meaningfull pieces automatically You would expect otherwise: IT people are formally trained compared to business people, so expectation is the other way around.
Sheet 12 Structured or Free-form SUM(i, INVBA - PREMIO, 10 + INFWP, (i/8) - prod(k, i + 1, PREMIO + 1, k + (i^2)))
Sheet 13 Plain Text versus anything else Programmers prefer text over everything Diagrams: remember UML bashing? Real programmers don t draw pictures Programmers like tables in HTML, XML, Wikis, but why have them in code? Even for tables, where text is clearly totally unsuitable!
Sheet 14 Plain Text versus anything else Business People like many notations Diagrams, Tables, Mathematical Formulas, Trees, Text, Dropdown lists, etc.... and combine them! Business people feel restricted if they have to use a notation that is not suitable for what they want to express.
Plain Text versus anything else Sheet 15
Sheet 16 Clean Sheets vs. Scaffolding Programmers like clean sheets Who needs guidance anyway? It s beneath a developer to need any help!
Sheet 17 Clean Sheets vs. Scaffolding Business People like scaffolding Clean sheet is confusing Prefer guidance on what can/should be done. What am I supposed to do with an empty page? Forms are nice, they tell me what to do and where to put what Why remember if the computer can tell you what to do? And where to do it!
Clean Sheets vs. Scaffolding Sheet 18
Sheet 19 Layout Programmers do their own layout Even getting developers to use the same formatter with the same configuration turns out to be really hard. I ve been told quite often to not even try that. Why is it so important that my IF statement looks different from the IF statement of my collegue programmer?
Sheet 20 Layout Business People prefer standardized layout Prefer layout of similar things to be identical Is always recognizable Don t want to waste time on doing manual layout But... it should be done right! Do developers really like to waste time? Why?
Layout Example Sheet 21
Sheet 22 Viewpoints Programmers use one view Use folding, but still see the folded element Want to see everything to be in control But Use outline view, hierarchy view, explorer view,... Won t see everything anyway when using e.g. aspect weaving or dependency injection I want to see everything that is there, cannot afford to miss anything
Sheet 23 Viewpoints Business People use diverse notations and views Different viewpoints, e.g. textual and visual Only show information needed for a task, hide irrelevant parts of the model People in some roles are not supposed (or allowed) to see certain things I only want to see what I need, no less, no more.
Viewpoints Sheet 24
Sheet 25 Menus, windows, toolbars... Programmers like to have many options Menus everywhere, including popup menus Toolbars with all options ever needed Not scared of unknown options... Tools that give me the power to do anything I need (and more...)
Sheet 26 Menus, windows, toolbars... Business People like to keep interface clean Only show menus, toolbars that are applicable Only show what I can actually do Any button, menu, etc. that I don t understand is distracting I only want to see what I need, no less, no more.
Sheet 27 Summing Up All these differences mean that the requirements for business oriented DSL s are very different from what we have learned about DSL s for developers (which is most DSL s we have today)
Sheet 28 Projectional Notation and Editing
Sheet 29 Parsing versus Projection Text Error Messages Text, Tables, Mathematical, Graphical Scanning & parsing Parse Tree Binding Abstract Syntax Graph Abstract Syntax Graph 29
Sheet 30 Examples Layout in PMW Manual, many hours per diagram With many hundreds of diagrams Mathematical Notation Sum, Product symbols Tables
Sheet 31 Projectional Advantages User Guidance Always looks the same, recognizable Important for working in teams Enables richer and more flexible notations Textual parsing does not work with tables, mathematical notation etc. Mixing different aspects Mix expressions with test cases and results of running the tests Show a referred element inline Mix different Languages Language composition made easier E.g. Java extensions in MPS Java
Sheet 32 Projectional Advantages Easy tot have multiple notations Just create multiple projections E.g. for views for different users in different roles Or partial views, leave thing out Trivial to change, improve, extend notation Notation is not stored Start using a notation and improve as it is being used and evaluated Agile!!! Language evolution easier Don t have to deal with notation. Otherwise unparsing has to be used and models will suddenly look different.
Sheet 33 Projectional Disadvantages Structured / projectional editors are cumbersome I did research at CWI and Vu 25 years ago and this was true Especially Expressions are hard We moved on since 25 years ago, try MPS. It feels just like typing and shows that this is not necessarily true But old beliefs die slowly...
Sheet 34 Projectional Disadvantages Need specialized tools Developers can use plain text editors, but in practice 99 % use specialized IDEs. And their editors use many things typical for projectional editors as well: templates for language constructs code completion auto-formatting But it is a non-issue because business users use specialized tools anyway, excel, word,...
Sheet 35 Additional Requirements for Business Users
Sheet 36 Multi User Programmers use SVN, Git, etc. Each programmer has its own private workspace Allows for parallel changes Merge if necessary Merge is a difficult concept for business users Pessimistic locking Optimistic locking Real-time updates from one user to another
Sheet 37 Versioning Programmers need versioning Only one version is in production at one machine Need to be able to access old versions of models as a whole Business users need versioning But many versions of a model may be in production at the same time E.g. Life insurance models Sometimes old models need to be updates to new models Model results in contract model version need to exists during lifetime of contract New model versions only used for new contracts Exception: legislation may require a change in older contracts / models
Sheet 38 Access Control Programmers use SVN, Git, etc. Read or write access to repository Business users need fine grained control Some parts of a model may be accessible by certain users Need optional visibility Role based views, notations and editing Formal approvals processes
Reviewing Sheet 39
Multi Lingual Sheet 40
Multi Lingual Sheet 41
Sheet 42 Direct Feedback Direct feedback Active models, directly testable, executable Examples with test cases and debugging
Sheet 43 The End (Almost)
Sheet 44 When use business DSL For SIMPLE or bulk data For complex structures, calculations, configurations, rules or analyses at the heart of a business domain
Sheet 45 Business Oriented Language Applications Business DSLs have huge potential Tools (especially MPS) are available now Tables Mathematical notation Graphical Textual MS-Word like Integrated testing Buttons, sliders, checkboxes, We are at the beginning of exploring all possibilities