View
213
Download
1
Category
Preview:
Citation preview
CONTENTS
Pg.No
1. COMPANY PROFILE
2. ABSTRACT
3. INTRODUCTION
3.1. About the Project
3.2. Project Overview
3.3. Project Scope
3.4. Screen Design/Graphical User Interface
3.5. General Description
4. SYSTEM ANALYSIS
4.1. Need for the System
4.2. Proposed System
4.3. Performing the Feasibility study
4.4. Software Requirements Specification
5. System Development Environment
5.1. Java Coding Standards
5.2. An Overview of J2EE
5.3. J2EE Architecture
5.4. Exploded Directory Format
5.5. Graphical User Interface
5.6. An Overview of JSP
5.7. An Overview of Servlets
5.8. An Overview of JDBC
6. System Design
6.1. Data Dictionary
6.2. Data Flow Diagrams
6.3. ER Diagrams
6.4. UML Diagrams
6.4.1. Class Diagrams
6.4.2. Use Case Diagrams
6.4.3. Sequence Diagrams
6.4.4. State Diagrams
6.4.5. Activity Diagrams
7. Input and Output Screens
8. Testing
8.1. Unit Testing
8.2. Integration Testing
8.3. Validation Testing
8.4. System Testing
9. Maintenance and Implementation
9.1. Corrective Maintenance
9.2. Adaptive Maintenance
9.3. Preventive Maintenance
10. Conclusion
11. Glossary
12. Reference
1. COMPANY PROFILE
Opera Technologies is a leading global software solution company has its full-
fledged 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 meta-informations 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 criteria’s, 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.
Today’s 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, today’s 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.1Purpose :
The purpose of this project is to storage documents in a proper manner
by providing security of an organization.
1.2Document 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.
Coding Standards for function:
• 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.
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.1Security 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 wouldn’t 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 they’re 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 they’re 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 doesn’t 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 let’s 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 isn’t worth documenting, it probably isn’t 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 aren’t, you
can’t 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 application’s 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 point-
to-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 publish-
subscribe 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 application’s 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 stand-
alone 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
W e b A p p l i c a t i o n S t r u c t u r e ( E D F ) F o r m a t
w e b . x m l
w e b l o g i c . x m l
m y l i b . j a r
l i b /
m y s e r v l e t . c l a s s
m y p a c k a g e
c l a s s e s /
W E B - I N F
* . h t m l , * . h t m , i m a g e f i l e s
* . j s p
M y W e b A p p
4.4.Graphical User Interface.
4.5. An Overview of JSP
The Java Server Pages™ TechnologyJava 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-of-
breed tools. Additionally, an explicit goal of the Java Server Pages design is to enable
the creation of high quality portable tools.
Separation of Roles
JSP supports the separation of roles: developers write components that interact with
server-side objects.
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 server’s
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 drivers—RMI, 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 vendor-
neutral 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
BEA’s 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.1WebLogic Server provides essential features for developing and deploying mission-
critical e-commerce applications across distributed, heterogeneous computing
environments. These features include the following:
Standards leadership—Comprehensive 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 options—WebLogic 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 services—WebLogic 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 one-
way 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 scalability—Efficient use and high availability of
critical resources are achieved through Enterprise JavaBean business
components and mechanisms such as WebLogic Server clustering for dynamic
Web pages, backend resource pooling, and connection sharing.
Robust administration—WebLogic Server offers a 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 security—WebLogic 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 components—BEA 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 enterprise-
messaging 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
CO_GROUPS
CO_USERS
COLUMN NAME TYPECO_MENUID INTEGERCO_MENUTEXT VARCHARCO_MENUPARENT INTEGERCO_MENUSORT INTEGERCO_MENUICON VARCHARCO_MENUPATH VARCHARCO_MENUTYPE INTEGERCO_MENUHIER INTEGERCO_MENUREF VARCHAR
COLUMN NAME TYPECO_GROUPNAME VARCHARCO_GROUPDESC VARCHAR
COLUMN NAME TYPECO_USERNAME VARCHARCO_PASSWORD VARCHARCO_NAME VARCHARCO_FIRSTNAME VARCHARCO_STREET VARCHARCO_POSTALCODE VARCHARCO_CITY VARCHARCO_COUNTRY VARCHARCO_LANGUAGE VARCHARCO_EMAIL VARCHARCO_TELEPHONE VARCHAR
CO_SYSTEMMESSAGE
CO_DOCUMENT
CO_EMAIL
COLUMN NAME TYPECO_MESSAGEID INTEGERCO_AUTHOR VARCHARCO_RECIPIENT VARCHARCO_MESSAGETEXT TEXTCO_SUBJECT VARCHARCO_SENTDATE VARCHARCO_DATESCOPE INTEGERCO_PRIO INTEGERCO_CONFIRMATION INTEGERCO_RED INTEGER
COLUMN NAME TYPECO_DOCID INTEGERCO_DOCNAME VARCHARCO_DOCVERSION VARCHAR CO_DOCDATE VARCHARCO_DOCPUBLISHER VARCHARCO_DOCSTATUS INTEGERCO_MENUID INTEGERCO_DOCTYPE VARCHARCO_CHECKOUTUSER VARCHARCO_SOURCE VARCHAR CO_SOURCEAUTHOR VARCHARCO_SOURCEDATE VARCHAR CO_SOURCETYPE VARCHARCO_COVERAGE VARCHARCO_LANGUAGE VARCHAR
COLUMN NAME TYPECO_MESSAGEID INTEGERCO_MESSAGETEXT VARCHARCO_AUTHOR VARCHAR CO_SUBJECT VARCHARCO_SENTDATE VARCHARCO_RED INTEGER CO_AUTHORADDRESS VARCHARCO_USERNAME VARCHAR CO_FOLDER VARCHAR
CO_TERMS
CO_VERSIONS
CO_ACCOUNT
CO_ATTACHMENT
COLUMN NAME TYPECO_MENUID INTEGERCO_STEM VARCHARCO_VALUE DOUBLECO_WORDCOUNT VARCHARCO_WORD VARCHAR
COLUMN NAME TYPECO_DOCID INTEGERCO_VERSION VARCHARCO_VERSIONUSER VARCHARCO_VERSIONDATE VARCHARCO_VERSIONCOMMENT VARCHAR
COLUMN NAME TYPECO_ACCOUNTID INTEGERCO_USERNAME VARCHARCO_MAILADDRESS VARCHAR CO_PROVIDER VARCHARCO_HOST VARCHARCO_PORT VARCHARCO_ACCOUNTUSER VARCHARCO_ACCOUNTPASSWORD VARCHAR CO_SMTPHOST VARCHAR
COLUMN NAME TYPECO_MESSAGEID INTEGERCO_PARTID INTEGERCO_FILENAME VARCHAR CO_ICON VARCHARCO_MIMETYPE VARCHAR
CO_MENUGROUP
CO_SEARCHDOCUMENT
CO_SEARCHSETTINGS
CO_KEYWORDS
CO_RECIPIENT
COLUMN NAME TYPECO_MENUID INTEGERCO_GROUPNAME VARCHARCO_WRITEENABLE INTEGER
COLUMN NAME TYPECO_LUCENEID INTEGERCO_MENUID INTEGERCO_INDEX VARCHAR
COLUMN NAME TYPECO_USERNAME VARCHARCO_MAXFRAGMENTS INTEGERCO_REPRESENTATION VARCHARCO_SCREENSIZE INTEGER
COLUMN NAME TYPECO_DOCID INTEGERCO_KEYWORD VARCHAR
COLUMN NAME TYPECO_MESSAGEID INTEGERCO_ADDRESS VARCHARCO_NAME VARCHAR
CO_USERDOC
CO_USERGROUP
CO_ARTICLE
CO_HISTORY
CO_TICKET
COLUMN NAME TYPECO_MENUID INTEGERCO_USERNAME VARCHARCO_TIMESTAMP VARCHAR
COLUMN NAME TYPECO_USERNAME VARCHARCO_GROUPNAME VARCHAR
COLUMN NAME TYPECO_ARTICLEID INTEGERCO_DOCID INTEGERCO_SUBJECT VARCHARCO_MESSAGE TEXTCO_ARTICLEDATE VARCHARCO_USERNAME VARCHAR
COLUMN NAME TYPECO_HISTORYID INTEGERCO_DOCID INTEGERCO_DATE VARCHARCO_USERNAME VARCHARCO_EVENT VARCHAR
COLUMN NAME TYPECO_TICKETID VARCHARCO_MENUID INTEGERCO_USERNAME 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 UML’s 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.
Window
originSize
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 that’s 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.
ChainChain 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.
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.
Component:
Place Order
Event Management
Suspend()Flush()
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.
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.
Waiting
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
TestC.No
.Input Expected Behaviour
Observed behaviou
r
StatusP =
PassedF = Failed
1
Type Wrong Username and Password for administrator
It has to display the login page again freshly
-do- P
2 Type Correct username and password
Home page has to be displayed
-do- P
3 Try to Create a group
It has to ask to select the group in which this subgroup is created
-do- P
4
Search for a group by giving the name
It should display theGroup info -do- P
5 Create a user which is already
Display an error message
-do- P
existing
6Send a Message to the user
Message will be sent to that user -do- P
7Send a Message with confirmation
Message will be sent to the user and confirmation will sent to sender
-do- P
8
Send a Mail to a person
Mail will be sent to the targeted user
-do- P
9 Create a document with some version and allow a group to access this document
Document has to stored
-do- P
10 Login as another user from another group
We can access the document what we have created
-do- P
11 Try to download the document and save it in the User system
This document has to be saved -do- P
12 Select the discuss Option on the document
It has to display the text area to create the article on this document
-do- P
13 Give the sort no for the document
It has to be sorted based on that number
-do- P
14 Click on version option of the document
It has to display different options for the document
-do- P
15 Click on a keyword in the search option
Document with this starting letter in their names will be displayed
-do- P
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 ---- Application Programming Interface.
CGI ---- Common Gateway Interface.
DHTML ---- Dynamic HyperText Markup Language. GUI ---- Graphical User Interface .
HTML ---- HyperText Markup Language.
HTTP ---- HyperText Transfer Protocol.
J2EE ---- Java 2 Enterprise Edition.
JDBC ---- Java DataBase Connectivity.
JSP ---- Java Server Pages.
SQL ---- Structured Query Language.
URL ---- Uniform Resource Locator. XML ---- 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 Practitioner’s 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.
Recommended