1 / 86 objects and classes objects and classes. 2 / 86 objects and classes 5.1. real-world vs...

1 / 86

Objects and ClassesObjects and Classes

2 / 86

Objects and Classes

5.1. Real-World vs Data-World Objects

5.2. Classes and Classification5.3. Transient and Persistent

Objects5.4. Objects: Classes or Instances?5.5. Associations

3 / 86

5.1. Real-World vs Data-World ObjectsHere is what it’s all about:

We Analysts must understandunderstand and documentdocument the real world real world where our users live.

We then create a product in the in the computer world,computer world,

To help the users do their job help the users do their job in the real world.

Effective analysts Effective analysts must ensure the computer-world product accurately mirrors the users’ real-world needs.real-world needs.

4 / 86


What An Object Is In the Real World In the Data World

Jacobson’s Three Types Entity Objects

Concrete objects Conceptual objects Event and State objects

Interface Objects Control Objects

Attributes Behavior Identity Encapsulation Object States

Now let’s look at these in detailNow let’s look at these in detail. . .. . .

5 / 86

The World is full of

THINGSTHINGS

6 / 86

THINGSTHINGS An object is some ThingThing in the world of the user

Car, Train, Elephant, Sale, Invoice, Division, Account, etc. Physical or Conceptual

It has AttributesAttributes that describe it: Make, Model, Year, Color, Weight, Serial Number, License Number

It has RelationshipsRelationships to other objects: e.g., to a Person object, i.e., the Owner.

It has BehaviorBehavior that it can do: Create Change Color Change Owner Destroy Itself (Suicide?)

Entity

Object

7 / 86

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 / 86

A Data Object Data Object is an abstractionabstraction of some thingthing in the real world, that

carries both the datadata describing the real-world object , and the

operationsoperations (i.e., program codeprogram code) that have the

only allowable access only allowable access to that data.to that data.

5.1. Real-World vs Data-World ObjectsWe Define:We Define:

9 / 86

Entity Objects Interface ObjectsControl Objects

5.1. Real-World vs Data-World ObjectsJacobson’s Three Types

In the interests of stability and flexibility to change, Jacobson classifies objects into

three types:

Let’s look at these in detail. . .Let’s look at these in detail. . .

10 / 86


Definition:Definition:

Entity Objects Entity Objects are the fundamental objects and

classes that we discover in Analysis by scanning the users’ scanning the users’

business.business.

11 / 86


There are three kinds of Entity Objects:

ConcreteConcrete objectsConceptualConceptual objectsEventEvent and StateState

objects. . .

12 / 86


.Concrete Objects:Solid, tangible and physical.Things you can grab hold of.People, animals and other beingsLand, buildings, equipment, vehiclesGoods, products, tools, appliances,

materialsThese are easily understood by both analysts and These are easily understood by both analysts and

users.users.

13 / 86

5.1. Real-World vs Data-World ObjectsConcrete Entity Objects

Person Apartment Elevator FoodEmployee Warehouse Forklift ProductCustomer House Car ClothesStudent College Cell phonePenCitizen Street Truck GravelEngineer Office Lathe SteelAnimal FarmTractor BeerDoctor Hospital Scalpel BloodLibrarian Library Computer BookCop Station Gun Bullets

BeingsBeings Land & BuildingsLand & Buildings EquipmentEquipment GoodsGoods

14 / 86


.

Conceptual Objects: Intangible, nonphysicalMore difficult for users to grasp,But they are still thingsthings and objectsobjectsTypically defined in terms of other

object classes . . . e.g., by breaking out a M:M

relationship See Chapter 9.

15 / 86

Corporation Strategy LeaseChurch Plan MortgageRegiment Map CeasefireSports club Schedule

MembershipGovernment dept Proposal ApprovalProfessional assn Qualification

CharterUnion Bylaws Contract

5.1. Real-World vs Data-World ObjectsConceptual Entity Objects

OrganizationsOrganizations AbstractionsAbstractions AgreementsAgreements

16 / 86

These are conceptualconceptual in the sense that a contract does notnot consist of a piece of paper.

Rather, it is an agreement that comes into existence,

The moment the two parties agreeagree, verbally or otherwise.

Signing the piece of paper documentsdocuments the existence of the contract, to make it easier to enforce (e.g. in court).


Conceptual Objects:

17 / 86

Also very abstract in nature.When an EventEvent occurs, some

object will change its StateState.When a business event business event occurs, it is documented, and that is a

fact we must record; i.e., it is it is DataData..


Event and State Objects:

18 / 86

A statestate 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 thingthing, and an object.object.


State Objects:

19 / 86

Purchase Deposit Ownership EnrolmentDelivery Loan Suspense AssignmentNegotiation Return Birth TerminationArrival Hire Status ImmigrantDeparture Rental Licence Registration Transaction Sale In Transit Employment

5.1. Real-World vs Data-World ObjectsEvent and State Entity Objects

EventsEvents StatesStates

20 / 86

Most software systems need to exchange data with other systems.


Interface Objects:

21 / 86

These might be: Other information systems, such as

Human Resources, Accounting, etc., etc. A real-world system controlled by our

softwareIndustrial processes, refineries, etc.Machinery, robots, assembly lines, etc.

Monitoring systemsSecurity systems, Intensive Care Units, etc.


Interface Objects:

22 / 86

These days, they might also be: Communications Interfaces

Point-to-PointModem and phone lineFax and Fax-backLAN, WAN, etc.Internet and/or IntranetPeripheral devices e.g. printers,

scanners, sound and video Input/Output.Graphical User Interfaces (GUIs)


Interface Objects:

23 / 86

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


Interface Objects:

24 / 86

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 Nothing outside this class needs to be touchedneeds to be touched!!!!


Interface Objects:

25 / 86

The complexity of the interface is hiddenhidden within the interface object.

All the interface processing is hidden,

And can be changed can be changed to handle changes such as the communications medium . . . . Without upsetting the rest of the systemWithout upsetting the rest of the system


Interface Objects, Advantages:

26 / 86

This is an example of

EncapsulationEncapsulation, , or Information Hiding, Information Hiding,

which we explore later in this chapter.


Interface Objects, Advantages:

27 / 86

5.1. Real-World vs Data-World Objects5.1. Real-World vs Data-World ObjectsJacobson’s Three Types Jacobson’s Three Types

Interface Objects, Advantages:OtherOther

InterfacesInterfaces

OutputsOutputs

User InterfaceUser Interface

Object BehaviorObject Behavior

Object AttributesObject Attributes

Object ClassesObject Classes

One reason this form of encapsulation is so important is that

The interfaces to other The interfaces to other systems are the least systems are the least stable aspect of any stable aspect of any information system. . information system. .

..

28 / 86

Sometimes we find a method (subroutine, function) that uses data, and calls other methods, from many different many different objects and classes.

These methods don’t easily fit don’t easily fit or don’t don’t logically belong logically belong in any of our entity classes entity classes or interface interface classes.classes.


Control Objects:

29 / 86

So we create a class just to have somewhere to put this method;

This we call a

Control Class.Control Class.


Control Objects:

30 / 86

Sometimes this control class will have just this one method.one method.

Nothing else, no attributesno attributes, no nothing!no nothing!Other times it will need a few attributes

for intermediate results, etc.And perhaps a few other methods.


Control Objects:

31 / 86

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


Control Objects:

32 / 86


We’ve looked at these, Now let’s look at these in detail. . .





Summary

AttributesBehaviorIdentityEncapsulation

Violating Encapsulation

Object States

33 / 86


Attributes

34 / 86

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

5.1. Real-World vs Data-World ObjectsAttributes

In the real world:

35 / 86

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 domaindomain of an attribute is its set of all all

permissible values. permissible values.

5.1. Real-World vs Data-World ObjectsAttributes

In the data world:

36 / 86


Behavior

37 / 86

A child makes two observations about the objects surrounding her:

They have attributesattributes, andThey DODO things.And she learns to influence that

behavior by sending them messagesmessages

5.1. Real-World vs Data-World Objects Behavior

In the real world:

38 / 86

An object (a parent) responds to the child’s message

by performing the behavior that goes with that message

And in the process performs some serviceservice that the child needed. This view of the behavior as a serviceservice is

important in ‘Responsibility-Driven Design’‘Responsibility-Driven Design’ which we will examine in later chapters.


In the real world:

39 / 86

Throughout life we use this method to manipulate objects around us

We issue commandscommands to people, computers, cars, graphic objects, and all kinds of things,

Sometimes we get the resultsresults we desire. Everyone, including your users,

manipulates their world with this “send-a-“send-a-message-get-a-service” message-get-a-service” approach to life.


In the real world:

40 / 86

OvertOvert behavior PassivePassive behavior ResponsiveResponsive behavior

Now let’s look at these in detail. . .Now let’s look at these in detail. . .


In the data world, there are three types of behavior that may concern us:

41 / 86

Where we actually instruct the object to do something:do something:

“Graphic object, display thyself”“Heating valve, open yourself”“Window, minimize yourself”

etc. . .

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

Overt Behavior:

42 / 86

This is really just record-keeping:record-keeping:The recording of the data generated by some The recording of the data generated by some

action or event in the real world.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. . .


Passive Behavior:

43 / 86

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


Responsive Behavior:

44 / 86


We’ve looked at these, and these,





Summary

AttributesBehaviorNow let’s look at these in detail. .

IdentityEncapsulation

Violating Encapsulation

Object States

45 / 86


Identity

46 / 86

Identity is inherentinherent in an object.Oxford: inherentinherent - “Involved in the

essential character of something.”

InherentInherent means that an object has identity just because it is that object.

5.1. Real-World vs Data-World Objects Identity

In the real world:

47 / 86

A child has identity from the moment of birth, or perhaps before.

It doesn’t get a name until after its birth. So an identifier does not conferconfer identity But simply documentsdocuments or recognizes recognizes identity

that already existed. So do identifiers such as customer

numbers, social security numbers, etc.


In the real world:

48 / 86

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 OObject IDIDentifiers or “OIDs”“OIDs”

Remember, only objects have identity, attribute values don’t.


In the data world:

49 / 86


Encapsulation

50 / 86

What does matter isConsistency in the published interface.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.

5.1. Real-World vs Data-World Objects Encapsulation

In the real world:

51 / 86

What all of these do, is

Hide the details.Hide the details. The complexity is enclosed within the

product Leaving a small, easily-understood set of

commands to operate it.


In the real world:

52 / 86

We hide both data and program code within the object

Giving a level of encapsulation better than ever before,

Leading to

StabilityStability and

Portability.Portability.


In the datadata world:

53 / 86

StabilityStability 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 We do our analysis accurately in the first place. in the first place.


In the data world:

54 / 86

PortabilityPortability is enhanced because:

Only the narrow published interfacenarrow published interfaceneeds to be learned

by the new developers,i.e., the reuse.


In the data world:

55 / 86

All the attributes and their valuesshould be hidden within the object

and accessible only via the methods.There should be a “crisp” boundary “crisp” boundary

between what is insideinside the object and what is outsideoutside it,

Crossed only by the narrow published interface.narrow published interface.


In the data world:

56 / 86

Since we have encapsulated all the data and behavior of our system within the classes,

we reduce the “ripple effect“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.


In the data world:

57 / 86


Object States

58 / 86

A Purchase Order Purchase Order begins life as a request document, request document, gets authorizedauthorized at various levels,

goes out to a vendor, out to a vendor, is fulfilled by receivingreceiving the goods, and finally is archivedarchived for future

reference.


Object States In the real world:

59 / 86

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 predictable cycle

From their creation,creation, Through their useful life,useful life, From stage to stage Until they die or are somehow disposed of disposed of

(Archived or deleted or whatever.)

60 / 86

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

and something changes about it, we say that it now exists in a different

state.state. We can also say that each time an attribute

changes its value, the object now exists in a new

state.state.

Each time something happens to the object,

61 / 86

5.1. Real-World vs Data-World Objects: Object States

As the act or experience of changing from one state to another.

We define an object lifecycle object lifecycle asas the various statesstates that an object may

transition through, the set of permissible transitionstransitions, and the sequencingsequencing of those states and

transitions, as it progresses from its initial creation to its as it progresses from its initial creation to its

eventual disposal.eventual disposal.

We define a State TransitionState Transition

62 / 86

Chapter 5: Objects and Classes


5.2. Classes and Classification5.2. Classes and Classification5.3. Transient and Persistent

Objects5.4. Objects: Classes or Instances?5.5. Associations

63 / 86

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 havehave a certain attribute (regardless

of value.) Those that display similar behavior. Those that have similar relationships.

5.2. Classes and ClassificationIn the real world

64 / 86

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 INSTANCE

65 / 86

For our purposes, then,

A classclass is a group of objects with: similar similar propertiesproperties

(attributes), common common behaviorbehavior (operations), common common

associationsassociations to other objects, and common common semanticssemantics (i.e.,

meaning.)

5.2. Classes and ClassificationIn the real world

66 / 86

The class of Fire Trucks

The class of Animals

67 / 86

Features not shared by the rest of the class Attributes Behavior Associations

Key verb is:

Some instances of a class may be grouped together on the basis of

““ISAKINDOF”ISAKINDOF”

5.2. Classes and Classification

Subclasses In the real world

68 / 86

The class of Fire Trucks

The class of Animals

Subclass of Elephants

Subclass ofTurtles

69 / 86

Yes, of course! But Why? Because a Customer is a personperson, , and peoplepeople have names. Does a Customer have a Wage Rate?Wage Rate? No, only EmployeeEmployee-type people have

one of those!

5.2. Classes and Classification Subclasses In the real world

In our company, does a Customer have a name?In our company, does a Customer have a name?

70 / 86

Balance Owing Amount Overdue 30 days Amount Overdue 60 days Amount Overdue 90 days

Credit Rating Date of Last Payment

Name NameAddress AddressPhone Phone

Date of Birth Date of BirthSex Sex

SIN Marital Status

Number of DependantsDate HiredWage Rate

Overlapping Sets of AttributesCustomerAttributes

Person Attributes

EmployeeAttributes

71 / 86

Venn diagram of ATTRIBUTES

CUSTOMER ATTRIBUTES EMPLOYEE

ATTRIBUTESPEOPLEATTRIBUTES

72 / 86

venn diagram of INSTANCES

PEOPLE

CUSTOMERS

EMPLOYEES

73 / 86

Hierarchy Diagram(UMLUML notation)

PERSON

CUSTOMER EMPLOYEEBalanceO/Due 30, 60, 90Credit RatingDate PaidCheckCrRatingAgeBalances

Name, AddressPhone, SexDate of BirthChangeAddressEnquireDOB&Sex

SINMarital StatusNo. of DependantsDate HiredWage RateGiveRaiseCalcMonthPay

CANBEA

ISAKINDOF

This kind of arrowhead to indicate that this relationship is one of subclassing

74 / 86

Creating InstancesHolding the program codeHolding the attribute definitions

Data type and size, etc.Point of contact for associations.

5.2. Classes and Classification Classes In the DATA world

Classes perform such things as:Classes perform such things as:

75 / 86

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.

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

76 / 86

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

5.2. Classes and ClassificationAdditional Data-world Classes

77 / 86

Interface ClassesInterface Classes To encapsulate communication details With user (GUI), other systems, etc. Reuse from earlier projects.

Control ClassesControl 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 / 86

Abstract ClassesAbstract 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 / 86

Abstract ClassesAbstract Classes Such classes have no instances other than the ones provided for them by their

subclasses That is, they have no Direct InstancesDirect Instances For this reason we call them

Abstract ClassesAbstract Classes More in Chapter 8.


80 / 86



5.2. Classes and Classification5.3. Transient and Persistent Objects5.3. Transient and Persistent Objects5.4. Objects: Classes or Instances?5.5. Relationships

81 / 86

5.3. Transient and Persistent ObjectsFor each class we discover or

create, we must decide whether these objects need to be:

Transient, Transient, destroyed at or before the end of the session, or

Persistent, Persistent, kept in storage for a considerably longer time.

82 / 86




Objects5.4. Objects: Classes or Instances?5.4. Objects: Classes or Instances?5.5. Associations

83 / 86

Many authors use “object” to refer to a classclass..

Strictly, as used in UMLas used in UML, an “object” “object” is

an InstanceInstance. .

5.4. Objects: Classes or Instances?

BEWAREBEWARE::

84 / 86




Objects5.4. Objects: Classes or Instances?5.4. Objects: Classes or Instances?5.5. Associations5.5. Associations

85 / 86

5.5. Associations Associations represent (i.e., they

abstractabstract) actions that involve two or more

objects; That is, they abstract the interinteractionsactions

among the objects. They are modeled by verbsverbs That abstractabstract what one object does to does to

another. More in Chapters 8 and 9.

86 / 86

End.

1 / 86 objects and classes objects and classes. 2 / 86 objects and classes 5.1. real-world vs...

Documents