07/09/04 Johan Muskens (email: [email protected] johan)[email protected] TU/e Computer Science, System...
-
date post
19-Dec-2015 -
Category
Documents
-
view
214 -
download
0
Transcript of 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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
2
Outline
• Introduction– Background– Problem– Approach
• Consistency Checking using RPA– Example (s)– Generalization
• Discussion
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
5
Introduction: Problem
• How to find inconsistencies between different views ?
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
7
Outline
• Introduction– Background– Problem– Approach
• Consistency Checking using RPA– Example (s)– Generalization
• Discussion
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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>}
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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>}
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
14
Example: “Class diagram - MSC”
• Rule– (CALLER ® CALLEE) " TYPE µ (DEPENDENCY ↓ INHERITANCE*)
GameManager
Player
HumanPlayer ComputerPlayer
Display
Board GameManager :Manager
HumanPlayer :Player1
ComputerPlayer :Player2
Display :display
!
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
15
Example: “Design Rules - Design”
GameManager
Player
HumanPlayer ComputerPlayer
Display
Board
Manager
Output
Data
Managed Element
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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>}
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
17
Example: “Design Rules - Design”
GameManager
Player
HumanPlayer ComputerPlayer
Display
Board
Manager
Output
Data
Managed Element
• Rule– DEPENDENCY µ Pdependency ↓ CATEGORY
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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>}
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
26
Outline
• Introduction– Background– Problem– Approach
• Consistency Checking using RPA– Example (s)– Generalization
• Discussion
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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.
07/09/04 Johan Muskens (email: [email protected] http://www.win.tue.nl/~johan)TU/e Computer Science, System Architecture and Networking
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