Domain Specific Languages
for Business Users
Jos Warmer, Independent
jos.warmer@openmodeling.nl
www.openmodeling.nl
Background Experience
Business DSLs
 Insurance
Product Modeling (structure)
 Pattern matching expressions
 Insurance Mathematics
 Insurance Product Modeling
Technologies used
EMF + Graphiti + CDO
 JetBrains MPS
Sheet 2
 Eclipse
Business Versus Technical DSL
Business DSL
Sheet 3
Technical DSL
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
Xtext or other textual parsing based DSL toolkits
Sheet 4
 E.g.
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.
between language and app disappears
Sheet 5
 Distinction
“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
Sheet 6
70: FLAG =
IF NMES>999 THEN 157
“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’
Sheet 7
PREMIO = PREMIO + BON07
Sheet 8
“We are not programmers”
Sheet 9
Notation and Editing:
Programmers versus
Business users
Structured or Free-form
Programmers dislike structure.
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 10
 Prefer
Structured or Free-form
Business People like structure.
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 11
 Structured
Structured or Free-form
Sheet 12
SUM(i, INVBA - PREMIO, 10 + INFWP, (i/8) - prod(k, i + 1, PREMIO + 1, k + (i^2)))
Plain Text versus „anything else“
Programmers prefer text over everything
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 13
 Diagrams:
Plain Text versus „anything else“
Business People like many notations
 Diagrams, Tables,
Mathematical Formulas, Trees, Text, Dropdown lists,
etc.
 ... and combine them !
Sheet 14
Business people feel restricted if they have to use a
notation that is not suitable for what they want
to express.
Sheet 15
Plain Text versus „anything else“
Clean Sheets vs. Scaffolding
Programmers like clean sheets
needs guidance anyway?
 It‘s beneath a developer to need any help !
Sheet 16
 Who
Clean Sheets vs. Scaffolding
Business People like scaffolding
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 !
Sheet 17
 Clean
Sheet 18
Clean Sheets vs. Scaffolding
Layout
Programmers do their own layout
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 19
 Even
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
... it should be done right !
Do developers really like to waste time ?
Why ?
Sheet 20
 But
Sheet 21
Layout Example
Viewpoints
Programmers use one view
 Use
folding, but still see the folded element
 Want to see everything to be in control
 But
 Use
I want to see everything that is there,
cannot afford to miss anything
Sheet 22
outline view, hierarchy view, explorer view, ...
 Won‘t see everything anyway when using e.g. aspect weaving or dependency
injection
Viewpoints
Business People use diverse notations and views
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.
Sheet 23
 Different
Sheet 24
Viewpoints
Menus, windows, toolbars ...
Programmers like to have many options
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 25
 Menus
Menus, windows, toolbars ...
Business People like to keep interface clean
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 26
 Only
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
Sheet 27
(which is most DSL‘s we have today)
Sheet 28
Projectional Notation and
Editing
Parsing versus Projection
Text
Error Messages
Text, Tables,
Mathematical,
Graphical
Scanning & parsing
Parse Tree
Binding
Abstract Syntax
Graph
29
Sheet 29
Abstract Syntax
Graph
Examples
Layout in PMW
 Manual,
many hours per diagram
 With many hundreds of diagrams
Mathematical Notation
 Sum,
Product symbols
Sheet 30
Tables
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
composition made easier
 E.g. Java extensions in MPS Java
Sheet 31
 Language
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
have to deal with notation. Otherwise unparsing has to be used
and models will suddenly look different.
Sheet 32
 Don’t
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
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 33
 We
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
it is a non-issue because … business users use specialized tools
anyway, excel, word, ...
Sheet 34
 But
Sheet 35
Additional Requirements for
Business Users
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
locking
 Optimistic locking
 Real-time updates from one user to another
Sheet 36
 Pessimistic
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
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 37
 Model
Access Control
Programmers use SVN, Git, etc.
 Read
or write access to repository
Business users need fine grained control
parts of a model may be accessible by certain users
 Need ‘optional visibility’
 Role based views, notations and editing
 Formal approvals processes
Sheet 38
 Some
Sheet 39
Reviewing
Sheet 40
Multi Lingual
Sheet 41
Multi Lingual
Direct Feedback
Direct feedback
models, directly testable, executable
 Examples with test cases and debugging
Sheet 42
 Active
Sheet 43
The End
(Almost)
When use business DSL
For SIMPLE or bulk data
Sheet 44
For complex structures, calculations,
configurations, rules or analyses at the
heart of a business domain
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, …
Sheet 45
We are at the beginning of exploring all
possibilities