Chap 05 - object and class...that we discover in Analysis by scanning the users’ business. 11/ 86...
Transcript of Chap 05 - object and class...that we discover in Analysis by scanning the users’ business. 11/ 86...
-
1 / 86
Chapter 5Chapter 5
Objects and ClassesObjects and Classes
2 / 86
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 / 86
���� 5.1. Real-World vs Data-World Objects
Here 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 computer in the computer
world,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’ realreal--world needs.world needs.
4 / 86
���� 5.1. Real-World vs Data-World Objects
� 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?)
EntityEntityEntityEntity
ObjectObjectObjectObject
-
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.
EntityEntityEntityEntity
ObjectObjectObjectObject
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 Objects
We Define:We Define:
-
9 / 86
�Entity Objects
� Interface Objects
�Control Objects
���� 5.1. Real-World vs Data-World Objects
Jacobson’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
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types
Definition:Definition:
Entity Objects Entity Objects are the fundamental objects and classes
that we discover in Analysis by
scanning the users’ business.scanning the users’ business.
-
11 / 86
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types
There are three kinds of Entity Objects:
��ConcreteConcrete objects
��ConceptualConceptual objects
��EventEvent and StateState objects. . .
12 / 86
���� 5.1. Real-World vs Data-World Objects
Jacobson’s 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 These are easily understood by both
analysts and users.analysts and users.
-
13 / 86
���� 5.1. Real-World vs Data-World Objects
Concrete Entity Objects
Person Apartment Elevator Food
Employee Warehouse ForkliftProduct
Customer House CarClothes
Student College Cell phone Pen
Citizen Street Truck Gravel
Engineer Office LatheSteel
Animal Farm Tractor Beer
Doctor Hospital ScalpelBlood
BeingsBeings Land & BuildingsLand & Buildings EquipmentEquipment GoodsGoods
14 / 86
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types .
Conceptual Objects:
� Intangible, nonphysical
�More difficult for users to grasp,
�But they are still thingsthings and objectsobjects
�Typically defined in terms of other
object classes . . .
e.g., by breaking out a M:M
relationship
See Chapter 9.
-
15 / 86
Corporation Strategy Lease
Church Plan Mortgage
Regiment Map Ceasefire
Sports club Schedule Membership
Government dept Proposal
Approval
Professional assn Qualification
Charter
Union Bylaws
Contract
���� 5.1. Real-World vs Data-World Objects
Conceptual 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).
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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..
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types State Objects:
-
19 / 86
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
���� 5.1. Real-World vs Data-World Objects
Event and State Entity Objects
EventsEvents StatesStates
20 / 86
Most software systems need
to exchange data with
other systems.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types
Interface Objects:
-
21 / 86
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.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types Interface Objects:
22 / 86
�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)
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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?
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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!!!!
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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 Without upsetting the rest
of the systemof the system
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types Interface Objects, Advantages:
26 / 86
�This is an example of
EncapsulationEncapsulation, , or Information Hiding, Information Hiding,
which we explore later in this chapter.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types Interface Objects, Advantages:
-
27 / 86
���� 5.1. Real5.1. Real--World vs DataWorld vs Data--World ObjectsWorld Objects
Jacobson’s Three Types Jacobson’s Three Types Interface Objects, Advantages:
OtherOther
InterfacesInterfaces
OutputsOutputs
User InterfaceUser Interface
Object BehaviorObject Behavior
Object AttributesObject Attributes
Object ClassesObject ClassesObject ClassesObject Classes
� One reason this
form of
encapsulation is
so important is
that
The interfaces to other The interfaces to other
systems are the systems are the
least stable aspect least stable aspect
of any information of any information
system. . .system. . .
28 / 86
�Sometimes we find a method
(subroutine, function) that uses data,
and calls other methods, from many many
different 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.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types 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.
���� 5.1. Real-World vs Data-World Objects
Jacobson’s Three Types Control Objects:
32 / 86
���� 5.1. Real-World vs Data-World Objects
We’ve looked at these, Now let’s look at these in detail. . .
� 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
� Summary
�Attributes
�Behavior
�Identity
�Encapsulation�Violating Encapsulation
�Object States
-
33 / 86
���� 5.1. Real-World vs Data-World Objects
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
���� 5.1. Real-World vs Data-World Objects
Attributes
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 Objects
Attributes
In the data world:
36 / 86
���� 5.1. Real-World vs Data-World Objects
Behavior
-
37 / 86
�A child makes two observations about
the objects surrounding her:
�They have attributesattributes, and
�They 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‘Responsibility--Driven Design’Driven Design’
which we will examine in later chapters.
���� 5.1. Real-World vs Data-World Objects
Behavior
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“send--aa--messagemessage--getget--aa--
service” service” approach to life.
���� 5.1. Real-World vs Data-World Objects
Behavior
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. . .
���� 5.1. Real-World vs Data-World Objects
Behavior
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 recordrecord--keeping:keeping:
��The recording of the data generated by The recording of the data generated by
some action or event in the real world.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. . .
���� 5.1. Real-World vs Data-World Objects
Behavior In the real worldBehavior In the real world
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. . .
���� 5.1. Real-World vs Data-World Objects
Behavior In the real worldBehavior In the real world
Responsive Behavior:
44 / 86
���� 5.1. Real-World vs Data-World Objects
We’ve looked at these, and these,
� 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
� Summary
�Attributes
�Behavior
Now let’s look at these in detail. .
�Identity
�Encapsulation�Violating Encapsulation
�Object States
-
45 / 86
���� 5.1. Real-World vs Data-World Objects
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.
���� 5.1. Real-World vs Data-World Objects
Identity
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.
���� 5.1. Real-World vs Data-World Objects
Identity
In the data world:
-
49 / 86
���� 5.1. Real-World vs Data-World Objects
Encapsulation
50 / 86
� What does matter is
��Consistency 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.
���� 5.1. Real-World vs Data-World Objects
Encapsulation
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
StabilityStabilityand
Portability.Portability.
���� 5.1. Real-World vs Data-World Objects
Encapsulation
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.
���� 5.1. Real-World vs Data-World Objects
Encapsulation
In the data world:
54 / 86
�� PortabilityPortability is enhanced because:
Only the narrow published interfacenarrow published interface
needs to be learned
by the new developers,
i.e., the reuse.
���� 5.1. Real-World vs Data-World Objects
Encapsulation
In the data world:
-
55 / 86
� All the attributes and their values
should 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.
���� 5.1. Real-World vs Data-World Objects
Encapsulation
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.
���� 5.1. Real-World vs Data-World Objects
Encapsulation
In the data world:
-
57 / 86
���� 5.1. Real-World vs Data-World Objects
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.
���� 5.1. Real-World vs Data-World Objects
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.1. Real-World vs Data-World Objects
���� 5.2. Classes and Classification5.2. Classes and Classification
���� 5.3. Transient and Persistent Objects
���� 5.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 TrucksThe class of Fire TrucksThe class of Fire TrucksThe class of Fire Trucks
The class of AnimalsThe class of AnimalsThe class of AnimalsThe 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 Some instances of a class may be Some instances of a class may be Some instances of a class may be
grouped together on the basis ofgrouped together on the basis ofgrouped together on the basis ofgrouped together on the basis of
“ISAKINDOF”“ISAKINDOF”“ISAKINDOF”“ISAKINDOF”“ISAKINDOF”“ISAKINDOF”“ISAKINDOF”“ISAKINDOF”
���� 5.2. Classes and ClassificationSubclasses In the real world
68 / 86
The class of Fire TrucksThe class of Fire TrucksThe class of Fire TrucksThe class of Fire Trucks
The class of AnimalsThe class of AnimalsThe class of AnimalsThe class of Animals
Subclass of ElephantsSubclass of ElephantsSubclass of ElephantsSubclass of Elephants
Subclass ofSubclass ofSubclass ofSubclass of
TurtlesTurtlesTurtlesTurtles
-
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 ClassificationSubclasses 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 Name
Address Address
Phone Phone
Date of Birth Date of Birth
Sex Sex
SIN
Marital Status
Number of Dependants
Date HiredWage Rate
Overlapping Sets of AttributesCustomer
Attributes
Customer
Attributes
Person
Attributes
Person
Attributes
Employee
Attributes
Employee
Attributes
-
71 / 86
Venn diagram of
ATTRIBUTES
CUSTOMER CUSTOMER CUSTOMER CUSTOMER
ATTRIBUTESATTRIBUTESATTRIBUTESATTRIBUTES EMPLOYEEEMPLOYEEEMPLOYEEEMPLOYEE
ATTRIBUTESATTRIBUTESATTRIBUTESATTRIBUTESPEOPLEPEOPLEPEOPLEPEOPLE
ATTRIBUTESATTRIBUTESATTRIBUTESATTRIBUTES
72 / 86
venn diagram of
INSTANCES
PEOPLEPEOPLEPEOPLEPEOPLE
CUSTOMERSCUSTOMERSCUSTOMERSCUSTOMERS
EMPLOYEESEMPLOYEESEMPLOYEESEMPLOYEES
-
73 / 86
Hierarchy Diagram
(UMLUML notation)PERSONPERSONPERSONPERSON
CUSTOMERCUSTOMERCUSTOMERCUSTOMER EMPLOYEEEMPLOYEEEMPLOYEEEMPLOYEE
Balance
O/Due 30, 60, 90
Credit Rating
Date Paid
CheckCrRating
AgeBalances
Name, Address
Phone, Sex
Date of Birth
ChangeAddress
EnquireDOB&Sex
SIN
Marital Status
No. of Dependants
Date Hired
Wage Rate
GiveRaise
CalcMonthPay
CANBEACANBEACANBEACANBEA
ISAKINDOFISAKINDOFISAKINDOFISAKINDOF
This kind of arrowhead to
indicate that this relationship
is one of subclassing
74 / 86
�Creating Instances
�Holding the program code
�Holding the attribute definitions
�Data type and size, etc.
�Point of contact for associations.
���� 5.2. Classes and ClassificationClasses 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.
���� 5.2. Classes and ClassificationAdditional Data-world Classes
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
���� 5.2. Classes and ClassificationAdditional Data-world Classes
-
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.
���� 5.2. Classes and ClassificationAdditional Data-world Classes
80 / 86
Chapter 5: Objects and Classes
���� 5.1. Real-World vs Data-World Objects
���� 5.2. Classes and Classification
���� 5.3. Transient and Persistent Objects5.3. Transient and Persistent Objects
���� 5.4. Objects: Classes or Instances?
���� 5.5. Relationships
-
81 / 86
���� 5.3. Transient and Persistent Objects
�For 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
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.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?
BEWAREBEWAREBEWAREBEWAREBEWAREBEWAREBEWAREBEWARE::::::::
84 / 86
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.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 interinteractionsactionsamong 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 of Chapter 5.