OO Development 1 - Introduction to Object-Oriented Development

OO Development 1 - Introduction to Object-Oriented Development

• 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 anew 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 gowrong? 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 gowrong? 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 Maintenanceso 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 ObjectOrientation (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 theObject 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 ofthe 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