What is an object?

1
What is an object?

• How do you find them?
• OO Design Methods

2
Language definition

• Encapsulates state and behavior
• Responds to messages
• Has identity
• Inheritance
• ??

3
Modeling definition

• Instance of a class
• Has behavior
• Has attributes (properties)
• Has relationships with other objects
• 1-1 relationship
• 1-n relationship
• n-m relationship

4
Philisophical definition

• Object is what you think is important
• Traffic engineer road, intersection, underpass,
  turning lane, right of way
• Airline airplane, flight, ticket, reservation,
  pilot, work schedule
• CFO bonds, debt, ROI,

5
Nouns and objects

• Find objects in a system by looking at English
  description of the system.
• Underline nouns
• Throw out duplicates, irrelevant, not part of
  implementation
• Works when people have already figured out what
  is important and named them.

6
Method
Method A systematic way of doing something.

• Concepts
• Notations
• Process
• Heuristics
• (a book)

7
Responsibility Driven Design

• Concepts
• Class
• Responsibility
• Collaboration
• Inheritance
• Subsystem
• Contracts

Book Object-Oriented Design by Wirfs-Brock,
Wilkerson and Wiener
8
Unified Modeling Language (UML)
Books by Booch, Rumbaugh, Jacobson UML
concepts and notation Unified Process UML a
process

• Concepts
• Objects
• Classes
• Associations / Cardinality
• Attributes
• Inheritance

9
Objects, Associations, and Attributes
JohnPerson 27 age address
parent
child
MaryPerson
owner
pet
employee
Bob Dog
employer
AnnPerson
10
Classes, Associations, Attributes and
Generalization
owner
pet
employer
0..1
0..1

Person name age address
Animal

employee
parent
0..2

child
Dog
zero or more 0..1 zero or one
11
Operations
owner
pet
employer

Person name age address buy feed chase
Animal price eat

employee
parent

child
Dog run bark
12
UML

• graphical OO modeling notation with many parts
• Class diagrams
• Interaction diagrams
• Use case diagrams and use cases
• Packages
• State diagram
• Activity diagrams, deployment diagrams, component
  diagrams

13
What is an OO Model?

• A OO model is a model expressed in terms of
  objects, classes, and the relationships between
  them.
• Models can be written in programming languages,
  graphics, or English.

14
Analysis and Design

• Analysis
• Process Understanding the problem
• Result Specification of the system
• Design
• Process Understanding the solution
• Result Plan for building the system

15
Design vs. Analysis

• Use of objects integrates design and analysis.
• advantages - easier to move from one to the
  other
• disadvantages - harder to tell which you are
  doing

16
Analysis vs. Design

• Analysis produces documents that customer can
  understand.
• Programmers need class diagrams
• Customers like use cases, not class diagrams
• Design produces documents that programmers can
  understand.

17
Design

• Design must be implementable.
• Include detail not needed in analysis model.
• Doesn't include objects outside computer.
• Design model is derived from analysis model, but
  is not produced by just adding and removing
  elements.

18
Finding Classes

• Model the real world.
• Nouns are classes, verbs are operations on
  classes.
• A class should capture one key abstraction.

19
To Be or Not To Be --- A Class

• Analysis model shouldn't contain
  implementation-specific objects like queues and
  lists.
• Classes should be
• unique
• relevant
• specific

20
To Be or Not To Be --- A Class

• Operations should not be objects unless you need
  to manipulate them.
• A Call in a telephone billing system has
  attributes such as date and destination phone
  number, and must be stored so it can be printed
  on the monthly bill.

21
To Be or Not To Be --- A Class

• The name of a class should represent its
  intrinsic nature and not a role that it plays in
  an association.
• A person can have many roles when associated
  with a car owner, passenger, driver, lesee.

22
RUP Process

• Find use-cases
• Describe each use case in detail
• Make analysis model, a class diagram that
  supports each use case. Also can include
  interaction diagrams and collaboration diagrams.
• Make design model, a very detailed model that
  shows how the system will be implemented.
  Similar to analysis model, but more layers, more
  dynamics

23
RDD Process

• Brainstorm object model
• Start simply
• Concrete scenarios
• Scenarios create class/resp./collaborations
• Turn objections into scenarios
• Stop when you are out of scenarios
• Review the object list
• Reorganize (inheritance, subsystems)

24
Heuristics

• Eliminate cycles of dependencies between classes.
• Hide implementation details.
• Distribute responsibility dont make one object
  control all the others.

25
Heuristics

• Minimize the number of methods in a class.
• Minimize the number of classes which which
  another class collaborates.
• Minimize the amount of collaboration between a
  class and its collaborator.

26
XP Process

• Customer makes list of user stories
• Developers estimate their cost
• Customer picks a set to be done in the next
  iteration
• Each day during iteration
• Developers work on a story
• Write tests
• Write code to make tests work
• Refactor to make good design

27
Domain-driven Design

• (book by Eric Evans)
• Part of the system is a domain model
• Customers and developers share ubiquitous
  language, which is expressed in domain model
• You understand the problem best on the last day
  of the project, which is why the domain model
  keeps changing

28
Patterns

• People dont design from first principles.
• People design by reusing ideas they have seen
  before
• From previous projects
• From books, courses, etc

29
What Really is an Object?

• Relationship can be an object if it has
  attributes and relationships
• Marriage has duration and children
• Intersection has accidents
• Attribute can be an object if it has attributes
• Temperature is taken at a point in time

30
What Really is an Object?

• Reservation -- a promise to give service to a
  customer
• Ticket -- record the event of the customer paying
  for service in advance,
• Flight -- an event in which an airplane provides
  service
• Payment -- an event (transaction?) in which money
  is exchanged

31

• Attributes are simpler than objects.
• Associations are simpler than objects.
• Models should be as simple as possible, but no
  simpler.

32
Why this is important

• Many of the objects in a good design are NOT
  problem domain objects.
• Example ValueWithHistory
• They can represent operations, processes, states,
  constraints, relationships, ...

33
Design for Reuse

• Purpose is to make a system flexible, extensible,
  and easily changed.
• Make things objects if they need to be changed
  and manipulated.

34
Design for Reuse

• Goal is to build an application just by using
  preexisting objects.
• Compose, don't program.
• Relationship between objects as important as
  class hierarchy.