8 UNIT TESTING Software Engineering Roadmap Chapter 8

8. UNIT TESTING

Software Engineering Roadmap: Chapter 8 Focus Identify corporate practices Test units (parts) separately - use implementations - apply discipline - gain coverage Plan project Maintain Analyze requirements Integrate & test system Design Implement Test units Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Learning Goals of This Chapter • Understand meaning of unit testing • Distinguish black box vs. white box testing • Attain proper test coverage • Learn a testing standard • Inspect a unit test plan Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

1. Introduction to unit testing

Golden Rules of Testing Goal of testing: maximize the number and severity of defects found per dollar spent – thus: test early

Golden Rules of Testing Goal of testing: maximize the number and severity of defects found per dollar spent – thus: test early Limits of testing: Testing can only determine the presence of defects, never their absence – use proofs of correctness to establish “absence” Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Testing: the Big Picture 3. System tests 2. Integration tests 1. Unit tests Module combination Module Function

Testing: the Big Picture 3. System tests Include use-cases 2. Integration tests 1. Unit tests OO: Module combination Module Function Packages of classes Combinations of methods in class Methods

Unified Process Inception Elaboration Jacobson et al: USDP Construction Transition Requirements Analysis Design Implementation Test Prelim. Iter. iterations #1 Iter. #n #n+1 …. . Iter. #m #m+1 Iter. #k

Unified Process Inception Elaboration Jacobson et al: USDP Construction Transition Requirements Analysis Design Implementation Unit Tests Test Prelim. Iter. iterations #1 Iter. #n #n+1 Integration tests. . . System tests …. . Iter. …. . #m #m+1 Iter. #k

Road. Map for Unit Testing Requirements 1. Plan for unit testing Detailed design -- see section SSS . . Test results

Road. Map for Unit Testing Requirements 1. Plan for unit testing Detailed design -- see section SSS Identify largest trouble spots Unit test plan Products of prior testing 2. Acquire test set -- see section SSS Test set Code under test 3. Execute unit test -- see section SSS Test results IEEE, 1986

2. Test types

Black-, Gray-, & White-box Testing Input determined by. . . … requirements* * from previous phase Result Black box Actual output compared with required

Input determined by. . . Black-, Gray-, & White-box Testing … requirements Black box … requirements & key design elements Gray box Result Actual output compared with required output As for blackand white box testing White box …design elements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Confirmation of expected behavior

Test Input Possibilities Infinitely many illegal values: choose a finite sample. principal $100 M 20% Infinitely many legal values: choose a finite sample. inflation 25% estimate 1% Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. 0% interest rate

Test Input Partitioning and Boundaries An illegal region principal $100 M 20% inflation Range of valid inputs estimate 25% 1% 0% Equivalence partitions Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. interest rate

Testing Ranges: Elementary Cases 1. within range 2. at the boundaries of the range 3. outside the range (“illegal”) Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. range

Covering Every Statement is Not Sufficient (Myers) Required program u>1 and v==0 Yes x = x/u No u==2 or x>0 No Yes ++x

Covering Every Statement is Not Sufficient (Myers) Required program u>1 and v==0 Yes x = x/u No u==2 or x>0 No Yes ++x Code attempt to implement flowchart if( (u>1) && (v==0) ) x = x/u; if( (u==2) || (x>3) ) ++x; (1) (2) (3) (4) u=2, v=0 and x=3 • executes every line (1) - (4) • gives the correct output x= 2. 5 However, line (3) is wrong

Paths to be Checked N Set _name to “default. Name" Parameter & settings make sense? N Set _name to parameter Y Parameter name too long? Y Truncate name

Paths to be Checked N Set _name to “default. Name" Decision Coverage Parameter & settings make sense? N Y Parameter name too long? Set _name to parameter Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Y Truncate name

Assertion-based testing for max() 1/2 public static boolean check. Assertion Defining the assertion checker ( int loop. So. Far. P, int index. Of. Max. P, double[] array. P ) { // First establish following booleans: boolean b 1 M = true; /* means values of array. P[ ] are lower than array. P[ index. Of. Max. P ] for all indices < index. Of. Max. P */ if( index. Of. Max. P != 0 ) // b 1 M true if max so far is first element for( int u = 0; u < index. Of. Max. P; ++u ) b 1 M &= ( array. P[u] < array. P[ index. Of. Max. P ] ); . .

Assertion-based Testing public static boolean check. Assertion for max() ( int loop. So. Far. P, int index. Of. Max. P, double[] array. P ) Defining an { Assertion Checker: // First establish following booleans: 1 of 2: boolean b 1 M = true; /* means values of array. P[ ] are lower than array. P[ index. Of. Max. P ] for all indices < index. Of. Max. P */ if( index. Of. Max. P != 0 ) // b 1 M true if max so far is first element for( int u = 0; u < index. Of. Max. P; ++u ) b 1 M &= ( array. P[u] < array. P[ index. Of. Max. P ] ); boolean b 2 M = true; /* means vals. of array. P[ ] no higher than array. P[ index. Of. Max. P ] for indices index. Of. Max. P … loop. So. Far. P */ for( int v = index. Of. Max. P; v <= loop. So. Far. P; ++v ) b 2 M &= ( array. P[v] <= array. P[ index. Of. Max. P ] ); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Defining an Assertion Checker for max(): 2 of 2 if ( // Loop has progressed up to index loop. So. Far. P ( 0 <= loop. So. Far. P ) && (loop. So. Far. P < array. P. length ) && // index. Of. Max. P is the index <= loop. So. Far. P. . . ( 0 <= index. Of. Max. P ) && ( index. Of. Max. P <= loop. So. Far. P ) && b 1 M && b 2 M //. . . where the first max occurs ) { System. out. println( "Assertion valid" ); return true; } else { System. out. println( "Assertion invalid" ); return false; Adapted from Software } Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

/** Finds index & value of first of the largest array elements. . . */ public static void main( String[] main. Arg ) Applying Assertion-based { testing to max() double[] a = get. Array(); // Let I be the assertion … (see section tbd of chapter 7). . . Establish I int i = 0; int k = 0; boolean validity. M = check. Assertion( i, k, a ); // assertion test // Following preserves I. … terminates. … (section tbd of chapter 7) while( i != a. length - 1 ) { ++i; if( a[i] > a[k] ) k = i; validity. M = validity. M && check. Assertion( i, k, a ); // assertion test } System. out. println( "First max value is " + a[k] + " at index " + Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. k );

3. Planning unit tests

Plan for Unit Testing 1. Decide on the philosophy for unit testing – individual engineer responsible (common)? – reviewed by others? – designed & performed by others? 2. Decide what / where / how to document – – individual’s personal document set (common)? how / when to incorporate into other types of testing? incorporate in formal documents? use tools / test utilities? 3. Determine extent of unit testing (i. e. , in advance). – do not just “test until time expires” – prioritize, so that important tests definitely performed 4. Decide how and where to get the test input – see section tbd. 5. Estimate the resources required – use historical data if available 6. Arrange to track time, defect count, type & source Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Checklists and examples for method testing

Perform Method Testing (Humphrey) 1/2 1. Verify operation at normal parameter values (a black box test based on the unit’s requirements) 2. Verify operation at limit parameter values (black box) 3. Verify operation outside parameter values (black box) 4. Ensure that all instructions execute (statement coverage) 5. Check all paths, including both sides of all branches (decision coverage) 6. Check the use of all called objects 7. Verify the handling of all data structures 8. Verify the handling of all files Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Perform Method Testing (Humphrey) 2/2 9. Check normal termination of all loops (part of a correctness proof) 10. Check abnormal termination of all loops 11. Check normal termination of all recursions 12. Check abnormal termination of all recursions 13. Verify the handling of all error conditions 14. Check timing and synchronization 15. Verify all hardware dependencies Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

4. Checklists and examples for method testing

Relating Tests to Requirements & Design (1) D-Requirements (2) Design Game. Character 3. 2. EC. 1. 2 Qualities of Encounter characters Every game character has the same set of qualities. Each quality shall be a nonnegative floating point number with at least one decimal of precision. . Requirements An abstract class with attribute name. . . .

(1) D-Requirements (2) Design Game. Character 3. 2. EC. 1. 2 Qualities of Encounter characters Every game character has the same set of qualities. Each quality shall be a nonnegative floating point number with at least one decimal of precision. . Test this method. . . against this requirement Relating Tests to Requirements & Design Requirements An abstract class with attribute name. . . Test this class. . . against this requirement Characters Game. Character Encounter Characters Encounter. Character adjust. Quality() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Applied to. . . Unit test Results in a zero value? 1. Within range Concentration Stamina No: Test 1. 1. 1 etc. Partitioning of Range for Unit Testing 1 of 2 Yes: Test 1. 2 Test 1. 2. 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. etc.

Applied to. . . Unit test Results in a zero value? 2. Outside range Concentration Stamina No: Test 2. 1. 1 etc. Partitioning of Range for Unit Testing 2 of 2 Yes: Test 2. 2 Test 2. 2. 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. etc.

5. Checklists and examples for class testing

1. Exercise methods in combination – – Perform Class 2 -5, usually Unit Tests choose most common sequences first include sequences likely to cause defects requires hand-computing the resulting attribute values 2. Focus unit tests on each attribute – initialize, then execute method sequences that affect it 3. Verify that each class invariant is unchanged – verify that the invariant is true with initial values – execute a sequence (e. g. , the same as in 1. ) – verify that the invariant still true 4. Verify that objects transition among expected states – plan the state / transition event sequence – set up the object in the initial state by setting variables – provide first event & check that transition occurred. etc. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Encounter State-Transition Test Sequence 1 of 2 Preparing Player dismisses qualities menu test step 1 Verify that the game is initially in Preparing state (by checking on the class membership of game. State. I) Waiting

Encounter State-Transition Test Sequence 1 of 2 test step 2 Dismiss the quality menu, and verify that the game is in Waiting state. Preparing Player dismisses qualities menu test step 1 Verify that the game is initially in Preparing state (by checking on the class membership of game. State. I) test step 3 Move the player character to an adjacent area, and verify that the game is still in Waiting state. Move to adjacent area Waiting Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Complete Encounter State-Transition Test 2 Preparing Player dismisses qualities menu Reporting 6 3 Move to adjacent area 1 Player dismisses encounter report menu 5 Waiting Encounter completed 4 Character enters area inhabited by an opponent Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Engaging

6. Summary

Unit Testing: Summary • Unit testing = “pieces” • Other testing = “assemblies” • Black box: input / output only • White box: verifies processing – Several ways – Ensure completeness • Test planning earlier / better – helps clarify requirements Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

Case Study Encounter. Character. java

/** To test this class. * @param args. P destination of method test log, class test log respectively */ public static void main( String[] args. P ) { // Default files on which to write test output & run tests String method. Output. File. Name. M = "method. Output. txt"; String class. Output. File. Name. M= "class. Output. txt"; if( args. P != null && args. P. length == 2 ) improper { method. Output. File. Name. M = args. P[0]; class. Output. File. Name. M = args. P[1]; } // use defaults if input // 1. EXECUTE TESTS WHICH DO NOT REQUIRE HUMAN INTERVENTION // Test methods individually, then test class try { test. Encounter. Character. Methods( method. Output. File. Name. M ); test. Encounter. Character. Class( class. Output. File. Name. M ); } catch( IOException e. P ) { System. out. println( e. P ); } Listing page 1 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

// 2. EXECUTE TESTS WHICH DO REQUIRE HUMAN INTERVENTION Frame[] image. Tests = { // Display test cases. new test. Character. Image( // Missing image. new Encounter. Character( "Guy. With. No. Image", null ) ), new test. Character. Image( // Image is present. new Encounter. Character( "Elena", "elena. gif" ) ) }; for( int i = 0; i < image. Tests. length; i++) { image. Tests[i]. set. Size(400, 250); character. image. Tests[i]. set. Visible(true); image. Tests[i]. show(); } // Display each test window. // Adequate size for try { // Let user examine windows. Thread. current. Thread(). sleep( 30*1000 ); } catch( Exception exc ) { } for( int i = 0; i < image. Tests. length; i++ ) image. Tests[i]. dispose(); System. exit( 0 ); // Shut the windows. Listing page 2 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

/** Tests this class by executing its methods in combination. * @param destination. P Location to write results. * @exception IOException If there’s a problem opening or accessing destination. P */ public static void test. Encounter. Character. Class( String destination. P ) throws IOException { /* Prepare for the test */ Print. Writer out. M = new Print. Writer( new File. Output. Stream( destination. P ) ); System. out. println( "n. Encounter. Character class test results on " + destination. P + "n" ); Listing page 3 /* * The following methods will be tested in sequences: * * a. adjust. Quality( String quality. P, float quality. Value. P ) * d. delete. From. Encounter. Characters( Encounter. Character encounter. Character. P ) * ge. Encounter. Character get. Encounter. Character( String name. P ) * gq. float get. Quality. Value( String quality. P ) * gt. float get. Tolerance() * io. int index. Of( String quality. P ) * ii. insert. Into. Encounter. Characters( Encounter. Character encounter. Character. P ) * m. int max. Num. Chars. In. Name() * sq. set. Quality( String quality. P, float quality. Value. P ) * so. float sum. Of. Qualities() Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

* * * * */ The following sequences occur commonly: ge-aq-so ge-sq-a-gq . . . The following sequences have a high potential for defects: ge-aq-aq-gq-so . . . Listing page 4 /* Test C 1: ge-aq-so */ Encounter. Character e. C 1 M = new Encounter. Character( "Char. For. Test. C 1" ); // method “ge” e. C 1 M. adjust. Quality(QUAL_STRENGTH, 40. 0 f ); // aq Test. Execution. print. Report. To. File( out. M, "Class test ge-aq-so", e. C 1 M. sum. Of. Qualities(), 100. 0 f ); // so /* Test C 2: ge-aq-aq-gq-so */ Encounter. Character e. C 2 M = new Encounter. Character( "Char. For. Test. C 2" ); // ge e. C 2 M. adjust. Quality(QUAL_STRENGTH, 40. 0 f ); e. C 2 M. adjust. Quality(QUAL_STAMINA, 20. 9876 f ); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. // aq

Test. Execution. print. Report. To. File( out. M, "Class test ge-aq-aq-gq-so: part 1", e. C 2 M. get. Quality. Value( QUAL_STAMINA ), 20. 9876 f ); // gq Test. Execution. print. Report. To. File( out. M, "Class test ge-aq-aq-gq-so: part 2", e. C 2 M. sum. Of. Qualities(), 100. 0 f ); // so /* INVARIANT-ORIENTED TESTS * Check for the invariant “qual. Value. I[i] >=0” * -- after executing the sequences of methods executed above */ boolean truth. M = true; for( int i = 0; i < quality. Type. S. length; ++i ) { /* Set truth. M false if any entry in e. C 1 M. qual. Value. I not >= 0 */ truth. M = truth. M && ( e. C 1 M. qual. Value. I[i] >= 0. 0 f ); } Test. Execution. print. Report. To. File( out. M, "Class test for the invariant 'qual. Value. I[i] >=0'", truth. M, true ); /* Conclude */ out. M. close(); System. out. println( "n. Class tests of Encounter. Char class concluded. " ); } // end of test. Encounter. Character. Class Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. Listing page 5

/** Tests all the methods of this class one at a time * @param destination. P Location to write results. * @exception IOException If there’s a problem opening or accessing destination. P */ public static void test. Encounter. Character. Methods( String destination. P ) throws IOException { /* Prepare for the test */ File. Writer out. M = new File. Writer( new File( destination. P ) ); System. out. println( "Encounter. Character method test results on " + destination. P + "n" ); /* Tests for get. Encounter. Character() */ Encounter. Character e. CNor. M = new Encounter. Character( "qwerty" ); // normal Test. Execution. report. To. File( out. M, "Get. Character Test 1: nominal value", e. CNor. M. get. Name(), "qwerty" ); Encounter. Character e. CNull. M = new Encounter. Character( null ); // null Test. Execution. report. To. File( out. M, "Get. Character Test 2: null parameter", e. CNull. M. get. Name(), Game. Character. DEFAULT_NAME); Listing page 6 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

String too. Long. M = "12345678901234567890"; Encounter. Character e. CToo. Long. M = new Encounter. Character(too. Long. M); // too long Test. Execution. report. To. File( out. M, "Get. Character Test 3: Limit parameter values, " + "max name len = " + e. CToo. Long. M. max. Num. Chars. In. Name(), e. CToo. Long. M. get. Name(), too. Long. M. substring(0, e. CToo. Long. M. max. Num. Chars. In. Name()) ); Encounter. Character e. CZero. M = new Encounter. Character( "" ); zero-len Test. Execution. report. To. File( out. M, "Get. Character Test 4: zero-length", e. CZero. M. get. Name(), Game. Character. DEFAULT_NAME); // Encounter. Character e. CPunc. M = new Encounter. Character( "a+b" ); bad chars Test. Execution. report. To. File( out. M, "Get. Character Test 5: bad char '+' ", e. CPunc. M. get. Name(), Game. Character. DEFAULT_NAME); // Listing page 7 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

/* Tests for index. Of() for every valid quality name. */ for( int i = 0; i < quality. Type. S. length; ++i ) try { Test. Execution. report. To. File( out. M, "index. Of() Test 1. " + i + ": valid name: " + quality. Type. S[i], index. Of(quality. Type. S[i]), i ); } catch( Exception e. P ) { Test. Execution. report. To. File( out. M, "index. Of() Test 1: valid name: compare ", "index. Of('" + quality. Type. S[i] + "')", "with expected " + i ); } /* Tests for index. Of() for an invalid quality name. */ try { Test. Execution. report. To. File( out. M, "index. Of() Test 2: invalid name: zorch", index. Of("zorch"), -1 ); } catch( Exception e. P ) { Test. Execution. report. To. File( out. M, "index. Of() Test 2: valid name: compare ", "index. Of("zorch")", "with expected 1" ); } Listing page 8 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

/* Tests for set. Quality() */ // Set up for test Encounter. Character hank = new Encounter. Character( "Hank" ); // Nominal value hank. set. Quality(QUAL_STRENGTH , 10. 3 f ); Test. Execution. report. To. File( out. M, "set. Quality() Test 1: nominal value", hank. get. Quality. Value( QUAL_STRENGTH ), 10. 3 f ); // Out of range value hank. set. Quality( QUAL_PATIENCE, -6. 2 f ); Test. Execution. report. To. File( out. M, "set. Quality() Test 2: nominal value", hank. get. Quality. Value(QUAL_PATIENCE ), 0. 0 f ); // Value below close-to-zero threshold. hank. set. Quality( QUAL_STAMINA, get. Tolerance() * 0. 9 f ); Test. Execution. report. To. File( out. M, "set. Quality() Test 3: value close to zero", hank. get. Quality. Value(QUAL_STAMINA), 0. 0 f ); Listing page 9 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

// Tests for adjust. Quality(). Listing page 10 // Set up for test and verify: Values should be 20 each. Encounter. Character harvey = new Encounter. Character( "Harvey" ); Test. Execution. report. To. File( out. M, "adjust. Quality() test 0: verify that values add to 100", harvey. sum. Of. Qualities(), 100. 0 f ); // Nominal adjustment harvey. adjust. Quality(QUAL_STRENGTH , 30. 0 f ); // strength 30 rest 70/4 each Test. Execution. report. To. File( out. M, "adjust. Quality() test 1: values sum to 100 after adjusting", harvey. sum. Of. Qualities(), 100. 0 f ); Test. Execution. report. To. File ( out. M, "adjust. Quality() test 2: values adjusted as commanded", harvey. get. Quality. Value(QUAL_STRENGTH ), 30. 0 f ); // Adjustment resulting in a zero value harvey. adjust. Quality( QUAL_STAMINA, 99. 0 f ); Test. Execution. report. To. File( out. M, "adjust. Quality() test 3: verify low value reverts to zero", harvey. get. Quality. Value( QUAL_STRENGTH ), 0. 0 f ); // Conclude Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.

/** Class to test repainting of characters. Creates a window, which will contain * several copies of the character image. */ private static class test. Character. Image extends Frame { /** Instance attribute that remembers which character image to display. */ private Encounter. Character character. I; /** Basic constructor -- create a window for testing some character's image. * @param character. P Character whose image is to be tested. */ test. Character. Image(Encounter. Character character. P) { super(character. P. get. Name()); // Do all normal Frame initialization. character. I = character. P; // Remember which character we're testing. } Listing page 11 Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 20001), with permission. Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission. by Eric J. Braude (Wiley 20001), with permission.

/** Repaint the display areaof the frame. * @param draw. P Graphics context for drawing the character. */ public void paint(Graphics draw. P) { Dimension frame. Size. M = get. Size(); // Size of the window area. int width. Unit. M = frame. Size. M. width / 5; // Convenient divisions of window. int height. Unit. M = frame. Size. M. height / 5; character. I. show. Character(this, draw. P, // Drawn small, facing right. new Point(width. Unit. M, height. Unit. M), height. Unit. M, false); character. I. show. Character(this, draw. P, // Drawn large, facing left. new Point(width. Unit. M*4, height. Unit. M*3), height. Unit. M*2, true); character. I. show. Character(this, draw. P, // Drawn large, facing right. new Point(width. Unit. M*2, height. Unit. M*2), height. Unit. M*2, false); character. I. show. Character(this, draw. P, Listing page 12 // Drawn small, facing left. new Point(width. Unit. M*3, height. Unit. M*4), height. Unit. M, true); Adapted from Software Engineering: An Object-Oriented Perspective by Eric J. Braude (Wiley 2001), with permission.