1. James Nowotarski 2 October 2008 SE 325/425 Principles and Practices of Software Engineering Autumn 2008

2. 2 Topic Duration Design (cont. from 9/25)45 minutes V model30 minutes *** Break Current event reports 30 minutes Testing techniques60 minutes Today’s Agenda

3. 3 Design Communication project initiation requirements Modeling analysis design Construction code test Deployment delivery support Planning & Managing Primary deliverables Design model: Data/Class Architecture Interfaces Components

4. 4 Key principles of architectural design Abstraction Modularity Reuse

5. 5 Abstraction There is a limit to the number of ideas you can comprehend at any one time 7 +/- 2 Raise the level of detail by creating relationships Example: Grouping Think in logical instead of physical terms

6. 6 Modular design Reduces complexity Facilitates change Results in easier implementation by supporting parallel development of different parts of the system. Information hiding Functional independence Modularity

7. 7 Cohesion A measure of the relative functional strength of a module High Cohesion (good) Func A-1 Func A-2 Func A-3 Func B-1 Func B-2 Func B-3 Two qualitative criteria Coupling A measure of the relative interdependence among modules. High coupling (bad)

8. 8 Cohesion "Cohesion is the degree to which the tasks performed by a single module are functionally related.“ IEEE, 1983 "Cohesion is the "glue" that holds a module together. It can be thought of as the type of association among the component elements of a module. Generally, one wants the highest level of cohesion possible.“ Bergland, 1981 "A software component is said to exhibit a high degree of cohesion if the elements in that unit exhibit a high degree of functional relatedness. This means that each element in the program unit should be essential for that unit to achieve its purpose.“ Sommerville, 1989

9. 9 Cohesion A cohesive module performs a single task within a software procedure, i.e., it should do JUST ONE THING. Strive for HIGH cohesion. LowHigh “Scatter-brained”“Single-minded” CoincidentalLogicalTemporalProcedural Communicational SequentialFunctional Strive for high cohesion. Often acceptable. Almost as good as high cohesion. Much worse than mid level cohesion.

10. 10 Low Cohesion Logical Cohesion Tasks related very loosely. (e.g., a module that produces ALL output regardless of its type). public void logical_example( int flag ) { switch ( flag ) { case 1: // “1” related functionality; break; case 2: // “2” related functionality; break; case 3: // “3” related functionality; break; } Solution: Isolate each functionality into a separate operation / class etc.

11. 11 Low Cohesion Temporal Cohesion Tasks related by the fact that they must all be executed within the same span of time. Common examples include startup or end of job clean-up routines. procedure initializeData() { font = "times"; windowSize = "200,400"; foo.name = "Not Set"; foo.size = 12; foo.location = "/usr/local/lib/java"; } Give each object a constructor and destructor.

12. 12 Example of Low Cohesion A module that performs the following tasks when computed data exceed pre-specified bounds. Computes supplementary data based on original computed data. Produces an error report (with graphical content) on the user’s workstation Performs follow-up calculations requested by the user Updates a database Enables menu selection for subsequent processing. These functions are loosely connected but could best be implemented through individual modules.

13. 13 Moderate Cohesion Relatively close to one another in the degree of module independence. Procedural Cohesion Processing elements are related and must be executed in a specific order. Communicational Cohesion All processing elements concentrate on one area of a data structure. Sequential Cohesion The output data from one processing element serves as input data for the next processing element

14. 14 Functional Cohesion If the operations of a module can be collectively described as a single specific function in a coherent way, the module has functional cohesion. If not, the module has a lower type of cohesion. In an O-O system, Each operation in public interface of an object should be functional cohesive Each object should represent a single cohesive concept

15. 15 Coupling A measure of interconnection among modules in a program structure. Depends on The interface complexity between modules The point at which entry or reference is made to a module The data that pass across the interface. Goal is LOW coupling in order to increase understandability and reduce the rippling effect during change. LowHigh No direct coupling Data coupling Stamp coupling Control coupling External coupling Common coupling Content coupling

16. 16 Types of coupling a bc d e fgh i jk Global data area Data structure Data (variables) No direct coupling Control flag Module MModule M’ Data Coupling Stamp Coupling Control Coupling Common Coupling

17. 17 Low Coupling Data coupling Coupling is via a simple argument list through which simple data are passed. Stamp coupling Same as data coupling except a portion of a data structure is passed. Control coupling Passage of control between modules. (For example setting a control flag to control decisions in a subordinate module.) Very common in most software designs.

18. 18 High Coupling Common Coupling High level of coupling occurs when variables are tied to an environment external to software: I/O couples a module to specific devices, formats, communication protocols. In the example on the previous slide, c, g, and k all access a common data area. c initializes it, g updates it incorrectly, later k uses and an error occurs. It appears that the error is in k – whereas actually it is in g. The use of global data is not absolutely bad but: Should be used sparingly Developers should understand the possible implications.

19. 19 Highest Coupling Content Coupling One module makes use of data or control information maintained within the boundary of another module. Branches are made into the middle of a module. AVOID Content coupling. Information hiding hiding helps prevent content coupling.

20. 20 Design Heuristics 1. Evaluate the first iteration of the program structure to reduce coupling and improve cohesion. Implode or explode modules 2. Minimize structures with high fan-out; strive for fan-in as depth increases. Avoid structures as shown below:

21. 21 Design Heuristics 3. Keep scope of effect of a module within the scope of control of that module. The scope of control of a includes all modules that are subordinate to module a. (i.e., b,c,d,e,f) If module a makes a decision that impacts module h, then this heuristic is violated. a bcd g hi ef

22. 22 Topic Duration Design (cont. from 9/25)45 minutes V model30 minutes *** Break Current event reports 30 minutes Testing techniques60 minutes Today’s Agenda

23. 23 Software Engineering Body of Knowledge Software requirements Software design Software construction Software testing Software maintenance Software configuration management Software engineering management Software engineering process Software engineering tools and methods Software quality Source: Guide to the Software Engineering Body of Knowledge. (2004). IEEE. www.swebok.orgwww.swebok.org What is SE? tonight

24. 24 Verification & Validation Testing is just part of a broader topic referred to as Verification and Validation (V&V) Pressman/Boehm/IEEE: Verification: Are we building the product right? Validation: Are we building the right product?

25. 25 Some overriding principles DRTFT Do it right the first time “The first mistake that people make is thinking that the testing team is responsible for assuring quality.” -- Brian Marick. Stage Containment

26. 26 Stage Containment Communication project initiation requirements Modeling analysis design Construction code test Deployment delivery support Planning & Managing errorError detectiondefectfault Error origination 

27. 27 V-Model System engineering Requirements Integration Test Unit Test Code External/Internal Design Detailed Design System Test Validation Test Testing: Test that the product implements the specification Flow of Work Verification Validation Legend:

28. 28 Terminology Testing - Ensures that the components of the application are put together correctly, according to the different levels of specification. Testing consists of exercising a newly integrated portion of the application by running a number of test cases in controlled mode. Each test case is designed to test a statement of the specification. Verification - Verification is the checking of a deliverable against a standard of work set out for the process that produces the deliverable. The sources for this standard include: 1) Exit criteria defined for each task; 2) Design and coding standards set up by the project team; 3) Evidence that the process prescribed for executing the activity has been followed; 4) Consistency and completeness checks; 5) Models and templates described as part of the application architecture; 6) Standards set up for using the technical architecture. Verification is usually done through reviews, inspections, and walk- throughs. Validation - Validation is the checking of a deliverable against the specification/requirements implemented by that deliverable (e.g., checking a database design against the data model). Stage Containment - Stage containment is a project management objective driven by the desire to minimize the number of defects or faults discovered after the work has been completed and handed off to the next stage of the development process. Activities to achieve stage containment include verification, validation, and testing. Entry/Exit Criteria - Entry and exit criteria are predefined standards that deliverables must meet before exiting one development stage and entering another. A team handing work off to another part of the project must fully satisfy their exit criteria, while the receiving team verifies that the work meets their standard entry criteria. The entry criteria for a receiving team are frequently the same as the exit criteria for the delivering team. V Model - The V model of verification, validation, and testing provides a structured testing framework throughout the development process and ensures that both verification and validation are applied to deliverables within a system.

29. 29 V-Model: Optional Tests System engineering Requirements Integration Test Unit Test Code External/Internal Design Detailed Design System Test Validation Test Testing: Test that the product implements the specification Flow of Work Verification Validation Legend: May include: Performance test Usability test Stress test Inter-Application integration test Hardware/Software integration test Restart/Recovery test Operational readiness test Benefits realization test

30. 30 V-Model: The Testing Process System engineering Requirements Integration Test Unit Test Code External/Internal Design Detailed Design System Test Validation Test Testing: Test that the product implements the specification Flow of Work Verification Validation Legend: For each activity on left side of V: Develop test conditions and cycles Develop entry and exit criteria for corresponding test For each activity on right side of V: Set up environment and test team Execute test and capture actual and expected results, identify errors, correct, and regression test

31. 31 Topic Duration Design (cont. from 9/25)45 minutes V model30 minutes *** Break Current event reports 30 minutes Testing techniques60 minutes Today’s Agenda

32. 32 V-Model System engineering Requirements Integration Test Unit Test Code External/Internal Design Detailed Design System Test Validation Test Testing: Test that the product implements the specification Flow of Work Verification Validation Legend: Unit testing

33. 33 Unit testing Focuses on a single software component or module. Design description guides test generation to Ensure coverage of important control paths Test the boundaries of the module. Focuses on internal processing logic and data structures. Specific tests/Common errors

34. 34 As no unit operates in a vacuum it is necessary to create stubs and drivers. Module to be tested Stub Driver RESULTS Test cases Interface Local data structures Boundary conditions Independent paths Error handling paths Pressman: 6 th ed., Figure 13.4 Unit test environment

35. 35 V-Model System engineering Requirements Integration Test Unit Test Code External/Internal Design Detailed Design System Test Validation Test Testing: Test that the product implements the specification Flow of Work Verification Validation Legend: Integration testing

36. 36 Integration testing Integration testing is a systematic technique for constructing the software architecture while at the same time conducting tests to uncover errors associated with the interfacing. BIG BANG integration is not advisable! Incremental, piece-meal approaches: Top-down Bottom-up Sandwich Regression testing Ensure changes do not introduce unintended side effects

37. 37 Modules are integrated by moving downward through the control hierarchy. Depth-first approach incorporates all components on a major control path. Example: M 1, M 2, M 6, M 8 Breadth-first approach incorporates all components directly subordinate at each level. Example: M 2, M 3, M 4. M1M1 M3M3 M2M2 M4M4 M6M6 M5M5 M7M7 M8M8 Top-down integration

38. 38 MaMa Mc D3D3 Cluster 1 Cluster 3 MbMb Cluster 2 D1D1 D2D2 Bottom-up integration

39. 39 The re-execution of some subset of tests that have already been conducted to ensure that changes have not introduced unintended side effects. Whenever change is introduced or existing tests uncover errors that are fixed – there is opportunity for new errors to be introduced. Supported by capture/playback tools. Regression testing includes: Tests focusing on the software components that have been changed. Additional tests that focus on software functions that are likely to be affected by the change. A representative sample of tests that will exercise all software functions. Regression testing

40. 40 Independent Test Group (ITG)

41. 41 Example of pair programming “Since then, [Adobe’s] Mr. Ludwig has adopted Fortify software and improved communication between his team of security experts and programmers who write software. A few years ago, each group worked more or less separately: The programmers coded, then the quality-assurance team checked for mistakes. Now, programmers and security types often sit side by side at a computer, sometimes lobbing pieces of code back and forth several times a day until they believe it is airtight. The result: ‘Issues are being found earlier,’ Mr. Ludwig says. But, he adds, ‘I'm still trying to shift that curve.’ “ Vara, V. (2006, May 4). Tech companies check software earlier for flaws. Wall Street Journal. Retrieved October 16, 2006, from http://online.wsj.com/public/article/SB114670277515443282- qA6x6jia_8OO97Lutaoou7Ddjz0_20060603.html?mod=tff_main_tff_top

42. 42 White box vs. Black box

43. 43 White box vs. Black box Inputs designed to test a system function Outputs (should match intended functionality)

44. 44 White box vs. Black box White boxBlack box Structural testing Logic paths Loops Internal variables Error conditions Functional testing Incorrect/missing functions Interface errors Performance errors

45. 45 V-Model Integration Test Unit Test Code System Test Validation Test White box Black box

46. 46 First proposed by Tom McCabe in 1976. Enables the test case designer to derive a logical complexity measure of the procedural design. Uses this measure as the basis for defining an upper bound on the number of execution paths needed to guarantee that every statement in the program ins executed at least once. Uses a notation known as a flow graph. Basis Path Testing

47. 47 Sequence if Case whileuntil Where each circle represents one or more nonbranching set of source code statements. Flow Graph Notation

48. 48 Flow chart and corresponding flow graph. 1 2 3 6 4 578 9 10 11 1 2,3 10 11 6 9 84,57

49. 49 Compound logic A compound condition occurs when one or more Boolean operators (logical OR, AND, NAND, NOR) is present in a conditional statement. Example: if a OR b then do X else do Y end if a b xy x a b xy

50. 50 Any path through the program that introduces at least one new set of processing statements or a new condition. In terms of a flow graph, an independent path must move along at least one edge that has not previously been traversed. In the previous flow chart/flow graph example: path 1: 1-11 path 2: 1-2-3-4-5-10-1-11 path 3: 1-2-3-6-8-9-10-1-11 path 4: 1-2-3-6-7-9-10-1-11 The path: 1-2-3-4-5-10-1-2-3-6-8-9-10-1-11 is NOT an independent path because it does not traverse any new edges. Independence path

51. 51 Independent paths constitute a basis set for the flow graph. Design tests to execute these paths. Guarantees: Every statement has been executed at least once. Every condition has been executed on both its true and false sides. There is more than ONE correct set of basis paths for a given problem. How many paths should we look for? Calculate cyclomatic complexity V(G) V(G) = E-N+2 (E = # edges, N = # nodes) V(G) = P + 1 (Where P = number of predicate nodes) V(G) = R (Where R = number of regions) Basis Set

52. 52 An Example: Procedure Average (Pressman 6e, p.397, Figure 14.4) * This procedure computes the average of 100 or fewer numbers that lie between bounding values; it also computes the sum of the total number valid. INTERFACE RETURNS average, total.input, total.valid; INTERFACE ACCEPTS value, minimum, maximum; TYPE value[1:100] IS SCALAR ARRAY; TYPE average, total.input, total.valid; minimum, maximum, sum IS SCALAR; TYPE i IS INTEGER;

53. 53 Continued… i = 1; total.input = total.valid = 0; sum = 0; DO WHILE value[i] <> -999 AND total.input = minimum and value[i] <= maximum THEN increment total.valid by 1; sum = sum + value[i] ELSE skip ENDIF increment i by 1; ENDDO IF total.valid > 0 THEN average = sum / total.valid; ELSE average = -999; ENDIF END average 1 2 3 4 5 6 7 8 9 10 11 12 13

54. 54 1. Use the design or code as a foundation and draw corresponding flow graph. 1 2 3 4 5 6 7 8 9 10 13 1211 Steps for deriving test cases 2. Determine the cyclomatic complexity of the resultant flow graph. V(G) = 17 edges – 13 nodes + 2 = 6 V(G) = 5 predicate nodes + 1 = 6.

55. 55 3. Determine a basis set of linearly independent paths. 1 2 3 4 5 6 7 8 9 10 13 1211 Steps for deriving test cases Path 1: 1-2-10-11-13 Path 2: 1-2-10-12-13 Path 3: 1-2-3-10-11-13 Path 4: 1-2-3-4-5-8-9-2… Path 5: 1-2-3-4-5-6-8-9-2… Path 6: 1-2-3-4-5-6-7-8-9-2… 4. Prepare test cases that will force execution of each path in the basis set.

56. 56 Infeasible Paths Some paths are infeasible… Begin 1.Readln (a); 2. If a > 15 then 3. b:=b+1; else 4. c:=c+1; 5. if a < 10 then 6.d:=d+1; 7.end V(G) = 3: There are three basis paths: Path 1: 1,2,3,5,7 Path 2: 1,2,4,5,7 Path 3: 1,2,3,5,6,7 Which of these paths is non- executable and why?

57. 57 Basis Path Testing In small groups Derive a data flow graph from the code (see next slide). Define independence paths (basis set) Derive tests to drive each path in the basis set

58. 58 Code for small group activitiy (Valid pins 10000-19999): Procedure Validate_Pin (Valid_Pin, Return_Code) Valid_Pin = FALSE Return_Code = GOOD Pin_Count = 0 do until Valid_Pin = TRUE or Pin_Count > 2 or Return_Code = CANCEL begin get Pin_Number (Pin_Number, Return_Code) if (Return_Code ≠ CANCEL) begin call Validate Pin_Number (Pin_Number, Valid_Pin) if (Valid_Pin = FALSE) then begin output “Invalid PIN, please re-enter PIN” Pin_Count = Pin_Count + 1 end return (Valid_Pin, Return_Code)

59. 59 Read Pressman Chapters 23, 24 Current event reports For October 9

60. 60 Statement coverage: Goal is to execute each statement at least once. Branch coverage Goal is to execute each branch at least once. Path coverage Where a path is a feasible sequence of statements that can be taken during the execution of the program. What % of each type of coverage does this test execution provide? 5/10 = 50% 2/6  33% 1/4  25% Where does the 4 come from? = tested = not tested Test Coverage Metrics