07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 1 Finding Inconsistencies using Relation Partition Algebra Location: Technische Universiteit Eindhoven Date:3 December 2004 Johan MuskensMichel ChaudronReinder Bril

07/09/04 Johan Muskens ( 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 ( 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 ( TU/e Computer Science, System Architecture and Networking 4 Introduction: Background View XView 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 ( TU/e Computer Science, System Architecture and Networking 5 Introduction: Problem How to find inconsistencies between different views ?

07/09/04 Johan Muskens ( 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 ( 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 ( TU/e Computer Science, System Architecture and Networking 8 Example: Overview of Operations on Relations – A -1 ´ { j 2 A} – A – B ´ { j 2 A Æ 2 B} – A [ B ´ { j 2 A Ç 2 B} – A Å B ´ { j 2 A Æ 2 B} – A;B ´ { j 2 A Æ 2 B} – A + ´  n=1 R n, where R n = R;R n-1 for n ¸ 2 – A * ´ A + [ I – A ® B ´ { j 2 A Æ 2 B Æ v=w} – A " B ´ B -1 ;A;B(lifting) – A ↓ B ´ B;A;B -1 (lowering) 1

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 9 Example: “Example of Lifting” E ={S,A,B,A 1,A 2,B 1,B 2 } C={,,, } D={,,, } S A B A1A1 A2A2 B1B1 B2B2 S A B A1A1 A2A2 B1B1 B2B2 D " C ´ C -1 ;D;C Hints: 2 C -1 2 C -1 ;D 2 D 2 C 2 C -1 ;D;C

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 10 Example: “Example of Lowering” E ={S,A,B,A 1,A 2,B 1,B 2 } C={,,, } D={ } S A B A1A1 A2A2 B1B1 B2B2 S A B A1A1 A2A2 B1B1 B2B2 D ↓ C ´ C;D;C -1 Hints: 2 C 2 C;D 2 D 2 C -1 2 C;D;C -1

07/09/04 Johan Muskens ( 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 ( 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={, …. } – INHERITANCE={, } – DEPENDENCY={, } – AGGREGATION={ }

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 13 Example: “Class diagram - MSC” MSC in RPA: – OBJECT= {Manager, Player1, Player2, display} – TYPE ={,,, } – CALL={c 1,c 2,c 3,c 4 c 5 } – NEXT={,,, } – CALLER={,,,, } – CALLEE={,,, } – MESSAGE={,,,, }

07/09/04 Johan Muskens ( 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 ( 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 ( TU/e Computer Science, System Architecture and Networking 16 Example: “Design Rules - Design” Design Rules in RPA: – P class ={Manager, Managed Element, Data, Output} – P dependency ={, } – P aggregation ={ } – Category={,,,,, }

07/09/04 Johan Muskens ( 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 µ P dependency ↓ CATEGORY

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 18 General Approach: Assumptions / Conventions View X View Y x1x1 x2x2 x3x3 M YX y1y1 y2y2 y2’y2’ y3y3 2 Views with elements – X = {x 1,x 2,x 3 } – Y = {y 1,y 2,y 2 ’,y 3 } Mapping between elements M YX – M YX = {,,, } Elements are related – R X = {, } – R Y = {,,,, }

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 19 General Approach: Constraints (1/2) View X (Leading) View Y x1x1 x2x2 x3x3 M YX y1y1 y2y2 y2’y2’ y3y3 Constraints expressed in View X result in an upper bound for the relations in View Y: – R Y " M YX µ R X con – R Y µ R X con ↓ M YX X X

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 20 General Approach: Constraints (2/2) View X View Y (Leading) x1x1 x2x2 x3x3 M YX y1y1 y2y2 y2’y2’ y3y3 Constraints expressed in View Y result in an upper bound for the relations in View X: – R X µ R Y con " M YX X

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 21 General Approach: Obligations (1/2) View X (Leading) View Y x1x1 x2x2 x3x3 M YX y1y1 y2y2 y2’y2’ y3y3 Obligations expressed in View X provide lower bound for the relations in View Y: – R X obl µ R Y " M YX

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 22 General Approach: Obligations (2/2) View X View Y (Leading) x1x1 x2x2 x3x3 M YX y1y1 y2y2 y2’y2’ y3y3 Obligations expressed in View Y result in lower bound for the relations in View X: – R Y obl " M YX µ R X – R Y obl µ R X ↓ M YX

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 23 General Approach: Exceptions (1/2) View X (Leading) View Y x1x1 x2x2 x3x3 M YX y1y1 y2y2 y2’y2’ y3y3 Constraints expressed in View X provide upper bound for the relations in View Y, but there are exceptions: – (R Y – E Y con ) " M YX µ R X con – R Y – E Y con µ R X con ↓ M YX

07/09/04 Johan Muskens ( 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 ConstraintsObligations X is LeadingYX Y is LeadingXY Make exception in

07/09/04 Johan Muskens ( TU/e Computer Science, System Architecture and Networking 25 General Approach: Overview (R Y – E Y con ) " M YX µ R X con R X obl – E X obl µ (R Y – E Y con ) " M YX View X View Y R Y – E Y con µ R X con # M YX M YX (R X – E X con ) µ R Y con " M YX (R Y obl – E Y obl ) " M YX µ (R X – E X con ) View X View Y R Y obl – E Y obl µ R X # M YX M YX X Leading Y Leading Constraint Obligation

07/09/04 Johan Muskens ( 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 ( TU/e Computer Science, System Architecture and Networking 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) XRXRX YRYRY M YX ClassDependencyObject(Caller ® Callee)Type P class P dependency ClassDependencyCategory ComponentDependencyFileIncludesImplemented in Sub SystemDependencyComponentDependencyContains Hardware NodeCommunication Channel ProcessCommunicatesExecutes on

07/09/04 Johan Muskens ( 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 ( 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 M YX – Obligations and Constraints in opposite direction as M YX