Logistics Management System Complete Documentation

S.No Content Page No.

1 Introduction

2 System Analysis

2.1 Domain Analysis

2.2 Existing system

2.3 Proposed System

2.4 Feasibility Study

3 System Requirements Specifications

3.1 Functional Requirements

3.2 Non Functional Requirements

3.3 Software Requirements

3.4 Hardware Requirements

3.5 UML Representation for Analysis

4 System Design

4.1 User Interface Design

4.2 Architecture Design

4.3 UML Design Diagrams

4.4 Database Design

5 Software Technology

6 Testing

6.1 Test Cases

7 Sample Code

8 Input & Output Results

9 Software Development Life Cycle

10 Conclusion

11 Bibiliography

Introduction

.

Logistics is the . . . “process of planning, implementing, and controlling the

efficient, effective flow and storage of goods, services, and related

information from point of origin to point of consumption for the purpose of

conforming to customer requirements.“

Logistics is the management of the flow of goods, information and other

resources, including energy and people, between the point of origin and

the point of consumption in order to meet the requirements of consumers.

Logistics involves the integration of information, transportation, inventory,

warehousing, material-handling, and packaging, and occasionally security.

The logistics and transportation activities are moving towards the centre

stage world around and becoming the most critical business function in

today’s world of immense competition. Today, quickest and efficient supply

chain management is the key success factor for many business sectors.

Surface transport still rules as the most widely used mode of logistics in

our country. It’s high time; the transportation companies switch to futuristic

technology solutions to manage the ever growing industry requirements

and never ending customer demands. The solutions that move beyond just

logics, towards being efficient, cost effective and quick.

The goal of the entire solution is to work as a mini ERP solution for the

haulage business entities with minimum investment and maintenance

costs. The benefits aren’t cost alone, it will benefit you to stay ahead by

offering high visibility of consignments to your entire team and for the

clients. Also assures customer satisfaction, transparency and effective

control for the business.

System Analysis

Existing system

There is no computerized provision in the company to maintain all the trip

details that are taking within the company. All the customer order are being

handled manually.

A customer has to come up to the company personally to book an order.

All the order details are also being maintained manually.

The labor work is too much and no proper maintenance is taking place in

the existing system.

Problems in Existing System

A considerable amount of effort, time and resources are involved

due to manual processing can be achieved.

No proper control over collection of data.

Proposed System

The proposed system is an online sales system which will help the

company to sell all their products online.

When a customer requires a product or multiple products, he issues an

order for the products. The proposed system will display an order form,

which can be filled by the customer. The proposed system will record the

order details as well as the customer details, and generate an appropriate

Invoice to be presented to the Customer for order confirmation.

Whenever an order is confirmed, then once the payment is done by the

customer the product has to be delivered to the customer.

The appropriate transport facilities must be set. The proposed system

displays all the vehicles information that are available for delivery. It then

allows the Admin to select the vehicle for the door delivery and records all

the information regarding the Trip. The proposed system displays a Door

Delivery form in which the administrator can add all the information

regarding the vehicle, and the customer details to whom the product has to

be delivered.

They are a number of vehicles that are used in the company to deliver the

order given by the customers. The proposed system will display a vehicle

processing form, where the admin can add all the vehicle details that are

available. Also it will add the information of which vehicle has devliered

what products and other related information by using the vehicle delivery

record form.

Feasibility Study

Feasibility studies aim to objectively and rationally uncover the strengths and weaknesses of the

existing business or proposed venture, opportunities and threats as presented by the environment,

the resources required to carry through, and ultimately the prospects for success.

In its simplest term, the two criteria to judge feasibility are cost required and value to be attained.

As such, a well-designed feasibility study should provide a historical background of the business

or project, description of the product or service, accounting statements, details of the operations

and management, marketing research and policies, financial data, legal requirements and tax

obligations. Generally, feasibility studies precede technical development and project

implementation.

They are 3 types of Feasibility

Technology and system feasibility

The assessment is based on an outline design of system requirements in terms of Input, Processes,

Output, Fields, Programs, and Procedures. This can be quantified in terms of volumes of data,

trends, frequency of updating, etc. in order to estimate whether the new system will perform

adequately or not.

Technological feasibility is carried out to determine whether the company has the capability, in

terms of software, hardware, personnel and expertise, to handle the completion of the project

Whether the required technology is available or not

Whether the required resources are available

Manpower- programmers, testers & debuggers

Software and hardware

Once the technical feasibility is established, it is important to consider the monetary factors also.

Since it might happen that developing a particular system may be technically possible but it may

require huge investments and benefits may be less. For evaluating this, economic feasibility of

the proposed system is carried out.

Operational Feasibility

Operational feasibility is mainly concerned with issues like whether the system will be used if it

is developed and implemented. Whether there will be resistance from users that will affect the

possible application benefits? The essential questions that help in testing the operational

feasibility of a system are following.

Does management support the project?

Are the users not happy with current business practices?

Will it reduce the time (operation) considerably? If yes, then they will welcome the

change and the new system.

Have the users been involved in the planning and development of the project? Early

involvement reduces the probability of resistance towards the new system.

Will the proposed system really benefit the organization?

Does the overall response increase?

Will accessibility of information be lost?

Will the system effect the customers in considerable way?

Economic Feasibility

For any system if the expected benefits equal or exceed the expected costs, the system can be

judged to be economically feasible. In economic feasibility, cost benefit analysis is done in which

expected costs and benefits are evaluated. Economic analysis is used for evaluating the

effectiveness of the proposed system.

In economic feasibility, the most important is cost-benefit analysis. As the name suggests, it is an

analysis of the costs to be incurred in the system and benefits derivable out of the system.

System Requirement Specifications

Functional Requirements

Introduction:

In software engineering, a functional requirement defines a function of a software system or its

component. A function is described as a set of inputs, the behavior, and outputs (see also

software).

Functional requirements may be calculations, technical details, data manipulation and processing

and other specific functionality that define what a system is supposed to accomplish. Behavioral

requirements describing all the cases where the system uses the functional requirements are

captured in use cases.

In order to show the functional requirements of the software we have to identify the following

activities.

SOFTRWARE REQUIREMENTS SPECIFICATION:

A Software Requirements Specification (SRS) - a requirements specification for a software

system - is a complete description of the behavior of a system to be developed. It includes a set

of use cases that describe all the interactions the users will have with the software. Use cases

are also known as functional requirements.

Functional Requirements:

Customer Order Processing

Add Order Details

Add Customer Details

Generate Order Report

Maintain Orders

Search Datewise Orders

Vehicle Maintenance Processing

Input New Vehicle Information

View Trips

Manage Door Pickup and Delivery Details

Input Customer Details

Accounts Processing

Adding various Branch Details

View Payment Information

View/Manage Pending Payments

Invoice Controlling

Online Trips Processing

Maintaing Branch Details

View Customer Information

Temporary Trips Management

Non Functional Requirements

Non-Functional Requirements describe the aspect of the system that are not directly related to its

functional behavior. The different Non-functional requirements for our project are

Performance Requirements: Since the software is online, therefore much of the

performance of the system depends on the traffic that is present online and the speed of the

Internet. We are trying to give an improved performance by setting cookies to the functions so

that when the user submits something for the second time, the processing is done much quicker.

Security Requirements: In order to provide security to the data all the different loginID’s

are completed encrypted and then transferred online. A strong encryption technique is used to

encrypt all the sensitive data.

Quality Software Requirements: The software is developed with a very high quality, as

the users can find their required data very quickly and efficiently. We will also provide a user

documentation with which the user can use the software very easily.

Software Requirements

Platform:

Windows XP Operating System

Server:

Apache Tomcat Web Server

Technology:

J2SE (Java 2 Second Edition) and J2EE (Java 2 Enterprise Edition)

API:

Java SQL Package (java.sql)

Java Servlet Package (javax.servlet)

Database:

Oracle

Front End Design Tool:

HTML, DHTML, Dreamweaver, Javascript, Cascading Style Sheets

Image Design Tools:

Adobe Photoshop

Hardware Requirements

PROCESS : PENTIUM IV 2.6 GHz

RAM : 512 MB DD RAM

MONITOR : 15” COLOR

HARD DISK : 20 GB

CDDRIVE : LG 52X

KEYBOARD : STANDARD 102 KEYS

UML Diagrams

Introduction to UML

Unified Modeling Language is the one of the most exciting tools in the world of system

development today. Because UML enables system builders to create blue prints that capture their

visions in a standard, easy to understand way and communicate them to others. The UML is

brainchild of Grady Brooch, James Rumbaugh and Ivar Jacobson.

Components of UML:

The UML consists of a number of graphical elements that combine to form diagrams. Because

it’s a language, the UML has rules for combining these elements. The purpose of the diagrams to

present multiple views of the system, and this set of multiple views is called a Model. A UML

Model of a system is something like a scale model of a building. UML model describes what a

system is supposed to do. It doesn’t tell how to implement the system.

Use Case Diagram:

A Use-Case is a description of a systems behavior from a users stand point. For system developer

this is a valuable tool: it’s a tried-and-true technique for gathering system requirements from a

user’s point of view. A little stick figure is used to identify an actor the ellipse represents use-case

functions.

Notations of Use Cases

Use cases. A use case describes a sequence of actions that provide something of measurable value

to an actor and is drawn as a horizontal ellipse.

Actors. An actor is a person, organization, or external system that plays a role in one or more

interactions with your system. Actors are drawn as stick figures.

Associations.  Associations between actors and use cases are indicated in use case diagrams by

solid lines. An association exists whenever an actor is involved with an interaction described by a

use case.  Associations are modeled as lines connecting use cases and actors to one another, with

an optional arrowhead on one end of the line. The arrowhead is often used to indicating the

direction of the initial invocation of the relationship or to indicate the primary actor within the use

case.  The arrowheads are typically confused with data flow and as a result I avoid their use.

System boundary boxes (optional). You can draw a rectangle around the use cases, called the

system boundary box, to indicates the scope of your system.  Anything within the box represents

functionality that is in scope and anything outside the box is not.  System boundary boxes are

rarely used, although on occasion I have used them to identify which use cases will be delivered

in each major release of a system.

Class Diagrams:

Class diagrams describe the structure of the system in terms of classes and objects.

Classes are abstractions that specify the attributes and behavior of a set of objects. Objects are

entities that encapsulate state and behavior. Each object has an identity: It can be referred

individually and is distinguishable from other objects.

Basic Class Diagram Symbols and Notations

Classes represent an abstraction of entities with common characteristics. Associations represent

the relationships between classes.

Illustrate classes with rectangles divided into compartments. Place the name of the class in the

first partition (centered, bolded, and capitalized), list the attributes in the second partition, and

write operations into the third.

Active Class

Active classes initiate and control the flow of activity, while passive classes store data and serve

other classes. Illustrate active classes with a thicker border.

Visibility

Use visibility markers to signify who can access the information contained within a class. Private

visibility hides information from anything outside the class partition. Public visibility allows all

other classes to view the marked information. Protected visibility allows child classes to access

information they inherited from a parent class

Associations

Associations represent static relationships between classes. Place association names above, on, or

below the association line. Use a filled arrow to indicate the direction of the relationship. Place

roles near the end of an association. Roles represent the way the two classes see each other.

Note: It's uncommon to name both the association and the class roles.

Multiplicity (Cardinality)

Place multiplicity notations near the ends of an association. These symbols indicate the number of

instances of one class linked to one instance of the other class. For example, one company will

have one or more employees, but each employee works for one company only.

Composition and Aggregation

Composition is a special type of aggregation that denotes a strong ownership between Class A,

the whole, and Class B, its part. Illustrate composition with a filled diamond. Use a hollow

diamond to represent a simple aggregation relationship, in which the "whole" class plays a more

important role than the "part" class, but the two classes are not dependent on each other. The

diamond end in both a composition and aggregation relationship points toward the "whole" class

or the aggregate.

Generalization

Generalization is another name for inheritance or an "is a" relationship. It refers to a relationship

between two classes where one class is a specialized version of another. For example, Honda is a

type of car. So the class Honda would have a generalization relationship with the class car.

Sequence Diagrams

Sequence diagrams describe interactions among classes in terms of an exchange of messages over

time.

Basic Sequence Diagram Symbols and Notations

Class roles

Class roles describe the way an object will behave in context. Use the UML object symbol to

illustrate class roles, but don't list object attributes.

Activation

Activation boxes represent the time an object needs to complete a task.

Messages

Messages are arrows that represent communication between objects. Use half-arrowed lines to

represent asynchronous messages. Asynchronous messages are sent from an object that will not

wait for a response from the receiver before continuing its tasks.

Lifelines

Lifelines are vertical dashed lines that indicate the object's presence over time.

State Chart Diagrams

A statechart diagram shows the behavior of classes in response to external stimuli. This diagram

models the dynamic flow of control from state to state within a system.

Basic Statechart Diagram Symbols and Notations

States

States represent situations during the life of an object. You can easily illustrate a state in

SmartDraw by using a rectangle with rounded corners.

Transition

A solid arrow represents the path between different states of an object. Label the transition with

the event that triggered it and the action that results from it.

Initial State

A filled circle followed by an arrow represents the object's initial state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the object's final state.

Synchronization and Splitting of Control

A short heavy bar with two transitions entering it represents a synchronization of control. A short

heavy bar with two transitions leaving it represents a splitting of control that creates multiple

states.

Activity Diagrams

An activity diagram illustrates the dynamic nature of a system by modeling the flow of control

from activity to activity. An activity represents an operation on some class in the system that

results in a change in the state of the system. Typically, activity diagrams are used to model

workflow or business processes and internal operation. Because an activity diagram is a special

kind of statechart diagram, it uses some of the same modeling conventions.

Basic Activity Diagram Symbols and Notations

Action states

Action states represent the noninterruptible actions of objects. You can draw an action state in

SmartDraw using a rectangle with rounded corners.

Action Flow

Action flow arrows illustrate the relationships among action states.

Object Flow

Object flow refers to the creation and modification of objects by activities. An object flow arrow

from an action to an object means that the action creates or influences the object. An object flow

arrow from an object to an action indicates that the action state uses the object.

Initial State

A filled circle followed by an arrow represents the initial action state.

Final State

An arrow pointing to a filled circle nested inside another circle represents the final action state.

Branching

A diamond represents a decision with alternate paths. The outgoing alternates should be labeled

with a condition or guard expression. You can also label one of the paths "else."

Synchronization

A synchronization bar helps illustrate parallel transitions. Synchronization is also called forking

and joining.

Collaboration Diagrams

A collaboration diagram describes interactions among objects in terms of sequenced messages.

Collaboration diagrams represent a combination of information taken from class, sequence, and

use case diagrams describing both the static structure and dynamic behavior of a system.

Basic Collaboration Diagram Symbols and Notations

Class roles

Class roles describe how objects behave. Use the UML object symbol to illustrate class roles, but

don't list object attributes.

Association roles

Association roles describe how an association will behave given a particular situation. You can

draw association roles using simple lines labeled with stereotypes.

Messages

Unlike sequence diagrams, collaboration diagrams do not have an explicit way to denote time and

instead number messages in order of execution. Sequence numbering can become nested using

the Dewey decimal system. For example, nested messages under the first message are labeled 1.1,

1.2, 1.3, and so on. The a condition for a message is usually placed in square brackets

immediately following the sequence number. Use a * after the sequence number to indicate a

loop.

System Design

A software design document (SDD) is a written description of a software product, that a software

designer writes in order to give a software development team an overall guidance of the

architecture of the software project.

An SDD usually accompanies an architecture diagram with pointers to detailed feature

specifications of smaller pieces of the design. Practically, a design document is required to

coordinate a large team under a single vision.

A design document needs to be a stable reference, outlining all parts of the software and how they

will work. The document is commanded to give a fairly complete description, while maintaining

a high-level view of the software.

The SDD contains the following documents:

1. Architecture Design2. User Interface Design3. Data Design

System/Architecture Design

3 Tier Architecture

Three-tier[2] is a client–server architecture in which the user interface, functional process logic

("business rules"), computer data storage and data access are developed and maintained as

independent modules, most often on separate platforms. It was developed by John J. Donovan in

Open Environment Corporation (OEC), a tools company he founded in Cambridge,

Massachusetts.

The three-tier model is a software architecture and a software design pattern.

Apart from the usual advantages of modular software with well-defined interfaces, the three-tier

architecture is intended to allow any of the three tiers to be upgraded or replaced independently as

requirements or technology change. For example, a change of operating system in the

presentation tier would only affect the user interface code.

Typically, the user interface runs on a desktop PC or workstation and uses a standard graphical

user interface, functional process logic may consist of one or more separate modules running on a

workstation or application server, and an RDBMS on a database server or mainframe contains the

computer data storage logic. The middle tier may be multi-tiered itself (in which case the overall

architecture is called an "n-tier architecture").

Three-tier architecture has the following three tiers:

Presentation tier

This is the topmost level of the application. The presentation tier displays information related

to such services as browsing merchandise, purchasing, and shopping cart contents. It

communicates with other tiers by outputting results to the browser/client tier and all other tiers in

the network.

Application tier (business logic, logic tier, data access tier, or middle tier)

The logic tier is pulled out from the presentation tier and, as its own layer, it controls an

application’s functionality by performing detailed processing.

Data tier

This tier consists of database servers. Here information is stored and retrieved. This tier keeps

data neutral and independent from application servers or business logic. Giving data its own tier

also improves scalability and performance.

Deployment Diagrams

Deployment diagrams depict the physical resources in a system including nodes, components,

and connections.

Basic Deployment Diagram Symbols and Notations

Component

A node is a physical resource that executes code components.Learn how to resize grouped objects like nodes.

Association

Association refers to a physical connection between nodes, such as Ethernet.Learn how to connect two nodes.

Components and Nodes

Place components inside the node that deploys them.

User Interface Design

User interface design or user interface engineering is the design of computers, appliances,

machines, mobile communication devices, software applications, and websites with the focus on

the user's experience and interaction.

The goal of user interface design is to make the user's interaction as simple and efficient as

possible, in terms of accomplishing user goals—what is often called user-centered design.

Good user interface design facilitates finishing the task at hand without drawing unnecessary

attention to itself. Graphic design may be utilized to support its usability. The design process

must balance technical functionality and visual elements (e.g., mental model) to create a system

that is not only operational but also usable and adaptable to changing user needs.

Interface design is involved in a wide range of projects from computer systems, to cars, to

commercial planes; all of these projects involve much of the same basic human interactions yet

also require some unique skills and knowledge.

As a result, designers tend to specialize in certain types of projects and have skills centered

around their expertise, whether that be software design, user research, web design, or industrial

design.

Tips for User Interface

Consistency, consistency, consistency. I believe the most important thing you

can possibly do is ensure your user interface works consistently. If you can double-click on items

in one list and have something happen, then you should be able to double-click on items in any

other list and have the same sort of thing happen. Put your buttons in consistent places on all your

windows, use the same wording in labels and messages, and use a consistent color scheme

throughout. Consistency in your user interface enables your users to build an accurate mental

model of the way it works, and accurate mental models lead to lower training and support costs.

2. Set standards and stick to them:

The only way you can ensure consistency within your application is to set user interface design

standards, and then stick to them. You should follow Agile Modeling (AM)’s Apply Modeling

Standards practice in all aspects of software development, including user interface design.

3. Be prepared to hold the line.

When you are developing the user interface for your system you will discover that your

stakeholders often have some unusual ideas as to how the user interface should be developed.

You should definitely listen to these ideas but you also need to make your stakeholders aware of

your corporate UI standards and the need to conform to them.

4. Explain the rules.

Your users need to know how to work with the application you built for them. When an

application works consistently, it means you only have to explain the rules once. This is a lot

easier than explaining in detail exactly how to use each feature in an application step-by-step.

5. Navigation between major user interface items is important.

If it is difficult to get from one screen to another, then your users will quickly become frustrated

and give up. When the flow between screens matches the flow of the work the user is trying to

accomplish, then your application will make sense to your users. Because different users work in

different ways, your system needs to be flexible enough to support their various approaches. User

interface-flow diagrams should optionally be developed to further your understanding of the flow

of your user interface.

6. Navigation within a screen is important.

In Western societies, people read left to right and top to bottom. Because people are used to this,

should you design screens that are also organized left to right and top to bottom when designing a

user interface for people from this culture? You want to organize navigation between widgets on

your screen in a manner users will find familiar to them.

7. Word your messages and labels effectively.

The text you display on your screens is a primary source of information for your users. If your

text is worded poorly, then your interface will be perceived poorly by your users. Using full

words and sentences, as opposed to abbreviations and codes, makes your text easier to

understand. Your messages should be worded positively, imply that the user is in control, and

provide insight into how to use the application properly. For example, which message do you find

more appealing “You have input the wrong information” or “An account number should be eight

digits in length.” Furthermore, your messages should be worded consistently and displayed in a

consistent place on the screen. Although the messages “The person’s first name must be input”

and “An account number should be input” are separately worded well, together they are

inconsistent. In light of the first message, a better wording of the second message would be “The

account number must be input” to make the two messages consistent.

8. Understand the UI widgets.

You should use the right widget for the right task, helping to increase the consistency in your

application and probably making it easier to build the application in the first place. The only way

you can learn how to use widgets properly is to read and understand the user-interface standards

and guidelines your organization has adopted.

9. Look at other applications with a grain of salt.

Unless you know another application has been verified to follow the user interface-standards and

guidelines of your organization, don’t assume the application is doing things right. Although

looking at the work of others to get ideas is always a good idea, until you know how to

distinguish between good user interface design and bad user interface design, you must be

careful. Too many developers make the mistake of imitating the user interface of poorly designed

software.

10. Use color appropriately.

Color should be used sparingly in your applications and, if you do use it, you must also use a

secondary indicator. The problem is that some of your users may be color blind and if you are

using color to highlight something on a screen, then you need to do something else to make it

stand out if you want these people to notice it. You also want to use colors in your application

consistently, so you have a common look and feel throughout your application.

11. Follow the contrast rule.

If you are going to use color in your application, you need to ensure that your screens are still

readable. The best way to do this is to follow the contrast rule: Use dark text on light backgrounds

and light text on dark backgrounds. Reading blue text on a white background is easy, but reading

blue text on a red background is difficult. The problem is not enough contrast exists between blue

and red to make it easy to read, whereas there is a lot of contrast between blue and white.

12. Align fields effectively.

When a screen has more than one editing field, you want to organize the fields in a way that is

both visually appealing and efficient. I have always found the best way to do so is to left-justify

edit fields: in other words, make the left-hand side of each edit field line up in a straight line, one

over the other. The corresponding labels should be right-justified and placed immediately beside

the field. This is a clean and efficient way to organize the fields on a screen.

13. Expect your users to make mistakes. How many times have you accidentally

deleted some text in one of your files or deleted the file itself? Were you able to recover from

these mistakes or were you forced to redo hours, or even days, of work? The reality is that to err

is human, so you should design your user interface to recover from mistakes made by your users.

14. Justify data appropriately.

For columns of data, common practice is to right-justify integers, decimal align floating-point

numbers, and to left-justify strings.

15. Your design should be intuitable.

In other words, if your users don’t know how to use your software, they should be able to

determine how to use it by making educated guesses. Even when the guesses are wrong, your

system should provide reasonable results from which your users can readily understand and

ideally learn.

16. Don’t create busy user interfaces.

Crowded screens are difficult to understand and, hence, are difficult to use. Experimental results

show that the overall density of the screen should not exceed 40 percent, whereas local density

within groupings should not exceed 62 percent.

17. Group things effectively.

Items that are logically connected should be grouped together on the screen to communicate they

are connected, whereas items that have nothing to do with each other should be separated. You

can use white space between collections of items to group them and/or you can put boxes around

them to accomplish the same thing.

Data Design

INTRODUCTION:

Persistent data and objects that have been derived during the Design is used to develop the

database. Storing data in a database enables the system to perform complex queries on a large data set.

Where and how the data is stored in the system impacts the system decomposition. The selection of a

specific data base management system can also have the implications on the overall control strategy

and concurrency management.

Entity Relationship Model: An Entity relationship model is a diagrammatic representation of

entities, attributes and the relationship among those entities and attributes.

Entity Type: Any thing in the real world that has the same characteristics or attributes can be

termed as an Entity. For example student can be called as an entity as they have the same

attributes such as roll number, name, address etc.

Attributes: The characteristics of an entity are called as attributes. Each entity will have its own

values for each attribute. For example the attributes for a student entity are roll number, name,

address etc. A Student entity such as Ravi will have its own values such as 1, Ravi,

Visakhapatnam etc.

Entity Set: The collection of entities of a particular entity type are grouped into an Entity Set. For

example if employee is the entity type then the collection of all the employees is referred as the

entity set.

Notations for ER-Diagram: In the ER diagrams the cardinality ration between the entity types can

be represented by attaching 1, M, or N on each participating edge. For example the cardinality

ratio of Department:Employee for manages is 1:1.

The different symbols used to represent the E-R diagram are

Rectangles: This symbol represents the each entity type.

Double Rectangle: This represent a Weak Entity.

Diamonds: These represent the relationship among the entities.

Double Diamonds: These represent the identifying relationship between the entities.

Ellipses: These represent the attributes of an entity.

Underlined Ellipse: These represent the key attributes of an entity.

Double Ellipse: These represent Multi valued attributes.

Dotted Ellipse: This represent Derived attribute.

Lines: Lines represent the connection between the attributes to their entities, and also entities

to entities.

Normalization

The process of analyzing the data to be represented and breaking it down into separate tables in

accordance with the principles of relational structure.

Need for Normalization

Normalization reduces redundancy. Redundancy is the unnecessary repetition of data. It can cause

problems with storage and retrieval of data redundancy can lead to inconsistence. Errors are more

likely to occur when facts are repeated. Update anomalies inserting, deleting, modifying data may

cause inconsistence. There is high likelihood of updating or deleting data in one relation, while

omitting to make corresponding changes in other relations.

During the process of normalization, we can identify dependence, which can cause problems when

deleting or updating. Normalization also helps to simplify the structure of tables to fully normalize

record, which should consist of a primary key that identifies that entity is a set of attributes that

describes the entity.

Normal Forms

Normalization results in the formation of tables that satisfy certain specified constraints and represent

certain normal forms. Normal forms are table structures with minimum redundancy.

First Normal Form

A relation R is in first normal form if and only if all underlying domains contain atomic values only.

Second Normal Form

A relation R is in the second normal form if and only if its is in 1st NF and every non – key attributes

is fully dependent on the primary key.

Third Normal Form

A relation R is in Third Normal form if and only if it is in SNF and every non-key attributes is not

transitively dependent on the primary key.

Fourth Normal Form

A relation R is in fourth normal form if and only if whenever there exist a multi-valued dependency is

R, say A>>B, then attributes on other attribute is a determinant.

Boyce-codd Normal Form

A relation is in Boyce-codd normal form (BCNF) if and only if every determinant is a candidate key.

An attribute is fully dependent on other attribute is a determinant.

Fifth Normal Form

A relation is in fifth normal form also called project-join normal form(PJNF) if and only if the

candidate keys of R imply every join dependency in R.

DATA DICTIONARY

After applying 1st , 2nd, and 3rd Normal form on the above relations we are able to derive the

following tables.

Login Table:

create table login(username varchar2(20), password varchar2(20));

insert into login values('admin','admin');

----------------------------------------------------------------------

Customers Table:

create table customers

(

cid number(5) primary key,

cname varchar2(50),

password varchar2(50),

address varchar2(50),

name varchar2(50),

emailid varchar2(50),

phoneno varchar2(50)

);

create sequence cidseq start with 1 increment by 1;

create or replace trigger cidinsert

before insert on customers

for each row

begin

select cidseq.nextval into :new.cid from dual;

end;

/

----------------------------------------------------------------------

Products Table:

create table products

(

pcode varchar2(50),

pname varchar2(50),

company varchar2(50),

qpack varchar2(50),

unit varchar2(50),

dprice varchar2(50),

price varchar2(50)

);

----------------------------------------------------------------------

create table vehicles

(

vno varchar2(50),

model varchar2(50),

year varchar2(50)

);

----------------------------------------------------------------------

create table orders

(

oid number(5) primary key,

cid varchar2(50),

pcode varchar2(50),

odate varchar2(50),

qty varchar2(50)

);

create sequence oidseq start with 1 increment by 1;

create or replace trigger oidinsert

before insert on orders

for each row

begin

select oidseq.nextval into :new.oid from dual;

end;

/

----------------------------------------------------------------------

create table trips

(

tid number(5) primary key,

oid varchar2(50),

vno varchar2(50),

tdate varchar2(50),

status varchar2(50)

);

create sequence tidseq start with 1 increment by 1;

create or replace trigger tidinsert

before insert on trips

for each row

begin

select tidseq.nextval into :new.tid from dual;

end;

/

Software Technology

Technologies Used

HTML

Hypertext Markup Language (HTML), the languages of the World Wide Web (WWW), allows users

to produces Web pages that include text, graphics and pointer to other Web pages (Hyperlinks).

HTML is not a programming language but it is an application of ISO Standard 8879, SGML (Standard

Generalized Markup Language), but specialized to hypertext and adapted to the Web. The idea behind

Hypertext is that instead of reading text in rigid linear structure, we can easily jump from one point to

another point.

Basic HTML Tags:

<! -- --> specifies comments

<A>……….</A> Creates hypertext links

<B>……….</B> Formats text as bold

<BIG>……….</BIG> Formats text in large font.

<BODY>…</BODY> Contains all tags and text in the HTML document

<CENTER>...</CENTER> Creates text

<DD>…</DD> Definition of a term

<DL>...</DL> Creates definition list

<FONT>…</FONT> Formats text with a particular font

<FORM>...</FORM> Encloses a fill-out form

<FRAME>...</FRAME> Defines a particular frame in a set of frames

<H#>…</H#> Creates headings of different levels( 1 – 6 )

<HEAD>...</HEAD> Contains tags that specify information about a document

<HR>...</HR> Creates a horizontal rule

<HTML>…</HTML> Contains all other HTML tags

<META>...</META> Provides meta-information about a document

<SCRIPT>…</SCRIPT> Contains client-side or server-side script

<TABLE>…</TABLE> Creates a table

<TD>…</TD> Indicates table data in a table

<TR>…</TR> Designates a table row

<TH>…</TH> Creates a heading in a table

JavaScript

JavaScript is a script-based programming language that was developed by Netscape Communication

Corporation. JavaScript was originally called Live Script and renamed as JavaScript to indicate its

relationship with Java. JavaScript supports the development of both client and server components of

Web-based applications. On the client side, it can be used to write programs that are executed by a

Web browser within the context of a Web page. On the server side, it can be used to write Web server

programs that can process information submitted by a Web browser and then update the browser’s

display accordingly

Even though JavaScript supports both client and server Web programming, we prefer JavaScript at

Client side programming since most of the browsers supports it. JavaScript is almost as easy to learn

as HTML, and JavaScript statements can be included in HTML documents by enclosing the

statements between a pair of scripting tags

<SCRIPTS>.. </SCRIPT>.

<SCRIPT LANGUAGE = “JavaScript”>

JavaScript statements

</SCRIPT>

Here are a few things we can do with JavaScript:

Validate the contents of a form and make calculations.

Add scrolling or changing messages to the Browser’s status line.

Animate images or rotate images that change when we move the mouse over them.

Detect the browser in use and display different content for different browsers.

Detect installed plug-ins and notify the user if a plug-in is required.

We can do much more with JavaScript, including creating entire application.

Java Technology

Initially the language was called as “oak” but it was renamed as “Java” in 1995. The primary

motivation of this language was the need for a platform-independent (i.e., architecture neutral)

language that could be used to create software to be embedded in various consumer electronic

devices.

Java is a programmer’s language.

Java is cohesive and consistent.

Except for those constraints imposed by the Internet environment, Java gives the

programmer, full control.

Finally, Java is to Internet programming where C was to system programming.

Features of Java

Portability

For programs to be dynamically downloaded to all the various types of platforms connected to the

Internet, some means of generating portable executable code is needed.

The Byte code

The key that allows the Java to solve the security and portability problems is that the output of

Java compiler is Byte code. Byte code is a highly optimized set of instructions designed to be

executed by the Java run-time system, which is called the Java Virtual Machine (JVM). That is,

in its standard form, the JVM is an interpreter for byte code.

Compiling and interpreting Java Source Code

During run-time the Java interpreter tricks the byte code file into thinking that it is running on a

Java Virtual Machine. In reality this could be a Intel Pentium Windows 95 or SunSARC station

running Solaris or Apple Macintosh running system and all could receive code from any

computer through Internet and run the Applets.

Simple

Java was designed to be easy for the Professional programmer to learn and to use effectively. If

you are an experienced C++ programmer, learning Java will be even easier. Because Java inherits

the C/C++ syntax and many of the object oriented features of C++. Most of the confusing

concepts from C++ are either left out of Java or implemented in a cleaner, more approachable

manner. In Java there are a small number of clearly defined ways to accomplish a given task.

Object-Oriented

Java was not designed to be source-code compatible with any other language. This allowed the

Java team the freedom to design with a blank slate. One outcome of this was a clean usable,

pragmatic approach to objects. The object model in Java is simple and easy to extend, while

simple types, such as integers, are kept as high-performance non-objects.

Robust

The multi-platform environment of the Web places extraordinary demands on a program, because

the program must execute reliably in a variety of systems. The ability to create robust programs

was given a high priority in the design of Java. Java is strictly typed language; it checks your

code at compile time and run time.

Java virtually eliminates the problems of memory management and de-allocation, which is

completely automatic. In a well-written Java program, all run time errors can –and should –be

managed by your program.

Java Database Connectivity

What Is JDBC?

JDBC is a Java API for executing SQL statements. (As a point of interest, JDBC is a trademarked

name and is not an acronym; nevertheless, JDBC is often thought of as standing for Java

Database Connectivity. It consists of a set of classes and interfaces written in the Java

programming language. JDBC provides a standard API for tool/database developers and makes it

possible to write database applications using a pure Java API.

Using JDBC, it is easy to send SQL statements to virtually any relational database. One can write

a single program using the JDBC API, and the program will be able to send SQL statements to

the appropriate database. The combinations of Java and JDBC lets a programmer write it once

and run it anywhere.

What Does JDBC Do?

Simply put, JDBC makes it possible to do three things:

Establish a connection with a database

Send SQL statements

Process the results.

JAVA

Application

JDBC

DBMS

Client machine

DBMS-proprietary protocol

Database

server

Java applet or

Html browser

ApplicationServer (Java)

JDBC

DBMS

Client machine (GUI)

HTTP, RMI, or CORBA

calls

Server machine (business

Logic)DBMS-proprietary

protocolDatabase server

Testing

A test plan is a document detailing a systematic approach to testing a system such as a machine or

software. The plan typically contains a detailed understanding of what the eventual workflow will be.

A test plan documents the strategy that will be used to verify and ensure that a product or system

meets its design specifications and other requirements. A test plan is usually prepared by or with

significant input from Test Engineers.

Depending on the product and the responsibility of the organization to which the test plan applies, a

test plan may include one or more of the following:

* Design Verification or Compliance test - to be performed during the development or approval

stages of the product, typically on a small sample of units.

* Manufacturing or Production test - to be performed during preparation or assembly of the product

in an ongoing manner for purposes of performance verification and quality control.

* Acceptance or Commissioning test - to be performed at the time of delivery or installation of the

product.

* Service and Repair test - to be performed as required over the service life of the product.

* Regression test - to be performed on an existing operational product, to verify that existing

functionality didn't get broken when other aspects of the environment are changed (e.g., upgrading the

platform on which an existing application runs).

Test Strategies

A test strategy is an outline that describes the testing portion of the software development cycle. It is

created to inform project managers, testers, and developers about some key issues of the testing

process. This includes the testing objective, methods of testing new functions, total time and resources

required for the project, and the testing environment.

The test strategy describes how the product risks of the stakeholders are mitigated at the test-level,

which types of test are to be performed, and which entry and exit criteria apply.

The test strategy is created based on development design documents. The system design document is

the main one used and occasionally, the conceptual design document can be referred to. The design

documents describe the functionalities of the software to be enabled in the upcoming release. For

every set of development design, a corresponding test strategy should be created to test the new

feature sets.

Test Levels

The test strategy describes the test level to be performed. There are primarily three levels of testing:

unit testing, integration testing, and system testing. In most software development organizations, the

developers are responsible for unit testing. Individual testers or test teams are responsible for

integration and system testing.

Functional Testing

Functional testing is a type of black box testing that bases its test cases on the specifications of the

software component under test. Functions are tested by feeding them input and examining the output,

and internal program structure is rarely considered.[1]

Functional testing differs from system testing in that functional testing "verif[ies] a program by

checking it against ... design document(s) or specification(s)", while system testing "validate[s] a

program by checking it against the published user or system requirements

Functional testing typically involves five steps[citation needed]:

1. The identification of functions that the software is expected to perform

2. The creation of input data based on the function's specifications

3. The determination of output based on the function's specifications

4. The execution of the test case

5. The comparison of actual and expected outputs

Test Cases

A test case is a set of input data and expected results that exercises a component with the purpose of

causing failures and detecting faults. A test case has five attributes: name, location, input, oracle, and

log. The name of the test case allows the tester to distinguish between different test cases. A heuristic

for naming test cases is to derive the name from the requirement it is testing or from the component

being tested. The location attribute describes where the test case can be found. It should be either the

pathname or the URL to the executable of the test program and its inputs.

Input describes the set of input data or commands to be entered by the actor of the test case. The

expected behavior is described by the oracle attribute. The log is set of time-stamped correlations of

the observed behavior with the expected behavior for various test runs.

Sample Code

Code to Add Customer details

<%@page import="java.sql.*,bean.ProjectBean" %>

<%

String cname=request.getParameter("cname");

String name=request.getParameter("name");

String password=request.getParameter("password");

String address=request.getParameter("address");

String emailid=request.getParameter("emailid");

String phoneno=request.getParameter("phoneno");

Connection con=null;

ResultSet rs=null;

ProjectBean CBean=new ProjectBean();

con=CBean.getConnection();

String sql="insert into customers(cname,name,password,address,emailid,phoneno) values

('"+cname+"','"+name+"','"+password+"','"+address+"','"+emailid+"','"+phoneno+"')";

int i=CBean.executeUpdate(sql);

%>

Code to post Order Details

<%@page import="java.sql.*,bean.ProjectBean" %>

<%

String cid=request.getParameter("cid");

String pcode=request.getParameter("pcode");

String odate=request.getParameter("odate");

String qty=request.getParameter("qty");

Connection con=null;

ResultSet rs=null;

ProjectBean CBean=new ProjectBean();

con=CBean.getConnection();

String sql="insert into orders(cid,pcode,odate,qty) values

('"+cid+"','"+pcode+"','"+odate+"','"+qty+"')";

int i=CBean.executeUpdate(sql);

%>

Code to Update Vehicle details

<%@page import="java.sql.*,bean.ProjectBean" %>

<%

String vno=request.getParameter("vno");

String model=request.getParameter("model");

String year=request.getParameter("year");

Connection con=null;

ProjectBean CBean=new ProjectBean();

con=CBean.getConnection();

String sql="update vehicles set model='"+model+"',year='"+year+"' where vno='"+vno+"'";

int i=CBean.executeUpdate(sql);

%>

Code to generate Invoice report

<%@page import="java.sql.*,bean.ProjectBean,java.util.Calendar,java.text.SimpleDateFormat" %>

<%

String name,pcode,qty;

String pname,qpack,dprice,price,unit;

int intprice,intqty,intdprice;

int total=0;

int sum=0;

String cname=null;

String address=null;

String emailid=null;

String phoneno=null;

Calendar currentDate = Calendar.getInstance();

SimpleDateFormat formatter=

new SimpleDateFormat("dd/MM/yyyy");

String dateNow = formatter.format(currentDate.getTime());

String cid=request.getParameter("cid");

Connection con=null;

ResultSet rs=null;

ResultSet rs1=null;

ResultSet rs2=null;

ProjectBean CBean=new ProjectBean();

con=CBean.getConnection();

rs=CBean.executeQuery("select * from customers where cid='"+cid+"'");

if(rs.next())

{

cname=rs.getString(2);

name=rs.getString(3);

address=rs.getString(5);

emailid=rs.getString(6);

phoneno=rs.getString(7);

}

%>

INPUT & OUTPUT SCREENS

Software Development Life Cycle

The Systems Development Life Cycle (SDLC), or Software Development Life Cycle in

systems engineering, information systems and software engineering, is the process of

creating or altering systems, and the models and methodologies that people use to

develop these systems. The concept generally refers to computer or information systems.

In software engineering the SDLC concept underpins many kinds of software

development methodologies. These methodologies form the framework for planning and

controlling the creation of an information system[1]: the software development process.

Systems Development Life Cycle (SDLC) is a process used by a systems analyst to

develop an information system, including requirements, validation, training, and user

(stakeholder) ownership. Any SDLC should result in a high quality system that meets or

exceeds customer expectations, reaches completion within time and cost estimates, works

effectively and efficiently in the current and planned Information Technology

infrastructure, and is inexpensive to maintain and cost-effective to enhance.

Water fall model:

The waterfall model is a sequential design process, often used in software development

processes, in which progress is seen as flowing steadily downwards (like a waterfall)

through the phases of Conception, Initiation, Analysis, Design, Construction, Testing and

Maintenance.

Requirements Specifications

A Software Requirements Specification (SRS) - a requirements specification for a

software system - is a complete description of the behavior of a system to be developed.

It includes a set of use cases that describe all the interactions the users will have with the

software. Use cases are also known as functional requirements. In addition to use cases,

the SRS also contains non-functional (or supplementary) requirements. Non-functional

requirements are requirements which impose constraints on the design or implementation

(such as performance engineering requirements, quality standards, or design constraints).

Design

Software design is a process of problem-solving and planning for a software solution.

After the purpose and specifications of software are determined, software developers will

design or employ designers to develop a plan for a solution. It includes low-level

component and algorithm implementation issues as well as the architectural view.

Implementation

Computer programming (often shortened to programming or coding) is the process of

designing, writing, testing, debugging / troubleshooting, and maintaining the source code

of computer programs. This source code is written in a programming language. The

purpose of programming is to create a program that exhibits a certain desired behaviour.

The process of writing source code often requires expertise in many different subjects,

including knowledge of the application domain, specialized algorithms and formal logic.

Testing

Software testing is an investigation conducted to provide stakeholders with information

about the quality of the product or service under test.[1] Software testing also provides

an objective, independent view of the software to allow the business to appreciate and

understand the risks of software implementation. Test techniques include, but are not

limited to, the process of executing a program or application with the intent of finding

software bugs.

Software testing can also be stated as the process of validating and verifying that a

software program/application/product:

1. meets the business and technical requirements that guided its design and

development;

2. works as expected; and

3. can be implemented with the same characteristics.

Installation

Software deployment is all of the activities that make a software system available for use.

The general deployment process consists of several interrelated activities with possible

transitions between them. These activities can occur at the producer site or at the

consumer site or both. Because every software system is unique, the precise processes or

procedures within each activity can hardly be defined. Therefore, "deployment" should be

interpreted as a general process that has to be customized according to specific

requirements or characteristics. A brief description of each activity will be presented

later.

Maintenance

Software maintenance in software engineering is the modification of a software product

after delivery to correct faults, to improve performance or other attributes.[1]

A common perception of maintenance is that it is merely fixing bugs. However, studies

and surveys over the years have indicated that the majority, over 80%, of the maintenance

effort is used for non-corrective actions (Pigosky 1997). This perception is perpetuated

by users submitting problem reports that in reality are functionality enhancements to the

system.

Software maintenance and evolution of systems was first addressed by Meir M. Lehman

in 1969. Over a period of twenty years, his research led to the formulation of eight Laws

of Evolution (Lehman 1997). Key findings of his research include that maintenance is

really evolutionary developments and that maintenance decisions are aided by

understanding what happens to systems (and software) over time. Lehman demonstrated

that systems continue to evolve over time. As they evolve, they grow more complex

unless some action such as code refactoring is taken to reduce the complexity.

The key software maintenance issues are both managerial and technical. Key

management issues are: alignment with customer priorities, staffing, which organization

does maintenance, estimating costs. Key technical issues are: limited understanding,

impact analysis, testing, and maintainability measurement.

CONCLUSION

This project has been developed to maintain all the details regarding the maintenance of

the products within the company. It records all the customer and order information, and also

keeps a record of the vehicles for delivery of the products to the customer.

The Project also generates an invoice report and as well as maintains the status of the

payment made.

The project has been tested at the clients machine and has been running successfully

without any defects.

Bibiliography

Bernd Bruegge & Allen H. Dutoit “Object Oriented Software Engineering – Using UML

Patterns” Pearson Education, 1995

Herbert Schidlt, “Java 2: The Complete Reference, Eighth Edition” Osborne Complete Reference

Series

http://www.ibm.com/developerworks/rational/library/content/RationalEdge/sep04/bell/

http://www.agilemodeling.com/artifacts/stateMachineDiagram.htm

http://www.modelmakertools.com/modelmaker/screenshots/page3.html