2. CS 325: Software Engineering February 16, 2016 Designing a Design Class Diagram Design Class Diagrams DCD: Restaurant Example DCD: ATM Example Software Testing

3. Design Class Diagrams CS 325 February 16, 2016 Designing a Design Class Diagram Page 95 The class diagrams developed for domain modeling are somewhat informal. Once sequence diagrams have been developed during object interaction modeling, a clearer understanding of the upcoming implementation, testing, and integration of the software system is possible.

4. DCD: Restaurant Example CS 325 February 16, 2016 Designing a Design Class Diagram Page 96 Consider this sequence diagram for eating at a restaurant.

5. DCD: Restaurant Example CS 325 February 16, 2016 Designing a Design Class Diagram Page 97 Identify classes from objects that send or receive messages, that are passed as parameters, or that serve as return types. Identify operations from the sequence diagram messages. Identify attributes from operations that retrieve objects, from get and set operations, from scalar calculation operations, and from constructor parameters. Identify associations that create (from constructor calls) and that use (from parameters and return types).

6. DCD: ATM Example CS 325 February 16, 2016 Designing a Design Class Diagram Page 98 Consider this sequence diagram for ATM money withdrawal.

7. DCD: ATM Example CS 325 February 16, 2016 Designing a Design Class Diagram Page 99 Identifying classes. Identifying operations. Identifying attributes. Identifying associations.

8. Software Testing CS 325 February 16, 2016 Designing a Design Class Diagram Page 100 Testing is a technical investigation process intended to reveal quality-related information about software The standard progression of software testing: UnitTesting Programmers test the minimal software components (i.e., classes and modules) UnitTesting Integration Testing Expose the defects in the interfaces between integrated modules Integration Testing Expose the defects in the interfaces between integrated modules Validation Testing Ensure that the implemented software meets customer requirements Validation Testing Ensure that the implemented software meets customer requirements System Testing Determine whether the software will work as desired when installed System Testing Determine whether the software will work as desired when installed Acceptance Testing The client tests the delivered software to decide whether it is in an acceptable form Acceptance Testing The client tests the delivered software to decide whether it is in an acceptable form

9. Unit Testing CS 325 February 16, 2016 Designing a Design Class Diagram Page 101 To facilitate the diagnosis of problems within a module, it is usually necessary to isolate that module Place the module or class being tested in an artificial environment that allows you to focus upon its performance. Stub programs are used to replace modules that are called by the module being tested. A dummy driver program merely accepts test case data and passes it to the module being tested. The module being tested.

10. Integration Testing CS 325 February 16, 2016 Designing a Design Class Diagram Page 102 While individual modules might pass their unit tests, they might not work correctly when integrated together Integration Alternatives: Big Bang: Test all modules simultaneously ({A, B, C, D, E, F, G, H}) Fine for small, well-structured systems, but locating bugs may be tough Top-Down: Incrementally test from the driver down ({A} with stubs for {B,C,D}, then {A, B, C, D} with stubs for {E, F, G, H}, then {A, B, C, D, E, F, G, H}) Helps localize bugs, but deep nodes are tested last, hurting performance Bottom-Up: Incrementally test starting at primitive modules ({E}, {F}, {G}, {H}, each with a dummy driver for {C}, then {B}, {C, E, F, G, H}, {D}, each with a dummy driver for {A}, then {A, B, C, D, E, F, G, H}) Early validation of performance-critical modules, but overall validation is delayed

11. Validation Testing Rather than testing the internal code, at some point the overall functionality of the software needs to be tested White-box testing is performed by programmers who utilize their skills to examine all of the paths through the software to diagnose internal problems. Black-box testing, on the other hand, takes an external perspective, with the test designer selecting valid and invalid input and examining the corresponding output for accuracy. CS 325 February 16, 2016 Designing a Design Class Diagram Page 103

12. System Testing CS 325 February 16, 2016 Designing a Design Class Diagram Page 104 After the software has been fully integrated, its compliance with its specified requirements must be tested Recovery testing is used to determine how well software can recover from crashes, hardware failures, etc. Security testing is used to determine how well software is protected from outside penetration Stress testing is used to determine how well software deals with extreme demands on its resources (e.g., memory, processing) Performance testing is used to determine the speed with which software deals with various workloads

13. Acceptance Testing CS 325 February 16, 2016 Designing a Design Class Diagram Page 105 In preparation for the software’s actual release, early versions may be provided to clients for testing Alpha testing is performed by clients on iterations of the software to which new features are still being added Beta testing is performed at a stage when all primary features have been added, but active debugging is still taking place