Experiment No.

-1
Study of UML Diagram
1.1 Introduction to UML
Unified Modeling Language (UML) is a standardized (ISO/IEC 19501:2005), general
purpose modeling language in the field of software engineering. The UML includes a set of
graphic notation techniques to create visual models of object-oriented software-intensive
system.
The Unified Modeling Language was developed by Grady Booch, Ivar Jacobson and James
Rumbaugh at Rational Software in the 1990s.It was adopted by the Object Management
Group (OMG) in 1997, and has been managed by this organization ever since. In 2000 the
Unified Modeling Language was accepted by the International Organization for
Standardization (ISO) as the industry standard for modeling software-intensive systems. The
current version of the UML is 2.4.1 published by the OMG in August 2011.
1.1.1 UML Diagrams
UML has 14 types of diagrams divided into two categories. Seven diagram types represent
Structural information, and the other seven represents general types of behavior, including four
that represent different aspects of interactions. These diagrams can be categorized hierarchically
as shown in the figure.1:

Class Diagram
Component Diagram
Object Diagram
Structure Diagram

Profile Diagram
Composite Structure
Diagram
Demployment
Diagram,
Package
Diagram

Diagram

Activity Diagram
Use Case Diagram
Behavior Diagram

State Machine Diagram

Sequence Diagram

Interaction Diagram

Communication
Diagram
Interaction Overview Diagram
Timing Diagram

Fig.1 UML Diagram Hierarchy

Structure Diagrams
They emphasise the things that must be present in the system being modeled.Since
structure diagrams represents the structure, they are used extensively in documenting the
software architecture of a system.
Class Diagram: describes the structure of a system by showing the systems
classes,their attributes,and the relationships among the classes.
Component Diagram: describes how a software system is split up into
components and shows the dependencies among these components.
Composite Structure Diagram: describes the internal structure of a class and the
collaborations that this structure makes possible.
Deployment Diagram: describes the hardware used in system implementations
and the execution environments and artifacts deployed on the hardware.
Object Diagram : shows a complete or partial view of the structure of an
example modeled system at a specific time.
Package Diagram: describes how a system is split up into logical groupings by
showing the dependencies among these groupings.

 Profile Diagram: operates at the metamodel level to show stereotypes as classes

with the <<stereotype>> stereotype, and profiles as packages with the
<<profile>> stereotype. The extension relation (solid line with closed, filled
arrowhead) indicates what metamodel element a given stereotype is extending.

Behavior Diagrams
It emphasizes what must happen in the system being modeled. Since behavior diagrams
illustrate the behavior of a system, they are used extensively to describe the functionality
of software systems.
Activity Diagram: describes the business and operational step-by-step workflows
of components in a system. An activity diagram shows the overall flow of control.
UML State Machine Diagram: describes the states and the state transitions of
the system.
Use Case Diagram: describes the functionality provided by the system in terms
of actors, their goals represented as use cases, and any dependencies among those
use cases.

Interaction Diagrams
These are the subset of behavior diagrams. It emphasizes the flow of control and data
among the things in the system being modeled.
Communication Diagram: shows the interactions between objects or parts in
terms of sequenced messages. They represent a combination of information taken
from Class,Sequence and Use Case Diagrams describing both static and dynamic
behavior of the system.
Interaction Overview Diagram: provides an overview in which the nodes
represent communication diagrams.
Sequence Diagram: shows how objects communicate with each other in temrs of
a sequence of messages. Also indicates the lifespan of objects relative to those
messages.
Timing Diagram: a specific type of interaction diagram where the focus is on
timing constraints.

1.2 View of UML Diagrams

UML plays an important role in defining different perspectives of a system. These
perspectives are:

DESIGN: design of a system consists of classes,interfaces and collaborations. UML

provides class diagram, object diagram to support this.

IMPLEMENTATION: defines the components assembled together to make a complete

physical system. UML component diagram is used to support the implementation
perspective.
PROCESS: defines the flow of the system. So the same elements used in design are also
used to support this perspective.
COMPONENT: shows the grouped module of a given system using component
diagrams.
DEPLOYMENT: represents the physical node of the system that forms the hardware.
The deployment diagram is used to support this perspective.
And the centre to all of the above views is the USE CASE VIEW which connects all the
four views. A Use case view represents the functionality of the system,so all the other
perspectives are connected to the same.

Fig. showing different views of UML Diagrams

1.3 Features in UML Tools

A UML tool is a software application that supports some or all the notations and smenatics
associated with UML. Its various features are:

DIAGRAMMING:

Diagramming in this context means creating and editing UML diagrams; that is
diagrams that follow the graphical notation of the Unified Modeling Language.The
use of UML diagrams as a means to draw diagrams of mostly objectoriented software is generally agreed upon by software developers. When developers
draw diagrams of object-oriented software, they usually follow the UML notation.
On the other hand, it is often debated whether those diagrams are needed at all,
during what stages of the software development process they should be used, and
how (if at all) they should be kept up to date. The primacy of software code often
leads to the diagrams being deprecated.

FORWARD ENGINEERING:
Forward Engineering is a traditional process of moving high-level abstracts and
logical, implementation-independent designs to the physical implementation of a
system.

REVERSE ENGINEERING:
Reverse engineering in this context means, that the UML tool reads program source
code as input and derives model data and corresponding graphical UML diagrams
from it.

DOCUMENTATION:
Documentation is an integral aspect of a UML tool. Software designing, by nature, is
an abstract process. Apart from a few syntax and semantic ground rules, there are no
other rules. The thought process of a software architect who designs applications
using UML can be lost if the reasons behind certain design decisions are not captured
and well documented. This becomes painfully clear when large systems are
maintained and no one has a clue to why a subsystem was designed in a certain way.
Hence, a UML tool must necessarily provide some way for the designer to document
design decisions in the diagrams by using simple things such as annotations or
comments. In addition to this, the UML tool should support the generation of
reports/listings of the different design elements of the diagram. Apart from the above
features, you should also identify a few features that would definitely be useful to
have in the UML tool.

ROUND TRIP ENGINEERING:

Round-trip engineering refers to the ability of a UML tool to perform code
generation from models, and model generation from code (a.k.a., reverse
engineering), while keeping both the model and the code semantically consistent
with each other. Code generation and reverse engineering are explained in more
detail below.

VERSION CONTROL:

Version control or source control is the management of changes to the documents,

computer programs, largers websites, and other collections of information.

INTEGRATION WITH IDE:

With the increasing use of iterative methodologies for building software systems, it
becomes very difficult to keep the design of the system in sync with the developed
code. Hence, it would be useful if the UML tool provides integration with popular
IDEs. This feature would enable the UML tool to be updated with the changes in the
source code made in the IDE.

1.4 Popular UML Tools

Rational Rose
No discussion of UML tools is complete without the mention of the Rational Rose
modeling tool from Rational Software Corporation. Rational Rose (the Rose stands
for "Rational Object-oriented Software Engineering") is a visual modeling tool for
UML. It comes in different versions suited to different requirements. Rational Rose
provides support for all the standard features that we discussed in the previous
section such as UML diagram support, forward and reverse engineering support, and
documentation and round-trip engineering support. Apart from this, Rational Rose
also provides support for version control, IDE integration, design pattern modeling,
test script generation, and collaborative modeling environment. In addition, Rational
Rose also supports the designing of data models within the same environment. An
interesting feature of Rational Rose is the ability to publish the UML diagrams as a
set of Web pages and images. This enables you to share and distribute your
application design where the Rational Rose tool is not installed.

Poseidon
Poseidon from Gentle ware has its roots in the Agrium open source project. The
Agrium modeling tool evolved as an open source effort and is a useful, full-featured
UML tool freely available under the Open Publication License. Gentle ware has
taken Agrium a step further and turned it into a good modeling tool. Poseidon comes
in different flavors suited to different requirements. Poseidon supports forward and
reverse engineering and documentation generation by using special-purpose plug-ins.
Gentle ware has not forgotten its open source moorings and offers the Poseidon for
UML Community Edition 1.5 free for individual software developers

Together control centre

Together Control Center (formerly from Togethersoft) from Borland is an entire suite
of visual modeling tools for UML. Together Control Center supports UML diagrams,
MVC modeling, forward and reverse engineering, and round-trip engineering, as
well as integration with IDEs such as IBM WebSphere Studio. It supports
comprehensive documentation and a powerful collaborative modeling
environment.An added feature of Together Control Center is the pattern repository.
The pattern repository (similar to the template-driven modeling concept discussed
above) makes frequently used diagrams and design patterns readily available for
reuse in modeling. Together Control Center supports the Rational Unified Process as
well as the Extreme Programming methodologies.

Experiment no.-2
USE-CASE DIAGRAM
DEFINITION:
A use case diagram in the Unified Modeling Language (UML) is a type of behavioral diagram
defined by and created from a Use-case analysis.
The use case diagram shows the position or context of the use case among other use cases.
As an organizing mechanism, a set of consistent, coherent use cases promotes a useful picture of
system behavior, a common understanding between the customer/owner/user and the
development team
AIM/PURPOSE OF USE CASE DIAGRAM:
Its purpose is to present a graphical overview of the functionality provided by a system in terms
of actors, their goals (represented as use cases), and any dependencies between those use cases.
The main purpose of a use case diagram is to show what system functions are performed for
which actor.
ELEMENTS OF USE CASE DIAGRAM
Actors: An actor portrays any entity (or entities) that performs certain roles in a given system.
The different roles the actor represents are the actual business roles of users in a given system.
An actor in a use case diagram interacts with a use case. For example, for modeling a banking
application, a customer entity represents an actor in the application.

Use case: A use case in a use case diagram is a visual representation of a distinct business
functionality in a system. The key term here is distinct business functionality

System boundary: A system boundary defines the scope of what a system will be. A system
cannot have infinite functionality.

Experiment no.-2(A)
AIM: To draw and design use-case diagram for Library Management System.
Problem statement:
The case study titled Library Management System is library management software for the
purpose of monitoring and controlling the transactions in a library. The case study gives us the
complete information about the library and the daily transactions done in a library. We need to
maintain the record of new books and retrieve the details of books available in the library which
mainly focuses on basic operations in a library like adding new member, new books, and
updating new information, searching books and members and facility to borrow and return
books. It features a familiar and well thought-out, an attractive user interface, combined with
strong searching, insertion and reporting capabilities. The report generaton facility of library
system helps to get a good idea of which are the books borrowed by the members, makes users
possible to generate hard copy.

Overall Description:
The modules are for:

Librarian: to maintain and update the records and also to cater the needs of the users.

Member: need books to read and also places various requests to the librarian.

Vendor: to provide and meet the requirement of the prescribed books.

Software Requirements: Rational Rose

Hardware Requirements: 128 MB RAM,Pentium iii processor

Use-Case Diagram:
Actors vs Use-cases
Librarian

Issues a book

Update and maintains records

Request the vendor for a book

Track complaints and fines

Member

Register

Login

Search a book

Request for issue

View history

Request to librarian

Unregister

Books Database

Update records

Show status of the book

Vendor

Provide books to the library

Payment and acknowledgement

Experiment no.-3
CLASS DIAGRAM
DEFINITION
In software engineering, a class diagram in the Unified Modeling Language (UML) is a type of
static structure diagram that describes the structure of a system by showing the systems classes,
their
attributes,
and
the
relationships
between
the
classes.
A class diagram is similar to a family tree. A class diagram consists of a group of classes and
interfaces reflecting important entities of the business domain of the system being modeled, and
the relationships between these classes and interfaces. The classes and interfaces in the diagram
represent the members of a family tree and the relationships between the classes are analogous to
relationships between members in a family free. Interestingly, classes in a class diagram are
interconnected in a hierarchical fashion, like a set of parent classes and related child classes
under the parent classes.
AIM / PURPOSE
Design experts who understand the rules of modeling and designing systems design the systems
class diagrams. A thing to remember is that a class diagram is a static view of a system. The
structure of a system is represented using class diagrams. Class diagrams are referenced time and
again by the developers while implementing the system.
ELEMENTS OF CLASS DIAGRAM
A class diagram is composed primarily of the following elements that represent the systems
business entities:
Class: A class represents an entity of a given system that provides an encapsulated
implementation of certain functionality of a given entity. These are exposed by the class to other
classes as methods. Apart from business functionality, a class also has properties that reflect
unique features of a class. The properties of a class are called attributes. A class is represented by
a rectangle
Interface: An interface is a variation of a class. As we saw from the previous point, a class
provides an encapsulated implementation of certain business functionality of a system. An
interface on the other hand provides only a definition of business functionality of a system. A
separate class implements the actual business functionality.
Package: A package provides the ability to group together classes and/or interfaces that are either

similar in nature or related. Grouping these design elements in a package element provides for
better readability of class diagrams, especially complex class diagrams.

Experiment no.-3(A)
AIM: To draw and design class diagram for Library Management
System.
CLASS DIAGRAM:
Classes identified:
Librarian
Books Database
Member
Vendor

Experiment no.-4
STATE CHART DIAGRAM
DEFINITION
State Chart diagrams, often used in real time embedded systems than in information systems
,show for class, the order in which incoming calls to operations normally occur and the
conditions under which the operation respond and the response. State chart diagram is one of the
five UML diagrams used to model dynamic nature of a system. They define different states of an
object during its lifetime. And these states are changed by events. So State chart diagrams are
useful to model reactive systems. Reactive systems can be defined as a system that responds to
external or internal events.
AIM / PURPOSE
They are class centric view of system functionality, as opposed to sequence diagram and
collaboration diagram which are use case centric view of system functionality
ELEMENTS OF STATE CHART DIAGRAM

States: Oblong boxes which indicate the stable state of the object between events.
Transitions: The solid arrow which shows possible change of states.
Events: The text on the transition before the / showing the incoming call to the object
interface which causes change of the state
Conditions: A Boolean statement in square brackets which qualifies the events.
Actions: The text after the / which defines the object response to the transition between
states.
Extra syntax defines state centric functionality.

Experiment no.-4(A)
AIM: To draw and design state chart diagram for Library Management
System.

STATE CHART DIAGRAM:

States:

Authentication
Successfully logged on or re-login
Search for a book/request the vendor/provide the requested book
Receive acknowledgement
Logged off/re-search/new function

Transitions:

Authenticate Logged in
Logged in search Acknowledgement
Logged in request vendor Provide book Acknowledgement
Logged in provide book Acknowledgement
Acknowledgement Logged off

Experiment no.-5
ACTIVITY DIAGRAM
DEFINITION:
Activity diagram is another important diagram in UML to describe dynamic aspects of the
system.Activity diagram is basically a flow chart to represent the flow form one activity to
another activity. The activity can be described as an operation of the system.So the control flow
is drawn from one operation to another. This flow can be sequential, branched or concurrent.
Activity diagrams deals with all type of flow control by using different elements like fork, join
etc.
AIM/PURPOSE:
The basic purposes of activity diagrams are similar to other two diagrams. It captures the
dynamic behaviour of the system. Other two diagrams are used to show the message flow from
one object to another but activity diagram is used to show message flow from one activity to
another.
ELEMENTS OF ACTIVITY DIAGRAM:

Initial node. The filled in circle is the starting point of the diagram. An initial node isnt
required although it does make it significantly easier to read the diagram.
Activity final node. The filled circle with a border is the ending point. An activity
diagram can have zero or more activity final nodes.
Activity. The rounded rectangles represent activities that occur. An activity maybe
physical, such as Inspect Forms, or electronic.
Flow/edge. The arrows on the diagram.
Fork. A black bar with one flow going into it and several leaving it. This denotes the
beginning of parallel activity.
Join. A black bar with several flows entering it and one leaving it. All flows going into
the join must reach it before processing may continue. This denotes the end of parallel
processing.
Condition. Text such as [Incorrect Form] on a flow, defining a guard which must
evaluate to true in traverse the node.
Decision. A diamond with one flow entering and several leaving. The flows leaving
include conditions although some modelers will not indicate the conditions if it is
obvious.
Merge. A diamond with several flows entering and one leaving. The implication is that
one or more incoming flows much reach this point until processing continues, based on
any guards on the outgoing flow.

Experiment no.-5(A)
AIM: To draw and design activity diagram for library management system.

ACTIVITY DIAGRAM:
Activities:
User Login and Authentication
Search book operation for Reader
Acknowledge and Issue books to the users by the Librarian
Provide books requested by the Librarian from the Vendor
Bill payment from the Librarian to the Vendor
Status of the books updated in the Books Database

Experiment no.-6
SEQUENCE & COLLABORATION DIAGRAM
DEFINITION:
A sequence diagram is an interaction diagram. It deals with the sequence of messages flowing
from one object to another. Sequence diagram is used to visualize the sequence of calls in a
system to perform a specific functionality.
A collaboration diagram is another form of interaction diagram. It represents the structural
organization of the system and the message sent/received. Structural organization consists of
objects and links. The purpose is same as that of sequence diagram. But they are specifically
used to visualize the organization of objects and their interaction.
AIM/PURPOSE:

To capture the dynamic behavior of a system.

To describe the message flow in the system.
To describe the structural organization of the objects.
To describe the interaction among objects.

ELEMENTS OF SEQUENCE/COLLABORATION DIAGRAM:

Lifeline: It represents the individual participant in the interaction.

Message: It represents the communication between lifelines of an interaction.
Gate: It is a message end showing the communication is complete.
Occurrence: It is the interaction fragment showing a moment in time in the beginning or
ending of a message.
Execution (full name - execution specification, informally called activation)
is interaction fragment which represents a period in the participant's lifetime when it is
executing a unit of behavior or action within the lifeline,
sending a signal to another participant,
waiting for a reply message from another participant.

Experiment no.-6(A)
AIM: To draw and design sequence diagram for library management system.

SEQUENCE DIAGRAM:
Sequence diagram for searching and issuing books as per the request of the user from the
librarian:

Experiment no.-6(B)
AIM: To draw and design collaboration diagram for library management
system.

COLLABORATION DIAGRAM:
Collaboration diagram for searching and issuing the books as per the request of the user from the
librarian :