SiriusCon 2018 - Talk by Arthur Daussy, Obeo In a banking environment (i-BP, a subsidiary of Groupe BPCE the 2nd largest banking group in France), EEF has been extensivly used during a 3-year migration project from Rational Rose UML to a EMF- and Sirius-based modeling workbench. In this talk, we will see how a user-friendly editing framework tackles the risk of ergonomy and product adoption. EEF substantially increases the productivity of developpers, by enhancing the user-experience and by seamlessly integrating domain constraints (e.g. read only, hidden properties). We will also address how the specifier of the odesign handled the properties specification in the context of a large metamodel (310 concepts, ~850 features) with multiple inheritances (290 concepts inheriting at least one feature) and how the specifier used model generation/transformation technologies to assist him/her. Different best practices on how to reuse and integrate existing business rules into the properties view to enhance the user experience, will also be discussed.

1. SIRIUS PROPERTIES VIEW
EXTENSIVE USE OF CUSTOM
PROPERTIES VIEWS IN BANKING DSL
WORKBENCH

2. PRESENTATION
i-BP & Obeo - Arthur Daussy
 Arthur Daussy <arthur.daussy@obeo.fr>
 Software Engineer @Obeo
 Worked at i-BP for 3.5 years

3. SUMMARY
Context
User perspective
Technical perspective
Conclusion
i-BP & Obeo - Arthur Daussy

4. HISTORY
i-BP & Obeo - Arthur Daussy
 Modelling of the Information System of the « Banque populaire » agencies and web site.
 With MDA, generates:
 Skeleton and data structure for back end
 90% of the front end (Dialog, State machine, etc.).
 The legacy tool was initiated in 2001 – 2002
 Project of this talk
 Migrating from « Rational Rose / UML 1.0 + Visual Basic Extensions » to « Sirius + DSL + Java»

5. VOLUMES
i-BP & Obeo - Arthur Daussy
 Before
 Size in byte: 1,1Go
 Numbers of components: > 1600
 Number of semantic elements: 1.5 M
 System too large for Rational Rose (memory limit) : Edited by chunk
 After
 Size in byte: 400 Mo
 Loading time improved : From 7 min to 20s
 Load entire system for coherence checks

6. A COMPLEX LANGUAGE
i-BP & Obeo - Arthur Daussy
 Epackages: 5
 EClassifiers: 373
 Complex inheritance hierarchy
 Some EClass has 20 super types with several diamond patterns
 Number of EAttributes: 342
 Numbers of EReferences: 405
 One EClass has 42 EStructural features
 An important number of business rules to handle:
 Specific scopes for each references
 Validation
 Creation in cascade

7. 7i-BP & Obeo - Arthur Daussy
USER PERSPECTIVE

8. BASIC VIEW IS NOT USER FRIENDLY
i-BP & Obeo - Arthur Daussy
 Why Use Sirius Properties ? EMF provides this by default ...
 Obvious, right ? But that's not all…
Major risk of
User rejection

9. TACKLES THE RISK OF ERGONOMY AND PRODUCT ADOPTION
i-BP & Obeo - Arthur Daussy
 90% of User's interactions was through custom wizards
 However keep improving user experience: Wizard -> Property view.
Legacy
wizard
Expected

10. HOW TO DISPLAY NUMEROUS FEATURES
i-BP & Obeo - Arthur Daussy
 Filter feature
 Split by category

11. MAKE DYNAMIC
i-BP & Obeo - Arthur Daussy
 Changes of elements in model notifies user of revelant fields.

12. VALIDATION
i-BP & Obeo - Arthur Daussy
 Validation
 Custom validation rules in the VSM
 Use pure EMF validation: Create dynamic

13. SCOPING
i-BP & Obeo - Arthur Daussy
 Scoping rules

14. COLLABORATIVE WORKFLOW
i-BP & Obeo - Arthur Daussy
 100 Developers working in 1600 components in parallel
 Set up collaborative workflow: Mixed optimistic and pessimistic approach using « Git + EMF
Compare »
 Still need read-only elements. Simple with Sirius extension:
 org.eclipse.sirius.ecore.extender.PermissionProvider

15. HELP
i-BP & Obeo - Arthur Daussy
 Provide on topic integrated help for each feature using « Help expression »

16. 16I-BP & Obeo - Arthur Daussy
SPECIFIER PERSPECTIVE

17. VERY FLEXIBLE
i-BP & Obeo - Arthur Daussy
 For quickly designed editor, Sirius wizard does an amazing job but…
 Legacy business rules complexity and ergonomy continuity required us to customize
everything…
 So we did…
 Easily provide custom widget using a well-documented extension point
 org.eclipse.eef.ide.ui.eefLifecycleManagerProvider
 Implements our own wizards for scoping and reference selection
 Implements our own tool for navigation (hyperlink style)
 And many more

18. ADAPTABLE
i-BP & Obeo - Arthur Daussy
 Editing Sirius properties have the same benefits as Editing Sirius representations
 Live reloading of properties/wizards when the VSM is changed
 Perfect for workshop with users
 Changing UI can even be performed during Sprint demo
 Perfect when working in really short sprints with a lot feedback from key users
 Continuity: Easy to update Sirius/Sirius properties even to major version
 Done one or two major Sirius/Sirius property update during the project at no cost

19. ARCHITECTURE YOUR SOLUTION GLOBALLY THEN FOCUS ON DETAIL
i-BP & Obeo - Arthur Daussy
 Create custom generic service for each identified feature:
 One service for navigation
 aql:self.navigate() => Display the result in our custom « model explorer view »
 One service for validation
 aql:self.validate() => Run default EMF Validation framework
 One service for reference selection/scope
 aql:self.getCandidatesTree(‘referenceName’) => Displays candidates using a Tree
 aql:self.getCandidatesList(‘referenceName’) => Display candidates using a List
 One service for label
 Aql:self.getFeatureLabel(‘featureName’) => Return the label to use for this reference
 Aql:self.getObjectLabel () => Return the label of the object
 One service for modification
 aql:self.put(‘featureName’, value)
 …

20. TEST EVERYTHING
i-BP & Obeo - Arthur Daussy
 Use java service => Easy to test
 To speed up your test writing look at BOEM
 Test services call
 Creation of a custom tool to test service call in the VSM
 Ex: aql:self.getFeatureLabel(‘featureName’)
 We know what self is so we can check if featureName is a valid feature
(Based on some work done on UML Designer)
 Test coverage
 Currently more than 7000 tests for the VSM and services

21. BENEFITS: TESTABLE
i-BP & Obeo - Arthur Daussy
Testabable

22. VSM ARCHITECTURE
i-BP & Obeo - Arthur Daussy
 Big and unstable language=> Need a tool to initiate and update the VSM
 Simple it is just an EMF Model
 First part : Definition
 Generate a group of each Eclass and an widget for each feature using our custom services
 Second part : Implementation
 Generate a page and a group of each non-abstract Eclass
 For all features (even inherited) create a widget that extends the widget from the definition part

23. VSM ARCHITECTURE
i-BP & Obeo - Arthur Daussy
 Customization for leaf elements in the « implementation » part
 Hide, Conditional display, Conditional style
 Customization for all elements are done in the « definition part »
 Benefits
 Order: Each feature is classified by its owning EClass
 Use efficiently inheritance mechanisms
 Drawbacks
 Big VSM ( but in our use case Sirius scaled very well)

24. i-BP & Obeo - Arthur Daussy

25. EXPERIMENTED DRAWBACKS
i-BP & Obeo - Arthur Daussy
 VSM does not use ids…
 Make it really hard to work in parallel (with Git + EMF Compare)
 Adding dynamically widgets is quite difficult at the moment
 https://bugs.eclipse.org/bugs/show_bug.cgi?id=506988
 Could not find some precious API in the VSM when creating custom tools
 getContextType when writing non-regression tests

26. CONCLUSION
i-BP & Obeo - Arthur Daussy
 Sirius properties
 are very, very flexible
 scale at will
 Can be used even without Sirius (see EEF project)
 Implementation of the modeler and properties took less than 10% of the time.
Most effort was spent on:
 Handling legacy
 Implementing a proper collaborative tooling

27. FEEL FREE TO ASK ME ANY QUESTION
THANK YOU FOR YOUR ATTENTION