Chapter 5 Objects and Classes

1
Chapter 5 Objects and Classes
2
Chapter 5 Objects and Classes

• ??5.1. Real-World vs Data-World Objects
• ??5.2. Classes and Classification
• ??5.3. Transient and Persistent Objects
• ??5.4. Objects Classes or Instances?
• ??5.5. Associations

3
??5.1. Real-World vs Data-World ObjectsHere is
what its all about

• We Analysts must understand and document the real
  world where our users live.
• We then create a product in the computer world,
• To help the users do their job in the real world.
• Effective analysts must ensure the computer-world
  product accurately mirrors the users real-world
  needs.

4
??5.1. Real-World vs Data-World Objects

• What An Object Is
• In the Real World
• In the Data World
• Jacobsons Three Types
• Entity Objects
• Concrete objects
• Conceptual objects
• Event and State objects
• Interface Objects
• Control Objects

• Attributes
• Behavior
• Identity
• Encapsulation
• Object States

Now lets look at these in detail. . .
5
The World is full of THINGS
6
THINGS

• An object is some Thing in the world of the user
• Car, Train, Elephant, Sale, Invoice, Division,
  Account, etc.
• Physical or Conceptual
• It has Attributes that describe it
• Make, Model, Year,
• Color, Weight,
• Serial Number, License Number
• It has Relationships to other objects
• e.g., to a Person object, i.e., the Owner.
• It has Behavior that it can do
• Create
• Change Color
• Change Owner
• Destroy Itself (Suicide?)

Entity
Object
7
in the DATA WORLD

• We have some kind of record in the computer for
  each real-world object
• It carries data for the attributes
• Make, Model, Year, Color, Weight, Serial Number,
  License Number
• The set of attribute values represents the STATE
  of the object
• It carries a link of some kind for each
  relationship
• Foreign Key or pointer
• It carries program code for each behavior
• Create, Change Owner, Change Color, Delete
• CRUD Create, Read, Update, Delete.

Entity
Object
8
??5.1. Real-World vs Data-World ObjectsWe Define

• A Data Object is an abstraction of some thing in
  the real world, that
• carries both the data describing the real-world
  object , and the
• operations (i.e., program code) that have the
• only allowable access
• to that data.

9
??5.1. Real-World vs Data-World
ObjectsJacobsons Three TypesIn the interests
of stability and flexibility to change, Jacobson
classifies objects into three types

• Entity Objects
• Interface Objects
• Control Objects

Lets look at these in detail. . .
10
??5.1. Real-World vs Data-World
ObjectsJacobsons Three Types

• Definition
• Entity Objects are the fundamental objects and
  classes that we discover in Analysis by scanning
  the users business.

11
??5.1. Real-World vs Data-World
ObjectsJacobsons Three TypesThere are three
kinds of Entity Objects

• Concrete objects
• Conceptual objects
• Event and State objects. . .

12
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types.Concrete Objects

• Solid, tangible and physical.
• Things you can grab hold of.
• People, animals and other beings
• Land, buildings, equipment, vehicles
• Goods, products, tools, appliances, materials
• These are easily understood by both analysts and
  users.

13
??5.1. Real-World vs Data-World ObjectsConcrete
Entity Objects
Beings
Land Buildings
Equipment
Goods

• Person Apartment Elevator Food
• Employee Warehouse Forklift Product
• Customer House Car Clothes
• Student College Cell phone Pen
• Citizen Street Truck Gravel
• Engineer Office Lathe Steel
• Animal Farm Tractor Beer
• Doctor Hospital Scalpel Blood
• Librarian Library Computer Book
• Cop Station Gun Bullets

14
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types .Conceptual
Objects

• Intangible, nonphysical
• More difficult for users to grasp,
• But they are still things and objects
• Typically defined in terms of other object
  classes . . .
• e.g., by breaking out a MM relationship
• See Chapter 9.

15
??5.1. Real-World vs Data-World
ObjectsConceptual Entity Objects
Organizations
Abstractions
Agreements

• Corporation Strategy Lease
• Church Plan Mortgage
• Regiment Map Ceasefire
• Sports club Schedule Membership
• Government dept Proposal Approval
• Professional assn Qualification Charter
• Union Bylaws Contract

16
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Conceptual
Objects

• These are conceptual in the sense that a contract
  does not consist of a piece of paper.
• Rather, it is an agreement that comes into
  existence,
• The moment the two parties agree, verbally or
  otherwise.
• Signing the piece of paper documents the
  existence of the contract, to make it easier to
  enforce (e.g. in court).

17
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Event and State
Objects

• Also very abstract in nature.
• When an Event occurs, some object will change its
  State.
• When a business event occurs,
• it is documented, and that is a fact we must
  record i.e., it is Data.

18
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types State Objects

• A state is a condition or situation.
• At any time an object exists in a certain state.
• Sometimes the state is more important to our
  project than the object, in which case, for us,
• the state itself is a thing, and an object.

19
??5.1. Real-World vs Data-World ObjectsEvent and
State Entity Objects
Events
States

• Purchase Deposit Ownership Enrolment
• Delivery Loan Suspense Assignment
• Negotiation Return Birth Termination
• Arrival Hire Status Immigrant
• Departure Rental Licence Registration
• Transaction Sale In Transit Employment

20
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects

• Most software systems need to exchange data with
  other systems.

21
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects

• These might be
• Other information systems, such as
• Human Resources, Accounting, etc., etc.
• A real-world system controlled by our software
• Industrial processes, refineries, etc.
• Machinery, robots, assembly lines, etc.
• Monitoring systems
• Security systems, Intensive Care Units, etc.

22
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects

• These days, they might also be
• Communications Interfaces
• Point-to-Point
• Modem and phone line
• Fax and Fax-back
• LAN, WAN, etc.
• Internet and/or Intranet
• Peripheral devices e.g. printers, scanners, sound
  and video Input/Output.
• Graphical User Interfaces (GUIs)

23
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects

• Suppose you developed a system that needed to
  communicate over modem lines.
• For simplicity, during testing you might just
  plug two serial ports together from one machine
  to another.
• When the software is deployed, we find things
  have changed - it must communicate over a LAN.
• And then what if the needs grew and the users
  wanted it to work across the Internet?
• Well, . .

24
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects

• To handle this, we would hide all the processing
  to do with the communication link within an
  object.
• When the changes happen, we rewrite some of the
  methods within this class,
• And add an attribute or two.
• Nothing outside this class needs to be touched!!

25
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects, Advantages

• The complexity of the interface is hidden within
  the interface object.
• All the interface processing is hidden,
• And can be changed to handle changes such as the
  communications medium . . . . Without upsetting
  the rest of the system

26
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects, Advantages

• This is an example of
• Encapsulation,
• or Information Hiding,
• which we explore later in this chapter.

27
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Interface
Objects, Advantages

• One reason this form of encapsulation is so
  important is that
• The interfaces to other systems are the least
  stable aspect of any information system. . .

Other Interfaces
Outputs
User Interface
Object Behavior
Object Attributes
Object Classes
28
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Control Objects

• Sometimes we find a method (subroutine, function)
  that uses data, and calls other methods, from
  many different objects and classes.
• These methods dont easily fit or dont logically
  belong
• in any of our entity classes or interface
  classes.

29
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Control Objects

• So we create a class just to have somewhere to
  put this method
• This we call a
• Control Class.

30
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Control Objects

• Sometimes this control class will have just this
  one method.
• Nothing else, no attributes, no nothing!
• Other times it will need a few attributes for
  intermediate results, etc.
• And perhaps a few other methods.

31
??5.1. Real-World vs Data-World
Objects Jacobsons Three Types Control Objects

• Definition
• Control Objects are created during Analysis or
  Design to give us somewhere to put behavior that
  doesnt easily fit into existing interface or
  entity objects.

32
??5.1. Real-World vs Data-World ObjectsWeve
looked at these, Now lets look at these
in detail. . .

• What An Object Is
• In the Real World
• In the Data World
• Jacobsons Three Types
• Entity Objects
• Concrete objects
• Conceptual objects
• Event and State objects
• Interface Objects
• Control Objects
• Summary

• Attributes
• Behavior
• Identity
• Encapsulation
• Violating Encapsulation
• Object States

33
??5.1. Real-World vs Data-World Objects
Attributes
34
??5.1. Real-World vs Data-World
Objects Attributes In the real world

• A child concludes there are objects out there
• And notices some properties they have
• e.g., Color, softness, taste, warmth, etc.
• The child is gathering data about these objects
• We will call each such data item an Attribute
• These Attributes fit our earlier definition.
• Thus, we build a mental model in our heads

35
??5.1. Real-World vs Data-World
Objects Attributes In the data world

• Each object instance carries a set of attribute
  values
• These represent the data items that a user might
  need to know
• about the object at any time
• Data types and sizes are defined for the class
• And apply to every instance.
• The domain of an attribute is its set of all
  permissible values.

36
??5.1. Real-World vs Data-World Objects
Behavior
37
??5.1. Real-World vs Data-World Objects
Behavior In the real world

• A child makes two observations about the objects
  surrounding her
• They have attributes, and
• They DO things.
• And she learns to influence that behavior by
  sending them messages

38
??5.1. Real-World vs Data-World Objects
Behavior In the real world

• An object (a parent) responds to the childs
  message
• by performing the behavior that goes with that
  message
• And in the process performs some service that the
  child needed.
• This view of the behavior as a service is
  important in Responsibility-Driven Design which
  we will examine in later chapters.

39
??5.1. Real-World vs Data-World Objects
Behavior In the real world

• Throughout life we use this method to manipulate
  objects around us
• We issue commands to people, computers, cars,
  graphic objects, and all kinds of things,
• Sometimes we get the results we desire.
• Everyone, including your users, manipulates their
  world with this send-a-message-get-a-service
  approach to life.

40
??5.1. Real-World vs Data-World Objects
Behavior In the data world, there are three
types of behavior that may concern us

• Overt behavior
• Passive behavior
• Responsive behavior
• Now lets look at these in detail. . .

41
??5.1. Real-World vs Data-World Objects
Behavior In the real world Overt Behavior

• Where we actually instruct the object to do
  something
• Graphic object, display thyself
• Heating valve, open yourself
• Window, minimize yourself
• etc. . .

42
??5.1. Real-World vs Data-World Objects
Behavior In the real world Passive Behavior

• This is really just record-keeping
• The recording of the data generated by some
  action or event in the real world.
• Here we do not make something happen
• but merely record what happened
• Purchase Order, change your status.
• Customer, change your address
• etc. . .

43
??5.1. Real-World vs Data-World Objects
Behavior In the real world Responsive
Behavior

• The providing of information (i.e., attribute
  values)
• in response to a message requesting them.
• Here is a customer number, give me the name and
  address
• How many sales exist for this customer?
• etc. . .

44
??5.1. Real-World vs Data-World ObjectsWeve
looked at these, and these,

• What An Object Is
• In the Real World
• In the Data World
• Jacobsons Three Types
• Entity Objects
• Concrete objects
• Conceptual objects
• Event and State objects
• Interface Objects
• Control Objects
• Summary

• Attributes
• Behavior
• Now lets look at these in detail. .
• Identity
• Encapsulation
• Violating Encapsulation
• Object States

45
??5.1. Real-World vs Data-World Objects
Identity
46
??5.1. Real-World vs Data-World Objects
Identity In the real world

• Identity is inherent in an object.
• Oxford inherent - Involved in the essential
  character of something.
• Inherent means that an object has identity just
  because it is that object.

47
??5.1. Real-World vs Data-World Objects
Identity In the real world

• A child has identity from the moment of birth, or
  perhaps before.
• It doesnt get a name until after its birth.
• So an identifier does not confer identity
• But simply documents or recognizes identity that
  already existed.
• So do identifiers such as customer numbers,
  social security numbers, etc.

48
??5.1. Real-World vs Data-World Objects
Identity In the data world

• We must be cautious about using real-world
  identifiers in our software and ensure they are
  truly unique
• Many O-O systems generate globally unique Object
  IDentifiers or OIDs
• Remember, only objects have identity, attribute
  values dont.

49
??5.1. Real-World vs Data-World Objects
Encapsulation
50
??5.1. Real-World vs Data-World Objects
Encapsulation In the real world

• What does matter is
• Consistency in the published interface.
• The Model T Ford had the clutch between the brake
  and gas pedals! But. . .
• Every car made these days has the standard pedal
  layout.
• Now we have standard user interfaces (or close)
  for all kinds of products
• Touch phones, keyboards, cars, motorcycles,
  microwave ovens, thermostats, TV remote controls,
  etc., etc., etc.

51
??5.1. Real-World vs Data-World Objects
Encapsulation In the real world

• What all of these do, is
• Hide the details.
• The complexity is enclosed within the product
• Leaving a small, easily-understood set of
  commands to operate it.

52
??5.1. Real-World vs Data-World Objects
Encapsulation In the data world

• We hide both data and program code within the
  object
• Giving a level of encapsulation better than ever
  before,
• Leading to
• Stability
• and
• Portability.

53
??5.1. Real-World vs Data-World Objects
Encapsulation In the data world

• Stability is improved since once a class is
  built, it will survive the years with very few
  changes.
• It can be reused in new projects with few changes
• But all this only works if
• We do our analysis accurately in the first place.

54
??5.1. Real-World vs Data-World Objects
Encapsulation In the data world

• Portability is enhanced because
• Only the narrow published interface
• needs to be learned
• by the new developers,
• i.e., the reuse.

55
??5.1. Real-World vs Data-World Objects
Encapsulation In the data world

• All the attributes and their values
• should be hidden within the object
• and accessible only via the methods.
• There should be a crisp boundary between what
  is inside the object and what is outside it,
• Crossed only by the
• narrow published interface.

56
??5.1. Real-World vs Data-World Objects
Encapsulation In the data world

• Since we have encapsulated all the data and
  behavior of our system within the classes,
• we reduce the ripple effect of change.
• Even though the reduction may be small for each
  class, remember. . .
• The number of possible interactions goes up
  exponentially with the number of objects.
• In a large system this makes a huge difference in
  maintenance.

57
??5.1. Real-World vs Data-World Objects
Object States
58
??5.1. Real-World vs Data-World Objects
Object States In the real world

• A Purchase Order
• begins life as a request document,
• gets authorized at various levels,
• goes out to a vendor,
• is fulfilled by receiving the goods,
• and finally is archived for future reference.

59
??5.1. Real-World vs Data-World Objects
Object States States in the real world

• Many objects in the real world go through a
  predictable cycle
• From their creation,
• Through their useful life,
• From stage to stage
• Until they die or are somehow disposed of
• (Archived or deleted or whatever.)

60
??5.1. Real-World vs Data-World Objects
Object States

• Each time something happens to the object,

• and something changes about it,
• we say that it now exists in a different
• state.
• We can also say that each time an attribute
  changes its value,
• the object now exists in a new
• state.

61
??5.1. Real-World vs Data-World Objects Object
States

• We define a State Transition

• As the act or experience
• of changing from one state to another.
• We define an object lifecycle as
• the various states that an object may
  transition through,
• the set of permissible transitions,
• and the sequencing of those states and
  transitions,
• as it progresses from its initial creation to its
  eventual disposal.

62
Chapter 5 Objects and Classes

• ??5.1. Real-World vs Data-World Objects
• ??5.2. Classes and Classification
• ??5.3. Transient and Persistent Objects
• ??5.4. Objects Classes or Instances?
• ??5.5. Associations

63
??5.2. Classes and ClassificationIn the real
world

• Children and adults alike group objects by some
  or all of the following criteria
• Similar values for one or more attributes.
• An attribute value within a specified range.
• All that have a certain attribute (regardless of
  value.)
• Those that display similar behavior.
• Those that have similar relationships.

64

• We group objects together on the basis of
• Shared Attributes
• Shared behavior
• Class of
• All Employees
• All Products
• All Transactions
• An individual object is then an
• INSTANCE

65
??5.2. Classes and ClassificationIn the real
world

• For our purposes, then,
• A class is a group of objects with similar
  properties (attributes), common behavior
  (operations), common associations to other
  objects, and common semantics (i.e., meaning.)

66
The class of Fire Trucks
The class of Animals
67
??5.2. Classes and ClassificationSubclasses In
the real world
Some instances of a class may be grouped
together on the basis of

• Features not shared by the rest of the class
• Attributes
• Behavior
• Associations
• Key verb is

ISAKINDOF
68
The class of Fire Trucks
Subclass of Elephants
The class of Animals
Subclass of Turtles
69
?? 5.2. Classes and Classification Subclasses In
the real world
In our company, does a Customer have a name?

• Yes, of course!
• But Why?
• Because a Customer is a person, and
• people have names.
• Does a Customer have a Wage Rate?
• No, only Employee-type people have one of those!

70
Overlapping Sets of Attributes
Customer Attributes
Balance Owing Amount Overdue 30 days Amount
Overdue 60 days Amount Overdue 90 days
Credit Rating Date of Last Payment
Name Name Address Address Phone
Phone Date of Birth Date of Birth Sex
Sex
Person Attributes
SIN Marital Status Number of
Dependants Date Hired Wage Rate
Employee Attributes
71
Venn diagram of ATTRIBUTES
CUSTOMER ATTRIBUTES
EMPLOYEE ATTRIBUTES
PEOPLE ATTRIBUTES
72
venn diagram of INSTANCES
PEOPLE
CUSTOMERS
EMPLOYEES
73
Hierarchy Diagram(UML notation)
PERSON
Name, Address Phone, Sex Date of
Birth ChangeAddress EnquireDOBSex
CANBEA
ISAKINDOF
CUSTOMER
EMPLOYEE
Balance O/Due 30, 60, 90 Credit Rating Date
Paid CheckCrRating AgeBalances
SIN Marital Status No. of Dependants Date
Hired Wage Rate GiveRaise CalcMonthPay
This kind of arrowhead to indicate that this
relationship is one of subclassing
74
?? 5.2. Classes and Classification Classes In
the DATA world
Classes perform such things as

• Creating Instances
• Holding the program code
• Holding the attribute definitions
• Data type and size, etc.
• Point of contact for associations.

75
??5.2. Classes and ClassificationMapping Classes
from the Real World to the Data World

• Finding the classes is the core activity of OOA.
• Chapter 9 has specific methods and how-tos.
• So we develop a Class Diagram, and
• add the attributes, to it
• and then add the behaviors.

76
??5.2. Classes and ClassificationAdditional
Data-world Classes

• You will add some extra classes as you go,
• Some at Analysis, and some at Design.
• Mostly they will be these 3 kinds
• Interface Classes
• Control Classes
• Abstract classes

77
??5.2. Classes and ClassificationAdditional
Data-world Classes

• Interface Classes
• To encapsulate communication details
• With user (GUI), other systems, etc.
• Reuse from earlier projects.
• Control Classes
• A place to put large method(s)
• That may draw data, and call methods, from many
  classes
• Typically these classes have few attributes, and
  perhaps only this one method.

78
??5.2. Classes and ClassificationAdditional
Data-world Classes

• Abstract Classes
• Often added to take advantage of inheritance and
  polymorphism
• Sometimes we invent an artificial superclass
• To make use of some common attributes or behavior

79
??5.2. Classes and ClassificationAdditional
Data-world Classes

• Abstract Classes
• Such classes have no instances other than
• the ones provided for them by their subclasses
• That is, they have no Direct Instances
• For this reason we call them Abstract
  Classes
• More in Chapter 8.

80
Chapter 5 Objects and Classes

• ??5.1. Real-World vs Data-World Objects
• ??5.2. Classes and Classification
• ??5.3. Transient and Persistent Objects
• ??5.4. Objects Classes or Instances?
• ??5.5. Relationships

81
??5.3. Transient and Persistent Objects

• For each class we discover or create, we must
  decide whether these objects need to be
• Transient, destroyed at or before the end of the
  session, or
• Persistent, kept in storage for a considerably
  longer time.

82
Chapter 5 Objects and Classes

• ??5.1. Real-World vs Data-World Objects
• ??5.2. Classes and Classification
• ??5.3. Transient and Persistent Objects
• ??5.4. Objects Classes or Instances?
• ??5.5. Associations

83
??5.4. Objects Classes or Instances? BEWARE

• Many authors use object to refer to a class.
• Strictly, as used in UML, an object is an
  Instance.

84
Chapter 5 Objects and Classes

• ??5.1. Real-World vs Data-World Objects
• ??5.2. Classes and Classification
• ??5.3. Transient and Persistent Objects
• ??5.4. Objects Classes or Instances?
• ??5.5. Associations

85
??5.5. Associations

• Associations represent (i.e., they abstract)
• actions that involve two or more objects
• That is, they abstract the interactions among the
  objects.
• They are modeled by verbs
• That abstract what one object does to another.
• More in Chapters 8 and 9.

86
End of Chapter 5.