SE 325/425 Principles and Practices of Software Engineering Autumn 2008

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

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

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

4. Key principles of architectural design • Abstraction • Modularity • Reuse

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. Modularity • Modular design • Reduces complexity • Facilitates change • Results in easier implementation by supporting parallel development of different parts of the system. • Information hiding • Functional independence

7. Two qualitative criteria • CohesionA 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 • CouplingA measure of the relative interdependence among modules. High coupling (bad)

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. Communicational Coincidental Logical Temporal Procedural Sequential Functional Low High “Scatter-brained” “Single-minded” Much worse than mid level cohesion. Often acceptable. Almost as good as high cohesion. Strive for high cohesion. Cohesion • A cohesive module performs a single task within a software procedure, i.e., it should do JUST ONE THING. • Strive for HIGH cohesion.

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. Low Cohesion • Temporal CohesionTasks 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. 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. Moderate Cohesion • Relatively close to one another in the degree of module independence. • Procedural CohesionProcessing elements are related and must be executed in a specific order. • Communicational CohesionAll processing elements concentrate on one area of a data structure. • Sequential CohesionThe output data from one processing element serves as input data for the next processing element

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. No direct coupling Data coupling Stamp coupling Control coupling Common coupling Content coupling External coupling Low High 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.

16. Types of coupling Module M Module M’ No direct coupling a d i Data (variables) Data structure Controlflag Stamp Coupling Data Coupling ControlCoupling j k b c e f g h Global data area CommonCoupling

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

18. High Coupling • Common CouplingHigh 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. 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. Design Heuristics • Evaluate the first iteration of the program structure to reduce coupling and improve cohesion. • Implode or explode modules • Minimize structures with high fan-out; strive for fan-in as depth increases. • Avoid structures as shown below:

21. g a b c d h i e f Design Heuristics • 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.

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

23. What is SE? • 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.org tonight tonight 23

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. 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.  Error origination defect fault Stage Containment Planning & Managing Communication project initiation requirements Modeling analysis design Construction code test Deployment delivery support Error detection error

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

28. Terminology 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. 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). 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. 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.

29. System Test Validation Test System engineering Requirements Unit Test External/Internal Design Detailed Design Code Legend: Validation Flow of Work Testing: Test that the product implements the specification Verification V-Model: Optional Tests • 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 Integration Test

30. System Test Validation Test System engineering Requirements Unit Test External/Internal Design Detailed Design Code Legend: Validation Flow of Work Testing: Test that the product implements the specification Verification V-Model: The Testing Process Integration Test • 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. Today’s Agenda Topic Duration • Design (cont. from 9/25) 45 minutes • V model 30 minutes *** Break • Current event reports 30 minutes • Testing techniques 60 minutes

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

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. Unit test environment • As no unit operates in a vacuum it is necessary to create stubs and drivers. InterfaceLocal data structuresBoundary conditionsIndependent pathsError handling paths Driver Moduleto betested Stub Stub Testcases Pressman: 6th ed., Figure 13.4 RESULTS

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

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. M1 M2 M3 M4 M5 M6 M7 M8 Top-down integration • Modules are integratedby moving downward throughthe control hierarchy. • Depth-first approachincorporates all components on a major control path.Example: M1, M2, M6, M8 • Breadth-first approachincorporates allcomponents directly subordinate at each level.Example: M2, M3, M4.

38. Bottom-up integration Mc Ma Mb D1 D2 D3 Cluster3 Cluster1 Cluster 2

39. Regression testing • 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.

40. Independent Test Group (ITG)

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. White box vs. Black box

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

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

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

46. Basis Path Testing • 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.

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

48. Flow chart and corresponding flow graph. 1 1 2,3 2 6 3 7 8 4,5 6 4 9 7 8 5 10 9 10 11 11

49. a b x y x 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 bthen do Xelse do Yend if a b y x

50. Independence path • 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-11path 2: 1-2-3-4-5-10-1-11path 3: 1-2-3-6-8-9-10-1-11path 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.