Introduction to Software Engineering Lecture 9

1. Introduction to Software EngineeringLecture 9 André van der Hoek

2. Today’s Lecture • Integration test plan • Implementation

3. A Good Design… • …is half the implementation effort! • Rigor ensures all requirements are addressed • Separation of concerns • Modularity allows work in isolation because components are independent of each other • Abstraction allows work in isolation because interfaces guarantee that components will work together • Anticipation of change allows changes to be absorbed seamlessly • Generality allows components to be reused throughout the system • Incrementality allows the software to be developed with intermediate working results

4. A Bad Design… • …will never be implemented! • Lack of rigor leads to missing functionality • Separation of concerns • Lack of modularity leads to conflicts among developers • Lack of abstraction leads to massive integration problems (and headaches) • Lack of anticipation of change leads to redesigns and reimplementations • Lack of generality leads to “code bloat” • Lack of incrementality leads to a big-bang approach that is likely to “bomb”

5. Develop Requirements Execute System Tests Requirements Review Develop Acceptance Tests Acceptance Test Review Design Execute Integration Tests Design Review Develop Integration Tests Integration Tests Review Code Execute Unit Tests Code Review Develop Unit Tests Unit Tests Review V-Model of Development and Testing

6. Integration Test Plan • Ensures module implementations adhere to assumptions and interfaces as designed • Uncovering interactions that highlight problems with assumptions is difficult • Approach • Combine more and more modules • Use USES hierarchy • Work up from lowest numbers • Use test harnesses to test each group of modules • Work down from highest numbers • Use stubs as mockups to test each group of modules • Can be done during implementation effort

7. Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Subcomponent Subcomponent Subcomponent Subcomponent Subcomponent Main component Subcomponent Subcomponent Subcomponent Required Interface Required Interface Required Interface Required Interface Required Interface Required Interface Required Interface Required Interface Required Interface Integration Test Example

8. Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Subcomponent Subcomponent Subcomponent Subcomponent Subcomponent Required Interface Required Interface Required Interface Required Interface Required Interface Test Harnesses Provided Interface Provided Interface Test Harness Test Harness Required Interface Required Interface

9. Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Provided Interface Subcomponent Subcomponent Subcomponent Subcomponent Subcomponent Subcomponent Subcomponent Subcomponent Required Interface Required Interface Required Interface Required Interface Required Interface Required Interface Required Interface Required Interface Test Harnesses Provided Interface Test Harness Required Interface

10. Stubs Provided Interface Main component Required Interface Provided Interface Provided Interface Provided Interface Stub Stub Stub Required Interface Required Interface Required Interface

11. Stubs Provided Interface Main component Required Interface Provided Interface Provided Interface Provided Interface Subcomponent Stub Stub Required Interface Required Interface Required Interface Provided Interface Provided Interface Stub Stub Required Interface Required Interface

12. Stubs Provided Interface Main component Required Interface Provided Interface Provided Interface Provided Interface Subcomponent Subcomponent Stub Required Interface Required Interface Required Interface Provided Interface Provided Interface Stub Stub Required Interface Required Interface

13. Design phase Testing phase Verify Verify ICS 52 Life Cycle Requirements phase Verify Implementation phase Test

14. Design/Implementation Interaction Design (previous lectures) Implementation (this lecture)

15. From Design to Implementation • Choose a suitable implementation language • Establish coding conventions • Divide work effort • Implement • Code • Unit tests • Code reviews • Inspections • Perform integration tests

16. Choose a Suitable Language • 4th Generation language • Databases • Visual Basic • Forms • “Real” programming language • Python • Java + Class Libraries • C++/C + STL (Standard Template Library) • Cobol • Fortran • Assembly language • Machine specific

17. Choose a Suitable Language • Maintain the design “picture” • Mapping of design elements onto implementation • Module inside versus outside • Does the language enforce a boundary? • Interfaces! • Explicit representation of uses relationship • Error handling • Return values • Exceptions

18. Establish Coding Conventions • #define _POSIX_SOURCE /* you are not supposed to understand this */ #define O(OOO,OO0,O00,O0O,OO,O0)\0##O0O%:%:OO\0##O0%:%:OOO\0##OO0%:%:O00 #include static volatile sig_atomic_t One; #include #include #define Zero(NULL)#NULL #define ONE(One) Zero(One) in??/ t #line 10 "01\015" main (register zero, char **ONE) %: } www.ioccc.org

19. Java Too! • import java.awt.*;import java.util.*;public class C extends Frame{Date D=new Date();void T(Date d){D=d;repaint();}double P=Math.PI,A=P/2,a,c,U=.05;int W,H,m,R;double E(int a,int u){return(3*P/2+2*P*a/u)%(2*P);}void N(Graphics g,double q,double s){g.fillPolygon(new int[]{H(s,q),H(U,q+A),H(U,q+3*A)},new int[]{J(s,q),J(U,q+A),J(U,q+3*A)},3);}public void paint(Graphics g){Color C=SystemColor.control;g.setColor(C);g.fillRect(0,0,W=size().width,H=size().height);W-=52;H-=52;R=Math.min(W/2,H/2);g.translate(W/2+25,H/2+36);g.setColor(C.darker());for(m=0;m<12;++m){a=E(m,12);g.drawLine(H(.8),J(.8),H(.9),J(.9));}m=D.getMinutes();N(g,E(D.getHours()*60+m,720),.5);N(g,E(m,60),.8);N(g,E(D.getSeconds(),60),.9);}int H(double y){return(int)(R*y*Math.cos(a));}int H(double y,double q){a=q;return H(y);}int J(double y){return(int)(R*y*Math.sin(a));}int J(double y,double q){a=q;return J(y);}public static void main(String[]_)throws Exception{C c=new C();c.resize(200,200);c.show();for(;;){c.T(new Date());Thread.sleep(200);}}}

20. Establish Coding Conventions • Naming • Avoid confusing characters • 1, l, L, o, O, 0, S, 5, G, 6 • Avoid misleading names • Avoid names with similar meaning • Use capitalization wisely • Code layout • White space / blank lines • Grouping • Alignment • Indentation • Parentheses

21. Divide Work Effort • Assign different modules to different developers • Assignments can be incremental • Assignments change • Illness • New employees • Employees who quit • Schedule adjustments • Star programmers • Interfaces are tremendously important • “Contracts” among modules

22. Coding • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY • FIRST MAKE IT WORK CLEANLY

23. Code Optimizations • Only make optimizations to a cleanly working module if absolutely necessary • Performance • Memory usage • Isolate these optimizations • Document these optimizations Empirical evidence has proven that these optimizationsare rarely needed and that if they are needed, they areonly needed in a few critical places

24. Defensive Programming • Make your code robust and reliable • Use assertions • Use tracing • Handle, do not ignore, exceptions • Contain the damage caused • Garbage in does not mean garbage out • Anticipate changes • Check return values • Plan to be able to remove debugging aids in the final, deliverable version Do not sacrifice any of these when facing a deadline

25. Comments • Self documenting code does not exist! • Meaningful variable names, crisp code layout, and small and simple modules all help… • …but they are not enough • Every module needs a description of its purpose • Every function needs a description of its purpose, input and output parameters, return values, and exceptions • Every piece of code that remotely may need explanation should be explained

26. Develop Requirements Execute System Tests Requirements Review Develop Acceptance Tests Acceptance Test Review Design Execute Integration Tests Design Review Develop Integration Tests Integration Tests Review Code Execute Unit Tests Code Review Develop Unit Tests Unit Tests Review V-Model of Development and Testing

27. Unit Tests • Developer tests the code just produced • Needs to ensure that the code functions properly before releasing it to the other developers • Benefits • Knows the code best • Has easy access to the code • Drawbacks • Bias • “I trust my code” • “I always write correct code” • Blind spots

28. Code Reviews (“Walk-throughs”) • Developer presents the code to a small group of colleagues • Developer describes software • Developer describes how it works • “Walks through the code” • Free-form commentary/questioning by colleagues • Benefits • Many eyes, many minds • Effective • Drawbacks • Can lead to problems between developer and colleagues

29. Inspections • Developer presents the code to a small group of colleagues • Colleagues look for predefined types of errors • Checklists • Colleagues read code beforehand • Moderator leads discussion • Benefits • Avoids personal “attacks” • Effective • Drawbacks • Only verifies code with respect to a predefined list of problem areas

30. Use the Principles • Rigor and formality • Separation of concerns • Modularity • Abstraction • Anticipation of change • Generality • Incrementality

31. Your Tasks • Read and study slides of this lecture