Evolution Complexity: Realistic estimation of “evolvability”

1. Software Evolution through Transformations(2 Oct. 2004), Rome, Italy Evolution Complexity:Realistic estimation of “evolvability” Tom Mens Service de Génie Logiciel Université de Mons Hainaut Amnon H. Eden University of Essex and Center for Inquiry International

2. 21:55 b1 b2 Example - DFSA • Requirement: Alarm clock • Can be modelled as a deterministic finite-state automaton (DFSA)

3. Implementation policy 1: State pattern Implementation policy 2: “Switch” style Example: DFSA (Cont.) interface ClockState { void b1(); \\ button 1 pressed void b2(); \\ button 2 pressed } class DisplayHour implements ClockState { public void b1() {\* b1 pressed *\} public void b2() {\* b2 pressed *\} } class DisplaySecond implements ClockState { ... } class DisplayDate implements ClockState { ... } class SetHour implements ClockState { ... } class SetDate implements ClockState { ... } enum states = { DisplayHour, DisplaySecond, DisplayDate, SetHour, SetDate} state; // Current state void b1() { \\ button 1 pressed switch (state) { case DisplayHour: \*...*\; case DisplaySecond: \*...*\; case DisplayDate: \*...*\; case SetHour: \*...*\; case SetDate: \*...*\; } } void b2() { \\ button 2 pressed switch (state) { case DisplayHour: \*...*\; case DisplaySecond: \*...*\; case DisplayDate: \*...*\; case SetHour: \*...*\; case SetDate: \*...*\; } }

4. … to the State-policy implementation: … to the “Switch”-policy implementation: Co-evolution step e1: Adding a button b3 b1 b2 21:55 b3 interface ClockState { void b1(); \\ button 1 pressed void b2(); \\ button 2 pressed void b3(); \\ button 3 pressed } class DisplayHour implements ClockState { public void b1() {\* b1 pressed *\} public void b2() {\* b2 pressed *\} public void b3() {\* b3 pressed *\} } class DisplaySecond implements ClockState { ... public void b3() {\* b3 pressed *\} } class DisplayDate implements ClockState { ... public void b3() {\* b3 pressed *\} } class SetHour implements ClockState { ... public void b3() {\* b3 pressed *\} } class SetDate implements ClockState { ... public void b3() {\* b3 pressed *\} } enum states = { DisplayHour, DisplaySecond, DisplayDate, SetHour, SetDate} state; // Current state void b1() { \\ button 1 pressed ... } void b2() { \\ button 2 pressed ... } void b3() { \\ button 3 pressed switch (state) { case DisplayHour: \*...*\; case DisplaySecond: \*...*\; case DisplayDate: \*...*\; case SetHour: \*...*\; case SetDate: \*...*\; } } Effort: Constant Effort: Linear in the number of states

5. … to the State-policy implementation: … to the “Switch”-policy implementation: Co-evolution step e2: Adding a state b1 b2 01 b3 interface ClockState { void b1(); \\ button 1 pressed void b2(); \\ button 2 pressed } class DisplayHour implements ClockState { public void b1() {\* b1 pressed *\} public void b2() {\* b2 pressed *\} } class DisplaySecond implements ClockState { ... } class DisplayDate implements ClockState { ... } class SetHour implements ClockState { ... } class SetDate implements ClockState { ... } class SetSecondsimplements ClockState { ... } enum states = { DisplayHour, DisplaySecond, DisplayDate, SetHour, SetDate} state; // Current state void b1() { \\ button 1 pressed switch (state) { case DisplayHour: \*...*\; case DisplaySecond: \*...*\; case DisplayDate: \*...*\; case SetHour: \*...*\; case SetDate: \*...*\; case SetSeconds: \*...*\; } } void b2() { \\ button 2 pressed switch (state) { case DisplayHour: \*...*\; case DisplaySecond: \*...*\; case DisplayDate: \*...*\; case SetHour: \*...*\; case SetDate: \*...*\; case SetSeconds: \*...*\; } } Effort: Linear in the number of buttons Effort: Constant

6. Evolution Complexity • Question: How much “effort” costs to implement change s in the requirements? • Definition: The complexity C(e) of a co-evolution step e is the complexity of the meta-programming algorithm that implements it. old requirements old implementation realize Evolution step: e= (s,a) Where s=(rold,rnew)shift in the requirements a=(iold,inew)adjustment in the impl. s a new requirements new implementation realize

7. Measuring Evolution Complexity (…by the number of modules affected:)

8. Conclusions • Evolvability–Out, Evolution Complexity–In • The effort required to implement the change is not an absolute of the implementation; instead: • Evolution complexity is a function of— • Change in the requirements (“shift”) • Change in the implementation (“adjustment”) • Evolution complexity depends on the metric • “Number of modules affected” is a useful first approximation • Refined approximations: Cyclomatic complexity

9. Benefits • Determine which implementation policy (design pattern, architectural style) is more robust to a specific type of changes • Approximate the effort required to implement a specific change • Example: Abstract Factory policy vs. “switch” style (with P products, C configurations, K clients)