Chapter 6:

Object Oriented Implementation,

Testing and Maintenance

Pragmatics- Making it a Reality

 2

Outline of topics
 Object Oriented Implementation, Testing and
Maintenance.
 OO Implementation
 Testing Philosophies
 The full-lifecycle object oriented testing (FLOOT)
methodology
 Quality Assurance
 Test Driven Development
 Transition/Deployment issues
 OO Software Maintenance ( Evolution)
 Documentation
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 3

1. Introduction
 Pragmatics, what is it? Why is it important ?
 Software development today is a multibillion-dollar,
competitive, worldwide business, stretching from North
America through Western and Eastern Europe and into Asia
and the Pacific Rim.
 In spite of the tools available to support the major
functions in object-oriented development—(requirements
management, configuration management, design, code,
and test)—there are still too many failures. (Booch)
 Schedules are missed.
 Costs are overrun.
 Functionality is not provided.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 4

Introduction Cont’d…
 Pragmatics, what is it ? Why is it important?
 Tens to hundreds of millions of dollars are lost on single
development efforts.
 An unfortunate example is the FBI’s Virtual Case File system, which was intended to
be an important tool in fighting terrorism.
 After more than three years in development, in April 2005 “the bureau had to scrap
the US $170 million project, including $105 million worth of unusable code”.
 On March 16, 2006, the FBI awarded a $305 million contract to develop the
Sentinel system to replace the Virtual Case File system.
 This is but one example of far too many failed software developments .
 Pragmatics is concerned with how the system design process we have done so far
would be linked to the reality or how it would give sense or meaning to the
stakeholders.
 These issues will cover Coding, testing along with documentation and object
oriented benefit realization.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 5

Introduction Cont’d…
Remember that ;
 Object-oriented analysis, design and
programming are related but distinct.
 OOA is concerned with developing an object model of the
application domain.
 OOD is concerned with developing an object-oriented
system model to implement requirements.
 OOP is concerned with realising an OOD using an OO
programming language such as Java, C# or C++.

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 6

2. Design and OO Implementation

 The purpose of object-oriented programming is to build your
actual system, to develop the code that fulfills your system’s
design.
 Your design artifacts, such as unified modeling language
(UML) class and state machine diagrams, drive the
development of your source code.
 Design and programming are highly interrelated and iterative
and you will often move back and forth between them.
 Your programming efforts will quickly reveal weaknesses
in your design that need to be addressed, and your design
efforts will reveal potential strategies to code the system
effectively.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 7

OO Design and Implementation

Developers will typically focus on

two types of source code:
 Object-oriented code, such as Java or
C#, and
 Database-oriented code, such as data
definition language (DDL), data
manipulation language (DML), stored
procedures, and triggers etc.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Philosophies for effective 8

programming
 Always write high-quality, clean code:
 Quality work is one of the practices of extreme programming (XP).
 High-quality code is easier to write, easier to understand, and easier to
enhance.
 Refactor ruthlessly:
 Make small changes to your code to improve its design without adding new
functionality.
 Refactoring includes, renaming a method, splitting a method in two,
moving a method up a class hierarchy etc.
 Think before you code:
 Conduct test or model driven development.
 Develop in small steps:
 Writing a few lines of code, testing it, and then writing a few more lines—is
often far more effective than writing a whole bunch of code all at once.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Philosophies for effective 9

programming Cont’d…
 Write understandable code:
 Program for people, not just only you
 Adopt and follow coding standards and guidelines:
 Add Internal documentation to improve code readability:
 Comments /*-------*/
 Write the documentation before you write the code:
 Write code documents before or as you code it.
 Follow the 30-second rule:
 Look at a method, a class, or an interface definition and be able to fully understand
what it does, why it does it, and how it does it in less than 30 seconds
 A method can be made understandable in less than 30 seconds by effective heading
documentation, adherence to common naming and programming conventions, and
effective internal documentation.
 Smaller methods are usually better:
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Object Oriented Programming 10

Languages
 Palo Alto Research Center (PARC)
developed Smalltalk in the early 1970’s
 Smalltalk is considered the first truly object-
oriented Language
 Led other languages to support object-
oriented programming
 examples: Objective-C, C++, Self, Eiffel, and
Flavors
 1980 Booch pioneered the concept of
object-oriented design (OOD)
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Object Oriented Programming Language 11

Evolution

 Object-orientation boom (1980–1990, but few languages survive)

 Smalltalk 80 Pure object-oriented language
 C++ Derived from C and Simula
 Ada83  Strong typing; heavy Pascal influence
 Eiffel Derived from Ada and Simula
 Emergence of frameworks (1990–today) Much language activity,
revisions, and standardization have occurred, leading to
programming frameworks.
 Visual Basic Eased development of the graphical user interface (GUI)
for Windows applications
 Java Successor to Oak; designed for portability
 Python  Object-oriented scripting language
 J2EE  Java-based framework for enterprise computing
 .NET Microsoft’s object-based Framework
 Visual C# Java’s competitor from the Microsoft .NET Framework
 Visual Basic .NET Visual Basic for the Microsoft .NET Framework
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Object Oriented vs Object based 12

Languages
 Object-oriented programming is a method of implementation in which
programs are organized as cooperative collections of objects, each of
which represents an instance of some class, and whose classes are
all members of a hierarchy of classes united via inheritance
relationships.

 In other Words, a language is object-oriented if and only if it satisfies

the following requirements:
 It supports objects that are data abstractions with an interface of named
operations and a hidden local state.
 Objects have an associated type [class].
 Types [classes] may inherit attributes from supertypes [superclasses].
 If a language does not provide direct support for inheritance, then it
is not object-oriented. Such languages are called object-based.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Modern day OO Programming 13

Languages

Java
C#
Python
Ruby
PHP
R
…too many to list them all here.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 14

3. OO Implementation (Programming)

In developing an object oriented

software, we need to implement
classes and object interaction
mechanisms.
 Classes
 Member variables
 Member methods

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 15

Relationship among classes

Association
Aggregation
Composition
Inheritance

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 16

Class Relationships - Association

Association represents a general binary relationship that
describes an activity between two classes.

Take Teach
5..60 0..3 1
Student * Course Teacher
Faculty

public class Student { public class Course { public class Faculty {

/** Data fields */ /** Data fields */ /** Data fields */
private Course[] private Student[] private Course[]
courseList; classList; courseList;
private Faculty faculty;
/** Constructors */ /** Constructors */
/** Methods */ /** Constructors */ /** Methods */
} /** Methods */ }
}

An association is usually represented as a data field in the class.

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 17

Aggregation and Composition

Aggregation is a special(stronger) form of association,
which represents an ownership relationship between two
classes. Aggregation models the has-a relationship.

If an object is exclusively owned by an aggregated object,

the relationship between the object and its aggregated
object is referred to as composition( a stronger form of
aggregation). (the parts are expected to live and die
with the whole)
Composition Aggregation

Name Person Address

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 18

Aggregation and Composition

An aggregation relationship is usually represented as
a data field in the aggregated class.

public class Name { public class Person { public class Address {

/** Data fields */ /** Data fields */ /** Data fields */
/** Constructors */ private Name name; /** Constructors */
/** Methods */ private Address address; /** Methods */
} }
/** Constructors */
/** Methods */
}

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 19

Inner Classes Translation( in java)

 If Name or Address is used in the Person class only,
they can be declared as an inner class in Person. For
example,public class Person {
private Name name;
private Address
address;
...
class Name {
...
}

class Address {
...
}
11/16/2025 } Chapter 6 Object Oriented Implementation, Testing and Maintenance
 20

Inheritance

Inheritance models the is-an-extension-

of relationship between two classes.

public class Faculty extends Person {

/** Data fields */
Person Faculty
/** Constructors */
/** Methods */
}
(A) (B)

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 21

Weak Inheritance
A weak is-an-extension-of relationship can be
represented using interfaces. For example, the
weak is-an-extension-of relationship “students are
comparable based on their grades” can be represented
by implementing the Comparable interface, as follows:
public class Student extends Person
implements Comparable {
Person /** Data fields, Constructors, and */
Student /** Methods */
Comparable
/** Implement the compareTo method */
public int compareTo(Object object) {
// ...
}
}
(A) (B)
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Multiple Inheritance- Not supported 22

by most languages.

Not an option for most development

languages
C++ and Eiffel support multiple
inheritance, but Java and C# do not.
C++ has an interesting concept called
“mixin classes,” where multiple
inheritance is used to obtain behaviors
implemented by an other class.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 23

Using Inheritance or Aggregation

 In general, the difference between inheritance
and aggregation is the difference between the
“is-an-extension-of” relationship and the “has-
a relationship”.
 For example,
 An apple is fruit; thus, you would use inheritance to model
the relationship between the classes Apple and Fruit.
 A person has a name; thus, you would use aggregation to
model the relationship between the classes Person and
Name
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Using Inheritance or Aggregation, 24

cont’d…

Both designs are fine. Which one is

preferred?
 If polymorphism is desirable, you need to use
the inheritance design.
 If you don’t care about polymorphism, the
aggregation design gives more flexibility
because the classes are less
dependent(loosely coupled) using
aggregation than using inheritance.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 25

Using Interfaces or Abstract Classes

Both interfaces and abstract classes can

be used to generalize common features.
How do you decide whether to use an
interface or a class?
In general,
 a strong is-an-extension-of relationship that clearly
describes a parent-child relationship should be
modeled using classes.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Using Interfaces or Abstract Classes 26

Cont’d…
 For example, since an orange is a fruit, their relationship should be
modeled using class inheritance.
 A weak “is-an-extension-of” relationship, also known as an is-kind-of
relationship, indicates that an object possesses a certain property.
 A weak is-an-extension-of relationship can be modeled using
interfaces.
 For example,
 All strings are comparable, so the String class implements the Comparable
interface.
 A circle or a rectangle is a geometric object, for example, so Circle can be designed
as a subclass of GeometricObject.
 Circles are different and comparable based on their radius, for example, so Circle
can implement the Comparable interface.

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

Using Interfaces or Abstract Classes 27

Cont’d…

 Interfaces are more flexible than abstract classes,

because a subclass can extend only one superclass,
but implement any number of interfaces.
 However, interfaces cannot contain concrete
methods.
 You can combine the virtues of interfaces and abstract
classes by creating an interface with a companion
abstract class that implements the interface.
 So you can use the interface or its companion class
whichever is more convenient.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 28

4. Object Oriented Testing

OO Testing Philosophies (Ambler)

 The goal is to find defects
 You can validate all artifacts
 Test often and early
 Testing builds confidence
 Test to the amount of risk of the artifact.
 One test is worth a thousand opinions
 Testing is not about fixing things
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Full Life Cycle Object Oriented 29

Testing(FLOOT)

Anything worth building is worth testing.

 You build a wide variety of artifacts, including
models, documents, and source code.
 You will need testing techniques that enable you
to validate the wide range of artifacts that you
create during software development.
A critical concept that motivates full-
lifecycle testing is the cost of change
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 30

The Cost of Change

 The traditional cost of change
curve (McConnell 1996; Ambler
1998) for the single release of
a project following a serial
(waterfall) process.

 Kent Beck (2000) argues that

in extreme programming (XP)
the cost of change curve is flat.
 Questioned by Many people
 But the claim is that “test early and
often”
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
A More Realistic cost of change 31

curve

For Agile Software

Developments –
this is the most
realistic curve

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

The techniques to apply FLOOT
 33

Quality Assurance
 Schulmeyer and McManus define software quality as “the fitness
for use of the total software product” .
 Software quality doesn’t just happen: It must be engineered into the
system.
 Quality assurance (QA) is the act of reviewing and auditing the
project deliverables and activities to verify that they comply
with the applicable standards, guidelines, and processes
adopted by your organization.
 Fundamentally, quality assurance attempts to answer the following
questions:
 “Are you building the right thing?” and
 “Are you building it the right way?”
 Which question is important? and why?
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 34

What does “Quality” Cover?

 A key concept in quality assurance is that quality is
often in the eye of the beholder, indicating many aspects
exist to software quality, including the following:
 Does it meet the needs of its users?
 Does it provide value to its stakeholders?
 Does it follow relevant standards?
 Is it easy to use by its intended users?
 Is it reasonably free of defects?
 Is it easy to maintain and to enhance?
 How easy will it integrate into the current technical environment?
 Quality assurance is critical to the success of a project and
should be an integral part of all project stages, but only
when it is done in an effective and efficient manner.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 35

Effective and Efficient Testing

 To test effectively, you must use a strategy that
uncovers as many defects as possible.
 To test efficiently, you must find the largest possible
number of defects using the fewest possible tests
 Testing is like a detective’s work:
 The tester must try to understand how programmers and
designers think, so as to better find defects.
 The tester must not leave anything uncovered, and must be
suspicious of everything.
 It does not pay to take an excessive amount of time; tester has to
be efficient.

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 36

What Testing Shows…

errors

requirements conformance

performance

an indication
of quality

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 37

What Testing Shows

 A failure is an unacceptable behaviour exhibited by a system
 The frequency of failures measures the reliability
 An important design objective is to achieve a very low
failure rate and hence high reliability.
 A failure can result from a violation of an explicit or
implicit requirement
 A defect is a flaw in any aspect of the system that contributes, or
may potentially contribute, to the occurrence of one or more failures
 could be in the requirements, the design and the code
 It might take several defects to cause a particular
failure
 An error is a slip-up or inappropriate decision by a software
developer that leads to the introduction of a defect
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 38

Software Testing

white- black-
box box
method
s method
s

Methods

Strategies

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 39

White-Box Testing

... our goal is to ensure that all

statements and conditions have
been executed at least once ...

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 40

White-Box Testing Cont’d…

 Also called ‘Glass-box testing’ or

‘structural’ testing
 Testers have access to the system design
 They can
 Examine the design documents
 View the code
 Observe at run time the steps taken by algorithms and their
internal data
 Individual programmers often informally employ
glass-box testing to verify their own code
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 41

Black-Box Testing

requirements

output

input events

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 42

Black-Box Testing

Testers provide the system with

inputs and observe the outputs
 They can see none of:
 The source code
 The internal data
 Any of the design documentation describing the
system’s internals

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 43

Testing Your Models

 The earlier you detect an error, the less expensive it is
to fix.
 Therefore, it is imperative for you attempt to test your
requirements, analysis, and design artifacts as early
as you can.
 Luckily, a collection of techniques exist that you can apply to
do exactly that.
 Proving it with code;
 Usage scenario testing
 Prototype walkthroughs
 User interface testing; and
 Model reviews.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 44

Testing Your Code

 You have a wide variety of tools and techniques to test
your source code.
 A test case is a single test that needs to be performed.
 If you discover that you need to document a test
case, you should describe
 Its purpose;
 The set up work you need to perform before running the test to
put the item you are testing into a known state;
 The steps of the actual test; and
 The expected results of the test.

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

Writing Formal Test Cases and 45

Test Plan

A test case is an explicit set of

instructions designed to detect a
particular class of defect in a
software system.
 A test case can give rise to many tests.
 Each test is a particular running of the test
case on a particular version of the system.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 46

Test Plans
 A test plan is a document that contains a complete set of
test cases for a system
 Along with other information about the testing process.
 The test plan is one of the standard forms of documentation.
 If a project does not have a test plan:
 Testing will inevitably be done in an ad-hoc manner.
 Leading to poor quality software.
 The test plan should be written long before the testing starts.
 You can start to develop the test plan once you have developed the
requirements.

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 47

Testing Tools
 Many Agile Developers use
 xUnit family of open source tools, such as;
 JUnit ([Link] and
 VBUnit ([Link] to test their code.
 The advantage of these tools is that they implement a testing
framework with which you can regression test all of your source code.
 Commercial testing tools, such as
 Mercury Interactive ([Link]
 jTest ([Link] and
 Rational Suite Test Studio ([Link] are also viable options.
 One or more testing tools must be in your development
toolkit;
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Object-Oriented Testing 48

Techniques
 Until just recently, object-oriented testing has been a
“little understood” topic.
 When testing systems built using object technology
it is important to understand that your source code is
composed of several constructs, including
 methods (operations),
 classes, and
 inheritance relationships.
 Therefore you need testing techniques that reflect
the fact that you have these constructs.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Object-Oriented Testing 49

Techniques
 Method testing. Method testing is the act of ensuring that
your methods, called operations or member functions in C++
and Java, perform as defined.
 Class testing. This is both unit testing and traditional
integration testing.
 Class-integration testing. Also known as component
testing, this technique addresses the issue of whether the
classes in your system, or a component of your system, work
together properly.
 Inheritance-regression testing. This is the running of the
class and method test cases for all the super classes of
the class being tested.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 50

System Testing ( entirety tests)

 System testing is a testing process in which you aim to ensure that
your overall system works as defined by your requirements.
 System testing is typically performed at the end of an iteration,
enabling you to fix known problems before your application is user
tested.
 System testing comprises the following techniques;
 Function testing: development staff verifies that their application meets the
defined needs of their users
 Installation testing: determine whether your application can be installed
successfully
 Operations testing: verify that the requirements of operations personnel are met
 Stress testing: volume testing, this is the process of ensuring that your application
works with high numbers of users, high numbers of transactions (testing of high
numbers of transactions is also called volume testing), high numbers of data
transmissions, high numbers of printed reports, and so on.
 Support testing: similar to operations
11/16/2025 Chapter 6testing except
Object Oriented with a support
Implementation, Testing personnel focus
and Maintenance
 51

Code Inspections

Also known as code reviews, often

reveal problems that normal testing
techniques do not,
In particular, it helps to flag out
 Poor coding practices that make your
application difficult to extend and
maintain.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
The roles of people involved in 52

testing
 The first pass of unit and integration testing is called
Developer testing.
 Preliminary testing performed by the software developers
who do the design.

 Independent testing is performed by a separate

group.
 They do not have a vested interest in seeing as many test
cases pass as possible.
 They develop specific expertise in how to do good testing,
and how to use testing tools.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 53

Tests Performed by Users.

 Alpha testing
 Performed by the user or client, but under the supervision of the software
development team. Alpha testing is a process in which you send out software that is
not quite ready for prime time to a small group of your customers to enable them
work with it and report back to you the problems they encounter( based on
Simulated Data)
 Beta testing
 Performed by the user or client in a normal work environment.
 Recruited from the potential user population.
 An open beta release is the release of low-quality software to the general
population. ( based on Real Data)
 Pilot testing.
 Pilot testing is the “in-house” version of alpha/beta testing,
 The only difference being that the customers are typically internal to your
organization.
 Companies that sell software typically alpha/beta test, whereas IT
organizations that produce software for internal use will pilot test.
 User-acceptance testing (UAT).
 Performed by users and customers.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 However, the customers do it on their own initiative.
 54

5. Test Driven Development

 Test-driven development (TDD), also known as test-first programming or
test-firstdevelopment,isanapproachwhereyouidentifyandwriteyourtests
before your write your code.
 TDD is actually a programming technique and not a validation technique.
 The focus of TDD is code-level testing, something that I like to refer to as
“testing in the small,” and in many ways TDD is simply an extreme form
of unit testing.
 You will still need to consider traditional testing techniques such as
functional testing, user-acceptance testing, system integration testing,
and so on as the full lifecycle object-oriented test (FLOOT) methodology
aptly points out
 Two simple rules for TDD:
 You should write new business code only when an automated test has failed.
 You should eliminate any duplication that you find.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 55

TDD- Basic Steps

 There are four basic steps to TDD.
 First, you quickly add a test (just enough
code to fail.
 The idea is that a programmer refuses to write
new code, even one single line, unless there is
a test that fails without
 Second step is to run your tests, either all or
apportion of them, to see the new test fail.
 Third, you make a little change to your code,
just barely enough to make your code pass
the tests
 Finally, you run the tests and hopefully see
them all succeed—if not you need to repeat
step 3.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Test Driven Development and 56

Refactoring

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 57

(Agile) Model Driven Development

 An important observation is that both TDD and AMDD are based
on the idea that you should think through your design before you
code.
 We have a wide variety of design models—UML class models,
physical data models, UML sequence diagrams, UML timing
diagrams, and so on—
 But how do you convert them to code?
 UML sequence diagrams and UML class diagrams to are the two most useful
design models to base object programming on.
 Sequence diagrams convert almost directly to code, whereas class
diagrams take a little more skill to convert (a skill you can quickly
gain).
 It is clearly possible to iterate to programming from other design diagrams too
but more difficult than class and
11/16/2025 sequence.
Chapter 6 Object Oriented Implementation, Testing and Maintenance
 58

6. Transition Issues
 Remember Transition is one of the main phases in RUP.
 The work products produced during the Transition phase
include
 the packaged product,
 any supporting documentation,
 training materials, and
 marketing materials.
 The Transition phase is successfully completed when the
functionality and quality of the releases are sufficient to
make the product available to end users (the system has
passed acceptance testing)
 This phase mainly focuses on deploying the application to its
production environment along with all it support materials
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Transition Issues- Documentations 59

Cont’d…
 Installation/Deployment
 Putting the system into the production environment.
 Direct(Cut over)- aka “Big Bang” associated with the waterfall model.
 Phased – a portion of the old application is replaced with the new one. Aka Rolling Deployment
 Parallel: A fail-safe process. In this method, two identical production environments work in
parallel. AKA Blue-Green, Red-Black or A/B Deployment
 One Site(single location): the new application is installed in only a subset of the deployment
infrastructure . AKA Canary Deployment
 Training Materials
 Enabling end users and technical personals to work and mange the system/software
 For whom and how much is an important questions?
 Operations Material
 Backup procedures, Batch job and printing requirements, Data extraction/sharing requirements,
Installation procedures, Resource requirements, Release notes
 Support Material
 Contact points within development and operations , Escalation procedures, Support call
recording process, User documentation (all versions), List of new features

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 60

Transition Issues: Deployment

 Development sandboxes.
 Good to have a deployment
script (deployment
specification file)
 Just like you test your
application, you should also
test your installation scripts.
 A good way to do this is to
develop your installation
scripts as you develop your
system, and use them to
promote your software
between your team integration
sandbox into your pre-
production testing
environments

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

Agile UP Deployment discipline workflows – what must be done during software deployment
7. OO Software Maintenance 62

( Evolution)
 Once a software system has been delivered (post-transition),
changes to the deployed system will most likely be needed.
 Planned or not, systems tend to evolve over time, a
condition that is often incorrectly labeled software
maintenance
 Changes may be made to provide new or improved features
(evolution) or to fix discovered defects (maintenance), or
at times to keep an old system functional(preservation).
 The issue of maintaining an operational system without
breaking what is already there is a real concern

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

OO Software Maintenance 63

( Evolution)
 Software change is inevitable
 New requirements emerge when the software is used;
 The business environment changes;
 Errors must be repaired;
 New computers and equipment is added to the system;
 The performance or reliability of the system may have to
be improved.
A key problem for all organizations is
implementing and managing change to
their existing software systems.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Maintenance, Evolution and 64

Preservation
To be more precise,
 it is maintenance when we correct errors;
 it is evolution when we respond to changing
requirements;
 it is preservation when we continue to use extraordinary
means to keep an ancient and decaying piece of software
in operation.
Reality suggests that an excessive percentage of
software development resources are spent on
software preservation
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 65

OO Software Maintenance

Maintenance
 Providing continuous support as long as the
software/system is alive.
 Types of Maintenance
 Adaptive
 Perfective
 Corrective
 Preventive
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
A state machine for a software 66

system ?

 Servicing is basically providing

maintenance or preservation
 During phase-out – The software may
still be used but no further changes
are made to it.

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 67
Observations regarding the maturation of a deployed
software system
 Two important Characterizations of a deployed system maturity.
 A program that is used in a real-world environment necessarily must change or
become less and less useful in that environment (the law of continuing change).
 As an evolving program changes, its structure becomes more complex unless active
efforts are made to avoid this phenomenon (the law of increasing complexity).
 Refinement of deployed software systems is especially important in
agile development
 With agile processes, deployed systems are continually refactored to
simplify their structure without breaking any existing
implementations (e.g., all tests must still pass).
 Changes to a deployed software system can be developed and
delivered by Re-executing a lifecycle that is similar to the original software
development lifecycle, except that
 the size and shape of a maintenance lifecycle depend on what needs to be
accomplished in the release.
 Is accompanied by a change request
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
OO Software Maintenance 68

( Evolution)
 Some maintenance releases involve
 simple localized changes and no architectural innovation (i.e., they include mainly a
Transition phase),
 Others require some thinking with regard to scope and
business value, as well as architecture and risk
 i.e., they include both
 Inception and
 Elaboration phases.
 Such maintenance releases are considered more major, and their lifecycles look
something more like the complete end-to-end process.
 In an evolutionary development( iterative and incremental), the line
between systems development and maintenance is blurred.
 This is because;
 Continuous Integration ??
 Continuous Delivery??

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 69

8. Documentation
 The main goal of effective documentation is to
ensure that developers and stakeholders are
headed in the same direction to accomplish the
objectives of the project.
 To achieve them, plenty of documentation types
exist.
 All software documentation can be divided
into two main categories:
 Product documentation
 Process documentation
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
Project Documentation: Types/ Classification
 71

Documentation types
 Two Types:
 Product documentation describes the product that is being
developed and provides instructions on how to perform various
tasks with it.
 System documentation represents documents that describe the system itself and
its parts. It includes requirements documents, design decisions, architecture
descriptions, program source code…etc.
 User documentation covers manuals that are mainly prepared for end-users of the
product and system administrators. User documentation includes tutorials, user
guides, troubleshooting manuals, installation, and reference manuals.
 Process documentation represents all documents produced during
development and maintenance that describe… well, the process.
 The common examples of process-related documents are standards, project
documentation, such as project plans, test schedules, reports, meeting notes, or even
business correspondence(e-mail, letters etc.).
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 72

System Documentation

 The system documentation can be for internal

or external to the system being developed.
 Internal System Documentation: comments in source
code, generated during the coding process or automatically
by software compilers or documenters are internal to the
system.
 External System Documentation: outcomes of
all diagrams, including use cases, design classes,
activity and sequence diagrams, etc. are
categorized under this sub category.
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 73

End of Chapter 6

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance

 74

Course Summary
 Introduction
 Understanding motivations and basic concepts
 Terminologies , concepts, processes, approaches
 Modeling using UML
 Understanding modeling tools in software development
 Types, categories and structure
 Requirement elicitation
 Collecting and organizing users requirement- WHAT- User
needs
 From function, class, and interface points of view
11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance
 75

Course Summary Cont’d…

 Requirement Analysis
 Analyzing and modeling requirements-WHAT System
 In terms of Function, Logic and Objects (classes)
 System and object design
 Specifying the new system-HOW
 At an architecture level and detail design level
 Implementation, testing and Pragmatic
 Making it a reality
 Coding, testing and documentation

11/16/2025 Chapter 6 Object Oriented Implementation, Testing and Maintenance