A

Case Study Report

On
PASSPORT AUTOMATION SYSTEM

Submitted in partial fulfilment of the

Requirements for the Course of

SOFTWARE ENGINEERING - LAB

IN

BE ¾ (CSE) II-SEMESTER
By

P.PAVAN KUMAR

1602-16-733-087

Department of Computer Science & Engineering

Vasavi College of Engineering (Autonomous)
Ibrahimbagh, Hyderabad-31

2019

1
 Vasavi College of Engineering (Autonomous)
Ibrahimbagh, Hyderabad-31

Department of Computer Science & Engineering

DECLARATION BY THE CANDIDATE

I, P.PAVAN KUMAR, bearing hall ticket number, 1602-16-733-087,

hereby declare that the Case study report entitled “PASSPORT
AUTOMATION SYSTEM” under the guidance of Mrs Garima Jain , Assistant
Professor, Department of Computer Science & Engineering, VCE, Hyderabad
is submitted in partial fulfilment of the requirement for the course of
Software Engineering - Lab in BE ¾ (CSE) II-Semester.

This is a record of bonafide work carried out by me and the Design

embodied in this project report has not been submitted by any other.

P.PAVAN KUMAR,
1602-16-733-087.

2
 Vasavi College of Engineering (Autonomous)
Ibrahimbagh, Hyderabad-31

Department of Computer Science & Engineering

BONAFIDE CERTIFICATE

This is to certify that the project entitled “PASSPORT

AUTOMATION SYSTEM” being submitted by P.PAVAN KUMAR,
bearing 1602-16-733-087, in partial fulfilment of the requirement
for the course of Software Engineering - Lab in BE ¾ (CSE) II-
Semester is a record of bonafide work carried out by him/her under
my guidance.

Mrs. Garima Jain, Dr.T.Adilakshmi,

Assistant professor, professor & HOD,
Internal Guide. Dept. of CSE.
External Examiner

3
 TABLE OF CONTENTS

1. Introduction------------------------------------------------------------------------06

2. Problem Statement----------------------------------------------------------------06

3. SRS----------------------------------------------------------------------------------07

4. Rational Rose Tool----------------------------------------------------------------19

5. System Design---------------------------------------------------------------------26

I. Data Flow Diagram------------------------------26

II. Functional decomposition----------------------34
III. Use-Case Diagram-------------------------------35
IV. Sequence Diagram-------------------------------39
V. Collaboration Diagram--------------------------45
VI. Activity Diagram---------------------------------53
VII. Class Diagram------------------------------------59
VIII. Component Diagram-----------------------------65
IX. Deployment Diagram----------------------------68

6. Forward and Reverse Engineering---------------------------------------------70

7. Test-Cases-------------------------------------------------------------------------73

8. Cost and Resource Estimation and Verification-----------------------------74

9. Rational Functional Tester------------------------------------------------------75

4
 LIST OF FIGURES

S. No Figure Page No
s
1 Level 0 DFD 28
2 Level 1 DFD 29
3 Level 2 DFD 30,31 ,32,33
4 Functional decomposition 34
5 Usecase diagram 38
6 Sequence diagram 42
7 Collaboration diagram 51
8 Activity diagram 57
9 Class diagram(general and advanced) 63,64
10 Component diagram 67
11 Deployment diagram 69
12 Reverse engineering diagram 72

5
 1.INTRODUCTION

a) INTRODUCTION

To simplify the process of applying passport, software has been created by designing
through rational rose tool, using visual basic as a front end and Microsoft access as a
back end. Initially the applicant login the passport automation system and submits his
details. These details are stored in the database and verification process done by the
passport administrator, regional administrator and police the passport is issued to the
applicant.

2) PROBLEM STATEMENT

Passport Automation System is used in the effective dispatch of passport to all of the
applicants. This system adopts a comprehensive approach to minimize the manual work
and schedule resources, time in a cogent manner. The core of the system is to get the
online registration form with details such as name, address etc., filled by the applicant
whose testament is verified for its genuineness by the Passport Automation System with
respect to the already existing information in the database. This forms the first and
foremost step in the processing of passport application. After the first round of
verification done by the system, the information is in turn forwarded to the regional
administrator's Ministry of External Affairs office. The application is then processed
manually based on the report given by the system, and any forfeiting identified can make
the applicant liable to penalty as per the law. The system forwards the necessary details
to the police for its separate verification whose report is then presented to the
administrator. After all the necessary criteria have been met, the original information is
added to the database and the passport is sent to the applicant.

6
 3.Software Requirements Specification

Contents

1. Introduction

1.1 Purpose

1.2 Scope

1.3 Definitions, Acronyms, and Abbreviations

1.4 Overview

2. General Description

2.1 Product Perspective

2.2 Product Functions

2.3 User Characteristics

2.4 General Characteristics

3. Specific Requirements

3.1 Functional Requirements

3.2 Performance Requirements

3.3 Non-Functional Requirements

3.4 Design Constraints

1. Introduction
7
1.1 Purpose

Basic Description of Problem

Passport Automation System is an interface between the Applicant and the Authority
responsible for the Issue of Passport. It aims at improving the efficiency in the Issue of
Passport and reduces the complexities involved in it to the maximum possible extent.

1.2 Scope

 The System provides an online interface to the user where they can fill in their
personal details and submit the necessary documents (may be by scanning).

 The authority concerned with the issue of passport can use this system to reduce his
workload and process the application in a speedy manner.

 Provide a communication platform between the applicant and the administrator.

 Transfer of data between the Passport Issuing Authority and the Local Police for
verification of applicant's information.

 Users/Applicants will come to know their status of application and the date in which
they must subject themselves for manual document verification.

1.3 Definitions, Acronyms, and Abbreviations

 Administrator:

Refers to the super user who is the Central Authority with the privilege to manage the
entire system. It can be any higher official in the Regional Passport Office of Ministry of
External Affairs.

 Applicant:

One who wishes to obtain the Passport.

 PAS:

to this Passport Automation System.

 HTML:

Markup Language used for creating web pages.

8
 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.

1.3 References

1.IEEE Software Requirement Specification format.

1.4Overview

This specification includes a brief product perspective and a summary of the functions
the software will provide. User characteristics are discussed and any general constraints
or assumptions and dependencies are listed.

Requirement statements are categorized as functional requirements, performance

requirements, non-functional requirements, or design constraints.

Functional requirements are further categorized in terms of Analysis, Design,

Implementation, Maintenance and Non-functional requirements are further categorized
in terms of loading speed, memory and transferring data speed.

2. General Description

2.1 Product Perspective

9
The PAS acts as an interface between the 'applicant' and the 'administrator'. This system
tries to make the interface as simple as possible and at the same time not risking the
security of data stored in. This minimizes the time duration in which the user receives
the passport.

2.2 Product Functions

 Secure Registration of information by the Applicants.

 Schedule the applicants an appointment for manual verification of original

documents.

 Panel for Passport Application Status Display by the Administrator.

 SMS and Mail updates to the applicants by the administrator.

 Administrator can generate reports from the information and is the only authorized
personnel to add the eligible application information to the database.

2.3 User Characteristics

 Applicant

These are the person who desires to obtain the passport and submit the information to
the database.

 Administrator

He has the certain privileges to add the passport status and to approve the issue of
passport. He may contain a group of persons under him to verify the documents and
give suggestion whether or not to approve the dispatch of passport.

 Police

He is the person who upon receiving intimation from the PAS, perform a personal
verification of the applicant and see if he has any criminal case against him before or at

10
present. He has been vetoed with the power to decline an application by suggesting it to
the Administrator if he finds any discrepancy with the applicant. He communicates via
this PAS.

2.4 General Constraints

 The information of all the users must be stored in a database that is accessible by
the System.
 The information security system must be compatible with the Internet
applications.
 The users must have their correct usernames and passwords to enter into the
System.

3. Specific Requirements

3.1 Functional Requirements

It is defined as how they should react in the particular input and how the system should
react in the particular situations and what the system do not do. In my project, login as
functional requirement. In that functional requirement we may check the user name and
password is correct or not. After checking entity of login, we can show the detail based
on the type of actor.
 Analysis:
In this place, the project requirement is analyzed and availability of requirement is seen.
 Design:
Project manager makes the design of the project.
 Implementation:
The construction of project is done and coding is developed.
 Maintenance:
In this the software maintenance and the ways to avoid the drawback of software is
made.

3.1.1APPLICANT DETAILS:
 the applicant enter the details such as name,gender,age,address,contact details etc.
When the applicant enter details. the database accepts applicant details.
Specifying details
storage of details in database

3.1.2STATUS ENQUIRY:

 Generates the process of applying and renewing the passport.

 the applicant wishes to apply for the passport first time or wishes to renew the
passport.

11
 .selecting the status
 If successful then the applicant will get the new passport or renew the old passport.

3.1.3.GENERATE UNIQUE ID:

issues unique id for each applicant.
When the applicant submits their details, the administrator will generate and issue a
unique id for each applicant.
The customer details are submitted to the administrator.
Unique id is generated for each customer based of the details provided.

3.1.4.VERIFICATION:

The administrator to verifies the details of applicant.

Verification of passport is done by the admin and report is submitted to the police for
confirmation.
The details are verified using the generated unique id.
If the online detail entered by the applicant does not match with the proof submitted to
administrator, the further process is halted.

3.1.5.CONFIRMATION:

The confirmation process done by the police.

The applicant details are verified by the police.
The passport will be issued, verified details are correct

3.2 Performance Requirements

The PAS shall respond to user's retrieving information quickly. The waiting time for
any retrieve operation must be under 2 seconds

3.3 Non-functional Requirements

This system can load at the speed of 2.4GHz-3.6GHz.

Memory 4GB RAM
Transferring data speed 50 Mbps in time.
It is high portability, reliability, accepting failure rates and user friendly.

 Hardware requirements:
Processor: Pentium –IV
Hard drive: 320 GB
RAM: 4GB
DVD-Drive: 1
Software requirements:
Operating system: Windows XP
Front-end: Rational Rose Enterprise Edition
Back-end: Oracle 9i
12
3.4 Design Constraints

 The applicants require a computer to submit their information.

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

13
 4. RATIONAL ROSE TOOL

RATIONAL UNIFIED PROCESS (OVERVIEW):

The rational unified process or RUP product is a software engineering product. It

provides a disciplined approach to assigning tasks and responsibilities a development
organization. The goal is to ensure the production of high quality software that meets the
needs its end users within a predictable schedule and budget. The six best practices
employed by the Rational Unified Process in terms of its phases and disciplines help us
understand the practices involved in software development. The software development
problems that are encountered are:

1 User or Business needs not met.

2 Requirements Churn.
3 Modules don’t integrate.
4 Hard to maintain.
5 Late discovery of Flaws.
6 Poor quality or end user inexperience.
7 Non coordinated team effort.
8 Build and release issues.

The six best practices employed by RUP to overcome these problems are:

Develop iteratively.

Manage Requirements.

Use component architectures.

Model visually.

Continuously verify quality.

Manage changes.

User Component Architectures:

14
 Architecture is a part of the design. It is about making decision on how the system
will be built. Software system architecture is perhaps the most important aspect that can
be used to control the iterative and incremental development to a system throughout its
lifecycle.

The purpose of this practice is:

1 Meet the current and future requirements.

2 Improve extensibility.
3 Enable reuse.
4 Encapsulate system dependencies.
5 Select from commercially available components.

Model Visually (UML):

A model is a simplification of reality that provides a complete description of a system
from a particular perspective. We build models so that we can understand the system we
are modeling. The main reasons for the modeling are:

1 Capture structure and technique.

2 Show how system elements fit together.
3 Keep design and implementation consistent.
4 Hide or expose details as appropriate.
5 Promote unambiguous communication.

Modeling is important because it helps the development team visualize, specify, construct
and document the structure and the behavior of system architecture.

Visual modeling helps improve a team’s ability to manage software complexity. A

diagram is a graphical representation of a set of elements, most often rendered as a
connected graph of vertices (things) and arcs (relationships).

15
UML includes nine such diagrams:

Use Case Diagram : To illustrate the user intersection with the system

Class Diagram : To illustrate logical structure.

Object Diagram: To illustrate the physical structure of the software.

Deployment Diagram: To shows the mapping of the software- hardware.

Interaction Diagram:To show the collaboration of group of objects.

Sequence &Collaboration:To illustrate behavior.

State Chart & Activity Diagram:To illustrate flow of events

Continuously Verify Quality:

Fifth best practice is quality and is defined as the “Characteristic of having demonstrated
the achievement of producing a product which meets or exceeds agreed upon measures
and criteria and is produced by an agreed upon process.”

Quality must include:

1 Tests for scenarios that all requirements are properly implemented.

2 Verify software reliability------memory leaks, bottlenecks.

3 Verify every iteration

16
The various tests to be performed are:

1.Functionality Test: Test the accurate working of each other scenario.

2. Usability Test: Test application from the perspective of convenience to end-user.

3. Realiability Test: Test the application behaves consistently and predictability.

4. Performance Test: Test on-line response under average and peak loading.

5. Supporting Test: This includes installation and configuration test.

VIEWS:

Rational Rose with UML

Modeling complex systems is an extensive task. If the entire system is described and in a
single graph that defines the entire system unambiguously and is easy to communicate
and understand. However, this is usually impossible. So there are several views
describing the system in depth with different diagrams. The views involved in UML are

Use Case View: a view describes the functionality of the system as perceived by an
external actor. An actor interacts with the system; it can be a user or another system. The
use case view is for customers, designers, developers and testers. The functions of the
systems are descried as a number of use cases in the use case view. The systems for some
functions are represented by use cases.

17
Logical View: A view showing the functionality is designed inside the system in terms
of the systems static structure and dynamic behavior. This is mainly for designers and
developers. The static structure is described in class and object diagram. The dynamic
modeling is described in state, sequence collaboration and activity diagrams.

Component View: A view showing the organization of the code components. This view
is a description of the implementation modules and the dependencies. It is mainly for
developers and consists of the component diagram.

Deployment View: A view showing the deployment of the system into the physical
architecture with computers and devices called nodes and how they connect to each
other. It is mainly for developers and testers.

Diagrams:

The diagrams are the actual graphs that show model element symbols of a system.
There are different types of diagrams to represent the systems functionality and
behavior.

Use-case Diagram: A use case diagram shows interactions of actors with a system in
terms of functions called use-case. A use case is description of a functionality that the
system provides. The actors are external to the system but who interacts with the system;
they may be external persons, external system and hardware.

Class Diagram: A class diagram shows the static structure of classes in the system.

The classes represent the “things” that are handled in the system. Class can be related to
each other in a number of ways: associated, dependent, specialized or packaged. Class
represents attributes and operations.

18
Object Diagram: An object diagram is a variant of the class diagram and uses almost
identical notation. The difference between the two is that an object diagram shows a
number of object instances of classes, instead of actual classes. Objects are written in
rectangular box with their names. object diagrams are written in rectangular box with
their names. Object diagrams are not important as class diagrams, but show the actual
instances of a class and the relationships.

State Diagram: A state diagram is typically a component to the description of a class. It

shows all possible states that the object of the class can have and which events cause the
state to change. An event can be another object that sends a message to it. A change is
called a transition. State diagrams are not drawn for all classes, only for those that have a
number of well-defined states.

State diagram can also be drawn for the system as a whole.

Sequence Diagram: A sequence diagram shows a dynamic collaboration between a

number of objects and shows an interaction between objects. This diagram shows a
number of objects with vertical lines that represent object lifeline. Messages passing
between objects are shown with arrows. This represents the scenario of functions how
they apply.

Collaboration Diagram: It is similar to a sequence diagram however the relationships

are only shown. If time or sequence of events is important then sequence diagrams are
more relevant.

19
Activity Diagram: An activity diagram shows a sequential flow of activities. This is
typically used to describe the activities performed in an operation.

Deployment Diagram: It represents the processors and devices to develop the system
,it shows deployment view of the system.

Component Diagram: A component diagram shows the physical structure of the code in
terms of code components .a component can be a source code component, a binary
component or an executable component. A component contains information about logical
class or classes it implements.

20
 5. SYSTEM DESIGN

I ) Data Flow Diagram

AIM: To draw Data Flow Diagram for PASSPORT AUTOMATION SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : MS Office edition or Paint Application

THEORY:

A data-flow diagram (DFD) is a graphical representation of the "flow" of data through an

information system, It differs from the flowchart as it shows the data flow instead of
the control flow of the program.

It is common practice to draw a context-level data flow diagram first which shows the
interaction between the system and outside entities. The DFD is designed to show how a
system is divided into smaller portions and to highlight the flow of data between those
parts. This context-level data-flow diagram is then "exploded" to show more detail of the
system being modelled. Developing a data-flow diagram helps in identifying the
transaction data in the data model. There are different notations to draw data-flow
diagrams, defining different visual representations for processes, data stores, data flow,
and external entities.

NAME AND NOTATION

External Entity: This notation represents any real world thing (person, place, object,
hardware device).

Data Flow: This notation represents the flow of information from source to destination.

21
Process: This notation represents the transformation and manipulation of data flow
information

Data Store: This is a place which holds the data with in the system i.e. the data which
has been processesed.

There exist three levels of data flow diagram

Level 0(Context level DFD)

Level 1(High level DFD)

Level 2(Purified level DFD)

1. Level 0(Context level DFD)

A context level Data flow diagram created using Select SSADM.This level shows the
overall context of the system and its operating environment and shows the whole system
as just one process. It does not usually show data stores, unless they are "owned" by
external systems, e.g. are accessed by but not maintained by this system, however, these
are often shown as external entities.

22
 LEVEL 0

DETAILS VERIFICATION

PAS
APPLICANT ADMINISTRATOR

INVALID PASSPORT
ALLOT

SYSTEM DATABASE

2. Level 1 (High Level Diagram)

23
The following is a Level 1 Data flow diagram for the same system. This level (level 1)
shows all processes at the first level of numbering, data stores, external entities and the
data flows between them. The purpose of this level is to show the major high-level
processes of the system and their interrelation. A process model will have one, and only
one, level-1 diagram. A level-1 diagram must be balanced with its parent context level
diagram, i.e. there must be the same external entities and the same data flows, these can
be broken down to more detail in the level 1, e.g. the "enquiry" data flow could be spilt
into "enquiry request" and "enquiry results" and still be valid

24
LEVEL1

APPLICANT
APPLICANT LOGIN

PROFILE SELECT OPTIONS

VERIFIED

CHECK CHECK
DETAILS THE
PASSPORT
VALID
STATUS
ACCOUNT
DATABASE
OK/NOT

USER ACCOUNT
DETAILS
DETAILS
CHECK
STATUS

ALERT ON
DUE DATE
AND RENEW
COMPILATION
PASSPORT

PASSPORT

FEEDBACK

25
3. Level 2 (unified Level Diagram)

A Level 2 Data flow diagram shows the "Process Enquiry" process for the same
system.This level is a decomposition of a process shown in a level-1 diagram, as such
there should be a level-2 diagram for each and every process shown in a level-1 diagram.
In this example processes 1.1, 1.2 & 1.3 are all children of process 1, together they wholly
and completely describe process 1, and combined must perform the full capacity of this
parent process. As before, a level-2 diagram must be balanced with its parent level-1
diagram.

26
Renewing-passport

27
 II ) Functional decomposition
AIM: To draw Functional Decomposition Diagram for PASSPORT AUTOMATION
SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : MS Office edition or Paint Application

THEORY:

What is the process of Functional Decomposition?

Functional decomposition is a term that engineers use to describe a set of steps in which they
break down the overall function of a device, system, or process into its smaller parts. This is
usually accomplished through thoughtful analysis and team discussions of project information
and the result is a chart that describes the problem and or solutions in increasing detail.

Here are some terms and their definitions that apply to the functional decomposition process.

A function is simply a task that is performed by a device, system, or process.

Decomposition is a process of breaking down. we will be breaking down functions into their
smaller parts.

A general function is a function that requires other functions to work in order to take place. A
general function may also be a sub function, since it may both depend on and be depended on by
other functions.

A subfunction is a function that has to work in order for a more general function to take place.
Remember, a subfunction may also be a general function. A basic function is a function that has
no smaller subfunctions.

Functional decomposition is a term that engineers use to describe a set of steps in which they
break down the overall function of a device, system, or process into its smaller parts.

A functional decomposition diagram is a picture that engineers draw to help them understand
how all of the general tasks and subtasks in a design fit together. They use tree diagrams because
these are good for showing how big things can split into smaller things (just like the branches of
a tree, which split into smaller twigs).

Steps to follow for the Functional Decomposition

1. Find the most general function

28
 What is the most general task that your design needs to accomplish? Your group
should come up with a one-sentence answer to this question and write it down. If you find
that you need more than one sentence to describe this task, it is likely that you are
incorporating some smaller functions into your answer. Try to identify the function that
reflects the overall purpose of the design.
Begin a functional decomposition diagram by centering a short description of
this most general function at the top of a piece of paper. Remember, all you need to write
is what the function does, not how it does it.

2. Find the closest sub functions

What are the functions that must take place immediately before the most general
function? You can place these (remember: tell us what, not how) on your functional
decomposition diagram, connecting them with lines to your description of your most
general function. Make sure that you are not choosing functions that require another step
before the most general function can be completed – we’ll use these in the next step.

3. Find the next level(s) of sub functions

For each of the functions that you put on your chart in step 2, find their closest
sub functions and draw them on the functional decomposition diagram. Keep doing
this until the functions on your diagram are basic functions that can’t be broken down
any further.

4. Check your diagram

When you have completed your diagram, check to make sure that there are no
additional functions that you have not included. If you think of one, try to figure out where
it fits on the diagram and draw lines to show its place.

29
30
 III) USECASE DIAGRAM

DEFINITION:

Use case Diagram is a collection of use cases, actors and relationships that exists
between them. Use-case diagrams graphically depict system behavior (use cases).

These diagrams present a high level view of how the system is used as viewed from an
outsider’s (actor’s) perspective. A use-case diagram may depict all or some of the use
cases of a system.

CONTENTS:

A use-case diagram can contain:

1.Actors ("things" outside the system):

Actors represent system users. They help delimit the system and give a clearer picture of
what the system should do. It is important to note that an actor interacts with, but has no
control over the use cases.

An actor is someone or something that:

⮚ Interacts with or uses the system

⮚ Provides input to and receives information from the system
⮚ Is external to the system and has no control over the use cases

actor

2·Use cases (system boundaries identifying what the system should do):
31
A more detailed description might characterize a use case as:

⮚ a pattern of behavior the system exhibits

⮚ a sequence of related transactions performed by an actor and the system
⮚ delivering something of value to the actor.

Use cases provide a means to:

⮚ capture system requirements

⮚ communicate with the end users and domain experts
⮚ test the system

Use cases are best discovered by examining the actors and defining what the actor will
be able to do with the system.

usecase

2. Interactions or relationships between actors and use cases in the system including
the associations, dependencies, and generalizations.

Association Relationship: An association provides a pathway for communication. The

communication can be between use cases, actors, classes or interfaces. Associations are
the most general of all relationships and consequentially the most semantically weak. If
two objects are usually considered independently, the relationship is an association.

Generalization Relationship:

32
A generalize relationship is a relationship between a more general class or use case and
a more specific class or use case. A generalization is shown as a solid-line path from the
more specific element to a more general element. The tip or a generalization is a large
hollow triangle pointing to the more general element.

actor1

actor3

actor2

Dependency Relationship:

A dependency is a relationship between two model elements in which a change to one

model element will affect the other model element. Use a dependency relationship to
connect model elements with the same level of meaning. Typically, on class diagrams, a
dependency relationship indicates that the operations of the client invoke operations of
the supplier.

33
DIAGRAM:

AIM: Use Case Diagram for PASSPORT AUTOMATION SYSTEM

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : In Rational rose software using Use case

online form filling

<<extend>>
invalid

validation

appointment

applicant
passport officer

verification

<<include>>
post officer police service verification
delivery

status

34
 reappointment
certificate

<<extend>>

passport officer

verification
photograph

<<include>>

checking original document

scanning document

applicant

enquiry

35
 IV) SEQUENCE DIAGRAM

A sequence diagram is a graphical view of a scenario that shows object interaction in a

time-based sequence¾what happens first, what happens next.

Sequence diagrams establish the roles of objects and help provide essential information
to determine class responsibilities and interfaces.

This type of diagram is best used during early analysis phases in design because they are
simple and easy to comprehend.

Sequence diagrams are normally associated with use cases.

Sequence diagrams are closely related to collaboration diagrams and both are alternate
representations of an interaction.

There are two main differences between sequence and collaboration diagrams:

Sequence diagrams show time-based object interaction

While collaboration diagrams show how objects associate with each other.

CONTENTS:

A sequence diagram has two dimensions: typically, vertical placement represents time
and horizontal placement represents different objects.

The following tools located on the sequence diagram toolbox enable you to model
sequence diagrams:

Object: An object has state, behavior, and identity. The structure and behavior of similar
objects are defined in their common class. Each object in a diagram indicates some
instance of a class. An object that is not named is referred to as a class instance.

If you use the same name for several object icons appearing in the same collaboration or
activity diagram, they are assumed to represent the same object; otherwise, each object
icon represents a distinct object. Object icons appearing in different diagrams denote
different objects, even if their names are identical. Objects can be named three different
ways: object name, object name and class, or just by the class name itself.

36
Message Icons: A message icon represents the communication between objects
indicating that an action will follow. The message icon is a horizontal, solid arrow
connecting two lifelines together. The following message icons show three different ways
a message icon can appear: message icon only, message icon with sequence number, and
message icon with sequence number and message label.

Each message icon represents a message passed between two objects, and indicates the
direction of message is going. A message icon in a collaboration diagram can represent
multiple messages. A message icon in a sequence diagram represents exactly one
message.

Focus of Control: Focus of Control (FOC) is an advanced notational technique that

enhances sequence diagrams. It shows the period of time during which an object is
performing an action, either directly or through an underlying procedure. FOC is
portrayed through narrow rectangles that adorn lifelines. The length of an FOC indicates the
amount of time it takes for a message to be performed. When you move a message vertically,
each dependent message will move vertically as well. Also, you can move a FOC vertically off
of the source FOC to make it detached and independent. An illustration of a sequence diagram
with FOC notation follows:

37
Message to Self: A Message to Self is a tool that sends a message from one object back to the
same object. It does not involve other objects because the message returns to the same object.
The sender of a message is the same as the receiver.

Note: A note captures the assumptions and decisions applied during analysis and design.
Notes may contain any information, including plain text, fragments of code, or references
to other documents. Notes are also used as a means of linking diagrams. A note holds an
unlimited amount of text and can be sized accordingly.

Notes behave like labels. They are available on all diagram toolboxes, but they are not
considered part of the model. Notes may be deleted like any other item on a diagram.

Note Anchor: A note anchor connects a note to the element that it affects. To draw a note
anchor, place a note on the diagram and connect the note to an element with the note
anchor icon.

38
DIAGRAM:

AIM: To draw sequence diagram for PASSPORT AUTOMATION SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : In Rational rose software using sequence Diagram tool.

VALID PASSPORT PIN:

39
Invalid Passport Pin :

40
NEW REGISTRATION:

CHECK STATUS:

41
ADMIN PANEL:

42
 V) COLLABORATION DIAGRAM

Collaboration diagrams and sequence diagrams are alternate representations of an

interaction. A collaboration diagram is an interaction diagram that shows the order of
messages that implement an operation or a transaction. A sequence diagram shows
object interaction in a time-based sequence.

Collaboration diagrams show objects, their links, and their messages. They can also
contain simple class instances and class utility instances. Each collaboration diagram
provides a view of interactions or structural relationships that occur between objects and
object-like entities in the current model.

The Create Collaboration Diagram Command creates a collaboration diagram from

information contained in the sequence diagram. The Create Sequence Diagram Command
creates the sequence diagram from information contained in the interaction's
collaboration diagram. The Goto Sequence Diagram and Goto Collaboration Diagram
commands traverse between an interaction's two representations.

Collaboration diagrams contain icons representing objects. You can create one or more
collaboration diagrams to depict interactions for each logical package in your model. Such
collaboration diagrams are themselves contained by the logical package enclosing the
objects they depict.

An Object Specification enables you to display and modify the properties and
relationships of an object. The information in a specification is presented textually. Some
of this information can also be displayed inside the icons representing objects in
collaboration diagrams.

You can change properties or relationships by editing the specification or modifying

the icon on the diagram. The associated diagrams or specifications are automatically
updated.

During: Analysis

Use Collaboration Diagrams: To Indicate the semantics of the primary and secondary
interactions.

43
Design Show the semantics of mechanisms in the logical design of the system
Use collaboration diagrams as the primary vehicle to describe interactions that express
your decisions about the behavior of the system.

Object:

An object has state, behavior, and identity. The structure and behavior of similar objects are
defined in their common class. Each object in a diagram indicates some instance of a class. An
object that is not named is referred to as a class instance.

If you use the same name for several object icons appearing in the same collaboration or
activity diagram, they are assumed to represent the same object; otherwise, each object
icon represents a distinct object. Object icons appearing in different diagrams denote
different objects, even if their names are identical. Objects can be named three different
ways: object name, object name and class, or just by the class name itself.

If you specify the name of the object's class in the Object Specification, the name must
identify a class defined in the model.

Graphical Depiction

The object icon is similar to a class icon except that the name is underlined:

If you have multiple objects that are instances of the same class, you can modify the
object icon by clicking Multiple Instances in the Object Specification. When you select
this field, the icon is changed from one object to three staggered objects:

Concurrency

An object's concurrency is defined by the concurrency of its class.

You can display concurrency by clicking Show Concurrency from the object's shortcut
menu. The adornment is displayed at the bottom of the object icon.

44
Persistence

You can explicitly set the persistence of an object in the Object Specification. You can
display this value as an adornment by clicking Persistence from the shortcut menu. If you
display both concurrency and persistence, the object's persistence is listed second:

Link:

Objects interact through their links to other objects. A link is an instance of an association
,analogous to an object being an instance of a class. A link should exist between two
objects, including class utilities, only if there is a relationship between their
corresponding classes. The existence of an relationship between two classes symbolizes
a path of communication between instances of the classes: one object may send messages
to another.
Links can support multiple messages in either direction. If a message is deleted, the link
remains intact Graphical Depiction

The link is depicted as a straight line between objects or objects and class
instances in a collaboration diagram. If an object links to itself, use the loop
version of the icon.

Adornments

You can document how objects see one another by specifying a visibility type on the
General tab of the Link Specification or by selecting an item from the shortcut menu. You
can select global, parameter, field, or local visibility. You can also specify whether object
visibility is shared.

45
Message/Event:

A message is the communication carried between two objects that trigger an event. A
message carries information from the source focus of control to the destination focus of
control.

A message is represented on collaboration diagrams and sequence diagrams by a

message icon which visually indicates its synchronization. The synchronization of a
message can be modified through the message specification. The following
synchronization types are supported:

· Simple
· Synchronous
· Balking
· Timeout
· Asynchronous
· Procedure Call
· Return

In a collaboration diagram, a message icon can represent several messages. If all

messages represented by a message icon do not have the same synchronization, the
"simple" message icon is displayed. You can change the synchronization of the message
by editing the message specification.

. The message to self icon appears as a message that returns to itself.

. The collaboration diagram toolbox contains two message tools. The forward message
tool,
bearing an arrow pointing "northeast," places a message icon from client to supplier
. The reverse message tool, bearing an arrow pointing "southwest," places a message
icon
from supplier to client. The default synchronization for a message is "simple."
. Scripts may be attached to messages to enhance the messages.
. If a message is deleted, the link remains intact.

Message Icons:

Overview

A message icon represents the communication between objects indicating that an action
will follow. The message icon is a horizontal, solid arrow connecting two lifelines
together. The following message icons show three different ways a message icon can
appear: message icon only, message icon with sequence number, and message icon with
sequence number and message label.

Each message icon represents a message passed between two objects, and indicates the
direction of message is going. A message icon in a collaboration diagram can represent

46
multiple messages. A message icon in a sequence diagram represents exactly one
message.

Displaying Operation Names

You may specify the name of a message through the message specification, or by right-
clicking on the message icon to display the shortcut menu of a message.

You can adjust the position of a message icon by selecting it and dragging it to a new
location. This action moves the icon, the names of any operations, and the sequence
numbers to the new location.

You can reposition the message labels by selecting one and dragging to a new location. This
action moves the message labels only; the message icon is not moved.

You can enhance a message by attaching a script to the message. The script will remain
aligned with the message regardless of any changes in the position of the message. Scripts
are attached to a message by clicking Edit > Attach Script.

47
DIAGRAM:

AIM: To draw Collaboration diagram for PASSPORT AUTOMATION SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : In Rational rose software using Collaboration

Diagram tools

VALID PASSPORT PIN:

valid passport pin

login

applicant

1: fill the application form

2: verify

adminstrator
database

3: authenticate

48
 INVALID PASSPORT PIN:

invalid passport pin

login

applicant

2: verify
1: fill the application form

adminstration database

3: invalid

NEW REGISTRATION:

49
CHECK STATUS:

ADMIN PANEL:

50
VI) ACTIVITY DIAGRAM

DEFINITION:

Activity diagrams provide a way to model the workflow of a business process. You can
also use activity diagrams to model code-specific information such as a class operation.
Activity diagrams are very similar to a flowchart because you can model a workflow from
activity to activity.

An activity diagram is basically a special case of a state machine in which most of the
states are activities and most of the transitions are implicitly triggered by completion of
the actions in the source activities.

The main difference between activity diagrams and state charts is activity diagrams are
activity centric, while state charts are state centric.

An activity diagram is typically used for modeling the sequence of activities in a process,
whereas a state chart is better suited to model the discrete stages of an object’s lifetime.

CONTENTS:

Activity Diagram Tools

You can use the following tools on the activity diagram toolbox to model activity
diagrams:

· Activities: An activity represents the performance of task or duty in a workflow. It

may also represent the execution of a statement in a procedure. An activity is similar to
a state, but expresses the intent that there is no significant waiting (for events) in an
activity. Transitions connect activities with other model elements and object flows
connect activities with objects.

Decisions: A decision represents a specific location on an activity diagram or state

chart diagram where the workflow may branch based upon guard conditions. There
may be more than two outgoing transitions with different guard conditions, but for the
most part, a decision will have only two outgoing transitions determined by a Boolean
expression

51
End State: An end state represents a final or terminal state on an activity diagram or
state chart diagram. Place an end state when you want to explicitly show the end of a
workflow on an activity diagram or the end of a state chart diagram. Transitions can
only occur into an end state; however, there can be any
number of end states per context.

Object: Rational Rose allows objects on activity, collaboration, and sequence diagrams.
Specific to activity diagrams, objects are model elements that represent something you
can feel and touch. It might be helpful to think of objects as the nouns of the activity
diagram and activities as the verbs of the activity diagram. Further, objects on activity
diagrams allow you to diagram the input and output relationships between activities. In
the following diagram, the Submit Defect and Fix Defects can be thought of as the verbs
and the defect objects as the nouns in the activity diagram vocabulary. Objects are
connected to activities through object flows.

Object Flow: An object flow on an activity diagram represents the relationship between
an activity and the object that creates it (as an output) or uses it (as an input).

Rational Rose draws object flows as dashed arrows rather than solid arrows to
distinguish them from ordinary transitions. Object flows look identical to dependencies
that appear on other diagram types.

Start State: A start state (also called an "initial state") explicitly shows the beginning of
a workflow on an activity diagram or the beginning of the execution of a state machine
on a state chart diagram. You can have only one start state for each state machine because
each workflow/execution of a state machine begins in the same place.

52
Normally, only one outgoing transition can be placed from the start state. However,
multiple transitions may be placed on a start state if at least one of them is labeled with a
condition. No incoming transitions are allowed.

States: A state represents a condition or situation during the life of an object during
which it satisfies some condition or waits for some event. Each state represents the
cumulative history of its behavior.

Swim lanes: Swim lanes are helpful when modeling a business workflow because they
can represent organizational units or roles within a business model. Swim lanes are very
similar to an object because they provide a way to tell who is performing a certain role.
Swim lanes only appear on activity diagrams. You should place activities within swim
lanes to determine which unit is responsible for carrying out the specific activity. For
more information on swim lanes, look at the swim lane sample.

When a swim lane is dragged onto an activity diagram, it becomes a swim lane view. Swim
lanes appear as small icons in the browser while a swim lane views appear between the
thin, vertical lines with a header that can be renamed and relocated.

Synchronizations: Synchronizations enable you to see a simultaneous workflow in an

activity diagram or state chart diagram. Synchronizations visually define forks and joins
representing parallel workflow.

Transitions: A state transition indicates that an object in the source state will perform
certain specified actions and enter the destination state when a specified event occurs or
when certain conditions are satisfied. A state transition is a relationship between two states,
two activities, or between an activity and a state.

You can show one or more state transitions from a state as long as each transition

is unique. Transitions originating from a state cannot have the same event, unless there
are conditions on the event.

53
DIAGRAM:

AIM: To draw Activity diagram for PASSPORT AUTOMATION SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : In Rational rose software using Activity diagram tools.

NEW REGISTRATION:

54
CHECK STATUS:

ADMIN PANEL:

STATE CHART DIAGRAM:

55
 start the process
HOME
PAGE

choosing the menu

Reading form

valid form

Reenter the
Enter username invalid password
and password

valid
valid

GET
APPOINTMENT

proceesing detail

Verification
details
invalid
valid for enquiry

Police
enquiry

valid report
Issue passport

password ready to deliver

Passport
delivery

delivery

VII ) CLASS DIAGRAM

56
DEFINITION:

A class diagram shows the existence of classes and their relationships in the
logical design of a system.

A class diagram may represent all or part of the class structure of a system.

CONTENTS:

A class diagram contains

1. Classes
2. Relationships
3.Interfaces

1) Classes:

A class is a set of objects that share a common structure and common

behavior (the same attributes, operations, relationships and semantics). A
class is an abstraction of real-world items. When these items exist in the
real world, they are instances of the class and are referred to as objects.

class

2) Relationships:

Aggregate Relationship

Use the aggregate relationship to show a whole and part relationship

between two classes.

The class at the client end of the aggregate relationship is sometimes

called the aggregate class. An instance of the aggregate class is an
aggregate object. The class at the supplier end of the aggregate
relationship is the part whose instances are contained or owned by the
aggregate object.

57
 suplier
suplier A client B

Association Relationship

An association provides a pathway for communication. The communication can

be between use cases, actors, classes or interfaces. Associations are the most
general of all relationships and consequentially the most semantically weak. If
two objects are usually considered independently, the relationship is an
association

association
class1 classs2

Dependency Relationship

A dependency is a relationship between two model elements in which a change to one

model element will affect the other model element. Use a dependency relationship to
connect model elements with the same level of meaning.

full order place order

58
Generalize Relationship

A generalize relationship between classes shows that the subclass shares the structure
or behavior defined in one or more super classes. Use a generalize relationship to show a
"is-a" relationship between classes.

super class

subclass1 subclass2

Realize Relationship

A realization is a relationship between classes, interfaces, components, and packages that

connects a client element with a supplier element. A realization relationship between
classes and interfaces and between components and interfaces shows that the class
realizes the operations offered by the interface.

59
3) Interfaces

An interface specifies the externally-visible operations of a class and/or component, and

has no implementation of its own. An interface typically specifies only a limited part of
the behavior of a class or component.

Interfaces belong to the logical view but can occur in class, use case and component
diagrams.

An interface in a component diagram is displayed as a small circle with a line to the

component that realizes the interface:

interface

Adornments

You can further define an interface using the Class Specification. Some class
specification fields correspond to adornment and compartment information that you
can display in the class diagram.

60
DIAGRAM:

AIM: To draw Advanced Class diagram for PASSPORT AUTOMATION SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : In Rational rose software using Class diagram tools.

61
 VII) COMPONENT DIAGRAM

Component diagrams provide a physical view of the current model. A component

diagram shows the organizations and dependencies among software components,
including source code components, binary code components, and executable components.
These diagrams also show the externally-visible behavior of the components by displaying
the interfaces of the components. Calling dependencies among components are shown as
dependency relationships between components and interfaces on other components. Note
that the interfaces actually belong to the logical view, but they can occur both in class
diagrams and in component diagrams.

Component diagrams contain:

· Component packages: Component packages represent clusters of logically

related components, or major pieces of your system. Component packages parallel the
role played by logical packages for class diagrams. They allow you to partition the
physical model of the system.

· Components: A component represents a software module (source code, binary

code, executable, DLL, etc.) with a well-defined interface. The interface of a component is
represented by one or several interface elements that the component provides.
Components are used to show compiler and run-time dependencies, as well as interface
and calling dependencies among software modules. They also show which components
implement a specific class.

A system may be composed of several software modules of different kinds. Each software
module is represented by a component in the model. To distinguish different kinds of
components from each other, stereotypes are used.

62
Interfaces: An interface specifies the externally-visible operations of a class and/or
component, and has no implementation of its own. An interface typically specifies only a
limited part of the behavior of a class or component.

· Dependency relationships: A dependency is a relationship between two model

elements in which a change to one model element will affect the other model element.
Use a dependency relationship to connect model elements with the same level of
meaning. Typically, on class diagrams, a dependency relationship indicates that the
operations of the client invoke operations of the supplier.

You can create one or more component diagrams to depict the component packages and
components at the top level of the component view, or to depict the contents of each
component package. Such component diagrams belong to the component package that
they depict.

A Component Package Specification enables you to display and modify the properties of
a component package. Similarly, a Component Specification and a Class Specification
enables you to display and modify the properties of a component and an interface,
respectively. The information in these specifications is presented textually. Some of this
information can also be displayed inside the icons representing component packages and
components in component diagrams, and interfaces in class diagrams.

You can change properties of, or relationships among, component packages, components,
and interfaces by editing the specification or modifying the icon on the diagram. The
affected diagrams or specifications are automatically updated.

63
DIAGRAM:

AIM: To draw Component diagram for PASSPORT AUTOMATION SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : In Rational rose software using component diagram

tools.

64
 IX) DEPLOYMENT DIAGRAM

A deployment diagram shows processors, devices, and connections. Each model

contains a single deployment diagram which shows the connections between its
processors and devices, and the allocation of its processes to processors.

Processor Specifications, Device Specifications, and Connection Specifications enable

you to display and modify the respective properties. The information in a specification
is presented textually; some of this information can also be displayed inside the icons.

You can change properties or relationships by editing the specification or modifying

the icon on the diagram. The deployment diagram specifications are automatically
updated.

CONTENTS:

Processor:-A processor is a hardware component capable of executing programs.

Devices:
A device is a hardware component with no computing power. Each device must have
a name. Device names can be generic, such as "modem" or "terminal."

Connections:
A connection represents some type of hardware coupling between two entities. An
entity is either a processor or a device. The hardware coupling can be direct, such as
an RS232 cable, or indirect, such as satellite-to-ground communication. Connections
are usually bi-
directional.

65
DIAGRAM:

AIM: To draw Deployment diagram for PASSPORT AUTOMATION SYSTEM.

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE: In Rational rose software using Deployment diagram tools.

66
 6. Forward and Reverse Engineering

AIM: To implement Forward and reverse engineering for QMS..

REQUIREMENTS:

HARDWARE : PIII Processor, 512 MB RAM, 80GB

SOFTWARE : Rational Rose Software

THEORY:

Forward engineering states creation of code from model.

Reverse engineering states creation of a model from code.

Performance of forward engineering using Rational rose tool:

1. Forward engineering is processed by using a class diagram of uml.

2. Firstly creating a one or more components in component view

3. according to the classes in class diagram. .

4. Assigning a name for each component which is created.

5. Right click on component view

6. Selecting open specification.

7. Select stereotypes and application to be used.

8. Dragging and dropping the created component between each class

9. Again right click on component view.

10. Select forward engineering option.

11. Displays the coding of the model in text format.

67
Performance of Reverse engineering using Rational rose tool.

1. Firstly opening the component view.

2. Creating the component

3. Assigning name for the component

4. Right click on component view

5. Select reverse engineering option

6. Select code to which model has to be generated

7. After selecting the code it generates class model elements (class

diagram) in logical view which is above the component view .
Dragging and dropping the model elements into the rational rose editor model is
generated.

Forward Engineering:

Generated code:

The code generated by performing forward engineering to the following class diagram
is:

Applicant .class

public class Applicant

68
private String Name;

private String Father name;

private Int Dob;

/**

@roseuid 5CB2A67D02C6

*/

public Admin()

/**

@return java.lang.Boolean

@roseuid 5CB29E970040

*/

public Boolean updateDataBase()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB29EA0035F

*/

69
 public Boolean provideUserId()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB29EAB002A

*/

public Boolean autenticateUserLogin()

return null;

Police class

public class Police extends Applicant

private String Name;

private String email;

private String Id;

private String qualification;

70
/**

@roseuid 5CB2A67D024C

*/

public Police()

/**

@return java.lang.Boolean

@roseuid 5CB29E2A03A8

*/

public Boolean accessPassport()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB29E3603CC

*/

public Boolean accessStudentInfo()

return null;

71
 }

/**

@return java.lang.Boolean

@roseuid 5CB29E45004A

*/

public Boolean validateCourse()

return null;

/**

@return java.lang.String

@roseuid 5CB29E4F024B

*/

public String provideCourseId()

return null;

Student.class

public class Student extends User

72
{

private String studentName;

private String year;

private String branch;

private String section;

private String email;

private String rollNo;

public Course theCourse;

/**

@roseuid 5CB2A67D0339

*/

public Student()

/**

@return java.lang.Boolean

@roseuid 5CB2A0B7038C

*/

public Boolean enrollCourse()

return null;

73
/**

@return java.lang.Boolean

@roseuid 5CB2A0C500A5

*/

public Boolean takeCourse()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB2A0CD0057

*/

public Boolean uploadAssignment()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB2A0D90086

*/

public Boolean takeQuiz()

74
 return null;

/**

@return java.lang.Boolean

@roseuid 5CB2A0E60198

*/

public Boolean checkResults()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB2A0F003AC

*/

public Boolean post_clarify_doubts()

return null;

Course.class

75
public class Course

private String courseId;

private String courseName;

private Date startDate;

private String endDate;

private String runningStatus;

private String facultyId;

public Faculty theFaculty;

/**

@roseuid 5CB2A67E004A

*/

public Course()

/**

@return java.lang.Boolean

@roseuid 5CB2A30C0135

*/

public Boolean createCourse()

76
 return null;

Quiz.class

public class Quiz

private String quizId;

private Date conductionDate;

private int noOfQuestions;

private String questions;

private String facultyId;

private String c_id;

public Course theCourse;

/**

@roseuid 5CB2A67D0389

*/

public Quiz()

/**

77
 @return java.lang.Boolean

@roseuid 5CB2A206033C

*/

public Boolean createQuiz()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB2A21001F9

*/

public Boolean postResults()

return null;

Assignment.class

public class Assignment

private String assignmentId;

private Date dueDate;

78
private String f_id;

private String c_id;

/**

@roseuid 5CB2A67D02FD

*/

public Assignment()

/**

@return java.lang.Boolean

@roseuid 5CB2A25F02B5

*/

public Boolean createAssignement()

return null;

/**

@return java.lang.Boolean

@roseuid 5CB2A26F023E

*/

public Boolean postResult()

79
 {

return null;

Reverse Engineering:

The class diagram generated from the above code is:

80
81
 7. TEST CASES
Test case doc

A good Test Case template maintains test artifact consistency for the test team and makes it easy for all stakeholders to understand the test
cases. Writing test case in a standard format lessen the test effort and the error rate. Test cases format are more desirable in case if you are
reviewing test case from experts.

Test Case Field Description

Test case ID:  Each test case should be represented by a unique ID. To indicate test types follow some convention like "TC_UI_1"
indicating "User Interface Test Case#1."

Test Priority:  It is useful while executing the test.

o Low
o Medium
o High

Name of the Module:  Determine the name of the main module or sub-module being tested

Test Designed by:  Tester's Name

Date of test designed:  Date when test was designed

Test Executed by:  Who executed the test- tester

Date of the Test Execution:  Date when test needs to be executed

Name or Test Title:  Title of the test case

Description/Summary of  Determine the summary or test purpose in brief

Test:

Pre-condition:  Any requirement that needs to be done before execution of this test case. To execute this test case list all pre-conditio

Dependencies:  Determine any dependencies on test requirements or other test cases

82
Test Steps:  Mention all the test steps in detail and write in the order in which it requires to be executed. While writing test steps e
that you provide as much detail as you can

Test Data:  Use of test data as an input for the test case. Deliver different data sets with precise values to be used as an input

Expected Results:  Mention the expected result including error or message that should appear on screen

Post-Condition:  What would be the state of the system after running the test case?

Actual Result:  After test execution, actual test result should be filled

Status (Fail/Pass):  Mark this field as failed, if actual result is not as per the estimated result

Notes:  If there are some special condition which is left in above field

LOGIN

83
Issue passport

84
 8.COST AND RESOURCE ESTIMATES
AIM: To estimate cost and resource for passport automation system.

THEORY: This estimation has to be done to develop a product in economically achieving

high quality, performance, maintainability.

TOTAL COST:

ACTIVTY REPORT:

85
ARCHIVE REPORT:

EFFOT:

86
SIZE:

87
SCALE DRIVERS:

88
 9. RATIONAL FUNCTIONAL TESTER

Rational Functional Tester is a tool for automated testing of software applications from
the Rational Software division of IBM. It allows users to create tests that mimic the actions
and assessments of a human tester. It is primarily used by Software Quality Assurance teams
to perform automated regression testing.

Rational Functional Tester is a software test automation tool used by quality assurance teams
to perform automated regression testing. Testers create scripts by using a test recorder which
captures a user's actions against their application under test. The recording mechanism creates
a test script from the actions. Testers can edit the script using standard commands and syntax
of these languages, or by acting against the screen shots in the storyboard.. Test scripts can
then be executed by Rational Functional Tester to validate application functionality.
Typically, test scripts are run in a batch mode where several scripts are grouped together and
run unattended.

Storyboard Testing
This technology enables testers to edit test scripts by acting against screen shots of the
application.
Object

89
The Rational Functional Tester Object Map is the underlying technology used by Rational
Functional Tester to find and act against the objects within an application. The Object Map is
automatically created by the test recorder when tests are created and contains a list of
properties used to identify objects during playback.
ScriptAssure
During playback, Rational Functional Tester uses the Object Map to find and act against the
application interface. However, during development it is often the case that objects change
between the time the script was recorded and when a script was executed. ScriptAssure
technology enables Rational Functional Tester to ignore discrepancies between object
definitions captured during recording and playback to ensure that test script execution runs
uninterrupted. ScriptAssure sensitivity, which determines how big an object map discrepancy
is acceptable, is set by the user.
Data Driven Testing
It is common for a single functional regression test to be executed multiple times with
different data. To facilitate this, the test recorder can automatically parameterize data entry
values, and store the data in a spreadsheet like data pool. This enables tester to add additional
test data cases to the test data pool without having to modify any test code. This strategy
increases test coverage and the value of a given functional test.

Dynamic Scripting Using Find API

Rational Functional Test script, Eclipse Integration uses Java as its scripting language. The
Script is a .java file and has full access to the standard Java APIs or any other API exposed
through other class libraries.
Apart from this RFT itself provides a rich API to help user further modify the script
generated through the recorder. RationalTestScript class that is the base class for any
TestScript provides a find API that can be used to find the control based on the given
properties.

START RECORDING:

90
APPLICANT DETAILS:

91
FILL THE DETAILS:

92
93
94
RESULT:

95
96
:

97