UML- LAB

INTRODUCTION:

USECASE DIAGRAM:
A behavioral diagram that shows a set of use cases and actors and their relation ships.

USECASE:
It is a description of set of sequence of actions that a system performs that yields an
observable result of value to a particular actor.
An use case is used to structure the behavioral things in a model and it is rendered as
an ellipse with solid line along with its name.

Actor:
It specifies a coherent set of roles that users of use cases play when interacting with these use
cases.

CLASS DIAGRAM:
A structural diagram that shows a set of classes, interfaces, collaborations, and their
relationships.

OBJECT DIAGRAM:
A structural diagram that shows a set of objects and their relationships.

SEQUENCE DIAGRAM:
A behavioral diagram that shows an interaction, emphasizing the time ordering of messages.

COLLABORATION DIAGRAM:
A behavioural diagram that shows an interaction, emphasizing the structural organization of
the objects that send and receive meassages.

STATECHART DIAGRAM:
A behavioural diagram that shows a state machine, emphasizing the event-ordered behavior
of an object.

ACTIVITY DIAGRAM :

CREC/CSE
Page 3
An activity diagram represents the execution state of a mechanism as a sequence of steps
grouped sequentially as parallel conrol flow branches.It is a variant of state chart diagrams
organized according to actions and internal behavior of a method or a usecase.

Activity diagram s are used to model the dynamic aspects of system.

 Swimlanes

 Forking

 Joining

COMPONENT DIAGRAM:

Component diagrams are basically used to model static view of the system. This can be
achieved by modeling various physical components like libraries, tables, files etc. which are
residing within a node.

Component diagrams are very essential for constructing executable systems. This can be
done using concepts of forward and reverse engineering. The graphical representation of a
component diagrams basically include collection of vertices and arcs.

DEPLOYMENT DIAGRAM:

Deployment is the stage of development that describes the configuration of the running
system in a real time environment.For deployment,decisions should be made about
configuration parameters,performece,resource allocation ,distribution and concurency.The
component develop or reused should be deployed on some set o f hardware for
execution.Nodes are used to model the topology of the hardware on which the system
executes.A node usually represents a processor or a device on which components can be
deployed

CREC/CSE
Page 4
EXPERIMENT NO: 1

COLLEGE INFORMATION SYSTEM

AIM:

To develop a college Information System

PROBLEM ANALYSIS AND PROJECT PLANNING

A college Information System (SIS) is a software application for educational

establishments to manage COLLEGE data. COLLEGE Information System provide
capabilities for entering student test and other assessment scores, building schedules,
tracking student attendance, and managing many other COLLEGE-related data needs in
a school, college or COLLEGE.

PROBLEM STATEMENT

a. Effective for Administration Purpose

b. Cheap
c. Better Service

UML DIAGRAMS:

The following UML diagrams describe the process involved in the online recruitment
system

a. Use case diagram

b. Class diagram

c. Sequence diagram

d. Collaboration diagram

e. Activity diagram

f. Component diagram

g. Data Flow Diagram

h. Deployment Diagram

CREC/CSE
Page 5
1. USE CASE DIAGRAM:

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. It is represented using ellipse. Actor is any external entity that makes
use of the system being modeled. It is represented using stick figure

For Administrator:

Admin Login

Add Student

Admin
Database
Delete Student

Update Student Records

COLLEGE

DOCUMENTATION OF USE CASE DIAGRAM

The actors in this use case diagram are Admin, Student, Database. The use cases are the
activities performed by actors.
a. Admin register login, and store the student records details in database.
b. Student Register from the Student Login process.
c. Then the database is searched for details and verified.
d. Database stores the details and returns acknowledgement
2. CLASS DIAGRAM:A class diagram in the unified modeling language (UML) is a type of
static structure diagram that describes the structure of a system by showing the
system's classes, their attributes, and the relationships between the classes. It is
represented using a rectangle with three compartments. Top compartment have the
class name, middle compartment the attributes and the bottom compartment with
operations.
DOCUMENTATION OF CLASS DIAGRAM

This class diagram has three classes Login, Student details and Update details in database.
a. Students – is the class name. Its attributes are name, Address, DOB, Gender, College,
Subjects, Semester, Year, Degree, Branch. The operations Performed in the students class,
Store database and Update.

b. Administration– is the class name. Its attributes are Login, Password and database.
The operations performed are Student Details store in database and send
acknowledgement.

c. Database – is the class name. The operations performed are storing Search and
storing the values.
 3. SEQUENCE DIAGRAM:
A sequence diagram in Unified Modeling Language (UML) is a kind of interaction diagram
that shows how processes operate with one another and in what order. It is a construct of a
Message Sequence Chart. There are two dimensions.
1. Veritcal dimension-represent time.
2. Horizontal dimension-represent different objects.

For Validity:

Admin/Student Validation Database

1 : Request for validity()

2 : Check for validity()

3 : Validate()

4 : Successful validate()

For Administrator:

Login ReqAdd Student ReqUpdate Student Database

Admin

1 : Enter Credentials for login()

2 : Check for validity()

3 : Valid user()

4 : Successful login()

5 : Enter details f or adding a student()

6 : Add()

7 : Successful()

8 : Successfully added()

9 : Enter credentials f or update student record()

10 : Update()

11 : Successful()

12 : Successfully Updated()
For Student:

Student Login ReqView Profile

ReqView Details Database

1 : Enter credentials for login()

2 : Check for Validity()

3 : Valid()

4 : Valid login()
5 : Request for view profile()

6 : Request()

7 : Set Details()

8 : Get the details()

9 : Request for view Details()

10 : Request()

11 : Set Details()

12 : Get the Details()

DOCUMENTATION OF SEQUENCE DIAGRAM:

The sequence diagram describes the sequence of steps to show

a. The Admin login and registering for add Stduent Details.

b. The verification done by the interface and sending acknowledgement for registration.
c. Searching the database with login and displaying it for maintenance.
4. COLLABORATION DIAGRAM:

A collaboration diagram, also called a communication diagram or interaction diagram.A

sophisticated modeling tool can easily convert a collaboration diagram into a sequence
diagram and the vice. A collaboration diagram resembles a flowchart that portrays the roles,
functionality and behavior of individual objects as well as the overall operation of the
system in real time
For Validity:

Database
3 : Validate()

2 : Check for validity()

Validation

1 : Request for validity()

4 : Successful validate()

Admin/Student

For Administrator:

Database

3 : Valid user()
6 : Add()
10 : Update()

7 : Successful() 2 : Check for validity()

11 : Successful()
Login

ReqAdd Student ReqUpdate Student

1 : Enter Credentials for login()

8 : Successfully added()
4 : Successful login()
12 : Successfully Updated()

9 : Enter credentials for update student record()

5 : Enter details for adding a student()

Admin
For Student:

Database

3 : Valid()
6 : Request() 2 : Check for Validity()

10 : Request()
7 : Set Details()

11 : Set Details() Login

ReqView Profile

8 : Get the details() ReqView Details

4 : Valid login()

1 : Enter credentials for login()

Object1
5 : Request for view profile()
9 : Request for view Details()

12 : Get the Details()

Student

DOCUMENTATION OF COLLABRATION DIAGRAM

The collaboration diagram is to show how the Student registers and the authorities
maintains the details of the registered students in the Information system. Here the
sequence is numbered according to the flow of execution.

5. ACTIVITY DIAGRAM:

Activity diagrams are graphical representations of workflows of stepwise activities and

actions with support for choice, iteration and concurrency. In the Unified Modeling
Language, activity diagrams can be used to describe the business and operational step-by-
step workflows of components in a system. An activity diagram shows the overall flow of
control. An activity is shown as an rounded box containing the name of the operation.

DOCUMENTATION OF ACTIVITY DIAGRAM

This activity diagram flow of stepwise activities performed in recruitment system.

a. The student details are Add and stored in database.

b. Select the course from the given Course by student.
c. Search Profile and Result with login and if data present in the database.
d. The searched data is displayed if available and then Log Out.

CREC/CSE
Page 13
 Login

Student Registration

back to registration
If No
Yes

Select Course

Profile

Result

Fee

Library

Log Out
6. COMPONENT DIAGRAM:

The component diagram's main purpose is to show the structural relationships between the
components of a system. It is represented by boxed figure. Dependencies are represented
by communication association.

User

IUser

<<application>>
Management <<infrastructure>>
Persistence

Request

IRequest

DB

JDBC

DOCUMENTATION OF COMPONENT DIAGRAM

The main component in this component diagram is Student Information system. And
register, User and Manage, Request details are the components comes under the main
component.
7. DEPLOYMENT DIAGRAM:

A deployment diagram in the unified modeling language serves to model the physical
deployment of artifacts on deployment targets. Deployment Diagrams show "the allocation
of artifacts to nodes according to the Deployments defined between them. It is represented
by 3-dimentional box. Dependencies are represented by communication association.

DOCUMENTATION OF DEPLOYMENT DIAGRAM

The processor in this deployment diagram is the COLLEGE Information System which is the
main part and the Student are the Admin, verify and search which are the some of the main
activities performed in the system.
Case Study 1: Library Application

1. Problem Statement:
A lightweight set of features for the first version of the library application might look like
this:

It is a support system for a library. The library lends books and magazines to borrowers,
who are registered in the system, as are the books and magazines. The library handles
the purchase of new titles for the library. Popular titles are bought in multiple copies.
Old books and magazines are removed when they are out of date or in poor condition.
The librarian is an employee of the library who interacts with the customers (borrowers)
and whose work is supported by the system. A borrower can reserve a book or magazine
that is not currently available in the library, so that when it’s returned or purchased by
the library, that borrower is notified. The reservation is cancelled when the borrower
checks out the book or magazine or through an explicit canceling procedure. The
librarian can easily create, update, and delete information about the titles, borrowers,
loans, and reservations in the system.
The system can run on all popular Web browser platforms (Internet Explorer 5.1+,
Netscape 4.0+, and so on).The system is easy to extend with new functionality.

2. Identification of actors and use cases:

The use cases in the library system are as follows:

Login

Search

Browse

Make Reservation

Remove Reservation

Checkout Item

Return Item

Manage Titles

Manage Items

Manage Borrowers

Manage Librarians

Assume Identity of Borrower

CREC/CSE
Page 17
The outline of the basic flow for the use case Checkout Item (which means that a Borrower
can check out an Item) is described as follows:

1. The borrower chooses to perform a “Search” for desired titles/

2. The system prompts the borrower to enter Search criteria.

3. The borrower specifies the search criteria and submits the search.

4. The system locates matching titles and displays them to the borrower.

5. The borrower selects a title to check out.

6. The system displays the details of the title, as well as whether or not there is an
available item to be checked out.

7. The borrower confirms that he or she wishes to checkout the item.

8. The system checks out the item.

9. Steps 1 to 8 can be repeated as often as desired by the borrower.

10. The borrower completes checkout.

11. The system notifies a librarian that the borrower has concluded the checkout item
session and displays instructions for the borrower to collect the contents.

CREC/CSE
Page 18
3: Identification of actors and use cases:

Registered
User

Login Search
Browse

Manage Borrowers Remove reservation

Librarian Borrower

Make Reservation
Manage Items

Checkout Item
Manage Titles

Assume Identity Of Borrower Return Item

Master Manage Librarian

Librarian

Fig: A use-case diagram for library system

Class diagram for library system: Fig:

classes for the library system

librarian

+1

+1..*
L_STAFF
L_VISITORS LIBRARY sta_name
sta_desig
v_name +1 lib_name +1 +1..*
+0..* sta_id
time visits lib_add
associated with
lend()
refers() timings()
maintain()
+1 log()

+1..*

is member of maintains

+0..*

L_MEMBER +1..*
mem_name L_BOOKS
mem_add uses
+1..* +1..* bk_name
no.books
bk_id
no.copies
take()
visit()
read()
 Borrower makes Reservation
creationDate : Date = currentDate
0..*
can Borrow()
0..*

checks out references

1
0..* Title
name : String
Loan
creationDate : Date = currentDate getLendingTime()

0..* Book Title Magzine Title

Item
lendingTime : Days = 30 lendingTime : Days = 10
id : integer

classes for the library system.

Sequence diagram for use case Return Item:

:Return item :Return item :Title :Borrower :item

: Borrower
Controller
1: specify criteria()

2: search() 3: search(criteria)
4: get matching(criteria)

5: select title() 6: get item(title) 7: get item()

8: select item()

9: return() 10: return(item)

11: can return (item)

12: [barrower is allowed to return this item]

13: set status()
Fig: collaboration diagram for use case Return Item

11: can return (item)

12: [barrower is allowed to return this item]
:Return item :Borrow
Controller er
4: get matching(criteria)
7: get item()
:Title
13: set status()

:item
3: search(criteria)
6: get item(title)
10: return(item)
5: select title()
1:8:specify
selectcriteria()
item()
2:9:search()
return()
:Return
item
: Borrower
Sequence diagram for use cases:

Checkout Item:

: Borrower : CheckoutItemForm : : Title : Borrower : Item

CheckoutItemCont...
1: specify citeria()

2: search() 3: search(criteria)
4: get matching(criteria)

5: select title() 6: get items(title) 7: get items()

8: select item()

9: checkout() 10: checkout(item)

11: can checkout(item)

12: checkout(item)
13: set status()
 1: Specify criteria()
2: Search()
5: select title()
8: select item()
: Item
9: checkout()

: :Borrower

: checkoutItemForm
3: search(criteria)
6: getitem(title)
10: checkout(item)

: Borrower

4: getmatching(criteria)
7: getitems()

:
: Title
checkoutItemController

Fig: collaboration diagram for Checkout Item

Sequence diagram for use case login:

: UserLocator

:EmployeeActor : EmployeeLoginUI : LoginWorkflow : User

displayLoginForm()

submitName AndPassword()

validateLogin()
findbyName()

NULL( )

INVALID

displayErrorMessage()

CREC/CSE
Page 26
 9: displayErrorMessages( )

1: displayLoginForm( )
2: submitNameAndPassword( )

: : EmployeeLoginUI
EmoloyeeActor
3: validateLogin( )
8: INVALID

7: INVALID

6: validateLogin( )
: User : LoginWorkFlow
5: USEROBJECT

4: findByName( )

: UserLocator

Fig: collaboration diagram for login

Activity diagram for library application:

student librarystaff librarian staff

submit
submit verify details Issue cards application
Application
3 cards

Take cards check for take cards

reference
borrow

non ref ref borrow

Renewal
books
issue books
Return search another
type of
book
transaction
Reference
take the
book return books

Get the Book

search
update books
database

search and
read books
update
members book
 STATE MACHINE DIAGRAM FOR THE TITLE CLASS:

Available
entry/ Number of reservations = 0

Title reservation / Number of reservations ++

Reservation removed[ Number of reservations = 1 ] / Number of reservations --

Title reservation / Number of reservations++

Reserved

Reservation removed[ Number of reservation = 1] / Number of reservation --

not reserved title reservation/reserved copies++

Entry:reservation num=0

reserved
reservation removed/reserved copies--

STATE DIAGRAM FOR LIBRARY SYSTEM

Component diagram :

Component diagram for library application:

Figure1:

Student issue
register.java

librarian.j item.java
ava

Figure2:

itemmjr.ja itemDAO
va .java

itemDAO. itemDAOA
mysql.java cess.java
Deployment diagram for library applications
Deployment usually refers to transfering the project to the required end users along with
the project documentation.Deployment diagrams are also essential in each application since
it narrates packaged scenario of interaction following is a deployment diagram referring to
unified library application scenario

Figure 1:

student/staff

library
database

library
management

Figure 2:

<<processor>>
library system <<processor>>
{book server}

<<processor>>
<<processor>> <<check out
login server
 Case Study 2: STUDENT INFORMATION SYSTEM:
Problem statement:-

To find the information regarding students studying in

a particular institute which include attendence and marks

Usecase diagram

lecturer a amend student

find student
add student

check grades

delete student
 MAINTAIN STAFF INFO

<<include>>

maintain staff info maintain attendence

<<uses>>
<<include>> <<include>>

performence

maintain subjests info

maintain time table

register for course

write examinations
student

pay fee
 MAINTAIN CURRICULUM

<<include>>

maintain curriculum introduce new course

<<include>>
<<include>>

update syllabus
maintain in take details

maintain circulam

maintain stu info

registrar

maintain staff info

Class diagram:

+1..*
University
Department
uni_name
dept_name
uni_code
has dept_id
uni_clz
+1
con_class()
admissions()
con_exam()
schedule()
<<aggregation>> <<aggregation>>
+1 +1..*
assigned to head of

<<aggregation>>
reffered
member

+*
+1..*
Student +1..*
Staff
stu_name
Course staff_name
stu_id
attends teaches staff_id
stu_add cou_name +* +1..*
staff_add
stu_ph cou_id
staff_ph +1
cou_type
attend_class()
take_class()
listen()
evaluate()
write_exam()
Class diagram:

Department
name
number
Fax num
HOD

find()
Delete()
Amend()

Scot law

Student b Module
Name code
Adress Module leader
Student number level
Gender +has +canTake name
1..* 1..*
Find() Find()
add() select()
Delete() change()
Amend() Allocate()
Sequence diagram:

student application interview admission

1:send

2:attend

3:[pass] admit

Collaboration:

1: 1:send
student application

2: 2:attend
3: 3:[pass] admit

admission interview
Sequence diagram:

Department Module student

: lecturer a
1: find()

2: add()

3: Select()

4: list()

Collaboration:

1: find()
Departm
ent

: lecturer a

3: Select() 2: add()

4: list()
Module student
ACTIVITY DIAGRAMS

student sends a
req for grade

confirms that the given req

student no is available

NO check pass?

YES check%<65

check%>75 NO

third class YES

second class
first class
 start

get the marks of

all the students

calculate
percentages

if%>=75

yes

A grade

no

if 60<=%<75

yes

B grade
no

if %<60 no

yes
C grade stop process
 Start

Enter student
details

<<Condition Checking>> <<Condition Checking>>

ValidStudentId( Yes )
Invalid id Cancel ValidStudent Id( No ) Calculate
check student id
Request Attendence

Display Results

End Calculate Marks

End
End
 STATE TRANSITION DIAGRAM FOR STUDENT INFORMATION

State chart diagram

Probatio
Create nal

Sucessfully completed 6 months period

On successful completion of 6 month period Permane

nt

Resigned

Left
 initialization add student/set c=0 open Entry:Register students
Do:initialize batch Exit: increment student

[c=n]
cancel
cancel

cancelled Do:notify cancel close Do:finalize

registered students batch

STATE TRANSITION DIAGRAM FOR STUDENT INFORMATION

student state chart diagram
Open Entry:Register
Initialization add student set c=0 student Exit:Increment student
do:initialize batch

cancel
cancel

cancelld do:notify Grades Do:> 75% 1st class

registered students < 65% and > 50%2nd class < 50% & pass 3rd class

cancel

close
do:finalize batch
Component diagram

Departm
ent

Course
Student

Deployment diagram

Staff

Login Studen
server t
Case study 3:

Bank ATM SYSTEM:

Problem statement:-

S/w system is to be designed for supporting a computerized ATM banking

n/w.All the accounts maintained in the bank and also the transactions effected,including
ATM transactions ,are to be processed by the computers in the bank.

An ATM accepts a relevant cash card interacts with the user,communicates with
the central system to carry out the transaction,dispenses cash,and print receipts.

The system to be designed and implemented must include appropriiate record

keeping and security provisions.The system must handle concurrent accesses to the
same account.

CREC/CSE
Page 46
 USE CASE DIAGRAM:

changepin customer session

<<include>>
<<include>> verifycheque

enquiry
Transaction depositcheque

viewbal view a/c details viewtransHistory transfer

<<include>> <<include>>

<<include>>
withdrawl

<<include>>

<<extend>>
<<include>>
Deposite amount
<<include>> <<include>>

verifymindetail
<<include>>
report out of bal

<<include>>

verify a/c type

update balance update trans history
 ATM CLASS DIAGRAM:

Bank server
ATM card customer server_id : int bank server
a/c no : str name : string operations
card no : int
OWN name : str location : str
a/c no : int
card type : str add : str valid pin()
phone no : int
uses commit() change pin()
rollback()
withdrawl() create a/c()
deposit() delete a/c()
session transfer() view details()
session id view bal() update details()
a/c no trans()
trans id valid pin()
change pin()
performs
session()
Account
Acc_no : int
holds a/c_type : str
bal : float
Transaction()
no commit()
trans_id rollback()
trans_type add()
amt

commit()
add()

saving a/c current a/c

ENQUIRY ACTIVITY DIAGRAM

New Sw imla ne New Sw imlane2

customer session bank s

enter pin no

insert card card blocked

valid no of
times
display menu yes

enter pin

validate pin

view transaction
history(1)

request for
enquiry

get type of view a/c

enquiry details b

get all previous

view transaction
balance(2)

get current
display balance
generated info

get a/c
details

CREC/CSE
Page 49
 customer : ATM : Bank
machine server
1: Insert card

2: Obtain Pin

3: Enter Pin

4: Validate Pin

5: Valid Pin

6: Enter deposit amt

7: Deposit Amt

8: Open deposit slot

9: Insert Envelop amt slot

10: Envelop recived

SEQUENCE DIAGRAM
COLLABORATION

1: Insert card
3: Enter Pin
custome 7: Deposit Amt
r

2: Obtain Pin : ATM

6: Enter deposit amt machine
8: Open deposit slot
9: Insert Envelop amt slot
10: Envelop recived

5: Valid Pin
4: Validate Pin

: Bank
server
 customer : session : Bank
server
1: Insert Card

2: Obtain Pin

3: Enter Pin

4: Send Pin

5: Request

6: Obtain types of enquiry

7: Type

8: Get a/c no's

9: seif

10: Bal enquiry

11: Current bal

12: Transaction history

13: Previous trans

14: View a/c details

15: Display(a/c no,bal,names)

SEQUENCE DIAGRAM
 custome
r
1: Insert Card
7: Type

9: seif
3: Enter Pin
5: Request
6: Obtain types of enquiry

: session
11: Current bal
13: Previous trans
15: Display(a/c no,bal,names)

2: Obtain Pin
4: Send Pin
8: Get a/c no's
: Bank
10: Bal enquiry
server
12: Transaction history
14: View a/c details
Enquiry collaboration:

COLLABORATION
 customer : ATM : Bank
machine server
1: Insert Card

2: Validate Pin

3: Validate

4: Choose Transaction

5: Withdraw
6: Check Balance

7: Sufficiant Balance

8: Creadit cash

9: Insufficiant Balance

10: Low balance

Withdraw sequence diagram:

COLLABORATION

custome 1: Insert Card

r 4: Choose Transaction

5: Withdraw
8: Creadit cash : ATM
10: Low balance machine

3: Validate
7: Sufficiant Balance
9: Insufficiant Balance

2: Validate Pin
6: Check Balance

: Bank
server
ACTIVITIY FLOW

customer ATM bank serv er

insert card

enter PIN validate PIN

:validation
start transaction
select [success]
transaction

:transaction
withdraw
receive cash

close
:receipt
transaction
print
 STATE CHART FOR ATM

idle enter/pressed ready

press [first digit>0]

next enter/pressed validate invalid

number

valid

transactions cancel pressed cancel

complete cancelled

customer ATM
account Machine

bank
manager
balance
withdraw enquiry

checking saving
account account

COMPONENT Diagram:
Component diagram:A sample component files

index.html

Parallel
port.exe

iput32.dll
cmd.exe

Deployement diagram:

Atm machine
location -A

console

bank
Atm machine server
location b
Case Study 4: cellular phone system

Problem statement:

The cellular network must place the phone call currently,and also

schedule the receiving and conference calls.

Usecase diagram:

Cellular
system

Isdn Call

<<Generalization>>
Local Call <<uses>>

<<Generalization>> <<uses>>

<<Generalization>> STD Call <<uses>>

<<uses>>
Call Connect Services
<<uses>> <<uses>>

Call is drop after it is connected

<<extend>>

Message Sevices Miscellaneos

<<uses>> <<uses>>
<<uses>>
<<uses>>
Call Drop <<uses>>

MSG Delivery MSG Sending GPRS WAP Other

Class diagram:

telephone line
subscriber telephone no
name
1..n 1..n 0..n
adrdress 1

make a call()

1 operator

chek bill()
+1
register new sub scriber()

0..n

call
Organization
individual callee number
business registration no.
ID date
start time
end time

call details()
sequence diagram

Subscriber : Telephone line call control :call

SampleModel

lift telephone receiver

request number

dial number
dial number

start call
create

replace telephone receiver

end call

set end time

collaboration diagram

call Telephone
control line
4: dial number
5: start call
8: end call
6: create
9: set end time1: lift telephone receiver 2: request number
3: dial number
7: replace telephone receiver

:call Subscriber :
SampleModel
STATE DIAGRAM

initial state

idle on hook

dial
on hook

talk

ready to
busy dial

busy

connecting ringing destination

altered
 Timeout

<Dial digit>
<After 15 sec>

<dial> Dialing
Idle DialTone

<dial invalid>
<Start> <Dial Valid>
Invalid
Connecting

Toling
<busy>
<Available>
Busy
<Calle Hung up>

Toling2 Ringing
 Lift telephone
receiver

wait for dial tone

dial number

[answered]
[busy or no one answers]

talk

replace telephone
receiver

ACTIVITY diagram for elaboration of make a call

Component diagram

Telephone
billingGUI

call
controlor
Billing db
server

:OPERATORPC

:Telephone swith
InterfacePC

:ServerPC

DEPLOYMENT DIAGRAM
Case study 5: Trading System

Problem statement:

The trading system must take care of sales information of the company
and must analyze the potential of the trade.

Usecase diagram:

Trading
System

Places Order <<include>>

<<uses>> Center Delivery
User
<<include>>
Order Delivery

Operates Order <<uses>>

<<Generalization>> Home Delivery
<<Generalization>> <<include>>

<<include>>
<<include>>
Check Password
Operator
Validation <<include>>

Instant Order Future Order

Check Availability
Place Order Trace Order
Class diagram:

customer
number order
name places number
address date
1 1..n type
request()
receive() 1
1..n contains
1..n
supplies orderline
number
1..n for quty
product name
number 1..n
name
1
colour ware house
unit price 1 city
stored in phone number
1..n
add()
delete()
Sequence diagram:

customer clerk supplier warehouse

place order()

chek product

request stock

product available()

deliver product

collaboration diagram

5: deliver product
clerk customer

1: place order()

2: chek product

4: product available()

supplier warehouse

3: request stock
ACTIVITY DIAGRAM FOR TRADING SYSTEM

customer sends an
order request

order request, system

confirms the receipt of ...

if order is
no normal? yes confirm the
order

order is special?
yes

dispatch the
order

no

STATE TRANSITION DIAGRAM FOR TRADING SYSTEM

Idle send order normal quit select normal or

request special order

confirm event
failures
order
confirmation

complete transaction diapatch

order
COMPONENT DIAGRAM

purchase reorder
check

stock
balance

receive
order place
order

DEPLOYMENT DIAGRAM:

ORDER
CUSTOMER

DATABASE
SERVER