Pragati Engineering College

Introduction to UML
UML is a language used for visualizing, specifying, constructing and documenting the artifacts of
software intensive system.UML makes a clear conceptual distinction between models, views and
diagrams.
A Model is an element that contains information for a software model.
A View is a visual expression of the information contained in a model, and
A Diagram is a collection of view elements that represent the users specific design thoughts.
UML is a language used for visualizing, specifying, constructing and documenting the artifacts of a
software intensive system.
A Modeling Language:
UML provides the vocabulary and the rules for communication and focus on conceptual and physical
representations of the system. So it is a modeling language.
UML Visualizes:
UML includes both graphical and textural representation and makes easy to visualize the system and
for better understanding.
UML specifies:
UML addresses the specification of all the important analysis, design implementation decisions,
developing and deploying a software intensive system.
UML Constructs:
UML models can be directly connected to a variety of programming languages. And it is sufficiently
expressive and free from any ambiguity to permit the direct execution of models, simulation of
systems, and the instrumentation of running systems.
UML Documents:
UML produces variety of documents, in addition to raw executable code, the aircrafts include
requirements, Architecture, Design, Source code, Project Plans, Test, Prototypes, Releases.

Building Blocks of UML :

Things
Relationships
Diagrams.

Things in UML :
Structural Things

Classes
Interfaces
Collaborations
Use Cases
Active Classes
Components
Nodes Classes

Behavioral Things

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

Interactions
State Machines

Grouping Things

Packages

Annotational Things

Notes

Relationships in UML:
Dependency
Association
1. Aggregation
2. Composition
Generalization
Realization
Diagrams in UML:

Class Diagram
Object Diagram
Usecase Diagram
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
Component Diagram
Deployement Diagram

System Development Phases and UML

Requirements Analysis
o Use-case diagrams
Analysis
o Class Diagrams, Dynamic Model
Design
Additional Classes etc., Technical Infrastructure

Programming
o Convert classes from design to actual code in OOPL
Unit Testing - Class diagrams and specifications
Integration Testing - Component and Collaboration diagrams
System Testing - Use-case diagrams

Class: A class is the descriptor for a set of objects with similar structure, behavior, and
relationships. It is represented by a rectangle.

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

Interface: An interface is a specified for the externally-visible operations of a class,

component, or other classifier (including subsystems) without specification of internal
structure. It is represented by a circle.

Relations:

Association
Dependency
Generalization
Realization

In addition to this there are

Directed Association
Aggregation and
Composition
Association:
An association is a structural relationship that specifies the relation between two objects
when they are at the same level (peer level systems).
An Association can specify the relationship, role of the class and Multiplicity.

An Association used in class diagram, Component diagram, deployment

diagram, usecase diagrams.
The multiplicity can be represented as 1-1..*,*,01.

It is represented as follows:
Directed Association:

Links a semantic association between two classes in the UML diagram.

Directed association is used in class diagram, Component diagram, deployment
diagram, usecase diagrams.

Symbol:
Aggregation:

Links a semantic association between two classes in the UML diagram.

Aggregation is used in class diagram.
Symbol:

Composition:

Links a semantic association between two classes in the UML diagram.

Composition is used in class diagram.

Symbol:

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

Generalization:
Generalization is a specification relationship in which objects of the specialized element (the child )
are substitutable for objects of the generalization element (the parent).It is used in class diagram.
Symbol:

Dependency:
A dependency is a semantic relationship in which if there is any change occurred in one object that
may effect other object.

Dependency is used in class diagram, Component diagram, deployment diagram,

usecase diagrams.

Symbol:

Realization:
Realization is a Specified tool that can be represented by providing a relationship with classifier.

Dependency is used in class diagram, Component diagram, deployment diagram,

usecase diagrams.

Symbol:
---------------------------------------------Class diagrams:
A class diagram is that which represents a set of classes, interfaces, and collaborations and their
relationships, graphically a class diagram is a collection of vertices and arcs.
It consists of three compartments.
<ClassName>
<Attributes>
<Operations>

Uses:

A class diagram is used to model the static design view of a system.

Object diagrams:

Operations

An object diagram shares the same common properties of all other diagrams.
Name
Attributes

Uses:
Operations
An object diagram is used to model
the static design view of a system.

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

UseCase Diagrams:
A usecase diagram shares the common properties as all diagrams. It distinguishes in the contents of
use cases, actors, dependency, and generalization relationships.

Actor
Uses:
A Usecase diagram is used to model the static design view of a system.
Interaction Diagrams:
An Interaction diagram shares the same common properties as all other diagrams. It differs in its
contents

Objects
Links
Messages

It includes two diagrams Sequence and Collaboration

Sequence Diagrams:
A sequence diagram emphasizes the time ordering of messages. Sequence diagrams have two
features that distinguish them from collaboration diagrams.
(i)Object life time
(ii)The focus of control

Collaboration Diagrams:
A collaboration diagram emphasizes the organization of the objects that participate in an
interaction.
Collaboration diagrams have two features that distinguish them from sequence diagrams.
(i)Path
(ii) The Sequence number
Object: It is an instance of a class.

Symbol:
Object name

Stimulus: A Stimulus is a communication between two Instances that conveys information

with the expectation that action will ensue. A Stimulus will cause an Operation to be invoked,
raise a Signal, or cause an Instance to be created or destroyed.
Symbol:

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

It can be annotated by a name. It has a property as Action kind.

Call:

Send:

Return:

------------------------------------------

Create:
<<create>>

Destroy:
<<destroy>>

Uses:
Interaction diagrams are used to model the dynamic aspects of a system. It is obtained in two ways:

(i)
(ii)

To model flows of control by time ordering.

To model flows of control by organization.

State Chart Diagrams:

State: A state is a condition during the life of an object or an interaction during which it satisfies
some condition, performs some action, or waits for some event. It is represented by a rounded
rectangle.
Symbol:
State Name

Sub machine State: A submachine state is a syntactical convenience that facilitates reuse
and modularity. It is a shorthand that implies a macro-like expansion by another state
machine and is semantically equivalent to a composite state.
Symbol:
Sub State Name

Initial State:

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

An initial is a kind of pseudostate that represents the starting point in a region of a

state machine. It has a single outgoing transition to the default state of the enclosing region,
and has no incoming transitions. There can be one (and only one) initial state in any given
region of a state machine. It is not itself a state but acts as a marker.
Symbol:
Final State: A final state represents the last or "final" state of the enclosing composite state.
There may be more than one final state at any level signifying that the composite state can
end in different ways or conditions. When a final state is reached and there are no other
enclosing states it means that the entire state machine has completed its transitions and no
more transitions can occur.
Symbol:

JunctionPoint: Junction Point chains together transitions into a single run-to-completion

path. May have multiple input and/or output transitions. Each complete path involving a
junction is logically independent and only one such path fires at one time. May be used to
construct branches and merges.
Symbol:
Transition: A transition is a directed relationship between a source state vertex and a target
state vertex. It may be part of a compound transition, which takes the state machine from one
state configuration to another, representing the complete response of the state machine to a
particular event instance.
Symbol:

Activity Diagram:
It represents the different activities in the system.
Action State: An action state represents the execution of an atomic action, typically the
invocation of an operation. An action state is a simple state with an entry action whose only
exit transition is triggered by the implicit event of completing the execution of the entry
action. The state therefore corresponds to the execution of the entry action itself and the
outgoing transition is activated as soon as the action has completed its execution.
Symbol:

Sub Activity State: A sub activity state represents the execution of a non-atomic sequence of
steps that has some duration; that is, internally it consists of a set of actions and possibly

Sub Activity Name

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

waiting for events. That is, a sub activity state is a hierarchical action, where an associated
sub activity graph is executed.
Symbol:

Initial State: An initial is a kind of pseudo state that represents the starting point in a region
of a state machine. It has a single outgoing transition to the default state of the enclosing
region, and has no incoming transitions. There can be one (and only one) initial state in any
given region of a state machine. It is not itself a state but acts as a marker.
Symbol:

Final State: A final state represents the last or "final" state of the enclosing composite state.
There may be more than one final state at any level signifying that the composite state can
end in different ways or conditions. When a final state is reached and there are no other
enclosing states it means that the entire state machine has completed its transitions and no
more transitions can occur.
Symbol:
Decision: A state diagram (and by derivation an activity diagram) expresses a decision
when guard conditions are used to indicate different possible transitions that depend on
Boolean conditions of the owning object.
Symbol:

Package: A package is a grouping of model elements. Packages themselves may be nested

within other packages. A package may contain subordinate packages as well as other kinds of
model elements. All kinds of UML model elements can be organized into packages.
Symbol:

Interface:
An interface is a specified for the externally-visible operations of a class,
component, or other classifier (including subsystems) without specification of internal
structure.
Symbol:

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

Component: A component represents a modular, deployable, and replaceable part of a

system that encapsulates implementation and exposes a set of interfaces.
Symbol:

Deployment Diagrams:
Package: A package is a grouping of model elements. Packages themselves may be nested within
other packages. A package may contain subordinate packages as well as other kinds of model
elements. All kinds of UML model elements can be organized into packages.
Symbol:

Node: A node is a run-time physical object that represents a computational resource,

generally having at least a memory and often processing capability as well, and upon which
components may be deployed.
Symbol:
Node Name

Node Instance: A node instance is an instance of a node. A collection of component

instances may reside on the node instance.
Symbol:
Node Name

Unified Modeling Language & Design Patterns( UML )

Pragati Engineering College

1. To create a UML diagram of ATM APPLICATION.

Aim:- To design a UML diagram showing the functionalities of ATM Application.
An automated teller machine (ATM) or automatic banking machine (ABM) is a
computerized telecommunications device that provides the clients of a financial institution with
access to financial transactions in a public space without the need for a cashier, human clerk or bank
teller. On most modern ATMs, the customer is identified by inserting a plastic ATM card with a
magnetic stripe or a plastic smart card with a chip that contains a unique card number and some
security information such as an expiration date or CVVC (CVV). Authentication is provided by the
customer entering a personal identification number (PIN). Using an ATM, customers can access their
bank accounts in order to make cash withdrawals (or credit card cash advances) and check their
account balances as well as purchase cellphone prepaid credit.
With growing usage of the Internet, people are utilizing the convenience of online
shopping and the ability to place an order for what they want at all hours of the day and night, at the
office, home, airport, a cafe, or just about anywhere you can imagine. They want conveniences of
Internet communications to help them improve their productiveness in the day to day balance
between work and personal life. While ATM's have added some convenience to our lives. By using
ATMs we can make payment transaction at anytime from anywhere.

Unified Modeling Language & Design Patterns( UML )

10

Pragati Engineering College

USE CASE DIAGRAMS:

System
verification
Bank

managedatabase

invalid PIN
<<extend>>

transcation
Bank client

ATM machine
<<include>>

deposite

withdrawal

balance enquiry

valid client

<<extend>>

invalid client

ACTORS:
1. BANKCLIENT: the bank client is a primary actor which having an ATM card.
2. ATM MACHINE: The ATM machine is a primary actor which is used to
Perform the online transaction. It is an intermediate
between the bank client and bank.
3. BANK: The Bank is a second actor which will verify the bank client account
and also manages the database.
USE CASES SPECIFICATION OF TRANSACTION:
The use case transaction performs the ATM transaction whenever cardholder is valid. It
contains another use cases like deposited, withdrawal & balance enquiry.
I) MAIN FLOW OF EVENTS:

The bank client must be valid person and have a valid PIN number.
II) EXCEPTION FLOW OF EVENTS:

The bank client is an invalid person.

The client had entered the invalid PIN number.
III) PRECONDITION:

The client must already have an account in the Bank.

IV) POSTCONDITION:

The account database of client is modified after transaction.

Unified Modeling Language & Design Patterns( UML )

11

Pragati Engineering College

CLASS DIAGRAMS OF ATM TRANSACTION:

Bank client

ATM machine

-pin card number

+deposit()
+tranfer()
+withdraw()
+insert_card()
+eject_card()
+entering_pin no.()

+atm_mach no.
1

request for

1..*

+providing_receipt()
+display_message()
+status()
+read_card()
+accept_card()
+view_balance()
+notify_successful receipt()

1
asks for

manages

1
Bank

Thirdparity

+account_number
-pin_balance
+open _account()
+create_account()
+withdraw_funds()
+verification()
+delete_account()

Bank database

-pin number

+card reader_ information

+verify_card()
+system_shut down()
+sys_start up()
+add_cash()
+verify_customer id()
+verify_customer status()
+asking _operation()

+updating_dbbase()

id()

I) PERSISTENCE CLASSES:
Bank client, ATM machine are the persistence classes.
II) NON-PERSISTENCE CLASSES:
Bank, Third-party, Bank database are non-persistence classes.

Unified Modeling Language & Design Patterns( UML )

12

Pragati Engineering College

SEQUENCE DIAGRAM OF ATM TRANSACTION:

(Overall ATM transaction)
: Bankclient

: ATM machine

: Bank

1 : Insert ATMcard()

2 : Request PINnum()
3 : Enter PINnum()
4 : verify PINnum()

5 : valid PIN()
6 : Request amount()

7 : Enter amount()
8 : withdraw checking()
9 : withdraw successfully()
10 : Transcation successfully finished()
11 : dispense cash()

12 : print reciept()

13 : terminate()

<<destroy>>

Unified Modeling Language & Design Patterns( UML )

13

Pragati Engineering College

COLLOBARATION DIAGRAM OF ATM TRANSACTION:

(Start-up of ATM transaction)

Unified Modeling Language & Design Patterns( UML )

14

Pragati Engineering College

ACTIVITY DIAGRAM OF ATM TRANSACTION:

Bankclient

ATM machine

Bank

Insert atmcard

[submite]

enter pin number

read PIN

verify PIN

[invalid]

[verification report]
[valid]
Enter amount

Request amount

dispense cash

update customer account

give recipt

close transcation

Unified Modeling Language & Design Patterns( UML )

15

Pragati Engineering College

STATE CHART DIAGRAMS OF ATM TRANSACTION:

ideal

Insert card
Active
cancel

maintain

withdraw/enquiery

validate

maintainance
[continue]
selecting

processing

[not continue]
printreciept
entry/readcard
exit/ejectcard

COMPONENT DIAGRAM OF ATM TRANSACTION:

ATM.exe

ATMdatabase.db

transaction
+pin number
+withdraw()
+enquiery()

.tbl
it contains
databse tables

it contains
ATM.obj files

Unified Modeling Language & Design Patterns( UML )

it contains
ATM.java files

it contain
ATM.dll files

16

Pragati Engineering College

DEPLOYMENT DIAGRAM OF ATM TRANSACTION:

ATM machine

Ethernet

server

RAID farm

RS-232

ATM.exe

Bank

Unified Modeling Language & Design Patterns( UML )

17

Pragati Engineering College

2. To create a UML diagram of LIBRARY MANAGEMENT SYSTEM.

Aim: To design a UML diagram of Library Management System.
This Library Management System is used accomplish the tasks like issue , return, renewal
the book to the library. To computerize the library system, it should validate the students, staff,
etc...By entering the student_id, and staff_id they used to log into the system.
The library has several volumes of books, journals, magazines, news papers so, this system
should maintain the library database and also it should maintain the student, staff database for
validating them.
To full fill these requirements we can to design this system by making use of the UML
diagrams for better understanding the specifications.
The Library Information System is a stand alone system based application used to automate a library.
This system is used by registered users like staff and students.

To borrow the items from library member have option to Enquiry about that item.

The member must confirm the require book is available before borrowing.

The member must reserve book to borrow.

The member got penalty when the period of time is over.

The Librarian can lend the books to registered members.

The Librarian can take books back when members return books.

The Librarian can renew books to members account.

The Librarian can remove reservation of books.

Actors
Staff:-Interactive actor who uses the library to Enquire, Borrow books, applies for Reserve
books and Pay fine.
Librarian:-Interactive actor responsible for Lending articles, Return articles, Renew books
and Remove reservations.
Student:-Interactive actor who uses the library to Enquire, Borrow books, applies for
Reserve books and Pay fine.
Usecases:
For Library system, we can find the following use-cases:
Enquiry
Borrow books
Reserve books

Unified Modeling Language & Design Patterns( UML )

18

Pragati Engineering College

Pay fine
Lending article
Return article
Renew books
Remove reservation

Usecase Diagram

Usecase Descriptions

1 Use-Case Specification: Enquiry

Description
A registered user can Enquiry about required books/articles.

Flow of Events
Basic Flow
1. Member gives the book title to search.
2. System gives list of related articles which is matched to given string.
3. Member select or may know the required articles is available or not.

Unified Modeling Language & Design Patterns( UML )

19

Pragati Engineering College

Alternative Flows
System displays there is no related books/articles in library.

Preconditions
Member must get memberid from librarian before using the system.

Post-conditions
Member got list of related book information if available, otherwise gives related message.

2. Use-Case Specification: Borrow books

Description
The member wants to borrow books from library through librarian and register it.

Flow of Events
Basic Flow
The librarian can give book if it is available.

Alternative Flows
1. The librarian cant give books if member cross borrowing limit.
2. The member has no reservation to borrow books.

Preconditions
The member must confirm that book is available or not in library.

Post-conditions
The librarian can register the information about borrowing book.
3. Use-Case Specification: Return books
Description
This usecase starts when the user wants to return the borrowed book.
Flow of Events
Basic Flow
Member who borrowed the book is going to return the book.
Alternative Flow
Member is going to penalty when time period is over.
Pre condition
Member has check the time period from the time of borrowing.
Post condition
None.

4. Use-Case Specification: Lending Articles

Description
Librarian is lending the articles to members when they require.
Flow of Events
Basic flow
Librarian checks reservation list from system and lend articles to members.
Alternative flow
None.
Pre condition
Member has provided borrowing book information.

Unified Modeling Language & Design Patterns( UML )

20

Pragati Engineering College

Post condition
Librarian can update article information.

5. Use-Case Specification: Renew books

Description
This usecase is starts when member wants to extends his issue time.
Flow of Events
Basic Flow
Member has the same book by renewing.
Alternative Flow
Member has return book
Pre condition
Member must check time period from issued date.
Post condition
Librarian updates issued list, member gets same copy.

6. Use-Case Specification: Reserve books

Description
This use-case starts when the user wants to make a reservation for an item

Flow of Events
Basic Flow
1. Member who wants to borrow the book, he gives the information about that book.
2. The system marks the item as reserved and associates the borrower with the reservation

Alternative Flows
Member is unable to get book. Re applies for reserve the book.
Pre-conditions
The borrower is viewing a particular title with an item that is not currently available
Post-conditions
The item is marked as reserved and the reservation is saved in the database

7. Use-Case Specification: Remove Reservation

1 Description
The borrower can remove an existing reservation for an item.
Flow of events
Basic Flow
1. The system prompts the borrower for the item information for which the reservation is
removed
2. The borrower enters the item information and submits
3. System marks the item as no longer reserved
Alternative Flows
None.
Pre-conditions
The borrower is viewing a particular Title with an Item that is reserved by the borrower.
Post conditions
None.

Unified Modeling Language & Design Patterns( UML )

21

Pragati Engineering College

8. Use-Case Specification: Pay fine

Description
The member must pay fine if he exceeds the time period from date of borrowing.
Flow of events
Basic Flow
The librarian collects fine from late return members.
Alternative Flow
None.
Pre condition
System prepare late return list based on issued date.
Post-conditions
None.
Class diagram

Unified Modeling Language & Design Patterns( UML )

22

Pragati Engineering College

Sequence Diagram

Activity diagram

Unified Modeling Language & Design Patterns( UML )

23

Pragati Engineering College

Component Diagram

Deployment Diagram

Unified Modeling Language & Design Patterns( UML )

24

Pragati Engineering College

3..To create a UML diagram of ONLINE BOOK SHOP

Aim: To design UML diagrams for Online Book Shop, and the functions takes place in the
application.

Usecase diagram:-

Unified Modeling Language & Design Patterns( UML )

25

Pragati Engineering College

Login sequence diagram:-

user

mainform

loginform

welcomeform

logincontroller

errorcontroller

database

1:login()

2:enter username/password

3:authenticatio

4:enter into database

5:valid

6:invalid

7:error message

8:relogin

Unified Modeling Language & Design Patterns( UML )

26

Pragati Engineering College

View reports sequence diagram:-

administrator

mainform

controller

errormessages

database

1:request id

2:enter id

3:verification

4:invalid

5:errormesage

6:re_enterid

7:verified

8:generate reports

Unified Modeling Language & Design Patterns( UML )

27

Pragati Engineering College

View stock sequence diagram:-

cuatomer

mainform
administrator

controller

errormessages

database

1:request book details

2:verify

3:not filled property

4:error message

5:verified

6:retrieve data

Unified Modeling Language & Design Patterns( UML )

28

Pragati Engineering College

Maintain book stock sequence diagram :-

manager

option form

book profile
form

1:to avial option

2:add books

sequence
diagram
3:update books
sequence
diagram
4:delete books
sequence
diagrams

Unified Modeling Language & Design Patterns( UML )

29

Pragati Engineering College

Add books sequence diagram :-

manager

new book add

form

book controller

error message

database

1: request for new book

2:add new book

3:verification

4:not filled properly

5:error message

6:filled property

7:generate id

Unified Modeling Language & Design Patterns( UML )

30

Pragati Engineering College

Modify books sequence diagram :-

manager

selector form

modification
form

modification
controller

errormessage

database

1:request to select book

2:selecting book

3:intimate database

4:retrive data

5:modify

6:verification

7:improper

8:error message

Unified Modeling Language & Design Patterns( UML )

31

Pragati Engineering College

Delete books sequence diagram :-

manager

selector form

deletion form

database

1:select book

2:retriving data

3:deleting

4:update()

Login collaboration diagram:1: login()

8: relogin

mainform

2: enter username/pas s word

us er

loginform

3: authentication

7: error m es s age
welcom eform

logincontroller

errorm es sage
6: invalid

5: valid
4: enter into database

databas e

Unified Modeling Language & Design Patterns( UML )

32

Pragati Engineering College

View reports collaboration diagram:2: enter id

6: re_enter id

3: verification

administrator

controller

mainform
1: requestid
8: generate reports
database

7: verified

4: invalid id

5: error message

errormessage

View stock collaboration diagram:1: request book details

user

2: verify
main form
administrator

controller

6: retrieved data

database

5: verified
3: not filled properly

4: error message

error
message

Unified Modeling Language & Design Patterns( UML )

33

Pragati Engineering College

Maintain book stock :manager

option
1: to avail option

2: add books
3: update books
4: delete books
book profile
form

Add books collaboration diagram:3: verification

2: add new books

manager

new book
add form
1: request for new book

book
controller

7: generate id
database

6: filled properly

4: not filled property

5: error message

errormessage

Unified Modeling Language & Design Patterns( UML )

34

Pragati Engineering College

Modify collaboration diagram:2: selecting book

manager

selector
form

modification
controller

1: request to select book

6: verification

5: modifying

3: intimate database
modification
form

7: improper modification

8: error messages

error
message

4: retrive database

database

e
Delete collaboration diagram:1: select book
manager

selector
form

3: deleting
2: retriving data
4: update()
deletion
form

Unified Modeling Language & Design Patterns( UML )

database

35

Pragati Engineering College

4.

To create a UML diagram of RAILWAY RESERVATION SYSTEM

Aim:- To design UML diagram for Railway Reservation System.

Reservation counter.
Identification of actors:
The actors in the system are the passenger, the counter clerk and the reservation
system consisting of form processing, reservation, canceling issued ticket, ticket printing and
updating etc.

Use cases:

User

Role

Use case

Passenger

1.Enquiry
2.Reservation and
ticketing
3.Cancellation

1. Enquire ticket availability

and other details.
2. Reserve seats and berths
etc.
3.Cancel tickets

Counter clerk

1.Form data entry

2.Ticket
processing
3.Updation
Server

1.Enter the details into

system
2.Trigger ticket for printing
3.Update data in the system
1. Process reservation data,
process
ticketing
and
process cancellation.
2.Update.

Reservation
system

Unified Modeling Language & Design Patterns( UML )

36

Pragati Engineering College

Use case diagrams

System
Enquiries for availability

Passenger

CounterClerk

Availability status

Passenger enquiries for the availability of Seats

Fill requisition form

Enter data into system

Passenger

Print ticket

Counter Clerk

Collect fare amount & Issues ticket

Reservation and ticketing

Unified Modeling Language & Design Patterns( UML )

37

Pragati Engineering College

System
Fill Cancellation form

Enter data into system

Passenger

Collect issued ticket

Counter Clerk
Cancels ticket

Return money after deduction

Cancellation of issued ticket

Unified Modeling Language & Design Patterns( UML )

38

Pragati Engineering College

Class diagram
Passenger

Clerk

+Name
+Gender
+Age
+Address

+Name
+Gender
+Age

0..*

1..*

+fillForm()
+payFareAmount()
+collectTicket()

+getDetails()
+getFareAmount()
+getTicket()
1

1
1
Reservation System
+processForm()
+reservation()
+fareComputation()
+processTicket()
+printTicket()

1..*
Payment

CreditPayment

CashPayment

Class diagram for railway reservation system

Unified Modeling Language & Design Patterns( UML )

39

Pragati Engineering College

Interaction diagrams
Sequence diagram
: passenger

: clerk

: reservation system

1 : requestForm()

2 : givesForm()

3 : returnsFilledForm()

4 : entersDetails()

5 : checksAvailability()

6 : fareamount

7 : paysAmount()

8 : triggersTicket()

9 : printTicket()

10 : issueTicket()
11 : updates()

Unified Modeling Language & Design Patterns( UML )

40

Pragati Engineering College

Collaboration diagram
4 : entersDetails()

1 : requestForm()
2 : givesForm()

5 : checksAvailability()

3 : returnsFilledForm()
: passenger

: clerk

8 : triggersTicket()

6 : fareamount

: reservation system

9 : printTicket()
11 : updates()

7 : paysAmount()
10 : issueTicket()

Collaboration diagram for reservation

Activity diagrams

[The Data train and tickets]

Data Entered into R&T System

Not Available Puts New Data and Train

R&T Checks Availabillity

Available
Fills Requisition From

R&T Process the Form

Prints Tickets

Tickets Issued and Fare Amount Collected

Unified Modeling Language & Design Patterns( UML )

41

Pragati Engineering College

Activity diagram for Enquiry of seats available

Passenger

Clerk

Reservation system

Passenger Comes to the Counter

[Fill form details]

[Clerk Enters Details into system]

[Submits form to clerk]

[Form modified]

Not ok

[Trigger Tickets Printing Process]

[prints the Tickets]

[Verify Availabilities]

Ok

Not

Ok

[Issue Tickets]

Ok
[Collect Amount]

[Informs the fare amount]

Not ok

[Trigger Update Process]

Confirms with the Passenger

Activity diagram for reservation process

Component diagram
reservation.exe
Reservation form
<<artifact>>
update.exe

cancellation.exe
Cancellation form

Component diagram for reservation and ticketing

Unified Modeling Language & Design Patterns( UML )

42

Pragati Engineering College

Deployment diagram

Clients

Reservation server

Clerk

Reservation Server

Kiosk

Deployment diagram for Railway reservation system

Unified Modeling Language & Design Patterns( UML )

43

Pragati Engineering College

5.To create a UML diagram for Banking System

Aim : To design UML diagrams for Banking System, which includes Banking
Transactions cash withdrawal, deposit money, etc.,
Usecase Diagram:-

Unified Modeling Language & Design Patterns( UML )

44

Pragati Engineering College

Activity Diagram:-

Unified Modeling Language & Design Patterns( UML )

45

Pragati Engineering College

Class Diagram for Banking System:-

Unified Modeling Language & Design Patterns( UML )

46

Pragati Engineering College

Sequence diagram for Banking System:-

Unified Modeling Language & Design Patterns( UML )

47

Pragati Engineering College

6. To design a Document Editor

The design of a What-You-See-Is-What-You-Get for WYSIWYG
document editor called Lexi.
A WYSIWYG representation of the document occupies the large rectangular
area in the center. The document can mix text and graphics freely in a variety of
formatting styles. Surrounding the document are the usual pull-down menus and
scroll-bars, plus a collection of page icons for jumping to a particular page in the
document.
7 Design Problems:
1. Document Structure: The choice of internal representation for the document
affects nearly every aspect of Lexis design. All editing, formatting,
displaying and textual analysis will require traversing the representation. The
way we organize this information will impact the design of the rest of the
application.
2. Formatting: How does Lexi actually arrange text and graphics into lines and
columns? What objects are responsible for carrying out different formatting
policies? How do these policies interact with the documents internal
representation?
3. Establishing the user Interface: Lexis user interface includes scroll bars,
borders, and drop shadows that embellish the WYSIWYG document
interface. Such embellishments are likely to change as Lexis user interface
evolves.
4. Supporting Multiple look-and-feel standards: Lexi should adapt easily to
different look-and-feel standards such as Motif and Presentation
Manager(PM) without major modification.
5. Supporting multiple window systems. Different look-and-feel standards are
usually implemented on different window systems. Lexis design should be
as independent of the window system as possible.
6. User operations. Users control Lexi through various user interfaces,
including buttons and pull-down menus. The functionality behind these
interfaces is scattered throughput the objects in the application. The challenge
here is to provide a uniform mechanism both for accessing this scattered
functionality and for undoing its effects.
7. Spelling checking and hyphenation. How does Lexi support analytical
operations such as checking for misspelled words and determining
hyphenation points? How can we minimize the number of classes we have to
modify to add a new analytical operation?

Unified Modeling Language & Design Patterns( UML )

48

Pragati Engineering College

Fig: Document Editor Design Pattern ( Glyph )

Unified Modeling Language & Design Patterns( UML )

49

Pragati Engineering College

7. Using UML design Abstract factory design pattern.

Factories and products are the key participants in the Abstract Factory pattern.
Different look-and-feels define different appearances and behaviors for user interface
widgets like scroll bars, windows, and buttons. To be portable across look-and-feel
standards , an application should not hard-code its widgets for a particular look and feel.
Instantiating look-and-feel-specific classes of widgets throughput the application makes it
hard to change the look and feel later.
Theres also an abstract class for each kind of widget, and concrete subclasses
implement widgets for specific look-and-feel standards. Widget Factorys interface has an
operation that returns a new widget object for each abstract widget class. Clients call these
operations to obtain widget object for each abstract widget class. Clients call these operations
to obtain widget instances, but clients arent aware of the concrete classes theyre using.
This pattern captures how to create families of related product objects without
instantiating classes directly. Its most appropriate when the number and general kinds of
product objects stay constant, and there are differences in specific product families.
The Abstract Factory patterns emphasis on families of products distinguishes it from
other creational patterns, which involve only one kind of product object.

Fig : Abstract Factory Design Pattern

Unified Modeling Language & Design Patterns( UML )

50

Pragati Engineering College

8. Using UML design Builder Design pattern.

A reader for the RTF(Rich Text Format) document exchange format should be
able to convert RTF to many text formats. The reader might convert RTF documents into
plain ASCII text or into a text widget that can be edited interactively. The problem,
however, is that the number of possible conversion s is open-ended. So it should be easy
to add a new conversion without modifying the reader.
A solution is to configure the RTF Reader class with a TextConverter object that
converts RTF to another textual representation. As the RTF Reader parses the RTF
document, it uses the TextConverter to perform the conversion. Whenever the
RTFReader recognizes an RTF token , it issues a request to the TextConverter to convert
the token. TextConverter objects are responsible both for performing the data conversion
and for representing the token in a particular format.
Subclasses of TextConverter specialize in different conversions and formats. For
example, an ASCII Converter ignores requests to convert anything except plain text. A
TeXConverter, on the other hand, will implement operations for all requests in order to
produce a TEX representation that captures all the stylistic information in the text.
Each kind of converter class takes the mechanism for creating and assembling a
complex object and puts it behind an abstract interface. The converter is separate from the
reader, which is responsible for parsing an RTF Document.
The builder pattern captures all these relationships. Each converter class is called
a builder in the pattern, and the reader is called the Director. The builder pattern
separates the algorithm for interpreting a textual format from how a converted format gets
created and represented. This lets us reuse the RTFReaders parsing algorithm to create
different text representations from RTF documentsjust configure the RTFReader with
different subclasses of TextConverter.
The following design represents Builder Design Pattern:

Fig : Builder Design Pattern

Unified Modeling Language & Design Patterns( UML )

51

Pragati Engineering College

9. Using UML design Facade Design pattern.

Intent:
Provide a unified interface to a set of interfaces in a subsystem. Faade defines a
higher-level interface that makes the subsystem easier to use.

Motivation:
Structuring a system into subsystems helps reduce complexity. Subsystems are groups
of classes, or groups of classes and other subsystems. The interface exposed by the classes in
a subsystem or set of subsystems can become quite complex. One way to reduce this
complexity is to introduce a facade object that provides a single, simplified interface to the
more general facilities of a subsystem

Applicability
Use the Facade pattern:
To provide a simple interface to a complex subsystem. This interface is good enough
for most clients; more sophisticated clients can look beyond the facade.
To decouple the classes of the subsystem from its clients and other subsystems,
thereby promoting subsystem independence and portability

Benefits
It hides the implementation of the subsystem from clients, making the
subsystem easier to use
It promotes weak coupling between the subsystem and its clients. This allows
you to change the classes the comprise the subsystem without affecting the clients.
It reduces compilation dependencies in large software systems
It simplifies porting systems to other platforms, because it's less likely that building
one subsystem requires building all others
It does not prevent sophisticated clients from accessing the underlying classes
Note that Facade does not add any functionality, it just simplifies interfaces

Fig : Faade Design Pattern

Unified Modeling Language & Design Patterns( UML )

52

Pragati Engineering College

10. Using UML design Bridge Design pattern.

When an abstraction can have one of several possible implementations, the usual
way to accommodate them is to use inheritance. An abstract class defines the interface to
the abstraction, and concrete subclasses implement it in different ways. But this approach
isn't always flexible enough. Inheritance binds an implementation to the abstraction
permanently, which makes it difficult to modify, extend, and reuse abstractions and
implementations independently.
Consider the implementation of a portable Window abstraction in a user
interface toolkit. This abstraction should enable us to write applications that work on both
the X Window System and IBM's Presentation Manager (PM), for example. Using
inheritance, we could define an abstract class Window and subclasses XWindow
and PMWindow that implement the Window interface for the different platforms. But
this approach has two drawbacks:
1. It's inconvenient to extend the Window abstraction to cover different kinds of
windows or new platforms. Imagine an IconWindow subclass of Window that
specializes the Window abstraction for icons. To support IconWindows for both
platforms, we have to implement two new classes, XIconWindow and PMIconWindow.
Worse, we'll have to define two classes for every kind of window. Supporting a third
platform requires yet another new Window subclass for every kind of window.
2. It makes client code platform-dependent. Whenever a client creates a window, it
instantiates a concrete class that has a specific implementation. For example, creating an
XWindow object binds the Window abstraction to the X Window implementation, which
makes the client code dependent on the X Window implementation. This, in turn, makes
it harder to port the client code to other platforms.
Clients should be able to create a window without committing to a
concrete implementation. Only the window implementation should depend on the
platform on which the application runs. Therefore client code should instantiate windows
without mentioning specific platforms.
The Bridge pattern addresses these problems by putting the Window abstraction
and its implementation in separate class hierarchies. There is one class hierarchy
for window interfaces (Window, IconWindow, TransientWindow) and a separate
hierarchy for platform-specific window implementations, with WindowImp as its root.
The XWindowImp subclass, for example, provides an implementation based on the X
Window System.

Unified Modeling Language & Design Patterns( UML )

53

Pragati Engineering College

Use the Bridge pattern when

1. You want to avoid a permanent binding between an abstraction and its
implementation. This might be the case, for example, when the
implementation must be selected or switched at run-time.
2. Both the abstractions and their implementations should be extensible by
subclassing. In this case, the Bridge pattern lets you combine the different
abstractions and implementations and extend them independently.
3. Changes in the implementation of an abstraction should have no impact on clients;
that is, their code should not have to be recompiled.
4. (C++) you want to hide the implementation of an abstraction completely
from clients. In C++ the representation of a class is visible in the class interface.
5. You have a proliferation of classes as shown earlier in the first Motivation
diagram. Such a class hierarchy indicates the need for splitting an object
into two parts; Rumbaugh uses the term "nested generalizations"
6. you want to share an implementation among multiple objects (perhaps using
reference counting), and this fact should be hidden from the client. A simple example is Coplien's String class, in which multiple objects can share the
same string representation (StringRep).
The following is the Bridge Pattern :

Fig: Bridge Design Pattern

Unified Modeling Language & Design Patterns( UML )

54

Pragati Engineering College

11. . Using UML design Decorator Design pattern.

Sometimes we want to add responsibilities to individual objects, not to an
entire class. A graphical user interface toolkit, for example, should let you add properties
like borders or behaviors like scrolling to any user interface component. One way to add
responsibilities is with inheritance. Inheriting a border from another class puts a border
around every subclass instance. This is inflexible, however, because the choice of border
is made statically. A client can't control how and when to decorate the component with a
border.
A more flexible approach is to enclose the component in another object that adds
the border. The enclosing object is called a decorator. The decorator conforms to the
interface of the component it decorates so that its presence is transparent to the
component's clients. The decorator forwards requests to the component and may
perform additional actions (such as drawing a border) before or after forwarding.
Transparency lets you nest decorators recursively, thereby allowing an unlimited
number of added responsibilities.
Decorator subclasses are free to add operations for specific functionality. For
example, ScrollDecorator's ScrollTo operation lets other objects scroll the interface if
they know there happens to be a ScrollDecorator object in the interface. The
important aspect of this pattern is that it lets decorators appear anywhere a
VisualComponent can. That way clients generally can't tell the difference between
a decorated component and an undecorated one, and so they don't depend at all on the
decoration.
Use Decorator
1. To add responsibilities to individual objects dynamically and transparently, that is,
without affecting other objects.
2. For responsibilities that can be withdrawn.
3. When extension by subclassing is impractical. Sometimes a large number of
independent extensions are possible and would produce an explosion of subclasses
to support every combination. Or a class definition may be hidden or
otherwise unavailable for subclassing.

Fig: Decorator Design Pattern

Unified Modeling Language & Design Patterns( UML )

55

Pragati Engineering College

12. Design to represent this chain of responsibility Design pattern.

Consider a context-sensitive help facility for a graphical user interface. The user
can obtain help information on any part of the interface just by clicking on it. The help
that's provided depends on the part of the interface that's selected and its context;
for example, a button widget in a dialog box might have different help information
than a similar button in the main window. If no specific help information exists for that
part of the interface, then the help system should display a more general help message
about the immediate contextthe dialog box as a whole,
For example: Hence it's natural to organize help information according to its
generalityfrom the most specific to the most general. Further more,it's clear that
a help request is handled by one of several user interface objects; which one
depends on the context and how specific the available help is. The problem here is that
the object that ultimately provides the help isn't known explicitly to the object (e.g.,
the button) that initiates the help request. What we need is a way to decouple the
button that initiates the help request from the objects that might provide help information.
The Chain of Responsibility pattern define show that happens.
The idea of this pattern is to decouple senders and receivers by giving multiple objects a
chance to handle a request. The request gets passed along a chain of objects until one of
them handles it.
Use Chain of Responsibility :
1. When more than one object may handle a request, and the handler isn't known a
priori. The handler should be ascertained automatically.
2. When you want to issue a request to one of several objects withoutspecifying
the receiver explicitly.
3. When the set of objects that can handle a request should be specified
dynamically.

Fig : Chain of Responsibility Design Pattern

Unified Modeling Language & Design Patterns( UML )

56