Module-6

Object-Oriented Analysis Process

Faculty: R Kiruba Thangam

RKT_Fall 2023 1 Faculty : R Kiruba Thangam

 Analysis
 Analysis is the process of transforming a
problem definition from a fuzzy set of facts
into a statement of a system’s requirements.
 Analysis involves:
 Identification of users who will be affected by
the system.
 Analysis is understanding the problem, its
associated constraints and methods
RKT_Fall 2023 2 Faculty : R Kiruba Thangam
 Analysis
 Analysis have following steps:
 Examination of existing system documentation
 Interviews
 Questionnaire
 Observation
 These activities must be done using use-case
model which captures,
 The user requirements
 The input to the system

RKT_Fall 2023 3 Faculty : R Kiruba Thangam

 Sources of requirement difficulties
 Three Fuzzy descriptions
 Fast response time, very easy and very
secure
 Incomplete requirements
 Necessary requirements not included due
to some reasons like forgetting to identify
the mand policies.
 Unnecessary features
 Every additional features affect the
performance,complexity,stability,cost

RKT_Fall 2023 4 Faculty : R Kiruba Thangam

 Use-case driven object-oriented
analysis: The unified approach
 OOA phase of the unified approach uses
actors and use cases to describe the
system.
 The actor is an external factors that
interact with the system.
 Use cases are scenarios that describes how
actors use the system.
RKT_Fall 2023 7 Faculty : R Kiruba Thangam
 OOA process steps
1) Identify the actors:
 Who is using the system
 For new system, who is going to use the system
2) Develop a simple business process model using
UML activity diagram
3) Develop the use case:
 What are the users doing with the system
 Or, what will users be doing with the system
 Use cases provide us with documentation of the
system under study

RKT_Fall 2023 8 Faculty : R Kiruba Thangam

 Use-case driven object-oriented
analysis: The unified approach
4) Prepare interaction diagrams:
 Determine the sequence
 Develop collaboration diagrams
5) Classification: develop UML class diagram:
 Identify classes
 Identify relationships
 Identify attributes
 Identify methods
6) Iterate and refine: if needed repeat the steps
RKT_Fall 2023 9 Faculty : R Kiruba Thangam
 Object Oriented Analysis Process in
the Unified Process

Develop Use- Develop Identify Classes,

Cases, ADs Refine
Interaction Relationships, and
Diagrams Attributes & iterate
Identify Actors prototyping Methods

O-O Analysis

RKT_Fall 2023 10 Faculty : R Kiruba Thangam

 Business Process Modeling
 Developing an activity diagram of the
business processes can provide us with an
overall view of the system.

RKT_Fall 2023 11 Faculty : R Kiruba Thangam

 Use case modeling
 Use cases are scenarios for understanding
system requirements.
 Use case is an interaction between users and a
system.
 It represents the goal of the user and the
responsibility of the system to its users.
 Also describes uses of the system and the set
of events that can be performed by the
system.
 Use case must have a name and short textual
representation of not more than few
paragraphs.
RKT_Fall 2023 12 Faculty : R Kiruba Thangam
 Some Definitions

 User – Human Users + Other Systems

 Use Case – A piece of functionality
 Use-Case Model – All the use cases
 Use-Case Driven – Development process follows
a flow

RKT_Fall 2023 13 Faculty : R Kiruba Thangam

 Use cases under the microscope
 Definition given by Jacobson:
 A use case is a sequence of transactions in a
system whose task is to yield results of
measurable value to an individual actor of
the system.

RKT_Fall 2023 14 Faculty : R Kiruba Thangam

 Use Case Key Concepts
Use case. Use case is a special flow of
events through the system.
Actors. An actor is a user playing a
role with respect to the system.
In a system. This simply means that
the actors communicate with the
system's use case.

RKT_Fall 2023 15 Faculty : R Kiruba Thangam

 Use Case Key Concepts (Con’t)
A measurable value. A use case must
help the actor to perform a task that
has some identifiable value.
Transaction. A transaction is an
atomic set of activities that are
performed either fully or not at all.

RKT_Fall 2023 16 Faculty : R Kiruba Thangam

 Key words of the use case
 Use case:
 Flow of events.
 Many courses of events can be grouped together.
 Many use cases can be grouped together to manage
complexities and to reduce number of use cases.
 Ex:
 Borrowing the book depends on whether book is
available and whether you are the member of the
library.
 Simple use cases can be grouped together.
RKT_Fall 2023 17 Faculty : R Kiruba Thangam
 Types of Use Cases
Use cases could be viewed as concrete
or abstract.
An abstract use case is not complete
and has no initiation actors but is
used by a concrete use case, which
does interact with actors.

RKT_Fall 2023 18 Faculty : R Kiruba Thangam

  Actors:
 An actor is the user who uses the system.
 A single actor can perform many use cases.
 A single use case can have many actors.
 An actor can be an external system which needs some
information from the system.
 A measurable value:
 A use case must help the actor to perform a task that
has some identifiable value.
 The performance of the use case in terms of cost or
price
 Transaction:
 An atomic set of activities performed either fully or
not at all.
 Can be triggered by the user or any other external
system.
RKT_Fall 2023 19 Faculty : R Kiruba Thangam
 Identifying the actors
 Actor represents the role a user plays with
respect to the system.
 A user must play more than one role
 A person can be member of an library and
also a customer of a bank.
 We have to identify the actors and the
interaction with the system.
RKT_Fall 2023 20 Faculty : R Kiruba Thangam
 Actors
 Actors can be found through:
 Who is using the system? or who is affected by the
system? Or which group need help from the system to
perform a task?
 Who affects the system? Or which user groups are
needed by the system to perform its functions?
 Which external hardware or other system use the
system?
 What problems does this application solve?
 Finally, how do users use the system?
 What are they doing with the system?
RKT_Fall 2023 21 Faculty : R Kiruba Thangam
 Actors
 An actor need not to be human.
 An actor also can be an external system.

RKT_Fall 2023 22 Faculty : R Kiruba Thangam

 Guidelines for finding use cases
 Steps:
 For each actor. Identify the tasks that actor can
able to perform or the system expects the task
from that actor.
 Name the use cases
 Describe the use case with user familiar terms.
 Actors represent a role that one or several
users can play
 Ex: employee is an actor.John,Ram..are users
RKT_Fall 2023 23 Faculty : R Kiruba Thangam
  Each use case should have only one main
actor. To achieve this,
 Isolate users from actors
 Isolate actors from other actors
 Isolate use cases that have different initiating
actors and slightly different behavior.

RKT_Fall 2023 24 Faculty : R Kiruba Thangam

 Use Associations
The use association occurs when you
are describing your use cases and
notice that some of them have
common subflows.
The use association allows you to
extract the common subflow and
make it a use case of its own.

RKT_Fall 2023 25 Faculty : R Kiruba Thangam

 Extends Associations
The extends association is used when
you have one use case that is similar
to another use case but does a bit
more or
Is more specialized; in essence, it is
like a subclass.

RKT_Fall 2023 26 Faculty : R Kiruba Thangam

 Naming a use case
 Should provide a general description of
the use-case model.
 The name should describe what happens.
 Name should be active
 Name should be verb(Borrow) or verb
and noun (Borrow books).
 The description should be consistent.
RKT_Fall 2023 27 Faculty : R Kiruba Thangam
 Guidelines for developing effective
documentation
 Common cover:
All documents should share a common cover
sheet that identifies the document, the current
version and the individual responsible for the
content.
The changes in the individual responsibility
should be reflected in the cover.
 80-20 rule:
80 percent of the work can be done with 20
percent of the documentation.

RKT_Fall 2023 31 Faculty : R Kiruba Thangam

  Familiar vocabulary:
 Use the vocabulary that your readers
understands.
 Make the document as short as possible:
 Repetition should be removed.
 Presents summaries,reviews, organization
chapters in less than three pages.
 The chapter headings should be task oriented so
that the table of contents can be an index.
RKT_Fall 2023 32 Faculty : R Kiruba Thangam
 Object Analysis: Classification
Faculty :R Kiruba Thangam

RKT_Fall 2023 33 Faculty : R Kiruba Thangam

 Introduction
 OOA is a process by which we can identify classes
that play a role in achieving system goals and
requirements.

 Identification of classes is the hardest part of OOA

and OOD.

RKT_Fall 2023 34 Faculty : R Kiruba Thangam

 ... Intelligent classification is
intellectually hard work, and it best
comes about through an incremental
and iterative process
***Booch***

RKT_Fall 2023 35 Faculty : R Kiruba Thangam

 ..There is no such thing as the perfect
class structure, nor the right set of
objects. As in any engineering
discipline, our design choice is
compromisingly shaped by many
competing factors.

RKT_Fall 2023 36 Faculty : R Kiruba Thangam

 Classifications Theory
 Classification
The process of checking to see if an object belongs to a category
or a class, is regarded as a basic attribute of human nature.
Example: Classifying the car

RKT_Fall 2023 37 Faculty : R Kiruba Thangam

 Point To Remember
Two Issues
A class is a specification of structure,
behavior, and the description of an
object.
Classification is more
concerned with identifying
classes than identifying the
individual objects in a system.
RKT_Fall 2023 38 Faculty : R Kiruba Thangam
 The Challenge of Classification

Intelligent classification is
intellectually hard work and may
seem rather arbitrary.
Martin and Odell have observed in
object-oriented analysis and
design, that
“In fact, an object can be categorized in
more than one way.”
RKT_Fall 2023 39 Faculty : R Kiruba Thangam
 The same object Betty can be classified in many ways

Employer Employee

Pet Owner Good Credit Risk

RKT_Fall 2023 40 Faculty : R Kiruba Thangam

 Approaches for Identifying Classes
1. The noun phrase approach.
2. The common class patterns approach.
3. The use-case driven approach.
4. The class responsibilities collaboration
(CRC) approach.

RKT_Fall 2023 41 Faculty : R Kiruba Thangam

 Noun Phrase Approach
Using this method, you have to read
through the Use cases, interviews, and
requirements specification carefully,
looking for noun phrases.

RKT_Fall 2023 42 Faculty : R Kiruba Thangam

 Noun Phrase Strategy (Con’t)
Change all plurals to singular and
make a list, which can then be
divided into three categories.

RKT_Fall 2023 43 Faculty : R Kiruba Thangam

 Noun Phrase Strategy (Con’t)
It is safe to scrap the Irrelevant
Classes.
You must be able to formulate a
statement of purpose for each
candidate class; if not, simply
eliminate it.
You must then select candidate
classes from the other two categories.
RKT_Fall 2023 44 Faculty : R Kiruba Thangam
 Guidelines For Identifying Classes

 Look for nouns and noun phrases in

the problem statement.
 Some classes are implicit or taken
from general knowledge.

RKT_Fall 2023 45 Faculty : R Kiruba Thangam

 Guidelines For Identifying Classes
(Con’t)
All classes must make sense in the
application domain.
 Avoid computer implementation classes,
defer it to the design stage.
Carefully choose and define class names.

RKT_Fall 2023 46 Faculty : R Kiruba Thangam

 Guidelines For Refining Classes

Redundant Classes:
Do not keep two classes that express
the same information.
If more than one word is being
used to describe the same idea,
select the one that is the most
meaningful in the context of the
system.

RKT_Fall 2023 47 Faculty : R Kiruba Thangam

 Guidelines For Refining Classes
(Con’t)
Adjective Classes:
Does the object represented by the noun
behave differently when the adjective is
applied to it?

RKT_Fall 2023 48 Faculty : R Kiruba Thangam

 Guidelines For Refining Classes
(Con’t)
If the use of the adjective signals that the
behavior of the object is different, then
make a new class.
For example, If Adult Membership and
Youth Membership behave differently,
than they should be classified as different
classes.
RKT_Fall 2023 49 Faculty : R Kiruba Thangam
 Guidelines For Refining Classes
(Con’t)
Attribute Classes:
Tentative objects which are used only
as values should be defined or
restated as attributes and not as a
class.
For example the demographics of
Membership are not classes but
attributes of the Membership class.
RKT_Fall 2023 50 Faculty : R Kiruba Thangam
 Guidelines For Refining Classes
(Con’t)
Irrelevant Classes:
Each class must have a purpose and
every class should be clearly defined
and necessary.
If you cannot come up with a
statement of purpose, simply
eliminate the candidate class.
RKT_Fall 2023 51 Faculty : R Kiruba Thangam
 Identifying a list of candidate classes

 Take a coherent, concise statement of the

requirement of the system
 Underline its noun and noun phrases, that is,
identify the words and phases the denote things
 This gives a list of candidate classes, which we can
then whittle down and modify to get an initial
class list for the system
RKT_Fall 2023 52 Faculty : R Kiruba Thangam
 In this particular case we discard
 Library, because it is outside the scope of our system
 Short term loan, because a loan is really an event, which
so far as we know is not a useful object in this system
 Member of the library, which is redundant
 Week, because it is a measure, not a thing
 Item, because it is vague (we need to clarify it)
 Time, because it is outside the scope of the system
 System, because it is part of the meta-language of
requirements description, not a part of domain
 Rule, for the same reason

RKT_Fall 2023 53 Faculty : R Kiruba Thangam

 This leaves:
 Book
 Journal
 Copy (of book)
 Library member
 Member of staff

RKT_Fall 2023 54 Faculty : R Kiruba Thangam

 Case study
 Refer Text book Pg:156-161

RKT_Fall 2023 55 Faculty : R Kiruba Thangam

 Common Class Patterns Approach
This approach is based on the knowledge-
base of the common classes that have
been proposed by various researchers.

RKT_Fall 2023 56 Faculty : R Kiruba Thangam

 Candidate Classes - Concepts
Concepts are principles or ideas not
tangible but used to organize or keep
track of
business activities and/or
communications.

RKT_Fall 2023 57 Faculty : R Kiruba Thangam

 Candidate Classes - Concepts
 Privately held ideas are called
conceptions.
 When an understanding is shared by
another,it becomes a concept.
 To communicate with others we must
share our individually held conceptions
and arrive at agreed concepts.
RKT_Fall 2023 58 Faculty : R Kiruba Thangam
 Example
 Performance

RKT_Fall 2023 59 Faculty : R Kiruba Thangam

 Candidate Classes - Events
These are points in time that must be
recorded and remembered.
Things happen, usually to something
else, at a given date and time, or as a
step in an ordered sequence.

RKT_Fall 2023 60 Faculty : R Kiruba Thangam

 Candidate Classes - Events
 Associated with things remembered are
attributes such as
who,what,when,where,how or why.

RKT_Fall 2023 61 Faculty : R Kiruba Thangam

 Example-Possible events
 Order
 Landing
 Interrupt
 request

RKT_Fall 2023 62 Faculty : R Kiruba Thangam

 Candidate Classes - Organization
An organization class is a collection
of people,resources,facilities,or
groups to which the user belongs.
The organizational units that people
belong to.
.

RKT_Fall 2023 63 Faculty : R Kiruba Thangam

 Candidate Classes - Organization
 For example, accounting department
might be considered as a potential class
 Bank
 COE
 Library

RKT_Fall 2023 64 Faculty : R Kiruba Thangam

 Candidate Classes – People
class(Person,Roles and Roles Played
class )
The different roles users play in
interacting with the application.

RKT_Fall 2023 65 Faculty : R Kiruba Thangam

 Candidate Classes - People (Con’t)
 It can be divided into two types (Coad &
Yourdon):
 Those representing users of the system,
such as an operator, or a clerk;
 Two types:
the users of the system (operator or
clerk) or who interacts with the system.
Who do not use the system but whom
information is kept by the system.
RKT_Fall 2023 66 Faculty : R Kiruba Thangam
 Candidate Classes - People (Con’t)

Those people who do not use the

system but about whom information
is kept.

 Some examples are Client, Employee,
Teacher, Manager.

RKT_Fall 2023 67 Faculty : R Kiruba Thangam

 Candidate Classes - Places

These are physical locations that the

system must keep information about.
Ex:
 buildings, stores, sites or offices that the
system must keep

RKT_Fall 2023 68 Faculty : R Kiruba Thangam

 Candidate Classes - Tangible Things
and Devices
Physical objects, or group of objects, that
are tangible, and devices with which the
application interacts.

For example, cars, pressure

sensors,printer etc..

RKT_Fall 2023 69 Faculty : R Kiruba Thangam

 Use-case Driven Approach:Identifying classes
& behaviors through sequence /collaboration
modeling

 Once the system has been described in

terms of its scenarios, we can examine
the textual description or steps of each
scenario to determine what objects are
needed for the scenario to occur.

RKT_Fall 2023 70 Faculty : R Kiruba Thangam

 Case study
 Refer Text book Pg:163

RKT_Fall 2023 71 Faculty : R Kiruba Thangam

 Use-case Driven Approach
 To identify objects of a system and
their behaviors, the lowest level of
executable use cases is further
analyzed with a sequence and
collaboration diagram pair.
By walking through the steps, you
can determine what objects are
necessary for the steps to take place.
RKT_Fall 2023 72 Faculty : R Kiruba Thangam
 Sequence Diagram Notation
Actor

Class

Synchronous message

Asynchronous message

Focus of Control

Return message

Termination
lifeline

RKT_Fall 2023 73 Faculty : R Kiruba Thangam

 The sequence diagram for the Invalid
PIN use case.

RKT_Fall 2023 74 Faculty : R Kiruba Thangam

 Sequence diagram for the withdraw
Checking use case.

RKT_Fall 2023 75 Faculty : R Kiruba Thangam

 The collaboration diagram for the
withdraw checking use-case.

RKT_Fall 2023 76 Faculty : R Kiruba Thangam

 COLLABORATION DIAGRAM
A Collaboration is a name given to the
interaction among two or more
classes\objects.
Collaboration Diagram show
 objects and their links to each other, as
well as
 how messages are sent between the linked
objects.
RKT_Fall 2023 77 Faculty : R Kiruba Thangam
 COLLABORATION DIAGRAM CONT.,

 Collaboration shows
 the implementation of an operation or
 the realization of a use case.
 The focus here is on Message.(Hence
numbered)
 The focus on message means that they
focus on object roles instead of time, and
therefore explicitly shown in the diagram.
RKT_Fall 2023 78 Faculty : R Kiruba Thangam
 COLLABORATION DIAGRAM

RKT_Fall 2023 79 Faculty : R Kiruba Thangam

 COLLABORATION DIAGRAM - PURPOSE

 Collaboration Diagrams are useful when

we want to refer to a particular interaction.

 To illustrate the coordination of object

structure and flow of control.

RKT_Fall 2023 80 Faculty : R Kiruba Thangam

 COLLABORATION DIAGRAM VS SEQUENCE
DIAGRAM

Both show the interaction between the

objects\classes.
If time is the most important aspect to
emphasize, choose sequence diagrams.
If the role is the most important aspect
to emphasize, choose collaboration
diagram
RKT_Fall 2023 81 Faculty : R Kiruba Thangam
 Case study
 Refer Text book Pg:165-169

RKT_Fall 2023 82 Faculty : R Kiruba Thangam

 CRC Cards
CRC stands for Class, Responsibilities
and Collaborators developed by
Cunningham, Wilkerson and Beck.
CRC can be used for identifying classes
and their responsibilities.

RKT_Fall 2023 83 Faculty : R Kiruba Thangam

 Process of the CRC Technique

Identify
Classes
responsibility

Iterate

Identify Assign
Collaboration responsibility

RKT_Fall 2023 84 Faculty : R Kiruba Thangam

 Classes, responsibilities and
collaborators process
 Three steps:
 Identify classes’s and classe’s responsibilities
 Assign responsibilities
 Identify collaborators

RKT_Fall 2023 85 Faculty : R Kiruba Thangam

 CRC
 Classes are identified and grouped by
common attributes.
 The class names are written onto classes,
responsibilities and collaborators cards.
 The class also notes sub and super classes to
show the class structure.
 The requirements are examined for actions
and information associated with each class to
find the responsibilities of each class.

RKT_Fall 2023 86 Faculty : R Kiruba Thangam

 CRC
 The responsibilities should be as general
as possible.
 Locating collaborators is to identify how
classes interact.

RKT_Fall 2023 87 Faculty : R Kiruba Thangam

 Collaborations

An object can accomplish either a

certain responsibility itself, or it may
require the assistance of other
objects.
If it requires an assistance of other
objects, it must collaborate with
those objects to fulfill
its responsibility.
RKT_Fall 2023 88 Faculty : R Kiruba Thangam
 CRC Cards (Con’t)
CRC cards are 4" x 6" index cards.
All the information for an object is
written on a card.

ClassName
... Collaborators

...
Responsibilities

RKT_Fall 2023 89 Faculty : R Kiruba Thangam

RKT_Fall 2023 90 Faculty : R Kiruba Thangam
RKT_Fall 2023 91 Faculty : R Kiruba Thangam
 CRC
 All the information for an object is written on
a card which is cheap,portable, readily
available and familiar.
 Class name should appear in the left-hand
corner.
 A bullet list of responsibilities should appear
under it in the left two thirds of the card.
 The list of collaborators should appear in the
right third.

RKT_Fall 2023 92 Faculty : R Kiruba Thangam

 CRC Cards (Con’t)

CRC starts with only one or two obvious

cards.
If the situation calls for a responsibility
not already covered by one of the objects:
 Add, or
 Create a new object to address that
responsibility.

RKT_Fall 2023 93 Faculty : R Kiruba Thangam

 Guidelines for Naming Classes
The class should describe a single
object, so it should be the singular
form of noun.
Use names that the users are
comfortable with.
The name of a class should reflect its
intrinsic nature.

RKT_Fall 2023 94 Faculty : R Kiruba Thangam

 Guidelines for Naming Classes (Con’t)
By the convention, the class name must
begin with an upper case letter.
 For compound words, capitalize the first
letter of each word - for example,
LoanWindow.

RKT_Fall 2023 95 Faculty : R Kiruba Thangam

 Case study
 Refer Text book Pg:171

RKT_Fall 2023 96 Faculty : R Kiruba Thangam

 Identifying object relationships,
attributes and methods

RKT_Fall 2023 97 Faculty : R Kiruba Thangam

  Three types of relationships:
 Associations: how are objects associated?
 Super-sub structure: how are objects
organized into super classes and subclasses?
 Aggregation and a-part-of structure: what is
the composition of complex classes?

RKT_Fall 2023 98 Faculty : R Kiruba Thangam

 Associations
 Association represents a physical or
conceptual connection between two or more
objects.
 Its shown as line connecting two objects.
 Association name is written above or below
the line.
 The association name can be omitted if the
relationship is obvious.
 Role name also be specified.
RKT_Fall 2023 99 Faculty : R Kiruba Thangam
 Association

RKT_Fall 2023 100 Faculty : R Kiruba Thangam

 Identifying associations
 Identifying associations begins by analyzing
the interactions between classes.
 Questions can be asked to identify
associations:
 Is the class capable of fulfilling task by itself?
 If not, what does it need?
 From what other class can it acquire what it
needs?
RKT_Fall 2023 101 Faculty : R Kiruba Thangam
 Guidelines for identifying
associations
 A dependency between two or more classes
may be an association.
 It often corresponds to a verb or
propositional phrase such as part of, next to,
work for or contained in.
 A reference from one class to another is an
association.
 Some association are implicit and taken from
general knowledge.

RKT_Fall 2023 102 Faculty : R Kiruba Thangam

 Common association patterns
 Location association: next to, part of,
contained in.
 Communication association: talk to,
order to. For example customer places an
order with an operator person.

RKT_Fall 2023 103 Faculty : R Kiruba Thangam

 Eliminate unnecessary associations
 Implementation association.
 Defer implementation-specific associations to the
design phase.
 Ternary associations.
 Ternary or n-ary association is an association among
more than two classes. They complicate the
representation. So restate with binary associations.
 Directed actions (derived) associations :
 can be defined in terms of other associations. Since
they are redundant you should avoid these types of
association.
RKT_Fall 2023 104 Faculty : R Kiruba Thangam
 Eliminate Unnecessary Associations
(Con’t)

RKT_Fall 2023 105 Faculty : R Kiruba Thangam

 Superclass-Subclass Relationships
 Recall that at the top of the class
hierarchy is the most general class, and
from it descend all other, more specialized
classes.
 Sub-classes are more specialized versions
of their super-classes.

RKT_Fall 2023 106 Faculty : R Kiruba Thangam

 Guidelines For Identifying Super-sub
Relationships
 Top-down
 Look for noun phrases composed of various
adjectives on class name.
 Example: Military Aircraft and Civilian
Aircraft.
 Only specialize when the sub classes have
significant behavior.

RKT_Fall 2023 107 Faculty : R Kiruba Thangam

  Bottom-up
 Look for classes with similar attributes or
methods.
 Group them by moving the common
attributes and methods to super class.
 Do not force classes to fit a preconceived
generalization structure.

RKT_Fall 2023 108 Faculty : R Kiruba Thangam

  Reusability
 Move attributes and methods as high as possible
in the hierarchy.
 At the same time do not create very specialized
classes at the top of hierarchy.
 This balancing act can be achieved through
several iterations.
 This process ensures that you design objects that
can be reused in another application
RKT_Fall 2023 109 Faculty : R Kiruba Thangam
 A-part-of Relationships -
Aggregation
 A-part-of relationship, also called
aggregation, represents the situation where a
class consists of several component classes.
 This does not mean that the class behaves like
its parts.
 For example, a car consists of many other
classes, one of them is a radio, but a car does
not behave like a radio.
RKT_Fall 2023 112 Faculty : R Kiruba Thangam
 Example:aggregation

RKT_Fall 2023 113 Faculty : R Kiruba Thangam

 A-part-of Relationships -
Aggregation
 Two major properties of a-part-of relationship
are:
Transitivity
 If A is part of B and B is part of C, then A is part of C.
 For example, a carburetor is part of an engine and an
engine is part of a car; therefore, a carburetor is part
of a car.
Antisymmetry
 If A is part of B, then B is not part of A.
 For example, an engine is part of a car, but a car is
not part of an engine.
RKT_Fall 2023 114 Faculty : R Kiruba Thangam
 A house is a container

RKT_Fall 2023 116 Faculty : R Kiruba Thangam

 A-part-of Relationships Patterns
Assembly
 An assembly is constructed from its parts.
 An assembly-Part situation physically exists.
 For example, a French soup consists of onion, butter,
flour, wine, French bread, cheddar cheese, etc.
Container
 A physical whole encompasses but is not constructed
from physical parts.
 For example, a house can be considered as a container
of furniture and appliances.
RKT_Fall 2023 117 Faculty : R Kiruba Thangam
 A football team is a collection of
players

RKT_Fall 2023 118 Faculty : R Kiruba Thangam

 Aggregation-Guidelines
Collection
 A conceptual whole encompasses parts that
may be physical or conceptual.
 For example, a football team is a collection of
players.

RKT_Fall 2023 119 Faculty : R Kiruba Thangam

 Identifying attributes and methods
 The responsibilities of a class is represented
by short verb phrases, each containing active
verb.
 Attributes are like color, cost and
manufacturer.
 System responsibilities can be identified by
developing use cases and the characteristics
of an application such as determining user
needs.
RKT_Fall 2023 120 Faculty : R Kiruba Thangam
  Questions to identify the responsibility of
classes:
 What information about an object should we
kept track of? (attributes)
 What services must a class provide?
(methods)

RKT_Fall 2023 121 Faculty : R Kiruba Thangam

 Defining attributes by analyzing use
cases and other UML diagrams
 Attributes can be derived from scenario
testing.
 By analyzing use cases,
sequence/collaboration, activity and state
diagram we can understand class
responsibility and how they interact to
perform their tasks.
RKT_Fall 2023 122 Faculty : R Kiruba Thangam
  Questions to define attributes:
 How am I going to be used?
 How am I going to collaborate other classes?
 What do I need to know?
 What state information do I need to
remember over time?
 What states can I be in?

RKT_Fall 2023 123 Faculty : R Kiruba Thangam

 Guidelines for defining attributes
 Attributes usually correspond to nouns
followed by prepositional phrases such as cost
of the soup.
 May be an adjectives or adverbs.
 Keep the class simple: state only the enough
attributes to define the object state.
 Omit derived attributes. This should be
expressed as methods.
RKT_Fall 2023 124 Faculty : R Kiruba Thangam
 Defining methods by analyzing UML
diagrams and use cases
 In a sequence diagram, the events occur
between the objects are drawn between
the vertical object lines.
 An event is considered to be an action
that transmits information.
 These actions are operations that the
objects should perform.
RKT_Fall 2023 125 Faculty : R Kiruba Thangam
  Case study

RKT_Fall 2023 126 Faculty : R Kiruba Thangam

RKT_Fall 2023 127 Faculty : R Kiruba Thangam
RKT_Fall 2023 128 Faculty : R Kiruba Thangam
RKT_Fall 2023 129 Faculty : R Kiruba Thangam
RKT_Fall 2023 130 Faculty : R Kiruba Thangam
RKT_Fall 2023 131 Faculty : R Kiruba Thangam