Introduction to Object Oriented Computing and Modeling

1
Introduction to Object Oriented Computing and
Modeling
2
Getting Started

• You were supposed to
• Read Chapter 1
• Lets not worry about chapter 2.1 yet
• Read the syllabus
• Any questions?

3
Think/Pair/Share

• In order, list the tasks you performed this
  morning before you left for campus.

4
Programming is a lot like planning out your
morning

• Some things are required, others are optional.
• Certain things must be in the right order while
  other things can be done in any order.
• Certain tasks are MUCH more involved, but we
  think about them from high view simple terms.
• Some tasks you assign to other objects.

5
So what is OO programming?

• The world
• consists of objects
• that interact
• to solve a problem.
• Object-oriented programming encourages us to
  think about the computer as a simulator of the
  world. Thus, a program is a map of the world we
  want to imitate.

6
So what is OO programming?

• Instead of asking
• How can I write a program that is structured like
  the machine on which it runs?
• We ask
• How can I write a program that is structured like
  the part of the world it describes?

7
So what is OO programming?

• We describe and understand the world around us
  by
• Identifying objects in our world
• Understanding what the objects can do
• Interacting with objects to accomplish a task
• Encapsulation
• Information confined or hidden inside an object
• Interact with objects via external properties

8
An example

• Suppose an individual named Chris wishes to send
  flowers to a friend named Robin, who lives in
  another city.
• Chris walks to a nearby flower shop, run by a
  florist named Fred.
• Chris tells Fred what kinds of flowers to send to
  Robin and the address to which they should be
  delivered.
• Chris can be assured that the flowers will be
  delivered expediently and automatically (from his
  perspective)

9
The community of agents in the process
10
The anatomy of an OO program

• The root of object oriented programming is
  objects
• An object is an entity that has
• State
• Behavior, and
• Identity
• (Grady Booch)

11
Object-Oriented Programming

• State information the object needs to remember
• Property a characteristic, quality, or feature
  that contributes to making an object unique
• Current values of properties

From Modern Software Development Using Java
12
Object-Oriented Programming

• Behavior objects reaction to state changes,
  interactions with other objects
• Methods model object behavior
• Methods are invoked

From Modern Software Development Using Java
13
Object-Oriented Programming (continued)
From Modern Software Development Using Java
14
Object-Oriented Programming (continued)

• Identity way to distinguish objects
• Reference variables identify objects
• Refer to one object at a time
• Equality are two objects equal?
• Name equivalent refer to the same object
• Compare memory addresses
• Content equivalent from the same class
• Understand the structure of objects

From Modern Software Development Using Java
15
Object-Oriented Programming (continued)
From Modern Software Development Using Java
16
A beginners process

• Begin with analysis
• What are the objects in my program?
• In order to identify similar objects, what do
  they need to know (state)?
• What actions should each object be able to take?
  (behavior)
• What messages should each object be able to
  respond to? (behavior)

17
Object-Oriented Design

• Requirements phase of software life cycle
• User needs identified and documented
• Requirements document describes behavior of
  proposed software from users perspective
• Focus on what to do, not how to do it
• Specification phase
• Define explicit behavior of program
• Specification document identifies specific
  outputs for all possible inputs
• Specific system requirements documented

18
Object-Oriented Design (continued)

• Design phase
• Requirements and specification documents
• Identifies and defines classes, behaviors of each
  class, and interactions
• Implementation phase
• Code written
• Design document is a guideline
• Design phase is one of the most difficult
• Design allows programmers to develop software
  that is efficient, easy to build and maintain

19
Finding Classes

• Primary goals of design phase
• Identify classes
• Determine relationships between classes
• Decisions require talent and experience
• Majority of classes identified in requirements
  and specification documents
• Nouns in requirements document provide list of
  potential classes
• List must be refined

20
Unified Modeling Language (UML)

• Software design must be clearly, concisely,
  correctly described to programmers
• Unified Modeling Language (UML) a graphical
  language
• Visually expresses software system design
• Represents a design in standard format
• UML provides five views, nine diagram types
• View diagrams that highlight a system aspect
• UML has no rigid rules for what is included

21
Class Diagrams

• Describe static structure of a system in terms of
  classes and their relationships
• Class drawn as a rectangle divided into three
  compartments
• Class names appear in bold text, centered at the
  top of the rectangle
• Compartments describing state and behavior are
  optional
• Method type information also optional
• Names of routines that take parameters must be
  followed by parentheses

22
Class Diagrams
ClassName attribute attribut
e DataType attribute DataType default
value operation operation (arg1, arg2, )
ResultType
23
Class Diagrams (continued)
Modern Software Development Using Java, 2e
24
Class Diagrams (continued)
Modern Software Development Using Java, 2e
25
Class Diagrams (continued)

• Specify parameter and return types with colon
  notation
• Include only as much information as necessary
• Most class diagrams do not include accessors or
  mutators
• Also omit void return values
• Relationship between classes defined
• One instance invokes a method or accesses the
  state of an instance of another

26
Class Diagrams (continued)

• UML defines relationships that describe how
  classes are related in a class diagram
• Association
• State of one class contains a reference to an
  instance of another class
• Permanent structural relationship
• Solid line drawn between two classes to represent
  association
• Not always bidirectional
• Navigability arrow indicates direction of a
  relationship

27
Class Diagrams (continued)

• Multiplicity several instances of a class
• Denoted with an asterisk and a number
• Number indicates the number of class instances
• Dependency change in one class affects another
  class that uses it
• Inherently one-way relationship
• Association usually implemented as part of the
  class state
• Dependency usually implemented as local variable,
  parameter, return value
• Called automatic variables

28
Class Diagrams (continued)
Modern Software Development Using Java, 2e