K.J.SOMAIYA COLLEGE OF ENGINEERING

VIDYAVIHAR , MUMBAI – 400 077

Department of Computer Engineering

Subject : Object Oriented Software Engineering

Term: odd(2010-2011) Class / Sem : T.E Comp / VI

List of Experiments

Sr no.Exp Title of the Title of the Experiment

1 Requirement Analysis for Mini Project.

2 Feasibility Analysis for Mini project.

3

Requirement and Design Modeling.

Use case Diagram

Activity Diagram

Sequence Diagram

Collaboration Diagram

State chart Diagram

Class Diagram

4 Design Document for Mini Project.

5 Project Plan Document for Mini project.

6 Testing plan for Mini Project.

7

Deployment Document for Mini Project.

Component Diagram

Deployment Diagram

Experiment No :1

Aim: To Prepare Requirement Specification Document

Document:

Introduction

1.1 Purpose READER’S HUT is a library, which provides reading services to its members. This library provides

following facilities to the readers: Granting and renewal of membership. Issue and return of books. Purchase and Updation of books.

While providing the above facilities, the following drawbacks are encountered: Issuing more than 1 book to a member Issuing a book to a member whose membership has expired. Physically searching for required book. Time consuming process.

An online system is to be designed which would overcome drawbacks.

1.2 Scope

The online system to be designed should perform following major functions: Acquisition of books. Membership maintenance. Book issue. Book return. Renewal of membership. Answer management queries.

1.3 Definition and acronyms

TCP/IP: Protocols used for connection.Module: A part of the system which performs a definite task.Server: A part of the client server model. Has higher processing capacity and servicesrequests made by clientClient: A part of the client server model. Requests services from the server.

1.4 References http://www.howstuffworks.com/tcp-ipconnections/1.html

5. Overall Description

2.2 Product Perspective The library management system allows the librarian to perform the tasks of issuing, returning books,

and other tasks related to membership maintenance with an easy to use interface.

2.1.1. System InterfacesThe system consists of four modules namely, admin module, client module, server module and the

database module.The server module is a server that accepts connection from the admin module and the client module

and interfaces them both with the database.

2.1.2. User InterfacesThe Admin module and the client module must provide a user interface to the user. The server module

and the database do not have a user interface.

2.1.3. Hardware InterfacesAll components must be able to execute on a personal computer.

2.1.4. Software InterfacesThe admin module and the client module must be java applets running within internet explorer 5(or

higher) or Firefox.The server module must integrate with the DBMS using JDBC. The web server must run within a

server available for Windows NT.

2.1.5. Communication InterfacesThe admin module and the client module must communicate with the server module using TCP/IP

connections.The server and the database components must be located on the same host.

2.1.6. Memory constraintsThe admin module and the client module must be able to run within 64MB. The server module must be

able to run along with the database within 256 MB.

2.1.7. OperationsThe operations of the client module and the admin module must be easy and intuitive to the users. No

specific knowledge must be required to operate the same. The server module must be installed and maintained with no interaction with the existing software on the machine.

Back up operations must be defined.Recovery operations must be specified in terms of user machine failures or database failures.

2.1.8. Site adaptation requirements

2.1.8.1 Website requirementFor online reservation of books, application for membership, renewal of membership etc a website

will be required. This website requires purchase of web space.

2.2 Product functionsThe main functions of the library management system are to allow for membership maintenance,

acquisition of books, issuing and returning of books and generating reports.

A member has a unique identification number called the membership number. Membership has an associated expiry date, which is used for notification to users and to the librarian. It also maintains the amount of fine that is collected in the membership period.

The acquisition of books requires assignment of a unique acquisition number for each acquired book and other details such as price, author name etc, which are used for report generation purposes.

The issuing of book requires the verification of membership details and books are issued if the member has a valid membership and has not already issued a book which is not returned yet.

While returning a book, the due date of the book is checked and if necessary fine calculations are done and the database us updated accordingly.

Various reports generated are: List of overdue books. List of memberships expiring in the current month. List of books present in the library. List of members.

2.3 User characteristicsThe users are untrained or have basic knowledge of computer functionalities. Theusers do not have knowledge of software engineering and do not understand the underlying

functions of the system.

2.4 ConstraintsThe system should enforce authentication and guarantee validity and integrity of the database.

2.5 Assumptions and dependenciesNo specific assumptions or dependencies.

6. Specific Requirement

3.6 External interface requirement

3.1.1 User InterfaceLogin screen: The login screen consists of user id and password fields and submit and cancel buttons.

Acquisition entry screen: This screen consists of fields like book name, author, price, acquisition number, publisher name, number of pages, date of publish, date of purchase and book status.

Application form: The form consists of Name, address, membership fee and caution money.

Admin screen: The admin screen consists of fields to update or add new data to the database. It consists of fields for updating book status, membership details, generating invoices and report generation.

3.7 Software product features

3.2.1 Membership managementValidity check is performed whenever a membership application is received.The librarian can modify the details of membership like the amount of fine collected etc.

Any errors occurring are reported.

3.2.2 Book managementFor acquisition of books as well as issue and return of books, validity check is performed.Members are allowed to reserve a book for issue. The librarian has to update the book status when

it is returned by the member.Any errors occurring are reported.

3.2.3 Staff accounts managementThe staff accounts consist of staff details and their respective login details. These details are used

while login of staff members. These details can be updated by the librarian.Any errors occurring are reported.

3.2.4 Invoice generation managementWhile generating invoices validity checks are performed to verify the quantity and name of books to

be bought.The librarian has to handle the generation of invoices. Any errors

occurring are reported.

3.2.5 Report generation

3.2.5.1 Overdue Books It consists of following format:

S.No. ACCE TITLE PRICE PUBLI MEMB MEMB MEMB BOOK PROPSSION OF OF SHER ERSHI ER ER ISSUE OSEDNUMB BOOK BOOK NAME P NAME ADDR D ON DATEER NUMB ESS OF

ER RETURN

3.2.5.2 Memberships expiring in the current month It consists of following format: S.No. MEMBERSHIP NAME ADDRESS MEMBERSHIP MEMBERSHIP

NO. BEGINNING EXPIRE DATEDATE

3.2.5.3 List of books present in the library It consists of following format:

S.No. ACQ ACCE BOO AUTH AUTH PUBL PRICUISITI SSIO K OR-I OR-II ISHE EON N TITLE NAM NAM RNUM NUM E E NAMBER BER E

NO. DATE DATEOF OF OFPAGE PUBL PURCS ISH HASE

3.2.5.4 List of members It consists of following format: S.No. MEMBE NAME ADDRE DATE DATE MEMBE CAUTIO CUMULRSHIP SS OF OF RSHIP N ATIVENO. MEMBE MEMBE FEE MONEY FINE

RSHIP RSHIP COLLE

BEGINS EXPIRY CTED

3.8 Performance requirementOur system will be scalable enough to handle the concurrent users accessing through web. We will be

maintaining the resource pools in our system for e.g. connection pools, object pools to achieve scalability. However the response time to various users will vary depending upon the kind and amount of information retrieved.

3.9 Software system attributesMaintainability: The system is to be developed using modular approach, hence it any errors in a

particular module can be easily identified and corrected without any effect on other modules.

Portability: The system is to be developed using java (platform independent tools), hence the system will be portable.

Recoverability: Recovery steps have to be defined in case of system or database failures. For database log based recovery is used.

Security: The system provides password based security.

3.10 Logical database requirementsThe database is required to store all the information about the books in the library, aswell as details about all the members of the library. The database also stores the details of the staff in

the library. It is also required to store the login details of the members as well as the staff of the library.

3.11 Other requirementsNo other specific requirements.

Roll no Signature of Faculty with date

Experiment No :2

Aim : To Perform Feasibility Analysis .

Theory:

Feasibility Analysis:

No project should be undertaken without detailed cost estimates and scope controls.  Even if a project is already underway, feasibility analysis can determine likely outcomes well ahead of time.  The following is a brief outline of the feasibility process.

Constraints:

There are four constraints to project success:

1. Cost :The cost incurred in developing this project include the cost of software developers,the system (computers required) and the softwares required.

2. Quality :The developers working on the project are highly skilled .

3. Time :The time taken for the project development is 6 months.

4. Scope: The online system to be designed should perform following major functions:

Acquisition of books. Membership maintenance. Book issue. Book return. Renewal of membership. Answer management queries.

Cost-Effectiveness:

Cost-effectiveness analysis can include the following:

Estimated direct costs:The direct cost includes cost of the softwares required and software developers.

Indirect costs: The indirect cost includes training provided to the end user.

Risk Analysis:

Project success depends on meeting the following requirements:

The software developers working on this project are highly skilled and have good experience on current platform being used.

The project is developed using agile project management methodology. Strong project management procedures Contingency plans are developed in case of system failure .

Complexity Analysis:

The complexity of the task assigned to the developers depends upon the experience and job knowledge of developer.

Requirements Definition :

A Requirements Definition gives the rationale, goals and description of a system. It is both a roadmap for the project and criteria for assessing completion. Thus the following task are performed during the project development :

Assess existing operations: Review systems, interview users, discuss options with management.

Review constraints: budget, time, personnel and technical. Evaluate strengths and enabling conditions.

Project Success :

Software projects are inherently risky.  Ethical approaches combined with good management mitigates those risks.

System requirements are discussed with the customer time to time.

The projects is feasible for given budget, time, personnel and technical constraints. The projects include all the factors critical for success: the right goals, the right staff, the

right vendors, the right work breakdown, the right budget and the right schedule.

Conclusion:Thus, feasibility analysis is performrd for the project .

Roll no Signature of Faculty with date

Experiment No :3

Aim : To Model the requirements using UWE approach.

Theory:

Requirement Modeling:

It is displayed using USE case diagram and activity Diagram.

Use cases It represents the functions of a system from the users point of view.

Use Case Diagram :

Use Case for Administrator:

Use Case for Librarian:

Use Case for member:

Use Case for clerk:

Use Case for helper:

Acivity Diagram

In its basic form, an activity diagram is a simple and intuitive illustration of what happens in a

workflow, what activities can be done in parallel, and whether there are alternative paths

through the workflow. Activity diagrams as defined in the Unified Modeling Language are

derived from various techniques to visually illustrate workflows. Activity diagrams are used

to visualize the workflow of a business use case. A complete workflow description will have

a basic flow, and one or several alternative flows. This workflow has a structure that we can

define textually, using informal if, if-then-else, or does-until statements of various kinds. For

a simple workflow with a simple structure such textual definitions may be quite sufficient,

but in the case of more complex structures, activity diagrams help to clarify and make more

apparent what the workflow is. Historically, activity diagramming techniques have mostly

been used in the business process modeling domain, but this article will also briefly discuss

how you can use it in the system modeling domain.

Basic Activity Diagram Notation:

As common for most notations, the activity diagram notation has some elements that are

necessary for you to understand if you want to be “conversant” about activity diagrams. A

basic activity diagram can have the following element:

Activity states, which represent the performance of a step within the workflow.

Transitions that show what activity state follows after another. This type of transition is

sometimes referred to as a completion transition, since it differs from a transition in that it

does not require an explicit trigger event, it is triggered by the completion of the activity the

activity state represents.

Decisions for which a set of guard conditions are defined. These guard conditions control

which transition of a set of alternative transitions that follows once the activity has been

completed. You may also use the decision icon to show where the threads merge again.

Decisions and guard conditions allow you to show alternative threads in the workflow of a

business use case.

Synchronozation Bars ,which you can use to show parallel subflows .Synchronization bars

allow you to show concurrent threads in the workflow of a business use case.

Activity Diagram:

Activity Diagram for librarian:

Activity Diagram for clerk:

Sequence Diagram: UML defines two types of interaction Diagrams :the Sequence Diagram and the collaboration

diagram. Sequence Diagram shows essentially the same information,but concentrates on the time-

ordered communication between objects rather than their relationships.The dashed vertical lines represent the lifeline io the object.

Sequence Diagram :Sequence Diagram for book return:

.

Sequence Diagram for Issue book :

Collabrotion Diagrams: In collaboration diagrams,objects are drawn as rectangles and the lines between them

indicates links. A link is an instance of an association.The order of the messages along the links

between the objects is indicated by the number at the head of the message. Collabration Diagrams are spatial representation of objects,links,interactions.

Collabration Diagram:

Collabration Diagram:

Content Modeling:Content modeling is done using Class Diagram and state diagram.

Class Diagram:

Class diagrams are the most popular UML diagrams used by the object oriented community. It describes the objects in a system and their relationships. Class diagram consists of attributes and functions.

A single class diagram describes a specific aspect of the system and the collection of class diagrams represents the whole system. Basically the class diagram represents the static view of a system.

Class diagrams are the only UML diagrams which can be mapped directly with object oriented languages. So it is widely used by the developer community

Class Diagram :

Statechart diagram

Represents the behavior of a class in terms of states at run time.

Statechart diagram define different states of an object during its lifetime. And these states are changed by events. So Statechart diagrams are useful to model reactive systems. Reactive systems can be defined as a system that responds to external or internal events.

Statechart diagram describes the flow of control from one state to another state. States are defined as a condition in which an object exists and it changes when some event is triggered. So the most important purpose of Statechart diagram is to model life time of an object from creation to termination.

State Diagram :

State Chart Diagram for book:

Roll no Signature of Faculty with date

Experiment No :4

Aim : To Prepare Software Design Description Document

Document:

a. Purpose

READER’S HUT is a library, which provides reading services to its members. This library provides following facilities to the readers:

Granting and renewal of membership. Issue and return of books. Purchase and Updation of books.

While providing the above facilities, the following drawbacks are encountered: Issuing more than 1 book to a member Issuing a book to a member whose membership has expired. Physically searching for required book. Time consuming process.

An online system is to be designed which would overcome drawbacks.

b. Scope

The online system to be designed should perform following major functions: Acquisition of books. Membership maintenance. Book issue. Book return. Renewal of membership. Answer management queries.

c. Definitions and Acronyms

TCP/IP: Protocols used for connection.

Module: A part of the system which performs a definite task.

Server: A part of the client server model. Has higher processing capacity services

requests made by client

Client: A part of the client server model. Requests services from the server.

Referenceshttp://www.howstuffworks.com/tcp-ipconnections/1.html

9Decomposition Descriptiona. Module Description

i. Admin Module Description

The admin module allows the user (Librarian) to make changes to the database. It allows him/her the generation of various reports and invoices. It also allows him/her to manage membership accounts.

ii. Client Module Description:

The client module allows the members to login and query the database for available books and for membership details.

It allows for requesting of books.It also provides interface for membership application and renewal.

iii. Server Module Description

The server module interfaces with the database and allows the admin and client module to query information from the database.

All the database operations are performed by the Server module.The client and admin module interface with the server module using TCP/IP connections.

b. Concurrent Process Description i. Admin process description

Admin process starts whenever the Librarian logs in. This process then connects to the Server process and maintains the connection till the librarian logs out. It passes the queries to the server module over the connection.

ii. Client process description

The client process starts whenever any member logs in. This process then connects with the Server Process and maintains the connection till the member logs out. Queries are passed by this process to the Server process over the connection.

iii. Server process description

The Server process is always active, regardless of whether any user has logged in or not. This process accepts connections from the admin and client process and replies with the result set for the queries. It interfaces with the database using JDBC connections.

c. Data Description i. Member

Member entity stores the information about the members of the Library. It is required for validating member information while issuing books and it is updated every time books are issued, returned or fine is to be calculated.

ii. Books

The Book entity stores the information of the books in the library. A new record is created whenever new books are acquired. Book status is updated every time books are issued or returned.

iii. Issuance

Issuance entity stores the records of books issued to members. These records are used for calculating fine for delayed returns and to keep a track of books that are issued.

10. Dependency Description a. Inter-Module Dependency

The Admin and Client modules require connecting to the Server module using TCP/IP connections and all the transactions are made using these two modules.

b. Inter-Process Dependency

The Client and Admin processes send queries to the Server process. These queries are then passed on to the Database management system by the Server process using the JDBC connection.

c. Data Dependency

The Issuance records require member id from the member records and acquisition number from the book records. These are necessary to maintain information for issuing books and for calculating fines for members.

11. Interface Description a. Module Interface

i. Admin Module Interface

The admin module interfaces with the server module using the TCP/IP connection. It also provides a user interface for the librarian to manage member accounts as well as for managing the book details.

ii. Client Module Interface

The client module interfaces with the server module using the TCP/IP connections. It also provides a user interface for the member to access membership details and also renew membership.

It also provides a user interface to unregistered members to apply for memberships.

iii. Server Module Interface

The server module interfaces to the client and admin modules through TCP/IP connections. It also interfaces with the database using JDBC.

It does not provide a user interface.It also provides a web server component.

b. Process Interface i. Client Process Interface

The client process interfaces with the server process. The client process requires identification information for connecting to the server process.

ii. Admin Process Interface:

The admin process interfaces with the server process. The client process requires identification information for connecting to the server process. The admin process has higher priority over the

client process when it comes to connect to the server.

iii. Server Process Interface

The Server process interfaces with the client and admin process after validating the identification information from the connecting process. The server process also interfaces with the database using JDBC.

12. Detailed Design a. Module Detailed Design i. Admin Module Design

The admin module has following components: Book management

o Updation of book status. o Adding of new books. o Removal of older and damaged books. Membership management o Fine calculation. o Adding new member.o Deleting expired membership records.o Renewing membership Report generation Invoice generation ii. Client Module Design

The client module has the following components: Book search. Membership access. Book reservation.

iv. Server Module Design The server module is designed to provide connectivity to the database. It has the following

components: Database interface Interface for connecting with the admin and client module. The server module is

required to remain active always. The server module has also a web server component that handles the TCP/IP connections and

also provides server side validation.

c. Data Detailed Design i. Members

Attribute name Type Size

3.1.1 Membership ID String 103.1.2 Name String 503.1.3 Address String 1003.1.4 Registration date Date 103.1.5 Fee Float 103.1.6 Caution money Float 103.1.7 Membership expiry Date 10

date3.1.8 Renewal amount Float 153.1.9 Password String 20

ii. Books

Attribute name Type Size3.2.1 Acquisition No. String 103.2.2 Accession No. String 103.2.3 Title String 303.2.4 Author 1 String 253.2.5 Author 2 String 253.2.6 Publisher String 253.2.7 Price Float 153.2.8 No. Of Pages Integer 303.2.9 Date of publication Date 103.2.10 Date of purchase Date 10

iii. Issuance

Attribute name Type Size3.3.1 Member ID String 103.3.2 Accession No. String 103.3.3 Date of Issue Date 103.3.4 Date of Return Date 103.3.5 Calculated Fine Float 15

Roll no Signature of Faculty with date

Experiment No : 5

Aim: To Prepare Software Project Management Plan

1.1 Project overview:The purpose of the software is to make the library systematic, easy to access and userfriendly.

1.2 Project deliverables:

1. SRS 2. Software project management plan 3. Software design document(data design, architectural design, interface design and procedural

design) 4. Software testing documents(test plan, test cases ) 5. User manuals

2. Project Organization:

2.1 Software Process Model:

WATERFALL MODEL:

Planning Analysis

Design

Implementation Testing

Coding

2.2 Roles and Responsibilities:

In order to complete the project successfully, the various tasks are assigned amongst the group members according to there ability. Each member should perform the given task efficiently. The members should give proper design for the code, based on which the functions have to be performed:

Following table shows the roles and responsibilities of the each member:

ROLES NAME RESPONSIBILITIES

Team Leader Kavita Kelkar Design generation

Requirement

gathering

Project Analyzer Prafull Bhosale Analysis Evaluation of codes

Project Manager Yogesh Jadhav Integration andtesting modules

Management ofdatabase

Project Advisors Rahul Bansode Coordinating Development of

user interfacemodule

2.3 Tools and Techniques:

System requirements:

Operating systems: Windows 9x/2000/xpHardware: RAM-256 MB or above Any Intel Processor of 1.0 GHz or above Barcode reader Hub

Front end: ASP.NETBack end: MS SQL SERVER

3. Project management plan:

3.1 Tasks:

Sr. Task Description Deliverables Resources Dependencies Risks andNo. and Needed and Contingencies

Milestones Constraints3.1.1 Interacting Get Prepare Developer Coding cannot Fixing of

with the requirement analysis manuals be started appointmentclient specifications report

3.1.2 Development Develop the Actual VS.NET Version of Availability ofactual development and SQL software software v/sapplication of project Server waiting for it

3.1.3 Testing Execute and Validating Code Getting right Availability ofcheck the the code inputs for knowledgeable

table for testingproject respective

modules

3.2 Assignments:ROLES NAME RESPONSIBILITIES

Team Leader Kavita Kelkar Design generation

Requirement

gathering

Project Analyzer Prafull Bhosale Analysis Evaluation of codes

Project Manager Yogesh Jadhav Integration and testing modules

Management ofdatabase

Project Advisors Rahul Bansode Coordinating Development of

user interfacemodule

3.3 Timetable:

Tasks Description Days allotted Start date End date

Requirement Collection of 15 Jul 2008 Jul 2008gathering information and

analysisof variousbooks

Designing Front-end using 15 Jul 2008 Jul 2008ASP.NET andback-end usingMS SQL Server

Coding Managing 45 Aug 2008 Sept 2008library systemusing .NET

Testing Testing various 30 Sept 2008 Oct 2008modules

Documentation Generating 15 Oct 2008 Oct 2008different reportsas per

requirements.

Roll no Signature of Faculty with date

Experiment No :6

Aim : To prepare SYSTEM TEST DOCUMENT

Test Approaches:

White box testingUsing white-box testing methods, the software engineer can derive test cases that do all of the

following:5. Exercise all independent paths within the module at least once.

6. Exercise all logical decisions for both true and false scenarios.

7. Execute all loops at their boundaries and within their operational loops

8. Exercise all internal data structures to ensure their validity.

Black box testing

Black box testing attempts to find errors in the following categories:

6. Incorrect or missing functions

7. Interface errors

8. Errors in data structures or external database access

9. Performance errors

10. Initialization and termination errors

Unit testing

Unit testing focuses verification effort on the smallest unit of software design – the software module.

Using the component level design description as a guide, important control paths are tested to

uncover errors within the boundary of the module. The unit test is white box oriented, and the steps

can be conducted in parallel for multiple modules.

Integration testing

Interfacing of various modules can cause problems. Data can be lost across an interface, one module may affect the other, and individually acceptable imprecision may be magnified when combined.Integration testing is a systematic technique for constructing the program structure while at the same time conducting tests to uncover errors associated with interfacing. The objective is to take unit tested components and build a program structure that has been dictated by design.

Stress testing

During earlier testing steps, white box and black box techniques result in a thorough evaluation of

normal program functions and performance. Stress tests are designed to confront programs with

abnormal situations. Stress testing executes a system in a manner that demands resources in

abnormal quantity, frequency or volume. Essentially, the tester attempts to break the program.

Performance testing

Software that performs the required functions but does not conform to performance requirements is

unacceptable. Performance testing is designed to test run-time performance of software within the

context of an integrated system. Performance testing occurs through all the steps in the

testing process. However, it is not until all system elements are fully integrated that the

true performance of a system can be ascertained.

Security testing

Any computer-based system that manages sensitive information or causes actions that

can harm individuals is a target for improper or illegal penetration. Security testing

attempts to verify that protection mechanisms built into a system will, in fact, protect it from

improper penetration. During security testing, the tester plays the role of the hacker who

desires to penetrate the system. Given enough time and resources, good security testing

will ultimately penetrate a system. The role of the system designer is to make penetration

cost more than the value of the information that will be obtained.

Recovery testing

Many computer-based systems must recover from faults and resume processing within a

pre-specified time. In some cases, a system must be fault-tolerant, i.e. processing faults

must not cause overall system function to cease. In other cases, a system failure must be

corrected within a specified period of time or severe economic damage will occur.

Recovery testing is a system test that forces the software to fail in a variety of ways and

verifies that recovery is properly performed. If recovery is automatic, re-initialization,

check-pointing mechanisms, data recovery and restart are evaluated for correctness. If

recovery requires human intervention, the mean-time-to-repair (MTTR) is evaluated to

determine whether it is within acceptable limits.

Test Plan:

It is a document consisting of different test cases designed for different testing objects and different testing attributes. The plan puts the test in sequential order as per the strategies

chosen that is, top down and bottom up. The test plan is matrix of test cases listed in order of its execution.Test Plan is developed to detect and identify potential problems before delivering the Software to its users.The scope of test will be limited just to the boundaries as the white box testing cannot be in detail.

Steps in delivering a Test Plan:

1. Prepare a Test Plan:

Identify members from quality assurance department, users and development to cover testing in full extent.

2. Define Objectives of Testing:

Define objectives of testing and describe how to achieve them. Define which type of testing is to be done and how will we be doing that. Define some testing milestones. Prepare detailed test plan considering milestones.

3. Development of a Test Plan:Develop test data, input, event or transaction and expected output for each test under consideration.

4. Perform Test Analysis:After preparing test cases perform testing and examine test output and document the result. The report will contain list with class, type and severity of defect.

Test Cases:

Type of testing

Item to be Input Expected Actual Output

tested Output

1.Login form Username: Welcome Welcome

admin

password:

******

Username: Re-enter Re-enter

_12admin username username

password: Password Password

* invalid. invalid.

Unit testing

2.Renewal form Member Accept ID Accept ID

ID:RH123

Member Invalid ID Invalid ID

ID:SS1213 Re-enter the ID Re-enter the ID

3.Application Name: ABC Accept Accept

form

Name: _____ Error. Name field Error. Name field

can’tb

left can’tb

left

blank. blank.

Integration 1. Connectivity Click on Page under Page under

testing hyperlink construction construction

Click on New page opens New page opens

hyperlink

2. Querying Post query Triggers an Triggers an

event event

Post query Data not found Data not found1.login failure Backup system Backup system

at work at work

System testing Data lost Data lost2. Security Unauthorized Unauthorized

access accessWelcome WelcomeMr.Administrator Mr.Administrator

Critical Credit card no Credit card Credit card

Beta testingapplications accepted accepted

Expired Credit Credit card Credit cardcard no rejected. rejected.

Alpha testingPassword Password entry Password Passwordencryption accepted safely accepted safely

Experiment No :7

Aim : To prepare Deployment Document.

Theory:Deployment Plan is a ‘how-to’ guide to implement a solution into a live production environment.

It provides detailed deployment guidelines and helps drive the deployment phases.

Deployment Planning :

Careful planning ensures that the system is installed smoothly, on schedule, without any significant problems, and to the complete satisfaction of the customer. Specific objectives are to complete the plans for:

  contingencies to cover for unexpected problems, software deployment, deployment and warranty support services. 

Environment Set-Up: The system is designed to run over the Internet and viewed through

browsers such as Netscape or MS Internet Explorer (MSIE). The software is to be created primarily by the use of Java Servlets and other Java components (Beans, JSPs . . . ). This system can be upgraded easily to support internet accessibility.

As with any internet program, a web server is needed. Although we could have used the free Apache web server with JRun as the Java Virtual Machine, we prefer to use IBM’s Java Web Server because of its simplicity. The servlets reside on the Web server. It is the web server that takes the majority of traffic,

We will transfer the existing Customer database and Product/Service database to Oracle 8i. In addition to the existing databases, the new data storage area for invoice transactions will be on Oracle. Oracle and the Web server are directly connected via a gigabit Ethernet.

The user need to be connected to the network. we suggest using a hub-based network. All the client computers are connected to the hub, which is in tern connected to the web server.

Installation and Configuration : Windows operating system. Web browser Netscape or IE. Oracle 8i. Configuring web server.

Rollout to End-Users :This module helps facilitates traning to end users .

Customization Modeling :

Component diagram.

Component diagrams document physical elements. Components are wired together by using an assembly connector to connect the required interface of one component with the provided interface of another component. This illustrates the service consumer - service provider relationship between the two components.

An assembly connector is a "connector between two components that defines that one component provides the services that another component requires. An assembly connector is a connector that is defined from a required interface or port to a provided interface or port."

When using a component diagram to show the internal structure of a component, the provided and required interfaces of the encompassing component can delegate to the corresponding interfaces of the contained components.

A delegation connector is a "connector that links the external contract of a component (as specified by its ports) to the internal realization of that behavior by the component’s parts."

Components diagrams can be used to illustrate the structure of arbitrarily complex systems. The following example illustrates what a typical Insurance policy administration system might look like:

It is possible to envisage that each of the components depicted in the above diagram will, in turn, have other component diagrams illustrating their internal structure.

Component Diagram:

Deployment Diagram:Deployment Diagram documents hardware elements .Deployment diagram in the UML serves

to model the physical deployment of artifacts on deployment targets .

Deployment Diagrams show “the location of artifacts to nodes according to the deployments defined between them.

Deployment of an artifacts to a node is indicated by placing the artifact inside the node.

Instances of nodes are used in deployment diagram to indicate multiplicity of this node.

Deployment Diagram:

Roll no Signature of Faculty with date