Traditionally, DSLs have been targeted at "specialized programmers" or at least at people with a strong technical background such as engineers, mathematicians or scientists. However, DSLs can also be very useful for people who work in fields that are less technical, and more on the business side of the universe.
In this session we discuss our experiences in building DSLs for business people, i.e. non-IT people who know their respective domain well. These people are not necessarily experienced in structured (or even formal) representation of their expert knowledge, and might not even be experts in computer usage.
Over the last few years, Markus, Jos & Bernd have gained some valuable experience into the kinds of domains, people, languages, and notations that make this approach feasible. It turns out that the requirements for DSLs and the tools used can be quite different for business users. The goal of this session is to present this experience and start a discussion about how to move the field forward.
The experiences are taken from Bernd's and Markus's work with Intentional and Achmea Insurance, Jos's work for an insurance company in Porto, and Markus's and Bernd's work on the requirements language in mbeddr.
2. 1 Background: mbeddr
2 mbeddr Demo 1
3 JetBrains MPS
4 mbeddr Demo 2
5 Generalization
6 LOBA
7 Evaluation
8 Conclusion
where we are
what is missing
why
6. About mbeddr
Language Engineering Embedded Software
Open Source
Eclipse Public License
http://mbeddr.com
http://www.eclipse.org/proposals/technology.mbeddr/
14. About MPS
Language Composition
L2 L1
Separate Files In One File
Type System
Transformation
Constraints
Type System
Transformation
Constraints
Syntax
Editor/IDE
21. Generic Tools, Specific Languages
Ingredients
Languages
Language Engineering
Syntactic Diversity
Language WorkbenchesGeneric Tools
Specific
Languages
(we don‘t have to reimplement
editors and synchronizers)
22. Generic Tools, Specific Languages
Ingredients
Languages
Language Engineering
Syntactic Diversity
Language WorkbenchesGeneric Tools
Specific
Languages
support
23. Language Workbenches
Typical Features
Goto Definition/Find Usages
Error Markup/Quick Fixes
Syntax Highlighting
Code Completion
Search/Replace
Refactoring
Debugging
Reporting
Visualization
Version Control
28. End User Need
Data is King!
End-Users want to
essentially operate on data.
Prof. Dr. Florian Matthes
Software Engineering for Business Information System
TU Munich
29. LOBA: Why
For which kinds of Systems?
Language
Workbenches act as
the foundation for
IDEs for any
language.
30. LOBA: Why
For which kinds of Systems?
Language
Workbenches act as
the foundation for
IDEs for (m)any
applications.
31. LOBA: Why
For which kinds of Systems?
many applications?
Structured or Formalizable
Mathematical
Data-Oriented
Language-y
32. LOBA: Why
For which kinds of Systems?
many applications?
Data Models
Pricing Calculations
Financial Calculations
Contracts
Business Rules
Highly Structured Requirements
36. LOBA: IT versus Business
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.
37. LOBA: IT versus Business
Structured or Free-form
Business People like structure.
• Structured editing can only create correct input
• 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.
38. LOBA: IT versus Business
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 !
39. LOBA: IT versus Business
Text versus „anything else“
Business People like many notations
• Diagrams, Tables, Mathematical Formulas,
Trees, Text, etc.
• ... and combine them !
Business people feel restricted if they nhave to use a notation
that is not suitable for what they want to express.
40. LOBA: IT versus Business
Clean Sheets vs. Scaffolding
Programmers like clean sheets
• Who needs guidance anyway?
• It‘s beneath a developer to need any help !
Nobody tells me what to do!
It hinders my artistic freedom!
41. LOBA: IT versus Business
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 !
42. LOBA: IT versus Business
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?
43. LOBA: IT versus Business
Layout
Business People prefer stanardized layout
• Prefer layout of similar things to be identical
• Is always recognizable
• Don‘t want to waste time on doing manual
layout
Do developers really like to waste time ? Why ?
44. LOBA: IT versus Business
Viewpoints
Programmers use one notation and view
• Use folding, but still see the folded element.
• Use design techniques to decompose aspects
I want to see everything that is there,
cannot afford to miss anything
45. LOBA: IT versus Business
Viewpoints
Business People use diverse notations
and views
• Different viewpoints, e.g. textual and visual
• Only show information needed for a task, hide
parts of the model
I only want to see what I need, no less, no more.
46. LOBA: IT versus Business
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)
47. LOBA: IT versus Business
Summing Up
Combine the best of
Applications/Forms/UIs
and
Languages and IDEs.
71. End User Need
Data is King!
End-Users want to
essentially operate on data.
Prof. Dr. Florian Matthes
Software Engineering for Business Information System
TU Munich
72. End User Need
Data is King!
End-Users want to
essentially operate on data.
Prof. Dr. Florian Matthes
Software Engineering for Business Information System
TU Munich
73. Language Workbenches
All the IDE Support We Expect
Goto Definition/Find Usages
Error Markup/Quick Fixes
Syntax Highlighting
Code Completion
Search/Replace
Refactoring
Reporting
Visualization
Version Control
75. LOBA
What is the Scope?
not the mass data –
this remains in databases.
Complex structures,
calculations, rules or analyses
at the heart of a
business domain.
77. LOBA: What is missing/Challenges
Apparent Tool Complexity
Too many (too big)
menus and buttons
78. LOBA: What is missing/Challenges
Need for Simplified Version Control
Too many options.
Locking?
Realtime?
79. LOBA: What is missing/Challenges
Some Shortcomings in MPS
Adressed by JetBrains in 2014.
Cross-model generation
Projection of computed collections
Better Graphical Editing
Type System Performance
Some Editor Usability
80. LOBA: What is missing/Challenges
Training
Users may not be used to this approach.
Training is important.
Productivity more useful than Learnability.
81. LOBA: What is missing/Challenges
SE Best Practices
Modularity, Reuse, Injeritance, ...
Users may not know about these
things, but they may still be necessary
for efficiency reasons.
84. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Visibility of system status
The system should always keep users informed
about what is going on, through appropriate
feedback within reasonable time.
Program is always visible
Realtime Type Checking
Scaffolding
85. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Match between system and the real world
The system should speak the users' language,
with words, phrases and concepts familiar to the
user, rather than system-oriented terms. Follow
real-world conventions, making information
appear in a natural and logical order.
DSLs
Domain Notations (Math, Tables)
Extensibility, „Grow Language“
86. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
User control and freedom
Users often choose system functions by mistake
and will need a clearly marked "emergency exit"
to leave the unwanted state without having to go
through an extended dialogue. Support undo
and redo.
Undo/Redo
Revert in Version Control
87. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Consistency and standards
Users should not have to wonder whether
different words, situations, or actions mean the
same thing. Follow platform conventions.
Consistent IDE
All languages „work“ the same
Design unambiguous syntax
88. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Error prevention
Even better than good error messages is a
careful design which prevents a problem from
occurring in the first place. Either eliminate
error-prone conditions or check for them and
present users with a confirmation option before
they commit to the action.
Language Structure/Constraints
Scaffolding
89. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Recognition rather than recall
Minimize the user's memory load by making
objects, actions, and options visible. The user
should not have to remember information from
one part of the dialogue to another. Instructions
for use of the system should be visible or easily
retrievable whenever appropriate.
Non-Modality
CC, Intentions, Menus
90. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Flexibility and efficiency of use
Accelerators – unseen by the novice user – may
often speed up the interaction for the expert
user such that the system can cater to both
inexperienced and experienced users. Allow
users to tailor frequent actions.
Keyboard Shortcuts (adaptable)
Intentions, Quickfixes, Refac‘ings
91. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Aesthetic and minimalist design
Dialogues should not contain information which
is irrelevant or rarely needed. Every extra unit of
information in a dialogue competes with the
relevant units of information and diminishes
their relative visibility.
Multiple Projections/Views
Intentions, Quick Fixes, etc.
92. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Help users recognize, diagnose,
and recover from errors
Error messages should be expressed in plain
language (no codes), precisely indicate the
problem, and constructively suggest a solution.
Up to the language designer.
Quick Fixes
93. Evaluation
J. Nielsen: Usability Heuristics for UI
Design
Help and documentation
Even though it is better if the system can be
used without documentation, it may be
necessary to provide help and documentation.
Any such information should be easy to search,
focused on the user's task, list concrete steps to
be carried out, and not be too large.
Up to the language designer.
95. Conclusions
Applications „hide“ Languages
No Explicit Tool Support for them
LOBAs are useful alternative
Connect Business & IT
Points to take away
LWBs are powerful enough
In particular, notations!
A lot of stuff is Open Source!