X CD Design-by-Contract for Reusable Components & Realizable Architectures Mert Ozkaya & Christos Kloukinas http://staff.city.ac.uk/c.kloukinas/Xcd - p. 1
Software Architecture: Beginnings Problem Two main approaches: Beginnings State Issues ■ Components & Connections No Connectors? Connectors ◆ Darwin 1996 Realizability Unrealizable Architecture Unrealizable Wright Connector Req vs Arch ■ Components & Connectors Realizable Plant ◆ Wright 1997 X CD Conclusions Extras http://staff.city.ac.uk/c.kloukinas/Xcd - p. 2
Current State Problem ■ Malavolta et al., IEEE TSE Beginnings v. 39, n. 6 “What Industry State Issues Needs from Architectural No Connectors? Connectors Languages: A Survey” Realizability Unrealizable Architecture (“needs” or “asks for”?) Unrealizable Wright Connector Req vs Arch ■ No “steep learning curve” Realizable Plant (UML), performance, X CD reliability, . . . Conclusions Extras http://staff.city.ac.uk/c.kloukinas/Xcd - p. 3
Issues ■ Formal process algebras not practitioners’ cup of tea. . . Problem Beginnings ◆ Practitioners care about Performance/Reliability/etc. State Issues No Connectors? ? But Performance/Reliability @ Deadlocked States = ? Connectors Realizability Unrealizable Architecture Unrealizable Wright Connector ■ Components + Connections Req vs Arch ◆ No Connectors Realizable Plant ◆ Components must describe the protocols they’ll be used with X CD Conclusions ? Modularity, Reusability, Architectural Exploration? Extras ? Architectural Mismatch? http://staff.city.ac.uk/c.kloukinas/Xcd - p. 4
No Connectors? ■ “All systems can be specified without connectors, therefore connectors are not needed” Alice (Monday): � √ x Bob (Friday): � x 2 Problem Beginnings State √ x Issues x 2 No Connectors? Connectors × + Realizability √ x Unrealizable Architecture x 2 Unrealizable Wright Connector + × Req vs Arch Realizable Plant √ x x 2 X CD � √ x × + Conclusions √ x + x 2 Extras × √ x x 2 � x 2 + × √ x x 2 ■ Yes, but what about map-reduce? (reduce R (map M x)) ■ Why re-invent the wheel each time? ◆ We’ll not get it right each time ■ Define it once and Reuse-by-Calling it not Reuse-by-Copying it http://staff.city.ac.uk/c.kloukinas/Xcd - p. 5
Connectors ■ Specify protocols once, reuse them by calling them Problem Beginnings ■ Components become protocol-independent State Issues No Connectors? ■ Components are more modular, easier to specify Connectors ◆ Less work � more specs � architectural mismatch less likely Realizability Unrealizable Architecture Unrealizable Wright Connector ■ Increase reusability of components & connectors Req vs Arch Realizable Plant (vector + bubble/quick/merge/. . . sort) X CD ■ Easier to verify each independently Conclusions ■ Easier to understand the system structure Extras ■ Easier to explore alternatives http://staff.city.ac.uk/c.kloukinas/Xcd - p. 6
Connector Realizability – Their Achilles’ Heel. . . ■ Wright defined the base notions: Roles + Glue Problem Beginnings ■ Components implement Roles State Issues No Connectors? ■ System = Components � Glue Connectors Realizability ■ All ADLs supporting connectors follow Wright but . . . Unrealizable Architecture Unrealizable Wright Connector ■ Glue adds global constraints Req vs Arch Realizable Plant ⇒ Unrealizable in general X CD ◆ If we want to preserve “communication integrity” Conclusions ◆ And we do – most analyses depend on it Extras http://staff.city.ac.uk/c.kloukinas/Xcd - p. 7
Unrealizable Architecture – A Nuclear Plant [AEY03] R. Alur, K. Etessami, P1 P2 and M. Yannakakis. Inference of Problem Beginnings message sequence charts. IEEE State Issues TSE, 29(7):623-633, 2003 No Connectors? Connectors Realizability UR NA Unrealizable Architecture Unrealizable Wright Connector Req vs Arch Realizable Plant (a) A decentralized architecture � X CD P1 UR NA P2 P1 UR NA P2 P1 UR NA P2 Conclusions inc double inc Extras inc double double double double inc double inc inc MSC1 MSC2 (b) The plant’s (unrealizable) MSCs (c) An unavoidable bad behaviour http://staff.city.ac.uk/c.kloukinas/Xcd - p. 8
Unrealizable Wright Connector connector Plant_Connector = role P1 = ur → na → P1. // increase both Problem role P2 = ur → na → P2. // double both Beginnings role UR = inc → UR � double → UR. State Issues role NA = inc → NA � double → NA. No Connectors? Connectors glue G = P1.ur → UR.inc → P1.na → NA.inc Realizability → P2.ur → UR.double → P2.na → NA.double Unrealizable Architecture Unrealizable Wright Connector → G Req vs Arch ⊓ P2.ur → UR.double → P2.na → NA.double Realizable Plant → P1.ur → UR.inc → P1.na → NA.inc X CD → G. // → link, → global constraint Conclusions SYSTEM = (P1:P1 � P2:P2 � UR:UR � NA:NA � G). Extras Wright’s (unrealizable) connector for the nuclear plant ■ Property is verified! ■ But no way to realize it while preserving comm. integrity . . . :-( ■ Architect needs to be told requirement isn’t satisfied ⇒ Global constraints are requirements ■ Architecture shouldn’t simply repeat the requirements http://staff.city.ac.uk/c.kloukinas/Xcd - p. 9
Requirements vs Architecture Requirement “I want infinite stairs” Architecture Problem Beginnings State Issues No Connectors? Connectors Realizability Unrealizable Architecture Unrealizable Wright Connector Req vs Arch Realizable Plant X CD Conclusions Extras M. C. Escher (1898 - 1972) ■ Architecture needs to be realizable In a way that respects communication integrity ■ Otherwise, performance/reliability/etc analyses are invalid http://staff.city.ac.uk/c.kloukinas/Xcd - p. 10
Realizable Plant connector Realizable_Plant_Connector = role P1 = ur → na → P1. // same role P2 = ur → na → P2. // same Problem Beginnings role UR = inc → UR � double → UR. // same State role NA = inc → NA � double → NA. // same Issues No Connectors? glue G = (G1 � G2 � G3 � G4). // Real glue Connectors Realizability // where Gi’s are simple links: Unrealizable Architecture G1= P1.ur → UR.inc → G1. Unrealizable Wright Connector Req vs Arch G2= P1.na → NA.inc → G2. Realizable Plant G3= P2.ur → UR.double → G3. X CD G4= P2.na → NA.double → G4. Conclusions SYSTEM = (P1:P1 � P2:P2 � UR:UR � NA:NA � G). Extras GlueProperty = UR.inc → NA.inc → UR.double → NA.double → GlueProperty UR.double → NA.double � → UR.inc → NA.inc → GlueProperty. ■ Of course, GlueProperty is no longer satisfied. . . ■ At least now we know that it doesn’t work! ■ And so do the designers/developers/clients . . . http://staff.city.ac.uk/c.kloukinas/Xcd - p. 11
X CD : Main Ideas ■ Support arbitrary connectors Problem ⇒ Modular specifications X CD Simpler component specifications X CD : Main Ideas ⇒ Reusable components & reusable connectors Interaction Constraints Java Thread in X CD Software Components & DbC ■ Only local constraints can be imposed Some Choices Structure & Roles ⇒ Realizable architectures + communication integrity X CD 2 ProMeLa Component ProMeLa Structure ■ Programming language-like syntax Centralized Plant Evaluation ⇒ Not (too) scary (?) Conclusions ■ Formal (extended Design-by-Contract approach – JML-inspired) Extras ⇒ Can verify (with SPIN): 1. Are provided services (local) interaction constraints satisfied? 2. Are provided services functional pre-conditions complete? 3. Are there race-conditions? 4. Do event buffer sizes suffice? and 5. Are there (global) deadlocks? Plus, general LTL properties (new) http://staff.city.ac.uk/c.kloukinas/Xcd - p. 12
Component Interaction Constraints Cleanliness is next to Godliness. . . Machine A Machine B Problem X CD X CD : Main Ideas Interaction Constraints Java Thread in X CD Software Components & DbC Some Choices Structure & Roles X CD 2 ProMeLa Component ProMeLa Structure Centralized Plant Evaluation Conclusions Same interfaces but. . . Extras @interaction { @interaction { 1 1 accepts: ! washing; } waits: ! washing; } 2 2 3 void open_door(); 3 void open_door(); A blocks my call till it’s safe B may reject it with undefined behaviour (might electrocute me!) http://staff.city.ac.uk/c.kloukinas/Xcd - p. 13
Java Thread as an X CD Component 1 component Thread { bool started := false ; // component data. 2 Problem bool died := false ; 3 X CD 4 X CD : Main Ideas aliveP() {return started && !died;} // helper function Interaction Constraints 5 Java Thread in X CD Software Components & DbC 6 provided p { Some Choices 7 Structure & Roles { ensures : \ result := aliveP();} X CD 2 ProMeLa @functional 8 Component ProMeLa Structure bool isAlive(); Centralized Plant 9 Evaluation 10 @interaction { waits : !aliveP();} Conclusions 11 void join(); Extras 12 13 @interaction { accepts : ! started;} 14 { ensures : started := true ;} @functional 15 void start(); 16 ? // ... other methods 17 }; 18 19 }; ■ Constraints are more modular (JML allows but doesn’t enforce it) ■ Functional constraints must be complete! Call already accepted!!! http://staff.city.ac.uk/c.kloukinas/Xcd - p. 14
Recommend
More recommend
