OO Development 1 - Introduction to Object-Oriented Development

INTRODUCTION TO OBJECT-ORIENTATIONWhat is it and why do we need it?

1

Paradigms2

Object-orientation is both a programming and analysis/design paradigm. A paradigm is a set of theories, standards and

methods that together represent a way of organizing knowledge; that is, a way of viewing the world [Kuhn 70]

Examples of other programming paradigms: Procedural (Pascal, C) Logic (Prolog) Functional (Lisp) Object-oriented (C++, Smalltalk, Java, C#, VB.NET)

Example of other analysis/design paradigm Structural (process modeling, data flow diagrams,

logic modeling)

Object-Oriented Paradigm3

A development strategy based on idea that computer systems should be built from a collection of reusable components called objects.

Unlike the structural paradigm, objects contain both data and functionality/behavior. That is, objects know things (data) and can do things (behavior).

Source: Scott Ambler, The Object Primer (Cambridge University Press, 2001), p.2

data

behavior

behavior

object

data

behavior

behavior

object

data

behavior

object

behavior

Object vs Functional-Oriented

4

Library Information System

LibrarianCatalog

Book Library

System

Record Loans Add Resources Report Fines

Structured ApproachDecompose by functions or processes

Object ApproachDecompose by objects or concepts

Source: Craig Larman, Applying UML and Patterns (Prentice Hall, 1998), p. 14

Why was a new paradigm needed?

5

According to one survey, 30% to 40% of all software projects are

cancelled the average software project costs more than

double the original cost estimate only 15% to 20% of all software projects are

completed on-time and on-budget. According to another survey (1998)

3 out of 4 software projects have exceeded deadlines and budgets, not worked, or been unmaintainable.

Source: Scott Ambler, The Object Primer (Cambridge University Press, 2001), p.xvii

Source: Leszek Maciaszek, Requirements Analysis and System Design (Addison Wesley, 2001), p. 3

Software Success?

Used as delivered2%

Used after changes

3%

Paid for but not delivered

29%

Used but extensively

reworked or later abandoned

19%

Delivered but never

successfully used47%

6

Source: US Government Accounting Office. Report FGMSD-80-4.FromCraig Larman, Software Economics presentation

Why things go wrong?7

Quality problems The wrong problem is addressed

Failure to align the project with business strategy Wider influences are neglected

Project team or business managers don’t take account of the system environment

Incorrect analysis of requirements Poor skills or not enough time allowed

Project undertaken for wrong reason Technology pull or political push

Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 34-36

Why things go wrong?8

Productivity problems Users change their minds (requirements

drift) External events

E.g. introduction of the Euro Implementation not feasible

May not be known at start of the project Poor project management

Inexperienced management or political difficulties

Source: Bennett, McRobb, and Farmer, Object-Oriented Systems Analysis and Design (McGraw Hill, 2002), p. 36-38

Complexity9

Ultimately, in sum, software projects fail due to the inherent complexity of building software. Physician, civil engineer and computer

scientist joke.

Source: Grady Booth, Object-Oriented Analysis and Design (Addison Wesley, 1994), p. 3-8Source: Xiaoping Jia, Object-Oriented Software Development using Java (Addison Wesley, 2003), p. 3

Complexity10

That is, large software projects are inherently complex due to: Complexity of problem domain

Often contradictory requirements (usability vs performance, cost vs reliability) as well as requirements that change over time.

Difficulty of managing the developmental process Longevity and evolution of software systems High user expectations The flexibility possible through software The problems of characterizing behavior in discrete

systems. That is, making changes in one thing will often effect other

things, and due to the sheer number of “things” in a software system. Exhaustive testing is impossible.

Object-oriented techniques seem to be better at managing this complexity than does structured approaches.

Source: Grady Booth, Object-Oriented Analysis and Design (Addison Wesley, 1994), p. 3-8Source: Xiaoping Jia, Object-Oriented Software Development using Java (Addison Wesley, 2003), p. 3

Cost of Complexity

Doc

Design

Test

Code

Other

Revise & Maintain

11

Source: Source: DP Budget, Vol. 7, No. 12, Dec. 1988FromCraig Larman, Software Economics presentation

System development plans must be based on the complete cost of a system, not solely on development costs.

But why is this so large?

Why is Maintenance so Expensive?

12

AT&T study indicates that business rules (i.e., user requirements) change at the rate of 8% per month ! Another study found that 40% of requirements arrived

after development was well under way [Casper Jones] Thus the key software development goal

should be to reduce the time and cost of revising, adapting and maintaining software.

Object technology is especially good at Reducing the time to adapt an existing system (quicker

reaction to changes in the business environment). Reducing the effort, complexity, and cost of change.

FromCraig Larman, Software Economics presentation

Benefits of Object Orientation (OO)

13

Some potential benefits are: Reusability

Once an object is defined, implemented, and tested, it can be reused in other systems.

Reliability Object-oriented code lends itself to verfication via unit

testing. Robustness

Most object-oriented languages support exception and error handling.

Extensibility Objects can inherit from other objects, thus lessening the

need to constantly “reinvent the wheel.” Easier to manage

Each object is relatively small, self-contained, and manageable, thus reducing complexity and leading to higher quality systems that are easier to maintain.

Source: Scott Ambler, The Object Primer (Cambridge University Press, 2001), p. 10-20Source: Meiler Page-Jones, Fundamentals of Object-Oriented Design in UML(Addison-Wesley, 2000), p.64-72

Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 9

Manageability

Reu

sab

ility

Relia

bility

Rob

ustn

ess

Exte

nsib

ility

History of the Object Approach

14

Smalltalk, developed by Xerox PARC in the late seventies, was the first commercial object-oriented language.

In the late eighties, several existing programming languages (C++, Pascal) were extended to include object-orientation.

In the mid-nineties other object-oriented languages were developed.

Java, developed by Sun Microsystems, became popular because of its object-orientation (as well as its ability to run on any operating system).

Microsoft's new .NET Framework now has fully object-oriented languages (C#, C++.NET, and VB.NET).

Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 8

More History of the Object Approach

15

As languages developed, object-orientation evolved in the 1990s from a programming methodology to a software development methodology that addresses the analysis, design, implementation, testing, and maintenance of software systems.

Modeling techniques and notations have been developed and unified in the form of the Unified Modeling Language (UML).

Source: Xiaoping Jia, Object-Oriented Software Development using Java (Addison Wesley, 2003), p. 11

Object-OrientedProgramming Methodology

Object-OrientedSoftware Development

Methodologyevolves into

Unified Modeling Language

developed as part of