Understanding Object Orientation Paradigm

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

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) Randy Connolly

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 Randy Connolly

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 Randy Connolly

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 Randy Connolly

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

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 Randy Connolly

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 Randy Connolly

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 Randy Connolly

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 Randy Connolly

11 Cost of Complexity System development plans must be based on the complete cost of a system, not solely on development costs. Other 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 Randy Connolly

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 Randy Connolly

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. Manageability Extensibility Robustness Reusability Reliability 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 Randy Connolly

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 Randy Connolly

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 Software Development Methodology evolves into 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 Randy Connolly