Model-based Software Engineering (02341, spring 2017) Ekkart Kindler

Transcription

1 Model-based Software Engineering (02341, spring 2017)

2 Lecture 8: Overview (cntd.) Some hints for the implementation Auxiliary datatypes and functions Helpful epnk functions Marking algorithm (OR-join: potentially arriving tokens) Hints on writing (Project Definiton / Final Report) DSL discussion revisited 2

3 Hints on writing

4 Inductive writing: Explain concepts by examples first Then extract concepts and explain in more detail Fill in more detailed concepts and explanations later Spiral form writing : Identify most important concepts (3-5): explain them first (on high level of abstraction) Idendify next most important concepts: explain first and next important concepts (in more detail),... 4

5 DSL discussion continued

6 Steps of defining a DSL 1. Define language concepts (abstract syntax): PetriNet * Object Node 1 source 1 target Arc Transition Place 2. Define graphical representation (concrete syntax): * Token Transition Place Arc Token 6

7 Steps of defining a DSL 3. Define semantics (its meaning or behaviour): a) Define runtime concepts b) Define presentation of runtime concepts c) Define logic for behaviour 7

8 Project example YAWL concepts and representation: 8

9 Project example YAWL Simulator: Runtime concepts 9

10 Status and Recapitulation: How far did we come?

11 Vision PetriNet * Object 1 source Node 1 target Transition Place Arc * Token Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %pluginname package PetriNets.impl; Bundle-SymbolicName: APetriNetEditorIn15Minutes.diagr Bundle-Version: qualifier public class PetriNetImpl extends EObjectImpl implements PetriNet { Bundle-ClassPath:. protected EList<PetriNets.Object> object; Bundle-Activator: PetriNets.diagram.part.PetriNetDiagr Bundle-Vendor: %providername protected PetriNetImpl() { Bundle-Localization: plugin super(); Export-Package: PetriNets.diagram.edit.parts, } PetriNets.diagram.part, PetriNets.diagram.providers protected EClass estaticclass() { Require-Bundle: org.eclipse.core.runtime, return PetriNetsPackage.Literals.PETRI_NET; org.eclipse.core.resources, } org.eclipse.core.expressions, org.eclipse.jface, public EList<PetriNets.Object> getobject() { org.eclipse.ui.ide, if (object == null) { org.eclipse.ui.views, object = new EObjectContainmentEList<PetriNets.Object>(Petri org.eclipse.ui.navigator, } org.eclipse.ui.navigator.resources, return object; org.eclipse.emf.ecore, } org.eclipse.emf.ecore.xmi, org.eclipse.emf.edit.ui, public NotificationChain einverseremove(internaleobject otherend, int org.eclipse.gmf.runtime.emf.core, switch (featureid) { org.eclipse.gmf.runtime.emf.commands.core, case PetriNetsPackage.PETRI_NET OBJECT: org.eclipse.gmf.runtime.emf.ui.properties, return ((InternalEList<?>)getObject()).basicRemove(otherEn org.eclipse.gmf.runtime.diagram.ui, } org.eclipse.gmf.runtime.diagram.ui.properties, return super.einverseremove(otherend, featureid, msgs); org.eclipse.gmf.runtime.diagram.ui.providers, } org.eclipse.gmf.runtime.diagram.ui.providers.ide, org.eclipse.gmf.runtime.diagram.ui.render, public Object eget(int featureid, boolean resolve, boolean coretype) { org.eclipse.gmf.runtime.diagram.ui.resources.ed switch (featureid) { org.eclipse.gmf.runtime.diagram.ui.resources.e case PetriNetsPackage.PETRI_NET OBJECT: APetriNetEditorIn15Minutes;visibility:=reexpor return getobject(); } return super.eget(featureid, resolve, coretype); Analysis Design Implementation Coding 11

12 Programming vs. SE 12

13 Vision PetriNet * Object 1 source Node 1 target Transition Place Arc * Token Manifest-Version: 1.0 Bundle-ManifestVersion: 2 Bundle-Name: %pluginname package PetriNets.impl; Bundle-SymbolicName: APetriNetEditorIn15Minutes.diagr Bundle-Version: qualifier public class PetriNetImpl extends EObjectImpl implements PetriNet { Bundle-ClassPath:. protected EList<PetriNets.Object> object; Bundle-Activator: PetriNets.diagram.part.PetriNetDiagr Bundle-Vendor: %providername protected PetriNetImpl() { Bundle-Localization: plugin super(); Export-Package: PetriNets.diagram.edit.parts, } PetriNets.diagram.part, PetriNets.diagram.providers protected EClass estaticclass() { Require-Bundle: org.eclipse.core.runtime, return PetriNetsPackage.Literals.PETRI_NET; org.eclipse.core.resources, } org.eclipse.core.expressions, org.eclipse.jface, public EList<PetriNets.Object> getobject() { org.eclipse.ui.ide, if (object == null) { org.eclipse.ui.views, object = new EObjectContainmentEList<PetriNets.Object>(Petri org.eclipse.ui.navigator, } org.eclipse.ui.navigator.resources, return object; org.eclipse.emf.ecore, } org.eclipse.emf.ecore.xmi, org.eclipse.emf.edit.ui, public NotificationChain einverseremove(internaleobject otherend, int org.eclipse.gmf.runtime.emf.core, switch (featureid) { org.eclipse.gmf.runtime.emf.commands.core, case PetriNetsPackage.PETRI_NET OBJECT: org.eclipse.gmf.runtime.emf.ui.properties, return ((InternalEList<?>)getObject()).basicRemove(otherEn org.eclipse.gmf.runtime.diagram.ui, } org.eclipse.gmf.runtime.diagram.ui.properties, return super.einverseremove(otherend, featureid, msgs); org.eclipse.gmf.runtime.diagram.ui.providers, } org.eclipse.gmf.runtime.diagram.ui.providers.ide, org.eclipse.gmf.runtime.diagram.ui.render, public Object eget(int featureid, boolean resolve, boolean coretype) { org.eclipse.gmf.runtime.diagram.ui.resources.ed switch (featureid) { org.eclipse.gmf.runtime.diagram.ui.resources.e case PetriNetsPackage.PETRI_NET OBJECT: APetriNetEditorIn15Minutes;visibility:=reexpor return getobject(); } return super.eget(featureid, resolve, coretype); Domain model from which some code can be generated Some code needs to be implemented manually 13

14 How concise are models With class diagrams (EMF/Ecore diagrams), some subtle aspects of some domains cannot be appropriately modelled Additional constraints (OCL or programmed in Java) allow us to express these subtle aspects (more or less adequately) 14

15 Automatical code generation structural parts of the software (API) infrastructure (objects are notifiers) for saving and loading object structures to files (in a default format defined by the model: XMI) default tree editors for editing object structures factories for creating objects... With additional models for graphics Fully functioning graphical editor 15

16 Framework Existing infrastructure adapters, observer, notifications, command framework, undo and redo mechanism, command framework MVC, many patterns behind the scene (we just scratched the surface yet) 16

17 Manually programming Some specific graphics for epnk programmed manually YAWL graphics Some technical classes (factory for specific graphics) needed to be programmed manually Some constraints programmed manually Code for real functionality (editor is standardfunctionality ) YAWL select actions firing YAWL transition 17

18 MBSE The goal is not to get rid of programming as such; but, to do things on the adequate level of abstraction and in a clear and consise way For some things, programming is an adequate and consise way of doing things (classical algorithms, graphical appearance) For other things, programming is not adequate and just used for technical reasons: We want to get rid of technical artifacts 18

19 Architecture by Example: epnk Applications

20 20

21 YAWL Simulator annotations 21

22 Blackboard Discussion Based on object diagram from slide 9 (and using some classes from slide 10): Scenario for starting the YAWL simulator BB Scenario for firing a YAWL transition BB 22

23 Modelling Behaviour

24 Overview Modelling behaviour on domain level Business process modelling YAWL models Activity diagrams ( UML) UML diagrams from modelling behaviour: overview xuml (Executable UML): short overview Other notations Story Patterns: by example The Event Coordination Notation (ECNO): by example 24

25 1. BPM / YAWL 25

26 What are good process models (1) Have a goal (litmus test: name / description) Have a start and an end Tasks have a good name: verb object e.g. register customer, pay bill, cancel appointment,... Possible order of execution of tasks makes sense from the domain point of view 26

27 What are good process models (2) Whatever happend in the process, it is always possible to finish the process When the process is finished, nothing is left in the process anymore and no task can be executed anymore 27

28 2. Behaviour in UML In UML, there are different concepts and diagrams that concern behaviour modelling Use case diagrams Activity diagrams Interaction diagrams Sequence diagrams Communication diagrams State machine diagrams (State Charts) Methods of classes (MOF: Operation) (in combination with OCL, the input/output relation of a method can be specified) 28

29 Activity diagrams From: OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, November 2007, p

30 Activity diagrams From: OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, November 2007, p

31 Activity diagrams From: OMG Unified Modeling Language (OMG UML), Superstructure, V2.1.2, November 2007, p

32 Sequence Diagram ignition switch rain sensor wiper control wiper turn key on rain off on 32

33 Communication Diagram ignition switch 1: on 2: off wiper rain sensor 3: rain wiper control 4: on 33

34 Sequence diagram (details) o:order item 1 product 1 item 2 product 2 :Customer getprice() getprice() getprice() Lifeline sum1 amount() Events getprice() getprice() Message total sum2 amount() getcustomerdiscount() discount 34

35 Sequence diagram (details) o:order item 1 product 1 item 2 product 2 :Customer getprice() getprice() getprice() Call (synchronous) amount() sum1 getprice() getprice() return sum2 amount() getcustomerdiscount() Selfcall total Activation discount 35

36 State machines on i off rain rd wiper control Message off w on wiper off engine off rd.dry/w.off rd.rain/w.on Initial state wiper on 36

37 Use of state machines ignition switch rain sensor wiper control One automaton for each component (plus structure) defines the complete behaviour of our wiper system. wiper wiper 37

38 rd.dry/w.off State machines i rd wiper control w wiper off Complex state engine off i.on/w.off i.off/w.off rd.rain/w.on wiper on 38

39 Behaviour in UML Use case diagrams Activity diagrams Interaction diagrams Sequence diagrams Communication diagrams State machine diagrams (State Charts) Methods of classes (in combination with OCL, the input/output relation of a method can be specified) 39

40 Behaviour in UML In general, UML behaviour models are used to analyse, design, and document a system It is hard to generate code from that automatically. 40

41 3. xuml Restricted versions of UML Domain diagram (package diagram) Class diagrams for each domain Use Case diagrams Sequence diagrams State machines (signals triggering transitions) Signals UML Action Language (ASL) for defining actions/operations on an abstract level and independent from a programming language 41

42 TBC (to be continued) 42