INSTITUTE FOR ADVANCED COMPUTING AND SOFTWARE DEVELOPMENT AKURDI, PUNE

SRS ON INTRANET CHATTING SERVER DAC-Feb-2012

Submitted By:
Group No: 20

Mansi Goyal (1032) Ajay Chouhan (1078) Rakesh Lokhande (1056) Yogeshwar Chandegave (1076)

Mr. Dhananjay N. Patil

Mr. Mahendra Waghmare

Course Coordinator

Project Guide

Table of Contents ................................................................................2 List of Figures.................................................................................................2 Introduction....................................................................................................3 Initial functional requirements will be: -.........................................................4 Initial non functional requirements will be: -..................................................4 2.0. Overall Description...................................................................................5
2.1 System Environment ....................................................................................................................................................5 2.2 Functional Requirements Specification.......................................................................................................................5 Use case: Search Article............................................................................................................................................5 2.2.3 Editor Use Cases...................................................................................................................................................6 Use case: Update Author...........................................................................................................................................7 Use case: Update Reviewer.......................................................................................................................................7 Use case: Update Article...........................................................................................................................................8 Use case: Receive Article..........................................................................................................................................8 Use case: Assign Reviewer.......................................................................................................................................9 Use case: Receive Review.......................................................................................................................................10 Use case: Check Status............................................................................................................................................10 Use case: Add to Cart..............................................................................................................................................11 Use case: Selling old servers...................................................................................................................................11 2.3 User Characteristics....................................................................................................................................................12 2.4 Non-Functional Requirements...................................................................................................................................12 3.1 External Interface Requirements................................................................................................................................13 3.2 Detailed Non-Functional Requirements.....................................................................................................................13 .....................................................................................................................................................................................13 3.3.2 Security................................................................................................................................................................21 1.4. References...................................................................................................................................................................4 1.5. Overview of Document...............................................................................................................................................4 1.1. Purpose........................................................................................................................................................................3 1.2. Scope of Project..........................................................................................................................................................4

3.0. Requirements Specification....................................................................13

List of Figures Figure 1 - System Environment.......................................................................5 Figure 2 - Editor Use Cases.............................................................................6

Introduction
1.1. Purpose The client server model is still used today on the internet where a user computing may connect to a s er vi ce operatin g on a remote sys tem th rough th e intern et protocol s uite web b rowser are clients that connect to web server and retrieve web page for display. Most people use Email client to retrieve their Email from their Internet service provider's mail storage servers. Online Chat uses a variety of clients, which vary depending on the chat protocol being used. Game Clients usually refer to the software that is the game in only multiplayer online games for the computer. Increasi ngly, exis tin g large cli ent ap p li cati ons are bein g swi tch ed to websi tes , making the brows er a sort of un iv er sal client. This avoids th e hass le of downloading a large piece of software onto any computer you want to use the application on. An example of this is the rise of Webmail. SERVER A server computer is a computer dedicated to running a server application. A server application is a Computer program that accepts Computer network connections in order to service requests by sending back responses. Examples of server applications include Mail transfer agent, Fileserver, and Proxy server. Server is also a designation for computer models intended for use in running server applications, often under heavy workloads, unattended, for an extended period of time. While any workstation computer can run server operating systems and server applications ,a server computer usually has special features intended to make it more suitable. These features can include a faster Central processing unit, faster and more plentiful RAM, and larger Hard disk drive, but these traits are shared with high-end Desktop computer More obvious distinctions include redundancy in power supplies, network connections, and RAID as well as Modular design. CLIENT A client is an Application software or system that accesses a remote service o n a n o t h e r C o m p u t e r s y s t e m , k n o w n a s a S e r v e r c o m p u t i n g, b y w a y o f a N e t w o r k . Th e t e r m w a s f i r s t applied to Peripheral device that were not capable of running their own stand-alone Computer program, but could interact with remote computers via a network. These Dumb terminals were clients of the Time sharing Mainframe compute

1.2. Scope of Project Initial functional requirements will be: Secure registration and profile management facilities for Client Creating a Server so that Client can communicate n no. of users and checkout finally with the entire Server. Browsing through the e-Mall to see the items that are there in each category of servers like Apparel, Kitchen accessories, Bath accessories, Food items etc. Adequate searching mechanisms for easy and quick access to communicate each other. This software system will be a server for a Communicating System. This system will be designed to maximize the users connectivity by providing tools to assist in automating the clients review and issuing users for Communication. Any client can become a member (for free) and then can influence or be influenced by others. Initial non functional requirements will be: Secure access of confidential data (users details). SSL can be used. 24 X 7 availability. Better component design to get better performance at peak time Advertisement space where it will effectively catch the customers attention and as a source of revenue. 1.4. References IEEE. IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specifications. IEEE Computer Society, 1998. 1.5. Overview of Document The next chapter, the Overall Description section, of this document gives an overview of the functionality of the server. It describes the informal requirements and is used to establish a connection for the technical requirements specification in the next chapter. The third chapter, Requirements Specification section, of this document is written primarily for the developers and describes in technical terms the details of the functionality of the server. Both sections of the document describe the same Chat server in its entirety, but are intended for different users and thus use different language.

2.0. Overall Description

2.1 System Environment

Figure 1 - System Environment

OSS User

Visitor

Customer

Administrtor

2.2 Functional Requirements Specification This section outlines the use cases for each of the active users separately. The Client, and the server have only one use case a piece while the admin is main actor in this system. Use case: Search Article Diagram:

Search Products

User

Brief Description The client accesses the Chat Server, searches for an user and connect with it.

Initial Step-By-Step Description Before this use case can be initiated, the User has already Logged On to the Chat Server. Client Initiates requests Waits for and receives replies Usually connects to a small number of servers at one time Typically interacts directly with end-users using a Graphical user interface Server 1. The Server then checks for proper validation and provide connection to the client. 2. The system displays the list of registered user to the Client. 5. The server Provides users for communication.

Diagram:
2.2.3 Editor Use Cases The Editor has the following sets of use cases:

Update Info Handle Art

Status

Editor Send Rec Publish Art

Figure 2 - Editor Use Cases Update Information use cases

Use case: Update Author Diagram:

Update Author

Editor

Brief Description The Editor enters a new Author or updates information about a current Author.

Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager. The Editor selects to Add/Update Author. 2. The system presents a choice of adding or updating. 3. The Editor chooses to add or to update. 4. If the Editor is updating an Author, the system presents a list of authors to choose from and presents a grid filling in with the information; else the system presents a blank grid. 5. The Editor fills in the information and submits the form. 6. The system verifies the information and returns the Editor to the Article Manager main page.
1.

Use case: Update Reviewer Diagram:

Update Reviewer MANAGER

Editor

Brief Description The Editor enters a new Reviewer or updates information about a current Reviewer. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager. The Editor selects to Add/Update Reviewer. 2. The system presents a choice of adding or updating.
1.

The Editor chooses to add or to update. The system links to the Historical Society Database. If the Editor is updating a Reviewer, the system and presents a grid with the information about the Reviewer; else the system presents list of members for the editor to select a Reviewer and presents a grid for the person selected. 6. The Editor fills in the information and submits the form. 7. The system verifies the information and returns the Editor to the Article Manager main page.
3. 4. 5.

Use case: Update Article Diagram:

Update Article

Editor

Brief Description The Editor enters information about an existing article. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager.
1. 2. 3. 4. 5.

The Editor selects to Update Article. The system presents s list of active articles. The system presents the information about the chosen article. The Editor updates and submits the form. The system verifies the information and returns the Editor to the Article Manager main page.

Handle Article use cases Use case: Receive Article Diagram:

Receive Article

Editor

Brief Description The Editor enters a new or revised article into the system. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the main page of the Article Manager and has a file containing the article available. The Editor selects to Receive Article. The system presents a choice of entering a new article or updating an existing article. The Editor chooses to add or to update. If the Editor is updating an article, the system presents a list of articles to choose from and presents a grid for filling with the information; else the system presents a blank grid. 5. The Editor fills in the information and submits the form. 6. The system verifies the information and returns the Editor to the Article Manager main page.
1. 2. 3. 4.

Use case: Assign Reviewer This use case extends the Update Article use case. Diagram:

Assign Reviewer

CUSTOMER

MANAGER

Brief Description The Editor assigns one or more reviewers to an article. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. 2. 3. 4. 5. 6. 7.

The Editor selects to Assign Reviewer. The system presents a list of Reviewers with their status (see data description is section 3.3 below). The Editor selects a Reviewer. The system verifies that the person is still an active member using the Historical Society Database. The Editor repeats steps 3 and 4 until sufficient reviewers are assigned. The system emails the Reviewers, attaching the article and requesting that they do the review. The system returns the Editor to the Update Article use case.

Use case: Receive Review This use case extends the Update Article use case. Diagram:

Receive Review

MANAGER

Brief Description The Editor enters a review into the system. Initial Step-By-Step Description Before this use case can be initiated, the Editor has already accessed the article using the Update Article use case.
1. 2. 3. 4.

The Editor selects to Receive Review. The system presents a grid for filling with the information. The Editor fills in the information and submits the form. The system verifies the information and returns the Editor to the Article Manager main page.

Check Status use case: Use case: Check Status Diagram:

Check Status

CUSTOMER

Brief Description The Customer checks the list of all servers. Initial Step-By-Step Description Before this use case can be initiated, the Customer has already accessed the main page of the Category.
1. 2. 3.

The Customers selects to Category. The system returns a scrollable list of all available servers with their lists of servers . The system returns the list of server of selected Category.

Add to cart use cases: Use case: Add to Cart This use case extends the use case. Diagram:

Add to Cart

CUSTOMER

Brief Description It adds the selected servers into shopping cart. Initial Step-By-Step Description Before confirmation system will ask to user for Continue shopping or Buy Now. 1. If customers select to continue shopping then control goes to Home page and carrys the process of shopping. 2. If Customers select Buy Now, if customer registered already then system ask to give the user name and password or if not registered then system will allow to create a new account. 3. Customers have to provide his card number for payment the bill. 4. After successfully buying system will gives the confirmation of transaction.

Use case: Selling old servers This use case extends the Selling old servers use case. Diagram:

Selling old products

Customer

Brief Description Only Registered customers can sell his old servers through our websites. Initial Step-By-Step Description

Before this use case customers must have to already buy the server from our websites. System will ask to Customers to details such as Server Id, Server Name, Server Description. .To proceed further system will ask to give Card Number to accept the request for Customers selling order. 3. The system returns the Customers to the Home page. 4. After that the old server will added into the Category of Sell old Servers.
1. 2.

2.3

User Characteristics The User is expected to be Internet literate and be able to use a search engine. The main screen of the Online Shopping Website will have the search function and a link to Administrator/Reviewer Information. The Administrator and Reviewer are expected to be Internet literate and to be able to use internet transaction. The Administrator is expected to be Windows literate and to be able to use button, pull-down menus, and similar tools. The detailed look of these pages is discussed in section 3.2 below. 2.4 Non-Functional Requirements 2.4.1 Behavioral It determines how much effort and time will go into educating, selling and training the user staff on a candidate system. 2.2.3 Economical A system developed technically and that will be used if installed must be still profitable for the organization .Financial benefits must equal or exceed the cost. In this feasibility following things are calculated:-(a) The cost to conduct a full system investigation.(b) The cost of hardware and software. (c) The cost of checking costly errors. Feasibility Study for the Project The Project CHAT SERVER satisfies all the feasibility criteria. The software used are open source software easily available in market. The hardware required to develop this system is a desktop computer with descent computing power. In case of financial feasibility, it is quite economical, only hardware circuit requires spending small money. In case of administrative feasibility no special training is required for the users as the project is very user-friendly, only working knowledge of computer is required.

3.0. Requirements Specification

3.1 External Interface Requirements The project is implemented in Core Java and JSP (Java Server Pages) as it provides the i m p l e m e n t a t i o n o f S o c k e t a n d S e r v e r S o c k e t c l a s s e s t h a t a r e u s e d t o c o n n e c t d i s t i n c t applications, hence the softwares required in the creation and execution of the project are j2sdk1.6 or JAVA D E V E L O P M E N T K I T 6 . A s w e k n o w J A V A i s a p l a t f o r m i n d e p e n d e n t language so this software runs with JRE environment on any desired platform i.e. windows 9x,XP, or 2000 operating system and Apache Tomcat 7.0 as a web server. Hardware Required: As the project does not involve any database, its hardware requirements are m i n i m a l . A n y System with Pentium P2 or above processor, 32MB RAM, 1GB Hard Disk, a LAN Card, and a CDROM is sufficient. Its network based software so computers connected with any kind of mode (wireless, LAN connected etc) will suit its requirements. It can also be run on a single machine for its demo use. Best suited in laboratory where we can run its server on any machine and many clients can use it simultaneously. 3.2 Detailed Non-Functional Requirements

3.2.1 LAN or local wireless network but later we can make this run on internet by providing public IP address and making it run global.We can handle user data separately proving them password access. We can also improvise it for private conversation with a user selected user. We can also add various emotions and smilies. Most important addition about which we our thinking is telecommunication through as presently available in g-talk and other chatting software. 3.2.2 .Functional Requirement:
The project is implemented in Core Java and JSP (Java Server Pages) as it provides the i m p l e m e n t a t i o n o f S o c k e t a n d S e r v e r S o c k e t c l a s s e s t h a t a r e u s e d t o c o n n e c t d i s t i n c t applications, hence the softwares required in the creation and execution of the project are j2sdk1.6 or JAVA DEVELOPMENT KIT 6 . A s w e k n o w J A V A i s a p l a t f o r m i n d e p e n d e n t language so this software runs with JRE environment on any desired platform i.e. windows 9x,XP, or 2000 operating system and Apache Tomcat 7.0 as a web server. Hardware Required: As the project does not involve any database, its hardware requirements are m i n i m a l . A n y System with Pentium P2 or above processor, 32MB RAM, 1GB Hard Disk, a LAN Card, and a CDROM is sufficient. Its network based software so computers connected with any kind of mode (wireless, LAN connected etc) will suit its requirements. It can also be run on a single machine for its demo use. Best suited in laboratory where we can run its server on any machine and many clients can use it simultaneously.

Software Analysis Report

About java: Features Platform Independent The concept of Write-once-run-anywhere (known as the Platform independent) is one of the important key feature of java language that makes java as the most powerful language. Not even a single language is idle to this feature but java is closer to this feature. The programs written onone platform can run on any platform provided the platform must have the JVM. Simple There are various features that make the java as a simple language. Programs are easy to write and debug because java does not use the pointers explicitly. It is much harder to write the java programs that can crash the system but we can not say about the other programming languages. Java provides the bug free system due to the strong memory management. It also has the automatic memory allocation and de-allocation system. Object Oriented To be an Object Oriented language, any language must follow at least the four characteristics. programming languages. Compiler checks the program whether there any error and interpreter checks any run time error and makes the system secure from crash. All of the above featuresmakes the java language robust. Inheritance : It is the process of creating the new classes and using the behavior of thee x i s t i n g c l a s s e s b y e x t e n d i n g t h e m j u s t t o r e u s e t h e e x i s t i n g c o d e a n d a d d i n g t h e additional features as needed. E n c a p s u l a t i o n : I t i s t h e m e c h a n i s m o f c o m b i n i n g t h e i n f o r m a t i o n a n d p r o v i d i n g t h e abstraction. Polymorphism: As the name suggest one name multiple form, Polymorphism is the wayof providing the different functionality by the functions having the same name based onthe signatures of the methods. Dynamic binding: Sometimes we don't have the knowledge of objects about their specifictypes while writing our code. It is the way of providing the maximum functionality to a program about the specific type at runtime.As the languages like Objective C, C++ fulfills the above four characteristics yet they are notfully object oriented languages because they are structured as well as object oriented languages.But in case of java, it is a fully Object Oriented language because object is at the outer mostlevel of data structure in java. No stand alone methods, constants, and variables are there in java.Everything in java is object even the primitive data types can also be converted into object byusing the wrapper class. Robust Java has the strong memory allocation and automatic garbage collection mechanism. It provides the powerful exception handling and type checking mechanism as compare to other

Distributed The widely used protocols like HTTP and FTP are developed in java. Internet programmers canc all functions on these protocols and can get access the files from any remote machine on the internet rather than writing codes on their local system. Portable The feature Write-once-run-anywhere makes the java language portable provided that the system must have interpreter for the JVM. Java also have the standard data size irrespective of operating system or the processor. These features make the java as a portable language. Dynamic While executing the java program the user can get the required files dynamically from a local drive or from a computer thousands of miles away from the user just by connecting with the Internet. Secure Java does not use memory pointers explicitly. All the programs in java are run under an area known as the sand box. Security manager determines the accessibility options of a class like reading and writing a file to the local disk. Java uses the public key encryption system to allow the java applications to transmit over the internet in the secure encrypted form. The byte code Verifier checks the classes after loading. Performance Java uses native code usage, and lightweight process called threads. In the beginning interpretation of byte code resulted the performance slow but the advance version of JVM uses the adaptive and just in time compilation technique that improves the performance. Multithreaded. Java is also a multithreaded programming language. Multithreading means a single program having different threads executing independently at the same time. Multiple threads execute instructions according to the program code in a process or a program. Multithreading works the similar way as multiple processes run on one computer. Multithreading programming is a very interesting concept in Java. In multithreaded programs not even a single thread disturbs the execution of other thread. Threads are obtained from the pool of available ready to run threads and they run on the system CPUs. This is how Multithreading works in Java which you will soon come to know in details in later chapters. Interpreted we all know that Java is an interpreted language as well. With an interpreted language such as Java, programs run directly from the source code. The interpreter program reads the source code and translates it on the fly into computations. Thus, Java as an interpreted language depends on an interpreter program. The versatility of being platform independent makes Java to outshine from other languages.The source code to be written and distributed is platform independent.Another advantage of Java as an interpreted language is its error debugging quality. Due to thisany error occurring in the program gets traced. This is how it is different to work with Java.

Architecture Neutral The term architectural neutral seems to be weird, but yes Java is an architectural neutral languageas well. The growing popularity of networks makes developers think distributed. In the world of network it is essential that the applications must be able to migrate easily to different computer systems. Not only to computer systems but to a wide variety of hardwarearchitecture and operating system architectures as well. The Java compiler does this bygenerating byte code instructions, to be easily interpreted on any machine and to be easilytranslated into native machine code on the fly. The compiler generates an architecture-neutral object file format to enable a Java application to execute anywhere on the network and then the compiled code is executed on many processors, given the presence of the Java runtime system. Hence Java was designed to support applications on network. This feature of Java has thrived the JDK. The Java Development Kit(JDK ) is a Sun Microsystems product aimed at programming language developers. Since the introduction of Java, it has been by far the most widely used Java Software development kit. On November 17 2006, Sun announced that it would be released under the GNU General Public License (GPL), thus making it Free software. This happened in large part on May 8 2007 and the source code was contributed to the Open JDK. The primary components of the JDK are a selection of programming tools, including: java The Loader for Java applications. This tool is an interpreter and can interpret the class files generated by the javac compiler. Now a single launcher is used for b o t h development and deployment. The old deployment launcher, jre, is no longer provided with Sun JDK. Javac The Compiler, which converts source code into byte code jar The archive, which packages related class computer class into a single file format. This tool also helps manage JAR files. Javadoc The documentation generator, which automatically generates documentation from source code comments jdb The debugger javap The class file disassembler

3.2.3 Hardware Requirement:

HARDWARE REQUIREMENT PROCESSOR RAM : : Pentium IV & Above. 1 GB & Above. 40 GB & above.

HARD DISC SPACE :

PRINTER MONITOR

: :

Dot Matrix / Ink Jet Color

SOFTWARE REQUIRMENT:

OPERATING SYSTEM
Eclipse- 2008

: 2000 / XP/Vista. And all above (but Must be MicrosoftOs

Software Life Cycle Model:

In order to make this Project we are going to use Classic LIFE CYCLE MODEL .Classic life cycle model is also known as WATER FALL MODEL. The life cycle model demands a Systematic sequential approach to software development that begins at the system level and progress through analysis design coding, testing and maintenance.

The Classic Life Cycle Model

The waterfall model is sequential software development process, in which progress is seen as flowing steadily downwards (like a waterfall) through the phases of conception initiation, Analysis, Design (validation), construction. Testing and maintained.
1)

System Engineering and Analysis:-

Because software is always a part of larger system work. Begins by establishing requirement for all system elements and Then allocating some subset of these requirement to the software system Engineering and analysis encompasses the requirement gathering at the system level with a small amount of top level design and analysis.

2)

Software requirement Analysis: =

The requirement gathering process is intensified and focused specifically on the software .Requirement for the both system and software are discussed and reviewed with the customer. The customer specifies the entire requirement or the software and the function to be performed by the software.
3)

Design:

Software design is actually a multi-step process that focuses on distinct attributes of the program data structure, software architecture, procedural detail and interface of the software that can be assessed or quality before coding begins .Like requirement the design is documented and becomes part of the software.
4)

Coding:

The design must be translated into a machine readable form. The coding step performs this task. If design is programmed in a detailed manner, coding can be accomplished mechanically.

5)

Testing:

Once code has been generated programmed testing begins. The testing process focuses on the internals of the software ensuring that all statement have been tested and on the functional externals hat is conducting tests to uncover the errors and ensure that defined input will produce the results that agree with the required results.

Unit testing:In computer programming, Unit testing is software Verification and validation method where the programmer gains confidence that individual units of source code are fit to use A unit is the smallest testable part of an application. In procedural programming a unit may be an individual programmed, function, procedure, etc. while in object-oriented programming, the smallest Unit is a class, which may belong to a base/super class abstract class or derived/child class. Benefits: The goal of unit testing is to isolate each part of the program and show that the individual parts are correct. A unit test provides a strict written contract that the piece of code must satisfy. Documentation:Unit testing provides a sort of living documentation of the system. Developers looking to learn what functionality is provided by a unit and how to use it can look at the tests to gain a basic understanding of the unit API.

Limitation of unit testing:

Testing cannot be expected to catch error in the program It is impossible to evaluate all execution paths for all but the most trivial programs. The same is true for unit testing. Additionally, by unit testing only types the functionality if the units themselves. 6) Maintenance: Software will undoubtedly undergo change after it is Delivered to the customer .Change will occur because errors have been encountered because the software must be able adopted to accommodate changes in its external environment because the customer requires functional or performance enhancement enhancements. The classic life cycle is the oldest and most widely used paradigm or software engineering

Conclusion:

Using this project Online Shopping and Selling, it reduces the manual work of submitting the infrastructure related complains.

Now, it can be done using this software and hence, it makes the Customers Shopping easier and comfortable. he Logical Structure of the data to be stored in the Online Journal database on the server is as follows:

Published Article Entity 3.3.2 Security

The server on which the Online Journal resides will have its own security to prevent unauthorized write/delete access. There is no restriction on read access. The use of email by an Author or Reviewer is on the client systems and thus is external to the system. The PC on which the Article Manager resides will have its own security. Only the Editor will have physical access to the machine and the program on it. There is no special protection built into this system other than to provide the editor with write access to the Online Journal to publish an article

Use Case:-

Search Products

View Product

View Review

Write Review

User

Add to Cart

Edit Cart

Sell old Product

Add to Old product section

ER Diagram:

Browse Category View Current Order Status Buy Old Product

Add /Remove Item from Shopping Cart

View Access Data

Login Review Customer

Checkout/Payments Add/View Product Entry Sell Old Products

Browse Category Visitor

Visit The Site

New Account Creation

Delete Review LogIn

Manage Customer Database

Approve/Reject Shop Creation Request

Add/Remove Categories Item

View/Delete Product Entries

Administrator

DFD :
LEVEL 0 DFD

Home

Item List

LEVEL 1 DFD

New User

Home

Item List

Existing User

LEVEL 2 DFD

Registration Form New User

Home

User

DataBase Login Page

Item List

LEVEL 3 DFD

Electronics

Bilke Home Item List Add To Cart Clothes

Jewellery

LEVEL 4 DFD

Modify

View Cart

Home

Item List

Add To Cart

Bill

Credit Card

LEVEL 5 DFD

Credit Card

DataBase

LEVEL 6 DFD

New User

Home

Item

Review

Existing User