1. 1 CSC 335: Object-Oriented Programming and Design Object-Oriented Technology: A Brief Historical Perspective Rick Mercer Pictures from OOT: A Manager’s Guide, David A. Taylor

2. 1-2 Object-Oriented Technology:  Outline  Consider a few ways in which data is protected from careless modification  Mention the key features object-oriented style of software development  Consider why object-oriented technology is important

3. 1-3 Chapter 1: Beating the Software Crisis  Corporations continue to become more dependent on information  Their ability to manage data decreases.  The problem is the software, not the hardware  The Software crisis  How often is software delivered on time, under budget, and does what it’s supposed to?  The software is not flexible enough to handle rapid changes

4. 1-4 How Software is Constructed  Wanted:  robust large-scale applications that evolve with the corporation  It isn’t easy!  Modular Programming (the past 40 years)  Break large-scale problems into smaller components that are constructed independently  Programs were viewed as a collection of procedures, each containing a sequence of instructions

5. 1-5 Modular Programming  Subroutine (1950s)  Provided a natural division of labor  Could be reused in other programs  Structured Programming and Design (1960s)  It was considered a good idea to program with a limited set of control structures (no go to statements, single returns from functions)  sequence, selection, repetition, recursion  Program design was at the level of subroutines  functional decomposition

6. 1-6 Functional Decomposition main readData mainMenu saveData addRecord deleteRecord editRecord

7. 1-7 A Problem with Structured Design  Structured programming has a serious limitation:  It’s rarely possible to anticipate the design of a completed system before it’s implemented  The larger the system, the more restructuring takes place

8. 1-8 And What About the Data?  Software development had focused on the modularization of code,  the data was either moved around between functions via argument/parameter associations  or the data was global  works okay for smaller programs or for big programs when there aren't to many global variables  Not good when variables number in the hundreds

9. 1-9 Don’t use Global Variables  Sharing data (global variables) is a violation of modular programming  This makes all modules dependent on one another  this is dangerous  Global Data

10. 1-10 Information (Data) Hiding  An improvement:  Give each subroutine it’s own local data  This data can only be “touched” by that single subroutine  Subroutines can be designed, implemented, and maintained independently  Other necessary data is passed amongst the procedures via argument/parameter associations.

11. 1-11 Modularized Data  Localize data inside the modules  This makes modules more independent of one another.  Local Data

12. 1-12 Data Outside of Programs  Small programs require little input and output  Large programs work with the same data over and over again  Inventory control systems  accounting systems  engineering design tools  Store data in external files

13. 1-13 External Data  A program that accesses data stored outside of the program  Data stored on an external file

14. 1-14 Sharing Data  Many people must access the same data stored on file  This requires a data base management system (DBMS) Data protected by a DBMS

15. 1-15 The Relational DBMS Model  Relational data bases store data in tables  Each table can have primary and secondary keys  For example, there is one table with complete information on all customers.  Each of these records has a primary key called custID. MillerR 123 W. Palm, Civino, CA MillerT 987 E. Orange, New York, NY  Another table stores all orders.  Each record stores all order information with a secondary key named customer ID. Icees 6/8/01 MillerR 5 6.00 30.00 1.80 31.80  Then you only need to store customer data once

16. 1-16 The Procedural Approach  The procedural style of programming builds systems one subroutine at a time.  This approach doesn’t work well in large systems  The result is defective software that is difficult to maintain  There is a better way

17. 1-17 Object-Oriented Style of Design and Programming  Three Keys to Object-Oriented Technology  Objects  Messages  Classes  Translation for structured programmers  Variables  Function Calls  Data Types

18. 1-18 Introducing objects  OOT began with Simula 67  developed in Norway  acronym for simulation language  Why this “new” language?  to build accurate models of complex working systems  The modularization occurs at the physical object level (not at a procedural level)

19. 1-19 What’s in the System  Simula 67 was designed for system simulation (in Norway by Nygaard and Dahl)  Caller and called subprogram had equal relationship  First notion of objects including class/instance distinctions  Ability to put code inside an instance to be executed  The class concept was first used here  In procedural programming, systems are modeled as a collection of procedures.  In object-oriented programming, the system is modeled as a collection of interacting objects.

20. 1-20 Inside Objects  An object is:  a software “package” that contains a collection of related methods and data  an entity stored in computer memory  an excellent software module  an instance of a class  a bunch of bits in memory or on the wire  We understand an object through:  the values the object stores (state) via attributes the  operations that can be applied to that object (behavior) [Booch 92].

21. 1-21 Modeling an Automated Vehicle  Consider how we would mode an automated guided vehicle (AGV):  Behaviors:  move from one location to another  loading and unloading contents  Must maintain information about  its inherent characteristic: pallet size, lifting capacity, maximum speed,...  its current state: contents, location, velocity,...

22. 1-22 One instance of a vehicle  Every object has:  a name  instance variables stored in computer memory  methods-a.k.a. procedures, member functions,...

23. 1-23 Introducing messages  Real-world objects exhibit many effects on each other.  These interactions are represented in software as messages (a.ka. method or function calls).  A message has these three things:  sender: the initiator of the message  receiver: the recipient of the message  arguments: data required by the receiver

24. 1-24 Example messages  Smalltalk examples sender is the object sending the message--sender is not shown here vehicle104 moveTo:binB7 myAccount withdraw:100.00  Java examples vehicle104.moveTo( binB7 ); myAccount.withdraw( 100.00 );  An object-oriented program consists of objects interacting with other objects by sending messages to one another

25. 1-25 Introducing Classes  We often need many of the same objects within a program--many numbers, Strings, BankAccounts, Employees, InventoryItems,...  We need an efficient way to redefine the same thing many times  The class mechanism provides a template to define the methods and instance variables of objects.  Each object (or instance) of a class has its own state--the set of values for that instance.

26. 1-26 One Class can Generate Many Objects  We can create many instances (objects) of the same class.  Every object has  name (a reference to it)  state (values)  methods

27. 1-27 Important OO languages  Simula started it all  Smalltalk was released in early 80s  Xerox Palo Alto Research Center PARC Place  Alan Kay, Adele Goldberg  It is Pure  C++ started in the mid 80s  AT&T (Bjarne Stroustrup)  Added classes to the popular C language  Hybrid -- both procedural and object-oriented  Ada became OO in 95  Java started in the mid 90s just another C extension?

28. 1-28 The OOT mindset  Traditionally, software was developed to satisfy a specific requirements specification.  A billing system could not be made into something else even if were similar.  Let the billing system handle mailings or ticklers  OOT has a different mindset  Instead of beginning with the tasks to be performed, OO design deals with the aspects of the real world that need to modeled in order to perform the tasks

29. 1-29 The OO approach  The OO approach is:  more flexible  more understandable -- it models the real world  more maintainable--later programmers understand it better  Basic corporate operations change more slowly than the information needs--software based on corporate models have a longer life span

30. 1-30 A Wish for Reuse  Traditional software started from scratch  easier than converting old code--specific task  OOT stresses reuse  objects are the building blocks  majority of time spent assembling proven components: ex. Graphical User Interface (GUI):  Borland's OWL, MS's MFC, or Java Swing  But reuse is hard to obtain!  I used to predict what we might need in the future I was right 10% of the time Ron Jeffries, an eXtreme Programmer (XP)

31. 1-31 The Promise of the Approach  OOT offers  techniques for creating flexible, natural software modules.  systems that are much easier to adapt to new demands  reuse shortens the development life cycle  systems are more understandable and maintainable  easier to remember 50 real world classes rather than 500 functions

32. 1-32 For Next Class  Depending on your Java background, skim and/or read Chapters 3 and 4 from Core Java Volume I  reviews 127A and 217BB or C Sc 227  Have your lab access cards  Go to 737 Gould-Simpson today or tomorrow and apply for your accounts  can telnet from home: user apply password apply  you don't get new card until you sign paperwork