CIS490

1
CIS490 Software Engineering Object Oriented
Analysis
2
Object oriented analysis
3
The world is made of objects. Just open your eyes
and ears. They are out there. Bank customers,
students, cats, elephants, cars, balls of string,
atoms, molecules, tubs of ice cream, Madonna,
stars, bureaucrats, Robin Hood. The world is
built of objects. Objects are built of smaller
objects, and so ad infinitum. Objects combine to
make bigger objects. We already live in an
object-oriented world.
4
The first thing an object analyst must do is to
remove the scales from his or her eyes. Object
modeling consists of looking for objects. Of
course, there has to be some boundary. Even
sitting at my desk I can see more objects than I
could reasonably list. But that is where the
beauty of object modeling comes in. It uses
observation.
5
Objects can be described by their attributes and
operations. Attributes are the changeable
characteristics of an object. Cats have color,
size, weight and a preference for either
Kit-E-Kat or Whiskers. Operations are the things
an object does or can have done to it. Cats can
catch mice, eat, miaow, worm up to owners, and be
stroked. In our notation we draw an object such
as a cat like this.
6
(No Transcript)
7
The name is shown at the top. The attributes are
listed underneath. The operations are listed
below that. Actually, strictly speaking, this is
the most very simple class diagram.
8
In an object model, all data is stored as
attributes of some object. The attributes of an
object are manipulated by the operations. The
only way of getting at the attributes is through
an operation.
9
In an object model, all functionality is defined
by operations. Objects may use each others
operations, but the only legal way one object can
manipulate another object is through an
operation. An operation may inform, say "mass of
ball", or change the state of an object, say
"throw ball".
10
Object modeling is about finding objects, their
attributes and their operations, and tying them
together in an object model. Nothing more. Here
are some more objects
11
(No Transcript)
12
Some of these objects may seem jockey, but they
could reasonably be part of a system, be it a
computer game or a multimedia story. Do not be
constrained to be those dull systems that most
software engineers drag out. Object modeling can
be used to design lots of things.
13
By now you should be getting the idea that object
modeling is, at its simplest level, very
straightforward. The trick comes in knowing what
objects are appropriate, and what their
appropriate attributes and operations are. It is
a question of focus. We will consider some ways
of controlling focus later in the course.
14
How do objects relate to other concepts in design
methods? Remember entity-relationship models?
SSADM, JSD and so on have a notion of entity.
These are really objects. All we are doing in
object modeling is relabelling entity modeling.
However, we put the emphasis on capturing and
grouping together both functions and data
(operations and attributes in our terminology).
That is the elegant simplicity of object
modeling. We will look at object models later
which look remarkably like entity-relationship
models (because they are). We will now look one
powerful way of arranging objects - inheritance
hierarchies.
15
Inheritance Often we will find that there are
objects which have something in common. It is
then useful to create an abstract object which
groups together the common features, and to use
inheritance to define the original objects.
16
For example, consider our two fairy story
creatures
Now we can see that they both have the same
operations "arrive" and "meet". We can therefore
create an abstract creature
17
which has the common operations. We can then draw
the original objects grouped under the abstract
object as follows
18
Inheritance means that all the attributes and
operations of an abstract object are available in
the specialized object below. The triangle in the
diagram indicates inheritance. The point of the
triangle indicates where operations and
attributes are inherited from. Now we can enter
a debate about whether nose, teeth and appetite
are characteristics of all creatures or not. It
they are, we can revise the diagram above as
19
(No Transcript)
20
By this device Red Riding Hood has also appetite,
nose and teeth as operations. The latter two may
be of relevance when she goes to charm the
woodcutter, provided they are petite and pearly
bright respectively. Okay, so let's have some
more practical examples for those of you who have
to do real work. Firstly, the frighteningly dull
student-lecturer example. You can do the same
with the equally dull employee-customer example.
21
(No Transcript)
22
(No Transcript)
23
(No Transcript)
24
The big deal about inheritance Inheritance is
considered good for the software re-use and for
clarity of description. Re-use When new objects
are created which are similar to other objects,
they can have many of their attributes and
operations ready defined. Let us suppose we now
introduce Grandma into our fairy story hierarchy.

25
(No Transcript)
26
Here we get a Grandma who already had an
appetite, nose and teeth and who can arrive and
meet. Actually these are not in the normal scope
of the fairy story, but the principle should be
clear.
27
We might be writing a simple geometry program
28
Now to add circles we simply put in another
object under 2D shape
So the circle object need not define the area and
position attributes or the get area operation
29
It is now possible to buy or obtain ready-built
class hierarchies written in object-oriented
languages which can be extended in this way to
produce a new application. Designing complex
class hierarchies takes time and good design
requires experience. But the basic principles
outlined above, with some intuitive guidelines,
are the basis for the design of good, re-usable
designs. Re-use can be viewed from two
directions. Components can be re-used, which is a
sort of bottom-up approach to re-use. Or designs
can be re-used. Both elements are important in
the production of re-usable software.
30
Relationships Objects can be related in other
ways than by inheritance and aggregation. Any
relationship between real world objects can be
modeled cats eat canaries, dogs bite postmen,
the woodcutter murders the wolf, cars run over
little old ladies, employees work for
organizations, patients visit hospitals, patients
stay in hospitals.
31
One to one relationships In a one-to-one
relationship, one object is associated with
exactly one of its related objects. This is
modelled by a straight line drawn between the
objects. If the relationship is one-way, then an
arrow is used to indicate the direction. The line
can be labelled.
32
Thus a man marries one woman (at a time) and a
woman marries one man (at a time). A cat eats one
canary (before being battered to death by the
little old lady who owned the canary). Canaries
do not (in general) eat cats, so the eats
relationship is one way.
33
One to many relationships Sometimes one object
can be related to many objects. This is indicated
by different marks at the end of the line.
A player plays for one football team. There are
at least 11 players for a given football team.
Football teams do not play for players.
34
Many to many relationships
Sometimes objects at either end of a relationship
may be related to many objects at the other end
A dog may bite zero or more postmen. A postman
may be bitten by zero or more dogs.
35
A lubricant is recommended for at least one
engine. An engine has at least one lubricant
recommended for it.
36
The OOA Process - I

• Steps and Rules
• Objects and Structures

37
The Steps of OOA - Part 1

• identify objects (classes)
• identify structures
• generalization - specialization (ISA)
• whole - parts (PART-OF)
• association (relationship)
• define attributes
• Static Objectdiagram
• incomplete Object Dictionary

38
The Steps of OOA - Part 2

• define services via scenarios
• services per object
• message passing between objects
• coordination of message passing
• states and transitions
• Scenarios
• complete Object Dictionary

39
OOA - Object

• generalization of
• a set of real-life entities/objects
• groups a set of attributes (schema)
• can be active (services)
• has memory (states)
• participates in structures
• label typically a noun
• specified in the object dictionary

label
label
40
OOA - Object Class Instance

• A symbol for
• an object class and
• its object instances.
• a description of one or more objects with a
  uniform set of attributes and services, and the
  actual object instances belonging to the given
  class
• usual way to model an object

label
41
OOA - Whole-Part

• groups objects by combining smaller parts into
  larger units
• forms a hierarchy by
• aggregation
• decomposition
• cardinalities must be specified
• (min , max)
• no inheritance

whole
(min,max)
(min,max)
(min, max)
(min, max)
part1
part2
42
OOA - Generalization-Specialization

• groups objects based on similarity of attributes
  and services
• forms a class hierarchy by
• generalization
• specialization
• attributes, services, etc. are inherited by the
  more specialized from the more general objects

gen
spec1
spec2
43
Employee
Inheritance
name address
Manager
Programmer
experience courses
list of prg-lang.
44
OOA - Object Class

• Object Class only
• NO instantiations possible
• a generalization of one or more objects with a
  uniform set of attributes and services
• can have attributes, services, states
• used in classification structures to organize
  object hierarchies

label
45
Student
Employee
Multiple Inheritance Inheritance Lattices
Major GPA
name address
Teaching Assistant
46
OOA - Association

• provides free mapping between objects
• complements the two predefined structural types
• forms a network of objects by using binary
  relationship types
• cannot carry attributes
• supports access to partner-object (via foreign
  key)

obj1
(min,max)
label
(min,max)
47
Manages which department? Follow
association. Since when? Attribute of ...?
access
Manager
Department
(1,N)
(1,1)
manages
48
OOA

• An Example

49
ACCOUNT
Static OOAD Diagram
acct balance sec-code state
TRANS_REC
trans_type date_time amount teller_ID
has
withdrw dep prov_balance
(0,N)
(1,1)
ATM
atm
req_withdrw req_dep req_balance req_int_rate
STD_ACCT
SAVINGS_ACCT
int_rate
add_on_interest prov_int_rate
50
Scenario 1
ACCOUNT
acct balance sec-code state
TRANS_REC
trans_type date-time amount teller_ID
withdrw dep
ATM
atm
req_withdrw req_dep
withdrw / deposit
create
51
Scenario 2
ACCOUNT
acct balance sec-code state
prov_balance
ATM
req_balance
prov_balance
52
ACCOUNT
Scenario 3
acct sec-code state
ATM
req_int_rate
SAVINGS_ACCT
int_rate
prov_int_rate
prov_int_rate
53

• HOW TO ?

Build Object model
54
Building an Object Model starts with
identifying Objects and Classes. Candidate
Objects and Classes can usually be found by
looking at the nouns in the problem statement
they can be physical entities as well as
concepts.
55

• Rules for Identifying Objects
• Objects ...
• Are actors. Objects can be viewed as actors that
  play a role in the system to be built. For
  example some of the actors on the stage of the
  purchasing system are the vendor, the purchaser,
  the purchase order and the purchase requisition.
• Are nouns. Objects often appear as nouns in
  problem descriptions.Example "A purchase order
  cannot be created until a purchase requisition is
  received."
• Have Uniqueness. Objects can be uniquely
  defined. That is instances of one object can be
  differentiated from another. For example, a
  person can be male or female. By contrast money
  has no distinguishing attributes. It only takes
  on importance as an attribute of some object for
  example a bank account.
• Have attributes. Objects can be described by one
  or more attributes. To be distinguishable from
  one another, objects must have attributes. For
  example, one automobile is distinguished from
  another by model, make, colour etc.
• Are data stores. Objects are the data stores in
  a data flow diagram.

56
(No Transcript)
57

• An object can be
• A tangible thingsomething you can
  touchExample plane, car, truck, purchase order,
  person, book, invoice, target
• A rolethe purpose or assignment of a person,
  item of equipment or organisationExample
  operator, customer, pilot, vendor, purchaser,
  scheduler
• An incidentsomething that happensExample
  delivery, attack, landing, telephone call,
  accident
• An interactionobjects that result from
  associations between other objectsExample A
  purchase results from the association of a vendor
  and a customer.
• A specificationa representation of rules,
  standards or criteriaExample recipe, articles
  of association, quality criteria

58
ATM Problem Statement
Design the software to support a
computerized banking network including both human
cashiers and automatic teller machine (ATMs) to
be shared by a consortium of banks. Each bank
provides its own computer to maintain its own
accounts and process transactions against them.
Cashier stations are owned by individual banks
and communicate directly with their own bank's
computers. Human cashiers enter account and
transaction data. Automatic teller machines
communicate with a central computer which clears
transactions with the appropriate banks.
An automatic teller machine
accepts a cash card, interacts with the user,
communicates with the central system to carry out
the transaction, dispenses cash, and prints
receipts. The system requires appropriate
recordkeeping and security provisions. The system
must handle concurrent accesses to the same
account correctly. The banks will provide their
network. The cost of the shared system will be
apportioned to the banks according to the number
of customers with cash cards.
59
ATM Problem Statement(SOLUTION)
Design the software to support a
computerized banking network including both human
cashiers and automatic teller machine (ATMs) to
be shared by a consortium of banks. Each bank
provides its own computer to maintain its own
accounts and process transactions against them.
Cashier stations are owned by individual banks
and communicate directly with their own bank's
computers. Human cashiers enter account and
transaction data. Automatic teller machines
communicate with a central computer which clears
transactions with the appropriate banks.
An automatic teller machine
accepts a cash card, interacts with the user,
communicates with the central system to carry out
the transaction, dispenses cash, and prints
receipts. The system requires appropriate record
keeping and security provisions. The system must
handle concurrent accesses to the same account
correctly. The banks will provide their network.
The cost of the shared system will be apportioned
to the banks according to the number of customers
with cash cards.
60
(No Transcript)
61
The correct Classes can be detected by following
the next guidelines
62
1. Discard redundant Classes customer and user
are redundant , customer is retained because it
is more descriptive
63
2. Discard irrelevant Classesapportioning cost
is outside the scope of the ATM transaction
software
64
3. Discard vague Classesrecord keeping is vague
in ATM problem , this is part of transaction
65
4. Do not model Attributes as Classes account
data is under specified but in any case probably
describes an account
66
5. Do not model Operations as Classes if we are
simply building telephones , then Call is part of
the dynamic model not an object class
67
6. Do not model implementation constructscommuni
cations links can be shown as associationscommuni
cation line is simply the physical
implementation of such a link
68
7. Do not model roles that objects play the
proper class is person(or possibly customer ,
which assumes various different roles such as
owner and driver.
69
(No Transcript)
70
Initial Object Diagram for ATM
Consortium
Bank
Account
Customer
71
After identifying Objects and Classes the
necessary Associations between Classes can be
identified . Associations can often be found by
looking at the verbs or verb phrases in the
problem statement.
72
1. Physical location next topart ofcontained in
73
2. Directed action drives
74
3. Communicationtalks to
75
4. Ownership haspart of
76
5. Satisfaction of some condition works for
married tomanages
77
Associations guide-lines

• 1 Review the concept of associations.
• 2 Identify verb phrases in problem statements,
  requirement statements, business rules and
  concepts of operation. For example
• a customer purchases a book (classcustomer,
  book associationpurchases)
• a customer complains about a product(classcustome
  r, product associationcomplains about)
• 3 Eliminate irrelevant associations that area)
  Outside the problem domainb) Specify
  implementation approaches (e.g. the transaction
  takes a record lock)

78
4 Discard actions. Associations describe class
structure not transient events. For example
"accountant creates a credit note" describes an
action on a credit note it does not imply an
association between accountant and credit note
that needs to be recorded. 5 Omit derived
associations. Omit associations that can be
defined in terms of other associations. For
example, given the business rule, "a credit note
is issued on an invoice for validated customer
complaints", an association need not be defined
between complaint and invoice. It is redundant as
it can be derived by identifying the credit note
the complaint was associated with and accessing
the related invoice from the is issued on
association.
79
(No Transcript)
80
6 Identify associative classes. 7 Define the
cardinality of the association
81
(No Transcript)
82
From David Brown Book Establishing the
cardinality sentence subject verb number
object customer buys many
products
83
ATM example Verb phrases Banking network
includes cashiers and ATMs Consortium shares
ATMs Bank provides bank computer Bank computer
maintains accounts Bank computer processes
transaction against account Bank owns cashier
station Cashier enters transaction for
account Cashier station communication with bank
computer ATM accepts cash card ATM interacts
with user ATM dispenses cash ATM prints receipts
System handles concurrent access Banks provide
software Cost apportioned to banks
84
Implicit verb phrases Consortium
consists of bank Bank holds account Consortium
owns central computer System provides record
keeping System provides security Customers have
cash cards Knowledge of problem domain Cash
card accesses accounts Bank employs cashiers
85
For keeping the correct associations the next
guidelines have to be applied
86
1. Discard associations between Classes that are
eliminated .ATM case we can eliminateBanking
network includes cashiers and ATMsCost
apportioned to banksATM prints receipts ATM
dispenses cashSystem provides record keeping
System provides security Banks provide software

87
2. Discard implementation associations System
handles concurrent access is an implementation
concept
88
3. Don't model actionswe can eliminate ATM
accepts cash carddescribes part of the
interaction cycle between an ATM and a
customerATM interacts with user
89
4. Decompose ternary associations if possible
into binary associations Cashier enters
transaction for account can be broken into
Cashier enters transaction andtransaction
concerns account
90
5. Don't model associations that can be derived
Consortium shares ATMs is a composition of the
associationsconsortium owns central
computerandcentral computer communicates with
ATMs
91
Notes

• Be careful not all associations from multiple
  paths between classes indicate redundancy.
• Although derived associations do not add
  information , they are useful in the real world
  and in design, they should be drawn using dotted
  lines.

92
Next the identified associations have to be
refined applying the next guidelines
93
1. Find a good name for every association bank
computer maintains accountsis a statement of
action rephrase as bank holds account
94
2. Add role names to associations if this is
necessary in the works-for associationcompany
has the role employer and person has the role
employee
95
3. Use qualified associations whenever possible
The context combines with the name to uniquely
identify the objectThe qualifier bank code
distinguishes the different banks in a consortium
96
4. Specify multiplicity (cardinality) of
associations
97
5. Find missing associationscashier authorized
on cashier station is needed if cashiers are
restricted to specific stations
98
Identify Associations
Consortium
Bank
Account
Customer
Holds
99
The next step is identifying Attributes
.Attributes can usually be found in nouns with
possessive phrases and adjectives. For derived
Attributes it's important to either label them as
derived, or discard them. Link Attributes also
have to be identified. Guidelines for
identifying Attributes
100
Identifying
attributes Identify the characteristics that are
common to all possible instances of objects in
the class. Types of Attribute Candidate key A set
of one or more attributes that uniquely
distinguishes one instance of an object from
another. For example, an invoice
number. Descriptive attributes Facts intrinsic
to each instance of the object. For example,
invoice date and invoice total. Referential
attributes An attribute that ties an instance of
one object to an instance of another. For
example, customer code.
101
(No Transcript)
102

• Rules for Identifying Attributes
• Single valued. One instance of an object has
  exactly one value of each attribute at any given
  instant in time
• Atomic. An attribute is atomic - cannot be
  described by other attributeslegal attribute
  phone-numberillegal attribute shipping address
  street-address, city, postcode
• Uniquely identify the object. A set of attributes
  (the candidate key) must uniquely identify all
  instances of the objectlegal candidate key
  customer-codeillegal candidate key last-name
• A property of the object. Each non-candidate key
  attribute is a characteristic of the instance
  named by the candidate key and not of some other
  non-candidate key attributelegal attributes
  invoice invoice-number invoice-date
  customer-code illegal attribute
  (street-address) invoice invoice-number
  invoice-date customer-code street-address
  Note that street-address is an attribute of
  customer not invoice.

103
1. Don't model Objects as Attributes boss is an
object and salary is an attribute
104
2. Use qualifiers wherever possible (names can
often be modeled as qualifier) employee number
is not a unique property of person with two
jobs it qualifies the associationcompany
employs person
105
Names Are Often Better Modeled As Qualifiers
Rather Than Object Attributes
106
3. Don't model identifier attributes that are
made to identify (For example 'Person ID')
107
4. Model link Attributes
108
5. Don't model internal values (states) of an
Object
109
6. Don't model fine details
110
7. Discordant attributes Attributes that are
very different from other Attributes of an Object
often indicate the need for adding a new Class
111
Identify Attributes
Consortium
Bank
Account
Customer
Holds
account-code balance credit limit account type
bank code bank name
112
Using Inheritance to organize the Class
Hierarchy can refine Object Classes. Common
aspects of Classes like Attributes, Operations or
Associations can be generalized into Super
classes and existing Classes can be specialized
into Subclasses. Specialization can be found in
noun phrases with adjectives. Multiple
Inheritance is also possible but should only be
used if it is really necessary.
113
Generalization bottom - up specialization top
- down
114
Top down specialization are often apparent from
the application domain like fixed-menu pop-menu s
liding-menu remember brown notations canbea and
isakinda
115
Remote transaction and cashier transaction are
similar and can be generalized by transaction
116
To control the adequateness of the Object Model
it is recommended to test several access paths
through the Object model to find missing and
unnecessary Classes, missing and unnecessary
Associations and incorrect placement of
Associations and Attributes.
117
The last step for building the Object model is
the grouping of sets of Classes that capture a
logical subset of the model into Modules For
grouping Classes the analyst should look at cut
points between Classes. The number of bridges
between Classes in different Modules should be
minimized.For grouping Classes into Modules it
is possible to look at earlier made Modules, it
may be possible to reuse previous made Modules.
118
ATM modules examples are tellers cashier ,
entry station , cashier , ATM banks consortium ,
bank
119
Determine Generalization and Aggregation
Consortium
Bank
Account
Customer
Holds
account-code balance credit-limit account-type
bank-code bank-name
120
(No Transcript)
121
(No Transcript)