UNIFIED MODELING LANGUAGE & DESIGN

PATTERNS LAB RECORD

Submitted in partial fulfillment of the requirements
for the Unified Modeling Language and Design Patterns lab in IV year of
Bachelor of Technology In ________CSE/IT

By:
NAME
:
ROLLNUMBER :

M. ABHILASH
11BQ1A1234

DEPARTMENT OF INFORMATION TECHNOLOGY

VASIREDDY VENKATADRI INSTITUTE OF TECHNOLOGY

NAMBUR(V), PEDAKAKANI(M), GUNTUR-522 508
Tel no: 0863-2118036, url:www.vvitguntur.com
Approved by AICTE and affiliated to JNTUK

VASIREDDY VENKATADRI INSTITUTE OF TECHNOLOGY

NAMBUR(V), PEDAKAKANI(M), GUNTUR-522 508
Tel no: 0863-2118036, url:www.vvitguntur.com
Approved by AICTE and affiliated to JNTUK

DEPARTMENT OF INFORMATION TECHNOLOGY

CERTIFICATE

Certified that this is a bonafied record of practical work done by

M.Abhilash (11BQ1A1234) of IV B.Tech 1 Semester in the Unified
Modeling Language and Design Patterns lab during the academic
year June 2014 to October 2014

No. of experiments done: 12

Signature of the In charge

Head of the Department

Internal examiner

External examiner

INDEX
SNo

Topic
INTRODUCTION TO UML
INTRODUCTION TO CASE TOOLS

1.

2.

3.

4.

5.

6.
7.
8.
9.
10.
11.
12.

CASE STUDY-1 AUTOMATED TELLER MACHINE SYSTEM

USE CASE DIAGRAM
ACTIVITY DIAGRAM
SEQUENCE DIAGRAM
COLLOBARATION DIAGRAM
DEPLOYMENT DIAGRAM
COMPONENT DIAGRAM
STATE DIAGRAM
CASE STUDY-2
LIBRARY MANAGEMENT SYSTEM
USE CASE DIAGRAM
SEQUENCE DIAGRAM
COLLOBARATION DIAGRAM
CLASS DIAGRAMS
ACTIVITY DIAGRAM
STATE CHART
COMPONENT DIAGRAM
DEPLOYMENT DIAGRAM
CASE STUDY -3 ONLINE BOOK SHOP
USE CASE DIAGRAM
ACTIVITY DIAGRAM
SEQUENCE DIAGRAM
COLLOBARATION DIAGRAM
CLASS DIAGRAM
CASE STUDY -4
RAILWAY RESERVATION SYSTEM
USE CASE DIAGRAM
ACTIVITY DIAGRAM
CLASS DIAGRAM
COLLOBARATION DIAGRAM
SEQUENCE DIAGRAM
COMPONENT DIAGRAM
DEPLOYMENT DIAGRAM
CASE STUDY -5 BANK MANAGEMENT SYSTEM
USE CASE DIAGRAM
CLASS DIAGRAM
SEQUENCE DIAGRAM
COLLOBARATION DIAGRAM
ACTIVITY DIAGRAM
COMPONENT DIAGRAM
DEPLOYMENT DIAGRAM
DOCUMENT EDITOR
ABSTRACT FACTORY
BUILDER
FAADE
BRIDGE
DECORATOR
CHAIN OF RESPONSIBILITY

INTRODUCTION TO UML

I) Introduction to UML:

Page no
5
6
12
12
13
14
15
16
17
18
20
26
28
33
38
40
42
43
45
46
46
47
48
49
50
51
52
53
55
55
56
58
57
60
60
61
62
63
69
73
74
81
96
101
106
109
113
116

The Unified Modeling Language (UML) is a standard language for specifying,

visualizing, constructing, and documenting the artifacts of software systems, as well as
for business modeling and other non-software systems. The UML represents a
collection of best engineering practices that have proven successful in the modeling of
large and complex systems. The UML is a very important part of developing object
oriented software and the software development process. The UML uses mostly
graphical notations to express the design of software projects. Using the UML helps
project teams communicate, explore potential designs, and validate the architectural
design of the software.
Goals of UML:
1. Provide users with a ready-to-use, expressive visual modeling language so they
can develop and exchange meaningful models.
2. Provide extensibility and specialization mechanisms to extend the core concepts.
3. Be independent of particular programming languages and development
processes.
4. Provide a formal basis for understanding the modeling language.
5. Encourage the growth of the OO tools market.
6. Support higher-level development concepts such as collaborations, frameworks,
patterns and components.
7. Integrate best practices.
Each UML diagram is designed to let developers and customers view a software system
from a different perspective and in varying degrees of abstraction. UML diagrams
commonly created in visual modeling tools include:
Use Case Diagram displays the relationship among actors and use cases.
Class Diagram models class structure and contents using design elements such as
classes, packages and objects. It also displays relationships such as containment,
inheritance, associations and others.
Interaction Diagrams Interaction Overview Diagram which can picture a control flow
with nodes that can contain interaction diagrams. The interaction overview diagram is
similar to the activity diagram, in that both visualize a sequence of activities.
Sequence Diagram displays the time sequence of the objects participating in the
interaction. This consists of the vertical dimension (time) and horizontal dimension
(different objects).

Collaboration Diagram displays an interaction organized around the objects and their
links to one another. Numbers are used to show the sequence of messages.
State Diagram displays the sequences of states that an object of an interaction goes
through during its life in response to received stimuli, together with its responses and
actions.
Activity Diagram displays a special state diagram where most of the states are action
states and most of the transitions are triggered by completion of the actions in the source
states. This diagram focuses on flows driven by internal processing.
Physical Diagrams
Component Diagram displays the high level packaged structure of the code
itself. Dependencies among components are shown, including source code
components, binary code components, and executable components. Some
components exist at compile time, at link time, at run times well as at more than
one time.1

Deployment Diagram displays the configuration of run-time processing

elements and the software components, processes, and objects that live on them.
Software component instances represent run-time manifestations of code units.

Use Case Diagrams

A use case is a set of scenarios that describing an interaction between a user and a
system. A use case diagram displays the relationship among actors and use cases. The
two main components of a use case diagram are use cases and actors.

An actor is represents a user or another system that will interact with the system you are
modeling. A use case is an external view of the system that represents some action the
user might perform in order to complete a task.

Class Diagrams
Class diagrams are widely used to describe the types of objects in a system and their
relationships. Class diagrams model class structure and contents using design elements

such as classes, packages and objects. 2 Class diagrams describe three different
perspectives when designing a system, conceptual, specification, and implementation. 1
These perspectives become evident as the diagram is created and help solidify the
design. This example is only meant as an introduction to the UML and class diagrams.
If you would like to learn more see the Resources page for more detailed resources on
UML.
Classes are composed of three things: a name, attributes, and operations. Below is an
example of a class.

Class diagrams also display relationships such as containment, inheritance, associations

and others.2 Below is an example of an associative relationship:

The association relationship is the most common relationship in a class diagram. The
association shows the relationship between instances of classes. For example, the class
Order is associated with the class Customer. The multiplicity of the association denotes
the number of objects that can participate in the relationship. For example, an Order
object can be associated to only one customer, but a customer can be associated to many
orders.
Another common relationship in class diagrams is a generalization. A generalization is
used when two classes are similar, but have some differences. Look at the generalization
below:

Interaction Diagrams
Interaction diagrams model the behavior of use cases by describing the way groups of
objects interact to complete the task. The two kinds of interaction diagrams are
sequence and collaboration diagrams. This example is only meant as an introduction to
the UML and interaction diagrams. If you would like to learn more see the Resources
page for a list of more detailed resources on UML.
Interaction diagrams are used when you want to model the behavior of several objects
in a use case. They demonstrate how the objects collaborate for the behavior. Interaction
diagrams do not give a in depth representation of the behavior. If you want to see what a
specific object is doing for several use cases use a state diagram. To see a particular
behavior over many use cases or threads use an activity diagrams.
Sequence diagrams, collaboration diagrams, or both diagrams can be used to
demonstrate the interaction of objects in a use case. Sequence diagrams generally show
the sequence of events that occur. Collaboration diagrams demonstrate how objects are
statically connected. Both diagrams are relatively simple to draw and contain similar
elements.
Sequence diagrams:
Sequence diagrams demonstrate the behavior of objects in a use case by describing the
objects and the messages they pass. the diagrams are read left to right and descending.
The example below shows an object of class 1 start the behavior by sending a message
to an object of class 2. Messages pass between the different objects until the object of
class 1 receives the final message.

Below is a slightly more complex example. The light blue vertical rectangles the objects
activation while the green vertical dashed lines represent the life of the object. The
green vertical rectangles represent when a particular object has control. The represents
when the object is destroyed. This diagrams also shows conditions for messages to be
sent to other object. The condition is listed between brackets next to the message. For
example, a [condition] has to be met before the object of class 2 can send a message() to
the object of class 3.

Collaboration diagrams:
Collaboration diagrams are also relatively easy to draw. They show the relationship
between objects and the order of messages passed between them. The objects are listed
as icons and arrows indicate the messages being passed between them. The numbers
next to the messages are called sequence numbers. As the name suggests, they show the
sequence of the messages as they are passed between the objects. There are many
acceptable sequence numbering schemes in UML. A simple 1, 2, 3... format can be
used, as the example below shows, or for more detailed and complex diagrams a 1, 1.1 ,
1.2, 1.2.1... scheme can be used.

State Diagrams
State diagrams are used to describe the behavior of a system. State diagrams describe all
of the possible states of an object as events occur. Each diagram usually represents
objects of a single class and track the different states of its objects through the system.
State diagrams have very few elements. The basic elements are rounded boxes
representing the state of the object and arrows indicting the transition to the next state.
The activity section of the state symbol depicts what activities the object will be doing
while it is in that state.

All state diagrams being with an initial state of the object. This is the state of the object
when it is created. After the initial state the object begins changing states. Conditions
based on the activities can determine what the next state the object transitions to.

Activity Diagrams
Activity diagrams describe the workflow behavior of a system. Activity diagrams
are similar to state diagrams because activities are the state of doing something. The

diagrams describe the state of activities by showing the sequence of activities

performed. Activity diagrams can show activities that are conditional or parallel.
Activity diagrams show the flow of activities through the system.
Diagrams are read from top to bottom and have branches and forks to describe
conditions and parallel activities. A fork is used when multiple activities are occurring at
the same time. The diagram below shows a fork after activity1. This indicates that both
activity2 and activity3 are occurring at the same time. After activity2 there is a branch.
The branch describes what activities will take place based on a set of conditions. All
branches at some point are followed by a merge to indicate the end of the conditional
behavior started by that branch. After the merge all of the parallel activities must be
combined by a join before transitioning into the final activity state.
An activity diagram is a special kind of state chart diagram that shows the
flow from activity to activity within a system. Activity diagrams address the dynamic
view of a system. They are especially important in modeling the functions of a system and
emphasize the flow of control among objects.
Activity diagram depicts the activities and responsibilities of elements. Activity
diagram have the following type of elements.
Action state
Control flow transition
Initial action state
Final action state
Object flow
Swimlane

Action state:

Shown as a shape with straight top with bottom convex arc on two sides. This
represents processing.

Control flow transition:

Shown as a solid line from source action state to target action state. This
represents that once the source action state completes its processing the target action
state starts its processing.

Initial action state:

Shown as a small solid filled circle, the control flow transition originating
from the initial state specifies the first action state.
[[

Final action state:

Shown as a circle surrounding a small solid filled circle (bulls eye) the control
transition to the final state specifies the final action state.

Object flow:

Shown as a dashed arrow between an action state and an object. This represents
that action state inputs or outputs the object. An input object flow which points to an
action state, represents that the action state inputs the objects, an output object flow
which points to an objects, represents that the action state outputs the objects.

A swimlane:
Shown as a visual region separated from neighboring swimlane by vertical solid
lines on both sides and labeled at the top with the element responsible for action
state within swimlane. This represents responsibility.

Physical Diagrams
There are two types of physical diagrams: deployment diagrams and component
diagrams. Deployment diagrams show the physical relationship between hardware and

software in a system. Component diagrams show the software components of a system

and how they are related to each other. These relationships are called dependencies.
The deployment diagram contains nodes and connections. A node usually represents a
piece of hardware in the system. A connection depicts the communication path used by
the hardware to communicate and usually indicates a method such as TCP/IP.

COMPONENT DIAGRAM:
The component diagram contains components and dependencies. Components represent
the physical packaging of a module of code. The dependencies between the components
show how changes made to one component may affect the other components in the
system. Dependencies in a component diagram are represented by a dashed line
between two or more components. Component diagrams can also show the interfaces
used by the components to communicate to each other.
The combined deployment and component diagram below gives a high level physical
description of the completed system. The diagram shows two nodes which represent
two machines communicating through TCP/IP. Component2 is dependant on
component1, so changes to component 2 could affect component1. The diagram also
depicts component3 interfacing with component1. This diagram gives the reader a quick
overall ventire system.

TOOLS OF UML:
RATIONAL ROSE :

The Rational Rose Family of products is a set of UML modeling tools for software
design. The Unified Modeling Language (UML) is the industry-standard language for
specifying, visualizing, constructing, and documenting the artifacts of software systems.
It simplifies the complex process of software design, creating a "blueprint" for
construction of software systems.

The IBM Rational Rose family is for customers wishing to integrate with legacy
integrated development environments or languages. For more modern architectures
IBM Rational Software Architect and IBM Rational Software Modeler were
developed. These products were created matching and surpassing Rose XDE
capabilities to include support for UML 2.x, pattern customization support, the latest
programming languages and approaches to software development such as SOA and
more powerful data modeling that supports Entity-Relationship modeling.

Rational Rose XDE, an "eXtended Development Environment" for

software
developers, integrates with Microsoft Visual Studio .NET and IBM WebSphere Studio
Application Developer. The Rational division of IBM, which previously produced
Rational Rose, wrote this software.

AgroUML:
ArgoUML is an UML diagramming application written in Java and released under the
open source Eclipse Public License. By virtue of being a Java application, it is
available on any platform supported by Java.

1. All 9 UML diagrams supported though not yet implemented. Only class
diagram and use-case diagrams are more or less fully implemented.
2. Closely follows the UML standard.
3. Platform independent Java 1.5+.
4. Forward engineering (code generation supports C++ and C#, Java, PHP 4, PHP5
5. Python, Ruby and, with less mature modules, Ada, Delphi and SQL).
6. Reverse engineering / JAR/class file import

Star UML
StarUML is an open source software modeling tool that supports UML
(Unified Modeling Language). It is based on UML version 1.4,
provides eleven different types of diagram and it accepts UML 2.0
notation. It actively supports the MDA (Model Driven Architecture)
approach by supporting the UML profile concept and allowing to
generate code for multiple languages.
Features
When you start a new project, StarUML proposes which approach you want to use: 4+1
(Krutchen), Rational, UML components (from Cheesman and Daniels book), default or
empty. Depending on the approach, profiles and/or frameworks may be included and
loaded. If you don't follow a specific approach, the "empty" choice could be used.
Although a project can be managed as one file, it may be convenient to divide it into
many units and manage them separately if many developers are working on it together.
StarUML 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.
StarUML is build as a modular and open tool. It provides frameworks for extending
the functionality of the tool. It is designed to allow access to all functions of the
model/meta-model and tool through COM Automation, and it provides extension of
menu and option items. Also, users can create their own approaches and frameworks
according to their methodologies. The tool can also be integrated with any external
tools.
StarUML supports the following diagram types

Use Case Diagram

Class Diagram
Sequence Diagram
Collaboration Diagram
Statechart Diagram
Activity Diagram
Component Diagram
Deployment Diagram
Composite Structure Diagram

StarUML has also a model verification feature. You can export diagram in different
formats (jpg, bmp, wmf). It also supports a patterns approach and import of
Rational Rose files.
StarUML Generator is platform module to generate various artifacts (like as Microsoft
Word, Excel, PowerPoint, and Text-based artifacts) by templates depending on UML
model elements in StarUML. The users can define their own templates and can apply
many different kinds of templates to the same UML model, so the users can get various
artifacts automatically, easily and fast. The tool supports code generation and reverse
engineering for Java, C# and C++.

VISUAL PARADIGM FOR UML:

Visual Paradigm for UML (VP-UML) is a
UML
CASE Tool
supporting UML 2, SysML and Business Process Modeling Notation
(BPMN) from the Object Management Group (OMG). In addition to
modeling support, it provides report generation and code
engineering capabilities including code generation. It can reverse
engineer diagrams from code, and provide round-trip engineering
for various programming languages.
VP-UML supports 13 types of diagrams:

Class diagram
Use case diagram
Sequence diagram
Communication diagram
State machine diagram
Activity diagram
Component diagram
Deployment diagram
Package diagram
Object diagram
Composite structure diagram
Timing diagram
Interaction overview diagram

VP-UML supports both Entity Relationship Diagrams (ERD) and Object

Relational Mapping Diagrams (ORMD). ERD is used to model the relational
database. ORMD is one of the tools to show the mapping between class from
object-oriented world and entity in relational database world.

Experiment Number: 2
CASE STUDY: AUTOMATED TELLER MACHINE SYSTEM
ATM Scenario Use Case Diagram

Bank officer

Transfer fund

Change pin

Deposit funds

Customer

Make payment

View balance

Withdraw money

Transfer funds

Client

ATM Scenario Activity Diagram

Insert
card
Enter
PIN
Connect

Not connected

Enter
transition
Any more transaction
No more transaction

Remove
card

ATM Scenario Sequence Diagram

A : Atm
machine

ac :
account

B : Bank
client

1: Insert card
Insert PIN
3 : Enter PIN
4 : Verification

5 : PIN ok

6 : Request for transaction

7 : Process transaction
8 : Enter amount

9 : Amount entered
10 : Withdrawal
11 : Withdrawal success
12 : Dispense cash
13 : take cash

14 : Terminate
15 : Print slip
16 : Eject card

ATM Scenario Collaboration Diagram

ATM Scenario Deployment Diagram

ATM Scenario Component Diagram

ATM.exe

Card Reader

Card Reader

Cash Dispenser

ATM Screen

ATM Screen

Card dispenser

ATM Scenario State Transition Diagram

ATM Scenario Class Diagram

Experiment Number: 2

CASE STUDY: LIBRARY MANAGEMENT

SYSTEM

Problem Statement:
A library case study is used to identify user interface modeling problems .The Library
System in the case study could be considered too simple to catch real problems faced during the
modeling of user interfaces. Indeed, the Library System is simple compared with real systems.
However, it has proved sufficiently complex to allow a range of problems to be identified in the
area of user interface modeling.
Actors in Library system are Librarian, Library database, users-normal user, VIP user.
The actor Library System User is a generalization of Librarian and Normal user and VIP user.
Librarians use the Library System to manage the book catalogue and the loan records. Librarians
only need to inform to the Library System when books are checked into and checked out of the
system to be able to manage loan records. Thus, the use cases BorrowBook and ReturnBook,
associated with Librarian, are created.
LibrarySystemUsers can connect to the system, list the books borrowed by a library user
and search for books by author, title, year or a combination of these. Thus,the use cases
associated with LibrarySystemUsers are ConnectToSystem, ListBooksBorrowed ByUser and
SearchBook. ConnectToSystem is considered as a use case since a LibrarySystemUser can login
to the system just to check his/her password. Borrowers can browse the library database without
specifying any condition.
The Library System must guarantee that only registered users can login to the system.
Further, the system must guarantee that borrowers can only perform services associated with
borrowers, and that librarians can only perform services associated with librarians. Books can be
selected while users are searching or browsing the book catalogue. Once a book is selected, users
can check its availability.

Creating Analysis Model:

* Requirements analysis:

Requirements analysis results in the specification of

softwares operational characteristics ; indicates softwares interface with other
system elements ; and establishes constraints that software must meet.
Requirements
analysis allows the software engineer to elaborate on basic
requirements established during earlier requirement engineering tasks and build models
that depict
User scenarios,
Functional activities,
Problem classes and their relationships,
System and class behavior,
The flow of data as it is transformed.
Requirements analysis provides the software designer with a representation of
information, function, and behavior that can be translated to architectural, interface and
component-level designs.

Classification of requirements:

User Requirements
System Requirements.

User Requirements:

They are the statements, in a natural language pulse diagrams of what services the
system is expected to provide and the constraints under which it must operate. The user
requirements for a system should describe the functional and non functional requirements so
that they are understandable by system users without detailed technical knowledge.

System requirements:

They set out the systems functions, services and operational constraints in
detail. The system requirements document should be prcised .It should define exactly what
is to be implemented. It may be part of the contract between the system buyer and the
software developers.

Software System requirements are often classified as:

* Functional requirements:

* Non functional requirements:

These are constraints on the services or functions offered by the system.
They include timing constraints on the development process and standards. Nonfunctional requirements often apply to the system as a whole. They do not usually
apply to individual system features often apply to the system features or services.
* Domain requirements:
These are requirements that come from the application domain of the
system and that reflect characteristics and constraints of that domain. They may
be functional or non-functional requirements.

Classification of Requirements
User Requirements

System Requirements

Functional

Non FunctionalDIAGRAM
Domain
USE-CASE

Importance of Use-case Diagram:

Within the Object-Modeling approach, one of the earlier steps involves building an
USE-CASE Model. The essence of this model is to capture user requirements of a new system,
whether it is being developed from scratch or based on an existing system, by detailing all the
scenarios that users will be performing.

Identifying use-cases:
A use-case captures the interactions that occur between producers
and
consumers of information and the system itself. A use-case is a description of set of
sequence of actions that a system performs that yields an observable result of value to a
particular actor. A use-case is used to structure the behavioral things in a model. A use-case
is realized by collaboration. Graphically, a use-case is rendered as an ellipse with solid
lines, usually including only its name.

Developing a set of use-cases:

The functions or activities performed by a specific actor are listed. These may be
obtained from a list of required system functions, through conversations with customers or
end-users.
Use-case diagram depict the functionality of the system. The use case diagram has
the following types of elements.
1. Actor.
2. Use-case.
3. Association.
1) Actor:
Shown as a stick figure icon. This represents users and external systems with
which the system we are discussing interacts.

2) Use-case:
Shown as an ellipse. This represents a functional requirement that is described from
the perspective of the users of a system.

3) Association:
Shown as a solid line path from an actor to use-case. This represents that the actor
uses the use-case.
Actor
use-case

To implement an Use Case Diagram for Unified Library System.

Requirements:
UseCase, Actor , Relationships.
Procedure:

A use case involves the interaction of actors and the system or other subject. An actor
represents a coherent set of roles that users of use cases play when interacting with these use
cases. Actors can be human or they can be automated systems. For example, in modeling a
Library Management System, processing a book involves, among other things, the interaction
between a Librarian and a Borrower.
We can apply use cases to your whole system. We can also apply use cases to part of your
system, including subsystems and even individual classes and interfaces. In each case, these use
cases not only represent the desired behavior of these elements, but they can also be used as the
basis of test cases for these elements as they evolve during development. Use cases applied to
subsystems are excellent sources of regression tests; use cases applied to the whole system are
excellent sources of integration and system tests. The UML provides a graphical representation
of a use case and an actor. This notation permits us to visualize a use case apart from its
realization and in context with other use cases.
A use-case diagram is typically used to communicate the high-level functions of the
system and the system's scope. To show a use case on a use-case diagram, we draw an oval in the
middle of the diagram and put the name of the use case in the center of, or below, the oval. To
draw an actor (indicating a system user) on a use-case diagram, we draw a stick person to the left
or right of our diagram. Use simple lines to depict relationships between actors and use cases.
The diagram has Usecase Diagram of various actions and Actors Each actor has specified
number of operations and these operations are related to other actors operations
From the given problem statement the following use-cases and Actors were being found:

Actors

Use Cases

Librarian

Login
View All Books
Update Book
Add Book
Delete Book
Manage Book

User

Borrow Book
Return Book
Reserve Book
Renewal Book
Search Book
Feed Back
Login

New User

Request for VIP user

Library Database

Maintain Database
User Registration

VIP user

Request for New Book

Borrow CD
Return CD
Home Delivery

Staff
Student

Library Management system: Use Case Diagram

LibraryDatabase

User

MaintainDatabase

BorrowBook

UserRegistration

ManageBook
Librarian
AddBook

NewUser

ReturnBook

FeedBack
DeleteBook

Staff

VIPUser

ReserveBook

UpdateBook

SearchBook
RequestForNewBook

Login

ReturnCD
HomeDelivery

ViewAllBooks
RenewalBook
Login
Student
RequestForVIPUser

BorrowCD

SEQUENCE DIAGRAM

: user

Registration
Form

Registration

DataBase

1:Request Registration Form

2 :Details For Registration

3 :Give Details

4 :Register

5 :Update Registration

6 :Confirm Registration

B) Add a Book:

System
Interface

: user

Book List

User Account

Sign In
Check Valid or Not

Valid User ID

View Book List

Display Book List

Borrow Book With Title

Search Book

Check User Account

Verify Status

Recheck if Available
Book Not in Account
Issue the Book

c) Borrow A Book

System
Interface

: user

Book List

Library
DataBase

Request for Login

check Valid or not

Valid User

Add Book with title

Check valid or not

Invalid Book Already existed

Add Book With Title

Check valid or not

Valid Book Adder

Update the DataBase

DataBase Updated

d) Return a Book :

System
Interface

: user

User Account

Sign In
Check Valid or not

Valid User

Return a Book
Check User Account
Check Valid or not

Return Valid

Update User Account

COLLABORATION DIAGRAM
a)User Registration:

1: 1:Request Registration Form

: user

Registration
Form

4: 4 :Register
3: 3 :Give Details
6: 6 :Confirm Registration

2: 2 :Details For Registration

5: 5 :Update Registration
Registration

DataBase

b) Add a Book
2: Check Valid or Not
1: Sign In
6: Borrow Book With Title

: user

System
Interface

3: Valid User ID

4: View Book List

5: Display Book List
12: Issue the Book

7: Search Book
9: Verify Status
10: Recheck if Available
8: Check User Account
Book
List
11: Book Not in Account

User
Account

c) Borrow a Book
2: check Valid or not
1: Request for Login
: user

3: Valid User
9: Valid Book Adder

System
Interface

11: DataBase Updated

10: Update the DataBase

4: Add Book with title
6: Invalid Book Already existed 7: Add Book With Title

5: Check valid or not

8: Check valid or not
Library
DataBase
Book
List

CLASS DIAGRAM
From the given problem statement the following attributes and operations were
being found for each of the classes:

Class Name

Attribute

Operations

LibrarySystem

libraryName
libraryIncharge
librarianName

viewLibraryDatabase()
viewUsersList()
librarySystem()

Librarian

qualification
librarianExperience
librarianID
librarianPassword
updateBook

checkDatabase()
addBook()
deleteBook()
librarian()
login()

Database

---

addBooks()
deleteBooks()
addCDs()

deleteCDs()
addMagazines()
deleteMagazines()
database()

Class Name
User

VIPuser

Attribute

Operations

userName
userID
userPassWord

login()

---

requestNewBook()
homeDelivery()
borrowCDs()
returnCDs()
vipuser()

Staff

department
designation

requestForMoreBooks()
staff()

UserDataBase

name
id
branch

working()
notWorking()
userDatabase()

BookList

bookAuthor
bookId

updateBook()
viewBookList()
bookList()

NormalUser

branch

normalUser()

Student
CDList

BorrowBook

--cdID
softwareName

---

student()
updateCD()
viewCDList()
cdList()
booklist()
cdList()

BorrowCD

cdName
staffName

cdList()

Library Management system: Class diagram

LibrarySystem
LibraryName : String
LibraryIncharge : Logical View : String
LibrarianName : String

+m_LibrarySystem

ViewLibraryDatabase()
ViewUsersList()
LibrarySystem()
1..*

+Need for

<<uses>>

+Works in

UsersDatabase
Name : String
Id : Number
Branch : String

Librarian
Qualification : String
LibrarianExperience : Integer
LibrarianID : Number
LibrarianPassword : String
UpdateBook() : Boolean
CheckDatabase()
AddBook()
DeleteBook()
Librarian()
Login()

Working()
NotWorking()
UsersDatabase()
<<uses>>

User
UserName : String
UserID : Name
UserPassword : String
Login()

RequestNewBook()
HomeDelivery()
BorrowCDs()
ReturnCDs()
VIPUser()

BookList
BookAuthor : String
BookId : Integer
UpdateBook()
VIewBookList()
BookList()
1..*

UpdateCDs()
ViewCDList()
CDList()
+Checks

BorrowBook

+Checks
Staff
Department : String
Designation : String

CDList
CDId : LogicalView : String
SoftwareName : String

1..*

NormalUser
Branch : String
NormalUser()

BookList()
CDList()

Student
Student()
1..*
+Borrows

Activity diagram:

AddBooks()
DeleteBook()
AddCDs()
DeleteCDS()
AddMagazines()
DeleteMagazines()
Database()

+m_User

VIPUser

RequestForMoreBooks()
Staff()

Database

BorrowCD
CDName : String
StaffName : String
CDList()

Submit
Application

Issue
Membership
[ Reservation ]

BookBank

Issue
Books

Return
BooksinTime

[ Late Submission ]

[ else ]
Rearrange
Book

CollectFine

State Chart diagram:

Available Entry
entry/ No of Reservations

Remove Reservations / No of Reservations --

Title Reservations / No of Reservations ++

Title Resevation / No of reservations++

Reserverd

Remove Reservations / No of Reservations --

Component diagram:

Library
System

DataBase

User

Librarian

User
DataBase

Normal User

VIP User

Book List

Student
Staff

Deployment diagram:
Any Client
:MidrangeMachine

<<execution environment>>
:AppServer

<<artifact>>
Librarian.war

Library
DB:DBMachine

CD List

EXPEIRMENT #3
CASE
STUDY:

Point

Of

Sale

Terminal

Construct a design element for Point of sale terminal management system that can be used for
buying
and
selling
of
goods
in
the
retail
shop.
When the customer arrives at the post check point with the items to purchase. The cashier
records each item, price and adds the item information to the running sales transaction. The
description and price of the current item are displayed. On completion of the item entry the
cashier informs the sales total and tax to the customer. The customer chooses payment type
(cash, cheque, credit or debit).After the payment is made the system generates a receipt and
automatically updates the inventory. The cashier handovers the receipt to the customer.

USE Case Diagram:-

Activity Diagram :-Sale Transaction

Class Diagram:

State Chart Diagram

Sequence Diagram:-

Collaboration Diagram:-

Deployment Diagram:-

Component Diagram:-

Experiment Number: 4
CASE STUDY: ONLINE BOOK SHOP
Use case diagram:

Activity diagram

Display Welcome
Message

Get Login

Get Password
& Validate

Rejected

Display Item
Information
More
Accept
Selection

Create
Order
Display
Order

Rejected
Accepted

Ship to
Customer

Sequence diagram:

Collaboration diagram

Class diagram:

Experiment Number: 4
CASE STUDY: RAILWAY RESERVATION SYSTEM

Railway Reservation System is a system used for booking tickets over internet. Any
Customer Can book tickets for different trains. Customer can book a ticket only if the tickets are
available.Customer searches for the availability of tickets then if the tickets are available he
books the tickets by initially filling details in a form.Tickets can be booked in two ways by iticket or by e-ticket booking.
In case of i-ticket booking customer can book the tickets online and the tickets are
couriered to Particular customer at their address.But in case of e-ticket booking and cancelling
tickets are booked and cancelled online sitting at the home and customer himself has to take print
of the ticket but in both the cases amount for tickets are deducted from customers account.
For cancellation of ticket the customer has to go at reservation office than fill cancellation form
and ask the clerk to cancel the ticket than the refund is transferred to customer account.After
booking ticket the customer has to checkout by paying fare amount to clerk

Use case diagram:

Activity diagram for booking ticket:

Activity diagram for cancelling ticket

Class diagram:

Collaboration diagram for cancel diagram

Collaboration diagram for booking ticket

Sequence diagram for cancelling ticket

Sequence diagram for booking ticket

Component diagram

Deployment diagram

Experiment Number: 6
CASE STUDY: BANK MANAGEMENT SYSTEM
Use case diagram:

Class Diagram for Banking System:

Online Transaction Sequence Diagram:

Online Transaction Collaboration Diagram:

Client desktop Transaction Sequence Diagram:

Client desktop Transaction Collaboration Diagram:

Login & Logout Sequence Diagram:

Login & Logout Collaboration Diagram:

ATM Transaction Sequence Diagram:

ATM Transaction Collaboration Diagram:

Card Validation Sequence Diagram:

Card Validation Collaboration Diagram:

Pin Validation Sequence Diagram:

Pin Validation Collaboration Diagram:

Web merchant Transaction Sequence Diagram:

Web merchant Transaction Collaboration Diagram:

Activity Diagrams
Online Transaction Activity Diagram:

Client Desktop Transaction Activity Diagram:

ATM Transaction Activity Diagram:

Web Merchant Transaction Activity Diagram:

Component Diagram for Banking System:

Deployment Diagram for Banking System:

DESIGN PATTERNS

1.

2.

3.

4.

Design Patterns: Each pattern describes a problem which occurs over and over
again in our environment, and then describes the core of the problem
Design Patterns are the best solutions for the re-occurring problems in the
application programming environment.
Design Patterns are very much about choices and alternatives. Frequently more
than one design pattern could be used to solve a given problem. E.g. Template
Method vs Strategy, Strategy vs State.
Design Pattern Elements
Pattern Name
Handle used to describe the design problem
Increases vocabulary
Eases design discussions
Evaluation without implementation details
Problem
Describes when to apply a pattern
May include conditions for the pattern to be applicable
Symptoms of an inflexible design or limitation
Solution
Describes elements for the design
Includes relationships, responsibilities, and collaborations
Does not describe concrete designs or implementations
A pattern is more of a template
Consequences
Results and Trade Offs
Critical for design pattern evaluation
Often space and time trade offs
Language strengths and limitations
(Broken into benefits and drawbacks for this discussion)
Design patterns can be subjective.
One persons pattern may be another persons primitive building block.
The focus of the selected design patterns are:
Object and class communication
Customized to solve a general design problem
Solution is context specific

Describing design patterns

Graphical notations, while important and useful, arent sufficient.
They capture the end product of the design process as relationships between
classes
and
objects.
By using a consistent format we describe the design pattern .
Each pattern is divided into sections according to the following template.
Pattern Name and Classification:
it conveys the essence of the pattern succinctly good name is vital, because it will
become part of design vocabulary.

Intent: What does the design pattern do?

What is its rational and intend?
What particular design issue or problem does it address?
Also Known As: Other well-known names for the pattern, if any.
Motivation:
A scenario that illustrates a design problem and how the class and object
structures in the pattern solve the problem.
The scenario will help understand the more abstract description of the pattern that
follows.
Applicability:
Applicability: What are the situations in which the design patterns can be applied?
What is example of the poor designs that the pattern can address?
How can recognize situations?
Structure: Graphical representation of the classes in the pattern using a notation
based on the object Modeling Technique (OMT).
Participants: The classes and/or objects participating in the design pattern and
their responsibilities.
Structure:
Graphical representation of the classes in the pattern using a notation based on the
object Modeling Technique (OMT).
Participants:
The classes and/or objects participating in the design pattern and their
responsibilities.

Collaborations:
How the participants collaborate to carry out their responsibilities.
Consequences:
How does the pattern support its objectives?
What are the trade-offs and result of using the pattern ?
What aspect of the system structure does it let vary independently?
Implementation:
What pitfalls, hints, or techniques should be aware of when implementing the
pattern ?
Are there language-specific issues?
Sample Code:
Code fragments that illustrate how might implement the pattern in c++ or
Smalltalk.
Known Uses:
Examples of the pattern found in real systems.
Related Patterns:
What design patterns are closely related to this one? What are the imp differences?
With Which other patterns should this one be used?

The Catalog of Design Pattern

Abstract Factory:
Provide an interface for creating families of related or dependent objects
without specifying their concrete classes.
Adaptor: Convert the interface of a class into another interface clients expect.
Bridge:
Decouple an abstraction from its implementation so that two can vary
independently.
Builder:
Separates the construction of the complex object from its representation so
that the same constriction process can create different representations.
Chain of Responsibility:
Avoid coupling the sender of a request to its receiver by giving more than
one object a chance to handle the request. Chain the receiving objects and pass the
request along the chain until objects handles it.
Command:
Encapsulate a request as an object, thereby letting parameterize clients
with different request, queue or log requests, and support undoable operations.
Composite:
Compose objects into three objects to represent part-whole hierarchies.
Composite lets clients treat individual objects and compositions of objects
uniformly.
Decorator:
Attach additional responsibilities to an object dynamically. Decorators
provide a flexible alternative to sub classing for extending functionality.
Faade:
Provide a unified interface to a set of interfaces in a subsystem's Facade
defines a higher-level interface that makes the subsystem easier to use.
Factory Method:
Defines an interface for creating an object, but let subclasses decide which
class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Flyweight:
Use sharing to support large numbers of fine-grained objects efficiently.
Interpreter:
Given a language, defining a representation of its grammar along with an
interpreter that uses the representation to interpret sentences in the language.
Iterator:
Provide a way to access the element of an aggregate object sequentially
without exposing its underlying representation.
Mediator:
Define an object that encapsulate how a set of objects interact. Mediator
promotes loose coupling by keeping objects from referring to each other
explicitly, and lets you very their interaction independently.

Memento:
Without violating encapsulation, capture and externalize an objects
internal state so that object can be restored to this state later.
Observer:
Define a one-to-many dependency between objects so that when one object
changes state, all its dependents are notified and updated automatically.
Prototype:
Specify the kinds of objects to create using a prototypical instance, and create new
objects by copying this prototype.
Proxy: Provide a surrogate or placeholder for another object to control access to it.
Singleton:
Ensure a class has only one instance, and provide a point of access to it.
State:
Allow an object to alter its behavior when its internal state changes. the object will
appear to change its class.
Strategy:
Define a family of algorithms, encapsulate each one, and make them
interchangeable. Strategy lets the algorithm vary independently from clients that
use it.
Template Method:
Define the Skelton of an operation, deferring some steps to subclasses. Template
method subclasses redefine certain steps of an algorithm without changing the
algorithms structure.
Visitor:
Represent an operation to be performed on the elements of an object structure.
Visitor lets you define a new operation without changing the classes of the
elements on which it operates.
Organizing the Catalog
Two criteria
Purpose: what a pattern does
Creational: concern the process of object creation
Structural: the composition of classes or objects
Behavioral: characterize the ways in which classes or objects interact and
distribute responsibility
Scope: whether the pattern applies primarily to classes or to objects
Class patterns deal with relationships between classes and their subclasses. These
relationships are established through inheritance, so they are staticfixed at
compile-time. Object patterns deal with object relationships, which can be
changed at run-time and are more dynamic. Almost all patterns use inheritance to
some extent. So the only patterns labeled "class patterns" are those that focus on
class relationships. Note that most patterns are in the Object scope.
Creational class patterns defer some part of object creation to subclasses,
while Creational object patterns defer it to another object. The Structural class

patterns use inheritance to compose classes, while the Structural object patterns
describe ways to assemble objects. The Behavioral class patterns use inheritance
to describe algorithms and flow of control, whereas the Behavioral object patterns
describe how a group of objects cooperate to perform a task that no single object
can carry out alone.
There are other ways to organize the patterns. Some patterns are often
used together. For example, Composite is often used with Iterator or Visitor.
Some patterns are alternatives: Prototype is often an alternative to Abstract
Factory. Some patterns result in similar designs even though the patterns have
different intents. For example, the structure diagrams of Composite and
Decorator are similar.
Figure 1.1 depicts these relationships graphically. Clearly there are many
ways to organize design patterns. Having multiple ways of thinking about patterns
will deepen your insight into what they do, how they compare, and when to apply
them.

Organizing of catalog
Purpose
Creational
Scope Class
Object

Structural

Behavioral

Factory
Method

Adapter
(class)

Interpreter
Template Method

Abstract
Factory
Builder
Prototype
Singleton

Adapter
(object)
Bridge
Composite
Decorator
Facade
Flyweight
Proxy

Chain of
Responsibility
Command
Iterator
Mediator
Memento
Observer
State
Strategy
Visitor

Design Pattern relationship