Title: Introduction to Object Oriented Computing and Modeling
1Introduction to Object Oriented Computing and
Modeling
2Getting Started
- You were supposed to
- Read Chapter 1
- Lets not worry about chapter 2.1 yet
- Read the syllabus
- Any questions?
3Think/Pair/Share
- In order, list the tasks you performed this
morning before you left for campus.
4Programming 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.
5So 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.
6So 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?
7So 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
8An 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)
9The community of agents in the process
10The 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)
11Object-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
12Object-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
13Object-Oriented Programming (continued)
From Modern Software Development Using Java
14Object-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
15Object-Oriented Programming (continued)
From Modern Software Development Using Java
16A 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)
17Object-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
18Object-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
19Finding 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
20Unified 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
21Class 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
22Class Diagrams
ClassName attribute attribut
e DataType attribute DataType default
value operation operation (arg1, arg2, )
ResultType
23Class Diagrams (continued)
Modern Software Development Using Java, 2e
24Class Diagrams (continued)
Modern Software Development Using Java, 2e
25Class 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
26Class 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
27Class 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
28Class Diagrams (continued)
Modern Software Development Using Java, 2e