Model-based Software Engineering (02341) · MBSE (02341 f17), L02 16 ”Buzzwords” Model Driven...

Model-based Software Engineering

(02341, spring 2016)

Ekkart Kindler

I. Introduction

Ekkart Kindler

3 MBSE (02341 f17), L02

Programming vs. SE

Program

Programmer

Programming

Software

Software Engineer

Software Engineering

Ekkart Kindler

4 MBSE (02341 f17), L02

Modelling

Ekkart Kindler

5 MBSE (02341 f17), L02

Ekkart Kindler

6 MBSE (02341 f17), L02

Place Transition

1 source

1 target

Arc

*

PetriNet

Token

*

Node

Object

Analysis

Design

Implementation

Coding

Manifest-Version: 1.0

Bundle-ManifestVersion: 2

Bundle-Name: %pluginName

Bundle-SymbolicName: APetriNetEditorIn15Minutes.diagr

Bundle-Version: 1.0.0.qualifier

Bundle-ClassPath: .

Bundle-Activator: PetriNets.diagram.part.PetriNetDiagr

Bundle-Vendor: %providerName

Bundle-Localization: plugin

Export-Package: PetriNets.diagram.edit.parts,

PetriNets.diagram.part,

PetriNets.diagram.providers

Require-Bundle: org.eclipse.core.runtime,

org.eclipse.core.resources,

org.eclipse.core.expressions,

org.eclipse.jface,

org.eclipse.ui.ide,

org.eclipse.ui.views,

org.eclipse.ui.navigator,

org.eclipse.ui.navigator.resources,

org.eclipse.emf.ecore,

org.eclipse.emf.ecore.xmi,

org.eclipse.emf.edit.ui,

org.eclipse.gmf.runtime.emf.core,

org.eclipse.gmf.runtime.emf.commands.core,

org.eclipse.gmf.runtime.emf.ui.properties,

org.eclipse.gmf.runtime.diagram.ui,

org.eclipse.gmf.runtime.diagram.ui.properties,

org.eclipse.gmf.runtime.diagram.ui.providers,

org.eclipse.gmf.runtime.diagram.ui.providers.ide,

org.eclipse.gmf.runtime.diagram.ui.render,

org.eclipse.gmf.runtime.diagram.ui.resources.ed

org.eclipse.gmf.runtime.diagram.ui.resources.e

APetriNetEditorIn15Minutes;visibility:=reexpor

package PetriNets.impl;

public class PetriNetImpl extends EObjectImpl implements PetriNet {

protected EList<PetriNets.Object> object;

protected PetriNetImpl() {

super();

}

protected EClass eStaticClass() {

return PetriNetsPackage.Literals.PETRI_NET;

}

public EList<PetriNets.Object> getObject() {

if (object == null) {

object = new EObjectContainmentEList<PetriNets.Object>(Petri

}

return object;

}

public NotificationChain eInverseRemove(InternalEObject otherEnd, int

switch (featureID) {

case PetriNetsPackage.PETRI_NET__OBJECT:

return ((InternalEList<?>)getObject()).basicRemove(otherEn

}

return super.eInverseRemove(otherEnd, featureID, msgs);

}

public Object eGet(int featureID, boolean resolve, boolean coreType) {



return getObject();

}

return super.eGet(featureID, resolve, coreType);






Bundle-ClassPath: .










org.eclipse.jface,

org.eclipse.ui.ide,






















super();

}



}




}

return object;

}





}


}




return getObject();

}


Ekkart Kindler

7 MBSE (02341 f17), L02

Place Transition

1 source

1 target

Arc

*

PetriNet

Token

*

Node

Object

Analysis

Design

Implementation

Coding






Bundle-ClassPath: .










org.eclipse.jface,

org.eclipse.ui.ide,






















super();

}



}




}

return object;

}





}


}




return getObject();

}







Bundle-ClassPath: .










org.eclipse.jface,

org.eclipse.ui.ide,






















super();

}



}




}

return object;

}





}


}




return getObject();

}


Model (domain model,

meta -model)

Instance of model

(example)

Ekkart Kindler

8 MBSE (02341 f17), L02

Example of a Petri net

semaphor

request1

critical1

idle1

request2

critical2

idle2

Ekkart Kindler Stages

Examples

Taxonomy (done on blackboard)

Glossary

Model (developed on blackboard)

9 MBSE (02341 f17), L02

Ekkart Kindler

10 MBSE (02341 f17), L02

1 target

Model for Petri nets Meta model for Petri nets

Models (Meta Models)

Petri net model

Place Transition

1 source

Arc

*

PetriNet context Arc inv: ( self.source.oclIsKindOf(Place) and self.target.oclIsKindOf(Transition) ) or ( self.source.oclIsKindOf(Transition) and self.target.oclIsKindOf(Place) )

Token *

Node

Object

Ekkart Kindler

11 MBSE (02341 f17), L02

1 target

Don’t think models as Java

Petri net model

Place Transition

1 source

Arc

*


Token *

Node

Object

Ekkart Kindler

12 MBSE (02341 f17), L02

Syntax (abstract and concrete)

:Place

:Transition

:Arc

:Transition

:Place

:Arc

:Arc

source

target source

target

target source

:Arc source target

:Petrinet

:Token

graphical / concrete syntax

abstract syntax (as an UML object diagram)

Ekkart Kindler

13 MBSE (02341 f17), L02

Benefits of Modelling

Better understanding

Mapping of instances to XML syntax (XMI)

Automatic code generation

API for creating, deleting and modifying model

Methods for loading and saving models (in XMI)

Standard mechanisms for keeping track of changes

(observers)

Ekkart Kindler

14 MBSE (02341 f17), L02

GMF

:Place

:Transition

:Arc

:Transition

:Place

:Arc

:Arc

source

target source

target

target source

:Arc source target

:Petrinet

:Token

Place Transition

1 source

1 target

Arc

*

PetriNet

Token *

Node

Object Place

Transition

Arc

Token

generate an editor

Ekkart Kindler

15 MBSE (02341 f17), L02

Benefits of Modelling (cntd.)

Better Understanding

Mapping of instances to XML syntax (XMI)

Automatic Code Generation

API for creating, deleting and modifying model

Methods for loading and saving models (in XMI)

Standard mechanisms for keeping track of changes

(observers)

Editors and GUIs

Ekkart Kindler

16 MBSE (02341 f17), L02

”Buzzwords”

Model Driven Architecture (MDA)

OMGTM software development approach for

separating business logic from platform specific

details

using models

automatic generators (for code and other models)

Model-based Software Engineering (MBSE)

General term for making “better” use of models for

easing the software development

Ultimately: Getting rid of programming

resp. technical artefacts.

Ekkart Kindler

17 MBSE (02341 f17), L02

”Buzzwords”

DSL (Domain Specific Language): Make it easy to

develop a language for some domain (in our

example Petri nets) along with editors (graphical or

textual)

MBSE technologies can be used for developing

DSLs by using domain models (meta-models)

More on the use of the term meta and

meta-model later in this course

Ekkart Kindler

18 MBSE (02341 f17), L02

Theses

We will always have programming and programmers!

We should always teach programming!

But, software engineers should be trained in their engineering and modelling skills!

And this is where they should be at their best!

Most of the rest can be automated!

Eventually, programming will be for software engineers as assembler is today for programmers.

Ekkart Kindler 3. Modelling with a Purpose

Anologies:

Models as floor plans (see earlier slides)

Architects and construction engineers use quite

different kind of plans – driven by the puprose

They even use models (miniatures)

Models as maps

Understand the world ( domain)

Find your way round in the software

19 MBSE (02341 f17), L02

Place Transition

1 source

1 target

Arc

*

PetriNet

Token

*

Node

Object

Ekkart Kindler Maps

20 MBSE (02341 f17), L02

Ekkart Kindler Maps

Different level of abstraction and detail

Different focus

Different aspects

Different purpose

21 MBSE (02341 f17), L02

Ekkart Kindler Software vs Programming

For programs (small software), models are often not

needed, and making them might be a waste of time

For software, they are essential for building

something which works out and the different pieces

fit to each other

22 MBSE (02341 f17), L02

Ekkart Kindler Discussion

Two models: Which is better?

23 MBSE (02341 f17), L02

Place Transition

1 source

1 target

Arc

*

PetriNet

Token *

Node

Object

Always ask first:

Better for what?

Tutorial 1: Q & A / Wrap up (BBD)

II. Modelling with a Purpose

Ekkart Kindler 1. Models to which end

Blackboard Discussion (BBD):

Purpose Kind of model

26 MBSE (02341 f17), L02

Ekkart Kindler 2. Domain models

Petri net example revisited (see next two slides)

Discussion:

Should in/out (opposites of target and source) be

in domain model?

What makes it a domain model?

What is the difference to a data model or data base

schema?

27 MBSE (02341 f17), L02

Ekkart Kindler

28 MBSE (02341 f17), L02

1 target

Petri net: Domain model

Petri net model

Place Transition

1 source

Arc

*


Token *

Node

Object

Ekkart Kindler Ecore model

29 MBSE (02341 f17), L02

Ekkart Kindler Representations of model

Same model can have different representations:

Graphical / tree (as of Tutorial 1)

Java

Ecore

XML Schema (XSD)

Different representation might serve different purposes

and have a different focus!

What would the focus for XSDs, Java and Ecore be?

30 MBSE (02341 f17), L02

Ekkart Kindler Petrinet.java

/** @model */

public interface Petrinet {

/** @model opposite="petrinet" containment="true" */

List<Node> getNodes();

/** @model opposite="petrinet" containment="true" */

List<Arc> getArcs();

/** @model */

String getName();

}

31 MBSE (02341 f17), L02

Ekkart Kindler Arc.java

/** @model */

public interface Arc {

/** @model opposite="out" required="true" */

Node getSource();

/** @model opposite="in" required="true" */

Node getTarget();

/** @model opposite="arcs" transient="false" */

Petrinet getPetrinet();

}

32 MBSE (02341 f17), L02

Ekkart Kindler Node.java

/** @model abstract="true" */

public interface Node {

/** @model opposite="nodes" transient="false" */

Petrinet getPetrinet();

/** @model opposite="target" */

List<Arc> getIn();

/** @model opposite="source" */

List<Arc> getOut();

/** @model */

String getName();

}

33 MBSE (02341 f17), L02

Ekkart Kindler Transition.java

/**

* @model

*/

public interface Transition extends Node {

}

34 MBSE (02341 f17), L02

Ekkart Kindler Place.java

/**

* @model

*/

public interface Place extends Node {

/**

* @model opposite="place" containment="true“

*/

List<Token> getTokens();

}

35 MBSE (02341 f17), L02

Ekkart Kindler Token.java

/**

* @model

*/

public interface Token {

/**

* @model opposite="tokens" transient="false"

*/

Place getPlace();

}

36 MBSE (02341 f17), L02

Ekkart Kindler

/** @model */

public interface Petrinet {

/** @model opposite="petrinet" containment="true“ */

List<Node> getNodes();

/** @model opposite="petrinet" containment="true“ */

List<Arc> getArcs();

/** @model */

String getName();

}

37 MBSE (02341 f17), L02

Ekkart Kindler 3. Software Models

Petri net example (cntd.): Models for

(small part of) the generated code

framework the generated code uses

38 MBSE (02341 f17), L02

Ekkart Kindler 3.1. Eclipse: JFace

“JFace is a UI toolkit with classes for handling many

common UI programming tasks.” [https://wiki.eclipse.org/JFace]

Viewers are a core part of editors (there are different

kinds of viewers), which are generic.

Here, we discuss the TreeViewer, which is the basis

for the automatically generated tree editor for Petri

nets.

39 MBSE (02341 f17), L02

https://wiki.eclipse.org/JFace

https://wiki.eclipse.org/JFace

Ekkart Kindler TreeViewer

40 MBSE (02341 f17), L02

input TreeViewer Object

1

Assuming that the input

object (model) is a Petri

net


41 MBSE (02341 f17), L02

input TreeViewer Object

1

Root object of the tree

which is to be shown in

the TreeViewer

Shows the input as a

tree (with all the features

of a tree view like

opening and closing

sub-trees, etc)

Ekkart Kindler How???

How could the TreeViewer, which does not know

anything about Petri nets (and the classes

representing the concepts of Petri nets), know how

this tree should be shown?

42 MBSE (02341 f17), L02

:Place

:Transition

:Arc

:Transition

:Place

:Arc

:Arc

source

target source

target

target source

:Arc source target

:Petrinet

:Token

: input


MBSE (02341 f17), L02

input

TreeViewer Object

1

ITreeContentProvider

ILabelProvider

contentProvider

1

labelProvider

1 getText(Object) : String getImage(Object): Image

getChildren(Object) : List getImage(Object): Image

Provides the label and

the icon for each object

For each object, provides

the current list of

children.

43


MBSE (02341 f17), L02

input

TreeViewer Object

1

ITreeContentProvider

ILabelProvider

contentProvider

1

labelProvider

1 getText(Object) : String getImage(Object): Image

getChildren(Object) : List getImage(Object): Image

Will come from the

generated code

(ItemProviders for each

kind of object in the

model): edit code

In the tutorial, you will

change the item provider

for Arcs for changing the

labels for arcs. 44

Ekkart Kindler Similarly for Properties

45 MBSE (02341 f17), L02

:Place

:Transition

:Arc

:Transition

:Place

:Arc

:Arc

source

target source

target

target source

:Arc source target

:Petrinet

:Token

: input

IPropertySourceProvider

(not discussed here)

Ekkart Kindler 3.2 EMF: Use of TreeViewer

In EMF, this is even more complicated: using a

generic ContentProvider, which creates the

respective ItemProviders and delegates to them

46 MBSE (02341 f17), L02

Idea is discussed on

blackboard (BBD)

Ekkart Kindler 3.3 Update Viewer on Changes

In order to make sure that the viewer properly

updates, whenever changes occur, it registers itself

as listener to the respective elements (actually to

their ItemProviders).

47 MBSE (02341 f17), L02

Idea is discussed on

blackboard (BBD); more

details next time

Ekkart Kindler 1. Models to which end

Understanding the world (conceptual models,

domain models)

Understanding what the software is supposed to do

(requirements)

Understanding and finding your way round in

existing software

Outline the idea of how to realize the software

(architecture)

Overview of componenents and their interplay

Detailed design and realization of the software

48 MBSE (02341 f17), L02

Ekkart Kindler Models to which end (cntd.)

Generate parts of the software automatically

Define data representations (XML, database

schemas, ...)

Define interfaces between different parts of the

software

...

49 MBSE (02341 f17), L02

Model-based Software Engineering (02341) · MBSE (02341 f17), L02 16 ”Buzzwords” Model Driven...

Documents

Transcript of Model-based Software Engineering (02341) · MBSE (02341 f17), L02 16 ”Buzzwords” Model Driven...