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

Paradigms 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-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 Paradigm 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

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).

Object vs Functional-Oriented Source: Craig Larman, Applying UML and Patterns (Prentice Hall, 1998), p. 14 Library Information System Librarian Catalog Book Library System Record Loans Add Resources Report Fines Structured Approach Decompose by functions or processes Object Approach Decompose by objects or concepts

Why was a new paradigm needed? 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

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 .

Software Success? Source: US Government Accounting Office. Report FGMSD-80-4. From Craig Larman, Software Economics presentation

Why things go wrong? 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

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

Why things go wrong? 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

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

Complexity 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-8 Source: Xiaoping Jia, Object-Oriented Software Development using Java (Addison Wesley, 2003), p. 3

Ultimately, in sum, software projects fail due to the inherent complexity of building software.

Physician, civil engineer and computer scientist joke.

Complexity 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-8 Source: Xiaoping Jia, Object-Oriented Software Development using Java (Addison Wesley, 2003), p. 3

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.

Cost of Complexity Source: Source: DP Budget, Vol. 7, No. 12, Dec. 1988 From Craig 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? 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. From Craig Larman, Software Economics presentation

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.

Benefits of Object Orientation (OO) 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-20 Source: 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 Reusability Reliability Robustness Extensibility

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.

History of the Object Approach 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

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).

More History of the Object Approach 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-Oriented Programming Methodology Object-Oriented Software Development Methodology evolves into Unified Modeling Language developed as part of

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).