Language-Oriented Business Applications

1,394 views

Published on

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.

Published in: Software
0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,394
On SlideShare
0
From Embeds
0
Number of Embeds
57
Actions
Shares
0
Downloads
24
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

Language-Oriented Business Applications

  1. 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. 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. 3. About mbeddr
  4. 4. About mbeddr Language Engineering Embedded Software An extensible collection of integrated languages for embedded software engineering.
  5. 5. About mbeddr Language Engineering Embedded Software An IDE + Debugger for all of them
  6. 6. About mbeddr Language Engineering Embedded Software Open Source Eclipse Public License http://mbeddr.com http://www.eclipse.org/proposals/technology.mbeddr/
  7. 7. mbeddr Demo I C & Extensions
  8. 8. JetBrains MPS
  9. 9. About mbeddr Built on JetBrains MPS A Language Workbench
  10. 10. About mbeddr Built on JetBrains MPS Open Source Apache 2.0 http://jetbrains.com/mps
  11. 11. About MPS Rich Set of Language Aspects + Refactorings, Find Usages, Syntax Coloring, Debugging, ...
  12. 12. About MPS Projectional Editing Parsing Projection
  13. 13. About MPS Notational Flexibility Regular Code/Text Mathematical Tables Graphical
  14. 14. About MPS Language Composition L2 L1 Separate Files In One File Type System Transformation Constraints Type System Transformation Constraints Syntax Editor/IDE
  15. 15. mbeddr Demo II Other Languages
  16. 16. Generalization
  17. 17. Thought Process From Data Formats To Languages Structure, Constraints, Semantics + Syntax + IDEData Format Language
  18. 18. Thought Process Language Engineering Languages Language Reuse Language Modularization Language Composition Language Engineering
  19. 19. Thought Process Language Engineering Languages Language Engineering Syntactic Diversity Text Tables Math Symbols Graphics Forms
  20. 20. Thought Process Language Workbenches Languages Language Engineering Syntactic Diversity But does this really work? Language Workbenches
  21. 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. 22. Generic Tools, Specific Languages Ingredients Languages Language Engineering Syntactic Diversity Language WorkbenchesGeneric Tools Specific Languages support
  23. 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. 24. Language Workbenches Typical Features for any Language!
  25. 25. Language Workbenches Typical Features Language Workbenches act as the foundation for IDEs for any language.
  26. 26. LOBA where we are what is missing why
  27. 27. LOBA where we are what is missing why
  28. 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. 29. LOBA: Why For which kinds of Systems? Language Workbenches act as the foundation for IDEs for any language.
  30. 30. LOBA: Why For which kinds of Systems? Language Workbenches act as the foundation for IDEs for (m)any applications.
  31. 31. LOBA: Why For which kinds of Systems? many applications? Structured or Formalizable Mathematical Data-Oriented Language-y
  32. 32. LOBA: Why For which kinds of Systems? many applications? Data Models Pricing Calculations Financial Calculations Contracts Business Rules Highly Structured Requirements
  33. 33. LOBA: Why [Motivation] Languages! A language may be hiding behind many of these!
  34. 34. LOBA: Why [Motivation] Languages! But: users don‘t want to be programmers!
  35. 35. LOBA: Why [Motivation] Languages! What makes a business user feel like a programmer???
  36. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 47. LOBA: IT versus Business Summing Up Combine the best of Applications/Forms/UIs and Languages and IDEs.
  48. 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. 49. LOBA where we are what is missing why
  50. 50. LOBA: Where we are. [Notation] Math (old)
  51. 51. LOBA: Where we are. [Notation] Math (new) I
  52. 52. LOBA: Where we are. [Notation] Math (new) II
  53. 53. LOBA: Where we are. [Notation] Tables
  54. 54. LOBA: Where we are. [Notation] Tables II
  55. 55. LOBA: Where we are. [Notation] Graphical
  56. 56. LOBA: Where we are. [Notation] Mixed Content
  57. 57. LOBA: Where we are. [Guided Editing] Form-Like
  58. 58. LOBA: Where we are. [Guided Editing] Form-Like
  59. 59. LOBA: Where we are. [Guided Editing] Form-Like II
  60. 60. LOBA: Where we are. [Guided Editing] Editor Buttons
  61. 61. LOBA: Where we are. [Guided Editing] Code Completion
  62. 62. Business Apps [Context Aware] Different Projections
  63. 63. Business Apps [Context Aware] Different Projections
  64. 64. LOBA: Where we are. [Structure] Tree Views I
  65. 65. LOBA: Where we are. [Structure] Tree Views II
  66. 66. LOBA: Where we are. [Context Aware] Visualization
  67. 67. LOBA: Where we are. [Context Aware] Visualization II
  68. 68. LOBA: Where we are. [Live Code] Error Checking
  69. 69. LOBA: Where we are. [Live Code] Interpreted Tests
  70. 70. LOBA: Where we are. [Live Code] Debugging
  71. 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. 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. 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. 74. Language Workbenches Where does App Funtionality go? Debugging Live Tests in IDE Advanced Analyses Execition via Generation
  75. 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. 76. LOBA where we are what is missing why
  77. 77. LOBA: What is missing/Challenges Apparent Tool Complexity Too many (too big) menus and buttons
  78. 78. LOBA: What is missing/Challenges Need for Simplified Version Control Too many options. Locking? Realtime?
  79. 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. 80. LOBA: What is missing/Challenges Training Users may not be used to this approach. Training is important. Productivity more useful than Learnability.
  81. 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. 82. Evaluation
  83. 83. Evaluation Usability Guru Jakon Nielsen 10 Usability Heuristics for UI Design
  84. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 94. Conclusions
  95. 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. 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

×