UML Lab Manual PDF

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 user’s 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 ) 1

 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.

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..*,*,0…1.
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:

 Aggregation is used in class diagram.
Symbol:
Composition:

 Composition is used in class diagram.
Symbol:

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.

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:

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) To model flows of control by time ordering.

(ii) 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:

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

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:

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

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
ATM’s we can make payment transaction at anytime from anywhere.

USE CASE DIAGRAMS:
System
verification
Bank
managedatabase
invalid PIN
<<extend>>
transcation
Bank client ATM machine

<<include>>
deposite balance enquiry valid client

withdrawal
<<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.

CLASS DIAGRAMS OF ATM TRANSACTION:

Bank client ATM machine
-pin card number +atm_mach no.
+deposit() +providing_receipt()
+tranfer() 1 request for 1..*
+display_message()
+withdraw() +status()
+insert_card() +read_card()
+eject_card() +accept_card()
+entering_pin no.() +view_balance()
+notify_successful receipt()
asks for manages
Bank Thirdparity Bank database

+account_number -pin number +card reader_ information
-pin_balance
+verify_card() +updating_dbbase()
+open _account() +system_shut down()
+create_account() 1 1 +sys_start up()
+withdraw_funds() +add_cash()
+verification() +verify_customer id()
+delete_account() +verify_customer status()
+asking _operation()
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.

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>>

COLLOBARATION DIAGRAM OF ATM TRANSACTION:
(Start-up of ATM transaction)

ACTIVITY DIAGRAM OF ATM TRANSACTION:
Bankclient ATM machine Bank
Insert atmcard
enter pin number [submite] read PIN verify PIN
[invalid]
[verification report]
[valid]
Enter amount Request amount
dispense cash update customer account
give recipt
close transcation

STATE CHART DIAGRAMS OF ATM TRANSACTION:
ideal
Insert card
Active
cancel
maintain validate withdraw/enquiery
maintainance
[continue]
selecting processing
[not continue]
printreciept
entry/readcard
exit/ejectcard
COMPONENT DIAGRAM OF ATM TRANSACTION:
ATMdatabase.db ATM.exe transaction

+pin number
+withdraw()
+enquiery()
.tbl it contains it contains it contain

it contains ATM.obj files ATM.java files ATM.dll files
databse tables

DEPLOYMENT DIAGRAM OF ATM TRANSACTION:
ATM machine server RAID farm

Ethernet
RS-232
Bank
ATM.exe

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

 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.

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 can’t 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.

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.

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

Sequence Diagram
Activity diagram

Component Diagram
Deployment Diagram

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:-

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

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

View stock sequence diagram:-
cuatomer mainform controller errormessages database

administrator
1:request book details
2:verify
3:not filled property
4:error message
5:verified
6:retrieve data

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

Add books sequence diagram :-
manager new book add book controller error message database

form
1: request for new book
2:add new book
3:verification
4:not filled properly
5:error message
6:filled property
7:generate id

Modify books sequence diagram :-
manager selector form modification modification errormessage database

form controller
1:request to select book
2:selecting book
3:intimate database
4:retrive data
5:modify
6:verification
7:improper
8:error message

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()
mainform
8: relogin
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

View reports collaboration diagram:-
2: enter id
6: re_enter id 3: verification
administrator mainform controller
1: requestid
8: generate reports
database
7: verified
4: invalid id
5: error message
errormessage
View stock collaboration diagram:-
1: request book details 2: verify

user main form controller
administrator
6: retrieved data
database 5: verified
3: not filled properly
4: error message
error
message

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:-
2: add new books 3: verification

manager new book book
add form controller
1: request for new book
7: generate id
database
6: filled properly
4: not filled property

5: error message
errormessage

Modify collaboration diagram:-
2: selecting book
manager selector modification
form controller
1: request to select book
6: verification
5: modifying
3: intimate database
modification
form
7: improper modification 4: retrive database
error 8: error messages database

message
Delete collaboration diagram:-
1: select book
manager selector
form
3: deleting
2: retriving data
4: update()
deletion database
form

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 1. Enquire ticket availability
2.Reservation and and other details.
ticketing 2. Reserve seats and berths
3.Cancellation etc.
3.Cancel tickets
Counter clerk 1.Form data entry 1.Enter the details into

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

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

System
Fill Cancellation form
Enter data into system
Collect issued ticket

Passenger
Counter Clerk
Cancels ticket
Return money after deduction
Cancellation of issued ticket

Class diagram
Passenger
Clerk
+Name
+Gender +Name
+Age +Gender
+Address +Age
0..* 1..*
+fillForm() +getDetails()
+payFareAmount() +getFareAmount()
+collectTicket() +getTicket()
1 1
1
Reservation System
+processForm()
+reservation()
+fareComputation()
+processTicket()
+printTicket()
1..*
Payment
CreditPayment CashPayment
Class diagram for railway reservation system

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()

Collaboration diagram
1 : requestForm() 4 : entersDetails()
2 : givesForm() 5 : checksAvailability()
3 : returnsFilledForm() 8 : triggersTicket()
: passenger : clerk : reservation system
6 : fareamount 9 : printTicket()
7 : paysAmount() 11 : updates()
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

Activity diagram for Enquiry of seats available
Passenger Clerk Reservation system

Passenger Comes to the Counter
[Fill form details]
[Clerk Enters Details into system] [Trigger Tickets Printing Process]
[Submits form to clerk] [prints the Tickets]

[Verify Availabilities]
Not ok
[Form modified] Ok Not [Issue Tickets]
Ok
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

Deployment diagram
Clients Reservation server
Clerk Reservation Server
Kiosk
Deployment diagram for Railway reservation system

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:-

Activity Diagram:-

Class Diagram for Banking System:-

Sequence diagram for Banking System:-

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 Lexi’s 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 document’s internal
representation?
3. Establishing the user Interface: Lexi’s user interface includes scroll bars,
borders, and drop shadows that embellish the WYSIWYG document
interface. Such embellishments are likely to change as Lexi’s 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. Lexi’s 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?

Fig: Document Editor Design Pattern ( Glyph )

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.
There’s also an abstract class for each kind of widget, and concrete subclasses
implement widgets for specific look-and-feel standards. Widget Factory’s 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 aren’t aware of the concrete classes they’re using.
This pattern captures how to create families of related product objects without
instantiating classes directly. It’s most appropriate when the number and general kinds of
product objects stay constant, and there are differences in specific product families.
The Abstract Factory pattern’s emphasis on families of products distinguishes it from

other creational patterns, which involve only one kind of product object.
Fig : Abstract Factory Design Pattern

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 RTFReader’s parsing algorithm to create
different text representations from RTF documents—just configure the RTFReader with
different subclasses of TextConverter.
The following design represents Builder Design Pattern:
Fig : Builder Design Pattern

9. Using UML design Facade Design pattern.

Intent:
Provide a unified interface to a set of interfaces in a subsystem. Façade 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 : Façade Design Pattern

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.

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

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

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 context—the dialog box as a whole,
For example: Hence it's natural to organize help information according to its
generality—from 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

UML Lab Manual PDF

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

UML Lab Manual PDF

Uploaded by

Copyright:

Available Formats

Pragati Engineering College

Building Blocks of UML :

Unified Modeling Language & Design Patterns( UML ) 1

System Development Phases and UML

Unified Modeling Language & Design Patterns( UML ) 2

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

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

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

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

Unified Modeling Language & Design Patterns( UML ) 3

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

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

It consists of three compartments.

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

Object diagrams: Operations

Unified Modeling Language & Design Patterns( UML ) 4

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

It includes two diagrams – Sequence and Collaboration

(i)Object life time

(ii)The focus of control

A collaboration diagram emphasizes the organization of the objects that participate in an

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

Unified Modeling Language & Design Patterns( UML ) 5

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

(i) To model flows of control by time ordering.

State Chart Diagrams:

Sub State Name

Unified Modeling Language & Design Patterns( UML ) 6

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

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

It represents the different activities in the system.

Sub Activity Name

Decision: A state diagram (and by derivation an activity diagram) expresses a decision

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

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

Unified Modeling Language & Design Patterns( UML ) 8

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

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

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

Unified Modeling Language & Design Patterns( UML ) 9

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

Unified Modeling Language & Design Patterns( UML ) 10

USE CASE DIAGRAMS:

Bank client ATM machine

deposite balance enquiry valid client

Unified Modeling Language & Design Patterns( UML ) 11

CLASS DIAGRAMS OF ATM TRANSACTION:

asks for manages

Bank Thirdparity Bank database

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

SEQUENCE DIAGRAM OF ATM TRANSACTION:

(Overall ATM transaction)

: Bankclient : ATM machine

10 : Transcation successfully finished()

Unified Modeling Language & Design Patterns( UML ) 13

COLLOBARATION DIAGRAM OF ATM TRANSACTION:

(Start-up of ATM transaction)

Unified Modeling Language & Design Patterns( UML ) 14