Finding Inconsistencies using Relation Partition Algebra

1
Finding Inconsistenciesusing Relation Partition
Algebra

• Location Technische Universiteit Eindhoven
• Date 3 December 2004
• Johan Muskens Michel Chaudron Reinder Bril
• J.Muskens_at_tue.nl M.R.V.Chaudron_at_tue.nl R.J.Br
  il_at_tue.nl

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
Empanada Consistency between multiple diagrams
in 1 design
View X
View Y
Consistent ?
Space4U Consistency between model of current
configuration and 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

• Introduction
• Background
• Problem
• Approach
• Consistency Checking using RPA
• Example (s)
• Generalization
• Discussion

8
Example Overview of Operations on Relations

• A-1 lty,xgt j ltx,ygt 2 A
• A B ltx,ygt j ltx,ygt 2 A Æ ltx,ygt 2 B
• A B ltx,ygt j ltx,ygt 2 A Ç ltx,ygt 2 B
• A Å B ltx,ygt j ltx,ygt 2 A Æ ltx,ygt 2 B
• AB ltx,zgt j ltx,ygt 2 A Æ lty,zgt 2 B
• A ?n1 Rn, where Rn RRn-1 for n 2
• A A I
• A B ltx,ygt j lty,vgt 2 A Æ lty,wgt 2 B Æ vw
• A " B B-1AB (lifting)
• A ? B BAB-1 (lowering)

1
9
Example Example of Lifting
S
S
A
A
A1
A2
A1
A2
B
B
B1
B1
B2
B2

• E S,A,B,A1,A2,B1,B2
• C ltA,Sgt,ltA1,Agt,ltA2,Agt
• ltB1,Bgt,ltB2,Bgt
• D ltA1,A2gt,ltA1,B2gt,
• ltA2.B2gt,ltB1,A2gt

D " C C-1DC Hints ltA,A1gt 2 C-1 ltA,B2gt2
C-1D ltA1,B2gt 2 D ltB2,Bgt 2 C ltA,Bgt2 C-1DC
10
Example Example of Lowering
S
S
A
A
A1
A2
A1
A2
B
B
B1
B1
B2
B2

• E S,A,B,A1,A2,B1,B2
• C ltA,Sgt,ltA1,Agt,ltA2,Agt
• ltB1,Bgt,ltB2,Bgt
• D ltA,Bgt

D ? C CDC-1 Hints ltA1,Agt 2 C ltA1,Bgt 2
CD ltA,Bgt 2 D ltB,B1gt 2 C-1 ltA1,B1gt 2 CDC-1
11
Example Class diagram MSC
Board
GameManager Manager
HumanPlayer Player1
ComputerPlayer Player2
Display display
GameManager
Player
Display
HumanPlayer
ComputerPlayer
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.getNex
  tMove,
• ComputerPlayer.setToken, Display.printLn,
• Display.printBoard
• IMPLEMENTS ltGameManager.play,GameManagergt,
• .
• INHERITANCE ltHumanPlayer,Playergt,ltComputerPlaye
  r,Playergt
• DEPENDENCY ltGameManager,Playergt,ltGameManager,Di
  splaygt
• AGGREGATION ltGameManager,Boardgt

13
Example Class diagram - MSC

• MSC in RPA
• OBJECT Manager, Player1, Player2, display
• TYPE ltManager, GameManagergt,ltPlayer1,HumanPl
  ayergt, ltPlayer2,ComputerPlayergt,ltdisplay,Di
  splaygt
• CALL c1,c2,c3,c4c5
• NEXT ltc1,c2gt,ltc2,c3gt,ltc3,c4gt,ltc4,c5gt
• CALLER ltManager,c1gt,ltPlayer1,c2gt,ltManager,c3gt,
  
• ltManager,c4gt,ltManager,c5gt
• CALLEE ltPlayer1,c1gt,ltdisplay,c2gt,ltdisplay,c3gt
• ltPlayer2,c4gt,ltdisplay,c5gt
• MESSAGE ltHumanPlayer.getNextMove,c1gt,ltDisplay.
  printLn,c2gt,
• ltDisplay.printBoard,c3gt,ltComputerPlayer.get
  NextMove,c4gt,
• ltDisplay.printBoard,c5gt

14
Example Class diagram - MSC
Board
GameManager Manager
HumanPlayer Player1
ComputerPlayer Player2
Display display
GameManager
Player
Display
HumanPlayer
ComputerPlayer

• Rule
• (CALLER CALLEE) " TYPE µ (DEPENDENCY ?
  INHERITANCE)

15
Example Design Rules - Design
Board
Data
GameManager
Player
Display
Managed Element
Manager
HumanPlayer
ComputerPlayer
Output
16
Example Design Rules - Design

• Design Rules in RPA
• Pclass Manager, Managed Element, Data,
  Output
• Pdependency ltManager,Outputgt,ltManager,Managed
  Elementgt
• Paggregation ltManager,Datagt
• Category ltBoard,Datagt,ltGameManager,Managergt,
• ltPlayer,ManagedElementgt,ltHumanPlayer,Managed
  Elementgt,
• ltComputerPlayer,ManagedElementgt,ltDisplay,Out
  putgt

17
Example Design Rules - Design
Board
Data
GameManager
Player
Display
Managed Element
Manager
HumanPlayer
ComputerPlayer
Output

• Rule
• DEPENDENCY µ Pdependency ? CATEGORY

18
General Approach Assumptions / Conventions
View Y
View X

y2
x1
x2
x3
MYX
y3
y1
y2

• 2 Views with elements
• X x1,x2,x3
• Y y1,y2,y2,y3
• Mapping between elements MYX
• MYX lty1,x1gt,lty2,x2gt,lty2,x2gt,lty3,x3gt
• Elements are related
• RX ltx1,x2gt,ltx2,x3gt
• RY lty1,y2gt,lty1,y2gt,lty2,y3gt,lty2,y3gt,lty3,y2gt

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

MYX
y2
x1
x2
x3
y3
y1
y2

• Constraints expressed in View X result in an
  upper bound for the relations in View Y
• RY " MYX µ RXcon
• RY µ RXcon ? MYX

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

MYX
y2
x1
x2
x3
y3
y1
y2

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

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

MYX
y2
x1
x2
x3
y3
y1
y2

• Obligations expressed in View X provide lower
  bound for the relations in View Y
• RXobl µ RY " MYX

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

MYX
y2
x1
x2
x3
y3
y1
y2

• Obligations expressed in View Y result in lower
  bound for the relations in View X
• RYobl " MYX µ RX
• RYobl µ RX ? MYX

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

MYX
y2
x1
x2
x3
y3
y1
y2

• Constraints expressed in View X provide upper
  bound for the relations in View Y, but there are
  exceptions
• (RY EYcon)" MYXµ RXcon
• RY EYcon µ RXcon ? 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

Make exception in
Constraints Obligations
X is Leading Y X
Y is Leading X Y
25
General Approach Overview
Constraint
Obligation
View Y
View X
(RY EYcon) " MYX µ RXcon RXobl EXobl µ (RY
EYcon) " MYX
RY EYcon µ RXcon MYX
MYX
X Leading
Y Leading
View Y
View X
(RX EXcon) µ RYcon " MYX (RYobl EYobl )"
MYX µ (RX EXcon)
MYX
RYobl EYobl µ RX MYX
26
Outline

• Introduction
• Background
• Problem
• Approach
• Consistency Checking using RPA
• Example (s)
• Generalization
• Discussion

27
Discussion Applicability

• Suitable 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 MYX
Class 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