CHAPTER 1

O BJECT -O RIENTED S OFTWARE

D EVELOPMENT:

A N I NTRODUCTION

L EARNING O UTCOME :

Identify software engineering challenges

Understand the process involved in software engineering

Identify various software development process models in software

engineering

Understand the fundamental concepts of object-orientation and the

justifications for an object-oriented approach

O VERVIEW

The evolving of OOSD is depends on the

advances in the following areas:

Convergence of OO modeling techniques

and notation

Development of OO framework and

widespread use of design patterns

Adoption of OO development paradigm by

software industry

O UTLINE

Challenges of software development

Software engineering - revisit

Object-orientation

Iterative development

C HALLENGES OF S OFTWARE
D EVELOPMENT
The Economist magazine (Nov 27, 2009 p.
71) cites the Standish Group's estimates that
"...30% of all software projects are canceled,
nearly half come in over budget, 60% are
considered failures by the organizations
that initiated them, and 9 out of 10 come
in late.

C HALLENGES OF S OFTWARE
D EVELOPMENT

According to survey of managers in 102 of UKs

top companies, almost half had encountered
an IT project failure (Kelly, 2007). Major factors
are poor specification and poor understanding
between business and IT departments.

Survey by Economist Intelligence Unit found

that more than half of the IT projects in a
majority of UK companies failed to meet
expectations (Veitch, 2007)

C HALLENGES OF S OFTWARE

D EVELOPMENT  COMPLEXITY

Software system being developed today

are often very large and complex.

Complexity is dictated by the problems

the systems are intended to solve and the
services they are intended to provide.

Methodologies, techniques and tools

must be effectively used.

C HALLENGES OF S OFTWARE
D EVELOPMENT  LONGEVITY &

EVOLUTION

Software system are often in service for

very long periods of time.

Evolving to accommodate changes in

users need and environment is difficult to
maintain.

Maintenance involves cost, time and also

degrade the quality

C HALLENGES OF S OFTWARE
D EVELOPMENT  HIGH USER

EXPECTATIONS

In the past, majority of users were

scientists and engineers who have
technical skills to handle glitches.

Today, computers are used in homes,

schools, and businesses. Majority of user
are nontechnical, ordinary people.

They expected quality and bug-free.

S OFTWARE S YSTEM
Q UALITIES

10

Usefulness: should adequately address the needs of their

intended users in solving problems and providing services.

Timeliness: should be completed and shipped in a timely

manner.

Reliability: should perform as expected by users



Maintainability: should be easily maintainable



Correctness, robustness, availability,

Maintainable, i.e., possible to make corrections,

adaptations, and extensions without undue costs.

Reusability: components should be designed as general

solutions to a class of problems in different contexts

S OFTWARE S YSTEM
Q UALITIES

11

User friendliness: should provide user-friendly

interfaces tailored to the capabilities

Efficiency: should not make wasteful use of

system resources


CPU time, memory, and disk space, etc.

M AINTAINABILITY R EVISITED

12

Maintenance costs far exceed development costs.

Maintainability should be focus because:



Software is long lifetimes

Current development technology does not

yield high reliability. Reliability is attained
through repeated corrections.

High maintainability requires flexibility in

design and implementation of software

W HAT C ONTRIBUTES TO
M AINTAINABILITY ?

13

Flexibility

Simplicity

Readability (understandability)

F LEXIBILITY

14

Changeable


The various aspects of software systems

should be easily changeable.

Minimal impact


Impact of change should be confined to a

small region.

The correctness of the change should be

reasoned by examining only the small affected
region rather than the entire software.

S IMPLICITY

15

Impossible to avoid making mistakes

When things are simple

Less error-prone

Easier to show correctness

Errors become more obvious and correcting

errors is easier.

Divide-and-conquer approach

R EADABILITY

16

This is prerequisite for maintainability

Depends on:


the clarity and the simplicity of the design

and the program code.

The clarity and completeness of the

documentation

Simple and consistent style of design,

implementation and documentation.

17

C HALLENGES OF S OFTWARE
D EVELOPMENT  P ROBLEMS &
2010 BENNETT, MCROBB AND FARMER

Problem
The wrong problem is addressed
Project undertaken for wrong reason

Wider influences are neglected

Missing or inappropriate functionality
Incorrect requirements analysis
Users change their minds
External events change the environment
Poor interface design
Inappropriate data entry
Software causes inappropriate ways of
working
Incomprehensible error messages
Unhelpful help
Requirements changed before project delivery

I NDICATIVE

SOLUTIONS

How to minimize risk

Strategic Information Systems Planning,
Business Modelling, Systematic Approach
Strategic Information Systems Planning,
Business Modelling, Systematic Approach,
Prototyping
Systematic Approach, Requirements,
Prototyping
Systematic Approach, RUP, AUP, EUP
Prototyping, User involvement, RUP, AUP
Prototyping, User involvement
Systematic Approach, User Involvement
User involvement
Systematic Approach, RUP, Agile, AUP

O UTLINE

18

Challenges of software development

Software engineering  revisit

Object-orientation

Iterative development

S OFTWARE E NGINEERING

19

Goals are to:

Produce software that meets the need of

users.

Produce correct software on time and on

budget

Produce software that can be maintained

and modified to keep abreast of changing
needs.

S OFTWARE E NGINEERING

20

Engineering discipline concerned with all

aspects of developing and delivering highquality and useful software in a cost-effective
manner

Defines activities and products (deliverables).

Defines the software development processes,

which define the order for carrying out the
development activities and the criteria for
the deliverables of the activities.

S OFTWARE A S

21

PRODUCT

What is software?


Computer program or source code

Encompasses the source code as well as all the

associated documentation produced during
activities.

The documentation may include requirement

specifications, architecture and design document,
data design, installation and user manual and so on.

S OFTWARE

22

AS PRODUCT

Software categories

 Custom software custom made

 Generic software general specification
 Embedded software incorporated into some

other product.

S OFTWARE E NGINEERING

23

S OLVING P ROBLEMS

Software products are large and complex

Development requires analysis and synthesis



Analysis: decompose a large problem into

smaller, understandable pieces


abstraction is the key

Synthesis: build (compose) a software from

smaller building blocks


composition is challenging

S OFTWARE E NGINEERING

24

S OLVING P ROBLEMS ( CONTINUED )

The analysis
process

The synthesis
process

T HE

25

SOFTWARE PROCESS

Many different software processes but all involve:



Analysis (i.e., requirements engineering) analysing and

defining what the system should do;

Design and Implementation defining the organization of

the system and implementing the system;

Verification and Validation testing; checking that it does

what the customer wants;

Evolution (i.e., maintenance) changing the system in

response to changing customer needs.

The terminology and details of each process may differ,

but the generic activities remain reasonably consistent.

R EQUIREMENTS E NGINEERING

26

Handling the requirements systematically

 The process of establishing what services are required
and the constraints on the systems operation and
development.
 Requirements engineering process [Sommerville, 2011]







Feasibility study - Is it technically and financially feasible to

build the system?
Requirements elicitation and analysis - What do the
system stakeholders require or expect from the system?
Requirements specification - Defining the requirements in
detail
Requirements validation - Checking the validity of the
requirements
26

R EQUIREMENTS ENGINEERING

27

Goals


To define the problem to be solved, i.e., to establish the

functions, services, and constraints of the software to
be developed.

Deals with the development of software requirements

Deliverables


Requirements specifications itemizing the functional

and nonfunctional requirements, called requirements
specifications.

IEEE template Software Requirement Specification

(SRS)

28

T HE

REQUIREMENTS
ENGINEERING PROCESS

28

S OFTWARE DESIGN AND

29

IMPLEMENTATION

The process of converting the system specification into

an executable system.

Software design


Implementation


Design a software structure that realises the

specification;

Translate this structure into an executable program;

The activities of design and implementation are

closely related and may be inter-leaved.

D ESIGN

30

Goals


To construct a solution to the problem by establishing

an overall architecture of the software, by partitioning
the software into components, and by identifying the
relationships and dependencies among them.

Deliverables


System design document and detailed design document,

along with various diagrams.

D ESIGN ACTIVITIES

31

Architectural design, where you identify the overall

structure of the system, the principal components
(sometimes called sub-systems or modules), their
relationships and how they are distributed.

Interface design, where you define the interfaces between

system components.

Component design, where you take each system component

and design how it will operate.

Database design, where you design the system data

structures and how these are to be represented in a
database.
31

32

A GENERAL MODEL OF THE

DESIGN ACTIVITIES

32

I MPLEMENTATION

33

Goals


To translate and implement the software

designs into an executable program

Deliverables


Source code and documentation

S OFTWARE

34

VERIFICATION

& VALIDATION

Verification and validation (V & V) is intended to

show that a system conforms to its specification
and meets the requirements of the system
customer.

Involves checking and review processes and

system testing.

System testing involves executing the system with

test cases that are derived from the specification
of the real data to be processed by the system.

Testing is the most commonly used V & V activity.

T ESTING

35

Development or component testing



Individual components are tested independently;

Components may be functions or objects or coherent groupings of these entities.

System testing


STAGES

Testing of the system as a whole. Testing of emergent properties is particularly

important.

Acceptance testing


Testing with customer data to check that the system meets the customers needs.

36

T ESTING

PHASES IN A PLAN DRIVEN SOFTWARE PROCESS

S OFTWARE

37

EVOLUTION

Software is inherently flexible and can change.

As requirements change through changing

business circumstances, the software that
supports the business must also evolve and
change.

S OFTWARE

38

Goals


EVOLUTION

To improve the system after it is already in

use, e.g., correcting bugs, improving
performance, enhancing functions or services,
and adapting to new environments.

Deliverables


New version and documentation of changes

Longest and most costly activity in the software life

cycle!

S OFTWARE

39

EVOLUTION

Software evolution takes place when you change

existing software systems to meet new requirements

Changes are continuous and the software must

evolve to remain useful

O UTLINE

40

Challenges of software development

Software engineering

Object-orientation

Iterative development

H OW H AS SE C HANGED ?

41

WASSERMAN ' S S EVEN K EY FACTORS

[ P F L E E G E R & AT L E E , 2 0 1 0 ]

The key factors that have changed the software

development

H OW H AS SE C HANGED ?

42

WASSERMAN ' S

DISCIPLINES OF SE
[ P F L E E G E R & AT L E E , 2 0 1 0 ]

Abstractions

Analysis and design methods and notations

User interface prototyping

Software architecture

Software process

Reuse

Measurement

Tools and integrated environments

H OW H AS SE C HANGED ?

43

A BSTRACTION

A description of the problem at some level of

generalization


Hide details

44

T HE WATERFALL MODEL

WATERFALL MODEL

45

PHASES

There are separate identified phases in the

waterfall model:






Requirements analysis and definition

System and software design
Implementation and unit testing
Integration and system testing
Operation and maintenance

The main drawback of the waterfall model is the

difficulty of accommodating change after the
process is underway. In principle, a phase has to be
complete before moving onto the next phase.

WATERFALL M ODEL

46

CHARACTERISTICS

Sequential

Phase based


Phase is the span of time between two major

milestones of the process in which a welldefined set of objectives are met, artifacts
are completed, and decisions are made
whether to move into the next phase.

Document driven (often called milestone)

WATERFALL MODEL

47

PROBLEMS

Inflexible partitioning of the project into distinct

stages makes it difficult to respond to changing
customer requirements.


only appropriate when the requirements are wellunderstood and changes will be fairly limited during the
design process.
few business systems have stable requirements.

The waterfall model is mostly used for large

systems engineering projects where a system is
developed at several sites.


In those circumstances, the plan-driven nature of the

waterfall model helps coordinate the work.

DEALING WITH COMPLEXITY

48

Complex systems are hard to understand

Three ways to deal with complexity



Abstraction and Modeling

Decomposition

Hierarchy

49

DEALING WITH COMPLEXITY

A BSTRACTION
Abstraction allows us to ignore unessential details
Two definitions for abstraction:
Abstraction is a thought process where ideas are
distanced from objects
Abstraction as activity
Abstraction is the resulting idea of a thought
process where an idea has been distanced from
an object
Abstraction as entity
Ideas can be expressed by models

DEALING WITH COMPLEXITY

M ODEL

50

A model is an abstraction of a system



A system that no longer exists

An existing system

A future system to be built.

51

S YSTEMS AND THE R EAL

W ORLD
2010 BENNETT, MCROBB

AND

FARMER

52

M ODELING

THE

R EAL W ORLD

A software system provides a solution to a problem in the real

world.

It consists of two essential components:



Model: abstraction of a part of the real world

Algorithm: captures the computations involved in manipulating

or processing the model.

Software system
Abstraction
Real world

Model
Interpretation

Algorithm

W E USE M ODELS TO DESCRIBE

S OFTWARE S YSTEMS

53

Object model: What is the structure of the system?

Functional model: What are the functions of the

system?

Dynamic model: How does the system react to

external events?

System Model: Object model + functional model +

dynamic model

O THER MODELS USED TO DESCRIBE

S OFTWARE S YSTEM D EVELOPMENT

Task Model:


PERT Chart: What are the dependencies between

tasks?

Schedule: How can this be done within the time limit?

Organization Chart: What are the roles in the project?

H OW TO M ODEL R EAL
W ORLD ?

55

The real world is enormous and complex.

Many of its aspects are fuzzy, unknown or

intangible.

Programming models used in software must be

precise and relatively small.

Model is abstraction of real world captures only

relevant and essential characteristics.

H OW TO M ODEL R EAL
W ORLD ?

56

Programming languages


Tools to describe computer models

Programming models


Computation-oriented model (50s ~ 60s)

Data-oriented model (70 ~ 80s)

Object-oriented model (90s ~ )



Balanced view between data and computation

W HY O-O M ODEL ?

57

Possible to directly represent real world objects in the

computer system

Thus, solves the so-called impedance mismatch

problem.

Data-oriented model

Real world

Software system

Object-oriented model

Real world

Software system

DEALING WITH COMPLEXITY

D ECOMPOSITION

58

A technique used to master complexity (divide and

conquer)

Two major types of decomposition

Functional decomposition

Object-oriented decomposition

Functional decomposition


The system is decomposed into modules

Each module is a major function in the application

domain

Modules can be decomposed into smaller modules.

D ECOMPOSITION ( CONT D )

59

Object-oriented decomposition


The system is decomposed into classes (objects)

Each class is a major entity in the application domain

Classes can be decomposed into smaller classes

O UTLINE

60

Challenges of software development

Software engineering

Object-orientation

Iterative development

I TERATIVE D EVELOPMENT

61

(B OOCH 1994)

Key characteristics
Consists of a number of successive iterations
 Each iteration produces a working program
 Build system incrementally
 Monolithic approach of waterfall model


Benefits
Facilitates and manage changes
Minimize and prevent changes

Examples
Rational Unified Process (RUP)
 Extreme Programming (XP)


RUP

62

Complete software engineering process.

Goal to ensure the production of highquality software that meets the needs of
its end users within a predictable
schedule and budget (Booch et al., 1999)

It is a process framework that can be

adapted and extended to suit the needs
of different organizations and different
types of projects.

RUP

63

Key practices are:

Develop software iteratively

Systematically elicit, organize and manage

changing requirements

Use component-based architecture

Visually model software using UML

Continuously verify software quality

Control changes to software

Emphasis on building models rather than paper

documents

RUP

64

Nine models covers all important decisions

that go into visualizing, specifying,
constructing, and documenting a softwareintensive system (Booch et al., 1999)

The models: business model, domain

model, use case model, analysis model,
design model, process model, deployment
model, implementation model, test model

RUP is use case driven

RUP

65

Nine process workflows:

Business modeling-structure and dynamics of

the organization

Requirements-use case-based method

Analysis and design-multiple architectural

view

Implementation- development, unit and

integration testing

Test-test cases, procedures and defecttracking metrics

RUP

66

Deployment- deliverables system

configuration

Project management-various strategies of

working with an iterative process

Environment necessary infrastructure to

develop a system

RUP

67

Four major phases:

Inception establish business case for the

project

Elaboration establish project plan and a

sound architecture

Construction grows the system

Transition supplies system to its end user

 Each phase is broken down into one/more

iterations.

68

RUP

RUP

69

THE

Approach


O BJECT -O RIENTED D EVELOPMENT

Focuses on improving the maintainability and

reusability of software systems through a set
of techniques, notations, tools, and criteria.

Activities






Conceptualization
Object-oriented analysis and modeling
Object-oriented design
Implementation
Maintenance

D ETAILED A CTIVITIES

70

Conceptualization
 To establish the vision and core requirements of
the software system to be developed.

Object-oriented analysis and modeling
 To build models of the systems desired behavior,
using notations such as the Unified Modeling
Language (UML).
 To capture the essential relevant aspects of the
real world and to define the services to be
provided and/or the problems to be solved.
 To simplify reality to better understand the
system to be developed.

D ETAILED A CTIVITIES

71

Object-oriented design


To create an architecture for implementation.

Represented in terms of objects and classes

and the relationships among them.

Main concern:


Does design satisfy all the stated requirements

and constraints?

Is the design flexible to accommodate future

changes?

Is the design feasible for implementation?

D ETAILED A CTIVITIES

72

Implementation:


To implement the design by using an objectoriented programming language (e.g., Java)

Involves coding, testing, debugging

Maintenance:


To manage post-delivery evolution effectively.

Task:




Removing bugs
Enhancing functionalities
Adapting to evolving needs and environment

73

O BJECT - ORIENTED
DEVELOPMENT

R EFERENCES

74

Sommerville (2011). Software Engineering, 9th Edition,

Pearson.

Bennett, McRobb and Farmer (2010). Object-oriented

systems analysis and design using UML, 4th edition,
McGrawHill.

Pfleeger and Atlee (2010). Software Engineering. Pearson.

Jia, Xiaoping (2001) Object-Oriented Software

Development Using Java: Principles, Patterns and
Frameworks. Addison Wesley.

www.cs.utep.edu/cheon/cs3331/notes/oosd.ppt