1.

Object Modelling using UML

The Unified Modelling Language, or UML, is a set of diagrammatic techniques, which are
specifically tailored for object-oriented development, and which have become an industry standard
for modelling object-oriented systems.
The UML grew out of the work of James Rumbaugh, Orady Booch and Ivor Jacobson, and has been
approved as a development standard by the Object Management Group.

Software Developers use specialized diagrams to model the system that they are working on
throughout the development process. Each model produced represents part of the system or some
aspect of it, such as the structure of the stored data, or the way that operations are carried out. Each
model provides a view of the system.

The principal UML diagrams with brief descriptions

Model View of the system

Use case How the system interacts with its users.
The data elements in the system and the relationships
Class between them.
Interaction How the objects interact to achieve the functionality of a use
(sequence and case.
collaboration)
How the different objects of a single class behave through all
State the use cases in which the class is involved.
Activity The sequence of activities that make up a process.
The different software components of the system and the
Component dependencies between them

Deployment The software and hardware elements of the system and the
physical relationships between them.
 2. Use Cases:

Introduction
Once you have developed an initial set of functional requirements during the
Requirements Gathering phase you will have a good understanding of the intended
behavior of the system. This includes what functionality is desired, what constraints
are imposed, and what business objectives will be satisfied. However, one
shortcoming of a traditional 'laundry-list' of requirements is that they are static and
don't adapt to the different business processes that need to be supported by one
feature.
For example, in a fictitious online library system, the functionality for managing
returns would need to handle the separate situations where a borrower returns a book
early and when they return it late. Although the same functionality is involved, they
are different situations and the system would need to handle the separate conditions
in each use case.
Definition:
A use case diagram of a software system describes the functionalities to be implemented by the software
system. It is at a relatively higher level of abstraction compared to the other UML diagrams and will not
include implementation details. Hence, it could be considered as a schematic view of the requirements for the
software system. Together with the narratives for the use cases, the use case view provides a complete set of
requirements for the system.
What is a Use Case?
A use case is a definition of a specific business objective that the system needs to accomplish. They do this by
describing the various external actors (or entities) that exist outside of the system, together with the specific
interactions they have with the system to accomplish the business objective.
Why Are They Important?
The major benefits that come with the creation of use cases are in the planning stage of development. Factors
such as requirements gathering, defining scope, and roadmap creation are all improved through these use cases.
They also allow the team to determine the best possible outcome scenario, accurately depicting the intended
design and use of the system. When it comes to less-than-ideal use cases, the brainstorming of these alternative
possible outcomes helps developers identify potential problems before they happen.
How to Write a Use Case
Thankfully, writing a use case can be broken down into three basic steps or questions that need to be answered:

Who is going to use the product?

What will it be used for?

How are they going to use it?

These questions form the basis of any successful use case, and should be used as a starting guide when writing
your own. Beyond that, use cases can be as high-level or detailed as they need to be for the audience and
system. The key to an effective and helpful use case is to carefully consider the flow of events for a typical user,
and use those to form the use case.
What to Include in a Use Case
As you’re writing your use case, there are several components that should typically be included. These range
from the identifier of the use case to who are involved and alternative solutions:
Use case number - assigning a number to each use case helps organize your records and can be sorted
in chronological order or by other criteria depending on how the developers decide to label them.
Use case name, description, and goal - giving a clear and concise name, description, and goal to each
use case also helps organize documentation while preventing scope creep.
Actor - this is someone or something that performs a behavior or action (can be a person or an object).
If we take an e-commerce site as an example, actors might include buyers, credit card companies,
shipping companies, and more.

Stakeholders - anyone with interests in the functionality and success of the system are called
stakeholders, and are often indirectly involved (not users but those that benefit from how the system
functions).

Primary actor - this is someone or something whose goals are fulfilled by the system in question, and
while they don’t always start the use case, it’s fairly common for them to do so.
Pre-conditions - the statements about what needs to happen before the use case starts.
Triggers - used to start a use case, triggers are events that initiate the steps of a scenario.

Post-conditions - the statements about the possible states that the system can be in after the use case
ends.

Basic flow - also called the main success scenario, this is a use case path that works perfectly and as
intended with no exceptions (this is often used as a base to create alternative paths).
Alternative path (or flow) -a variation of the main success scenario, these usually show what happens
when there’s an error or unexpected event in a use case.
Types of Use Case
Use cases can be described either at an abstract level (known as a business use-case) or at an implementation-
specific level (known as a system use case). Each of these is described in more detail below:

Business Use Case - also known as an "Abstract-Level Use Case", these use cases are written in a
technology-agnostic manner, simply referring to the high-level business process being described
(e.g. "book return") and the various external actors that take part in the process (e.g. "borrower",
"librarian", etc.). The business use case will define the sequence of actions that the business needs to
perform to give a meaningful, observable result to the external entity.

System Use Case - also known as an "Implementation Use Case", these use cases are written at a more
granular level of detail than the business use case and refer to specific processes that will be carried
out by different parts of the system. For example, a system use case might be "return
book when overdue". It would then describe the interactions of the various actors (borrower,
librarian, etc.) with the system in carrying out the end-to-end process.
Symbols in Use Case diagram : Actor:
An actor represents an external entity that interacts with a system. Since it is external to the system, the actor
itself is not fully modelled by the system.
User of a system is a typical example of an actor. Other types of actors include software systems that are being
integrated with the current system (e.g., a network protocol, a database system, a file system), external hardware
such as a sensor and so on.

Actors are classified into primary actors (also called active actors) and secondary actors (also called passive
actors)
5 relationship types in a use case diagram.
• Association between actor and use case
• Generalization of an actor
• Extend between two use cases
• Include between two use cases
• Generalization of a use case

Use Case:
A use case represents a functionality (typically a requirement) that is expected to be implemented by
the system. The details of a use case, other than its unique name, are not represented visually in the
diagram; such details are given in use case narratives. Depending on the application domain and the
choice made by the designer, a use case may be broken down into several use cases which are
connected through <<include>> or <<extend>> relationships (described later in this document).
Generalization:
This represents a relationship between actors or between use cases. If two actors are related through this
relationship, then the actor (or use case) at the tail end of the arrow (connected to the base of the
triangle) is a specialized version of the actor (or use case) at the other end.

Association:
This represents a two-way communication between an actor and a use case and hence is a binary
relation. Since it is a two-way communication, for every use case initiated by a primary actor, the
actor must get a response back from the use case.

Extend relationship: The use case is optional and comes after the base use case. It is represented by a
dashed arrow in the direction of the base use case with the notation
<<extend>> .
Include relationship: The use case is mandatory and part of the base use case.

• error or unexpected event in a use case.

Example: ATM SYSTEM

Unified Modeling Language, Tools

UML

Unified Modeling Language (UML) is a general purpose modelling language. The main aim of UML is to
define a standard way to visualize the way a system has been designed. It is quite similar to blueprints used in
other fields of engineering.

UML is not a programming language, it is rather a visual language. We use UML diagrams to portray the
behavior and structure of a system. UML helps software engineers, businessmen and system architects with
modelling, design and analysis. The Object Management Group (OMG) adopted Unified Modelling Language
as a standard in 1997. Its been managed by OMG ever since. International Organization for Standardization
(ISO) published UML as an approved standard in 2005. UML has been revised over the years and is reviewed
periodically.

Do we really need UML?

Complex applications need collaboration and planning from multiple teams and hence require a clear and
concise way to communicate amongst them.
Businessmen do not understand code. So UML becomes essential to communicate with non programmers
essential requirements, functionalities and processes of the system.
A lot of time is saved down the line when teams are able to visualize processes, user interactions and
static structure of the system.
UML is linked with object oriented design and analysis. UML makes the use of elements and forms
associations between them to form diagrams. Diagrams in UML can be broadly classified as:
Structural Diagrams – Capture static aspects or structure of a system. Structural Diagrams include:
Component Diagrams, Object Diagrams, Class Diagrams and Deployment Diagrams.
Behavior Diagrams – Capture dynamic aspects or behavior of the system. Behavior diagrams include:
Use Case Diagrams, State Diagrams, Activity Diagrams and Interaction Diagrams.
The image below shows the hierarchy of diagrams according to UML 2.2

Object Oriented Concepts Used in UML –

Class – A class defines the blue print i.e. structure and functions of an object.
Objects – Objects help us to decompose large systems and help us to modularize our system.
Modularity helps to divide our system into understandable components so that we can build our
system piece by piece. An object is the fundamental unit (building block) of a system which is
used to depict an entity.
Inheritance – Inheritance is a mechanism by which child classes inherit the properties of their parent
classes.
Abstraction – Mechanism by which implementation details are hidden from user.
Encapsulation – Binding data together and protecting it from the outer world is referred to as
encapsulation.
Polymorphism – Mechanism by which functions or entities are able to exist in different forms.
Additions in UML 2.0 –
Software development methodologies like agile have been incorporated and scope of original UML
specification has been broadened.
Originally UML specified 9 diagrams. UML 2.x has increased the number of diagrams from 9 to 13.
The four diagrams that were added are : timing diagram, communication diagram, interaction
overview diagram and composite structure diagram. UML 2.x renamed statechart diagrams to state
machine diagrams.
UML 2.x added the ability to decompose software system into components and sub- components.

3. Structural UML Diagrams –

Class Diagram – The most widely use UML diagram is the class diagram. It is the building block of
all object oriented software systems. We use class diagrams to depict the static structure of a system
by showing system’s classes,their methods and attributes. Class diagrams also help us identify
relationship between different classes or objects.
Composite Structure Diagram – We use composite structure diagrams to represent the internal
structure of a class and its interaction points with other parts of the system. A composite structure
diagram represents relationship between parts and their configuration which determine how the
classifier (class, a component, or a deployment node) behaves. They represent internal structure of a
structured classifier making the use of parts, ports, and connectors. We can also model collaborations
using composite structure diagrams. They are similar to class diagrams except they represent
individual parts in detail as compared to the entire class.
Object Diagram – An Object Diagram can be referred to as a screenshot of the instances in a system
and the relationship that exists between them. Since object diagrams depict behaviour when objects
have been instantiated, we are able to study the behaviour of the system at a particular instant. An
object diagram is similar to a class diagram except it shows the instances of classes in the system. We
depict actual classifiers and their relationships making the use of class diagrams. On the other hand,
an Object Diagram represents specific instances of classes and relationships between them at a point
of time.
Component Diagram – Component diagrams are used to represent how the physical components in
a system have been organized. We use them for modelling implementation details. Component
Diagrams depict the structural relationship between software system elements and help us in
understanding if functional requirements have been covered by planned development. Component
Diagrams become essential to use when we design and build complex systems. Interfaces are used by
components of the system to communicate with each other.
Deployment Diagram – Deployment Diagrams are used to represent system hardware and its
software.It tells us what hardware components exist and what software
components run on them.We illustrate system architecture as distribution of software artifacts over
distributed targets. An artifact is the information that is generated by system software. They are primarily
used when a software is being used, distributed or deployed over multiple machines with different
configurations.
Package Diagram – We use Package Diagrams to depict how packages and their elements have
been organized. A package diagram simply shows us the dependencies between different packages
and internal composition of packages. Packages help us to organise UML diagrams into
meaningful groups and make the diagram easy to understand. They are primarily used to organise
class and use case diagrams.

Behavior Diagrams –

State Machine Diagrams – A state diagram is used to represent the condition of the system or
part of the system at finite instances of time. It’s a behavioral diagram and it represents the
behavior using finite state transitions. State diagrams are also referred to as State machines and
State-chart Diagrams . These terms are often used interchangeably.Sosimply, a state diagram is
used to model the dynamic behavior of a class in response to time and changing external stimuli.
Activity Diagrams – We use Activity Diagrams to illustrate the flow of control in a system. We
can also use an activity diagram to refer to the steps involved in the execution of a use case. We
model sequential and concurrent activities using activity diagrams. So, we basically depict
workflows visually using an activity diagram.An activity diagram focuses on condition of flow and
the sequence in which it happens. We describe or depict what causes a particular event using an
activity diagram.
Use Case Diagrams – Use Case Diagrams are used to depict the functionality of a system or a part
of a system. They are widely used to illustrate the functional requirements of the system and its
interaction with external agents(actors). A use case is basically a diagram representing different
scenarios where the system can be used. A use case diagram gives us a high level view of what
the system or a part of the system does without going into implementation details.
Sequence Diagram – A sequence diagram simply depicts interaction between objects in a
sequential order i.e. the order in which these interactions take place.We can also use the terms
event diagrams or event scenarios to refer to a sequence diagram. Sequence diagrams describe how
and in what order the objects in a system function. These diagrams are widely used by
businessmen and software developers to document and understand requirements for new and
existing systems.
Communication Diagram – A Communication Diagram(known as Collaboration Diagram in
UML 1.x) is used to show sequenced messages exchanged between objects. A communication
diagram focuses primarily on objects and their relationships. We can represent similar information
using Sequence diagrams,however, communication diagrams represent objects and links in a free
form.
Timing Diagram – Timing Diagram are a special form of Sequence diagrams which are used to
depict the behavior of objects over a time frame. We use them to show time and duration
constraints which govern changes in states and behavior of objects.
Interaction Overview Diagram – An Interaction Overview Diagram models a sequence of
actions and helps us simplify complex interactions into simpler occurrences. It is a mixture of
activity and sequence diagrams.
Example: CONFERENCE MANAGEMENT SYSTEM(UML diagram)

AIM:
To implement a software for Conference management system

PROBLEM STATEMENT:
The Conference Management System is an online website in which candidate can
submit the paper and register themselves and then attend the conference. The paper will be reviewed. The
details of the conference, date and time will be made available to them through the website. After getting the
confirmation details the candidate should submit the revised and camera ready paper. Then the registration
process will be done.

SOFTWARE REQUIREMENT SPECIFICATION:

INTRODUCTION
This software specification document consist full set of features and function for online conference management
system. In this we give specification about the system requirements that are apart from the functionality of the
system to perform the candidate paper valuation. It tells the usability, reliability defined in use case
specification.

PURPOSE
The purpose of the conference management system is that the system can easily
review the process. The main process in this document is the submission of paper by the candidate, reviewing
process by the reviewer and sending of acknowledgement to the candidates whose paper is selected.

SCOPE
The scope of this conference management process is to select the best candidate from the list of candidates
based on their performance in the process.

DEFINITIONS, ACRONYMS AND THE ABBREVIATIONS

CANDIDATE - The candidate can login and submit the paper to the reviewer. After getting
acknowledgement the candidate will submit the revised and camera ready paper then registration
process will be carried out.
REVIEWER - Reviewer will reviews the paper and sending acknowledgement to the candidate
DATABASE - Database is used to verify login and store the details of selected candidates.
HTML - Markup Language used for creating web pages.
J2EE – Java 2 Enterprise Edition is a programming platform java platform for developing and running
distributed java applications.
HTTP - Hyper Text Transfer Protocol.
TCP/IP – Transmission Control Protocol/Internet Protocol is the communication protocol used to
connect hosts on the Internet.
REFERENCES
IEEE Software Requirement Specification format.
TECHNOLOGIES TO BE USED
HTML
JSP
Java

TOOLS TO BE USED
Eclipse IDE (Integrated Development Environment)
Rational Rose tool (for developing UML Patterns)
OVERVIEW
SRS includes two sections overall description and specific requirements – Overall Description will describe
major role of the system components and inter- connections.
Specific Requirements will describe roles & functions of the actors.

OVERALL DESCRIPTION

PRODUCT PERSPECTIVE
The process of the candidates is to login the conference system and submit the paper through online. Then the
reviewer reviews the paper and sends the acknowledgement to the candidate either paper selected or rejected.

SOFTWARE INTERFACE
Front End Client - The exporter online interface is built using JSP and HTML.
Web Server – Apache Tomcat Server (Oracle Corporation)
Back End - Oracle 11g database

HARDWARE INTERFACE
The BPO system’s server is directly connected to the client systems via ftp. The client systems have access to
the database in the server.

SYSTEM FUNCTIONS
This process of on conference management system are described sequentially through following steps,
The candidate login to the conference management system.
The paper title is submitted.
The paper is been reviewed by the reviewer.
The reviewer sends acknowledgement to the candidate.
Based on the selection, the best candidate is selected.
Finally the candidate registers all details

USER CHARACTERISTICS
Candidate - Logins the conference system and submits the paper then do the registration process.
Reviewer – Review the paper, select best candidate and send acknowledgement to them.

CONSTRAINTS
Although the security is given high importance, there is always a chance of intrusion in the web world
which requires constant monitoring.
The user has to be careful while submitting the information. Much care is required.
ASSUMPTIONS AND DEPENDENCIES
The candidate and reviewer must have basic knowledge of computers and English Language.
Provide privacy and security for the documents and candidate information

USECASE DIAGRAM:
A use case is a methodology used in system analysis to identify, clarify, and
organize system requirements. The use case is made up of a set of possible sequences of interactions between
systems and users in a particular environment and related to a particular goal. It is represented using ellipse.
Actor is any external entity that makes use of the system being modeled. It is represented using stick figure.
The conference management system use cases are:
Paper submission
Review the paper
Send confirmation details
Send revised paper
Registration ACTORS:
Actors are as follows:
Candidate
Reviewer

ACTORS DOCUMENTATION:
Candidate - Logins the conference system and submits the paper then do the registration process.
Reviewer – Review the paper, select best candidate and send acknowledgement to them.
Paper submission – Candidate submits the paper.
Review the paper– The paper is been reviewed by the reviewer and the paper is selected.
Paper confirmation details – The reviewer can send the confirmation details to the candidate.
Revised and camera ready paper – After the paper is selected and the camera ready paper should be
submitted to the reviewer by candidate.
Registration – After submitting the revised paper the candidate wants to register.
 13. Functional Modelling
Functional Modelling gives the process perspective of the object-oriented analysis model and an overview
of what the system is supposed to do. It defines the function of the internal processes in the system with the
aid of Data Flow Diagrams (DFDs).
14. Data Flow Diagrams
Functional Modelling is represented through a hierarchy of DFDs. The DFD is a graphical representation of a
system that shows the inputs to the system, the processing upon the inputs, the outputs of the system as well as
the internal data stores. DFDs illustrate the series of transformations or computations performed on the objects
or the system, and the external controls and objects that affect the transformation.

The four main parts of a DFD are

• Processes,
• Data Flows,
• Actors, and
• Data Stores.

The other parts of a DFD are

• Constraints, and
• Control Flows.

Processes
Processes are the computational activities that transform data values. A whole system can be visualized as a
high-level process. A process may be further divided into smaller components. The lowest-level process may
be a simple function.

Representation in DFD − A process is represented as an ellipse with its name written inside it and contains a
fixed number of input and output data values.

Example − The following figure shows a process Compute_HCF_LCM that accepts two integers as inputs and
outputs their HCF (highest common factor) and LCM (least common multiple).

Data Flows
Data flow represents the flow of data between two processes.
Representation in DFD − A data flow is represented by a directed arc or an arrow, labelled with the
name of the data item that it carries.
The output value is sent to several places as shown in the following figure. Here, the output arrows
are unlabelled as they denote the same value.
The data flow contains an aggregate value, and each of the components is sent to different places as
shown in the following figure. Here, each of the forked components is labelled.
Actors
Actors are the active objects that interact with the system by either producing data and inputting them
to the system, or consuming data produced by the system.
Representation in DFD − An actor is represented by a rectangle. Actors are connected to the inputs
and outputs and lie on the boundary of the DFD.
Example − The following figure shows the actors, namely, Customer and Sales_Clerk in a counter
sales system.

Data Stores
Data stores are the passive objects that act as a repository of data.
Representation in DFD − A data store is represented by two parallel lines containing the name of
the data store. Each data store is connected to at least one process. Input arrows contain information
to modify the contents of the data store, while output arrows contain information retrieved from the
data store. When a part of the information is to be retrieved, the output arrow is labelled. An
unlabelled arrow denotes full data retrieval. A two-way arrow implies both retrieval and update.
Constraints

Constraints specify the conditions or restrictions that need to be satisfied over time.

Representation − A constraint is rendered as a string within braces.

Control Flows
A process may be associated with a certain Boolean value and is evaluated only if the
value is true, though it is not a direct input to the process. These Boolean values are
called the control flows.
Representation in DFD − Control flows are represented by a dotted arc from the
process producing the Boolean value to the process controlled by them.

Example − The following figure represents a DFD for arithmetic division. The
Divisor is tested for non-zero. If it is not zero, the control flow OK has a value
True and subsequently the Divide process computes the Quotient and the
Remainder.