SPOUSAL

1. INTRODUCTION
1.1 Rationale
1.2 Problem Definition and Proposed Solution
1.3 Functionality Set

1.1 Rationale:

Marriage is an interpersonal relationship with governmental, social, or religious

recognition, usually intimate and sexual, and often created as a contract though custom,
ballot or civil process. Civil marriage is the legal concept of marriage. The reasons people
marry vary widely, but usually include one or more of the following: legal, social and
economic stability; the formation of a family unit; procreation and the education and
nurturing of children; legitimizing sexual relations; public declaration of love. A marriage
is often declared by a wedding ceremony, which may be performed by a religious
officiator, through a similar government-sanctioned secular officiator, or (in weddings
that have no church or state affiliation) by a trusted friend of the wedding participants.
The act of marriage usually creates obligations between the individuals involved, and in
many societies, their extended families.

1.2 Problem Definition and Proposed Solution:

1.2.1 Problem Domain:

I have select this project Spousal (A Matrimony Website) because

currently no one has time to visit from one place to another looking for bride and
grooms. In earlier days people visit often from one place to another but maximum
time they didn’t get satisfied and there is waste of time and money both.

1.2.2 Main Problems:

1. Inflexible and rigid

2. Information not reliable
3. Software uneconomical

1.2.3 Solution Domain:

The basic need why our project required is the lack of time because it is time only
which makes people to visit any matrimonial site and thousands of profiles are
available to access and help people in finding their right spouse.

RIT, INDORE 1
 SPOUSAL

1.2.4 Proposed Solution need to be

 Distributed
 Flexible
 Usable
 Extensible
 Secured

The System includes the following features:

• Provide information about bride and groom.

• Provide easily accessible information for all appropriate.

• Provide only that information which is given by user.

• User Friendly i.e. it’s easy to use.

• Some features can only be accessible by registered user.

Here, the inputs taken will be:

1. Username, First name, Last name, Date of Birth, Password, E-

mail ID.
2. At the time of Login, User ID and Password
3. Basic Detail, Educational detail, etc. to be entered by the profile
owner himself.
4. Want to be a registered user or want to remain unregistered.
5. For what the user is looking for.

The outputs will be:

1. Complete Personal Profile

2. User personal page.
3. Messages received
4. Can search any profile throughout the database.

1.3 Functionality Set

Brides, Grooms are major user with following functionality set:

Both can edit there personal information and see others profile, save profile link
which is perfect match with your profile. Any member from your family can post
your profile. Every user can easily update their profile accordingly. Once data is
uploaded can only be changed by user administrator has no role in this project.

RIT, INDORE 2
 SPOUSAL

2. LITERATURE SURVEY

2.1 Object Oriented Analysis and Design

2.2 Design Architecture
2.3 Tools and Technology

2.1 OBJECT ORIENTED ANALYSIS AND DESIGN

Many different kinds of Application Development can be benefited by

applying Rational Unified Process and Modeling.
 The Rational Unified Process is a Software Engineering Process.
 It provides a disciplined approach to assigning tasks and responsibilities
Within a development organization.
 It captures many of the best practices in modern software development.

RUP Process Made

Sustained development of quality software.

Delivered On –Time and On-budget
Cohesive Teamwork & Common understanding of development tasks.
Ensures implementation is predictable and repeatable.

The UML is the standard language for visualizing, specifying, constructing and
documenting the artifacts of a software-intensive system. It can be used with all
processes, throughout the development life cycle, and across different
implementation technology.
UML can also be used to Forward Engineer i.e. to generate code from the model
you have built. It can generate Visual Basic code, Power Builder code, and C++
code with numerous more. Similarly we can use it for Backward engineering i.e.
Generating Model from the code.

RIT, INDORE 3
 SPOUSAL

2.2 DESIGN ARCHITECTURE

Idea

Analysis

Design

Development

Test

Final Product

RIT, INDORE 4
 SPOUSAL

2.3 TOOLS AND TECHNOLOGY

Following technologies are being used in implementing the project:

2.3.1 J2EE (Enterprise Edition as Front End)

2.3.2 MySQL (Back End Tool)
2.3.3 Rational Rose 2000 Enterprise Edition

2.3.1 J2EE (Enterprise Edition as Front End)

As a Front End tool I am using Java. Java is a general purpose class based, object
oriented programming language. It is designed to be the simple enough that many
programmers can achieve fluency in the language. The main advantage of Java is its
platform independent property; this has made Java a powerful tool.

2.3.1.1 Why is Java used?

1. Java is the most powerful language today.
2. When properly applied, the features of Java combine to produce a
programming environment that supports the development of far more robust
and scalable programs.
3. A well-designed hierarchy of classes helps programmers in reusing the
code.
4. Encapsulation allows programmer to migrate his implementation over
time without breaking the code that depends on the public interface of the
classes as in encapsulation public methods can be used to protect private data.
2.3.1.2 Servlets:
Java Servlets technology provides web developers with a simple, consistent
mechanism for extending the functionality of a web server and for accessing existing
business systems. A servlet can almost be thought of as an applet that runs on the server
side -- without a face. Java servlets have made many web applications possible.
Servlets are the Java platform technology of choice for extending and enhancing web
servers. Servlets provide a component-based, platform-independent method for building
web-based applications, without the performance limitations of CGI programs. And
unlike proprietary server extension mechanisms (such as the Netscape Server API or
Apache modules), servlets are server- and platform-independent. This leaves you free to
select a "best of breed" strategy for your servers, platforms, and tools.
Servlets have access to the entire family of Java APIs, including the JDBC API to access
enterprise databases. Servlets can also access a library of HTTP-specific calls and receive
all the benefits of the mature Java language, including portability, performance,
reusability, and crash protection.

RIT, INDORE 5
 SPOUSAL

• Portability

Because servlets are written in Java and conform to a well defined and widely accepted
API, they are highly portable across operating systems and server implementations. With
servlets you can truly say “write once, serve everywhere” reason being a class file is
made which is nothing but machine-independent byte codes. We can develop a servlet on
Windows NT machine running the Java Web Server and later deploy it effortlessly on a
Unix server running Apache.

• Safety

Servlets support safe programming practices on a number of levels. Firstly, servlets

inherit the strong type safety of Java language. Secondly, Java’s automatic garbage
collection means that servlets are safe from memory management problems like dangling
pointers, invalid pointer references and memory leaks.

• Extensibility and Flexibility

The servlet API is designed to be easily extensible. The API includes classes that are
optimized for HTTP servlets but at a later date it could be extended and optimized for
another type of servlets by a third party. Servlets are also quite flexible. An HTTP servlet
can be used to generate a complete webpage it can be added to a static page using a
<SERVLET> tag in what is known as a server-side include and it can be used in
cooperation with any number of servlets to filter the content in something known as
servlet chain.

2.3.1.3 JSP (Java Server Pages):

Java Server Pages, also known as JSPs are simple but powerful technology used to
generate dynamic HTML on severs side. They are a direct extension of Java Servlets and
provide a way to separate content generation from content presentation. The JSP engine
is just another Servlet that is mapped to the extension *.jsp.
The source code of a JSP document looks like any other HTML document with some
added tags containing Java code. The source code is stored in a file called XXX.jsp and
copied to the document directory of the Web server. When a request is made for this
document, the server recognizes the *.jsp extension and realizes that special that special
handling is required. The first time the file is requested, it is compiled into a Servlet
object and stored in the memory, and the output is sent back to the requesting client.
After the first request, the server checks to see whether the *.jsp file has changed. If it has
not changed, then the server invokes the previously compiled Servlet object.

Steps required for JSP request:

1. The user visits a web site made using JSP. He goes to a JSP page (ending
with .jsp). The web browser makes the request via internet.

RIT, INDORE 6
 SPOUSAL

2. The JSP request is sent to the web server.

3. The web server recognizes that the file required is special (.jsp), therefore
passes the file to the JSP Sevlet engine.

Benefits of the Java Server Pages Technology

The Java Server Pages technology offers a number of benefits:

• WRITE ONCE, RUN ANYWHERE PROPERTIES

The Java Server Pages technology is platform independent, both in its dynamic Web
pages, its Web servers, and its underlying server components. You can author JSP pages
on any platform, run them on any Web server or Web enabled application server, and
access them from any Web browser. You can also build the server components on any
platform and run them on any server.

• HIGH QUALITY TOOL SUPPORT

The Write Once, Run Anywhere properties of JSP allows the user to choose best-of-
breed
tools. Additionally, an explicit goal of the Java Server Pages design is to enable the
creation of high quality portable tools.

• SEPARATION OF ROLES

JSP supports the separation of roles: developers write components that interact with
server-side objects; authors put static data and dynamic content together to create
presentations best suited for their intended audiences. Each of these roles emphasizes
different types of abilities and, although these abilities may all be present in the same
individual, they most commonly will not. A subset of the developer community may be
focused on creating reusable components intended to be used by authors.

• REUSE OF COMPONENTS AND TAG LIBRARIES

The Java Server Pages technology emphasizes the use of reusable components such as:
JavaBeans™ components, Enterprise JavaBeans™ components and tag libraries. These
components can be used in interactive tools for component development and page
composition. This saves considerable development time while giving the cross-platform
power and flexibility of the Java programming language and other scripting languages.

• SEPARATION OF DYNAMIC AND STATIC CONTENT

The Java Server Pages technology enables the separation of static content from dynamic
content that is inserted into the static template. This greatly simplifies the creation of
content. This separation is supported by beans specifically designed for the interaction

RIT, INDORE 7
 SPOUSAL

with server-side objects, and, specially, by the tag extension mechanism.

• SUPPORT FOR SCRIPTING AND ACTIONS

The Java Server Pages technology supports scripting elements as well as actions. Actions
permit the encapsulation of useful functionality in a convenient form that can also be
manipulated by tools; scripts provide a mechanism to glue together this functionality in a
Per-page manner.

• WEB ACCESS LAYER FOR N-TIER ENTERPRISE APPLICATION

ARCHITECTURE(S)

The Java Server Pages technology is an integral part of the Java 2 Platform Enterprise
Edition (J2EE), which brings Java technology to enterprise computing. You can now
develop powerful middle-tier server applications, using a Web site that uses Java Server
Pages technology as a front end to Enterprise JavaBeans components in a J2EE compliant
environment.

2.3.2 MYSQL:
MySQL, the most popular Open Source SQL database management system, is
developed, distributed, and supported by MySQL AB. MySQL AB is a commercial
company, founded by the MySQL developers.

• MySQL is a relational database management system

A relational database stores data in separate tables rather than putting all the data in one
big storeroom. This adds speed and flexibility. The SQL part of 'MySQL' stands for
'Structured Query Language. 'SQL is the most common standardized language used to
access databases and is defined by the ANSI/ISO SQL Standard.

• MySQL software is Open Source

Open Source means that it is possible for anyone to use and modify the software.
Anybody can download the MySQL software from the Internet and use it without paying
anything. If you wish, you may study the source code and change it to suit your needs.
The MySQL software uses the GPL (GNU General Public License), to define what you
may and may not do with the software in different situations. If you feel uncomfortable
with the GPL or need to embed MySQL code into a commercial application, you can buy
a commercially licensed version.

• The MySQL Database Server is very fast, reliable, and easy to use.

RIT, INDORE 8
 SPOUSAL

MySQL Server has a practical set of features developed in close cooperation with our
users. It was originally developed to handle large databases much faster than existing
solutions and has been successfully used in highly demanding production environments
for several years. It offers a rich and useful set of functions. Its connectivity, speed, and
security make MySQL Server highly suited for accessing databases on the Internet.

• Scalability and Flexibility

The MySQL database server provides the ultimate in scalability, sporting the capacity to
handle deeply embedded applications with a footprint of only 1MB to running massive
data warehouses holding terabytes of information. Platform flexibility is a stalwart
feature of MySQL with all flavors of Linux, UNIX, and Windows being supported. And,
of course, the open source nature of MySQL allows complete customization for those
wanting to add unique requirements to the database server.

• MySQL Server works in client/server or embedded systems.

The MySQL Database Software is a client/server system that consists of a multi-threaded

SQL server that supports different back ends, several different client programs and
libraries, administrative tools, and a wide range of application programming interfaces
(APIs).
A large amount of contributed MySQL software is available.

2.3.2.1 Features of MySQL:

INTERNALS AND PORTABILITY

• Written in C and C++.

• Uses GNU Auto make (1.4), Autoconf (Version 2.52 or newer), and Libtool for
portability.
• Works on many different platforms; APIs for C, C++, Eiffel, Java, Perl, PHP,
Python, Ruby, and Tcl.
• Fully multi-threaded using kernel threads, this means it can easily use multiple
CPUs if available.

Platforms

MySQL works on many different platforms — including AIX, BSDi, FreeBSD, HP-UX,
i5/OS, Linux, Mac OS X, NetBSD, Novell NetWare, OpenBSD, OS/2 Warp, QNX,
IRIX, Solaris, SunOS, SCO OpenServer, SCO UnixWare, Tru64, Windows 95, Windows
98, Windows ME, Windows NT, Windows 2000, Windows XP, and the 32-bit version of
Windows Vista (but not the 64-bit version). A port of MySQL to OpenVMS is also
available.

RIT, INDORE 9
 SPOUSAL

Uses
MySQL is popular for web applications and acts as the database component of the
LAMP, MAMP, and WAMP platforms (Linux/Mac/Windows-Apache-MySQL-
PHP/Perl/Python), and for open-source bug tracking tools like Bugzilla. Its popularity for
use with web applications is closely tied to the popularity of PHP and Ruby on Rails,
which are often combined with MySQL. PHP and MySQL are essential components for
running popular content management systems such as Joomla!, e107, Word Press,
Drupal, and some BitTorrent trackers. Wikipedia runs on MediaWiki software, which is
written in PHP and uses a MySQL database.

Because of the above features I’ have used MySQL as a Back End.

2.3.3 Rational Rose

Rational Rose is an object-oriented Unified Modeling Language (UML)

software design tool intended for visual modeling and component construction of
enterprise-level software applications. In much the same way a theatrical director blocks
out a play, a software designer uses Rational Rose to visually create (model) the
framework for an application by blocking out classes with actors (stick figures), use case
elements (ovals), objects (rectangles) and messages/relationships (arrows) in a sequence
diagram using drag-and-drop symbols. Rational Rose documents the diagram as it is
being constructed and then generates code in the designer's choice of C++, Visual Basic,
Java, Oracle8, CORBA or Data Definition Language.
Two popular features of Rational Rose are its ability to provide iterative
development and round-trip engineering. Rational Rose allows designers to take
advantage of iterative development (sometimes called evolutionary development)
because the new application can be created in stages with the output of one iteration
becoming the input to the next. (This is in contrast to waterfall development where the
whole project is completed from start to finish before a user gets to try it out.) Then, as
the developer begins to understand how the components interact and makes modifications
in the design, Rational Rose can perform what is called "round-trip engineering" by going
back and updating the rest of the model to ensure the code remains consistent.
Rational Rose is a tool set produced and marketed by Rational Software
Corporation (now owned by IBM). Rose is an operational tool set that uses the Unified
Modeling Language (UML) as its means for facilitating the capture of domain semantics
and architecture/design intent. UML has a number of different notations, allowing the
specification of the artifacts of design from many different perspectives and for different
objectives during the computer engineering life cycle. Most of these notations are
directly supported through the Rose tool set. One of the unique characteristics of Rose is
its ability to be extended through use of its "Add-In" capability. This allows the tool

RIT, INDORE 10
 SPOUSAL

functionality to be extended in a number of different directions, such as by adding new

tools, modifying existing ones.

Os used:

Windows 98/ Windows XP or any other higher version.

Hardware Requirement for project

No special requirement, any processor of Pentium family or equivalent,

128 MB of RAM and Secondary storage space of more than 5 GB.

RIT, INDORE 11
 SPOUSAL

3. PROCESS MODEL ADOPTED

3.1 Requirement Analysis

3.2 OOA
3.3 Architectural Specification
3.4 OOD
3.5 Software Development Process

A Process is a set of partially ordered steps intended to reach a goal. In software

engineering, goal is to efficiently and predictably deliver a software product that
meets the needs of business.

UML is largely process-independent; meaning that you can use it with a number
of software engineering processes. The Rational Unified Process is one such life
cycle approach that is especially well suited to the UML.

For design I used RUP for following reasons

 Architectural centric
 Employee industry standard language UML: To visualize modeling and
synthesis architecture and component.

3.1 REQUIREMENT ANALYSIS

The purpose of Requirement Analysis is:

 To come to an agreement with the customer and the users on what the
system should do.
 To give system developers a better understanding of the requirements of
the system.
 To define a user interface of the system.
 Understand the basic Requirements concepts and how they affect Analysis
and Design.

Requirements can be divided into two categories:

 Functional Requirement

 Non-Functional Requirement

RIT, INDORE 12
 SPOUSAL

Following are main artifacts used in project of requirement analysis:

Use case diagram:

The use case diagram shows a set of use cases , and actors (a
special kind of class) and their relationship.

Use case description:

The use case description tells story of how a system and its actor
collaborate to achieve a specific goal. It is step by step description of a particular
way of using a system.

3.2 OOA(OBJECT ORIENTED ANALYSIS)

The primary purpose of OOA is to formulate a model of the problem domain.
Analysis focuses on how top do. Here each use case is realized using class
diagram and sequence diagram.

Following artifacts of OOA is used in project:

Class Diagram:
A class diagram shows a set of classes, interfaces, collaboration
and their relationships.

Sequence Diagram:
A sequence diagram is an interaction diagram that emphasizes the
time ordering of the message. Sequence diagram shows a set of objects and the
message sent and received by those objects.

Collaboration Diagram:
A collaboration diagram is an interaction that emphasizes the
structural organization of the object that sends and receive message.

3.3 ARCHITECTURAL SPECIFICATION

In architecture, developer describes the system at a high level and decomposes the
system into smaller parts such as subsystem relationship. The data are highlighted
while the details of each part are deferred.

RIT, INDORE 13
 SPOUSAL

Architecture is all about managing complexity by dividing the solution into small
pieces and then combining the small system into large more coherent structure.

In the projects following step applied for the architecture:

 Set goals
 Grouping classes
 Show technology
 Evaluate against guideline and goals
 Extract modules

Set Goals

Functionality
Multi user is able to perform its work, ie. Many at a time.

Usability
The user interface used is very simple to use, response will be fast,
and navigation will be easy.

Maintainability
Maintenance will be one limitation of project because of
architecture used and lots of constraints, but still I tried to use
modules which are quiet cohesive within and less coupled to out.

Reliability
It depends on the user requirements.

 Security
The system is password protected.

 Scalability
The application is a Web Application.

Grouping classes

Classes in the project are divided into following category:

1. Boundary classes (which interacts with the user).

2. Entity classes (which performs one specific task).
3. Control classes (control Boundary & Entity Classes).

RIT, INDORE 14
 SPOUSAL

Boundary Entity

Control

MAIN COMPONENT DIAGRAM FOR

SPOUSAL

3.4 OOD(OBJECT ORIENTED DESIGN)

Following goals are established for the entire design:

 Clarity:
Strong cohesion within modules and weak coupling between
modules is target of entire design.

 Reuse Potential:
Classes kept small and well focused.

 Review prior steps:

The analysis model describes exactly what the system will do from
the developer’s perspective, the architecture describes the structural and
technology decision that constraints the design. Here the analysis model and
architecture design are review to apply the various constraints identified.

3.5 Software Development Process:

The spiral model is a software development process combining elements of

both design and prototyping-in-stages, in an effort to combine advantages of top-
down and bottom-up concepts. Also known as the spiral lifecycle model, it is a
systems development method (SDM) used in information technology (IT). This

RIT, INDORE 15
 SPOUSAL

model of development combines the features of the prototyping model and the
waterfall model. The spiral model is intended for large, expensive and
complicated projects.

The spiral model, also known as the spiral lifecycle model, is a systems development
method (SDM) used in information technology (IT). This model of development
combines the features of the prototyping model and the waterfall model. The spiral model
is intended for large, expensive, and complicated projects.
The steps in the spiral model can be generalized as follows:

RIT, INDORE 16
 SPOUSAL

1. The new system requirements are defined in as much detail as possible. This
usually involves interviewing a number of users representing all the external or
internal users and other aspects of the existing system.
2. A preliminary design is created for the new system.
3. A first prototype of the new system is constructed from the preliminary design.
This is usually a scaled-down system, and represents an approximation of the
characteristics of the final product.
4. A second prototype is evolved by a fourfold procedure:
1. evaluating the first prototype in terms of its strengths, weaknesses, and
risks;
2. defining the requirements of the second prototype;
3. planning and designing the second prototype;
4. constructing and testing the second prototype.
5. At the customer's option, the entire project can be aborted if the risk is deemed
too great. Risk factors might involve development cost overruns, operating-cost
miscalculation, or any other factor that could, in the customer's judgment, result in
a less-than-satisfactory final product.
6. The existing prototype is evaluated in the same manner as was the previous
prototype, and, if necessary, another prototype is developed from it according to
the fourfold procedure outlined above.
7. The preceding steps are iterated until the customer is satisfied that the refined
prototype represents the final product desired.
8. The final system is constructed, based on the refined prototype.
9. The final system is thoroughly evaluated and tested. Routine maintenance is
carried out on a continuing basis to prevent large-scale failures and to minimize
downtime.

RIT, INDORE 17
 SPOUSAL

4. Use Case Diagrams & Descriptions

4.1 Use case Diagram

4.2 Actors
4.3 Use case Diagram and Description

4.1 Use Case Diagram:

A use case diagram is a type of behavioral diagram defined by the Unified Modeling
Language (UML). Its purpose is to present a graphical overview of the functionality
provided by a system in terms of actors, their goals—represented as use cases—and any
dependencies between those use cases.
The two main components of a use case diagram are use cases and actors.

4.2 Actors

An actor defines a coherent set of roles that user of an entity can play when
interacting with the entity. An actor may be considered to play a separate role
with regard to each Use Case with which it communicates.
In developing the project “www.Spousal.com” following actors is identified:

Registered user

A registered user (Bride/Groom) can….

Enter self information
Post the information for some relative
View other user information (if permitted)
Not modify information except self
Perform various searches

Unregistered user

An unregistered user (Bride/Groom) can….

Enter self information
Become registered user by filling registration form
View other user limited information

RIT, INDORE 18
 SPOUSAL

Perform quick search

4.3 Use case Diagram and Description

4.3.1 Main Use Case Diagram

This is a comprehensive picture for all actors and use cases involved in the
project, partially demonstrate interaction/relation among them.

Use Case Diagram (Main)

RIT, INDORE 19
 SPOUSAL

4.3.2 Registration of user use case diagram

This diagram shows interaction between actors and use cases which takes place
during Registration of users

REGISTER

«include»

REGISTRATION
FORM

ADMINISTRATOR UNREGISTERED
USER

USECASE DIAGRAM::
REGISTRATION FORM

Use Case Diagram (Registration)

RIT, INDORE 20
 SPOUSAL

Registration of user Use Case Description

1. Description →
This use case will allow user to register them for browsing profile.

2. Precondition →

A) The user should have logged in by giving correct user name and password.
B) Personal Information should be uploaded by user for further usage as other can browse
there profile accordingly.

3. Primary Flow →

A) The use case begins when the user enters his user name and password correctly
B) Then it check whether the user is registered or unregistered so according to that
functionality is provided to them
C) System checks whether the password is correct. If it is incorrect then alternate flow A1
executes.

4. Alternate Flow A1 → Invalid Password

System prompts the user that password entered is incorrect & that the user should re-enter
it.

RIT, INDORE 21
 SPOUSAL

4.3.3 Quick search use case diagram

This diagram shows interaction between actors and use cases which takes place
during job through quick search

COMMUNITY LOOKING

AGE
«include»
«include»

«include»

VIEW LIST

«include»

QUICK SEARCH

ADMINISTRATOR BRIDE GROOM UNRIGISTERED

USER

Use Case Diagram (quick search jobs)

RIT, INDORE 22
 SPOUSAL

Quick search Use Case Description

1. Description →

This use case will allow user to search or browse profile.

2. Precondition →

A) The user should have logged in by giving correct user name and password.
B) If available then only user can interact with other user.

3. Primary Flow →

A) The use case begins when the user enters his user name and password correctly
B) Then it check whether the user is registered or unregistered so according to that
functionality is provided to them
C) System checks whether the password is correct. If it is incorrect then alternate flow A1
executes.

4. Alternate Flow A1 → Invalid Password

System prompts the user that password entered is incorrect & that the user should re-enter
it.

RIT, INDORE 23
 SPOUSAL

4.3.4 Browse Profile use case diagram

RIT, INDORE 24
 SPOUSAL

Browse Profile Use Case Description

1. Description →

This use case will allow user to Browse Profile.

2. Precondition →

A) The user should have logged in by giving correct user name and password.

3. Primary Flow →

A) The use case begins when the user enters his user name and password correctly
B) Then it check whether the user is registered or unregistered so according to that
functionality is provided to them
C) System checks whether the password is correct. If it is incorrect then alternate flow A1
executes.

4. Alternate Flow A1 → Invalid Password

System prompts the user that password entered is incorrect & that the user should re-enter
it.

RIT, INDORE 25
 SPOUSAL

UENCE DIAGRAM
6.1 Sequence Diagram Model
5. SEQUENCE DIAGRAM
5.1 Sequence Diagram Model
5.2 Sequence Diagrams

5.1 SEQUENCE DIAGRAM MODEL

Sequence diagrams model the flow of logic within your system in a visual manner,
enabling you both to document and validate your logic, and are commonly used for both
analysis and design purposes.
Sequence diagrams are typically used to model:

1. Usage scenarios

A usage scenario is a description of a potential way your system is used. The logic of a
usage scenario may be part of a use case, perhaps an alternate course. It may also be one
entire pass through a use case, such as the logic described by the basic course of action or
a portion of the basic course of action, plus one or more alternate scenarios. The logic of
a usage scenario may also be a pass through the logic contained in several use cases. For
example, a student enrolls in the university, and then immediately enrolls in three
seminars.

2. The logic of methods

Sequence diagrams can be used to explore the logic of a complex operation, function, or
procedure. One way to think of sequence diagrams, particularly highly detailed
diagrams, is as visual object code.

5.2 Sequence Diagrams

 Search
 Browse profile
 Quick search

RIT, INDORE 26
 SPOUSAL

5.2.1 Search Sequence Diagram

Following shows the time sequence of messages exchanged between different

:USER
:MAIN FORM :VALIDATE :SEARCHLIST_FORM :DATABASE

ENTER_USERTYPE

OPEN()

PROMT_FOR_PASSWORD()

ENTER_PASSWORD()

OPEN_SEARCH_LIST()

SEARCH_LIST_LOAD()

CMD_BACK()

RETURN_TO_USER()

SEQUENCE DIAGRAM :: SEARCH

RIT, INDORE 27
 SPOUSAL

5.2.2 Browse Profile Sequence Diagram

Following shows the time sequence of messages exchanged between different
objects and classes while modification of resume.

:USER :MAIN FORM :VALIDATE :BROWSE_FORM :DATABASE

ENTER_USERTYPE

OPEN()

PROMT_FOR_PASSWORD()

ENTER_PASSWORD()

OPEN_BROWSE_LIST()

ENTER CHOICE

BROWSE_LIST_LOAD()

CMD_BACK()

RETURN_TO_USER()

SEQUENCE DIAGRAM :: BROWSE PROFILE

RIT, INDORE 28
 SPOUSAL

6. COLLABORATION DIAGRAM
6.1 Collaboration Diagram Model
6.2 Collaboration Diagram
6.1 COLLABORATION DIAGRAM MODELS
UML Collaboration diagrams (interaction diagrams) illustrate the relationship and
interaction between software objects. They require use cases, system operation contracts,
and domain model to already exist. The collaboration diagram illustrates messages being
sent between classes and objects (instances). A diagram is created for each system
operation that relates to the current development cycle (iteration).
When creating collaboration diagrams, patterns are used to justify relationships. Patterns
are best principles for assigning responsibilities to objects and are described further in the
section on patterns. There are two main types of patterns used for assigning
responsibilities which are evaluative patterns and driving patterns.
Each system operation initiates a collaboration diagram.

6.2 Collaboration Diagram

6.2.1 Search
6.2.2 Browse profile
6.2.3 Quick search

RIT, INDORE 29
 SPOUSAL

6.2.1 Search Collaboration diagram

7.CMD_BACK

8.RETURN TO :SEARCHLIST_FORM :DATABASE

USER

6.SEARCHLIST
LOAD

4.ENTER
PASSWORD
:USER
5.OPEN
SEARCH
3.PROMPT FOR LIST
PASSWORD
1.ENTER
USER

:VALIDATE
2.OPEN

:MAIN FORM

COLLABRATION DIAGRAM :: SEARCH

RIT, INDORE 30
 SPOUSAL

6.2.2 Browse Profile Collaboration Diagram

7.CMD BACK

8.RETURN :BROWSE_FORM
TO USER

:DATABASE

6.BROWSELIST
LOAD

4.ENTER
PASSWORD
:USER

3.PROMPT FOR
PASSWORD 5.OPEN BROWSE
LIST
1.ENTER USERTYPE

:VALIDATE
2.OPEN

:MAIN FORM

COLLABRATION
COLLABRATION DIAGRAM
DIAGRAM :: BROWSE
:: BROWSE PROFILE

7. Component Diagram

RIT, INDORE 31
 SPOUSAL

In the Unified Modeling Language, a component diagram depicts how a

software system is split up into components and shows the dependencies among
these components. Physical components include files, headers, link libraries,
modules, executables, or packages. Component diagrams are prevalent in the field
of software architecture but can be used to model and document any system’s
architecture.

7.1 Control Package

welcome home

login

COMPONENT DIAGRAM : CONTROL PACKAGE

7.2 Boundary Package

RIT, INDORE 32
 SPOUSAL

7.3 Entity Package

RIT, INDORE 33
 SPOUSAL

RIT, INDORE 34
 SPOUSAL

8. DEPLOYMENT DIAGRAM
The Deployment diagram models the hardware used in implementing a system and the
association between those hardware components. Components can also be shown on a
Deployment diagram to show the location of their deployment. Deployment diagrams can
also be used early on in the design phase to document the physical architecture of a
system.
The elements used in Deployment diagrams are Components, as we have seen in
Component diagrams, Nodes, which represent the physical processing resources in the
system, and Associations.

Component A component represents a software entity in a

system. Examples include source code files,
programs, documents, and resource files. On a
deployment diagram, components are placed
within nodes to identify their deployed location. A
component is represented using a rectangular box,
with two rectangles protruding from the left side,
as seen in the image to the right.

Node A node represents a piece of hardware in the

system. This entity is represented by a three-
dimensional cube.

Association An association, drawn as a solid line between two

Nodes, indicates a line of communication between
the hardware elements.

RIT, INDORE 35
 SPOUSAL

• Captures the distinct number of computers involved

• Shows the communication modes employed
• Component diagrams can be embedded into deployment diagrams
effectively

RIT, INDORE 36
 SPOUSAL

10. Data Model

A data model is an abstract model that describes how data is represented and accessed.
The term data model has two generally accepted meanings:
1. A data model theory, i.e. a formal description of how data may be structured
and accessed.
2. A data model instance, i.e. applying a data model theory to create a practical
data model instance for some particular application.

RIT, INDORE 37
 SPOUSAL

RIT, INDORE 38
 SPOUSAL

11. Entity Relationship Diagram:

An entity-relationship model is an abstract conceptual representation of structured

data. Entity-relationship modeling is a relational schema database modeling method, used
in software engineering to produce a type of conceptual data model (or semantic data
model) of a system, often a relational database, and its requirements in a top-down
fashion. Diagrams created using this process are called entity-relationship diagrams, or
ER diagrams for short. Originally proposed in 1976 by Dr. Pin-Shan (Peter) Chen , many
variants of the process have subsequently been devised.
Entity-relationship diagrams don't show single entities or single instances of relations.
Rather, they show entity sets and relationship sets. Example: a particular song is an
entity. The collection of all songs in a database is an entity set. The eaten relationship
between a child and her lunch is a single relationship. The set of all such child-lunch
relationships in a database is a relationship set.

RIT, INDORE 39
 SPOUSAL

RIT, INDORE 40
 SPOUSAL

13. TIME LINE CHART

The development details of the project is planned and documented in the form of
Gantt chart as follows

Work Tasks aug’07 sep’07 oct’07 nov’07 dec’07 jan’08 feb’08 mar’08 apr’08

1. Problem Definition
Gathering the
requirements
Obtaining the list of
tasks to be performed
Preparation of the
problem definition
MILESTONE: writing
problem definition
2. Preparation of
Functional
Specification
Make a brief overview of
the system
Prepare a list of the
objectives, goals,
anticipated benefits and
scope.
MILESTONE: Defining
the functional
specification.
3. Decide on the process
model to be used
Considered the
alternative process
models available for
use.
Deciding the relevant
model on the basis of
requirements.

RIT, INDORE 41
 SPOUSAL

Work Tasks aug’07 sep’07 oct’07 nov’07 dec’07 jan’08 feb’08 mar’08 apr’08

Writing the
description of the
process model
MILESTONE: process
Model Chosen.
4. Perform the
Requirement Analysis
Write out the
requirement
documentation including
the requirement,
definition and the
requirement
specification.
MILESTONE:
Completion of the
requirement analysis
phase.
5. Planning the Project
Determine the project
scope.
Determine the project
resources.
MILESTONE: Plan of
the project completed.
6. Identify the sub-
system
Separation module-wise
information.
Modularize software.
MILESTONE: Back end
modularized.
7. Design Modules
Designing of Login Form
module.
Designing of Search
Form Module

RIT, INDORE 42
 SPOUSAL

Work Tasks aug’07 sep’07 oct’07 nov’07 dec’07 jan’08 feb’08 mar’08 apr’08
Designing of Advance
search module.
Designing of Photo
Gallery search
Designing of Personal
profile page module.
Designing of Database
MILESTONE:
Completion of the design
of System Modules.
8. Deciding Tools &
Database System
Comparison of available
tools.
Evaluate the selected
tool. Decide the
architecture to be used.
Choose Database System.
MILESTONE: Tool &
Architecture decided.
9. Implementation of
the Project Modules
Coding the login form
module.
Coding the Search
module.
Coding the Photo Gallery
search module.
Coding the Advance
search module.
Coding the Personal
profile page module.
Coding the up gradation
Submodule.
MILESTONE:
Completion of Coding
the System Modules.
10. Testing
Perform White Box &
Black Box Testing
Test each individual
function and the entire
system as a unit
MILESTONE:
Completion of Testing.

14. COST ESTIMATION

RIT, INDORE 43
 SPOUSAL

COCOMO
Boehm derived a cost model called COCOMO (Constructive Cost Model) using data
from a large set of projects at TRW, a consulting firm based in California (Fenton, 1997).
COCOMO is a relatively straightforward model based on inputs relating to the size of the
system and a number of cost drivers that affect productivity. The original COCOMO
model was first published in 1981 (Boehm, 1981). Boehm and his colleagues have since
defined an updated COCOMO, called COCOMO II, which accounts for recent changes in
software engineering technology (Fenton, 1997).

Original COCOMO

The original COCOMO is a collection of three models:

A Basic model that is applied early in the project, an Intermediate model that is applied
after requirements are specified, and an Advanced model that is applied after design is
complete.
All three models take the form:
E = aS^b x EAF
where E is effort in person months, S is size measured in thousands of lines of code
(KLOC), and EAF is an effort adjustment factor (equal to 1 in the Basic model) .The
factors a and b depend on the development mode.
Boehm has defined three development modes:
• Organic mode – relatively simple projects in which small teams work to a set
of informal requirements.

• Semi-detached mode – an intermediate project in which mixed teams must

work to a set of rigid and less than rigid requirements.

• Embedded mode – a project that must operate within a tight set of

constraints.

Basic COCOMO Model

The Basic COCOMO model computes effort as a function of program size (Pressman,
1997).
The Basic COCOMO equation is:
E = aKLOC^b
The factors a and b for the Basic COCOMO model are shown in Table 3 (Boehm, 1981).

RIT, INDORE 44
 SPOUSAL

Effort for three modes of Basic COCOMO

Mode a b
Organic 2.4 1.05
Semi-detached 3.0 1.12
Embedded 3.6 1.20

Intermediate COCOMO Model

The Intermediate COCOMO model computes effort as a function of program size and a
set of cost drivers (Pressman, 1997). The Intermediate COCOMO equation is:
E = aKLOC^b x EAF
The factors a and b for the Intermediate COCOMO model are shown in Table 4 (Boehm,
1981).

Effort parameters for three modes of Intermediate COCOMO

Mode a b
Organic 3.2 1.05
Semi-detached 3.0 1.12
Embedded 2.8 1.20

The effort adjustment factor (EAF) is calculated using 15 cost drivers. The cost drivers
are grouped into four categories: product, computer, personnel, and project. Each cost
driver is rated on a six-point ordinal scale ranging from low to high importance. Based on
the rating, an effort multiplier is determined using Table 5 (Boehm, 1981). The product
of all effort multipliers is the EAF.
Current Semester Project
Sr Measurement Count Weighting Factor Total
.No. parameter
Simple Average Complex Weighting
Factor*Count

1 Number of input 8 3 4 6 24
2 Number of output 11 4 5 7 44
3 Number of files 10 3 4 6 40

RIT, INDORE 45
 SPOUSAL

4 Number of inquiry 4 7 10 15 40
5 Number of interfaces 3 5 7 10 15

Total count: - 163 i.e. UFP=24+44+40+40+15= 163

Factors Complexity Adjustment questions Values(0-5)

F1 Does the system require reliable backup and recovery? 5
F2 Are data communications required? 4
F3 Are the distributed processing functions? 0
F4 Is performance critical? 2
F5 Will the system run in an existing, heavily utilized operational 5
environment?
F6 Does the system require on line data entry? 4
F7 Does the on line data entry requires the input transaction to be 0
built over multiple screen or operations?
F8 Are the master files updated online? 4
F9 Are the inputs, outputs, files, or inquires complex? 4
F10 Is the internal processing complex? 4.5
F11 Is the code designed to be reusable? 3.5
F12 Are conversion and installation included in the design? 1
F13 Is the system designed for multiple installations in different 3
organizations?
F14 Is the application designed to facilitate change and ease of use 3
by the user?

Total: - 43

FP = UFP*(0.65+0.01*∑F)
=176.04
≈176

1FP=32LOC in VB

176*32=5632LOC
=5.6KLOC
≈6KLOC

Type Efforts Tdev

A1 A2 B1 B2
Organic 2.4 1.05 2.5 0.38
Semidetached 3.0 1.12 2.5 0.35

RIT, INDORE 46
 SPOUSAL

Embedded 3.6 1.20 2.5 0.32

Our system is organic because of less complexity of the system and understanding of the
functionality of the system was easy. Also the project length is 6 KLOC which comes
under the category of organic systems.

Effort = A1*(KLOC)^A2
=2.4 * 6 ^ 1.05
≈16 PM

Tdev=B1 * (Effort) ^ B2
=7.16
≈ 7 months

13. CONCLUSION

13.1 Limitations of projects:

RIT, INDORE 47