Motivation: Motivation: Programming By Example Programming By - - PDF document

▶
motivation motivation programming by example programming
SMART_READER_LITE
LIVE PREVIEW

Motivation: Motivation: Programming By Example Programming By - - PDF document

Mar 08, 2024 582 likes •1.07k views

Foundations and Applications of Graph Foundations and Applications of Graph Transformation Transformation An introduction from a software engineering perspective An introduction from a software engineering perspective Luciano Baresi Luciano

slide-1
SLIDE 1

Foundations and Applications of Graph Foundations and Applications of Graph Transformation Transformation

An introduction from a software engineering perspective An introduction from a software engineering perspective

Luciano Baresi Luciano Baresi Politecnico di Milano Politecnico di Milano Reiko Heckel Reiko Heckel University of Paderborn University of Paderborn

Politecnico Politecnico di Milano di Milano Universität Universität Paderborn Paderborn

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

2 2

Motivation: Motivation: Programming By Example Programming By Example

StageCast StageCast ( (www.stagecast.com www.stagecast.com): a visual programming ): a visual programming environment for kids (from 8 years on), based on environment for kids (from 8 years on), based on

  • behavioural rules associated to graphical objects

behavioural rules associated to graphical objects

  • visual pattern matching

visual pattern matching

  • simple internal control structures (priority, sequence, non

simple internal control structures (priority, sequence, non-

  • determinism, ...)

determinism, ...)

  • external

external keybord keybord control control

  • Rule

Rule-

  • based behaviour modelling is a natural and

based behaviour modelling is a natural and intuitive paradigm! intuitive paradigm! Example: Example: A simple A simple PacMan PacMan game; concrete ( game; concrete (StageCast StageCast) )

  • vs. abstract (graph
  • vs. abstract (graph-
  • based) presentation.

based) presentation.

slide-2
SLIDE 2
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

3 3 Field

States of the States of the PacMan PacMan Game: Game: Graph Graph-

  • Based Presentation

Based Presentation

:Ghost :Field :Field :Field :Field :Field :Field :PacMan marbles=3 PacMan marbles:int Ghost Marble

typing typing instance graph (represents a single state; abstracts from spatial layout) type graph (specifies legal instance graphs state space)

:Marble

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

4 4

Rules of the Rules of the PacMan PacMan Game: Game: Graph Graph-

  • Based Presentation

Based Presentation

f1:Field f2:Field pm:PacMan f1:Field f2:Field pm:PacMan

movePM

g:Ghost f1:Field f2:Field :PacMan f1:Field f2:Field g:Ghost

kill

pm:PacMan marbles=m f1:Field f2:Field :Marble f1:Field f2:Field pm:PacMan marbles=m+1

collect

slide-3
SLIDE 3
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

5 5

Outline Outline

  • Motivations

Motivations

  • Foundations

Foundations

  • Sample

Sample applications applications

  • Tool

Tool support support

  • Conclusions

Conclusions

1 1-

  • Motivations

Motivations

Why you are here. Why you are here.

slide-4
SLIDE 4
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

7 7

Visual Visual Modeling Modeling Techniques Techniques

p3 p2 t2 t0 p1 t3 t1

Petri Petri nets nets

Media Media Continuous Continuous Media Media Discrete Discrete Media Media Audio Audio Video Video Animation Animation Graphics Graphics Image Image Text Text

Class Diagrams (UML)

DB_FF S1 R Q1 OFF_TMR TON IN PT Q ET OUT DB_TIME IN IN PT Q ET TON ON_TMR SR

Function Block Diagrams Structured Structured Analysis Analysis

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

8 8

Separation of Concerns Separation of Concerns

  • Complexity requires abstractions. Models

Complexity requires abstractions. Models allow to focus separately on: allow to focus separately on:

  • System parts

System parts

  • class, component, subsystem

class, component, subsystem

  • aspects

aspects

  • data, function, distribution, security

data, function, distribution, security

  • user views

user views

  • clerk, customer, system administrator

clerk, customer, system administrator

  • abstraction levels

abstraction levels

  • requirements, design, …

requirements, design, …

  • Black

Black-

  • vs. white
  • vs. white-
  • box

box

  • Development processes

Development processes

  • human

human-

  • oriented (
  • riented (

visual) visual)

  • incomplete and redundant

incomplete and redundant

Problem domain Implementation Model

slide-5
SLIDE 5
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

9 9

Integration and Consistency Integration and Consistency

  • Req. A

Viewpoint A

  • Req. B

Viewpoint B ensure consistency

Model A Model B

capture integrate & transform

System

Make sure there is an implementation satisfying all requirements !

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

10 10

What do we need? What do we need?

  • Concepts

Concepts, , theory theory and and tools tools like like for for textual textual programming programming languages languages

  • syntax

syntax

  • semantics

semantics

  • denotational

denotational

  • perationa
  • perationa
  • transformation

transformation / / refinement refinement

  • verification

verification

  • …

…

  • GT at two levels

GT at two levels

  • rule

rule-

  • based behaviour

based behaviour modelling modelling

  • meta modelling

meta modelling

Semantic domain/ Programming language Semantic domain/ Semantic domain/ Programming language Programming language Concrete syntax Concrete Concrete syntax syntax Abstract syntax Abstract syntax Abstract syntax

layout scanning and parsing denotational semantics semantic feedback

  • perational

semantics

slide-6
SLIDE 6

2 2-

  • Foundations of

Foundations of Graph Transformation Graph Transformation

How it works. How it works.

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

12 12

Outline Outline

  • Roots and Sources

Roots and Sources

  • Where it all came from and who invented it.

Where it all came from and who invented it.

  • A Basic Formalism

A Basic Formalism

  • Light

Light-

  • weight presentation of a categorical approach.

weight presentation of a categorical approach.

  • Variations and Extensions

Variations and Extensions

  • Syntactic and semantic alternatives, and advanced features.

Syntactic and semantic alternatives, and advanced features.

  • Relation with Classic Rewriting Techniques

Relation with Classic Rewriting Techniques

  • Inspiration for application and theory.

Inspiration for application and theory.

slide-7
SLIDE 7
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

13 13

Roots and Sources Roots and Sources

Chomsky Grammars Term Rewriting Petri Nets Graph Transformation and Graph Grammars (Web grammars: Pfaltz, Rosenfeld 68; Montanari 69) (Grammars for partial orders: Schneider 70) (λ-graph reduction: Wadsworth 71)

Node label-controlled graph grammars [NLC] Monadic 2nd Order Logic of Graphs [MSO] PROgrammed Graph REwriting Systems [PROGRES] Algebraic double- pushout approach [DPO]

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

14 14

A Basic Approach: A Basic Approach: Typed Graphs Typed Graphs

  • Graphs as algebraic structures

Graphs as algebraic structures

G = (V, E, G = (V, E, src src, tar) , tar) with with src src, tar: E , tar: E V V

  • Graph homomorphism

Graph homomorphism as pair of mappings as pair of mappings

h = ( h = (h hV

V : V

: V1

1

V V1

1,

, h hE

E : E

: E1

1

E E2

2) : G

) : G1

1

G G2

2

preserving the graph structure preserving the graph structure

  • Typed graphs

Typed graphs (cf. PacMan example)

  • fixed type graph

fixed type graph TG TG

  • instance graphs

instance graphs (G, g : G (G, g : G TG) TG) typed over typed over TG TG

  • UML

UML-

  • like notation

like notation x : t x : t for for x x in in G G with with g(x) = t g(x) = t

slide-8
SLIDE 8
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

15 15

Rules Rules

p: L R with L ∩ R well-defined, in different presentations

like above (cf. PacMan example) with L ∩ R explicit [DPO]: L K R with L, R integrated [Fujaba]: L ∪ R and marking

L - R {destroyed} R - L {new}

f1:Field f2:Field pm:PacMan {destroyed} {new}

movePM:

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

16 16

Transformation: Transformation: Operational Intuition Operational Intuition

1. 1.

select rule select rule p : L p : L R R ; occurrence ; occurrence o

  • L

L : L

: L G G

2. 2.

remove from remove from G G the the occurrence of

  • ccurrence of L

L \ \ R R

3. 3.

add to result an occurrence of add to result an occurrence of R R \ \ L L L R

  • L
  • R

f1:Field f2:Field pm:PacMan f1:Field f2:Field pm:PacMan

p

f1:Field f2:Field pm:PacMan marbles=3 m:Marble f1:Field f2:Field pm:PacMan marbles=3 m:Marble

G H

slide-9
SLIDE 9
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

17 17

Transformation: Transformation: Declarative Formalization Declarative Formalization

Transformation Transformation G G p(o)

p(o) H

H with with p: L p: L R R

  • ccurrence
  • ccurrence o: L
  • : L ∪

∪ R R G G ∪ ∪ H H

  • (L
  • (L \

\ R) = G R) = G \ \ H H and and o(R

  • (R \

\ L) = H L) = H \ \ G G

That is, a conservative approach: That is, a conservative approach:

  • don

don‘ ‘t delete if this causes t delete if this causes „ „dangling edges dangling edges“ “

  • invertible transformations, no side

invertible transformations, no side-

  • effects

effects

E.g.: E.g.: violation of violation of dangling edge dangling edge condition [DPO] condition [DPO]

a:A a:A :B

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

18 18

Variants and Extensions: Variants and Extensions: Graphs Graphs

Graphs as relational structures: G = (V, E) with E ⊆ V × V

  • no parallel edges; special case of algebraic variant

Undirected graphs

  • directed graphs with symmetric edges

Hyper graphs: edges have lists of source (and target) vertices

  • encoding as bipartite graphs

Labelled graphs: Vertices and edges labelled over an alphabet L:

  • G = (V, E , lv) with E ⊆ V × L × V ; lv : V L

resp.

  • G = (V, E, src, tar, lv, le) with ... ; lv : V L ; le : E L

Attributed grahps: labelled over an abstract data type, e.g. type level: instance level:

pm:PacMan marbles = 3 PacMan marbles : int

slide-10
SLIDE 10
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

19 19 :Field :Field

Variants and Extensions: Variants and Extensions: Rules and Transformations Rules and Transformations

  • context

context-

  • free rules: one

free rules: one vertice vertice or edge in

  • r edge in L

L

  • dealing with unknown context

dealing with unknown context

  • node

node-

  • label controlled embedding and set

label controlled embedding and set-

  • nodes

nodes [NLC, PROGRES] [NLC, PROGRES]

  • explicit (negative) context conditions

explicit (negative) context conditions (turns f1 into a trap by reversing all outgoing edges (turns f1 into a trap by reversing all outgoing edges to Field vertices, but only if there is no Ghost) to Field vertices, but only if there is no Ghost)

f1:Field :Field f1:Field :Field :Ghost

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

20 20

Chomsky Grammars: Chomsky Grammars: Rewriting of Strings Rewriting of Strings

Production Production A A aAb aAb as (context as (context-

  • free) graph grammar

free) graph grammar production production Theory of graph grammars as formal language theory Theory of graph grammars as formal language theory for more for more-

  • dimensional structures

dimensional structures

  • hierarchies of language classes and grammars

hierarchies of language classes and grammars

  • decidability and complexity results

decidability and complexity results

  • parsing algorithms

parsing algorithms

  • L

L-

  • system

system-

  • like parallel graph grammars

like parallel graph grammars

1: 2: 3: 4: a b A 2: 3: A

slide-11
SLIDE 11
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

21 21

Petri Nets: Petri Nets: Rewriting of Rewriting of Multisets Multisets

A PT net transition as graph transformation rule A PT net transition as graph transformation rule Theory of concurrency of graph transformation Theory of concurrency of graph transformation

  • independence, causality, and conflicts

independence, causality, and conflicts

  • concurrent

concurrent shift shift -

  • equivalence of transformations sequences

equivalence of transformations sequences

  • processes and

processes and unfoldings unfoldings

  • event structure semantics

event structure semantics

A B C 2 a2:A b1:B a1:A b2:B c:C

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

22 22

Term Rewriting: Term Rewriting: Rewriting of Trees or Rewriting of Trees or DAGs DAGs

TR Rule TR Rule f(x) f(x) g(x, f(x)) g(x, f(x)) as DAG rewrite rule as DAG rewrite rule Theory of term graph rewriting Theory of term graph rewriting

  • soundness and completeness w.r.t. TR

soundness and completeness w.r.t. TR

  • termination, confluence and critical pairs

termination, confluence and critical pairs

  • implementation of functional languages

implementation of functional languages

  • semantics of process (e.g., pi

semantics of process (e.g., pi-

  • , ambient

, ambient-

  • ) calculi

) calculi

f g x f x 2 1

slide-12
SLIDE 12

Exercise 1 Exercise 1

Improving Improving Pacman Pacman. .

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

24 24

Be a (slightly) more clever player! Be a (slightly) more clever player!

Extend the Extend the movePM movePM rule so that rule so that Pacman Pacman does does not move next to a not move next to a Ghost. Ghost.

f1:Field f2:Field pm:PacMan f1:Field f2:Field pm:PacMan

movePM

f2:Field g:Ghost

Solution: a negative application condition.

slide-13
SLIDE 13
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

25 25

Give Give Pacman Pacman another chance another chance

Let Let Pacman Pacman have a counter for his lives. have a counter for his lives. Refine the rule Refine the rule kill kill to remove to remove Pacman Pacman only if he

  • nly if he

has run out of lives. Otherwise decrease has run out of lives. Otherwise decrease the counter and remove the the counter and remove the Ghost Ghost. .

Field PacMan marbles:int Ghost Marble PacMan marbles:int lives:int

Solution: add an attribute.

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

26 26

Refine rule Refine rule kill kill

g:Ghost f1:Field f2:Field :PacMan f1:Field f2:Field g:Ghost

kill

:PacMan lives = 0

Solution: match attribute value.

g:Ghost f1:Field f2:Field :PacMan f1:Field f2:Field g:Ghost

kill

:PacMan lives = n

n > 0

:PacMan lives = n-1

Solution: an attribute application condition.

slide-14
SLIDE 14

3 3-

  • Applications

Applications of

  • f

Graph Transformation Graph Transformation

What it is all good for What it is all good for (except video games). (except video games).

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

28 28

Outline Outline

Semantic domain/ Programming language Semantic domain/ Semantic domain/ Programming language Programming language Concrete syntax Concrete Concrete syntax syntax Abstract syntax Abstract syntax Abstract syntax

layout scanning and parsing denotational semantics semantic feedback

  • perational

semantics

  • As semantic domain for

As semantic domain for behavior modeling behavior modeling

  • capturing and analyzing

capturing and analyzing functional requirements functional requirements

  • reconfiguration, mobility,

reconfiguration, mobility, and evolution of soft and evolution of soft-

  • and hardware

and hardware architectures architectures

  • As a meta language for

As a meta language for visual modeling visual modeling techniques techniques

slide-15
SLIDE 15
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

29 29

Motivation: Software Development as Motivation: Software Development as Integration of Views Integration of Views

  • Req. A

User View A

  • Req. B

User View B ensure consistency

Model A Model B

capture integrate & transform

System

Make sure there is an implementation satisfying all requirements ! 1. Aspects of requirements models 2. Conflicts between functional requirements 3. Theory and tool support

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

30 30

Aspects of Requirements Models Aspects of Requirements Models

Model A Model B

1.

  • 1. Static domain model: Agree on vocabulary first !

Static domain model: Agree on vocabulary first !

  • class and object diagrams

class and object diagrams

2.

  • 2. Business process model: Which actions are performed

Business process model: Which actions are performed in which order ? in which order ?

  • use case description in natural language, activity or sequence

use case description in natural language, activity or sequence diagrams, etc. diagrams, etc.

slide-16
SLIDE 16
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

31 31

Structure: Class and Object Diagrams Structure: Class and Object Diagrams

Rack Customer

cash

Cart Shop Bill

total

  • wns
  • wns

0..1 0..1 0..1 0..1 0..1 0..1 0..1 1 1 1 0..1

CashBox

amount 1 1

Item

value

typing

  • formal, e.g., attributed

formal, e.g., attributed graphs at the type and graphs at the type and instance level instance level

  • established techniques

established techniques for view integration for view integration

:Customer

cash = 50

:Cart :Shop :Bill

total = 40

:Cash Box

amount = 1000

:Item

value = 30

:Item

value = 10

  • wns
  • wns
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

32 32

Behaviour Behaviour: Use Case Description by : Use Case Description by Structured Text Structured Text

  • take shopping cart

take shopping cart

  • select items from rack

select items from rack

  • take items out of cart

take items out of cart

  • pay required amount

pay required amount

  • collect items

collect items

  • create empty bill for

create empty bill for new customer new customer

  • take items out of

take items out of customer’s cart customer’s cart

  • add them to the bill

add them to the bill

  • collect payment

collect payment

  • pack and give items to

pack and give items to customer customer <<refine>> Customer Clerk buy items sell items Shop

  • based on vocabulary

based on vocabulary

  • f integrated domain
  • f integrated domain

model model

  • no way to

no way to tell if views are tell if views are consistent consistent

slide-17
SLIDE 17
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

33 33

Aspects of Requirements Models Aspects of Requirements Models

Model A Model B

  • Static domain model: Agree on vocabulary first !

Static domain model: Agree on vocabulary first !

  • class and object diagrams

class and object diagrams

  • Business process model: Which actions are performed

Business process model: Which actions are performed in which order ? in which order ?

  • use case description in natural language, activity or sequence

use case description in natural language, activity or sequence diagrams, etc. diagrams, etc.

3.

  • 3. Functional model: What happens if an action is

Functional model: What happens if an action is performed ? performed ?

  • pre

pre-

  • /post conditions as logic constraints

/post conditions as logic constraints

  • transformation rules on object diagrams

transformation rules on object diagrams (Fusion, Catalysis, (Fusion, Catalysis, Fujaba Fujaba, formally: graph transformations) , formally: graph transformations)

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

34 34

Function: Function: Transformation Rules on Transformation Rules on Object Diagrams Object Diagrams

:Shop :Item :Bill

total = x

:CashBox

amount = y

  • wns

:Shop :Item :Bill

total = x

:CashBox

amount = y+x

Clerk:: close bill

:Customer

cash=y

:Cart :Item :Bill

total=x

:Shop

  • wns

:Customer

cash=y-x

:Cart :Item :Bill

total=x

  • wns

:Shop

Customer:: pay bill conflicting actions

slide-18
SLIDE 18
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

35 35

:Customer cash = 40 :Cart :Shop :Bill total = 10 :Cash Box amount = 1000

pay bill

:Item value = 10

  • wns

Conflicts Conflicts Between Between Functional Functional Requirements Requirements

:Customer cash = 50 :Cart :Bill total = 10 :Cash Box amount = 1000

  • wns

:Item value = 10 :Shop :Customer cash = 50 :Cart :Shop :Bill total = 10 :Cash Box amount = 1010 :Item value = 10

  • wns

close bill

both delete

  • wns link

customer updates cash clerk updates amount

Customer Clerk

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

36 36

Theory: Independence, Causality and Theory: Independence, Causality and Conflicts in Graph Transformation Conflicts in Graph Transformation

Alternative steps are parallel

independent if they do not disable each other. Otherwise they are in conflict.

Consecutive steps are

sequentially independent if they may be swapped without affecting the result. Otherwise they are causally dependent. Idea: Find potential conflicts and causal dependencies between rules by critical pair analysis Characterization [EPS73]: Characterization [EPS73]: Two (alternative or consecutive) steps are independent iff all commonly accessed items are in read-access only.

G H1 H2

p2 p1

X

p1 p2

slide-19
SLIDE 19
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

37 37

Tool Support: Critical Pair Analysis with Tool Support: Critical Pair Analysis with AGG AGG

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

38 38

Usage Usage Scenario Scenario

1. 1.

input input model model to CASE to CASE tool tool

2. 2.

import import model model by by analysis analysis tool tool

3. 3.

analyze analyze model model for for conflicts conflicts

4. 4.

back back annotate annotate models models with with conflicts conflicts

5. 5.

interprete interprete and and improve improve models models Modeller UML CASE Tool Analysis Tool 1. 2. 3. 4. 5.

Customer Clerk buy items sell items Shop <<disables>>

Domain expert: “ Domain expert: “buy items buy items and sell items should and sell items should not be in conflict” not be in conflict” Modeller: Modeller: “ “inconsistency inconsistency between views between views” ”

slide-20
SLIDE 20
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

39 39

Another Interpretation: Another Interpretation: Graphs as Architectures Graphs as Architectures

Cash Box SmartCard Banking System

CardReader

Internet

1. 1.

Type vs. instance level Type vs. instance level

2. 2.

Generation and reconfiguration Generation and reconfiguration

3. 3.

Integration with functional requirements Integration with functional requirements

  • static and dynamic

static and dynamic

  • consistency issues

consistency issues

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

40 40

Architecture: Architecture: Type and Instance Graphs Type and Instance Graphs

  • individual configuration

individual configuration

  • instance graph

instance graph

  • architectural style =

architectural style = class of configurations class of configurations

  • type graph

type graph

  • components

components

  • ports

ports

  • connectors

connectors

typing

CashBox

Card Reader

BankingServer

IPInt

SmartCard

CardInt 0..1 0..1 IPInt

:CashBox

:Card Reader

:BankingServer

:IPInt

:SmartCard

:CardInt :IPInt

:BankingServer

:IPInt

slide-21
SLIDE 21
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

41 41

Reconfiguration: Reconfiguration: Typed Graph Transformation Typed Graph Transformation

  • Elementary operations

Elementary operations

  • creating (destroying) new

creating (destroying) new component instances component instances

  • establishing (removing)

establishing (removing) connectors connectors

  • Complex reconfigurations

Complex reconfigurations

  • local (CF) rules with

local (CF) rules with synchronization synchronization

  • global (non

global (non-

  • CF) rules

CF) rules

Also: Also: architectural style as architectural style as graph grammar graph grammar

r:Card Reader c:CardInt r:Card Reader c:CardInt insert(r,c) i1:IPInt i2:IPInt connect(i1,i2) i1:IPInt i2IPInt

:SmartCard

:CardInt newCard()

∅

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

42 42

Development Problem: Implement Development Problem: Implement functionality on a given architecture functionality on a given architecture

Functional Requirements System Architecture Deployment <<refine>> <<extend>>

  • static: deploy classes at components and objects at

static: deploy classes at components and objects at component instances component instances

  • define

define a typed relation a typed relation

  • dynamic: distribute functionality

dynamic: distribute functionality

  • decompose global operations

decompose global operations

  • add

add communication and reconfiguration communication and reconfiguration

slide-22
SLIDE 22
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

43 43

Functional Requirements Functional Requirements

Payment of Bills Payment of Bills

  • static: type graph

static: type graph

  • dynamic: typed graph

dynamic: typed graph transformation rule transformation rule

Bill total has to Account number balance pays 1 1 1 Client name Transfer amount src dest 1 1 :Account balance = b1 :Account balance = b2 b:Bill total = a to :Client pays has

payBill(b)

:Account balance = b1-a :Account balance = b2+a :Client has

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

44 44

Static Integration: Static Integration: Instance and Type Level Instance and Type Level

location of objects at location of objects at component instances component instances

:CashBox :BankingServer

BS2:IPInt CB:IPInt

A2:Account B:Bill

to

:BankingServer

BS1:IPInt

A1:Account

has

:SmartCard

SC:CardInt

C:Client

R:CardReader

C:Client

Bill Account Client Transfer

CashBox BankingServer SmartCard

constrained by type constrained by type level level

typing

<<supports>> <<supports>> <<supports>> <<supports>>

slide-23
SLIDE 23
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

45 45

Dynamic Integration: Three views Dynamic Integration: Three views

Rules for Rules for

  • computation: what happens inside components

computation: what happens inside components

  • reconfiguration: how the architecture is transformed

reconfiguration: how the architecture is transformed

  • interaction: how components communicate

interaction: how components communicate :CashBox :BankingServer

  • rderTransfer(t)

ackTransfer(t) :SmartCard authorizeTransfer(c) :BankingServer executeTransfer(t)

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

46 46

Implementing Implementing payBill(B payBill(B) )

1. 1.

insert(R,SC); insert(R,SC); authorize(C); authorize(C); eject(R,SC); eject(R,SC);

2. 2.

createTransfer(B,T createTransfer(B,T); );

3. 3.

connect(CB,BS1); connect(CB,BS1); orderTransfer(T

  • rderTransfer(T);

); ackTransfer(T ackTransfer(T); ); disconnect(CB,BS1); disconnect(CB,BS1);

4. 4.

connect(BS1,BS2); connect(BS1,BS2); executeTransfer(T executeTransfer(T); ); disconnect(BS1,BS2) disconnect(BS1,BS2)

:CashBox :BankingServer

BS2:IPInt CB:IPInt

A2:Account

:BankingServer

BS1:IPInt

A1:Account

has

:SmartCard

SC:CardInt

C:Client

R:CardReader

B:Bill

to

T:Transfer

dest src pays

C:Client

has

T:Transfer

src dest

slide-24
SLIDE 24
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

47 47

Computation rule: Computation rule: createTransfer createTransfer

  • local to

local to CashBox CashBox instance instance

cb:CashBox

t:Transfer amount = a src dest :Account :Account :Client has

cb.create Transfer(b,t)

cb:CashBox

:Account :Account b:Bill total = a to :Client pays has

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

48 48

Computation Rule: Computation Rule: executeTransfer executeTransfer

  • non

non-

  • local operation

local operation

  • synchronized between two

synchronized between two BankingServer BankingServer instances instances

bs2:BankingServer :PermIP

a2:Account balance=b2

bs1:BankingServer

:PermIP a1:Account balance=b1 t:Transfer amount=a

src dest

bs2:BankingServer :PermIP

a2:Account balance=b2+a

bs1:BankingServer

:PermIP a1:Account balance=b1-a

(bs1,bs2). executeTransfer(t)

slide-25
SLIDE 25
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

49 49

Communication Rule: Communication Rule:

  • rderTransfer
  • rderTransfer
  • shows effect of communication

shows effect of communication

  • transmission of

transmission of Transfer Transfer instance instance

  • abstracts from communication protocol

abstracts from communication protocol

  • sending and reception of messages

sending and reception of messages

:CashBox

cb:DialUpIP

t:Transfer src

:BankingServer

bs1:PermIP

a1:Account

  • rderTransfer(t)

:CashBox

t:Transfer src

:BankingServer

a1:Account t:Transfer

cb:DialUpIP bs1:PermIP

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

50 50

Consistency Problem: Consistency Problem: Partial Correctness ? Partial Correctness ?

Do executions of the rule sequence implement the Do executions of the rule sequence implement the requirements expressed by the global rule ? requirements expressed by the global rule ?

1. 1.

Project sequence to the functional view Project sequence to the functional view

  • hide all communication and reconfiguration rules

hide all communication and reconfiguration rules

  • remove all components, connectors, and ports

remove all components, connectors, and ports

  • identify shared objects

identify shared objects 2. 2.

Minimize the resulting sequence Minimize the resulting sequence

  • clip off unnecessary context

clip off unnecessary context

  • skip idle steps

skip idle steps 3. 3.

Compare reduced sequence s to the original rule r Compare reduced sequence s to the original rule r Thm Thm [embedding]: [embedding]: If If r r can be embedded into (is can be embedded into (is equal to) the equal to) the derived rule derived rule of the sequence

  • f the sequence s,

s, each each execution of execution of s s implements at least (exactly) the implements at least (exactly) the effects specified by effects specified by r. r.

slide-26
SLIDE 26
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

51 51

t:Transfer amount = a src dest :Account :Account :Client has create Transfer(b,t) :Account balance = b1 :Account balance = b2 t:Transfer amount = a src dest :Account balance = b1-a :Account balance = b2+a execute Transfer(t) :Account :Account b:Bill total = a to :Client pays has :Account balance = b1 :Account balance = b2 b:Bill total = a to :Client pays has :Account balance = b1-a :Account balance = b2+a :Client has t:Transfer amount = a src dest :Account balance = b1 :Account balance = b2 :Client has create Transfer(b,t) execute Transfer(t)

Example: Reduced Sequence Equals Global Rule Example: Reduced Sequence Equals Global Rule

createTransfer(b,t createTransfer(b,t) ) ; ; executeTransfer(t executeTransfer(t) = ) = payBill(b payBill(b) )

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

52 52

Summary Summary

  • Specification of changes by means of graph

Specification of changes by means of graph transformation rules on object structures, transformation rules on object structures, architectures, … architectures, …

  • formal, yet visual and intuitive

formal, yet visual and intuitive

  • integrates structural and behavioral aspect

integrates structural and behavioral aspect

  • Relevant graph transformation theory

Relevant graph transformation theory

  • independence and local Church

independence and local Church-

  • Rosser; critical pair analysis:

Rosser; critical pair analysis: detect potential conflicts between views detect potential conflicts between views

  • embedding of transformation sequences: consistency of

embedding of transformation sequences: consistency of implementation and requirements implementation and requirements

  • theory of concurrency and rewriting

theory of concurrency and rewriting

slide-27
SLIDE 27

Exercise 2 Exercise 2

Meta Meta modelling modelling. .

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

54 54

One formalism One formalism – – two interpretations: two interpretations: Integration at the Meta Level Integration at the Meta Level

type ComponentInst PortInst ConnectorInst Component Port Connector type type

1 1 1 2 1 2 1

Architecture Object Class ComponentInst Component Deployment PairType PairInst Object LinkEnd Link Class AssociationEnd Association type type type

1 1 1 2 1 2 1

Function

1

dom dom cod cod

1 1 1 1

type

<<extends>> <<extends>> 1

slide-28
SLIDE 28
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

55 55

Represent as meta model instance! Represent as meta model instance!

cb:CashBox

b:Bill

CashBox

Bill

<<supports>>

type level diagram: instance level diagram:

:Object name=“b” :Class name=“Bill” type :ComponentInst name=“cb” :Component name=“CashBox” type PairType PairInst type dom dom cod cod

Hint: Assume that every meta type has a name attribute.

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

56 56

Meta language Meta language

  • as semantic domain for

as semantic domain for behaviour modelling behaviour modelling

  • as a

as a meta language meta language for for visual modelling visual modelling techniques techniques

  • syntax definitions:

syntax definitions:

  • editors, parsers, ...

editors, parsers, ...

  • semantics definitions:

semantics definitions:

  • interpreters, compilers,

interpreters, compilers,

  • syntactic and semantic

syntactic and semantic integration of integration of VMTs VMTs

  • CASE tools

CASE tools

Semantic domain/ Programming language Semantic domain/ Semantic domain/ Programming language Programming language Concrete syntax Concrete Concrete syntax syntax Abstract syntax Abstract syntax Abstract syntax

layout scanning and parsing denotational semantics semantic feedback

  • perational

semantics

slide-29
SLIDE 29
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

57 57

Running example Running example

Operating Idle Card Inserted Authentication Started Rejected Serving Transaction Handling

1 2 3 4 5 6 ejectCard receiveClientData insertCard [! clientAccepted] [clientAccepted]

Cashbox

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

58 58

Syntax Syntax

  • Concrete syntax

Concrete syntax

  • Describes how graphical elements are represented and their

Describes how graphical elements are represented and their actual shapes actual shapes

  • Open, closed lines, and labels are specialized in kinds of lines

Open, closed lines, and labels are specialized in kinds of lines and closed shapes and closed shapes

  • Concepts are modeled through

Concepts are modeled through spatial relationship graphs spatial relationship graphs

  • Abstract syntax

Abstract syntax

  • Describes the sentence by the structure it has according to

Describes the sentence by the structure it has according to the language and fully abstracts away from the visual the language and fully abstracts away from the visual representation representation

  • Sentences (diagrams/models/graphs) are defined by

Sentences (diagrams/models/graphs) are defined by composing shapes (concrete elements) composing shapes (concrete elements)

  • Sentences are rendered as abstract syntax graphs (close to

Sentences are rendered as abstract syntax graphs (close to OMG OMG metamodels metamodels) ) Concrete syntax Concrete Concrete syntax syntax Abstract syntax Abstract syntax Abstract syntax

layout scanning and parsing

slide-30
SLIDE 30
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

59 59

Scanning and parsing Scanning and parsing

  • User models are

User models are scanned scanned to build spatial relationship to build spatial relationship graphs and abstract syntax graphs graphs and abstract syntax graphs

  • The grammar predicates in terms of lines, bubbles, labels,

The grammar predicates in terms of lines, bubbles, labels, etc etc

  • Abstract syntax graphs can be

Abstract syntax graphs can be parsed parsed to validate that to validate that they represent valid elements of the language they represent valid elements of the language

  • The grammar predicates in terms of language’s tokens

The grammar predicates in terms of language’s tokens

  • It could be used to define allowed steps in syntax

It could be used to define allowed steps in syntax-

  • directed

directed editors editors

Concrete syntax Concrete Concrete syntax syntax Abstract syntax Abstract syntax Abstract syntax

scanning and parsing

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

60 60

Example Example

(Cashbox) (Cashbox)

  • Concrete syntax

Concrete syntax

(Spatial relationships graph) (Spatial relationships graph)

  • Abstract syntax

Abstract syntax

(Abstract syntax graph) (Abstract syntax graph) :Rectangle :Rectangle Idle:Label Idle:Label :Edge :Edge :Edge :Edge :Edge :Edge

in in top/left top/left bottom/center bottom/center right/center right/center

Idle:State Idle:State 1:Transition 1:Transition 2:Transition 2:Transition 6:Transition 6:Transition

source source target target target target

1:Label 1:Label

  • ver
  • ver

Only fragments of Only fragments of complete diagrams complete diagrams

slide-31
SLIDE 31
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

61 61

Layout Layout

  • Abstract syntax graphs can be used also to define automatic

Abstract syntax graphs can be used also to define automatic layouts through special layouts through special-

  • purpose grammars that embody layout

purpose grammars that embody layout algorithms algorithms

  • Textual attributes can be used to compute correct positions for

Textual attributes can be used to compute correct positions for concrete shapes concrete shapes

  • Almost all algorithms employ general purpose rules. Subtle

Almost all algorithms employ general purpose rules. Subtle positioning cannot be rendered positioning cannot be rendered

  • Example (toy)

Example (toy)

  • The first edge always leaves for the

The first edge always leaves for the center center of the left side

  • f the left side
  • The second edge from the

The second edge from the center center of the top side

  • f the top side
  • …

… Concrete syntax Concrete Concrete syntax syntax Abstract syntax Abstract syntax Abstract syntax

layout

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

62 62

Example Example

( (DiaGen DiaGen) )

From specifications of From specifications of

  • abstract and concrete syntax

abstract and concrete syntax

  • by graph grammar rules

by graph grammar rules

  • free

free-

  • hand and syntax

hand and syntax-

  • directed editing operations

directed editing operations

  • by editing rules

by editing rules

  • perational semantics
  • perational semantics
  • by animation rules

by animation rules

DIAGEN DIAGEN generates generates standalone standalone editors editors as as Java Java classes classes

Live demo

slide-32
SLIDE 32
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

63 63

Semantics Semantics

  • It defines the meaning

It defines the meaning

  • f language sentences
  • f language sentences
  • Semantics can be given in two different ways

Semantics can be given in two different ways

  • Operational semantics

Operational semantics

  • Directly on the abstract syntax graph through another grammar

Directly on the abstract syntax graph through another grammar

  • Denotational

Denotational semantics semantics

  • Through a mapping from the abstract syntax to an external

Through a mapping from the abstract syntax to an external semantic domain semantic domain

  • In this case the role played by the grammar depends on the

In this case the role played by the grammar depends on the chosen domain chosen domain

  • It depends on what we want to communicate with

It depends on what we want to communicate with the language the language

Semantic domain/ Programming language Semantic domain/ Semantic domain/ Programming language Programming language Abstract syntax Abstract syntax Abstract syntax

denotational semantics semantic feedback

  • perational

semantics

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

64 64

Operational semantics Operational semantics

  • Mainly two different ways

Mainly two different ways

  • The grammar transformation rules can specify an

The grammar transformation rules can specify an abstract interpreter for the language abstract interpreter for the language

  • The interpreter is for the notation and can be applied on

The interpreter is for the notation and can be applied on all correct models all correct models

  • Each model can be “compiled” into a set of rules

Each model can be “compiled” into a set of rules

  • The set of rules is specific to the particular model

The set of rules is specific to the particular model

  • Theoretically, each model generates a different set of

Theoretically, each model generates a different set of rules rules

Abstract syntax Abstract syntax Abstract syntax

  • perational

semantics

slide-33
SLIDE 33
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

65 65

Abstract Abstract Interpreter Interpreter

Operating Idle Card Inserted Authentication Started Rejected Serving Transaction Handling

: : ORState ORState :Transition :Transition : State : State : State : State : : ActiveState ActiveState

contains contains is is

: : ORState ORState :Transition :Transition : State : State : State : State

contains contains

: : ActiveState ActiveState

is is src src tar tar src src tar tar

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

66 66

Ad hoc rules Ad hoc rules

  • Transitions as rules

Transitions as rules

Idle: State TranHdlg: ORState

:startState

AuthStrd: State TranHdlg: ORState Serving: State Idle: State : State

t1 t5 t6

contains contains Operating Idle Card Inserted Authentication Started Rejected Serving Transaction Handling

1 5 6

slide-34
SLIDE 34
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

67 67

Denotational Denotational semantics semantics

  • The identification of the right semantic domains

The identification of the right semantic domains impacts what sentences can be represented impacts what sentences can be represented

  • It is extremely complex for practical modeling languages

It is extremely complex for practical modeling languages

  • Usually it is defined only informally

Usually it is defined only informally

  • Or it captures only certain crucial aspects

Or it captures only certain crucial aspects

  • The semantic domain itself needs

The semantic domain itself needs

  • a syntactic representation to “denote” the meaning of

a syntactic representation to “denote” the meaning of models models

  • Tool support for analysis and reasoning

Tool support for analysis and reasoning

  • Good examples are formal methods, like algebraic

Good examples are formal methods, like algebraic specification, Petri nets, CSP, Z, Alloy specification, Petri nets, CSP, Z, Alloy

Semantic domain/ Programming language Semantic domain/ Semantic domain/ Programming language Programming language Abstract syntax Abstract syntax Abstract syntax

denotational semantics semantic feedback

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

68 68

Statecharts Statecharts to to CSP CSP

: :FinalState FinalState name name = fin = fin

State(fin) = State(fin) = stop stop

: :SimplelState SimplelState name name = s = s

State(s) = State(s) = beh(s) beh(s)

: :CompositeSate CompositeSate name name = = comp comp isCurrent isCurrent = false = false Events Events = E = E : :PseudoState PseudoState name name = = init init Kind Kind = = initial initial :State :State name name = = default default : :Transition Transition

target target source source

State( State(comp comp) = ) = State( State(default default) )

1 1 3 3 2 2

… …. .

Rules Rules for for state state decomposition decomposition and and behavior behavior

slide-35
SLIDE 35
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

69 69

Statecharts Statecharts to to Petri Petri nets nets

1 1

ASGG ASGG SGG SGG

2 2 1 1 2 2 3 3

3 3.id = .id = 3 3.name = .name = 3 3.type = “ .type = “Transition Transition” ” 3 3. .event event = = 3.action = 3.action = 3 3.name =@ .name =@3 3.name@ .name@ 3 3.type = “ .type = “STran STran” ” 3 3. .predicate predicate = @ = @3 3. .event event@ @ 3.action = @3.action@ 3.action = @3.action@ S S S S S S S S T T

1 1 2 2

St St St St St St St St STran STran

3 3 2 2 1 1

Rules Rules are are pairs pairs

  • f
  • f productions

productions

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

70 70

A possible net A possible net

Card Inserted Card Inserted Authentication Started Authentication Started Start Start Idle Idle Rejected Rejected Transaction Handling Transaction Handling Serving Serving

Operating Operating Idle Idle Card Card Inserted Inserted Authentication Authentication Started Started Rejected Rejected Serving Serving Transaction Handling Transaction Handling

slide-36
SLIDE 36
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

71 71

Integration Integration

( (Mapping among Mapping among grammars grammars) )

1: Stat 1: Stat 5: Stat 4: Stat 3: Cond 2: IfStat

::=

lp1

::=

rp1

1a: Begin 1b: End 1a: Begin 3: Cond 5a: Begin 5b: End 4a: Begin 4b: End 1b: End T F

::=

cp1

(1, 1a) (1, 1b) (1, 1a) (3, 3) (5, 5a) (5, 5b) (4, 4a) (4, 4b) (1, 1b)

The triple GG approach

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

72 72

Semantic feedback Semantic feedback

  • One

One-

  • way mapping

way mapping

  • The formal model is visible to users

The formal model is visible to users

  • The visual notation is supplemented with the semantic

The visual notation is supplemented with the semantic domain domain

  • Two

Two-

  • way mapping

way mapping

  • The formal model remains hidden to users

The formal model remains hidden to users

  • The formal method is used to interpret visual sentences

The formal method is used to interpret visual sentences

  • Feedback on the formal model must be mapped back onto

Feedback on the formal model must be mapped back onto the visual model the visual model

  • Ad

Ad-

  • hoc graph grammars

hoc graph grammars

  • Simple textual rules

Simple textual rules

slide-37
SLIDE 37
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

73 73

Separation Separation of

  • f concerns

concerns at the meta at the meta level level

Axiom Axiom Diagram Diagram

Main Element Main Element Interface Interface Internals Internals Details Details

Process Process Process Process Input Input Process Process Output Output Input Input Consumption Consumption Output Output Consumption Consumption Process Process Execution Execution

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

74 74

Modularity Modularity in in Graph Graph Transformation Transformation

For example: For example:

  • Grace: an approach

Grace: an approach-

  • independent initiative

independent initiative

  • Progres

Progres: see above : see above

  • …

…

DR = export from MUX import types procedures

p r p r rec_dl(p,r)

body from MUX import rel(p,r) implement types procedures

p r rec_dl(p,r) p r p r ≠ waiting(p,r) p r ≠ p r p r ignore(p,r) p r p r rel(p,r)

slide-38
SLIDE 38
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

75 75

Summary Summary

  • GT for syntax, semantics, and integration of

GT for syntax, semantics, and integration of VMT’s VMT’s

  • Relevant graph transformation theory

Relevant graph transformation theory

  • generative power of graph grammars and parsing

generative power of graph grammars and parsing

  • f graph languages: specifying and recognizing
  • f graph languages: specifying and recognizing

the syntax of visual languages the syntax of visual languages

  • confluence and termination: translation of models

confluence and termination: translation of models into semantic domains into semantic domains

  • theory of formal languages and rewriting

theory of formal languages and rewriting

4 4-

  • Tool support

Tool support

slide-39
SLIDE 39
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

77 77

Outline Outline

  • Two main groups:

Two main groups:

  • General purpose modeling environments

General purpose modeling environments

  • PROGRES, AGG,

PROGRES, AGG, Fujaba Fujaba, … , …

  • Environments for specifying visual notations

Environments for specifying visual notations

  • DIAGEN,

DIAGEN, GENGEd GENGEd, , MetaEnv MetaEnv, … , …

  • Good prototype tools developed in academia

Good prototype tools developed in academia

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

78 78

PROGRES PROGRES

( (PROgrammed PROgrammed Graph Rewriting Systems) Graph Rewriting Systems)

  • Graphical/textual

Graphical/textual language to specify language to specify graph transformations graph transformations

  • Graph rewrite rules with

Graph rewrite rules with complex and negative complex and negative conditions conditions

  • Cross compilation in

Cross compilation in Modula 2, C and Java Modula 2, C and Java

slide-40
SLIDE 40
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

79 79

AGG AGG

(The Attributed Graph Grammar System) (The Attributed Graph Grammar System)

  • Algebraic approach to

Algebraic approach to graph transformation graph transformation

  • Annotations are in Java

Annotations are in Java

  • Efficient graph parsing

Efficient graph parsing

  • Parse grammar

Parse grammar

  • Critical pair analysis

Critical pair analysis

  • Easy integration with

Easy integration with Java code Java code

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

80 80

Fujaba Fujaba

(From UML to Java and (From UML to Java and BAck BAck) )

  • Round trip engineering

Round trip engineering with UML, Java, and with UML, Java, and design patterns design patterns

  • Class, collaboration and

Class, collaboration and activity diagrams for activity diagrams for story diagrams story diagrams

  • Dynamic

Dynamic behavior behavior

  • Automatic generation

Automatic generation

  • Reverse engineering

Reverse engineering

slide-41
SLIDE 41
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

81 81

DiaGen DiaGen

( (The Diagram Editor Generator ) The Diagram Editor Generator )

  • Notations are specified

Notations are specified through through hypergraphs hypergraphs

  • Framework of Java

Framework of Java classes classes

  • to provide basic

to provide basic functionality functionality

  • Generator program

Generator program

  • to produce Java source

to produce Java source code code

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

82 82

GenGED GenGED

(Generation of Graphical (Generation of Graphical Env.s Env.s for Design) for Design)

  • Graphical editors and

Graphical editors and simulation environments simulation environments

  • Syntax grammar

Syntax grammar

  • Actual syntax

Actual syntax

  • Parse grammar

Parse grammar

  • Free

Free-

  • hand editing

hand editing

  • Simulation grammar

Simulation grammar

  • To simulate models

To simulate models

  • AGG and graphical constraint

AGG and graphical constraint solving techniques solving techniques

slide-42
SLIDE 42
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

83 83

MetaEnv MetaEnv

  • Customizable engine to

Customizable engine to map diagram notations map diagram notations

  • nto high
  • nto high-
  • level timed

level timed Petri nets Petri nets

  • Rules are pairs of graph

Rules are pairs of graph grammars grammars

  • Results are mapped

Results are mapped back onto the diagram back onto the diagram model model

5 5-

  • Conclusions

Conclusions

slide-43
SLIDE 43
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

85 85

Main results Main results

  • The tutorial has

The tutorial has

  • Motivated the use of graph transformation in software

Motivated the use of graph transformation in software engineering engineering

  • Introduced the foundations of graph transformation

Introduced the foundations of graph transformation

  • Shown example applications of graph transformation

Shown example applications of graph transformation

  • GT as semantic domain for behavior modeling

GT as semantic domain for behavior modeling

  • GT as meta language for visual modeling techniques

GT as meta language for visual modeling techniques

  • Presented available tools

Presented available tools

  • Now, attendees should be able to

Now, attendees should be able to

  • Better understand the different proposals

Better understand the different proposals

  • Better evaluate if and how they can exploit it in their work

Better evaluate if and how they can exploit it in their work

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

86 86

Future work Future work

( (Applications Applications) )

  • GT

GT should should become become more “ more “usable usable” ” by by non non experts experts: :

  • It

It should should be be better better disseminated disseminated ( (This This tutorial tutorial) )

  • More

More examples examples and case and case studies studies to to “convince” “convince” skeptical skeptical users users

  • Further

Further cooperations cooperations between between GT GT experts experts and and domain domain experts experts

  • More

More friendly friendly tools tools ( (even even if if they they are are much much better better than than a few a few years years ago) ago)

slide-44
SLIDE 44
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

87 87

Future work Future work

(Foundations) (Foundations)

  • analysis and verification techniques

analysis and verification techniques

  • theory of concurrency and rewriting

theory of concurrency and rewriting

  • semantics

semantics-

  • preserving transformations

preserving transformations

  • evolution /

evolution / refactoring refactoring of diagrams

  • f diagrams
  • refinement and modularity of graph transformations

refinement and modularity of graph transformations

  • relation with other areas like

relation with other areas like

  • process calculi (e.g., Robin Milner‘s talk): proof techniques

process calculi (e.g., Robin Milner‘s talk): proof techniques

  • f algebraic and logic methods;
  • f algebraic and logic methods; Can we adopt them?

Can we adopt them?

  • tree

tree-

  • and term

and term-

  • based rewriting techniques (in compilers,

based rewriting techniques (in compilers, XML, etc.): efficiency of special XML, etc.): efficiency of special-

  • purpose tools vs. usability of

purpose tools vs. usability of graph graph-

  • based specification;

based specification; Can’t we have both? Can’t we have both?

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

88 88

Research Training Network Research Training Network SegraVis SegraVis (10/2002 (10/2002 – – 9/2006) 9/2006)

Syntactic and Semantic Integration of Visual Modeling Techniques Syntactic and Semantic Integration of Visual Modeling Techniques 12 European partners offer grants for young researchers (< 36) w 12 European partners offer grants for young researchers (< 36) with interest ith interest in visual modeling techniques in visual modeling techniques Paderborn Paderborn Leiden Leiden Antwerp Antwerp London London Barcelona Barcelona Milan Milan Berlin Berlin Darmstadt Darmstadt Bremen Bremen Pisa Pisa Canterbury Canterbury Rome Rome Objectives: to develop meta Objectives: to develop meta-

  • level

level t techniques for defining syntax, semantics, echniques for defining syntax, semantics, analysis, transformation, … of UML and other visual models analysis, transformation, … of UML and other visual models Contact: Reiko Heckel Contact: Reiko Heckel

slide-45
SLIDE 45
  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

89 89

A few basic A few basic references references

  • HANDBOOK OF GRAPH GRAMMARS AND

HANDBOOK OF GRAPH GRAMMARS AND COMPUTING BY GRAPH TRANSFORMATION COMPUTING BY GRAPH TRANSFORMATION

  • Volume 1: foundations

Volume 1: foundations edited by Grzegorz Rozenberg (Leiden University, The edited by Grzegorz Rozenberg (Leiden University, The Netherlands) Netherlands)

  • Volume 2: Applications, Languages and Tools

Volume 2: Applications, Languages and Tools edited by H Ehrig (Technical University of Berlin, Germany), edited by H Ehrig (Technical University of Berlin, Germany), G Engels (University of Paderborn, Germany), H G Engels (University of Paderborn, Germany), H-

  • J Kreowski

J Kreowski (University of Bremen, Germany) & G Rozenberg (Leiden (University of Bremen, Germany) & G Rozenberg (Leiden University, The Netherlands) University, The Netherlands)

  • Volume 3: Concurrency, Parallelism, and Distribution

Volume 3: Concurrency, Parallelism, and Distribution edited by H Ehrig (Technical University of Berlin, Germany), edited by H Ehrig (Technical University of Berlin, Germany), H H-

  • J Kreowski (University of Bremen, Germany), U Montanari

J Kreowski (University of Bremen, Germany), U Montanari (University of Pisa, Italy) & G Rozenberg (Leiden University, (University of Pisa, Italy) & G Rozenberg (Leiden University, The Netherlands) The Netherlands)

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

90 90

Web sites Web sites

  • AGG home page

AGG home page

  • tfs.cs.tu

tfs.cs.tu-

  • berlin.de/agg

berlin.de/agg/ /

  • PROGRES home page

PROGRES home page

  • www

www-

  • i3.informatik.rwth

i3.informatik.rwth-

  • aachen.de/research/projects/progres/

aachen.de/research/projects/progres/

  • DiaGen

DiaGen home page home page

  • www2.informatik.uni

www2.informatik.uni-

  • erlangen.de/DiaGen/

erlangen.de/DiaGen/

  • GenGED

GenGED home page home page

  • tfs.cs.tu

tfs.cs.tu-

  • berlin.de/~genged

berlin.de/~genged/ /

  • Graph Grammar Bibliography

Graph Grammar Bibliography

  • www.informatik.uni

www.informatik.uni-

  • bremen.de/theorie//appligraph/bibliography.html

bremen.de/theorie//appligraph/bibliography.html

slide-46
SLIDE 46

6 6-

  • Open

Open discussion discussion

  • L. Baresi and R. Heckel
  • L. Baresi and R. Heckel -
  • ICGT Tutorial (Barcelona, Spain 08/10/2002)

ICGT Tutorial (Barcelona, Spain 08/10/2002)

92 92

Our Our Addresses Addresses

  • Luciano Baresi

Luciano Baresi

  • Politecnico di Milano

Politecnico di Milano Dipartimento di Elettronica e Informazione Dipartimento di Elettronica e Informazione Piazza L. da Vinci, 32 Piazza L. da Vinci, 32 – – I20133 Milano (Italy) I20133 Milano (Italy) baresi@elet.polimi.it baresi@elet.polimi.it

  • Reiko Heckel

Reiko Heckel

  • Dr. Reiko Heckel
  • Dr. Reiko Heckel

University of Paderborn University of Paderborn Mathematics/Computer Science Department Mathematics/Computer Science Department Warburger Warburger Str Str, 100 , 100 -

  • D33098 Paderborn (Germany)

D33098 Paderborn (Germany) reiko@upb.de reiko@upb.de