Course material from my Object-Oriented Development course. This presentation introduces the main themes of the course.

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

2. Paradigms
2
 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)

3. Object-Oriented Paradigm
3
 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
object
data
data
behavior
behavior
object behavior
behavior
data behavior
behavior
Source: Scott Ambler, The Object Primer (Cambridge University Press, 2001), p.2

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

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

6. 6
Software Success?
Used as delivered
Used after
2%
changes
3%
Used but
extensively
reworked or later Delivered but
never
abandoned
19% successfully used
47%
Paid for but not
delivered
29%
Source: US Government Accounting
Office. Report FGMSD-80-4.
From
Craig Larman, Software Economics
presentation

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

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

9. Complexity
9
 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

10. Complexity
10
 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

11. 11
Cost of Complexity
System development plans must be based
on the complete cost of a system, not
Other solely on development costs.
Code
Revise &
Maintain
Test
But why is this so large?
Design
Doc
Source: Source: DP Budget, Vol. 7,
No. 12, Dec. 1988
From
Craig Larman, Software Economics
presentation

12. 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.
From
Craig Larman, Software Economics presentation

13. 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.”
Manageability  Easier to manage
 Each object is relatively small, self-contained, and manageable, thus reducing
Extensibility
Robustness
Reusability
Reliability
complexity and leading to higher quality systems that are easier to maintain.
Source: Satzinger and Orvik, The Object-Oriented Approach (Course Technology, 2001), p. 9
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

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

15. 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).
Object-Oriented
evolves into Software Development
Methodology
Object-Oriented
Programming Methodology
developed
as part of
Unified Modeling Language
Source: Xiaoping Jia, Object-Oriented Software Development using Java (Addison Wesley, 2003), p. 11