CSC 335: ObjectOriented Programming and Design

1
CSC 335 Object-Oriented Programming and Design

• 27/Aug/02
• Syllabus
• Introduce Section Leaders
• Introduce JBuilder
• Object-Oriented Technology A Brief Historical
  Perspective

2
About this course

• Read Syllabus
• Check out the web page
• There are only two required books
• I'll ask you to read most chapters (days)
• I will enhance this material from many textbooks
  that should be of interest
• See recommended reading list on next slide

3
A few sources of lecture enhancements during this
semester

• Computing Fundamentals with Java, Rick Mercer
• 127A book plus GUIs, events, Exceptions, IO,
  designing an inheritance Hierarchy
• Design Patterns Explained, A New Perspective on
  Object-Oriented Design, Alan Shalloway and James
  Trott
• Abstract view of how design patterns can improve
  software quality
• Refactoring, Improving the Design of Existing
  Code
• Why making small changes to code results in
  better code
• Extreme Programming Explained, William Lake
• Concrete examples of what master programmers
• Object-Oriented Design Heuristics, Arthur Riel
• 60 guidelines to help write OO software
• Designing OO Software, Rebbeca Wirfs-Brock,
  Wilkerson, Wiener
• Responsibility-driven design using CRC cards

4
Reading List continued

• Object-Oriented Technology OOT A Managers
  Guide, Taylor
• Good introduction to object-oriented technology
  for IT managers. Also source for the outline and
  pictures in the remaining slides.

5
335 Section Leaders, Fall 2002
Section Section Leader Location Time 1
Jacob Pitts BIO E 307 800am
2 Shauna Eggers BIO E 307 900am 3H
Joshua Louie PAS 416 1100am 4
Armand Navabi BIO E 307 1200pm 5
Gergely Kota BIO E 307 100pm 6 Tom
Slattery HAURY 219 200pm 8 Cullen Linn
HARV 303 400pm 9 Charlie Chi HARV
303 500pm
6
Break

• 5-minute break
• We're available for questions now.
• If you need to add or switch sections, see Rick
  now

7
Object-Oriented Technology Pictures from OOT A
Managers Guide, David A. Taylor

• 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

8
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 its supposed to?
• The software is not flexible enough to handle
  rapid changes

9
How Software is Constructed

• Wanted
• robust large-scale applications that evolve with
  the corporation
• It isnt 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

10
Modular Programming

• Subroutine (1950s)
• Provided a natural division of labor
• Could be reused in other programs
• Structured Programming and Design (1960s)
• SPD 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

11
SPD Used Functional Decomposition
main
readData
saveData
mainMenu
deleteRecord
addRecord
editRecord
12
A Problem with SPD

• Structured programming has a serious limitation
• Its rarely possible to anticipate the design of
  a completed system before its implemented
• The larger the system, the more restructuring
  takes place

13
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

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

15
Information (Data) Hiding

• An improvement
• Give each subroutine its 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.

16
Modularized Data

• Localize data inside the modules
• This makes modules more independent of one
  another.
• Local Data

17
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

18
External Data

• A program that accesses data stored outside of
  the program
• Data stored within external files

19
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

20
The Relational DBMS Model

• Data in a relational data base are stored in
  simple 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
• OO Systems still talk to relational data bases

21
The Procedural Approach

• The procedural style of programming builds
  systems one subroutine at a time.
• This approach doesnt work well in large systems
• The result is defective software that is
  difficult to maintain
• There is a better way

22
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

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

24
Whats in the System

• Simula 67 was designed for system simulation (in
  Norway by Kristen Nygaard and Ole-Johan 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 functions and procedures that
  pass data all over the place
• In object-oriented programming, the system is
  modeled as a collection of interacting objects
  where the data is encapsulated with the methods
  that need them

25
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
• We understand an object through
• the values the object stores (state) via
  attributes (instance variables
• the operations that can be applied to that object
  (behavior) Booch 92.

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

27
One instance of a vehicle

• Every object has
• a name
• instance variables stored in computer memory
• methods-a.k.a. procedures, member functions, ...

28
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

29
Example messages

• Smalltalk examples
• sender is the object sending the
  message--sender is not shown here
• vehicle104 moveTobinB7
• myAccount withdraw100.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.

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

31
One Class can Generates Many Objects

• We can create many instances (objects) of the
  same class.
• Every object has
• name (a reference to it)
• state (values)
• methods

32
Inheriting Class Information

• Imagine we need several classes of similar
  automated Vehicles, BankAccount, or Employee
  objects.
• We can derive new classes from existing ones
  through the inheritance mechanism.
• The "top" class is called the superclass (or base
  class in Java).
• The new class in called a subclass (or derived
  class in Java).

33
Inheritance

• The superclass should pull together the common
  characteristics
• The subclasses inherit methods and data
• Derived classes can also add new data and methods
• Derived classes can also override some methods to
  give the method new meaning
• In Java you have overridden these Java methods
• toString
• equals

34
Inheritance Hierarchies

• Classes can be extended to any degree.
• Each new derived class accumulates the data and
  behavior (methods) of it ancestors
• Much human knowledge is structured in this manner
  (insects, parts, lendables in a library)
• We use software models of real world objects
• The base class captures common data and behavior

35
Two Small Class Hierarchies
In UML
Software needed to control these AVs
36
Programming with Objects

• 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
• ATT (Bjarne Stroustrup)
• Added classes to the popular C language
• Hybrid -- both procedural and object-oriented
  (ugly stuff)
• Ada became OO in 95
• Java started in the mid 90s just another C
  extension?
• C makes improvements to Java
• int, double, char are true objects (not something
  different

37
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

38
The OO approach The Good

• More natural -- models the real world, not the
  computer
• More flexible
• More maintainable
• later programmers understand it better
• touch as few self-contained classes as possible
• More reliable can perform unit testing
• Can build reusable modules (classes)
• Extensible
• Easier to add new functionality and offer
  alternatives
• Accomplished through inheritance and polymorphism

39
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 A Ron
  Jeffries quote during the first Birds of a
  Feather on Extreme Programming (OOPSLA 1998)
• Some frameworks have been successful
• MacApp, ET, Interviews, Microsoft's MFC, Java's
  RMI

40
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