CONTENTS

Pg.No
1. COMPANY PROFILE 2. ABSTRACT 3. INTRODUCTION 3.1. 3.2. 3.3. 3.4. 3.5. About the Project Project Overview Project Scope Screen Design/Graphical User Interface General Description

4. SYSTEM ANALYSIS 4.1. 4.2. 4.3. 4.4. Need for the System Proposed System Performing the Feasibility study Software Requirements Specification

5. System Development Environment 5.1. 5.2. 5.3. 5.4. 5.5. 5.6. 5.7. 5.8. Java Coding Standards An Overview of J2EE J2EE Architecture Exploded Directory Format Graphical User Interface An Overview of JSP An Overview of Servlets An Overview of JDBC

6. System Design 6.1. 6.2. 6.3. 6.4. Data Dictionary Data Flow Diagrams ER Diagrams UML Diagrams Class Diagrams Use Case Diagrams Sequence Diagrams State Diagrams Activity Diagrams

6.4.1. 6.4.2. 6.4.3. 6.4.4. 6.4.5.

7. Input and Output Screens 8. Testing 8.1. 8.2. 8.3. 8.4. Unit Testing Integration Testing Validation Testing System Testing

9. Maintenance and Implementation 9.1. 9.2. 9.3. 10. 11. 12. Corrective Maintenance Adaptive Maintenance Preventive Maintenance

Conclusion Glossary Reference

1. COMPANY PROFILE
Opera Technologies is a leading global software solution company has its fullfledged offshore development and corporate training divisions in Hyderabad. Opera Technologies understand the need for qualified IT professionals has been spiraling over the last decade. For over a decade now India has been the obvious destination for enterprise seeking topnotch services and solutions. Opera Technologies has a broad spectrum of Fortune 500 clients hailing from medicine to communication, banking to manufacturing, services to R&D. to ensure that recruits skills and technical expertise remain relevant of all times, they are put through rigorous on the job, hands-on training in up-to-the-minute technologies ERP-SAP & Oracle, ABAP, Data warehousing, .NET, J2EE and all advanced technologies.

Opera professionals possess the best credentials in their individual fields of expertise and are continuously encouraged to upgrade their technical and motivational skills through in-house training programs. Coupled with the fact that our infrastructure is more state-of-the-art than most. Our innovative technologies are second to none, and our employee-friendly policies are designed exclusively to guarantee work satisfaction. We can confidently boast of attracting the finest talent in the industry. A high-powered activity graph, blended with top-of-the-line projects ensures that their excitement and commitment remain undeterred.

Abstract:
Team Space is a web based document management system. It supports its users by managing documents in most popular formats. Team Space aims to fulfill all phases of document lifecycle. You can create documents by using office software. With Team Space itself, you can publish, search, and manage the versions of documents. Further, you can communicate with some other users directly or via e-mail. To understand the use of Team Space, let us take a company that generates a lot of documents - protocols, reports, pictures and other one. One of the most time-consuming processes is to find a document containing the information you need. This is very easily done by Team Space software. It also supports its user by capturing, publishing, finding, and storing electronic documents. While the documents are stored it adds metainformations like title, author, keywords, and language. This will enable the search engines to find the information depending on these keywords or Meta information. Teams pace can organize documents by different criterias, so the user can have an idea where to look for when he/she is thinking of a document. Teams pace is a multiuser system and uses a database management system. Using TeamSpace we can handle documents created in MSOFFICE, .PDF format, HTML and XML files, pure text files, dBase files and WordPerfect files. TeamSpace has features to handle Users and Groups of people. It has a feature to search for any document with required text or feature. Backup of documents and Debugging of a document is also provided by this software.

Teams pace allows us to manage users and groups. It will be useful to maintain the logging data and backup data. It will allow us to create directories for each and every purpose. Using the features like Messages and Mails users can flexibly communicate with each other. The following functionality can be expected on any document by Teams pace : -Add documents via HTTP upload -Download of documents -Edit/Delete documents -Move documents -CheckIn/CheckOut of documents -Versioning -History -Export folder as zip -Import folder as zip

2. INTRODUCTION
2.1. PROJECT OVERVIEW
The revolutionary trends of computerization have reached the peaks achieving global goals in the field of document management system. The TeamSpace systems getting converted into software application is leading to a new and innovative way to approach to documents efficiently. With the major organizations hosting services of TeamSpace our product specifically aims to the total organizing all types in a proper manner at a secured central location. With the total conversion of TeamSpace web based document management system application, the manual dependency in maintaining and organizing the documents is minimized to a large extent. It inherits all the properties of Control Versioning System system that includes storing different versions of the document, sharing the documents, provides security for the document, download the document, managing the documents in a hierarchy passion, robustness, flexibility, reliability, scalability.

Todays trend demands high rate of automation for the Document management system in the organizations a re growing in exponential form and maintaining different documents and their versions in a consistent format. To satisfy the needs of clients, todays organization need more and more of workforce. The TeamSpace system takes care of this by taking different formats of the documents and maintain it at a central location.

2.2. PROJECT SCOPE

The project mainly focuses on maintaining different kinds of documents and their versions at a central location by providing some security. It can also manage the documents in a hierarchy passion by creating directories and storing the documents inside that. It supports all the document formats. It allows the users to share the document from different systems and then can discuss on this document by writing some articles on that document. User can see the original document which is stored at the server and he can edit that document and he save that document with different version number. It allows the user to download the document from the client. It provides a way for the users to maintain entire directory as it is in the document management system. This application also allows the user to communicate in different ways.

2.3. SCREEN DESIGN / GRAPHICAL USER INTERFACE

The system uses a very user-friendly interface developed using Hyper Text Markup Language (HTML), which most users are acquainted with and is broadly used on the World Wide Web (WWW). The controls are placed on the forms in an easily accessible manner so that user strain is minimized to the maximum extent. Whenever a user enters any form the system also states the action to be performed in an easily understandable and pleasant speech. The navigation of the user form one area of the system to another is very easy using easy to access and properly placed hyperlinks which user can access on the click of a button.

The system also poses a unique format for each type of employee; this ensures that employee is presented with options he has access to. This ensures a great deal of security to the system and to the organization as an employee is not given an option to carryout unauthorized activity.

2.4. General Description

The system has four major modules: Personal Module Administration Module Document Management Module Services Module

The welcome form of the project displays the options to login different types of persons. It has an option to select the language at the login time. Once the user is logged in it provides some facilities based on the user type. In the home page the user gets the help from to know how to use the application. It also provides different options to the user with user-friendly screens.

2.4.1. Personal Module

This is very useful module for the users to communicate each other very easily using TeamSpace application with in the company. It allows the user to create a message and send to another user in the company from Messages option in the personal Module. The recipient user can see the messages sent to him and he can open that content and can reply back to the sender. The sender can also set the confirmation for sending the message just like the acknowledgement. The user can delete the messages that are already seen. This application provides another facility for communication through mailing which is provided in this application. The user can create the email account by selecting

POP3 servers etc .The user can mails to another person outside the company also. using this option the user can also send attachments. The user enters into Inbox to see his mails or sent items option for visiting already sent mails. The user can create the mails using create mail option. The user can edit the user information and he can change or update his information. Change password option allows the user to change his password. The user can parameters for search option.

2.4.2. Administration Module

This module focuses on the basic features of the application. It allows you to manage the following : Users Groups Logging Search Engine Backup It allows the administator to create, update, edit the groups. He can create a group based on parent group. He can see the information of the group. Search facility is also provided to search for a group. The administrator can create the users and assign them to a group. He has the permission to edit and delete the users at any point of time from groups. He can see the information or search for a user same as the group. It allows the administrator to enable different logging facilities and setting parameters Core Logging The application stores the log statements which are common to all the users. Admin Logging The application stores the log statements which are specific to Administrator. Documan The application stores the log statements for the exceptions which are

raised recently. Actions - The applications stores the log statements the each and every action that The user is performing. Communication The application stores the log statements when the user is communicating another another through messages or mails. Search Engine The application stores the log statements when the user searches For a document using search engine option. Finally the administrator is responsible for enable the backup option and restoring the content.

2.4.3. Document Management Module

This module focuses on managing the documents of formats in proper manner at a Central location. It also provides security for accessing that document. Multiple user can access the same document at a time and they store the changes with different version of the same document. This avoids conflicts between the user in saving the changes to the document. It has the following options Create Folder Create Document Import Folder Folder actions File Actions Info History Whenever user logs into system he can create the folder, delete or edit the directories. He can also search for a folder. The user can also create, edit or delete the document also. He can create the document in a directory. Using directories the user can create the document in a hierarchical manner. The user can also search for a particular document. When the user is creating the document the system ask several parameters like Document Name, Version no, Sort no, Keywords, Coverage

document type and the description. The user can give any name for the document or else the TeamSpace will give the default name. Version no is to specify which version for the document it is. Later on the user can identify which document is the latest one basing on their version nos. The TeamSpace automatically sorts the documents bases on their names or else we can sort on our own basing on their sort nos of the document if the user assigns document nos to the document. The user can also search for a document based on the keywords. The coverage option gives the information of the document. The import folder option allows the user to import the directory as it is and maintain it inside TeamSpace system. The same hierarchy will continue in the application. It provides better security. Create Menu option is to create the menus or creating the directories. A menu in particular is a link which can refer to a normal website or an action. It has a name and optional an action (link) and a sorting number. If you have not specified the action the menu is used like a folder. The menu type international menu needs a entry in special language bundles. This feature is only for experts. Further you have to define the group having access to the menu. To add a new document you first have to upload the file. Furthermore, you must select the groups having read and write permissions. You also can fill in the other attributes. If you have not specified a document name the name file is used. It is possible to upload archives in the zip or jar format . You have to specify the start document if you will add an archive. The start document is the file in the archive which will be shown when you view this document (eg: index.html if the archive is a html homepage). In the folder view you can navigate by the documents in a hierarchical opinion. To add a document to current folder you have to click on create document icon. The author can set the permission for his directory. He can also export the directory as all levels as zip to copy the entire structure. He can also export the direcotory as Mind Map also. He can also see the information of the directory. In the folder document view, the document can be called edited , deleted, cut the documents. The user can download the documents and save it to the user system.

The user can also see the similar documents or different versions of the documents. He can send a document as an email or download ticket. The users can discuss on a document by creating articles on that. The user can maintain information about the document and the history of the document.

2.4.4. Services Module

This module focuses on creating or setting the following options: Directories Search Keywords Help Move Up and Reload

The Directories option allows the user to create doc dir , index dir and user dir. Doc dir allow the users of the TeamSpace system to store the documentation in the target Doc dir directory. Index dir allow the users of the TeamSpace system to store search indexes User dir allow the user of the TeamSpace system to store the user information in target User Dir direcotory. The search option allows the user base some xml files Sxcontent Kocontent

The move up and reload options allows the users to move to the upward page and reload the lastest changes. The keywords Management options allows the users to click on an alphabet and display the related document names.

This allows two types of users to login into TeamSpace system: 1.Administrator 2. Normal User Administrator can have following the options: 1.Administration options 2.Personal options 3.Document options 4.other options 5.Keywords option Whereas a normal can have the following options: 1.Personal options 2.Document options 3.Keywords options

3. SYSTEM ANALYSIS
3.1. Need of the system
Present day organizations, especially large companies house employees in large numbers. In order to maintain their design documents and other related documents to project development, which include customer reuiqrements, work force requirements and design details, the burden on document storage department is immense. The lack of consistency in document maintenance leads to both loss of work as well as reusability. With the total automation of Document Management System, the manual storage dependency is minimized to a large extent. It should inherit all the properties of control versioning system, which includes efficient management of documents with version numbers, less processing time, high security, fast recovery, robustness, flexibility, reliability, scalability

In addition to these characteristics the system should maintain data in consistent format all the while.

3.2. Proposed System

The proposed system should have the above features. The features of the system are, it maintains the client requirement documents, project documents, design documents architecture and also the UML diagrams of a new project. The system should also be easy to access, accurate and consistent results can be obtained in the form of documents whenever the user needs. The document management includes all the types of documents in different formats to be stored in a hierarchy passion at the central server. The system should be able to maintain the indexes and version nos to easily recognize the latest version of the document. The sort no of the documents allow the user to sort the document based on the sort no of the document. It also provides efficient way to communicate between the users.

3.3. FEASIBILITY STUDY REPORT

After analyzing the existing system, the organization is in need of automation of existing manual storage system. The organization has the capacity to stand the cost of developing new system and is willing to do that. The product will be of utmost use and the level of ease has been increased to a great extent.

3.4. SOFTWARE REQUIREMENT SPECIFICATION

1.Introduction
1.1 Purpose : The purpose of this project is to storage documents in a proper manner by providing security of an organization. 1.2 Document Conventions 1. All the main heading are in BOLD and underlined. 2. Error message will be denoted using a (!) prefix. 3. The steps in the document follow Software Development Lifecycle methodology. 1.3. Product Scope The scope of the project is limited to a single organization. 1.4.Reference Java Server Programming J2EE edition wrox. J2EE Complete reference -McGraw Hill. Oracle 8i-Oracle Press Java Servlet Programming Oreilly . Core Servlets and JSP from Sun Press Jakarta Struts Live from Apache

2.Overall Description
2.1. Product Perspective This project has been developed in replacement of existing manual document storage system. This project mainly focuses on automation and management of documents by providing high security. 2.2. Product Function The different functionalities provided by this module are as follows:

1. It maintains different types of documents. 2. Provides the security for the directories and documents. 3. Edit the document and share it across the team. 4. Discuss the document by creating articles on it. 5. Sending Messages from one user to another. 6. Upload and download documents. 2.3. User Classes and Characteristics The project may consist of user classes: 1. User class Maintains details of the users and his details. 2. Group class The class contains the groups of the organization. Each group has its own users and And its parent group details 3. Document This class contains the contents of a document and its document name, version no, sort no, keywords, coverage, version description and information about the document like whether the document is a archive file or normal file 4.Directory This class contains the information the contents in the directory, its sub directories, files, no of files in that directory, size, hierarchy information etc 5. Login class The class displays the login screen and after validates the login id with the password in the database. The class also checks the user details based on the users, groups which are stored in the database.

2.4. Operating Environment

Operating System Windows 2000server and professional Hardware platform Pentium 4 processor 256 MB RAM Software specifications Apache Tomcat 5.0.25 J2SDK 1.5 MySQL 4.1 Microsoft Front Page Express Internet Explorer

2.5. Design and Implementation Constraints

Coding standards for variables: Do not start or end variable names with underscores. Do not initialize variables in definition. Global variables should be initialized separately in a initialization routine. Initialize only one variable per statement and explicitly. Use prototyping for all the function. Argument should be listed one per a line. Return from only one place and function as for as possible. Watch out for functions that do not null terminate strings. Coding Standards for function:

2.5. Design and Implementation Constraints

Only authorized users should be able to access the system. Employees except HR should not be able to change the pay details of the pupil. The entire user interfaces need to be in HTML format.

2.6 User Documentation

A complete documentation depicting the functionality of the system should be provided with the system.

2.7 Assumptions and Dependencies

The values to calculate the deductions and allowances will be varying as per Government rules and regulations so the system should be able to change them as and when necessary. The project assumes that all the employees need to login and logout each day.

4.External Interface Requirements

1.User Interfaces
The interfaces between the user and system should be done using the HTML forms in Struts. The HTML fields are of the same font. The HTML forms have to be titled with the functionality of the form. The colors used should be uniform throughout the application.

2.Hardware Interfaces The system is being developed on Windows platform on a network and intended to work in a single organization. 3.Software Interfaces The application connects to the database using the jdbc type 3 drivers for MySQL. Tomcat provides these to the application. The project gets its inputs from the HTML forms which are processed by the struts. 4.Communication Interfaces The HTML forms communicate to the servlets using the HTTP 1.1 protocol. The data is being passed along in encrypted format.

Servlets communicate with database using a global name assigned using Tomcat JNDI service. The connections are maintained using the connection pooling objects.

4.System Features
It maintains different types of documents Sharing the documents by providing the security. Maintaining different versions of the document to avoid conflict. Provide intranet communication through messages. Provides intranet and internet communication through mails Upload and download the documents. Provides sorting option for documents. Discuss the documents and create the articles.

Other Non-Functional Requirements

1.Performance Requirements The system needs to be reliable. When the system is unable to process a particular request an appropriate error message should be generated. 2. Safety Requirements The details need to be maintained properly. When and employee leaves the organization his details need to be removed both in masters and dependent tables and the same employee id should not be assigned to any new employee. 2.1 Security Requirements The information passes between the html forms and the struts should be in encrypted format. The system should be accessible to authorized personnel only.

4. System development environment

Java coding standards
Why Coding Standards are Important Coding standards for Java are important because they lead to greater consistency within your code and the code of your teammates. Greater consistency leads to code that is easier to understand, which in turn means it is easier to develop and to maintain. This reduces the overall cost of the applications that you create. You have to remember that your Java code will exist for a long time, long after you have moved on to other projects. An important goal during development is to ensure that you can transition your work to another developer, or to another team of developers, so that they can continue to maintain and enhance your work without having to invest an unreasonable effort to understand your code. Code that is difficult to understand runs the risk of being scrapped and rewritten I wouldnt be proud of the fact that my code needed to be rewritten, would you? If everyone is doing their own thing then it makes it very difficult to share code between developers, raising the cost of development and maintenance. Inexperienced developers, and cowboys who do not know any better, will often fight having to follow standards. They claim they can code faster if they do it their own way. Pure hogwash. They might be able to get code out the door faster, but I doubt it. Cowboy programmers get hung up during testing when several difficult-to-find bugs crop up, and when their code needs to be enhanced it often leads to a major rewrite by them because theyre the only ones who understand their code. Is this the way that you want to operate? I certainly do not.

The Prime Directive No standard is perfect and no standard is applicable to all situations: sometimes you find yourself in a situation where one or more standards do not apply. This leads me to introduce what I consider to be the prime directive of standards: When you go against a standard, document it. All standards, except for this one, can be broken. If you do so, you must document why you broke the standard, the potential implications of breaking the standard, and any conditions that may/must occur before the standard can be applied to this situation. The bottom line is that you need to understand each standard, understand when to apply them, and just as importantly when not to apply them. Important Instructions to maintain standards Use full English descriptors that accurately describe the variable/field/class/ For example, use names like first Name, grandTotal, or CorporateCustomer. Although names like x1, y1, or fn are easy to type because theyre short, they do not provide any indication of what they represent and result in code that is difficult to understand, maintain, and enhance (Nagler, 1995; Ambler, 1998a). Use terminology applicable to the domain. If your users refer to their clients as customers, then use the term Customer for the class, not Client. Many developers will make the mistake of creating generic terms for concepts when perfectly good terms already exist in the industry/domain. Use mixed case to make names readable. You should use lower case letters in general, but capitalize the first letter of class names and interface names, as well as the first letter of any non-initial word (Kanerva, 1997). Use abbreviations sparingly, but if you do so then use them intelligently. This means you should maintain a list of standard short forms (abbreviations), you should

choose them wisely, and you should use them consistently. For example, if you want to use a short form for the word number, then choose one of nbr, no, or num, document which one you chose (it doesnt really matter which one), and use only that one. Avoid long names (< 15 characters is a good idea). Although the class name PhysicalOrVirtualProductOrService might seem to be a good class name at the time this name is simply too long and you should consider renaming it to something shorter, perhaps something like Offering (NPS, 1996). Avoid names that are similar or differ only in case. For example, the variable names persistentObject and persistentObjects should not be used together, nor should anSqlDatabase and anSQLDatabase (NPS, 1996). Avoid leading or trailing underscores. Names with leading or trailing underscores are usually reserved for system purposes, and may not be used for any user-created names except for pre-processor defines (NPS, 1996). More importantly, underscores are annoying and difficult to type so I try to avoid their use whenever possible. Good Documentation We will also be discussing documentation conventions, so lets discuss some of the basics first: Comments should add to the clarity of your code. The reason why you document your code is to make it more understandable to you, your coworkers, and to any other developer who comes after you (Nagler, 1995). If your program isnt worth documenting, it probably isnt worth running (Nagler, 1995). What can I say, Nagler hit the nail on the head with this one. Avoid decoration, i.e. do not use banner-like comments. In the 1960s and 1970s COBOL programmers got into the habit of drawing boxes, typically with asterisks, around their internal comments (NPS, 1996). Sure, it gave them an outlet for their artistic urges, but frankly it was a major waste of time that added little value to the end

product. You want to write clean code, not pretty code. Furthermore, because many of the fonts used to display and print your code are proportional, and many arent, you cant line up your boxes properly anyway. Keep comments simple. Some of the best comments I have ever seen are simple, point-form notes. You do not have to write a book, you just have to provide enough information so that others can understand your code. Write the documentation before you write the code. The best way to document code is to write the comments before you write the code. This gives you an opportunity to think about how the code will work before you write it and will ensure that the documentation gets written. Alternatively, you should at least document your code as you write it. Because documentation makes your code easier to understand you are able to take advantage of this fact while you are developing it. The way I look at it, if you are going to invest the time writing documentation you should at least get something out of it (Ambler, 1998a). Document why something is being done, not just what. Fundamentally, I can always look at a piece of code and figure out what it does. For example, I can look at the code in Example 1 below and figure out that a 5% discount is being given on orders of $1,000 dollars or more. Why is this being done? Is there a business rule that says that large orders get a discount? Is there a limited-time special on large orders or is it a permanent program? Was the original programmer just being generous? I do not know unless it is documented somewhere, either in the source code itself or in an external document (Ambler, 1998a).

4.1. An Overview of J2EE

The following topics describe the J2EE Platform requirements for each kind of J2EE platform element. J2EE Application Components The J2EE runtime environment defines four application component types that a J2EE product must support:

Application clients are Java programming language programs that are typically GUI programs that execute on a desktop computer. Application clients offer a user experience similar to that of native applications, and have access to all of the facilities of the J2EE middle tier. Applets are GUI components that typically execute in a web browser, but can execute in a variety of other applications or devices that support the applet-programming model. Applets can be used to provide a powerful user interface for J2EE applications. Servlets, JSP pages, filters, and web event listeners typically execute in a web container and may respond to HTTP requests from web clients. Servlets, JSP pages, and filters may be used to generate HTML pages that are an applications user interface. They may also be used to generate XML or other format data that is consumed by other application components. A special kind of servlet provides support for web services using the SOAP/HTTP protocol. Servlets, pages created with the JavaServer Pages technology, web filters, and web event listeners are referred to collectively in this specification as web components. Web applications are composed of web components and other data such as HTML pages. Web components execute in a web container. A web server includes a web container and other protocol support, security support, and so on, as required by J2EE specifications. Enterprise JavaBeans (EJB) components execute in a managed environment that supports transactions. Enterprise beans typically contain the business logic for a J2EE application. Enterprise beans may directly provide web services using the SOAP/HTTP protocol. J2EE Server Support for Application Components The J2EE servers provide deployment, management, and execution support for conforming application components. Application components can be divided into three categories according to their dependence on a J2EE server: Components that are deployed, managed, and executed on a J2EE server. These components include web components and Enterprise JavaBeans components. See the separate specifications for these components.

Components that are deployed and managed on a J2EE server, but are loaded to and executed on a client machine. These components include web resources such as HTML pages and applets embedded in HTML pages. Components deployment and management is not completely defined by this specification. Application Clients fall into this category. Future versions of this specification may more fully define deployment and management of Application Clients. J2EE Containers Containers provide the runtime support for J2EE application components. Containers provide a federated view of the underlying J2EE APIs to the application components. J2EE application components never interact directly with other J2EE application components. J2EE Servers Underlying a J2EE container is the server of which it is a part. A J2EE Product Provider typically implements the J2EE server-side functionality using an existing transaction processing infrastructure in combination with Java 2 Platform, Standard Edition (J2SE) technology. The J2EE client functionality is typically built on J2SE technology. Resource Adapters A resource adapter is a system-level software component that implements network connectivity to an external resource manager. A resource adapter can extend the functionality of the J2EE platform either by implementing one of the J2EE standard service APIs (such as a JDBC driver), or by defining and implementing a resource adapter for a connector to an external application system. Java Transaction API (JTA) The Java Transaction API consists of two parts:

An application-level demarcation interface is used by the container and application components to demarcate transaction boundaries. An interface between the transaction manager and a resource manager used at the J2EE SPI level (in a future release). RMI-IIOP The RMI-IIOP subsystem is composed of APIs that allow for the use of RMI-style programming that is independent of the underlying protocol, as well as an implementation of those APIs that supports both the J2SE native RMI protocol (JRMP) and the CORBA IIOP protocol. J2EE applications can use RMI-IIOP, with IIOP protocol support, to access CORBA services that are compatible with the RMI programming restrictions (see the RMI-IIOP spec for details).

JDBC API The JDBC API is the API for connectivity with relational database systems. The JDBC API has two parts: an application-level interface used by the application components to access a database, and a service provider interface to attach a JDBC driver to the J2EE platform. Support for the service provider interface is not required in J2EE products. Java Message Service (JMS) The Java Message Service is a standard API for messaging that supports reliable pointto-point messaging as well as the publish-subscribe model. This specification requires a JMS provider that implements both point-to-point messaging as well as publishsubscribe messaging. Java Naming and Directory Interface (JNDI) The JNDI API is the standard API for naming and directory access. The JNDI API has two parts: an application-level interface used by the application components to access naming and directory services and a service provider interface to attach a provider of a naming and directory service. Java Connector Architecture

The Connector architecture is a J2EE SPI that allows resource adapters that support access to Enterprise Information Systems to be plugged in to any J2EE product. The Connector architecture defines a standard set of system-level contracts between a J2EE server and a resource adapter. Security Service The Java Authentication and Authorization Service (JAAS) enables services to authenticate and enforce access controls upon users. It implements a Java technology version of the standard Pluggable Authentication Module (PAM) framework, and extends the access control architecture of the Java 2 Platform in a compatible fashion to support user-based authorization. The Java Authorization Service Provider Contract for Containers (JACC) defines a contract between a J2EE application server and an authorization service provider, allowing custom authorization service providers to be plugged into any J2EE product. Web Services J2EE provides full support for both clients of web services as well as web service endpoints. Several Java technologies work together to provide support for web services. The Java API for XML-based RPC (JAX-RPC) provides support for web service calls using the SOAP/HTTP protocol. JAX-RPC defines the mapping between Java classes and XML as used in SOAP RPC calls. The SOAP with Attachments API for Java (SAAJ) provides support for manipulating low-level SOAP messages. The Web Services for J2EE specification fully defines the deployment of web service clients and web service endpoints in J2EE, as well as the implementation of web service endpoints using enterprise beans. The Java API for XML Registries (JAXR) provides client access to XML registry servers. Deployment The Java 2 Platform, Enterprise Edition Deployment Specification defines a contract between deployment tools and J2EE products. The J2EE products provide plug-in components that run in the deployment tool and allow the deployment tool to deploy applications into the J2EE product. The deployment tool provides services used by these plug-in components.

4.2. J2EE Architecture

4.3. Web Applications and Exploded Directory Format (EDF)

Overview of Web Applications A Web application contains an applications resources, such as servlets, JavaServer Pages (JSPs), JSP tag libraries, static resources such as HTML pages and image files. A Web Application can also define links to outside resources such as Enterprise Java Beans (EJBs). Web applications deployed on WebLogic Server use a standard J2EE deployment descriptor file and Web Logic-specific deployment descriptor file to define their resources and operating attributes. JSP and HTTP servlets can access all services and APIs available in Web Logic Server. These services include EJB, database connections via Java Database Connectivity (JDBC), Java Messaging Service (JMS), XML, and more. A Web archive (WAR file) contains the files that make up a Web application (WAR file). A WAR file is deployed as a unit on one or more Web Logic

Server instances. A Web archive on Web Logic Server always includes the following files: One servlet or Java Server Page (JSP), along with any helper classes. A web.xml deployment descriptor, which is a J2EE standard XML document that describes the contents of a WAR file. A weblogic.xml deployment descriptor, which is an XML document containing Web Logic Server-specific elements for Web applications. A Web archive may also include HTML or XML pages and supporting files such as image and multimedia files. The WAR file can be deployed alone or packaged in an enterprise application archive (EAR file) with other application components. If deployed alone, the archive must end with a .war extension. If deployed in an EAR file, the archive must end with an .ear extension. BEA recommends that you package and deploy your standalone Web applications as part of an enterprise application. This is a BEA best practice, which allows for easier application migration, additions, and changes. Also, packaging your applications as part of an enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure. Note: If you are deploying a directory in exploded format (not archived), do not name the directory .ear, .jar, and so on. Web Application Directory Structure Web applications use a standard directory structure defined in the J2EE specification. You can deploy a Web application as a collection of files that use this directory structure, known as exploded directory format, or as an archived file called a WAR file. BEA recommends that you package and deploy your WAR file as part of an enterprise application. This is a BEA best practice, which allows for easier application migration, additions, and changes. Also, packaging your Web application as part of an enterprise application allows you to take advantage of the split development directory structure, which provides a number of benefits over the traditional single directory structure. Web application components are assembled in a directory in order to stage the WAR file for the jar command. HTML pages, JSP pages, and the non-Java class files they reference are accessed beginning in the top level of the staging directory. The WEB-INF directory contains the deployment descriptors for the Web application (web.xml) and weblogic.xml) and two subdirectories for storing compiled Java classes and library JAR

files. These subdirectories are respectively named classes and lib. JSP taglibs are stored in the Web Applications Basics WEB-INF directory at the top level of the staging directory. The Java classes include servlets, helper classes and, if desired, precompiled JSP. The entire directory, once staged, is bundled into a WAR file using the jar command. The WAR file can be deployed alone or as part of an enterprise application (recommended) with other application components, including other Web applications, EJB components, and Web Logic Server components. JSP pages and HTTP servlets can access all services and APIs available in Web Logic Server. These services include EJBs, database connections through Java Database Connectivity (JDBC), Java Message Service (JMS), XML, and more. Main Steps to Create a Web Application The following is an example of a Web application directory structure, in which myWebApp/ is the staging directory: Web Application Directory Structure

e b

p p lic a t io n M y W e b W w w A E B

t r u c t u r e

( E

F )

o r m

a t

p p - I N F l l

e b . x m

e b lo g i c . x m l i b / m

y l ib . j a r

c l a s s e s / m y p a c k a g e m * . h t m l , * .h t m * . j s p y s e r v l e t. c l a s s , i m a g e f i l e s

4.4.Graphical User Interface.

4.5. An Overview of JSP

The Java Server Pages Technology Java Server Pages technology is the Java technology in the J2EE platform for building applications containing dynamic Web content such as HTML, DHTML, XHTML and XML. The Java Server Pages technology enables the authoring of Web pages that create dynamic content easily but with maximum power and flexibility. The Java Server Pages technology provides a textual description for the creation of a response from a request. The technology builds on the following concepts:

Template Data Substantial portions of dynamic content is actually fixed. The JSP technology allow for the natural manipulation of this data. Addition of Dynamic Data The JSP technology allows the addition of dynamic data to the template data in a way that is simple yet powerful. Encapsulation of Functionality The JSP technology provides two related mechanisms for the encapsulation of functionality: the standard Java Beans component architecture and the tag library mechanism. Good Tool Support The JSP technology has features that enable the creation of good authoring tools. The result is a flexible and powerful server-side technology.

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, 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. High quality tool support The Write Once, Run Anywhere properties of JSP allows the user to choose best-ofbreed 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. Reuse of components and tag libraries The Java Server Pages technology emphasizes the use of reusable components such as Java Beans components, Enterprise Java Beans components and tag libraries. 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. 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.

4.6. An Overview of Servlets

What is a Servlet
A servlet is a web component, managed by a container that generates dynamic content. Servlets are small, platform independent Java classes compiled to an architecture neutral byte code that can be loaded dynamically into and run by a web server. Servlets interact with web clients via a request response paradigm implemented by the servlet container. This request-response model is based on the behavior of the Hypertext Transfer Protocol (HTTP).

What is a Servlet Container

The servlet container, in conjunction with a web server or application server, provides the network services over which requests and responses are set, decodes MIME based requests, and formats MIME based responses. A servlet container also contains and manages servlets through their lifecycle. A servlet container can either be built into a host web server or installed as an add-on component to a Web Server via that servers native extension API. Servlet Containers can also be built into or possibly installed into web-enabled Application Servers. All servlet containers must support HTTP as a protocol for requests and responses, but may also support other request / response based protocols such as HTTPS (HTTP over SSL). The minimum required version of the HTTP specification that a container must implement is HTTP/1.0. It is strongly suggested that containers implement the HTTP/1.1 specification as well. A Servlet Container may place security restrictions on the environment that a servlet can executed In a Java 2 Platform Standard Edition 1.2 (J2SE) or Java 2 Platform Enterprise Edition 1.3 (J2EE) environment, these restrictions should be placed using the permission architecture defined by Java 2 Platform. For example, high end application servers may limit certain action, such as the creation of a Thread object, to insure that other components of the container are not negatively impacted.

4.7. An Overview of JDBC

JDBC drivers implement the interfaces and classes of the JDBC API. The following sections describe the JDBC driver options that you can use with WebLogic Server. Types of JDBC Drivers WebLogic Server uses the following types of JDBC drivers that work in conjunction with each other to provide database access: Standard JDBC drivers that provide database access directly between a WebLogic Server connection pool and the database. Web Logic Server uses a DBMS vendor-specific JDBC driver, such as the WebLogic jDrivers for Oracle and Microsoft SQL Server, to connect to a back-end database.

Wrapper drivers that provide vendor-neutral database access. A Java client application can use a wrapper driver to access any database configured in WebLogic server (via a connection pool). BEA offers three wrapper driversRMI, Pool, and JTS. The WebLogic Server system uses these drivers behind the scenes when you use a JNDI look-up to get a connection from a connection pool through a data source. A client application can also use these drivers directly to get a connection from a connection pool (You can use RMI from external clients and the pool and JTS from server-side clients only). However, BEA recommends that you use a data source to get a connection from a connection pool, rather than using these drivers directly. The middle tier architecture of WebLogic Server, including data sources and connection pools, allows you to manage database resources centrally in WebLogic Server. The vendorneutral wrapper drivers makes it easier to adapt purchased components to your DBMS environment and to write more portable code. Using JDBC Drivers with WebLogic Server
Web Logic Server JDBC Drivers

WebLogic jDriver for Oracle BEAs WebLogic jDriver for Oracle is included with the WebLogic Server distribution. This driver requires an Oracle client installation. The WebLogic jDriver for Oracle XA driver extends the WebLogic jDriver for Oracle for distributed transactions. Type 2 (requires native libraries): WebLogic jDriver for Oracle WebLogic jDriver for Oracle XA Third-party drivers, such as the Oracle OCI driver and theIBM DB2 driver Between WebLogic Server and DBMS in local and distributed transactions. Type 4 (pure Java) WebLogic jDrivers for Microsoft SQL Server Third-party drivers, including: Oracle Thin and Oracle Thin XA drivers Between WebLogic Server and DBMS in local and distributed transactions.

Type 3 WebLogic RMI Driver Between an external client and WebLogic Server (connection pool).

4.8. An Overview of WebLogic Server 8.1

WebLogic Server provides essential features for developing and deploying missioncritical e-commerce applications across distributed, heterogeneous computing environments. These features include the following:

Standards leadershipComprehensive enterprise Java support to ease the

implementation and deployment of application components. WebLogic Server is the first independently developed Java application server to achieve J2EE certification. In addition, BEA actively participates in the development of J2EE and Web Services standards that drive innovation and advancement in Java and XML technology.

Rich client optionsWebLogic Server supports Web browsers and other

clients that use HTTP; Java clients that use RMI (Remote Method Invocation) or IIOP (Internet Inter-ORB Protocol); SOAP clients on any SOAP-enabled platform; and mobile devices that use (WAP) Wireless Access Protocol. Connectors from BEA and other companies enable virtually any client or legacy application to work with a WebLogic Server application.

Flexible Web servicesWebLogic Server provides a solid platform for

deploying Web services as components of a heterogeneous distributed application. Web services use a cross-platform, cross-language data model (XML) to provide interoperability among application components on diverse hardware and software platforms. Web services support user-defined data types and oneway asynchronous operations. A Web service can intercept SOAP messages for further processing. New Ant tasks automatically generate important components and package the service into a deployable EAR file.

WebLogic Server uses Web Services Description Language (WSDL) 1.1, an XML-based specification, to describe Web services. WebLogic Web services support Simple Object Access Protocol (SOAP) 1.1 and 1.2 as the message format and HTTP as a connection protocol. Note: WebLogic Web services accept both SOAP 1.1 and 1.2 incoming requests, but produce only SOAP 1.1 outgoing responses.

Enterprise e-business scalabilityEfficient use and high availability of resources are achieved through Enterprise JavaBean business

critical

components and mechanisms such as WebLogic Server clustering for dynamic Web pages, backend resource pooling, and connection sharing.

Robust

administrationWebLogic

Server

offers

Web-based

Administration Console for configuring and monitoring WebLogic Server services. A command-line interface for configuration makes it convenient to administer WebLogic Servers with scripts.

E-commerce-ready securityWebLogic Server provides Secure Sockets

Layer (SSL) support for encrypting data transmitted across WebLogic Server, clients, and other servers. User authentication and authorization for all WebLogic Server services are provided through roles and security providers. External security stores, such as Lightweight Directory Access Protocol (LDAP) servers, can still be adapted to WebLogic realms, enabling single sign-on for the enterprise. The Security Service Provider Interface makes it possible to extend WebLogic Security services and to implement WebLogic Security features in applications.

Maximum development and deployment flexibility WebLogic Server

provides tight integration with and support for leading databases, development tools, and other environments.

Bi-directional functional interoperability between Java/J2EE objects and

Microsoft ActiveX componentsBEA WebLogic jCOM provides a run-time component that implements both Component Object Model (COM)/Distributed Component Object Model (DCOM) and Remote Method Invocation (RMI) distributed components infrastructures. This makes the objects look like native objects for each environment.

Java Message Service (JMS)An enterprise messaging system, also

referred to as message-oriented middleware (MOM), enables applications to communicate with one another through the exchange of messages. A message is a request, report, and/or event that contains information needed to coordinate communication between different applications. A message provides a level of abstraction, allowing you to separate the details about the destination system from the application code. The Java Message Service (JMS) is a standard API for accessing enterprisemessaging systems. Specifically, JMS enables Java applications sharing a messaging system to exchange messages, and it simplifies application development by providing a standard interface for creating, sending, and receiving messages.

5. System design
5.1. Data Dictionary
Co_Menus COLUMN NAME
CO_MENUID CO_MENUTEXT CO_MENUPARENT CO_MENUSORT CO_MENUICON CO_MENUPATH CO_MENUTYPE CO_MENUHIER CO_MENUREF

TYPE
INTEGER VARCHAR INTEGER INTEGER VARCHAR VARCHAR INTEGER INTEGER VARCHAR

CO_GROUPS COLUMN NAME

CO_GROUPNAME CO_GROUPDESC

TYPE
VARCHAR VARCHAR

CO_USERS COLUMN NAME

CO_USERNAME CO_PASSWORD CO_NAME CO_FIRSTNAME CO_STREET CO_POSTALCODE CO_CITY CO_COUNTRY CO_LANGUAGE CO_EMAIL CO_TELEPHONE

TYPE
VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR

CO_SYSTEMMESSAGE COLUMN NAME

CO_MESSAGEID CO_AUTHOR CO_RECIPIENT CO_MESSAGETEXT CO_SUBJECT CO_SENTDATE CO_DATESCOPE CO_PRIO CO_CONFIRMATION CO_RED

TYPE
INTEGER VARCHAR VARCHAR TEXT VARCHAR VARCHAR INTEGER INTEGER INTEGER INTEGER

CO_DOCUMENT COLUMN NAME

CO_DOCID CO_DOCNAME CO_DOCVERSION CO_DOCDATE CO_DOCPUBLISHER CO_DOCSTATUS CO_MENUID CO_DOCTYPE CO_CHECKOUTUSER CO_SOURCE CO_SOURCEAUTHOR CO_SOURCEDATE CO_SOURCETYPE CO_COVERAGE CO_LANGUAGE

TYPE
INTEGER VARCHAR VARCHAR VARCHAR VARCHAR INTEGER INTEGER VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR

CO_EMAIL COLUMN NAME

CO_MESSAGEID CO_MESSAGETEXT CO_AUTHOR CO_SUBJECT CO_SENTDATE CO_RED CO_AUTHORADDRESS CO_USERNAME CO_FOLDER

TYPE
INTEGER VARCHAR VARCHAR VARCHAR VARCHAR INTEGER VARCHAR VARCHAR VARCHAR

CO_TERMS COLUMN NAME

CO_MENUID CO_STEM CO_VALUE CO_WORDCOUNT CO_WORD

TYPE
INTEGER VARCHAR DOUBLE VARCHAR VARCHAR

CO_VERSIONS COLUMN NAME

CO_DOCID CO_VERSION CO_VERSIONUSER CO_VERSIONDATE CO_VERSIONCOMMENT CO_ACCOUNT

TYPE
INTEGER VARCHAR VARCHAR VARCHAR VARCHAR

COLUMN NAME
CO_ACCOUNTID CO_USERNAME CO_MAILADDRESS CO_PROVIDER CO_HOST CO_PORT CO_ACCOUNTUSER CO_ACCOUNTPASSWORD CO_SMTPHOST

TYPE
INTEGER VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR VARCHAR

CO_ATTACHMENT COLUMN NAME

CO_MESSAGEID CO_PARTID CO_FILENAME CO_ICON CO_MIMETYPE

TYPE
INTEGER INTEGER VARCHAR VARCHAR VARCHAR

CO_MENUGROUP COLUMN NAME

CO_MENUID CO_GROUPNAME CO_WRITEENABLE

TYPE
INTEGER VARCHAR INTEGER

CO_SEARCHDOCUMENT COLUMN NAME

CO_LUCENEID CO_MENUID CO_INDEX

TYPE
INTEGER INTEGER VARCHAR

CO_SEARCHSETTINGS COLUMN NAME

CO_USERNAME CO_MAXFRAGMENTS CO_REPRESENTATION CO_SCREENSIZE

TYPE
VARCHAR INTEGER VARCHAR INTEGER

CO_KEYWORDS COLUMN NAME

CO_DOCID CO_KEYWORD

TYPE
INTEGER VARCHAR

CO_RECIPIENT COLUMN NAME

CO_MESSAGEID CO_ADDRESS CO_NAME

TYPE
INTEGER VARCHAR VARCHAR

CO_USERDOC COLUMN NAME

CO_MENUID CO_USERNAME CO_TIMESTAMP

TYPE
INTEGER VARCHAR VARCHAR

CO_USERGROUP COLUMN NAME

CO_USERNAME CO_GROUPNAME

TYPE
VARCHAR VARCHAR

CO_ARTICLE COLUMN NAME

CO_ARTICLEID CO_DOCID CO_SUBJECT CO_MESSAGE CO_ARTICLEDATE CO_USERNAME CO_HISTORY

TYPE
INTEGER INTEGER VARCHAR TEXT VARCHAR VARCHAR

COLUMN NAME
CO_HISTORYID CO_DOCID CO_DATE CO_USERNAME CO_EVENT

TYPE
INTEGER INTEGER VARCHAR VARCHAR VARCHAR

CO_TICKET COLUMN NAME

CO_TICKETID CO_MENUID CO_USERNAME

TYPE
VARCHAR INTEGER INTEGER

UNIFIED MODELLING LANGUAGE

An Overview of UML
The UML is a language for Visualizing Specifying Constructing Documenting These are the artifacts of a software-intensive system.

A conceptual model of UML:

The three major elements of UML are The UMLs basic building blocks The rules that dictate how those building blocks may be put together. Some common mechanisms that apply throughout the UML.

Basic building blocks of the UML

The vocabulary of UML encompasses three kinds of building blocks: Things Relationships Diagrams Things are the abstractions that are first-class citizens in a model;

Relationships tie these things together; Diagrams group the interesting collection of things. Things in UML: There are four kind of things in the UML 1. Structural things 2. Behavioral things. 3. Grouping things 4. Annotational things These things are the basic object oriented building blocks of the UML.They are used to write well-formed models.

STRUCTURAL THINGS
Structural things are the nouns of the UML models. These are mostly static parts of the model, representing elements that are either conceptual or physical. In all, there are seven kinds of Structural things. Class: A class is a description of a set of objects that share the same attributes, operations, relationships, and semantics. A class implements one or more interfaces. Graphically a class is rendered as a rectangle, usually including its name, attributes and operations, as shown below.

W indow origin Size Open() Close() Display()

Interface: An interface is a collection of operations that specify a service of a class or component. An interface describes the externally visible behaviour of that element. Graphically the interface is rendered as a circle together with its name.

ISpelling

Collaboration: Collaboration defines an interaction and is a society of roles and other elements that work together to provide some cooperative behavior thats bigger than the sum of all the elements. Graphically , a collavoration is rendered as an ellipse with dashed lines, usually including only its name as shown below.

Chain Chain of Responsibility

Use Case: Use case is a description of a set of sequence of actions that a system performs that yields an observable result of value to a particular things in a model. Graphically, Use Case is rendered as an ellipse with dashed lines, usually including only its name as shown below.

Place Order

Active Class: An active class is a class whose objects own one or more processes or threads and therefore can initiate control activity. Graphically, an active class is rendered just like a class, but with heavy lines usually including its name, attributes and operations as shown below.

Event Management

Suspend() Flush()

Component:

Component is a physical and replaceable part of a system that conforms to and provides the realization of a set of interfaces. Graphically, a component is rendered as a rectangle with tabs, usually including only its name, as shown below.

orderform.java

Node: A Node is a physical element that exists at run time and represents a computational resource, generally having at least some memory and often, processing capability. Graphically, a node is rendered as a cube, usually including only its name, as shown below.

server

BEHAVIORAL THINGS
Behavioral Things are the dynamic parts of UML models. These are the verbs of a model, representing behavior over time and space. Interaction:

An interaction is a behavior that comprises a set of messages exchanged among a set of objects within a particular context to accomplish a specific purpose. Graphically, a message is rendered as a direct line, almost always including the name if its operation, as shown below.

Display

State Machine: A state machine is a behavior that specifies the sequence of states an object or an interaction goes through during its lifetime on response to events, together with its responses to those events. Graphically, a state is rendered as rounded rectangle usually including its name and its sub-states, if any, as shown below.

Waiting

GROUPING THINGS
Grouping things are the organizational parts of the UML models. These are the boxes into which a model can be decomposed. Package: A package is a general-purpose mechanism for organizing elements into groups.

Business Rules

ANNOTATIONAL THINGS
Annotational things are the explanatory parts of the UML models.

Note: A note is simply a symbol for rendering constraints and comments attached to an element or a collection of elements. Graphically a note is rendered as a rectangle with dog-eared corner together, with a textual or graphical comment, as shown below.

Business Rules

RELATIONSHIPS IN THE UML:

There are four kinds of relationships in the UML: 1. Dependency 2. Association 3. Generalization 4. Realization

CLASS DIAGRAMS Class diagrams are the most common diagrams found in modeling object-oriented systems. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Graphically, a class diagram is a collection of vertices and arcs. Contents: Class Diagrams commonly contain the following things: Classes Interfaces Collaborations Dependency, generalization and association relationships

USE CASES Use Case diagrams are one of the five diagrams in the UML for modeling the dynamic aspects of systems (activity diagrams, sequence diagrams, state chart diagrams and collaboration diagrams are the four other kinds of diagrams in the UML for modeling the dynamic aspects of systems). Use Case diagrams are central to modeling the behavior of

the system, a sub-system, or a class. Each one shows a set of use cases and actors and relationships. Common Properties: A Use Case diagram is just a special kind of diagram and shares the same common properties, as do all other diagrams- a name and graphical contents that are a projection into the model. What distinguishes a use case diagram from all other kinds of diagrams is its particular content. Contents Use Case diagrams commonly contain: Use Cases Actors Dependency, generalization, and association relationships Like all other diagrams, use case diagrams may contain notes and constraints. Use Case diagrams may also contain packages, which are used to group elements of your model into larger chunks. Occasionally, you will want to place instances of use cases in your diagrams, as well, especially when you want to visualize a specific executing system.

INTERACTION DIAGRAMS An Interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. Interaction diagrams are used for modeling the dynamic aspects of the system. A sequence diagram is an interaction diagram that emphasizes the time ordering of the messages. Graphically, a sequence diagram is a table that shows objects arranged along

the X-axis and messages, ordered in increasing time, along the Y-axis and messages, ordered in increasing time, along the Y-axis.

Contents: Interaction diagrams commonly contains: Objects Links Messages Like all other diagrams, interaction diagrams may contain notes and constraints.

SEQUENCE DIAGRAMS: A sequence diagram is an interaction diagram that emphasizes the time ordering of the messages. Graphically, a sequence diagram is a table that shows objects arranged along the X-axis and messages, ordered in increasing time, along the Y-axis. Typically you place the object that initiates the interaction at the left, and increasingly more sub-routine objects to the right. Next, you place the messages that these objects send and receive along the Y-axis, in order of increasing time from top to the bottom. This gives the reader a clear visual cue to the flow of control over time. Sequence diagrams have two interesting features: 1. There is the object lifeline. An object lifeline is the vertical dashed line that represents the existence of an object over a period of time. Most objects that appear in the interaction diagrams will be in existence for the duration of the interaction, so these objects are all aligned at the top of the diagram, with their lifelines drawn from the top of the diagram to the bottom. 2. There is a focus of the control. The focus of control is tall, thin rectangle that shows the period of time during which an object is performing an action, either directly or through the subordinate procedure. The top of the rectangle is aligns with the action; the bottom is aligned with its completion.

ACTIVITY DIAGRAM

An Activity Diagram is essentially a flow chart showing flow of control from activity to activity. They are used to model the dynamic aspects of as system. They can also be used to model the flow of an object as it moves from state to state at different points in the flow of control. An activity is an ongoing non-atomic execution with in a state machine. Activities ultimately result in some action, which is made up of executable atomic computations that result in a change of state of distinguishes a use case diagram from all other kinds of diagrams is its particular content.

Contents: Use case diagrams commonly contain: Use cases Actors Dependency, generalizations, and association relationships Like all other diagrams use case diagrams may contain notes and constraints

Use case diagrams may also contain packages, which are used to group elements of your model into larger chunks. Occasionally you will want to place instances of use cases of your diagrams, as well especially when you want to visualize a specific executing system.

INTERACTION DIAGRAMS An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among them. A sequence diagram is an interaction diagram that emphasizes the time ordering of messages. Graphically, a sequence diagram is a table that shows objects along the X-Axis and messages along the Y-Axis. Contents: Interaction diagrams commonly contains: Objects Links Messages Like all other diagrams, interaction diagrams may contain notes and constraints.

STATE CHART DIAGRAMS A state chart diagram shows a state machine. State chart diagrams are used to model the dynamic aspects of the system. For the most part this involves modeling the behavior of the reactive objects. A reactive object is one whose behavior is best characterized by its response to events dispatched from outside its context. A reactive object has a clear lifeline whose current behavior is affected by its past. A state chart diagram show a state machine emphasizing the flow of control from state to state. A state machine is a behavior that specifies the sequence of states an object goes through during its life time in response to events together with its response to those events. A state is a condition in the life of the object during which it satisfies some conditions,

performs some activity or wait for some events. An event is a specification of a significant occurrence that has a location in time and space. Graphically a state chart diagram is a collection of vertices and arcs. State chart diagram commonly contain: Simple states and Composite states. Transitions, including events and actions.

UML Diagrams

6. Input and output screens

7.Testing
Testing is the major quality measure employed during the software engineering development. Its basic function is to detect error in the software. Testing is necessary for the proper functioning of the system. Testing has to be done at four levels

Unit Testing
Unit testing focuses verification effort on the smallest unit of the software ,design the module. Here ,using the detail design as a guide ,important control paths are tested to uncover errors within the boundary of the module. Unit testing is always white-box oriented, and the step can be conducted in parallel for multiple modules. .

Integration Testing
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 the unit tested modules and build program structure that has been directed by the design.

Validation Testing
Validation testing demonstrates the traces the requirements of the software .This can be achieved through a series of black box tests.

System Testing
System testing is actually a series of different tests whose primary purpose is to fully exercise the computer-based system . Although each test has a different purpose, all works should verify that all system elements have been properly integrated and perform allocated functions. The various tests include recovery testing , stress testing , perform testing. Test cases

Test C.No .

Input

Expected Behaviour

Observe d behaviou r

Status P= Passed F = Failed

Type Wrong Username and Password for administrator Type Correct username and password Try to Create a group

It has to display the login page again freshly Home page has to be displayed

-do-

-do-

It has to ask to select the group in which this subgroup is created It should display the Group info Display an error message

-do-

4 5

Search for a group by giving the name Create a user which is already

-do-do-

P P

6 7 8

existing Send a Message to the user Send a Message with confirmation Send a Mail to a person

Message will be sent to that user Message will be sent to the user and confirmation will sent to sender Mail will be sent to the targeted user

-do-do-do-

P P P

Create a document with some version and allow a group to access this document Login as another user from another group Try to download the document and save it in the User system

Document has to stored

-do-

10 11

We can access the document what we have created This document has to be saved

-do-

-do-

12

Select the discuss It has to display the Option on the text area to create document the article on this document Give the sort no for the document It has to be sorted based on that number It has to display different options for the document

-do-

13

-do-

14

Click on version option of the document

-do-

15

Click on a keyword in the search option

Document with this starting letter in their names will be displayed

-do-

8. Maintenance and Implementation

Corrective maintenance This acts to correct errors that are uncovered after the software is in use. Adaptive Maintenance This is applied when changes is the external environment precipitate modifications to software. Preventive maintenance This improves future maintainability and reliability and provides basis for future enhancements.

9. Conclusion
TeamSpace is web based document management system which allows the user to

efficiently store documents at a secured location and shared them between the users. It can maintain different versions of the document for feature reference. This system allows the users to flexible communicate using Messages and Mailing option. The user can see the document if he has the permission and he can edit and he can save it with a different version no. The users can discuss about a document and they can store the discussion by creating an article on the document. The user can very search for a document for a particular document using this application. This application has a facility to log all the messages. It supports its users by managing documents in most popular formats. TeamSpace aims to fulfill all phases of document lifecycle. You can create documents by using office software. With TeamSpace itself, you can publish, search, and manage the versions of documents.

10. Glossary
API CGI DHTML GUI HTML HTTP J2EE JDBC JSP SQL URL XML ---------------------------------Application Programming Interface. Common Gateway Interface. Dynamic HyperText Markup Language. ---Graphical User Interface .

HyperText Markup Language. HyperText Transfer Protocol. Java 2 Enterprise Edition. Java DataBase Connectivity. Java Server Pages. Structured Query Language. Uniform Resource Locator. Extensible Markup Language.

11. References
1. Deitel ,Deitel and Nieto ,Internet and World Wide Web how to program.

2. Ian Somerville, Principles of Software Engineering ,4 Edition . 3. Roger S. Pressman ,Software Engineering A Practitioners Approach . 4. IEEE, IEEE Software Standards , IEEE Press ,1989 . 5. Patrick Naughton and Herbert Schildt , Complete Reference Java 2 , 3 Edition ,Tata McGraw Hill ,1999. 6. Er. V.K.Jain , Programming Java Server Pages & Servlets.