CMPS 406 Software Engineering

1
CMPS 406 Software Engineering
2
What is Software Engineering?

• The study of how software systems are designed
  and built.
• The recognition that systems must be planned, and
  that the plan must be followed.
• SWE is the opposite of hacking, i.e., writing
  code without thinking it through first, and then
  patching up any problems that are encountered.

3
Problems with Large Systems

• On average, a line of computer code costs 100.
• The amount of code in consumer products is
  doubling every 2 years.
• 25 of all large software projects are never
  completed.
• Large projects go, on average, 50 over budget.
• 75 of completed projects do less than intended.

4
Some Examples

• Due to software problems, the new Denver airport
  went 200 million over budget.
• Intel spent almost 500 million correcting an
  error in the original Pentium chip.
• The FAA hired IBM to modernize its air-traffic
  control software. The project was cancelled
  after 10 years and 1.5 billion.

5
Why is SWE Needed?

• Modern software projects are too large and
  complex for one person to design, code, debug,
  and maintain.
• Teams of designers and programmers must have a
  way of coordinating their work.
• Modern software is used (and reused) longer.
• Projects must follow budgets and schedules.
• Professional and ethical standards must be met
  (e.g., safety requirements).

6
Goals of SWE

• To produce software that is correct, useable, on
  time, and on budget.
• To make software creation a science.
• To find and correct errors as soon as possible.
• To simplify system debugging and/or modification
  by
• localizing the effects of an error or
  modification.

7
Why All the B.S.?

• SWE tends to have a high B.S. quotient.
• Lots of fancy terminology for common sense ideas.
• SWE want to be a science, but it is probably
  still an art.
• But this doesnt mean the concepts arent valid.

8
Some SWE Principles

• Localization of effects
• Errors
• Modifications
• Reusability
• When possible, SW is designed to be general
• Can we trust SW made by someone else?
• Modularity separate, independent pieces
• Data protection controlled access to values

9
Data Protection

• Also called data hiding
• How is data protection implemented in
  object-oriented software?
• How is data protection implemented when using
  other programming languages?

10
Object Orientation

• Localization of effects
• Within a particular class or object
• Can add new classes with private data
• Reusability
• Classes are designed to be general
• We can trust a class made by someone else.
• Modularity
• classes are designed to be separate, independent

11
Software Life-Cycle

• Specification (define the problem)
• Analysis (model the solution)
• Design (create a coding blueprint)
• Implementation (code it)
• Testing (debug it)
• Maintenance (upgrade it, modify it, etc.)

12
Specification

• Define the system/problem clearly and completely.
• Requirements and behaviors
• Feasibility study
• Do the developers understand what the user wants?

13
Analysis

• Explore various possible solutions.
• Select the best solution.
• Create a high-level, abstract model of the
  solution.
• Examples of models
• State diagrams
• Dataflow diagrams

14
Design

• Create a detailed blueprint that can be used to
  create code.
• Examples
• Formulas
• Pre- and post-conditions
• prototypes

15
Implementation

• Write the code using SWE principles such as
• Data protection
• Modularity
• Reusability
• Self-documenting

16
Testing

• Test the code in a systematic manner.
• Tests may begin before the entire system has been
  coded.
• Find and correct s many bugs as possible.
• Realize that not all bugs will be found.

17
Maintenance

• The system may be in use for many years, and by
  many different users.
• Periodic upgrades may be needed.
• Undetected bugs may appear.

18
Prototype System

• A scaled-down version of the final product
• Can be be created at different life-cycle phases.
  
• May include a subset of system functions.
• May include simplified implementations of
  functions.
• May be gradually enhanced, eventually creating
  the completed product.

19
Modeling the Software Life-Cycle

• How do we implement the life-cycle?
• How long does it take?
• Schedules and budgets must be met.
• Is this a linear process?
• Can backtracking be minimize, or at least
  predicted?

20
Backtracking

• The success of a project may depend on minimizing
  backtracking
• At times, mistakes are detected or ideas change,
  and work must be redone.
• This throws off schedules and budgets.
• A realistic model of the software life-cycle can
  help control backtracking.

21
Waterfall Model

• Life-cycle phases may iterate--be repeated many
  times.
• Detecting an error may necessitate backtracking
  to the previous phase to correct the error.
• When a phase it error-free, we move on to the
  next phase.

22
Waterfall Diagram
Specification
Analysis Design
Implementation
Testing
Maintenance
23
Waterfall Example

• Tests (in the testing phase) reveal an error.
• Re-examining the code (created in the
  implementation phase) shows that some code
  definitions are contradictory.
• Examining the design we see that the error
  occurred here.
• After correcting the design error, the code is
  corrected and re-tested.

24
Weaknesses of Waterfall Model

• There is no clear end to the process.
• It may be necessary to backtrack multiple phases
  before the source of an error can be corrected.
• Completing a phase is no guarantee that it will
  not have to be revisited later.
• Difficult to schedule and budget a project.

25
Spiral Model

• Addresses weaknesses of waterfall model
• Each life-cycle phase is broken into phases.
• Stresses risk management
• minimizing the effect of errors by anticipating
  what might go wrong
• Each step is more detailed, to minimize errors.
• A certain amount of iteration is scheduled.
• Includes a prototyping phase
• Because this also reduces risk

26
Spiral Diagram
27
Example Specification Phase

• Specify the specification
• Determine what this specification must include.
• Design the specification
• Determine what kind of specification is needed
  (formal, etc.)
• Create a prototype specification
• Create a draft of the specification and show it
  to users, etc.
• Implement the specification
• Create a final draft of the specification
• Test the specification
• Does the spec. fulfill the requirements defined
  in the initial stage?
• Maintain the specification
• During future phases, it may be found that
  changes are needed.

28
Phase 1 Specification

• Defines the system to be built in terms of
• Functional Requirements
• Non-functional requirements
• User requirements
• Environmental requirements
• These are different ways of viewing and
  systematically eliciting requirements.

29
Functional Requirements

• The actions the system must carry out
• Described as functions, in terms of inputs and
  corresponding outputs
• Each function is viewed as a black box-- we
  dont know how it will be implemented.
• This is a good way to define test cases that are
  valid for (and independent of) all
  implementations.

30
Non-Functional Requirements

• Constraints on the system--things the system
  shouldnt do.
• Acceptable execution speed
• Ease of use
• Security restrictions
• May include system requirement
• These requirements must also be testable.

31
User Requirements

• What kinds of people will use the system?
• What functions do each kind of user need
  expect?
• How will each kind of user interface with the
  system?
• In O.O. systems, we define use cases.

32
Environmental Requirements

• The new program must fit into an existing
  environment, that may include
• Specific programming languages
• Available resources( e.g., limited memory)
• Interfacing software already in place
• Employee abilities
• Physical considerations (temperature, etc.)

33
Example Online Game System

• The XYZ Company wants to create an internet
  website that allows users who have paid a
  subscription fee to access and play computer
  games stored at the site. Users will be charged
  an hourly fee for game use, and will be billed
  monthly. An online Help facility will also be
  available that contains game-related information.
• Periodically the games will be evaluated, and
  unpopular games will be removed. One concern is
  that subscribers do not get a busy signal too
  often when they attempt to access the website.

34
Functional Requirements

• Heres a partial list (whats missing?)
• Login/logout
• Select a game
• Play a game
• Read help file
• Charge fees/send bills
• Evaluate games

35
Non-Functional Requirements

• Make system easy to use
• Include high quality, popular games
• Minimize busy signals
• Allow only paid subscribers to use system

36
Non-Functional (Modified)

• Include high quality, popular games
• Games accessed 50 below average will be
  replaced.
• Minimize busy signals
• On average, users will wait no more than X
  minutes for game access.
• Allow only paid subscribers to use system
• Users enter a password, which is verified.

37
Environmental Requirements

• Internet capabilities
• Server capabilities
• Project budget
• Available personnel

38
User Requirements

• Functions used by Subscribers
• Create new account
• View account information
• Pay subscription fee
• Login/logout
• Play a game
• Read Help File

39
User Requirements

• Functions used by the Billing Department
• Generate bills
• Send Bills
• Process payments (by updating accounts)

40
User Requirements

• Functions used by Security
• Assign passwords
• Verify passwords
• View account information
• Modify account data

41
User Requirements

• Functions used by Maintenance
• Add a new game
• Remove an existing game
• Modify a Help file

42
User Requirements

• Functions used by Management
• Record game usage (for popularity)
• View game usage
• Record system usage (for busy signals)
• View system usage
• Set hourly fees

43
Use Cases
Record Game Use
View Game Use
Record Sys. Use
View System Use
Management
Set Hourly Fees
44
The Analysis Phase

• Create a model of the specificationto make sure
  you understand it.
• Abstract out details that can be decided during
  the design or implementation phases.
• Goal understand what must be done so you can
  figure out how to do it.

45
Why is Analysis Needed?

• The specification is usually written in English,
  which is inherently imprecise.
• Using a model allows the specifiers to
  communicate exactly what they want.
• Creating a model helps us discover and fix
  ambiguities or inconsistencies in the
  specification.
• We get information from manipulating the model
  that we dont get from changing the
  specification. (What if we try this)

46
Some Model Types

• Mathematical model
• Describe the system in terms of formulas and
  logical rules.
• Structured model
• Describe the hierarchical levels of the system
  top-down, bottom-up, etc.
• Object model
• Describe the system as a set of independent,
  cooperating entities.

47
Object-Oriented Analysis

• Combines 3 different models
• Static Model
• Identify objects and their relationships
• Dynamic Model
• Represent system actions as a state diagram
• Functional Model
• Identify functions and their I/O

48
Static Model

• Defines the static system structure using
  objects
• Identify possible object classes
• Assign attributes to classes
• Identify object relationships

49
Dynamic Model

• Represents the time-dependent aspects of the
  system using state diagrams
• Identify states (particular set of values)
• Identify events (actions) that create new
  states.
• Identify common sequences of events.
• Identify parallel events.

50
Functional Model

• Shows how the system transforms data
• Identify where data comes from and where it goes.
• Identify functions and their I/O.
• Show which functions outputs are inputs to other
  functions.

51
Example Dynamic Model

• Some system event sequences
• Customer logs on and plays a game
• Billing creates and sends out bills
• Maintenance adds/removes games

52
High-Level Diagram

Customer Id password
End customer session

stop
start
Maintenance login
End maint. session
Billing login
End billing session

53
Expansion of Customer Session
Enter ID and password
start

User rejected
User accepted
end customer session
Request game
User is done
play game or request help
request accepted
request denied
end game
54
Expansion of Verification Process
Enter ID and password
Valid ID and password Check account status
User accepted
User behind in payments
Invalid ID and/or password
User rejected
55
Example Static Model

• Some possible objects
• Game
• Help file
• Customer
• Billing
• Maintenance
• System Interface

56
Possible Class Relationships
Interface
Game
Customer
Main-tenance
Help
Billing
57
Dataflow Diagrams

• Models the flow of data through the system.
• Identify processes that transform data.
• Identify data sources and data. destinations
• Hierarchical structure

58
Example Game System

• What external entities access the system?
• Customers
• Management
• Billing
• Maintenance
• Security

59
Diagram Symbols
System function (verb) Dataflow (noun) Actor (a
person or department) Data source or
destination (document, report, manual)
60
Example Top Level
Mgt.
Security
Game system
Customer
Billing
Maint.
61
Partial Expansion
Process user request
Customer
password file
Help files
Current users
Game library
User history log
Game usage log
Generate usage reports
Generate user bills
Update Game library
Management
Billing
Maintenance
62
Process User Request
C U S T O M E R
Proc. access
Current users
Password file
Verify passwd
Game library
Proc. game
Game usage log
User history log
Proc. help
Help files
63
The Design Phase

• Use the model created during the Analysis phase
  to define hardware and software components.
• Abstract out details that can be decided during
  the implementation phase.
• Goal understand all details necessary to write
  the code for the system.

64
Why is a Design Needed?

• The model created during Analysis is too
  abstract. Details have been left out to simplify
  the model.
• Adding detail to the model helps us discover and
  fix ambiguities or inconsistencies in the model.
• The design communicates to programmers exactly
  what they must create.

65
Design Decisions

• Some Design phase activities are
• Organizing the system into subsystems
• Identifying subsystems that run in parallel
• Allocating subsystems to processors
• Managing access to data and other recourses.

66
Object-Oriented Design

• Fill in details of the class diagram by
• Using state diagrams to identify possible class
  methods.
• Using dataflow diagrams to identify possible
  class attributes and data structures.
• Using use cases, create collaboration diagrams
  to identify interactions between classes.

67
Identifying Class Methods

• The transition arrows of state diagrams are
  labeled with events/actions.
• Dataflow diagrams also identify system functions.
• Try to define each of these actions and functions
  as a method of some object class (or define new
  classes).

68
Identifying Class Attributes

• The arrows of dataflow diagrams are labeled with
  data items.
• Dataflow diagrams also identify data structures
  (i.e., sources and sinks).
• Assign these data items to appropriate object
  classes (or define new classes).

69
Identifying Class Interactions

• The state diagram of each use case identifies a
  sequence of actions.
• Many of these actions represent interface
  methods that allow different classes to
  communicate with each other.
• We can use these to identify parameters for the
  interface methods.
• We can also identify private variables.

70
Collaboration Diagrams

• A collaboration diagram identifies the sequence
  of object methods needed to carry out a
  particular use case.
• They are similar to state diagrams, except they
  identify specific class names, methods, and
  method parameters.

71
Example Game System
Interface
Game
Customer
Main-tenance
Help
Billing
72
Some Possible Class Methods

• Request login (Customer class?)
• Enter password (Customer class?)
• Verify password (Password file?)
• Request game (Game class?)
• Play game (Game class?)
• Log game usage (Management class?)
• Log customer hours (Billing class?)
• Add new game (Maintenance class?)

73
Access vs. Control

• One or more classes may need to access a certain
  piece of data.
• But one particular class should have control over
  who accesses that data and how.
• The data should be an attribute of the
  controlling class.
• The only methods directly accessing the data
  should be in the controlling class.

74
Assigning Methods to Classes

• Interface class (controls system data and
  usage)
• Request login
• Enter password
• Verify password
• Game class (controls game data and usage)
• Request game
• Log game usage
• Add new game
• Customer class (controls customer data)
• Log customer hours

75
Possible Class Attributes

• List of Current users
• Password file
• Game library
• Help files
• Game usage log
• User history log

76
Assigning Attributes to Classes

• Interface class (controls system data and
  usage)
• List of current users
• Password file
• Game class (controls game data and usage)
• Game library
• Game usage log
• Customer class (controls customer data)
• User history log
• Help file class (controls Help data and
  usage)
• Help files

77
Detailed Class Diagram
Interface
userRequest
systemResponse
systemStatus
setSysStatus()
logon()
getSysStatus()
getUserRequest()
0..n
0..n
processRequest()
0..n
0..n
Customer
custID
custName
Help
0..n
0..n
password
gameName
acctStatus
helpUsage
acctHours
helpText
reads
newCustomer()
editHelpFile()
setCustUsage()
setHelpUsage()
setCustStatus()
getHelpFile()
setPassword()
getHelpUsage()
has a
plays
getCustUsage()
getCustStatus()
Game
verifyPassword()
gameName
gameStatus
gameUsage
newGame()
deleteGame()
requestGame()
setGameStatus()
setGameUsage()
getGameStatus()
getGameUsage()
78
Creating a Collaboration Diagram

• One collaboration diagram for each use case.
• Based on the state diagram, identify the sequence
  of methods used.
• Identify parameters needed to be passed to the
  methods.
• Identify the returned value of each method.
• Identify the classes that own the methods.

79
Analyzing the Play Game Use Case (1)

• Methods needed to enter customer password
• enter password is not a method.
• accept and reject password are not methods.
• Verify password(ID,password)
• returns accept or reject
• owned by Interface class

80
Analyzing the Play Game Use Case (2)

• Methods needed to play a game
• userRequest(play,game-name)
• Owned by Interface class
• Calls method requestGame(game-name)
• owned by Game class
• returns accept or reject

81
Play a GameCollaboration Diagram
4 setGameStatus(gameY,inuse)
1 logon(userX, password)
5 setGameUsage(gameY, time)
2 UserRequest(play, gameY)
6 UserRequest(quit)
3 requestGame(gameY)
interface Interface
gameY Game
user
7 setCustomerUsage(time)
userX Customer
82
The Implementation Phase

• Implementation means writing code.
• At this point, writing code should be straight
  forward, because all the hard decisions were made
  in previous phases.
• Each implementation decision should affect only a
  small part of the program.

83
Implementation Guidelines

• Reusability
• Extensibility
• Robustness
• Programming-in-the-Large
• Maintainability

84
Reusability

• Reusability means minimizing code duplication
  by
• Sharing code within a program
• Using code originally created for a different
  program
• Creating code that can easily be used by other
  programs in the future

85
Writing Reusable Code

• Keep methods coherent
• Each method should have a single function.
• Keep methods small
• You cant reuse part of a large method.
• Keep methods consistent
• Dont do unexpected things like create aliases.
• Avoid global information
• Using local variables increases a methods
  independence.

86
Extensibility

• Extensibility is the ability to add
  functionality to the program during the
  Maintenance phase.
• Localizing effects increases extensibility.
• Data hiding increases extensibility.
• Increasing Extensibility will also increase
  reusability.

87
Writing Extensible Code

• Encapsulate classes
• Prevent direct access to a classs data. Use of
  specific data structures should be hidden.
• Minimize references to external classes
• Have only the main application aware of
  different classes.
• Distinguish public and private operations
• Minimize a classs interface with the rest of the
  system.

88
Robustness

• A Robust method can continue to execute during
  unexpected conditions, such as
• Given incorrect user inputs
• Given improper parameters from another method.
• Errors caused by bugs the method code.

89
Writing Robust Code

• Validate arguments
• For example, define arguments as String and
  then check for correct type (JOptionPane does
  this).
• Avoid predefined limits
• For example, use a linked list instead of an
  array.
• Build-in execution monitoring
• For instance, using Java exceptions.
• Optimization isnt always the goal
• Robustness often causes duplication and
  redundancy.

90
Programming-in-the-Large

• Programming-in-the-large means dividing work
  among teams of programmers.
• This allows large programs to be split into
  easily understandable pieces.
• This is necessary because modern programs are two
  complex for a single person to hold in their
  head.
• This requires team coordination and organization.

91
How to Program-in-the-Large

• Keep method understandable
• Because the designer is not the coder
• Make methods readable
• One team must be able to understand code written
  by another team.
• Use the same names as in the object model
• This allows traceability, the ability to use
  the design to understand the code.
• Choose names carefully
• This is what naming conventions are for

92
Maintainability

• Maintainability means the code can be used long
  after the original designers and coders are gone.
  This allows
• Correction of errors not found during the Testing
  phase
• Adding new functions, upgrades
• Extensibility, reusability, programming-in-the-lar
  ge

93
Writing Maintainable Code

• Use Comments
• Use descriptive variable and function names
• Use naming and other conventions
• Create documentation
• User manual
• coding blueprints what does each method do
• Log tests, corrections, and modifications

94
The Testing Phase

• Once implementation has begun, we can begin
  identifying and correcting errors.
• When an error is found, It must be determined if
  it is the result of faulty coding, or of faults
  in the specification, analysis, or design.
• The further back we have to go to correct an
  error, the more time and money is wasted.

95
Testing Philosophy

• We assume the code has errors.
• The more errors we find, the better.
• Finding few errors means the program has not been
  properly tested.
• But programmers dont want to find errors in
  their code.
• Thats why the program is usually coded and
  tested by separate people.

96
How Much Testing is Enough?

• The purpose of the Testing phase is not to locate
  every error. That isnt practical.
• We might try to correct 95 of the errors. Then
  do some beta-testing, then deal with the rest
  during the Maintenance phase.
• Why 95 ?
• And 95 of what?

97
Scheduling the Testing Phase

• Program length
• predict the number of errors based on program
  length.
• Program complexity
• predict the number of tests needed based on
  program complexity.
• Program reliability
• predict how much testing is needed to attain an
  acceptable level of program reliability.

98
Predicting the Number of Errors

• Based on lines of code (LOC)
• Assume x errors per 1,000 LOC
• Can you see a weakness with the LOC method?
• Based on past experience
• Adjust x based on the number of bugs found in
  similar programs written in the past by the same
  people.
• Based on complexity of code
• Adjust x based on the complexity of the code.

99
Predicting the Number of Tests

• One way of scheduling the Testing phase is to try
  to determine how many tests will be necessary.
• For instance, how many tests would it take to
  make sure you tested every line of code at least
  once?
• (This is called statement coverage).

100
Example Program Code

• k 0
• read n
• while (k lt n)
• read x, y
• if (x gt 0)
• do functionA
• else
• do functionB
• If (y gt 0)
• do functionC
• else
• do functionD
• k k 1

101
Two Test Cases are Needed

• k 0
• read n
• while (k lt n)
• read x, y
• if (x gt 0)
• do functionA
• else
• do functionB
• If (y gt 0)
• do functionC
• else
• do functionD
• k k 1

Test case 1 (n2, x3, y4) Test case 2
(n2, x-3, y-4)
102
Measuring Program Complexity

• We know from writing programs that some parts of
  a program are more likely to have errors than
  others.
• The harder the logic, the more difficult the
  code, and more likelihood of coding mistakes.
• These tough spots tend to require more decisions,
  codes as Ifs and loops.

103
The McCabe Metric

• Purpose to predict the number of tests needed
  for statement coverage (based on the complexity
  of the program).
• Create a flowchart-like model the code.
• Calculate the complexity of the graph based on
• The number of nodes, and
• The number of edges
• Complexity edges - nodes 2

104
Creating the Graph

• Start by creating a flowchart of the program
• Each operation is a node
• Arrow connect the nodes to indicate execution
  order.
• Merge consecutive nodes that have
• one incoming arrow, and
• one outgoing arrow.
• i.e., ones that do not involve a decision.

105
Complexity Graph
k 0 get n
edges 12 nodes 10 12 10 2 4
k lt n?
get x,y x gt 0?
funA
funB
y gt 0?
funD
funC
Exit loop
k
106
Using the Complexity Metric

• So the programs complexity metric is 4.
• That means it will take at most 4 test cases to
  execute every line of the program.
• Question What happens if we remove the loop?
• Does the number of loop iterations matter?
• Does not executing the loop at all matter?

107
Reliability

• Reliability is the probability that the program
  will not fail.
• One way to schedule the Testing phase is to aim
  for an acceptable level reliability.
• However, measuring software reliability can be
  difficult.

108
Measuring Reliability

• Hardware reliability can be determined by testing
  individual components to
• track the percentage of errors.
• calculate the average component lifetime.
• Software reliability cannot be determined the
  same way
• software components are not identical.
• software errors are not cause by part wearing
  out.
• software failures are caused by particular inputs.

109
Statistical Measurement of Reliability

• A test case generator is a program that creates
  large numbers of test cases (both inputs and
  outputs) for a particular program.
• Statistical testinguses a test case generator
  to subject a program to hundreds or thousands of
  tests, and calculates the percentage of failures.
• Reliability 1 - failures.

110
Reliability Growth Modeling

• Create a graph showing the predicted reliability
  increase with each bug removed.
• To actually do this, we would have to
• predict the total number of errors.
• carry out statistical testing to measure
  reliability improvements.
• However, reliability growth predictions can also
  be based on knowledge gained from previous
  programs.

111
Defining a Model
RELIABILITY
Point of Diminishing Returns
Small improvements in reliability
Large improvements in reliability
OF ERRORS CORRECTED
112
Point of Diminishing Returns

• At the point of diminishing returns (PDR), any
  increases in reliability are not worth the
  expense of extra testing.
• This is more of an opinion than a fact, and will
  be different for different projects and different
  companies.
• It maybe derived at using instinct and past
  experience.

113
Creating a Testing Schedule

• Assume the following
• 95 reliability is selected as the P.D.R.
• The program has an estimated 100 errors.
• On average, our testers find 5 errors a day.
• How long must our Testing phase last?

114
Creating a Testing Schedule

• Assume the following
• 95 reliability is selected as the P.D.R.
• The program has an estimated 100 errors.
• On average, our testers find 5 errors a day.
• How long must our Testing phase last?
• 19 days

115
Problems with the Model

• Each bug removed does not increase reliability
  the same amount.
• Some bugs are more important than others, and
  so increase reliability more.
• Some bugs are harder to find than others.
• The most obvious errors are usually found first.
• Fixing one bug often creates new ones.

116
Testing-in-the-Large

• Tests by programming teams must be coordinated
• Unit tests
• Test individual components.
• Sub-system tests
• Test combined components.
• Acceptance tests
• Prove that the program meets its requirements.
• Field tests (beta tests)
• Allow users to find errors.

117
Unit Testing

• Each module is tested separately
• A module can be an object class, or even a
  single method.
• Used in bottom-up testing
• Begin with a single component
• Then test combined components
• Test ever larger program sub-systems.

118
Sub-System Testing

• Testing multiple components together.
• Can be used in either bottom-up or top-down
  testing
• Top-down testing the entire system before it is
  finished.
• Requires stubs simulations of unfinished
  components.
• Eventually the complete system is tested.
• Interface testing check for mismatching
  component interfaces.
• Example passing the wrong number or types of
  parameters.
• Difficult to identify interface errors with unit
  testing.

119
Types of Tests

• Prototyping
• related to top-down testing
• Stress testing
• Try to overload the program with too much input,
  too fast, etc.
• Boundary testing
• Use boundary or unusual values
• Example testing zero factorial
• Black box testing
• Tests based on the specification
• White box testing
• Tests based on the code structure.

120
Black Box Testing

• Tests based only on the specification.
• Also called functional testing because the test
  values are considered inputs to functionsblack
  boxes.
• A black box is a something we can give inputs
  to, and receive inputs from, but we cannot look
  inside the box to see how the outputs are derived.

121
Create Test Cases Before Coding?

• Identify the functions (defined in the
  specification) that the program must
  performregardless of how the program is
  implemented.
• Example a factorial program
• Input 3, output 6
• Input 0, out put 1
• Input 1, output error message

122
Identify Equivalence Partitions

• An equivalence partition is a set of inputs
  that are all treated the same way.
• For instance, they are interchangeable operands
  to the same formula, they use the same program
  functions, etc.
• We assume that all inputs in a particular
  partition will cause the same code to be
  executed, no matter how the code is written.

123
Equivalence Partitions Example

• Assume we are writing a factorial program. We
  assume that, no matter who writes the code, all
  inputs in each of the following sets will be
  treated the same
• 1, 2, 3, 4,
• 0
• -1, -2, -3, -4,
• Are our assumptions valid?

124
Another Example

• Assume we are writing a binary search program. We
  assume that, no matter who writes the code, all
  inputs in each of the following sets will be
  treated the same
• Values for which found is returned.
• Values for which not found is returned.
• Are our assumptions valid?

125
Using Partitions

• We use the equivalence partitions to select test
  cases.
• Since (we assume) every value in a partition is
  equivalent, testing one value is as good as
  testing every value in the partition.
• So a testing strategy is to include one test case
  from each partition.
• This allows us to use a finite number of test
  cases.

126
Boundary Testing

• A boundary value is a value at the beginning or
  end of a partition.
• For instance 1 is a boundary value of the
  partition 1, 2, 3, 4, we defined for the
  factorial program.
• Boundary values are usually good candidates for
  test cases.
• Why is 1 a good test case for factorial?

127
White Box Testing

• Tests based on the program code.
• Also called structural testing because the test
  values are chosen based on the code structure.
• A white box is the opposite of a black box we
  can look inside it to see how outputs are derived.

128
Goal Code Coverage

• White box tests attempt to cover or exercise
  the code.
• We will identify two different levels of
  coverage
• Statement coverage
• Path coverage

129
Statement Coverage

• The goal of statement coverage is to execute
  every code statement at least once.
• Statement coverage is considered minimal.
• In other words, its a good starting place.

130
Two Test Cases are Needed

• read x, y
• if (x gt 0)
• do functionA
• else
• do functionB
• If (y gt 0)
• do functionC
• else
• do functionD

Test case 1 (x3, y4) Test case 2 (x-3,
y-4)
131
Loops Dont Add Test Cases

• k 0
• read n
• while (k lt n)
• read x, y
• if (x gt 0)
• do functionA
• else
• do functionB
• If (y gt 0)
• do functionC
• else
• do functionD
• k k 1

Test case 1 (n2, x3, y4) Test case 2
(n2, x-3, y-4)
132
Path Coverage

• A path is a sequence of executed code.
• Path coverage identifies different possible
  paths/sequences of execution.
• This means that the order in which code
  statements are executed is important.
• Path coverage is considered to much more rigorous
  than statement coverage.

133
There are 4 Possible Paths

• read x, y
• if (x gt 0)
• do functionA
• else
• do functionB
• If (y gt 0)
• do functionC
• else
• do functionD

Test case 1 (x3, y4) Test case 2 (x-3,
y-4) Test case 3 (x3, y -4) Test Case
4 (x-3, y4)
134
How Many Tests Are Needed Now?

• k 0
• read n
• while (k lt n)
• read x, y
• if (x gt 0)
• do functionA
• else
• do functionB
• If (y gt 0)
• do functionC
• else
• do functionD
• k k 1

135
Dealing with Loops

• Each loop iteration adds to the executed code
  sequence.
• So if the loop iterates k times, it executes a
  different path than when the loop iterates k1
  times.
• Therefore, this code has an infinite number of
  paths.

136
White Box Testing Strategy

• Begin with tests aimed at statement coverage.
• Then execute tests aimed at path coverage, but
  either ignore loops or test a finite number of
  loop iterations.