07/09/04 Johan Muskens (email: [email protected] johan)[email protected] TU/e Computer Science, System...

07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking

1

Finding Inconsistenciesusing Relation Partition Algebra

Location: Technische Universiteit Eindhoven

Date: 3 December 2004

Johan Muskens Michel Chaudron Reinder Bril

[email protected] [email protected] [email protected]


2

Outline

• Introduction– Background– Problem– Approach

• Consistency Checking using RPA– Example (s)– Generalization

• Discussion


3

Introduction: Background

• Space4U– Integrity Management

• Is system structure / behaviour consistent with certain integrity / design rules ?

• Empanada– Predict Quality Attributes

• Consistency within a design influences quality attributes


4

Introduction: Background

View X View Y

Empanada: Consistency between multiple diagrams in 1 design

Consistent ?

Space4U: Consistency between model of current configuration and integrity / design rules.

UML design

Selfmodel (model of current configuration) Integrity / Design Rules


5

Introduction: Problem

• How to find inconsistencies between different views ?


6

Introduction: Approach

• A general solution using Relation Partition Algebra for expression and verification of– Constraints imposed by one view on another– Obligations imposed by one view on another


7

Outline



• Discussion


8

Example: Overview of Operations on Relations

– A-1 ´ {<y,x> j <x,y> 2 A}– A – B ´ {<x,y> j <x,y> 2 A Æ <x,y> 2 B}– A [ B ´ {<x,y> j <x,y> 2 A Ç <x,y> 2 B}– A Å B ´ {<x,y> j <x,y> 2 A Æ <x,y> 2 B}– A;B ´ {<x,z> j <x,y> 2 A Æ <y,z> 2 B}

– A+ ´ n=1 Rn, where Rn = R;Rn-1 for n ¸ 2

– A* ´ A+ [ I– A ® B´ {<x,y> j <y,v> 2 A Æ <y,w> 2 B Æ v=w}– A " B ´ B-1;A;B (lifting)– A ↓ B ´ B;A;B-1 (lowering)

1


9

Example: “Example of Lifting”

E = {S,A,B,A1,A2,B1,B2}

C ={<A,S>,<A1,A>,<A2,A>

<B1,B>,<B2,B>}

D = {<A1,A2>,<A1,B2>,

<A2.B2>,<B1,A2>}

SA

B

A1 A2

B1 B2

SA

B

A1 A2

B1 B2

D " C ´ C-1;D;C

Hints:

<A,A1> 2 C-1 <A,B2>2 C-1;D

<A1,B2> 2 D

<B2,B> 2 C <A,B>2 C-1;D;C


10

Example: “Example of Lowering”

E = {S,A,B,A1,A2,B1,B2}

C ={<A,S>,<A1,A>,<A2,A>

<B1,B>,<B2,B>}

D = {<A,B>}

SA

B

A1 A2

B1 B2

SA

B

A1 A2

B1 B2

D ↓ C ´ C;D;C-1

Hints:

<A1,A> 2 C <A1,B> 2 C;D

<A,B> 2 D

<B,B1> 2 C-1 <A1,B1> 2 C;D;C-1


11

Example: “Class diagram – MSC”

GameManager

Player

HumanPlayer ComputerPlayer

Display

Board GameManager :Manager

HumanPlayer :Player1

ComputerPlayer :Player2

Display :display

There is no dependency between HumanPlayer and Display in the class diagram


12

Example: “Class diagram - MSC”• Class Diagram in RPA:

– CLASS = {GameManager, Board, Player, HumanPlayer,

ComputerPlayer, Display}

– METHOD = {GameManager.play, GameManager.stop,

Player.setToken, HumanPlayer.getNextMove,

HumanPlayer.setToken, ComputerPlayer.getNextMove,

ComputerPlayer.setToken, Display.printLn,

Display.printBoard}

– IMPLEMENTS = {<GameManager.play,GameManager>,

….

}

– INHERITANCE = {<HumanPlayer,Player>,<ComputerPlayer,Player>}

– DEPENDENCY = {<GameManager,Player>,<GameManager,Display>}

– AGGREGATION = {<GameManager,Board>}


13

Example: “Class diagram - MSC”• MSC in RPA:

– OBJECT = {Manager, Player1, Player2, display}

– TYPE = {<Manager, GameManager>,<Player1,HumanPlayer>, <Player2,ComputerPlayer>,<display,Display>}

– CALL = {c1,c2,c3,c4c5}

– NEXT = {<c1,c2>,<c2,c3>,<c3,c4>,<c4,c5>}

– CALLER = {<Manager,c1>,<Player1,c2>,<Manager,c3>,

<Manager,c4>,<Manager,c5>}

– CALLEE = {<Player1,c1>,<display,c2>,<display,c3>

<Player2,c4>,<display,c5>}

– MESSAGE = {<HumanPlayer.getNextMove,c1>,<Display.printLn,c2>,

<Display.printBoard,c3>,<ComputerPlayer.getNextMove,c4>,

<Display.printBoard,c5>}


14

Example: “Class diagram - MSC”

• Rule– (CALLER ® CALLEE) " TYPE µ (DEPENDENCY ↓ INHERITANCE*)

GameManager

Player


Display

Board GameManager :Manager

HumanPlayer :Player1

ComputerPlayer :Player2

Display :display

!


15

Example: “Design Rules - Design”

GameManager

Player


Display

Board

Manager

Output

Data

Managed Element


16

Example: “Design Rules - Design”• Design Rules in RPA:

– Pclass = {Manager, Managed Element, Data, Output}

– Pdependency = {<Manager,Output>,<Manager,Managed Element>}

– Paggregation = {<Manager,Data>}

– Category = {<Board,Data>,<GameManager,Manager>,

<Player,ManagedElement>,<HumanPlayer,ManagedElement>,

<ComputerPlayer,ManagedElement>,<Display,Output>}


17

Example: “Design Rules - Design”

GameManager

Player


Display

Board

Manager

Output

Data

Managed Element

• Rule– DEPENDENCY µ Pdependency ↓ CATEGORY


18

General Approach: Assumptions / ConventionsView X View Y

x1 x2 x3MYX y1

y2

y2’y3

• 2 Views with elements– X = {x1,x2,x3}– Y = {y1,y2,y2’,y3}

• Mapping between elements MYX

– MYX = {<y1,x1>,<y2,x2>,<y2’,x2>,<y3,x3>}• Elements are related

– RX = {<x1,x2>,<x2,x3>}– RY = {<y1,y2>,<y1,y2’>,<y2,y3>,<y2’,y3>,<y3,y2>}


19

General Approach: Constraints (1/2)View X (Leading) View Y

x1 x2 x3

MYX

y1

y2

y2’y3

• Constraints expressed in View X result in an upper bound for the relations in View Y:– RY " MYX µ RX

con

– RY µ RXcon ↓ MYX

XX


20

General Approach: Constraints (2/2)View X View Y (Leading)

x1 x2 x3

MYX

y1

y2

y2’y3

• Constraints expressed in View Y result in an upper bound for the relations in View X:– RX µ RY

con " MYX

X


21

General Approach: Obligations (1/2)View X (Leading) View Y

x1 x2 x3

MYX

y1

y2

y2’y3

• Obligations expressed in View X provide lower bound for the relations in View Y:– RX

obl µ RY " MYX


22

General Approach: Obligations (2/2)View X View Y (Leading)

x1 x2 x3

MYX

y1

y2

y2’y3

• Obligations expressed in View Y result in lower bound for the relations in View X:– RY

obl " MYX µ RX

– RYobl µ RX ↓ MYX


23

General Approach: Exceptions (1/2)View X (Leading) View Y

x1 x2 x3

MYX

y1

y2

y2’y3

• Constraints expressed in View X provide upper bound for the relations in View Y, but there are exceptions:– (RY – EY

con)" MYXµ RXcon

– RY – EYcon µ RX

con ↓ MYX


24

General Approach: Exceptions (2/2)

• Exceptions can be made for– Constraints

– Obligations

• Depending on the leading diagram– View X is Leading

– View Y is Leading

Constraints

Obligations

X is Leading

Y X

Y is Leading

X Y

Make exception in


25

General Approach: Overview

(RY – EYcon) " MYX µ RX

con

RXobl – EX

obl µ (RY – EYcon) " MYX

View X View Y

RY – EYcon µ RX

con # MYX

MYX

(RX – EXcon) µ RY

con " MYX

(RYobl – EY

obl )" MYX µ (RX – E

Xcon)

View X View Y

RYobl – EY

obl µ RX # MYX

MYX

X Leading

Y Leading

Constraint

Obligation


26

Outline



• Discussion


27

Discussion: ApplicabilitySuitable for:

– Consistency checking within a phase (different diagrams in design)– Consistency checking between phases

• Architecture v.s. Design• Design v.s. Implementation

– Integrity Management (verification of rules)

X RX Y RY MYXClass Dependency Object (Caller ® Callee) Type

Pclass Pdependency Class Dependency Category

Component Dependency File Includes Implemented in

Sub System Dependency Component Dependency Contains

Hardware Node Communication Channel

Process Communicates Executes on


28

Discussion: Leading Views

• Most development support tools / languages do not have the notion of leading views.– One of the reasons of the success of UML and

UML case tools is the flexibility to support a large number of development processes.

• Leading views are defined based on the development process.


29

Discussion: Advantages - Limitations

• Suitable for structure– Less suitable for behavior (path expressions)

• No limitations on development process since consistency checks are defined for a specific process.

• Can be used for constraints as well as obligations• Works in two directions

– Obligations and Constraints in same direction as MYX

– Obligations and Constraints in opposite direction as MYX

07/09/04 Johan Muskens (email: [email protected] johan)[email protected] TU/e Computer Science, System...

Documents

Transcript of 07/09/04 Johan Muskens (email: [email protected] johan)[email protected] TU/e Computer Science, System...