1. Example-Driven Modeling Using Michał Antkiewicz, Kacper Bąk, Krzysztof Czarnecki, Zinovy Diskin, Dina Zayan 1, and Andrzej Wąsowski 2 mantkiew@gsd.uwaterloo.ca 1 University of Waterloo 2 IT University of Copenhagen MDEBE, MODELS, Miami, Sep. 29, 2013

2. Domain Knowledge Transfer Alice (SME)Bob (BA) o Domain novice Domain expert o Novice modeler examples Modeling expert abstractions Domain Model 2

3. Example-Driven Modeling [1] “An approach to systematically using explicit examples for eliciting, modeling, verifying, and validating complex domain knowledge” Examples + Abstractions Model = [1] Bąk et al., Example-Driven Modeling. Model = Abstractions + Examples, NIER, ICSE'13Bąk et al., Example-Driven Modeling. Model = Abstractions + Examples, NIER, ICSE'13 3

4. Why Apply Example-Driven Modeling? H1: Constructing models with the aid of explicit examples improves the quality of models. H2: Augmenting models with explicit examples improves model comprehension among various stakeholders [2]. 4 [2] Zayan, Antkiewicz, Czarnecki, Effects of Using Examples on Structural Model Comprehension (submitted)Zayan, Antkiewicz, Czarnecki, Effects of Using Examples on Structural Model Comprehension (submitted)

5. H3: Begin with examples or abstractions; switch H4: Tools validate abstractions wrt. examples H5: Variety of examples H6: Positive and negative examples How to do Example-Driven Modeling? 5

6. Languages? Methods? Tools? We present a vision of how EDM should be done in a scenario, and how it can be supported by a language and a tool 6

7. class feature reference class feature reference http://clafer.org http://clafer.org Lightweight structural modeling language – One construct (clafer)/many roles – Feature and configuration modeling – Meta- and (partial) instance modeling Yet powerful – First-order predicate/relational logic – Constraint language inspired by Alloy 7

8. Instance Generator Reasoner for Clafer – Finite-scope analysis – Model consistent  All correct instantiations – Model inconsistent  UnSAT Core + a near-miss instance Clafer Tools Binary Distributions [3] 8 [3] http://gsd.uwaterloo.ca/clafer-tools-binary-distributionshttp://gsd.uwaterloo.ca/clafer-tools-binary-distributions

9. A Domain Knowledge Elicitation Scenario Alice (SME)Bob (BA) 9

10. Part 1: Examples only 10

11. June Steven 1 midYearReview month -> June chair -> Steven room -> C participant 1..* onlineParticipant + C whiteboard audioConferencing 11 Our members often book rooms for meetings. Give me an example of a room booking, please. We have a mid-year review meeting in June. It is organized by Steven, a chair, and is held in the meeting room C that provides a whiteboard and audioconferencing equipment to include online participants. June Steven midYearReview month -> June chair -> Steven room -> C participant$1 participant$2 onlineParticipant$1 C whiteboard audioConferencing ClaferIG

12. 12 Another example is an on-demand meeting organized within work hours. Joanna, a team-leader, sometimes meets other team members in room D. They use a whiteboard and have no online participants. Joanna ondemandMeeting chair -> Joanna participant + onlineParticipant 0 room -> D D whiteboard

13. 13 No, there are two chairs, but a meeting must have exactly one chair. Also, it is our policy that rooms cannot be booked for meetings with online participants only. The maximum number of online participants supported by our system is 20. Finally, one cannot have a meeting with online participants without audio conferencing equipment! Al John aMeeting chair -> Al, John participant 0 onlineParticipant 25 room -> E E whiteboard Is this example valid?

14. 14 There's no chair, which is required. I am also unsure if we have any rooms without a whiteboard. Tom Ed aMeeting participant -> Tom onlineParticipant -> Ed room -> F F audioConferencing Is this example valid?

15. Part 1: Summary Examples helped ground the discussion, elicit the missing constraints, and uncover tacit knowledge 15

16. Part 2: Abstraction Inference 16

17. abstract Member abstract Room abstract Meeting June Steven : Member midYearReview : Meeting month -> June chair -> Steven room -> C participant -> Member + onlineParticipant -> Member 1..20 C : Room whiteboard audioConferencing Joanna : Member ondemandMeeting : Meeting chair -> Joanna room -> D participant -> Member + onlineParticipant -> Member 0 D : Room whiteboard 17 Let’s extract the commonality to the abstractions.

18. abstract Member abstract Room whiteboard ? audioConferencing ? abstract Meeting chair -> Member room -> Room participant -> Member + onlineParticipant -> Member 0..20 [ some onlineParticipant => some room.audioConferencing ] June Steven : Member 18 C : Room whiteboard 1 audioConferencing midYearReview : Meeting month -> June chair -> Steven room -> C onlineParticipant -> Member 1..20 Joanna : Member D : Room whiteboard audioConferencing 0 ondemandMeeting : Meeting chair -> Member = Joanna room -> D onlineParticipant -> Member 0 redefinition

19. Part 2: Summary The abstractions look the same as the examples thanks to redefinition [4][5]. The abstractions can capture more general constraints than examples. 19 [4] Bąk et al. Partial Instances via Subclassing, SLE’13Partial Instances via Subclassing [5] Bąk et al. Unifying class and feature modeling (submitted)

20. Part 3: Example Derivation 20

21. 21 aMember : Member 2..5 aMeeting : Meeting [ some onlineParticipant ] aRoom : Room So far, our abstractions look quite good. Let’s automatically derive a few examples. Are they valid?

22. aMember$1 : Member aMember$2 : Member aMember$3 : Member aMeeting : Meeting chair -> aMember$3 room -> aRoom participant -> aMember$3 onlineParticipant$1 -> aMember$3 onlineParticipant$2 -> aMember$2 onlineParticipant$3 -> aMember$1 aRoom : Room audioConferencing 22 aMember$1 : Member aMember$2 : Member aMeeting : Meeting chair -> aMember$2 room -> aRoom participant$1 -> aMember$1 participant$2 -> aMember$2 onlineParticipant -> aMember$2 aRoom : Room whiteboard audioConferencing No, they are invalid! A chair cannot be a participant. Also, no member can participate both on-site and on-line. ClaferIG

23. abstract Meeting chair -> Member [ chair not in participant.ref ] [ chair not in onlineParticipant.ref ] room -> Room participant -> Member + onlineParticipant -> Member 0..20 [ no participant.ref & onlineParticipant.ref ] [ some onlineParticipant => some room.audioConferencing ] 23 Then we need to add the missing constraints.

24. 24 aMember$1 : Member aMember$2 : Member aMember$3 : Member aMember$4 : Member aMember$5 : Member aMeeting : Meeting chair -> aMember$1 room -> aRoom participant -> aMember$5 onlineParticipant$1 -> aMember$4 onlineParticipant$2 -> aMember$3 onlineParticipant$3 -> aMember$2 aRoom : Room audioConferencing aMember$1 : Member aMember$2 : Member aMember$3 : Member aMember$4 : Member aMeeting : Meeting chair -> aMember$1 room -> aRoom participant$1 -> aMember$4 participant$2 -> aMember$3 onlineParticipant -> aMember$2 aRoom : Room whiteboard audioConferencing These examples are valid! ClaferIG

25. Part 3: Summary Automatic example derivation helped uncover missing constraints, extend and subsequently validate the model. 25

26. Discussion: Clafer & The Hypotheses of EDM 26

27. Summary A vision for doing EDM Applied Clafer & ClaferIG in a scenario – Abstraction inference – Example derivation – Abstractions checking Demonstrated supporting language features 27

28. Conclusions (i) Variety of examples – Partial examples Focus on an area – Positive examples Correct scenarios – Near-miss negative examples Constraint violations 28

29. Conclusions (ii) Language design to support EDM – Single modeling concept: clafer – Unified syntax for examples and abstractions – Key mechanism: redefinition – Partial examples – Partial typing – Specialization – Extension 29

30. Open Questions Cost/benefit ratio of EDM? – Study industrial use What type of examples? How to collect them? How many are needed? How diverse are needed? How to infer abstractions from examples? How to support co-evolution? 30

31. Example-Driven Modeling Using Thank You! 31