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.

1. Markus Voelter
independent/itemis
voelter@acm.org
www.voelter.de
@markusvoelter
Bernd Kolb
itemis
kolb@itemis.de
www.itemis.de
@berndkolb
Language-Oriented
Business Applications
On the way to DSLs for non-programmers
Jos Warmer
OpenModeling
Jos.warmer@openmodeling.nl
openmodeling.nl

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

3. About mbeddr

4. About mbeddr
Language Engineering Embedded Software
An extensible collection of integrated
languages for embedded software engineering.

5. About mbeddr
Language Engineering Embedded Software
An IDE + Debugger for all of them

6. About mbeddr
Language Engineering Embedded Software
Open Source
Eclipse Public License
http://mbeddr.com
http://www.eclipse.org/proposals/technology.mbeddr/

7. mbeddr Demo I
C & Extensions

8. JetBrains MPS

9. About mbeddr
Built on JetBrains MPS
A Language Workbench

10. About mbeddr
Built on JetBrains MPS
Open Source
Apache 2.0
http://jetbrains.com/mps

11. About MPS
Rich Set of Language Aspects
+ Refactorings, Find Usages, Syntax Coloring, Debugging, ...

12. About MPS
Projectional Editing
Parsing Projection

13. About MPS
Notational Flexibility
Regular Code/Text Mathematical
Tables Graphical

14. About MPS
Language Composition
L2 L1
Separate Files In One File
Type System
Transformation
Constraints
Type System
Transformation
Constraints
Syntax
Editor/IDE

15. mbeddr Demo II
Other Languages

16. Generalization

17. Thought Process
From Data Formats To Languages
Structure, Constraints, Semantics
+ Syntax + IDEData Format
Language

18. Thought Process
Language Engineering
Languages
Language Reuse
Language Modularization
Language Composition
Language Engineering

19. Thought Process
Language Engineering
Languages
Language Engineering
Syntactic Diversity
Text
Tables
Math
Symbols
Graphics
Forms

20. Thought Process
Language Workbenches
Languages
Language Engineering
Syntactic Diversity
But does this really work?
Language Workbenches

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

24. Language Workbenches
Typical Features
for any
Language!

25. Language Workbenches
Typical Features
Language
Workbenches act
as the foundation
for IDEs for any
language.

26. LOBA where we are
what is missing
why

27. LOBA where we are
what is missing
why

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

33. LOBA: Why
[Motivation] Languages!
A language may be hiding
behind many of these!

34. LOBA: Why
[Motivation] Languages!
But: users don‘t want to
be programmers!

35. LOBA: Why
[Motivation] Languages!
What makes a business user
feel like a programmer???

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.

48. LOBA: Why
[Motivation] Languages!
Applications/Forms/UIs
Structure
User Guidance
Tables
Views
Languages + IDEs
Expressions
Complex Structures
Code Completion
Type Checking
Debugging
Refactoring
vs.

49. LOBA where we are
what is missing
why

50. LOBA: Where we are.
[Notation] Math (old)

51. LOBA: Where we are.
[Notation] Math (new) I

52. LOBA: Where we are.
[Notation] Math (new) II

53. LOBA: Where we are.
[Notation] Tables

54. LOBA: Where we are.
[Notation] Tables II

55. LOBA: Where we are.
[Notation] Graphical

56. LOBA: Where we are.
[Notation] Mixed Content

57. LOBA: Where we are.
[Guided Editing] Form-Like

58. LOBA: Where we are.
[Guided Editing] Form-Like

59. LOBA: Where we are.
[Guided Editing] Form-Like II

60. LOBA: Where we are.
[Guided Editing] Editor Buttons

61. LOBA: Where we are.
[Guided Editing] Code Completion

62. Business Apps
[Context Aware] Different Projections

63. Business Apps
[Context Aware] Different Projections

64. LOBA: Where we are.
[Structure] Tree Views I

65. LOBA: Where we are.
[Structure] Tree Views II

66. LOBA: Where we are.
[Context Aware] Visualization

67. LOBA: Where we are.
[Context Aware] Visualization II

68. LOBA: Where we are.
[Live Code] Error Checking

69. LOBA: Where we are.
[Live Code] Interpreted Tests

70. LOBA: Where we are.
[Live Code] Debugging

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

74. Language Workbenches
Where does App Funtionality go?
Debugging
Live Tests in IDE
Advanced Analyses
Execition via Generation

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.

76. LOBA where we are
what is missing
why

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.

82. Evaluation

83. Evaluation
Usability Guru Jakon Nielsen
10 Usability Heuristics for UI Design

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.

94. Conclusions

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!

96. THE END.
Markus Voelter
independent/itemis
voelter@acm.org
www.voelter.de
@markusvoelter
Bernd Kolb
itemis
kolb@itemis.de
www.itemis.de
@berndkolb
Jos Warmer
OpenModeling
Jos.warmer@openmodeling.nl
openmodeling.nl
Language-Oriented
Business Applications
On the way to DSLs for non-programmers