Change-based FODA diagrams - Bridging the gap between feature-oriented design and implementation

Feature Oriented Design Analysis (FODA) diagrams present the design of feature-oriented software applications. In some cases, however, the actual implementation of such an application does not correspond to the design that was set forward by the FODA diagram. Such discrepancies are referred to as the gap between design and implementation.

We present a bottom-up approach for generating FODA diagrams from the changes to the source code. Unlike ordinary FODA diagrams, those diagrams are based on the implementation. Thanks to that, they do not only contain coarse-grained design information, but also incorporate fine-grained implementation details, which can be used to bridge between feature-oriented design and implementation.

Transcript

1. Ansymo Antwerp Systems and Software Modelling Peter Ebraert Quinten David Soetens Dirk Janssens Change-based FODA diagrams Bridging the gap between feature-oriented design and implementation
2. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 2
3. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 2 Introduction
4. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 2 Introduction Design
5. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 2 Introduction Design Implementation
6. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 2 Introduction Design Implementation Bridging the gap
7. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 2 Introduction Design Implementation Bridging the gap
8. Traditional Software Engineering 3 Extraction and Specification of Requirements Software Design Implementation Verification and Maintenance Introduction
9. Gap between design and implementation 4 Design Implementation Introduction
10. Gap between design and implementation 4 Design Implementation Introduction
11. Gap between design and implementation 4 Design Implementation ONE WAY Introduction
12. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 5 Introduction Design Implementation Bridging the gap
13. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 5 Introduction Design Implementation Bridging the gap
14. Feature Oriented Programming • Targets Separation of concerns • every concern is modularized as a separate feature • a feature is an increment in program development or functionality • features are first class entities that form the basic building blocks of a software system • Features can be composed to form different variations of the same system. 6 Design
15. FODA Diagrams 7 Design
16. Buffer Restore Logging Mul. Res Invoke Log LogMe thod PrintInst Vars FODA Diagrams 7 Design
17. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 8 Introduction Design Implementation Bridging the gap
18. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 8 Introduction Design Implementation Bridging the gap
19. What is ChOP? • Change-Oriented Programming • Changes as First Class Entities • Change = Main development entity • Software System = Set of Changes • Software Evolution = Set of Changes 9 Change-Oriented Software Engineering Peter Ebraert, Jorge Antonio Vallejos Vargas, Pascal Costanza, Ellen Van Paesschen, Theo D'Hondt In "Proceedings of the 2007 International Conference on Dynamic Languages", published by ACM, 2007 Implementation
20. ChOP 10 Change-Oriented Software Engineering Peter Ebraert, Jorge Antonio Vallejos Vargas, Pascal Costanza, Ellen Van Paesschen, Theo D'Hondt In "Proceedings of the 2007 International Conference on Dynamic Languages", published by ACM, 2007
21. ChOP - Logging 11 Implementation
22. ChOP - Logging 11 class Buffer { } Implementation
23. ChOP - Logging 11 class Buffer { } B1 B1 Implementation
24. ChOP - Logging 11 class Buffer { } int buf = 0; B1 B1 Implementation
25. ChOP - Logging 11 class Buffer { } int buf = 0; B2 B1 B1 B2 Implementation
26. ChOP - Logging 11 class Buffer { } int buf = 0; int get() { } return( buf ); void set( int x ) { } buf = x; B2 B1 B3 B4 B5 B6 B1 B2 B3 B4 B5 B6 Implementation
27. ChOP - Logging 11 class Buffer { } int buf = 0; int get() { } return( buf ); void set( int x ) { } buf = x; B2 B1 B3 B4 B5 B6 Buffer B1 B2 B3 B4 B5 B6 Implementation
28. Bottom up Feature Oriented Programming 12 class Buffer { int buf = 0; int get() { return( buf ); } void set( int x ) { buf = x; } } B1 B2 B3 B5 B4 B6 class Buffer { int buf = 0; int back = 0; int get() { return( buf ); } void set( int x ) { back = buf; buf = x; } void restore() { buf = back; } } R1 R2 R3 R4 class Buffer { int buf = 0; int back = 0; int get() { logit(); return( buf ); } void set( int x ) { logit(); back = buf; buf = x; } void restore() { logit(); buf = back; } void logit() { print(back); print(buf); } } L1 L5 L6 L2 L3 L4 class Buffer { int buf = 0; Stack back = Stack new(); int get() { logit(); return( buf ); } void set( int x ) { logit(); back.push(x); buf = x; } void restore() { logit(); buf = back.pop(); } void logit() { print(back.top()); print(buf); } } M4 M6 M1 M2 M3 M5 int buf = 0; int get() { return( buf ); } void set( int x ) { buf = x; } } B2 B3 B5 B4 B6 class Buffer { int buf = 0; int back = 0; int get() { return( buf ); } void set( int x ) { back = buf; buf = x; } void restore() { buf = back; } } R1 R2 R3 R4 class Buffer { int buf = 0; int back = 0; int get() { logit(); return( buf ); } void set( int x ) { logit(); back = buf; buf = x; } void restore() { logit(); buf = back; } void logit() { print(back); print(buf); } } L1 L5 L6 L2 L3 L4 class Buffer { int buf = 0; Stack back = Stack new(); int get() { logit(); return( buf ); } void set( int x ) { logit(); back.push(x); buf = x; } void restore() { logit(); buf = back.pop(); } void logit() { print(back.top()); print(buf); } } M4 M6 M1 M2 M3 M5 ; ) { B4 class Buffer { int buf = 0; int back = 0; int get() { return( buf ); } void set( int x ) { back = buf; buf = x; } void restore() { buf = back; } } R1 R2 R3 R4 ; ) { class Buffer { int buf = 0; Stack back = Stack new(); int get() { logit(); return( buf ); } void set( int x ) { logit(); back.push(x); buf = x; } M1 M2 M3 Implementation
29. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 13 Introduction Design Implementation Bridging the gap
30. Outline • Gap between Design and Implementation • FODA Diagrams • Change Oriented Programming • Change-Based FODA Diagrams 13 Introduction Design Implementation Bridging the gap
31. LogMethod Restore λ( )=5..5 λ( )=8..8 λ( )=3..3 Mul. Res λ( )=0..1 Buffer Logging PrintInstVars B2 B1 B4 B3 B6 B5 R1 R2 R4 R3 M4 M6 M1 M2 M3 M5 L1 opt_Buffer opt_Logging λ( )=0..1 opt_Restore opt_Mul.Res λ( )=0..1 opt_L5 λ( )=0..1 opt_L6 L6 L5 λ( )=0..1 opt_M6 L4 L2 L3 λ( )=0..1 opt_L4 Invoke Log opt_L3 λ( )=0..1 opt_L2 λ( )=6..6 λ( )=3..3 λ( )=2..2 λ( )=1..1 " ˰ 
    
     
     
     #   " 
    
    
    
    
    
    
    
     
    
    
    
    
    
    
    
    ! 
    
    
    
    
    
    
    
    
     
    
    
    
    
    
    # r λ( )=0..1 λ( )=0..1 λ( )=0..1 Generated Feature Diagram 14 Bridging the gap
32. Buffer Restore Logging Mul. Res Invoke Log LogMe thod PrintInst Vars B2 B1 B4 B3 B6 B5 R1 R2 R4 R3 M4 M6 M1 M2 M3 M5 L6 L5 L4 L2 L3 L1 Change Based FODA Diagram 15 () { R4 Stack new(); f ); x ) { x); () { pop(); .top()); M4 M6 M1 2 M3 M5 print(back); print(buf); } } L5 L6 print(back.top()); print(buf); } } void logit() { print(back); print(buf); } } L1 L5 L6 void logit() { print(back.top()); print(buf); } } ft to right: source of Restore, Logging, and MultipleRestore and the change specifica Buffer Restore Logging Mul. Res Invoke Log LogMe thod st B2 B1 B4 B3 B6 B5 R1 R2 R4 R3 M4 M6 M1 M2 M3 M5 L4 L2 L3 L1 B2 B1 R3 B2 M1 R1 B3 B1 R4 R1 M2 R3 B5 B1 R4 R2 M3 M2 B4 B3 R4 B2 M4 R4 B4 B2 L1 B1 M5 M4 B6 B2 L2 L1 M6 L5 B6 B5 L2 B3 L5 L1 R1 B1 L3 L1 L5 R1 R2 B1 L3 R2 L6 L1 R3 R1 L4 L1 L6 B2 R3 B3 L4 B5 e 4: Change-based FODA diagram representing the Bu er change specification. mplementation. Note that there is even ” dependency that shows up in Figure 4, t to depend on Restore. meaning” of the change-based FD (Fig- s that of the original change specifica- all change objects that make up the system. Anoth tant concept is that of a feature, so let F denote all features f i in the system. As seen in Section 2.3 consist of changes and can have sub-features. First, consider the sub-feature relation. A featu Bridging the gap
33. Buffer Restore Logging Mul. Res Invoke Log LogMe thod PrintInst Vars B2 B1 B4 B3 B6 B5 R1 R2 R4 R3 M4 M6 M1 M2 M3 M5 L6 L5 L4 L2 L3 L1 Change Based FODA Diagram 15 () { R4 Stack new(); f ); x ) { x); () { pop(); .top()); M4 M6 M1 2 M3 M5 print(back); print(buf); } } L5 L6 print(back.top()); print(buf); } } void logit() { print(back); print(buf); } } L1 L5 L6 void logit() { print(back.top()); print(buf); } } ft to right: source of Restore, Logging, and MultipleRestore and the change specifica Buffer Restore Logging Mul. Res Invoke Log LogMe thod st B2 B1 B4 B3 B6 B5 R1 R2 R4 R3 M4 M6 M1 M2 M3 M5 L4 L2 L3 L1 B2 B1 R3 B2 M1 R1 B3 B1 R4 R1 M2 R3 B5 B1 R4 R2 M3 M2 B4 B3 R4 B2 M4 R4 B4 B2 L1 B1 M5 M4 B6 B2 L2 L1 M6 L5 B6 B5 L2 B3 L5 L1 R1 B1 L3 L1 L5 R1 R2 B1 L3 R2 L6 L1 R3 R1 L4 L1 L6 B2 R3 B3 L4 B5 e 4: Change-based FODA diagram representing the Bu er change specification. mplementation. Note that there is even ” dependency that shows up in Figure 4, t to depend on Restore. meaning” of the change-based FD (Fig- s that of the original change specifica- all change objects that make up the system. Anoth tant concept is that of a feature, so let F denote all features f i in the system. As seen in Section 2.3 consist of changes and can have sub-features. First, consider the sub-feature relation. A featu Bridging the gap
34. Buffer Restore Logging Mul. Res Invoke Log LogMe thod PrintInst Vars B2 B1 B4 B3 B6 B5 R1 R2 R4 R3 M4 M6 M1 M2 M3 M5 L6 L5 L4 L2 L3 L1 Change Based FODA Diagram 15 () { R4 Stack new(); f ); x ) { x); () { pop(); .top()); M4 M6 M1 2 M3 M5 print(back); print(buf); } } L5 L6 print(back.top()); print(buf); } } void logit() { print(back); print(buf); } } L1 L5 L6 void logit() { print(back.top()); print(buf); } } ft to right: source of Restore, Logging, and MultipleRestore and the change specifica Buffer Restore Logging Mul. Res Invoke Log LogMe thod st B2 B1 B4 B3 B6 B5 R1 R2 R4 R3 M4 M6 M1 M2 M3 M5 L4 L2 L3 L1 B2 B1 R3 B2 M1 R1 B3 B1 R4 R1 M2 R3 B5 B1 R4 R2 M3 M2 B4 B3 R4 B2 M4 R4 B4 B2 L1 B1 M5 M4 B6 B2 L2 L1 M6 L5 B6 B5 L2 B3 L5 L1 R1 B1 L3 L1 L5 R1 R2 B1 L3 R2 L6 L1 R3 R1 L4 L1 L6 B2 R3 B3 L4 B5 e 4: Change-based FODA diagram representing the Bu er change specification. mplementation. Note that there is even ” dependency that shows up in Figure 4, t to depend on Restore. meaning” of the change-based FD (Fig- s that of the original change specifica- all change objects that make up the system. Anoth tant concept is that of a feature, so let F denote all features f i in the system. As seen in Section 2.3 consist of changes and can have sub-features. First, consider the sub-feature relation. A featu Bridging the gap Buffer Restore Logging Mul. Res Invoke Log LogMe thod PrintInst Vars
35. Take Home Message • Change Oriented Programming (http://peter.ebraert.be) • Change-based FODA bridges between design and implementation • provides links between design and implementation • reveals possible inconsistencies 16