SYBTech_2021_Patt_Unit 4 Object Oriented Analysis Part I.pdf

Object Oriented Analysis

1. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
OBJECT ORIENTED ANALYSIS
ObjectOrientedAnalysisProcess,UseCaseModeling:ActorIdentification,Actor
Classification,ActorGeneralization,UseCasesIdentification,Communication,Uses/Include
andExtendAssociations,WritingaFormalUseCases,UseCaserealizationsDomain/Class
Modeling:ApproachesForIdentifyingClasses(Noun-PhaseApproach,CommonClassPattern
Approach,ClassResponsibilitiesCollaborationApproach,NamingClasses,ClassAssociations
andIdentificationofAssociations,Generalization/SpecializationRelationship,Aggregationand
CompositionRelationships,AttributesandMethodsIdentification

2. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Object-oriented analysis and design
Object-oriented programming (OOP) is a method
based on the concept of “objects",
which are data structures that contain data,
in the form of fields, often known as attributes;
and code, in the form of procedures, often known as methods

3. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Object-oriented analysis and design
What is OOAD?-Object-oriented analysis and design (OOAD) is a
software engineering approach that models a system as a group of
interacting objects.
Analysis—understanding, finding and describing concepts in the problem
domain.
Design—understanding and defining software solution/objects that
represent the analysis concepts and will eventually be implemented in code.

4. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Object-oriented analysis and design
OOAD-A software development approach that emphasizes a logical
solution based on objects.
Software development is dynamic and always undergoing major change.
System development refers to all activities that go into producing
information system solution.

5. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Object-oriented analysis and design
System development activities consist of
system analysis,
modelling,
design,
implementation,
testing and maintenance.

6. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Object-oriented analysis and design
A software development methodology series of processes can
lead to the development of an application.
Practices, procedures, and rules used to develop software, totally based on
system requirements
Two Approaches
Traditional Approach
Objected-Oriented Approach

7. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Traditional Approach
Collection of programs or functions.
A system that is designed for performing certain actions.
Algorithms + Data Structures = Programs.
Software Development Models (Waterfall, Spiral, Incremental, etc..)

8. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Object Oriented Approach
OO development offers a different model from the traditional software
based on functions and procedures.
software is a collection of discrete object that encapsulate their data as
well as the functionality.
Each object has attributes (properties) and method (procedures).
software by building self contained modules or objects that can be easily
REPLACED, MODIFIED AND REUSED.
Objects grouped in to classes and object are responsible for itself.

9. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Object Oriented Approach
OO approach is more like creating a lot of helpers
take on an active role, a spirit, that form a community whose interactions
become the application.
Reusable
Modified
Replaced

10. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Examples Of Object Oriented Systems
In OO system , “everything is object”
A spreadsheet cell, bar chart, title in bar chart, report, numbers, arrays,
records, fields, files, forms, an invoice, etc.
A window object is responsible for things like opening, sizing, and closing
itself
A chart object is responsible for things like maintaining data and labels
even for drawing itself.

11. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Examples Of Object Oriented Systems
In OO system , “everything is object”
A spreadsheet cell, bar chart, title in bar chart, report, numbers, arrays,
records, fields, files, forms, an invoice, etc.
A window object is responsible for things like opening, sizing, and closing
itself
A chart object is responsible for things like maintaining data and labels
even for drawing itself.

12. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
WHAT IS AN OBJECT?
The term object was first formally utilized in the Simulalanguage to
simulate some aspect of reality.
Attributes or properties describe object‘s state (data) and methods
(properties or functions) define its behaviour.
An object is an entity.
It knows things (has attributes)
It does things (provides services or has methods)

13. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Use Case Modeling
In use-case modeling, the system is looked upon as a black box whose
boundaries are defined by its functionality to external stimuli.
The actual description of the use-case is usually given in plain text. A
popular notation promoted by UML is the stick figure notation
Both visual and text representation are needed for a complete view.
A use-case model represents the use-case view of the system
A use-case view of a system may consist of many Use-case diagrams.
An use-case diagram shows (the system), the actors, the use-cases and the
relationship among them.

14. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Components of Use-case Model
The components of a Use-case model are:
System Modeled
 Actors
Use-cases
 Stimulus
System Name
name
Use-case

15. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
System
As a part of the use-case modeling, the boundaries of the system are
developed.
System in the use-case diagram is a box with the name appearing on the top.
Define the scope of the system that you are going to design with your
EXAM. (software scope)
EXAM Software Appln.
The system is represented by a
boundary box, which contains all the
use cases and actors involved in the
system.

16. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors
An actor is something or someone that interacts with the system.
Actor communicates with the system by sending and receiving messages.
An actor provides the stimulus to activate an Use-case.
Message sent by an actor may result in more messages to actors and to
Use-cases.
Actors can be ranked: primary and secondary; active andpassive.
Actor is a role not an individual instance.

17. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors Identification
Identifying actors is one of the first steps in use case analysis.
Each type of external entities with which the system must interact is
represented by an actor
Who is using the system?
Incase of new system, who will be using the system?

18. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
which has the following characteristics:
An actor in use case modeling specifies a role played by a user or any other
system that interacts with the subject.
An Actor models a type of role played by an entity that interacts with the
subject (e.g., by exchanging signals and data), but which is external to the
subject.
Actors may represent roles played by human users, external hardware, or other
subjects.
Actors do not necessarily represent specific physical entities but merely
particular facets (i.e., “roles”) of some entities that are relevant to the
specification of its associated use cases.

19. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Finding Actors
The actors of a system can be identified by answering a number of
questions:
Who will use the functionality of the system?
Who will maintain the system?
What devices does the system need to handle?
What other system does this system need to interact?
Who or what has interest in the results of this system?

20. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors classification
Actors can be people, other systems, time triggers, or event triggers.
Primary Actor: a user whose defined user goal and is fulfilled by the system
The primary actor of a use case is the stakeholder that calls on the system to
deliver one of its services. It has a goal with respect to the system –one that
can be satisfied by its operation. The primary actor is often, but not always,
the actor who triggers the use case.

21. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors classification
Supporting Actors: a user who provides a service (e.g., information) to the
system.
A supporting actor (also known as a secondary actor) in a use case in an
external actor that provides a service to the system under design. It might be
a high-speed printer, a web service, or humans that have to do some
research and get back to us.

22. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Types of actors include:

23. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Actors Generalization
refers to the relationship which can exist between two actors in a use case
diagram and which shows that one actor (descendant) inherits the role and
properties of another actor (ancestor).
The generalization relationship also implies that the descendant actor can
use all the use cases that have been defined for its ancestor.
generalization is simply the inheritance relationship
between two actors by which one actor inherits
all the properties and relationships of another actor.

24. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Use-cases
A Use-case in UML is defined as a set of sequences of actions a system performs that
yield an observable result of value to a particular actor.
Actions can involve communicating with number of actors as well as performing
calculations and work inside the system.
A Use-case
is always initiated by an actor.
provides a value to an actor.
must always be connected to at least one actor.
must be a complete description.

25. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCaseIdentification
A use case is a methodology used in system analysis to identify, clarify and
organize system requirements.
The use case is made up of a set of possible sequences of interactions
between systems and users in a particular environment and related to a
particular goal.
Use cases describe the functional requirements of a system from the end
user's perspective

26. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCaseIdentification
creating a goal-focused sequence of events that is easy for users and
developers to follow
The alternate flow, also known as an extending use case, describes normal
variations to the basic flow as well as unusual situations.

27. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCaseIdentification
A use case should display the following characteristics:
Organizes functional requirements.
Models the goals of system/actor interactions.
Records paths --called scenarios --from trigger events to goals.
Describes one main flow of events and various alternate flows.
Multi-level, so that one use case can use the functionality of another one.

28. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCaseIdentification
Use cases can be identified in two methods:
i. Use case identification on actor-based: method
(a) Find and specify all the actors by looking at which users will use the
system and which other systems must interact with it.
(b) For each actor, identifying the processes they initiate or participate in by
looking at how the actor communicate/interact with (or use) the system to do
his work.

29. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UseCaseIdentification
ii. Use case identification on event-based method
(a) Identify the external events that a system must respond to.
(b) Relate the events to actors and use cases.

30. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Naming a Use case
Name should provide a general description of the usecasefunction.
Name should express what happens when an instance of the usecaseis
performed
Name should be active, often expressed in the form of verb (Borrow) or
verb and noun (Borrow books)
Naming should be done with care.
The description of the usecaseshould be descriptive and consistent.

31. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Naming a Use case
Example:
The usecasethat describes what happens when a person deposits money
into an ATM machine could be named either receive money or deposit
money.

32. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
To represent complex relationships between different use cases, we can use the
extend and include relationships.
Extend relationship: The use case is optional and comes after the base use
case. It is represented by a dashed arrow in the direction of the base use
case with the notation <<extend>>.
Include relationship:The use case is mandatory and part of the base use
case. It is represented by a dashed arrow in the direction of the included use
case with the notation <<include>>.
Uses/Include and Extend Associations

33. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

34. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

35. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Modeling
Use Static modelling is the base on which the edifice of object orientation
is built.
A static model signifies the conceptual view of a system.
Example college library system will definitely have concepts like book,
magazine, library attendant, librarian, student, teacher, book-issue policy,
book return policy, book procurement policy, a procedure to calculate fine
in the case a book/magazine is returned after the due date, a procedure to
determine the book/magazine to be replaced only in the reference section
and those in the take-home section and so on.

36. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Modeling
Object can be instantiated from classes
An object has identity, data and operations to be performed on the data.
The identity of the object is indicated by the uniqueness of its name.
This unique name differentiates the particular object from other objects.
The data stored within an object includes the attributes of the object.
The operations serve as a means manipulating data stored in a particular
object

37. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Modeling
Thus, the attributes of book in the above-mentioned college library system
can be
Author
Title
Publisher
Catalogue number
Accession number
Number of pages

38. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Operation to be performed on a book object can include operations to set
and get the values for the above-mentioned attributes.
Object structure contains both data and behavior within it.
Two different levels
Conceptual level
Design level

39. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes and Objects
A class is a concept within the application domain being modelled
Class diagram is to model the static view of an application
Class diagrams are the only diagrams which can be directly mapped with
object-oriented languages and thus widely used at the time of construction.
Class is what the programmer designs and programs, where as an object is
created from a class at runtime.

40. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes and Objects
MyClass

41. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Attributes and Operations
Triangle
Base : float
Height : float
Area : float
+setBase(in b:float):void
+getBase(): float
+setHeight(in h:float): void
+getHeight():float
+calculateArea(): void
+getArea():float

42. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes and Objects
The purpose of the class diagram can be summarized as −
Analysis and design of the static view of an application.
Describe responsibilities of a system.
Base for component and deployment diagrams.
Forward and reverse engineering.

43. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
How to Draw a Class Diagram
Class diagrams have a lot of properties to consider while drawing but here
the diagram will be considered from a top level view.
Class diagram is basically a graphical representation of the static view of
the system and represents different aspects of the application.
A collection of class diagrams represent the whole system.

44. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
How to Draw a Class Diagram
The following points should be remembered while drawing a class diagram
The name of the class diagram should be meaningful to describe the aspect
of the system.
Each element and their relationships should be identified in advance.
Responsibility (attributes and methods) of each class should be clearly
identified
For each class, minimum number of properties should be specified, as
unnecessary properties will make the diagram complicated.

45. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Use of Class Diagram
Describing the static view of the system.
Showing the collaboration among the elements of the static view.
Describing the functionalities performed by the system.
Construction of software applications using object oriented languages.

46. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Visibility of Attributes and Operations
Private Visibility
Public Visibility
Protected Visibility

47. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Attributes with Default Values
Triangle
-custName:String=“Tom”
-custID:int= 100
//some operations

48. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
One to one Association
Unidirectional Association
owns1
Person Flat
1

49. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
One to Many Association
Unidirectional Association
owns1
Person Flat
*

50. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Many to Many Association
Unidirectional Association
owns*
Person Flat
*

51. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
One to One Association
Bidirectional Association
owns1
Person Flat
1
ownedBy

52. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
one to Many Association
Bidirectional Association
owns1
Person Flat
*
ownedBy

53. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Many to Many Association
Bidirectional Association
owns*
Person Flat
*
ownedBy

54. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
one to Many Association
Bidirectional Association
owns1
Person Flat
*
ownedBy
Mapping class to Java Code
Public class Person
{
public Flat owns;
}
Public class Flat
{
Public Person ownedby;
}

55. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
One to One Association
Unidirectional Association
owns1
Person Flat
1
Mapping class to Java Code
Public class Person
{
public Flat owns;
}
Public class Flat
{}

56. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Mapping class to Java Code
Triangle
-Base : float
-Height : float
-Area : float
-nonOfTriangles:int
+setBase(in b:float):void
+getBase(): float
+setHeight(in h:float): void
+getHeight():float
+calculateArea(): void
+getArea():float
+getNumberOfTrainagle():int
Public class Triangle{
private float base;
private float height;
private float area;
private static intnoOfTraingles;
public void setBase(float b)
{}
public float getBase()
{}
public void calculateArea()
{}
Class Scope Attribute

57. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Role Names
coached By
1
Coach Player
1..6
Role Name is String placed at the end of an association near the class
to which it applies.
It denotes the role played by the class with respect to the association
BatsmanBowler
coaches

58. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Role Names
employed By
1
Company Person
*
One to Many association between company and Person
EmployeeEmployer
employs

59. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Qualified Association
employed By
0..1
Company Person
0..1
Qualified association between company and Person
Employee
Employer
employs
empID
The Qualifier is drawn as small box at the end of an association near the class
from which the navigation should be made
Qualified associations can be used with one to many or many to many
associations

60. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Association Class
An Association Class is a UML construct
that enables an Association to have
attributes and operations (features).
This results in a hybrid relation with the
characteristics of an Association and a
Class.
The association class is a class that is
connected to the association of two
classes using a dashed line.

61. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Association Class
Consider the relationship “person rents flat’. To rent flat, often a contract is required
Now the details of the rent such as the amount and mode of payment of rent are
neither the property of the class person nor the property of the class Flat
It is a property of the association ‘rents’. So an association class called ‘Rent’ can be
made and the properties of rent can be included in it. Operations can also be added
to this class

62. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Ternary association
Consider the case of buying reference book for a college library.
Total bills depends on
The publisher
The quantity of books
The price of each book
Assist in finding total bill that will contain the itemized details
Multiplicity on all classes has to be *

63. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Ternary association
Publisher
BookPrice PurchasedQty

64. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Ternary association
Publisher
BookPrice PurchasedQty
TotalBill
|
|
|

65. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Recursive association
Person
*
Mother
givesBirthTo1
Child
A class may have an association to itself.
This association is called recursive association
One person (Mother) can give birth to other
persons (child)
At one end the person plays the role of mother and
at the end that of a child
import java.util.*;
Public class person
{
Public Collection givesBirthTo;
}

66. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Multiple Associations between Two Classes
Train Station
*
*
1
1
arrivesAt
leavesFrom
Two classes can have multiple associations between them.
Many trains can arrive at a station and many trains can leave a station
Public class Train
{
public Station arrivesAt;
public Station leavesFrom;
}
Public class Station
{
}

67. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Approaches for identifying classes
Noun Phrase approach
Common class patterns approach
Usecasedriven, sequence/ collaboration modeling approach
Classes, Responsibilities and Collaborators approach

68. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Noun Phrase Approach
Proposed by Rebecca Wirfs-Broack, Brian Wilkerson and Lauren
Wiener.
The requirements or Usecase
Nouns –textual description are considered to be classes
Verbs –to be methods of the classes
All plurals are changed to singular, noun are listed, divided into
Relevant Classes, Fuzzy Classes and irrelevant classes

69. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Identifying Tentative Classes

70. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Identifying Tentative Classes

71. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Selecting Classes from the relevant and Fuzzy
Categories
Redundant Classes –
do not keep two classes that express same information
Choose your vocabulary carefully
Adjective Classes
Suggest different kind of object

72. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Selecting Classes from the relevant and Fuzzy
Categories
Attribute Classes
Tentative objects that are used only as values should be defined or
restated as attributes and not as class
Irrelevant Classes
Class have purpose and every class should be clearly defined and
necessary.

73. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

74. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

75. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

76. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

77. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology

78. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Approaches for identifying classes
Noun Phrase approach
Common class patterns approach
Usecasedriven, sequence/ collaboration modeling approach
Classes, Responsibilities and Collaborators approach

79. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
The ViaNetbank ATM System:
Identifying classes by using Noun Phrase Approach
Initial List of Noun Phrases: Candidate Classes
Account Cash Fund Savings account
Account Balance Check Invalid PIN Step
Amount Checking Message System
Approval process Checking Account Money Transaction
ATM Card Client Password Transaction
ATM Machine Client’s Account PIN
Bank Dollar PIN Code
Bank Client Envelope Record
Card Four Digits Savings

80. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
The ViaNetbank ATM System:
Identifying classes by using Noun Phrase Approach
The following irrelevant classes can be eliminated because they do not
belongs to the problem statement
Envelope
Four Digits
Step

81. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
The ViaNetbank ATM System:
Identifying classes by using Noun Phrase Approach
Initial List of Noun Phrases: Candidate Classes
Account Cash Fund Savings account
Account Balance Check Invalid PIN Step
Amount Checking Message System
Approval process Checking Account Money Transaction
ATM Card Client Password Transaction
ATM Machine Client’s Account PIN
Bank Dollar PIN Code
Bank Client Envelope Record
Card Four Digits Savings

82. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Reviewing the Redundant Classes and Building a
Common Vocabulary
Need to review the candidate list to see which classes are redundant
If different words are being used to describe the same idea, must select
the one that is the most meaningful in the context of the system and
eliminate the others.
Client, BankClient= BankClient(the term Chosen)
Account, Client’s Account = Account
Checking, Checking Account = Checking Account
Savings, Savings Account = Savings Account
ATM Card, Card = ATM Card
Fund, Money = Fund PIN, PIN Code = PIN

83. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
The ViaNetbank ATM System:
Identifying classes by using Noun Phrase Approach
Initial List of Noun Phrases: Candidate Classes
Account Cash Fund Savings account
Account Balance Check Invalid PIN Step
Amount Checking Message System
Approval process Checking Account Money Transaction
ATM Card Client Password TransactionHist-
ATM Machine Client’s Account PIN
Bank Dollar PIN Code
Bank Client Envelope Record
Card Four Digits Savings

84. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Reviewing the Classes Containing Adjectives
Again review the remaining list, now with an eye on classes with
adjectives
Does the object represented by noun behave differently when the
adjective is applied to it?

85. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Reviewing the Possible Attributes
Next review focuses on identifying the noun phrases that are attributes, not
classes.
Noun phrases used only as values should be restated as attributes.
This process also will help us identify attributes of the classes in the system.
Amount : A value, not a class.
Account Balance : An attribute of the Account Class
Invalid PIN : It is only a value, not a class
Password : An attribute, possibly of the BankClientclass.
Transaction History : An attribute, possibly of the Transaction class.
PIN : An attribute, possibly of the BankClientclass.

86. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
The ViaNetbank ATM System:
Identifying classes by using Noun Phrase Approach
Initial List of Noun Phrases: Candidate Classes
Account Cash Fund Savings account
Account Balance Check Invalid PIN Step
Amount Checking Message System
Approval process Checking Account Money Transaction
ATM Card Client Password TransactionHist-
ATM Machine Client’s Account PIN Currency
Bank Dollar PIN Code
Bank Client Envelope Record
Card Four Digits Savings

87. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Reviewing the Class Purpose
Identifying the classes that play a role in achieving system goals and
requirements is a major activity of object oriented analysis.
Each class must have a purpose
Every class should be clearly defined and necessary in the context of
achieving the system’s goals
If you cannot formulate a statement of purpose for a class, simply eliminate
it.
The classes that add no purpose to the system have been deleted from the
list

88. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Common Class Patterns Approach
Based on a Knowledge base of the common Classes
Proposed by Shlaer, Mellor
Complied and listed pattern for finding the candidate class & Object
Name. Concept Class
Context. It encompasses principles that are not tangible but used to organize
or keep track of business activities or communications.
Example. Performance is an example of concept class object
Name. Event Class
Context. Event classes are points in time that must be recorded. Things
happen, usually to something else at a given date and time or as a step in
an ordered sequence.
Example. Landing, interrupt, request and order are possible events

89. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Common Class Patterns Approach
Name. Organization Class
Context. An organization class is a collection of people, resources facilities,
or groups to which the users belong.
Example. An accounting department might be considered a potential class
Name. People Class
Context. The people class represents the different roles users play in
interacting with the application.
Example. Employee, client, teacher and manager are examples

90. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Common Class Patterns Approach
Name. Places Class
Context. Places are physical locations that the system must keep
information about.
Example. Buildings, stores, sites, and offices are examples of places.
Name. Tangible things and devices class
Context. This class includes physical objects or groups of objects that are
tangible and devices with which the application interacts.
Example. Cars are an example of tangible things and pressure sensors
are an example of devices

91. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Common Class Patterns Approach
Name. Places Class
Context. Places are physical locations that the system must keep
information about.
Example. Buildings, stores, sites, and offices are examples of places.
Name. Tangible things and devices class
Context. This class includes physical objects or groups of objects that are
tangible and devices with which the application interacts.
Example. Cars are an example of tangible things and pressure sensors
are an example of devices

92. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
UsecaseDriven Approach
Identifying Classes and their Behaviors through Sequence/Collaboration
Modeling
Implementation of Scenarios
Decomposing a Use-Case Scenario with a Sequence Diagram

93. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes, Responsibilities and Collaborators

94. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes, Responsibilities and Collaborators Process

95. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Classes, Responsibilities and Collaborators :-
Example ViaNetBank ATM System

96. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Naming Classes
Name should b singular
Use general name with user or client comfortable
Name should reflect its intrinsic nature
Use Readable names
Capitalize class names

97. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Class Associations and Identification of
Associations
Association represent a physical or conceptual connection between two
or more objects
Identify association
Is the class capable of fulfilling the required task by itself?
If not, what does it need?
From what other class can it acquire what it needs?
Guidelines for identifying association
Common Association Patterns-Location,Communication

98. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Generalization
Generalization is a mechanism for combining similar classes of objects
into a single, more general class
Generalization identifies commonalities among a set of entities
The commonality may be of attributes, behaviour, or both
In other words, a superclass has the most general attributes, operations,
and relationships that may be shared with subclasses. A subclass may
have more specialized attributes and operations.
Specialization is the reverse process of Generalization means creating
new sub-classes from an existing class

99. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Generalization

100. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Guidelines for Generalization/Specialization Relationship
Top-down –noun phrased composed of various adjectives
Bottom Up –similar attribute or method
Reusability-move attribute and behavior (methods) as high as possible
in the hierarchy
Multiple inheritance –Avoid excessive use of multiple inheritance.

101. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Aggregation and Composition Relationships
A-Part-of Relationship
Represent a situation where a class consists of several component classes
Transitivity –if A is part of B and B is Part of C, then A is part of C
Antisymmetry–if A is part of B then B is Not Part of A
Does part class belong to a problem domain?
Is the part class within the system’s responsibilities?
Does the part class capture more than a single value?
Does it provide a useful abstraction in dealing with the problem
domain?

102. Software Engineering Modeling and Design
Object Oriented Analysis Mr. N. L. Shelake Department of Information Technology
Composite Aggregation
This aggregation shows that the parts reside within the whole.
Composition implies a relationship where the child cannot exist independent of the
parent.