Software Engineering

Lecture 8
Software Implementation and
Testing
Reading:
Software engineering, 9th edition (ian
sommerville)
The Art of Unit Testing, Ch. 7 (Osherove)
 SW Implementation
• Converting design to language specific code
• Requires knowledge of programing language,
frameworks and API
• Those who are assigned this role called
“Programmers”
• Better practice :
– Use familiar language on implementation
– Write an easy and flexible code that can be modified
easily
– Use version control tools for better team work
– Use open source products

2
 Cont’d
Here are some aspects of implementation that are
particularly important to software engineering that are
language independent.
1. Reuse: functions and objects in programming
language libraries
• The abstraction level
• The object level: find appropriate libraries and discover
if the objects and methods offer the functionality that
you need. Eg. JavaMail library.
3
 Cont’d
• The component level: build your components using a
framework. Eg. display mangt: add connections to the
data to be displayed and write code to define specific
display details such as screen layout and colors.
• The system level

2. Configuration management : version control, general-

purpose IDE
3. Host-target development: Simulators are often used
when developing embedded systems.
4
 Implementation
Methodologies
Several implementation methodologies exist:
– Direct cutover – new system is turned on and old system
turned off
• Riskiest but least expensive – no need to support 2 systems
– Pilot implementation – a small group uses the new system
• Small impact on organization is something goes wrong – still
have old system running
– Parallel operation – all transactions are entered in new and
old system
• Very expensive to maintain 2 systems
• Least risky that you can identify bugs and go back to old
system if needed
– Phased implementation – new functions are implemented
as parts of old system are turned off
• Slowly move from old system to new one 5
 Bugs and testing
• software reliability: Probability that a software
system will not cause failure under specified conditions.
– measured by uptime, MTTF (mean time till failure), MTTR
(mean time to recovery, crash data
• bugs are inevitable in any complex software system
– industry estimates: 10-50 bugs per 1000 lines of code
– a bug can be visible or can hide in your code until much
later

• testing: A systematic attempt to reveal errors.

– failed test: an error was demonstrated
– passed test: no error was found (for this particular
6
situation)
 Difficulties of testing
• perception by some developers and managers
– testing is seen as a novice's job
– assigned to the least experienced team members
– done as an afterthought (if at all)

• limitations of what testing can show you

– it is impossible to completely test a system
– testing does not always directly reveal the actual bugs in
the code
– testing does not show absence of errors in software

7
 Faults and errors
• error: incorrect software behavior
– example: Message box said, "Welcome, null!"
– Example: Software controller for the Ariane
5 rocket crashed (and so did the rocket).
• fault: mechanical or algorithmic cause of
error (bug)
– example: Account name field is not set
properly.
– Requirements specify desired behavior;
if the system deviates from that, it has a
fault.

8
 Quality control
techniques
• fault avoidance: Prevent errors before system is
released.
– reviews, inspections, walkthroughs,
development methodologies, configuration management

• fault tolerance: When system can recover by itself.

– rollbacks, redundancy

• fault detection: Find faults without recovering from

them.
– debugging, testing

9
 Testing vs Verification
• Testing – Detects the presence of bugs by running the
code on a few carefully chosen inputs
• Verification – Shows the absence of bugs on all
possible inputs

10
 Some kinds of testing
• unit testing: Looks for errors in subsystems in
isolation.

• integration testing: find errors when connecting

subsystems
– bottom-up: integrate upward into double, triple,
quadruple test
– top-down: test UI first, then add layers
• system testing: test entire system behavior as a
whole, with respect to scenarios and requirements
– functional testing: test whether system meets
requirements
– performance, load
– acceptance, usability, installation 11
 Two rules of unit testing
• Do it early and do it often
– Catch bugs quickly, before they have a chance to hide
– Automate the process if you can
• Junit for Java, PHPUnit for PHP, test/unit for Ruby

• Be systematic
– If you thrash(did not handle well) about arbitrarily, the
bugs will hide in the corner until you're gone

12
 Four basic steps for a
test
This is hard! Need a set of test
cases that is small enough to
run quickly, yet large enough
to cover [all] interesting
• 1. Choose input data
program behaviors.
– without looking at the implementation: black box
– with knowledge of the implementation: white box

• 2. Define the expected outcome

• 3. Run on the input to get the actual outcome

• 4. Compare the actual and expected outcomes

13
 Choosing Input: two key
ideas
• Partition the input space
– Identify subdomains with the same
behavior
– Pick one input from each subdomain

• Boundary values
– Pick inputs at the edges of the
subdomains.
– Effective at finding corner
case bugs:

14
 Partitioning the input
space
// returns the maximum of a, b
public static int max(int a, int b) { ... }

• Partition into
– a<b,a=b,a>b

• Pick an input from each class

– (1, 2), (0, 0), (2, 1)

15
 Choosing Boundary
Values
// returns|x|
public static int abs(int a) { ... }

• Partition into
– a<0, a>0, a=0(boundary)

• Other boundary values

– Integer.MAX_VALUE
– Integer.MIN_VALUE

16
 Black box testing
• Explores alternate paths through the specification.
– Module under test is a black box: interface visible,
internals hidden.

// If a >= b, returns a. Otherwise returns b.

public static int max(int a, int b) { ... }

• 3 paths, so 3 subdomains
– (1,2)=>2
– (2,1)=>2
– (0,0)=>0

17
 White box testing
• Explores alternate paths through the implementation
3 Main White Box Testing Techniques:
1. Statement Coverage: it is the method of checking
whether each and every line of the code is executed at
least once.
2. Branch Coverage:
In case of an “IF statement”, there will be
two test conditions:
• One to validate the true branch and,
• Other to validate the false branch.
3. Path Coverage
Path coverage tests all the paths of the program(large
and complicated program) 18
 Example
INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
• Test case (A=40 and B=70), then all the lines of code
will be executed.
• What if I consider my Test case as A=33 and B=45?

INPUT A & B
C=A+B
IF C>100
PRINT “ITS DONE”
ELSE
PRINT “ITS PENDING”

19
 Other things to consider
• Maintenance plan/manual : includes operating
procedures, schedules, emergency protocols …etc
• Training manual: a comprehensive document
explaining your company’s policies, procedures,
products, clients, projects.
You can represent this using charts, video, visuals ,
practical examples.

Reading Assignment

• Pros and cons of each testing (black and white)

• Tools for testing
• Look more examples into UML Diagrams 20
 Case Study :Coin Flip
Game
• Description

This is A game two people's can play

which is player one and player
two .the game allows a person to give
prediction of the flip result and the
other take the another option [which
is head and tail ]

21
 From Problem to Code
What we are expected to do :

• First Make Analysis [Requirement Analysis]

• Design the Solution
• Implementation

22
 Use Case

Coin Flip Game

Predict Coin Flip

• <<player>>

Description:
A player at random offers a guess of a coin flip .the other player gets
the other option .The coin is flipped and correct guess wins

23
 Formal Description
• Use case Name : Predict Coin Flip
• Use Case Id : UC01
• Trigger : A player at random offers a prediction
• Actors :
– A player who makes prediction(Primary Actor)
– A player that gets other option
– A coin
– Coin Game
• Precondition :
– Two players must be available
– A coin must be available
• Goal : One player wins and the other loss

24
 Formal Description …
• Main Success Scenario :
1. The player starts the game
2. The game picked a player to predict a coni flip
3. The player picked offers a prediction of a coin flip
4. The game provide other player remining flip option
5. The game flips the coin is flipped
6. The game provides the result
7. The game picked the winner and losers
8. The game Offers to try again
Extension
??
Alternative
?? 25
 Component and
Deployment Diagram

Play Request
Game Game Service
Client PC

Requester Provider Game Service

Provider

Game Requester
Component diagram

Deployment diagram

• Architectural style [client server model] : since java follows client server
model and we prefer performance and over the other design goal
• We can divide game service component to coin ,player and game flipper
component but it is too small to consider as components so all components
are deployed under the same package 26
Design Class Diagram

27
 Implementation
• This are the implementation classes
– Coin class [Coin.java]
– Player class [Player.java]
– CoinGame class [CoinGame.java]
– CoinFlippingGame class [CoinFlippingGame.java]
• The main class [For Testing]

28
 More Ideas
• Design Patterns
– Solutions to existing problems in software engineering

• Usability, Performance, Reliability, Security Testing

– Covered in SW testing course

• Continuous integration
– Used to deploy as you code (automatically from your code
base)
– Check out travisCI

• Code review
– Review each others code before deploying
29