COM419

Object-Oriented Modelling

Construction:
Implementation and Testing

1
 Key Definitions
Construction is the development of
• all parts of the software itself,
• documentation, and
• new operating procedures.
Testing is a form of insurance. It costs more
to repair software bugs when people are
depending on the programs than in earlier
stages before the systems are in use.
Documentation provides information to
make the system easier to use and repair.
2
 Programming languages
• Considerations:
– Nature of problem
– Computer hardware requirements
– Ease of use
– Maintainability

3
 Programming Languages
and Software Development
Assembly language Systems software
FORTRAN Scientific, mathematical problems

COBOL Business problems

PL/1 Scientific, business problems
BASIC Problems that can be solved by PCs
PASCAL Education, scientific problems
Ada Weapons systems, business problems
C General purpose
4th generation Simple problems solved by non-
technical specialists
OO languages Problems where a solution can be
modelled as objects
4
Programming Language Classes…
First Generation:
– machine code & assembly code
Second Generation
– foundation for 3 GL
• FORTRAN, COBOL, ALGOL, BASIC
• all had huge libraries
Third Generation
– structured programming languages including modern
versions of the 2GLs above
– General Purpose:
• ALGOL and its descendants: PL/1, PASCAL, Modula-2, C, Ada
• PASCAL - developed for teaching, now widely used in science
• C - originally for operating system implementation (UNIX)
• Ada - U.S. D.O.D. – Pascal-like but more features

5
Programming Language Classes…
– OO
• C++, Smalltalk, Java - all based on C
– 4th generation
• Query languages
• Graphics languages
• Report generators
• Application generators
• Very high-level programming languages

6
Programming Language Classes
• Specialised languages
– LISP & PROLOG - symbol manipulation and list processing,
used in developing expert systems
– Visual languages - VB, Delphi - designed for rapid
development of Windows applications.
• Fourth Generation
– higher level of abstraction - no need to specify control and
data structures
• e.g. COMPUTE NPV AND ROI FOR EXPENDITURES #5 AND #9
– usually with databases using a query language e.g. SQL
– Program generators - e.g. from diagrams

7
 Implementation Issues
1. Reuse
– When developing software you should make as much use
as possible of existing code
2. Configuration management
– During development, many different versions of each
component are created, and you must keep track of these
3. Host-target development
– Production software does not usually execute on the
same computer as the software development
environment

8
 Open Source Development
• Source code is published, volunteers invited to
participate in development process
– Advantages
– Usually fairly cheap or free to acquire open source software
– Mature open source systems are usually very reliable
– Disadvantages
– May not suitable for a specific set of organisational
requirements
– May reveal confidential business knowledge to their
competitors

9
 Open Source Development
• 3 licensing models:
– GNU General Public Licence (GPL)
• If you use this software you must make it open source
– GNU Lesser Public Licence (LGPL)
• You can write components that link to open source code
without having to publish source
– Berkley Standard Distribution Licence (BSD)
• You are not obliged to republish any changes or
modifications, and you can include the code in proprietary
systems that are sold but you must acknowledge original
creator

10
 Main Tasks of Managing the
Programming Effort

• Assigning the programmers

• Coordinating the activities
• Managing the schedule

11
 The Programmer Paradox
• After an appropriate number of people are
assigned to a programming task, adding more
people slows down rather than speeds up
completion of the project.
• When projects are so complex they require a
large team, the best strategy is to break the
project into a series of smaller parts that can
function as independently as possible.

12
 Managing the Schedule
Use initial time estimates as a baseline
Revise time estimates as construction proceeds
Fight against scope creep
Monitor “minor” slippage
Create risk assessment and track changing risks
Fight the temptation to lower quality to meet
unreasonable schedule demands

13
 Avoid Classic Mistakes
1. Research-oriented development
If you use state-of-the art technology, lengthen planned time
2. Using “low-cost” personnel
If using a significant number of entry level personnel,
lengthen planned time
3. Lack of code control
Use source code library to keep programmers from changing
the same code at the same time
4. Inadequate testing
Always allocate sufficient time for formal testing

14
 Designing Tests
• The purpose is not to demonstrate that the
system is free of errors
• The purpose is to detect as many errors as
possible

15
 Validation and verification
• Validation:
– Are we building the right product?
• Verification:
– Are we building the product right?
• Together, these establish if software is ‘fit for
purpose’
– Software inspections or peer reviews
– Software testing

16
 Some definitions
• Error
• Fault
• Failure
– What do we observe in testing?

17
 Testing Philosophy
• It is dangerous to test early modules without
an overall testing plan
• It may be difficult to reproduce the sequence
of events causing an error
• Testing must be done systematically and
results documented carefully

18
 Stages of Testing
• Unit testing
– Tests each module to assure that it performs its function
• Integration testing
– Tests the interaction of modules to assure that they work
together
• System testing
– Tests to assure that the software works well as part of the
overall system
• Acceptance testing
– Tests to assure that the system serves organizational needs

19
Error Discovery Rates

20
 Unit Testing
• Black Box Testing
– Focuses on whether the unit meets requirements stated
in specification
• White-Box Testing
– Looks inside the module to test its major elements

21
 Test Planning
• Address all products created during
development
• Test completeness of CRC cards
• Test cases
• Stubs

22
 Exhaustive Testing (infeasible)

Two nested loops

containing four
if..then..else
statements. Each
loop can execute
up to 20 times

There are 10^14 possible paths! If we execute one test per

millisecond, it would take 3170 years to test this program
23
 Selective Testing (feasible)

Test a carefully selected execution path. Cannot be comprehensive

24
Class Test Plan

25
 Path Testing
• Program flow graphs
– Describes the program control flow
– Used as a basis for computing the cyclomatic complexity
– Complexity = Number of edges - Number of nodes +2

i f- t h e n - e ls e l o o p - w h ile c a se - o f
26
 Binary Search Flow Graph
1

(wh il e B ot t < = To p l oo p)
2

(if n ot Fo un d t he n ...)
3

(If T (m id ) = Ke y th e n.. .)
4 5

6 7
(if T (m id) < K e y t hen...)

8 9

10

12 11

Independent Paths
13 1,2,12,13
1, 2, 3, 4, 12, 13
1, 2,3, 5, 6, 11, 2, 12, 13
1, 2, 3, 5, 7, 8, 10, 11, 2, 12, 13
1, 2, 3, 5, 7, 9, 10, 11, 2, 12, 13 27
 Independent Paths
• CC = The number of tests to test all control statements equals =
number of conditions in a program
• Independent Paths
– 1,2,12,13
– 1, 2, 3, 4, 12, 13
– 1, 2,3, 5, 6, 11, 2, 12, 13
– 1, 2, 3, 5, 7, 8, 10, 11, 2, 12, 13
– 1, 2, 3, 5, 7, 9, 10, 11, 2, 12, 13
• Test cases should be derived so that all of these paths are executed
• A dynamic program analyser may be used to check that paths have
been executed

28
 Cyclomatic complexity
• Cyclomatic complexity (CV)
CV(G) = V(G) + 1
here
V(G) = e – n + p
where
e = no of edges in graph
n = number of nodes
p = number of components

29
 Cyclomatic Complexity and Errors
• A number of industry studies have indicated that the higher
V(G), the higher the probability of errors

modules

V(G)

modules in this range are

more error prone
30
 Integration Testing
• User interface testing
– Tests each interface function
• Use-case testing
– Ensures that each use case works correctly
• Interaction testing
– Tests each process in a step-by-step fashion
• System interface testing
– Ensures data transfer between systems

31
 System Testing
• Requirements Testing
– Ensures that integration did not cause new errors
• Usability Testing
– Tests how easy and error-free the system is in use
• Security Testing
– Assures that security functions are handled properly
• Performance Testing
– Assures that the system works under high volumes of
activity
• Documentation Testing
– Analysts check that documentation and examples work
properly

32
 Acceptance Testing
• Alpha Testing
– Repeats tests by users to assure they accept the
system
• Beta Testing
– Uses real data, not test data

33
 Summary
• The project manager needs to manage coordination,
scheduling, and overall effectiveness of the project.

• Testing begins early in the development process and

continues looking to find problems throughout the
development lifecycle.

• Documentation helps the user quickly assimilate the

new technology and provide assistance in
transitioning to the new business processes.

34