Language-Oriented Business Applications

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

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

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

About mbeddr
An IDE + Debugger for all of them

About mbeddr
Open Source
Eclipse Public License
http://mbeddr.com
http://www.eclipse.org/proposals/technology.mbeddr/

About mbeddr
Built on JetBrains MPS
A Language Workbench

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

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

About MPS
Projectional Editing
Parsing Projection

About MPS
Notational Flexibility
Regular Code/Text Mathematical
Tables Graphical

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

mbeddr Demo II
Other Languages

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

Thought Process
Language Engineering
Languages
Language Reuse
Language Modularization
Language Composition

Thought Process
Languages
Syntactic Diversity
Text
Tables
Math
Symbols
Graphics
Forms

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

Generic Tools, Specific Languages
Ingredients
Languages
Syntactic Diversity
Language WorkbenchesGeneric Tools
Specific
Languages
(we don‘t have to reimplement
editors and synchronizers)

Generic Tools, Specific Languages
Ingredients
Languages
Syntactic Diversity
Language WorkbenchesGeneric Tools
Specific
Languages
support

Typical Features
Goto Definition/Find Usages
Error Markup/Quick Fixes
Syntax Highlighting
Code Completion
Search/Replace
Refactoring
Debugging
Reporting
Visualization
Version Control

Typical Features
for any
Language!

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

LOBA where we are
what is missing
why

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

LOBA: Why
For which kinds of Systems?
Language
Workbenches act as
the foundation for
IDEs for any
language.

LOBA: Why
Language
Workbenches act as
the foundation for
IDEs for (m)any
applications.

LOBA: Why
many applications?
Structured or Formalizable
Mathematical
Data-Oriented
Language-y

LOBA: Why
many applications?
Data Models
Pricing Calculations
Financial Calculations
Contracts
Business Rules
Highly Structured Requirements

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

LOBA: Why
But: users don‘t want to
be programmers!

LOBA: Why
What makes a business user
feel like a programmer???

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.

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.

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 !

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.

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!

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 !

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?

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 ?

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

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.

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)

Summing Up
Combine the best of
Applications/Forms/UIs
and
Languages and IDEs.

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

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

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

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

LOBA: Where we are.
[Notation] Tables

LOBA: Where we are.
[Notation] Tables II

LOBA: Where we are.
[Notation] Graphical

LOBA: Where we are.
[Notation] Mixed Content

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

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

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

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

Business Apps
[Context Aware] Different Projections

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

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

LOBA: Where we are.
[Context Aware] Visualization

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

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

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

LOBA: Where we are.
[Live Code] Debugging

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

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

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.

LOBA: What is missing/Challenges
Apparent Tool Complexity
Too many (too big)
menus and buttons

Need for Simplified Version Control
Too many options.
Locking?
Realtime?

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

Training
Users may not be used to this approach.
Training is important.
Productivity more useful than Learnability.

SE Best Practices
Modularity, Reuse, Injeritance, ...
Users may not know about these
things, but they may still be necessary
for efficiency reasons.

Evaluation
Usability Guru Jakon Nielsen
10 Usability Heuristics for UI Design

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

Evaluation
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“

Evaluation
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

Evaluation
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

Evaluation
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

Evaluation
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

Evaluation
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

Evaluation
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.

Evaluation
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

Evaluation
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.

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!

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

Language-Oriented Business Applications

More Related Content

What's hot (20)

Similar to Language-Oriented Business Applications (20)

More from Markus Voelter (19)

Recently uploaded (20)

Language-Oriented Business Applications