Object-Oriented Analysis: and Design

Object-Oriented Analysis
and Design
Commercial Billiards - Center
Notation and Tool
• The Unified Modeling Language (UML)
is the industry-standard language for
specifying, visualizing, constructing, and
documenting the artifacts of software
systems.
• Rational Rose was our obvious choice for
the “tool” considering the powerful features
that the tool exhibit to visualize,
Problem Statement(1)
• The players of Billiards center can be
either members or non-members of the
billiards center
• Note: The details of members such as
name, address and phone number are
already stored in database and they are
provided with identification number.
• Non-members have to provide their name
and address before start playing.
• The players may request a catalog
showing table numbers and the availability
of tables in terms of hours
• They have the option to either extend the
game if there are no waiting members or
stop the game
• The registration system sends information
to the billing system so that the buyer can
pay the bill
• If all the play boards are occupied
incoming players are kept in the waiting
list.
• Players can book the table or cancel the
table in advance.
Project Activities
• Maintaining current players information
• Waiting list of the players who would like
to play next
• Membership provision – becoming a
member at the center
• Booking provision at the center
• Billing system to deliver the charges for
the facilities availed at the center
Constructing our model in Rational Rose
Step 1: USE CASES AND ACTORS
• USE CASE DIAGRAMS are created to visualize

interaction of our system with the external world.
• The actors are:
• Members
• Non members
• Operator (one who is in charge of the
operational activities of the center)
• Manager (one who owns the center)
• We assume that the “members” or “non-members” enter

the center, perform some activities described at the start
of this report, and leave the center.
• ACTOR: MEMBER
• Enter his details (ID number, name)
• Select the tables that he is wanting to play once he
is approved by the operator
• Book tables to play in advance
• Pay the bill for the activity he performed
• ACTOR: NON-MEMBER
• Enter his details (name, address, occupation)
• Select the tables that he is wanting to play once he
is approved by the operator
• Book tables to play in advance
• Become a member if he wants to
• Pay the bill for the activity he performed
• ACTOR: OPERATOR
• Validate ID information for members, details of the non-
members depending on whether the player is a member
or non-member
• Allot tables for the players
• Maintain the membership information
• Maintain waiting list information of members
• Maintain waiting list information of non-members
• Maintain table/time information for members
• Maintain table/time for non-members
• Maintain correctness of the system (system
administration)
• Maintain booking information
• Maintain current players information
• Generate bill for the players
• ACTOR: MANAGER
• Responsible for collecting the payment from
the player and manages the overall activities of
the center.
• Member use case diagram
Select member tables Enter member details
<<include>>
Validate membership information
Member
Paybill for members

Book member tables to play in
advance
• Nonmember use case diagram
Enter non-member details
Book non-mem ber table to play in

advance
Select non-member tables

Nonmem ber
Pay bill for non-mem bers
Avail mem bership

• Operator use case diagram

Allot Tables
Generate bill
Maintain members hip information
Maintain current players

inform ation
Maintain waiting lis t for m em bers
Maintain booking inform ation Operator
Maintain waiting lis t for

Maintain correctnes s of s ys tem non-m embers
Maintain table or tim e information

Maintain table or tim e information for m em bers
for non-m em bers
• Combined USE CASE DIAGRAM

Paybill for m embers Select m ember tables
<<include>> Maintain waiting list for members
Allot Tables
Enter member details

Validate membership information
Member
Maintain waiting list for

Book member tables to play in non-members
advance
Maintain booking information
Manager
Generate bill
Operator
Maintain membership information
Select non-member tables
Maintain current players

information
Pay bill for non-members Maintain correctness of sys tem

Book non-member table to play in
advance Maintain table or time information Maintain table or time information
Nonmember for members for non-m embers
Avail membership Enter non-member details

Constructing our model in Rational
Rose
STEP 2: ACTIVITY DIAGRAMS (member)
• A member enters the center
– Enters his/her ID
– Operator validates his/her ID
– Member is given options – he/she can:
• Play
• Book
– If member wants to play:
• Operator checks the availability of tables:
– Checks booked tables of members and non-members
– Checks the waiting list tables of members and non-members
(Because a member can avail the privilege of playing in a non-member table if free)
– If the table is free then the operator allots tables
» Member selects the table that he/she prefers
» Extends the play/not extends the play (basically the operator maintains the
player information and checks whether he/she wants to extend or not)
– Once the member finishes his/her game, he/she pays the bill
– Leaves the center
STEP 2: ACTIVITY DIAGRAMS
– If member wants to book:

– Checks booked tables of members and non-members
– Checks the waiting list tables of members and non-
members
• (Because a member can avail the privilege

of playing in a non-member table if free)
– The information is passed to the member
STEP 2: ACTIVITY DIAGRAMS (non-member)
• A non-member enters the center

– Enters his/her details
– Operator validates his/her details
– Non-member is given options – he/she can:
• Play
• Book
• Become a member if he/she wants to
– If non-member wants to play:
– Checks booked tables of non-members
– Checks the waiting list tables of non-members
• Non-member selects the table that he/she prefers
• Extends the play/not extends the play (basically the operator maintains the
player information and checks whether he/she wants to extend or not)
– Once the nonmember finishes his/her game, he/she pays the bill
Rose
STEP 2: ACTIVITY DIAGRAMS (non-member)
– If non-member wants to book:
– Checks booked tables of non-members
– Checks the waiting list tables of non-members
» The information is passed to the non-member
• (In both cases, if there are no free tables, then the
operator passes an appropriate message to the player)
– If non-member wants to become a member:
• Operator validates the details and collects the membership fee.
• Delivers the membership ID card to the player and relevant
documents
• Non-member collects the same and leaves the center
Rose
Step 3: CLASSES
• We identify the CLASSES here at the analysis stage, we
just identify the roles of the classes and we will later on
identify the methods and the attributes at the design
phase.
• There are three types of classes that needs to be
identified for the analysis and design model:
• Boundary Class
• Entity Class
• Control Class
Rose
Step 3: CLASSES
• Boundary class models the interaction between the system and its
environment. We identify a boundary class for every use case/actor pair.
Based on this definition we identified the following boundary classes:
• Category: This class will have attributes and methods
pertaining to obtaining the category of the players (whether
a member/non-member).
• Activity: This class will have attributes and methods
pertaining to obtaining the activity (whether
play/book/membership) of the players
• Activity Information: This class will have attributes and
methods pertaining to obtaining the activity information of the
players currently playing and storing them also.
Rose
Step 3: CLASSES
• Entity class store and manage information in
the system.
• Table: This class will have attributes and methods pertaining
to storing and retrieving the details of all the tables in the
center (this includes member tables/non-member tables)
• Members: This class will have attributes and methods
pertaining to storing and retrieving the details of all members
in the center.
• Booking Members: This class will have attributes and
methods pertaining to storing and retrieving the details of
booking information for all members in the center.
Rose
Step 3: CLASSES
• (Note: This inherits from Member’s class)
• Waitinglist Members: This class will have attributes and methods
pertaining to storing and retrieving the details of waiting list queue
information for all members in the center.
• Nonmembers: This class will have attributes and methods pertaining to
storing and retrieving the details of all non-members in the center.
• Booking Nonmembers: This class will have attributes and methods
pertaining to storing and retrieving the details of booking information for all
non-members in the center.
• (Note: This inherits from Nonmember’s class)
• Waitinglist Nonmembers: This class will have attributes and methods
pertaining to storing a retrieving the details of waiting list queue information
for all non-members in the center.
• Bill: This class will have attributes and methods pertaining to storing and
retrieving the details of billing and money transactions information for all
players in the center.
• NO CONTROL CLASS WAS IDENTIFIED.
Rose
Step 4: PACKAGES
• Once the classes have been identified, we will try to
group them into PACKAGES.
• We identified three packages for our model.
• Members Information Package
• Non-Members Information Package
• Interface Information Package
Rose
Step 4: PACKAGES
• Members Information Package
• Member class
• Booking Member Class
• Waiting list Member Class
• Non-Members Information Package
• Nonmember class
• Booking Nonmember Class
• Waiting list Nonmember Class
• Interface Information Package
• Category class
• Activity Class
• Activity Information Class
• Table Class
• Bill Class
Rose
Step 4: PACKAGES
Foundations NonmembersInfo
global
Database Interface GUI Controls
Error Handling MembersInfo
global
Rose
Step 5: SEQUENCE DIAGRAMS
• we have specified the “actors” and the participating
“classes” – typical to a sequence diagram.
• There are nine independent sequence diagrams that
we have come up with for this model based on the
sequences of activities performed by the member/non-
member. We will briefly describe each of them and
explicitly show them with the help of RATIONAL ROSE.
Rose
• Sequence-diagram 1: Operator obtains the respective activity
requested by the player -diagram
: Category : Activity
Member
: Operator
players
Nonmember
Member or players
get category
Nonmember
Members
booking
get activity
Nonmembers
booking
Become
members
Rose
• Collaboration diagram 1: Operator obtains the respective
activity requested by the player
1: get category
: Category
: Operator
2: get activity
: Activity
Rose
• Sequence-diagram 2: Member play/bill - diagram
: ActivityInformation : Tables : Bill
: Manager
: Mem ber
Pass ID
validate details
get free tables
Free tables
are displayed
select tables
Member starts
playing
indicat e time over
E xtend the get total time played

play
generate bill
Bill is passed
to player
pay bill
Rose
• Collaboration diagram 2: Member play/bill
7: generate bill
: Bill
: Mem ber
1: Pass ID
4: select tables
6: get total time played
8: pay bill
5: indicate tim e over 2: validate details
3: get free tables

: ActivityInform ation : Tables
: Manager
Rose
• Sequence-diagram 3: Nonmember play/bill - diagram
: ActivityInformation : Tables : Bill

: Manager
: Nonmem ber
pass details
validate details
get free tables
free tables
are displayed
select tables
Player starts
to play
indicate time over
Extend the
get total time played
play for
non-members
generate bill
Bill is passed
to players
pay bill
Rose
• Collaboration diagram 3: Nonmember play/bill
2: validate details
1: pass details
4: select tables 3: get free tables
: ActivityInformation : Tables
: Nonmem ber 5: indicate time over
6: get total time played
8: pay bill
7: generate bill
: Bill
: Manager
Rose
• Sequence-diagram 4: Nonmember availing membership
provision - diagram
: Members
: Operator
: Nonm em ber
add entries
pay membership amount
generate ID
provide membership benefits

Rose
• Collaboration diagram 4: Nonmember availing
membership provision 3: generate ID
1: add entries
:
Members
: Nonm em ber
4: provide members hip benefits 2: pay mem bers hip am ount
: Operator
Rose
• Sequence-diagram 5: Member book/bill sequence - diagram
Members cancel
booking
: ActivityInform ation : Tables : BookingMembers
: Mem ber : Operator
pass ID
validate details
get free tables
free tables
are displayed
select tables
implement booking
update booked tables

Rose
• Collaboration diagram 5: Member book/bill sequence
2: validate details
1: pas s ID
4: s elect tables
: ActivityInform ation
: Mem ber
3: get free tables

: Tables
6: update booked tables
: BookingMem bers
5: implem ent booking : Operator

Rose
• Sequence-diagram 6: Nonmember book/bill sequence - diagram
Nonmembers
cancel booking
: ActivityInform ation : Tables : BookingNonmembers

: Nonm em ber : Operator
pass details
validate details
get free tables
free tables
are displayed
select tables
implement booking
update booked tables

Rose
• Collaboration diagram 6: Nonmember book/bill sequence
2: validate details
1: pass details
4: select tables
: ActivityInformation
: Nonmember
3: get free tables

: Tables
6: update booked tables
: BookingNonmembers
5: implement booking : Operator

Rose
• Sequence-diagram 7: Extend to play sequence – diagram
(member)
: Member : Operator
Player wants to
extend the play
get free tables
free tables
are displayed
select tables
update status of tables

Rose
• Sequence-diagram 7: Extend to play sequence – diagram
(non-member)
: Nonmem ber
: Operator
Player wants
to extend the
play
get free tables
Free tables
are displayed
select tables

Rose
• Collaboration diagram 7: Extend to play sequence (member)
2: select tables
: Member
1: get free tables
: Tables
Rose
• Collaboration diagram 7: Extend to play sequence – diagram
(non-member) 2: select tables
: Nonmember
1: get free tables
: Tables
3: update status of tables : Operator

Rose
• Sequence-diagram 8: Member canceling the booking - diagram
: ActivityInformation : Tables : BookingMembers

: Member : Operator
pass id
validate details
indicate cancel booking
implement cancel booking

Rose
• Collaboration diagram: Member canceling the booking
2: validate details
1: pass id
3: indicate cancel booking
: Member
: Tables
5: update status of tables
: BookingMembers
4: implement cancel booking : Operator

Rose
• Sequence-diagram 9: Nonmember canceling the booking -
diagram
: ActivityInformation : Tables : BookingNonmembers

: Nonmember : Operator
pass details
validate details
indicate cancel booking

implement cancel booking

Rose
• Collaboration diagram: Nonmember canceling the booking
2: validate details
1: pass details
3: indicate cancel booking
: Nonmember
: Tables
5: update status of tables
: BookingNonmembers
4: implement cancel booking : Operator

Rose
Step 6: RELATIONSHIPS
• There are two kinds of relationships defined to specify
communication between “entities” in different classes or
packages:
• Association
• Aggregation
Rose
• Relationships between the classes in Interface package:
– Once the “category” of the player is identified, he/she selects “activity” –
hence an association relationship between classes “Category” and
“Activity”.
– The “Activity” class “directs” the sequence to “Activity Information”
class because, once the activity is identified, the next step is to obtain
information pertaining to the selected activity. Hence, an association
relationship between classes “Category” and “Activity”.
– The “Activity Information” class “verifies” Table class for required
information. This is because, once the information is obtained, the
processing of it is done with the avilablity/non-availablity of tables at the
center. Hence, an association relationship between classes “Activity
Information” and “Table”.
• The “Activity Information” class “generates” Bill class for required
information. This is because, once the player has finished the game,
the next step is to generate the bill before he/she leaves the center.
Hence, an association relationship between classes “Bill” and
“Activity Information”.
Rose
• Relationships between the classes in
Member package
– Once the details and tasks related to the
members are stored in Member class, Waitinglist
Member class and Booking Member Class – both
contains “a part” of this class. Hence an
aggregation relationship between:
• Member class and Waitinglist Member class
• Member class and Booking Member class
Rose
• Relationships between the classes in
Nonmember package
– Once the details and tasks related to the non-
members are stored in Nonmember class,
Waitinglist Nonmember class and Booking
Nonmember Class – both contains “a part” of this
class. Hence an aggregation relationship
between:
• Nonmember class and Waitinglist Nonmember class
• Nonmember class and Booking Nonmember class
Rose
• Relationships between the classes in Member
package, Nonmember package, and Interface package.
– Since the activity information of members/non members is required
for processing activities relating to their information stored in
waiting list database and booking database respectively back and
forth, we have identified an association relationship between:
• Activity Information class (Interface package) and Booking Member
class (Member Package)
• Activity Information class (Interface package) and Waitinglist Member
class (Member Package)
• Activity Information class (Interface package) and Booking
Nonmember class (Nonmember Package)
• Activity Information class (Interface package) and Waitinglist
Nonmember class (Nonmember Package)
Step 7: IDENTIFYING CLASS ATTRIBUTES AND METHODS (Design
phase has begun!!!!)
• MembersInfo class diagram
Members
BookingMembers WaitinglistMembers
• MembersInfo class diagram with attributes and operations
Members
name : String
address : String
id : Integer
addEntries()
deleteEntries()
modifyEntries()
getID() : Integer
BookingMembers
WaitinglistMembers
bookDate : Date
startTime : Time waitinglistNumber : Integer
endTime : Time
tablenum : Integer getWaitinglistNum() : Integer
doBooking()
cancelBooking()
• NonmembersInfo class diagram
Nonmembers
BookingNonmembers WaitinglistNonmembers
• NonmembersInfo class diagram with attributes and

operations
BookingNonmembers
Nonmembers
bookDate : Date
name : string
startTime : time
address : string
endTime : time
occupation : string
tablenum : Integer
addEntries()
doBooking()
deleteEntries()
cancelBooking()
WaitinglistNonmembers
waitinglistNumber : Integer
getWaitinglistNum() : Integer
• Interface class diagram

selects
Category 1 1..3 Activity
directs
ActivityInformation
1
1
verifies generates
1
*
Tables Bill
• Interface class diagram with attributes and operations
Bill
Activity
timePlayedByMem : Time
play : Boolean = false
timePlayedByNonmem : Time
book : Boolean = false
costOfMemTable : Float
costOfNonmemTable : Float
getActivity() : String
costOfPlay : Float
getTimePlayedByMem() : Time
getTimePlayedByNonmem() : Time
getBill()
Tables
tablenum : Integer
startTime : Time
endTime : Time ActivityInformation
id : Integer
getFreeTables() : Integer name : String
tablenum : Integer
noOfMemTablesVisited : Integer
noOfNonmemTablesVisited : Integer
Timein : Time
Category hoursToPlay : Integer
extendToPlay : Boolean
member : Boolean
nonmember : Boolean
validateDetails()
indicateTimeOver()
getCategory()
validateTablenum()
validateHours()
extendToPlay()
getTablesVisited()
Step 8: Discovering Inheritance
• Actually, Inheritance defines a relationship

among classes where one class shares the
structure/behavior of one or more classes.
• We identified that the following classes
inherits from Member class:
• Booking Member class
• Waitinglist Member class
• We identified that the following classes
inherits from Nonmember class:
• Booking Nonmember class
• Waitinglist Nonmember class
Step 9: Analyzing Object Behavior
• A state-chart diagram shows the states of a single object, the

events or messages that cause a transition from one state to
another state, and the actions that result from the state change.
• A state-chart diagram is created only for classes that exhibit
maximum dynamic behavior. Based on this theory, we have
demonstrated five state-chart diagrams for our model.
Essentially, we identified the ongoing activities pertaining to
each class to create our state-chart diagrams.
• Diagram 1:Participating Class: Activity Information

Initialization
do/ Initialize activity information details
[ Extend to play ] ^Tables.getFreeTables

[ play ]
Add
do/ Add player details

exit/ Alloted time over
[ finish game ]
Delete
do/ remove player details

do/ ^Bill.generateBill
• Diagram 2: Participating Class: Table
Initialization
do/ Initialize Tables data
[ EndTime - StartTime < 30 ]
Delete
do/ Remove Tables details

• Diagram 3: Participating Class: Member
Initialization add member

do/ Initialize members details
[ warranty ends ]
Delete Add
do/ remove member details do/ generateID

• Diagram 4: Participating Classes: Booking Member and Booking Nonmember
Initialization Initialization
do/ initialize booking member details do/ initialize booking details
cancel booking cancel booking
Delete
Delete
do/ remove booked details
do/ remove booked details
• Diagram 5: Participating Classes: Waitinglist Member and

Waitinglist Nonmember
Initialization [ free tables ] Initialization [ free tables ]

do/ Initialize waitinglist data
do/ initialize waitinglist data
[ no free tables ] [ no free tables ]
Add Delete
Add Delete
do/ add to waiting list do/ remove from waiting list

do/ add to waitinglist do/ remove from waiting list
Step 10: Checking the Model
• In this step, we check our model to verify consistency

among the classes, combining classes if possible,
splitting and eliminating classes if required, and
review our documentation – which we did before we
proceeded to the next step.
Step 11: Designing the System Architecture
• Software architecture is not a single view; it is made of

concurrent multiple views.
– The logical view – addressing the functional requirements of the
system has been covered.
– The implementation view – which concerns with the actual
software module organization within the development
environment, which has been covered.
– The use case view – which concerns with understandability and
usability of the system, has also been covered before.
• We will discuss the process view and the deployment
view here.
• Process view:
– This view of the architecture takes into account the run-time
implementation of the system. Component diagrams are
created to view the run-time and executable components created
for the system. Components are related via the dependency
relationships.
Interfaces
MembersInfo Database NonmembersInf

o
Error Handling
Foundations
• Interfaces Component diagram
Category ActivityInformation
Tables Bill
Activity
• MembersInfo Component diagram
Members
WaitinglistMembers
BookingMembers
• NonmembersInfo Component diagram
Nonmembers
BookingNonmembers
WaitinglistNonmembers
• Deployment View
Database
Operator Customer
Any Question

Object-Oriented Analysis: and Design

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Object-Oriented Analysis: and Design

Uploaded by

Copyright:

Available Formats

Object-Oriented Analysis

• USE CASE DIAGRAMS are created to visualize

• We assume that the “members” or “non-members” enter

• Member use case diagram

Select member tables Enter member details

Validate membership information

Paybill for members

• Nonmember use case diagram

Enter non-member details

Book non-mem ber table to play in

Select non-member tables

Pay bill for non-mem bers

Avail mem bership

• Operator use case diagram

Maintain current players

Maintain waiting lis t for m em bers

Maintain booking inform ation Operator

Maintain waiting lis t for

Maintain table or tim e information

• Combined USE CASE DIAGRAM

<<include>> Maintain waiting list for members

Enter member details

Maintain waiting list for

Maintain booking information

Select non-member tables

Maintain current players

Pay bill for non-members Maintain correctness of sys tem

Avail membership Enter non-member details

– If member wants to book:

• (Because a member can avail the privilege

• A non-member enters the center

Database Interface GUI Controls

Error Handling MembersInfo

get free tables

indicat e time over

E xtend the get total time played

5: indicate tim e over 2: validate details

3: get free tables

: ActivityInformation : Tables : Bill

get free tables

indicate time over

: Nonmem ber 5: indicate time over

6: get total time played

pay membership amount

provide membership benefits

4: provide members hip benefits 2: pay mem bers hip am ount

: ActivityInform ation : Tables : BookingMembers

: Mem ber : Operator

get free tables

update booked tables

3: get free tables

6: update booked tables

5: implem ent booking : Operator

: ActivityInform ation : Tables : BookingNonmembers

get free tables

update booked tables

3: get free tables

6: update booked tables

5: implement booking : Operator

get free tables

update status of tables

get free tables

update status of tables