1 / 86 objects and classes objects and classes. 2 / 86 objects and classes 5.1. real-world vs...
Post on 18-Jan-2018
274 Views
Preview:
DESCRIPTION
TRANSCRIPT
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
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?)
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
5.1. Real-World vs Data-World ObjectsJacobson’s Three Types
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
5.1. Real-World vs Data-World ObjectsJacobson’s Three Types
There are three kinds of Entity Objects:
ConcreteConcrete objectsConceptualConceptual objectsEventEvent and StateState
objects. . .
12 / 86
5.1. Real-World vs Data-World ObjectsJacobson’s Three Types
.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
5.1. Real-World vs Data-World ObjectsJacobson’s Three Types
.
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).
5.1. Real-World vs Data-World ObjectsJacobson’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 ObjectsJacobson’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 ObjectsJacobson’s Three Types
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.
5.1. Real-World vs Data-World ObjectsJacobson’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
softwareIndustrial processes, refineries, etc.Machinery, robots, assembly lines, etc.
Monitoring systemsSecurity systems, Intensive Care Units, etc.
5.1. Real-World vs Data-World ObjectsJacobson’s Three Types
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)
5.1. Real-World vs Data-World ObjectsJacobson’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?
Well, . .Well, . .
5.1. Real-World vs Data-World ObjectsJacobson’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 ObjectsJacobson’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 of the systemWithout upsetting the rest of the system
5.1. Real-World vs Data-World ObjectsJacobson’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 ObjectsJacobson’s Three Types
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.
5.1. Real-World vs Data-World ObjectsJacobson’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 ObjectsJacobson’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 ObjectsJacobson’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 ObjectsJacobson’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
AttributesBehaviorIdentityEncapsulation
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 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
5.1. Real-World vs Data-World Objects
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.
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-a-“send-a-message-get-a-service” message-get-a-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 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. . .
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
AttributesBehaviorNow let’s look at these in detail. .
IdentityEncapsulation
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 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.
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
StabilityStability and
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 interfaceneeds 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 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.
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 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.
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 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
Chapter 5: 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.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
Chapter 5: 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.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.
top related