Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software...
-
Upload
anne-burns -
Category
Documents
-
view
220 -
download
2
Transcript of Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software...
![Page 1: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/1.jpg)
Berrached::CS3320::Ch13 1
Implementation Phase
Chapter 13
Classical & Object-Oriented Software Engineering by Stephen R. Schach
![Page 2: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/2.jpg)
Berrached::CS3320::Ch13 2
Implementation Phase
• Aim: to translate the detailed design into code.• Programming-in-the-many: Product is
implemented by a team of programmers• All working at same time on different components
of the product.
![Page 3: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/3.jpg)
Berrached::CS3320::Ch13 3
Outline
• Choice of programming language• Good Programming Languages• Testing Techniques
![Page 4: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/4.jpg)
Berrached::CS3320::Ch13 4
Choice of a Programming Language• Language usually specified in contract by client.• If not, choice should be based on:
– cost-benefit analysis – COBOL: for data processing
– Object-Oriented Languages
– 4th generation Languages: e.g. SQL, DB2, Oracle, PowerBuilder
• Higher-level: each line equivalent to 30-50 line of machine code
• ease in programming, but slower
• mostly for data processing tasks
![Page 5: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/5.jpg)
Berrached::CS3320::Ch13 5
Good Programming Practice
• Use of consistent and meaningful variable name– Meaningful to future maintenance programmer
– Consistent to aid maintenance programmer
Example:– Module contains a variable to represent
maximum, minimum, and average temperatures:
• MaxFr: too ambiguous
• frequencyMax, minFreq: not consistent
• maxFrequency, minFreqency, avgFrequency
– Companies usually have their own internal conventions.
![Page 6: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/6.jpg)
Berrached::CS3320::Ch13 6
Good Programming Practice CNTD
• Self-documenting code: code can be understood without the aid of comments:– very rare
• Key question:– Can module be understood easily and unambiguously by
• SQA team
• maintenance programmers
• all others who have to read code
– E.g. xCooddinateOfPositionOfRobotArm
• abbreviate to xCoord
![Page 7: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/7.jpg)
Berrached::CS3320::Ch13 7
Prologue Comments• Mandatory at top of every single module
– module name– brief description of what module does– programmer’s name– date module was coded– date it was approved and by whom– Module parameters– Variable name, alphabetically and their uses– files accessed and updated by module– module I/O– error handling capabilities– name of file of test data– list if modifications made, when, by whom, approved by whom– known faults, if any
![Page 8: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/8.jpg)
Berrached::CS3320::Ch13 8
Other Comments
• In-line comments needed to explain code
Fallacy:– Comment are only needed when code is written in non-
obvious way, or makes use of subtle aspect of language
– If that is the case, re-code in clearer way
• Code layout for increased readability– use indentation
– use blank lines
![Page 9: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/9.jpg)
Berrached::CS3320::Ch13 9
Nested if Statements
![Page 10: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/10.jpg)
Berrached::CS3320::Ch13 10
Nested if Statements CNTD
![Page 11: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/11.jpg)
Berrached::CS3320::Ch13 11
Nested if Statements CNTD
![Page 12: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/12.jpg)
Berrached::CS3320::Ch13 12
Nested if Statements CNTD
![Page 13: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/13.jpg)
Berrached::CS3320::Ch13 13
Nested if Statements CNTD
• Combination of if-if and if-else-if statements usually difficult to read
• simplify by making use of fact that if-if combinationif <condition1>
if <condition2>
is frequently equivalent to single condition
if <condition1> && <condition2>
• Note: if programming language supports “short-circuit” evaluation of logical operations, they can always be equivalent.
![Page 14: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/14.jpg)
Berrached::CS3320::Ch13 14
Nested if Statements CNTD
Some basic rules:– if conditions are interdependent, use if-else statement
instead of a sequence of if statements
– Don’t forget the final else part
– Avoid if-if and if-else-if statements by combining conditions using the && operator
– Rule of thumb: if-statements nested to depth greater than three should be avoided as poor programming practice
![Page 15: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/15.jpg)
Berrached::CS3320::Ch13 15
Programming Standards• Standards are difficult to enforce• Can be both blessing and curse
– setting limits of module size
• Examples of good standards– documentation standards– program layout– naming standards– “ nesting of if-statements should not exceed a depth of 3,
except with prior approval from team leader”– “Use of goto should be avoided. However, with prior
approval from team leader, a forward goto many be used for error handling”
![Page 16: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/16.jpg)
Berrached::CS3320::Ch13 16
Module Testing
• After preliminary testing by programmer, each module is handed over to SQA group for formal testing.
• How to methodically test a module?
![Page 17: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/17.jpg)
Berrached::CS3320::Ch13 17
Module Test Case Selection
• Worst way- random testing• Need systematic way to construct test cases
Two extremes to testing:1. Test to specifications (also called black-box, data
driven, functional, or input/output driven testing).
• Ignore code. Use spec. document to select test cases
2. Test to code (also called glass-box, logic-driven, structured, or path-oriented testing)
• Ignore specifications. Use code to select test cases
![Page 18: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/18.jpg)
Berrached::CS3320::Ch13 18
Feasibility Of Testing To Specs
Example:– Specification for a data processing product include 5
commissions and 7 types of discount
– 35 test cases
• Suppose specs include 20 factors, each taking 4 values– 420 or over 1 trillion test cases
– if each takes 30 seconds to run, running all test cases takes > 1 million years!!
• Combinatorial explosion makes exhaustive testing to specification unfeasible.
![Page 19: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/19.jpg)
Berrached::CS3320::Ch13 19
Feasibility Of Testing To CodeEach path through module must be executed at least
once– Combinatorial explosion: flow chart has over 1012
different paths
![Page 20: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/20.jpg)
Berrached::CS3320::Ch13 20
Feasibility Of Testing To Code CNTD
• Can exercise every path without detecting every fault
Example:
if ( (x+y+z)/ 3 ==x)
cout <<“x, y, z are equal”<<endl;
else
cout <<“x, y, z are not equal”<<endl;
Test case 1: x=1, y=2, z=3
Test case 2: x=2, y=2, z=2
![Page 21: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/21.jpg)
Berrached::CS3320::Ch13 21
Feasibility Of Testing To Code CNTD
• Path can be tested only if it is presentExample 1:
if (d==0)
zeroDivisionRoutine();
else
x = n/d;
Example 2:
x = n/d;
![Page 22: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/22.jpg)
Berrached::CS3320::Ch13 22
Coping With The Combinatorial Explosion
• Exhaustive testing (to specs or to code) is not feasible
Art of testing:
• Small, manageable set of test cases to
– maximize chances of detecting faults, while
– minimizing chances of wasting test cases
• Every test case must be designed to detect previously undetected faults
• Methods that will high-light as many faults as possible
– First black-box test cases
– Then glass-box methods
![Page 23: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/23.jpg)
Berrached::CS3320::Ch13 23
Black-Box Module Testing
• Equivalence Testing
Example:– Specs for DBMS state that product must handle any
number of records between 1 and 16,000
– if system works for any one test in range [1..16,000], then it will probably work for any test case in range
• range [1..16,00] constitutes one equivalence class
• Any one member is as good a test case as any other member of the class.
![Page 24: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/24.jpg)
Berrached::CS3320::Ch13 24
Equivalence Testing CNTD
• Range [1..16,000] defines three difference equivalence classes:– Equivalence Class 1: Fewer than 1 record
– Equivalence Class 2: between 1 and 16,000 records
– Equivalence Class 3: More than 16,000 records
• Boundary Analysis:– Selecting test case on or just to one side of boundary of
equivalence class increases probability of detecting faults
![Page 25: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/25.jpg)
Berrached::CS3320::Ch13 25
Equivalence Testing & Boundary Analysis• DBMS Example:
– Test Case 1: 0 record: (member of class 1 & adjacent to boundary value)
– Test Case 2: 1 record (Boundary value)
– Test Case 3: 2 records (Adjacent to boundary value)
– Test Case 4: 8349 records (member of class 2)
– Test Case 5: 15,999 recs (Adjacent to Boundary value)
– Test Case 6: 16,000 recs (Boundary value)
– Test case 7: 16,001 recs (Adjacent to Boundary value)
![Page 26: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/26.jpg)
Berrached::CS3320::Ch13 26
Black-Box Testing Methods CNTD
Functional Testing• Test for each item of functionality• Example:
– module authenticates user login
– Module computes some arithmetic function
• Weakness:– Functionality may span several modules
![Page 27: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/27.jpg)
Berrached::CS3320::Ch13 27
Glass-Box Module Testing Methods
Statement Coverage• Series of test cases to check every statement• CASE tools needed to keep track• Weakness:
– Branch statements
if (S > 1 && t = 0) // && should have been ||
X= 8;
Test case: S=2, t=0
Both statements can be executed without fault showing up
![Page 28: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/28.jpg)
Berrached::CS3320::Ch13 28
Glass-Box Module Testing Methods
Branch Coverage• Series of tests check all branches.• CASE tool needed
Path Coverage• Most powerful form of Glass box testing• Weakness: with loops, number of paths very
large , can be infinite• Want weaker condition than all paths but which
shows up more coverage than branch coverage
![Page 29: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/29.jpg)
Berrached::CS3320::Ch13 29
Glass-Box Module Testing Methods
Path Coverage (continued)
Linear code sequences:• Identify set points L from which control flow may
jump, including entry and exit points– e.g.
• Restrict test cases to paths that begin and end with elements of L
• Uncovers many faults without testing every path.
![Page 30: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/30.jpg)
Berrached::CS3320::Ch13 30
Glass-Box Testing Methods CNTDAll-definition-use- path coverage
• Each occurrence of variable, zz say, is labeled either as – definition of variable:
e.g. zz=1 or read(zz)
– or use of variable:
e.g. Y = zz + 1 or if (zz > 0) ….
• Identify all paths from definition of variable to use of that variable– can be done by automated tool
• Set up a test case for each such path.
![Page 31: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/31.jpg)
Berrached::CS3320::Ch13 31
Glass-Box Testing Methods CNTD
All-definition-use- path coverage CNTD
• Disadvantages:– upper bound on number of paths is 2d, where d
is number of branches• In practice
– Actual number of paths is proportional to d
![Page 32: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/32.jpg)
Berrached::CS3320::Ch13 32
Glass-Box Testing Methods CNTD
Infeasible Code• May not be possible to test specific statement
because there is an infeasible path ("dead code")
if ( k < 2) {
if ( k > 3)
{ // dead code ….
• Dead code is frequently an indication of a fault
![Page 33: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/33.jpg)
Berrached::CS3320::Ch13 33
Glass-Box Testing -- Quality Assurance• Module m1 is more "complex" than module "m2"
=> m1 is likely to have more faults
• Software complexity– highlights modules most likely to have faults
• Unreasonably high complexity
=> re-design and re-code
![Page 34: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/34.jpg)
Berrached::CS3320::Ch13 34
Measures of Complexity
Lines of code– simplest measure of complexity– underlying assumption: constant probability p
that a line of code contains fault.
• Number of faults is related to size of product as a whole
![Page 35: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/35.jpg)
Berrached::CS3320::Ch13 35
Measures of Complexity
Cyclomatic Complexity
• Essentially number of decisions (branches) in module
• Easy to compute• Good measure of faults
![Page 36: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/36.jpg)
Berrached::CS3320::Ch13 36
Measures of Complexity
Software Science Metrics• Based on number of operators and operands in
module• Problem with cyclomatic and software science
– Being challenged theoretically and experimentally
– The both have high correlation wit LOC
• Several experiments have shown that LOC is as good predictor of fault rate as any other metrics
• Note: LOC is poor metric of productivity
![Page 37: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/37.jpg)
Berrached::CS3320::Ch13 37
Code Walkthrough and Inspections• Done by SQA team
– group of 4-6 members
– "walkthrough" code
– detect faults (no correction)
• Leads to rapid and thorough fault detection
• Experiments have shown that they are at least as effective in detecting faults as black-box and glass-box testing techniques.
![Page 38: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/38.jpg)
Berrached::CS3320::Ch13 38
CLEANROOM TESTING
• Incorporates several SW development techniques:– incremental process model
– Formal techniques for specification and design
– non-execution based testing: walkthroughs and inspections
• A module is not compiled until it has passed inspection
![Page 39: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/39.jpg)
Berrached::CS3320::Ch13 39
CLEANROOM TESTING
• 1820 lines of FoxBASE (U.S. Naval Underwater Systems Center, 1992)– 18 faults detected by "functional verification"
• based correctness proving techniques
– 19 faults detected in walkthroughs before compilation
– NO compilation errors
– NO execution errors
![Page 40: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/40.jpg)
Berrached::CS3320::Ch13 40
![Page 41: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/41.jpg)
Berrached::CS3320::Ch13 41
![Page 42: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/42.jpg)
Berrached::CS3320::Ch13 42
![Page 43: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/43.jpg)
Berrached::CS3320::Ch13 43
![Page 44: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/44.jpg)
Berrached::CS3320::Ch13 44
![Page 45: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/45.jpg)
Berrached::CS3320::Ch13 45
![Page 46: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/46.jpg)
Berrached::CS3320::Ch13 46
![Page 47: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/47.jpg)
Berrached::CS3320::Ch13 47
![Page 48: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/48.jpg)
Berrached::CS3320::Ch13 48
![Page 49: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/49.jpg)
Berrached::CS3320::Ch13 49
![Page 50: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/50.jpg)
Berrached::CS3320::Ch13 50
![Page 51: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/51.jpg)
Berrached::CS3320::Ch13 51
![Page 52: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/52.jpg)
Berrached::CS3320::Ch13 52
Approaches to Real Time Testing• Non-execution based
– Structure analysis techniques– deadlock detection methods– formal methods for modeling system behavior
that can take synchronization into consideration– e.g. PetriNets
![Page 53: Berrached::CS3320::Ch131 Implementation Phase Chapter 13 Classical & Object-Oriented Software Engineering by Stephen R. Schach.](https://reader035.fdocuments.net/reader035/viewer/2022070401/56649f1d5503460f94c3397e/html5/thumbnails/53.jpg)
Berrached::CS3320::Ch13 53
Approaches to Real Time Testing (CNTD)
• Execution Based– Systematic testing
• all possible ordering of inputs
• often impossible (combinatorial explosion)
– Simulation is the most important testing method for real-time systems