SDD Online Fleet Management

SOFTWARE DESIGN DESCRIPTION V.1.
0 201
3
PROJECT
Online Fleet Management

System SOFTWARE DESIGN DESCRIPTION
VERSION 1.0
Group: --- Supervisor:

Project Manager
Online Fleet Management System
SOFTWARE DESIGN DESCRIPTION V.1.0 201

3
TABLE OF CONTENTS
1. Introduction
1.1 Purpose
1.2 Scope
1.3 Definitions and Acronyms
1.4 References
2. Context Diagram
3. Document Overview
3.1 Project Overview
3.2 System Overview
3.3 System Architecture
3.4 Presentation
3.5 Quality Measures
4. Stakeholders
4.1 Project Team
4.2 Client
4.3 Users
5. System Overview
6. Technology
6.1 PHP vs. Java
6.2 MYSQL
6.3 CSS
7. Modules
7.1 Modules purpose and Functionalities
8. Use case Diagram

3
8.1 Use case description
9. Sequence Diagram
10.
Data Flow Diagrams
10.1 Admin
10.2 Login
10.3 Register
10.4 User login
11.
System Architecture
11.1 Multi Tyre Architecture

11.1.1
Client Tyre
11.1.2
Middle Tyre
11.1.3
Database layer
1. Introduction
1.1 Purpose

3
This Software Design Description document provides the design
description of Online Fleet Management System in the form of
object oriented analysis. This analysis will comprise of use case,
collaboration diagrams and prior to that the context level diagram
will show the working model of Online Fleet Management System
and the Data flow diagrams are included.
1.2
Scope
This document contains complete description of Online Fleet

Management System in the form of diagrammatic designs of object
oriented analysis. The basic architecture of the web site is done with
the help of PHP and java scripts on a Dreamweaver software
development tool. The supervisor of the project would be an in
charge of this document to make any necessary changes related to
the diagrammatic description and the contents of the index.
1.3
Definitions and Acronyms
2. NAME
DEFINITION
PM
Project Manager
SPMP
Software
Plan
SRS
Software
Specification
SDD
Software Design Description
ATMC
Australian Technical Management

College
UD
User Documentation
WBS
Work Breakdown Structure
QAM
Quality Assurance Manager
PHP
Hypertext Pre-Processor
HTML
Hypertext Mark-up Language
MYSQL
Simplified Query Language
Admin
Administrator
Project
Management
Requirements

3
DBA
Data Base Administrator
IEEE
Institute
of
Electrical
Electronic Engineers
TOM
Theory of Mind
SUMS
Student and Unit Management

System
DFD
Data Flow Diagram
and
1.4 References
Document
Software
Design
Description
Version
1.1,
December
82003 / .doc
SRS Sample.doc
SADD_v2.0.doc
Reference Description / Name

Michael
J.
Reaves,
Web
Accessible Alumni Database
TBBC, Testing TOM
AWARA Technologies
2. Context Diagram:

3
The context diagram highlights several important characteristics of the
system. It reflects the people of the organization or the system, with
which the system communicates and these are known as External entities.
The data that the system receives from the outside world and that must
be processed in some way. The data stored, is shared between the system
and the external entities. These data stores are either created outside the
system and used by the system, or created by the system and used
outside the system.
3. Document Overview

3
3.1
Project Overview:
This section is an overall look of the project. This section will explain the
position of this document in the entire project and all documents that refer
to this document. The contents of this section are brief as explanations
are already explained in related documents.
3.2 System Overview:
This section will explain about the overview of the final product and the
basis of major decisions.
3.3 System Architecture:
This section will explain the architectural specification of the solution. The
specification will include a comparison between technologies that will be
used, structure of the technology, how they will be used, logical steps on
how the solution will work, and structure of the database. This section will
show the detail of the overall idea of how the system will work.
3.4 Presentation:
This section will explain about the user interface of the final product. The
explanation will include a draft look of the user interface for each page.
The look will follow the idea that makes up the user interface and how this
presentation will suit the final product. The presentation is more
concentrated on how the user will interact with the system.
3.5 Quality Measures:
We have explained the quality of the final product in SRS. The standard
quality of the deliverables is already defined in the Quality attributes.
Quality attributes explained the quality of the final product and how the
quality is measured in terms of usability, maintainability and reliability.
4. Stakeholders
4.1 Project Team:
This document will be used as the reference for the final solution and the
design of the entire final deliverable. For more information about roles and
responsibilities, please refer to the SRS document of the website.

3
4.2 Client:
As the project develops, the client will need to provide feedback and
discuss their needs on a more regular basis. It is essential the client cooperates as much as possible with the project team in order to achieve a
successful completion.
4.3 Users:
Users are the people who will use this system and mainly divided into
admin, employees and client level of the institution.
5. System overview
Transport is an integral part of our social living. The modern society cannot run
without transport facilities. There are many companies who give transport
services to the individual and corporate clients. In the current system, the client
first contacts with the transport company for getting transport service. The
company then books the vehicle for him on the requested date and time and
then sends the vehicle to his place at the time. The Online taxi booking system is
the online service which will automate the process of booking a taxi and will
facilitate both the client and the company with reduced time and efforts. First the
company will register his vehicles and the vehicles to the system. Then the client
will request for booking a vehicle on his required date and time, providing all
necessary information. The fare will be calculated and client should confirm it.
Then the employee will serve the client on the specific date and time. Finally the
client will have an opportunity to give a feedback for the service he got. The
company can check it and take appropriate action for the future improvements.
This system will have 3 levels of login

Admin level usually perform the following tasks
1. Perform weekly roster of Employees.

3
2. Print reports annually, weekly, and daily.
3. Check feedbacks.
4. Send newsletters.
5. Manage user portfolio.
6. Changing the super password.
Employee level usually perform the following tasks

1. Check online bookings
2. Check their rosters.
3. Maintain daily logs.
4. Select availability.
Client level usually perform the following tasks

1. Make a booking.
2. Check their booking status.
3. Calculate the fare.
4. Check the driver history.

The GUI based system will be built based on the PHP that is able to be
executed in the IE 7 browser and additionally Firefox 2. The client will only
see the html page but PHP scripting will be used to interpret instructions
dynamically.
The first interface will be the welcome screen where the user level has the
ability to select a level of login in the system. Additionally, a form for
booking fleet will also be available for potential clients. Once the login is
selected, the user will be directed to a page that shows the tables and
sections that they have access to, based on their role. Admin is a special
role that is password protected and is for administrator use only.
Additionally, links to the help in registering new users will be provided in
the admin page so that users can get registered and view their records
from the website.
6. Technology
6.1 PHP vs. JAVA:

3
PHP and Java can both be considered server-programming languages that
can be the middle processing point between the user interface and the
database. Both languages are widely used to create Internet application(s)
and allow developers to create dynamic content that interacts with
databases. There are several advantages of using PHP over Java; thus we
have chosen PHP as the programming language to build the final product.
6.2 MYSQL:
MYSQL is a free relational database management system that is widely
used by organizations and individuals alike and is a subsidiary of Sun
Microsystems. With this wide use comes community support but also
continual development on improving the software and adding features.
The MYSQL database will store the competition data from competitor
details to section details, results, and more. This data can be retrieved
and updated as required by various roles. Access control and other
security can be implemented using database tables for flagging access for
the roles and their varying required access. MYSQL provides the ability to
backup this data to prevent data loss but also to import any other data
that may need to be loaded in at any stage.
6.3 CSS (Cascading Style Sheets):
A language used to describe how a web pages document is formatted.
CSS only focuses on the presentation of a document written in a mark-up
language commonly in HTML. CSS is also used for XML page formatting.
CSS consists of a pre-defined set of rules and the specification is
maintained by the W3C to create one standard.
7. Modules
The application has been divided into modules, to assist in development.
Each module is designed so that they can be written independently of
other modules. They may however be dependent on other modules to
complete each modules own task.
Admin
Login
Register
Employee
10

3
Client
Roster
Fleet Booking
Feedback
Edit / view contact details
7.1 Module purpose and functionalities:
Admin: Admin is the main person by which every user will be

employees and clients activities will be controlled.
Login: Login differs the types of login we have in our system

namely admin, employees and client. Its very important that
every registered user has to select their designated login
method to login into the website.
Register: Registering
admin. He will give
password to proceed
validations. On the
themselves using the
Employee: Employees are the person who will serve the

clients. They will be able to see the rosters and the bookings
and serve the client.
Client: The clients are the persons who will take the service of
the system to book a fleet online through the application.
They can see the available cars and book it according to it.
Roster: Rosters are the employment term for the employees

for a specific week. The admin should add roster for the
employees and the employees will be able to see it.
Fleet Booking: The bookings can be created by filling up the

booking form by the clients.
the employees will be in the hands of

the employees a user name / id and
further to create the details and further
other hand, the clients can register
registration form.
11

3
Feedback: The clients can give a feedback about the quality of

the service after he get the service.
8. USE CASE DIAGRAM
12

3
13

3
14

3
8.1 USE CASE DESCRIPTION: In a brief overview what the scenarios

and actor will do is given below in the description schema and every
case has been clearly explained in the Software Requirements
Description Document based on the functional requirements.
USE CASE NAME:
Name of use Case.
SCENARIO:
Scenario if multiple use cases with different

actors.
TRIGGERING
EVENT:
What starts this use case?
BRIEF
DESCRIPTION:
Describe the use case.
ACTORS:
Who is involved?
STAKEHOLDERS:
Who uses the information from the use case?
PRECONDITIONS:
What has to be true beforehand?
POSTCONDITIONS
What has to be done afterwards?
FLOW OF EVENTS:
EXCEPTION
ACTOR
SYSTEM
1. Flow of Events.
1.1. Flow of Events.
2. For the actor.
2.1. For the system.
2. If 2 is not true, use case ends

15

3
CONDITIONS:
9. SEQUENCE DIAGRAM:
16

3
17

3
10.
DATA FLOW DIAGRAM:
The purpose of this product is to share information from a centralized

server. The data will only flow from the user to the centralized server, but
the process can be categorized into level of users.
10.1 Admin:
18

3
10.2 Login:
10.3 Employee Register:

19

3
10.4 Client Register:
11.
SYSTEM DESIGN ARCHITECTURE:
This is an explicit listing of decisions made during a design process and

the reason why those decisions were made. This section will include the
reasons behind why a design decision was chosen and the justification for
it as well as other alternatives considered in the tradeoffs evaluation and
the rationale that led to the decision. The below sections explain the
decision that influences the design:
11.1 Multi-tier Architecture:
Multi-tier architecture is a client-server based architecture where the
application acts as a middleware to provide the architecture between the
user and the database. This means the user interface, functional process
logic, computer data storage and data access are maintained as
independent modules. The decision to use a multi-tiered architecture is
based on the capability to share data that can be accessed by a number
of users. A multi-tiered architecture is able to control and identify each
users access. By knowing the user access, the server will be able to
respond correctly and maintain data integrity. To support the multi-tiered
decision, from a technological point of view, the architecture allows
different languages to be used such as PHP for the client side, Scripting on
server processing and SQL for database. It also means, to a degree, that
different database servers and web servers can be used without changing
the user interface, or the user interface can be changed without altering
the database.
20

3
The server we have used is WMAP server in which Apache engine will work along
with PHP, MYSQL.
11.2 Client Tyre:

This layer allows the user to view, manipulate and update data to provide
simple control of the system. This layer represents all things that are
visible to the user, including screen layout and navigation. For our
application the user will view the final product through a web browser
which means the user will view PHP rendered code. The PHP will be
functioning in conjunction with CSS for presentation purposes.
11.3 Middle Tyre:
The middle-tier, also known as middleware or business logic of the
application, is the layer that is mission critical to the business problems
that will be solved. This component makes up the middle tier that will be
in the server to assist in resource sharing. For our application, the middletier will be J Query environment. The scripting code will run on a Java
application server, where the code is embedded and rendered into PHP
after processing according to the business rules. The middle-tier will
contain modules that will handle each function for each specific task like
validations.
11.4 Database Layer:
21

3
The Data-Storage layer will contain a database where all the data is
stored. It can be accessed and modified by the middle tier whose
instruction comes in the form of input from the client tier. For our
application, the database layer will be in the form of a MySQL database
sitting on the server.
22

SDD Online Fleet Management

Hochgeladen von

Dokumentinformationen

Originaltitel

Copyright

Verfügbare Formate

Dieses Dokument teilen

Dokument teilen oder einbetten

Freigabeoptionen

Stufen Sie dieses Dokument als nützlich ein?

Sind diese Inhalte unangemessen?

Copyright:

Verfügbare Formate

SDD Online Fleet Management

Hochgeladen von

Copyright:

Verfügbare Formate

SOFTWARE DESIGN DESCRIPTION V.1.

Online Fleet Management

Group: --- Supervisor:

Online Fleet Management System

SOFTWARE DESIGN DESCRIPTION V.1.0 201

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Data Flow Diagrams

11.1 Multi Tyre Architecture

SOFTWARE DESIGN DESCRIPTION V.1.0 201

This document contains complete description of Online Fleet

Definitions and Acronyms

Software Design Description

Australian Technical Management

Work Breakdown Structure

Quality Assurance Manager

Hypertext Mark-up Language

Simplified Query Language

Online Fleet Management System

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Data Base Administrator

Student and Unit Management

Data Flow Diagram

Reference Description / Name

SOFTWARE DESIGN DESCRIPTION V.1.0 201

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Online Fleet Management System

SOFTWARE DESIGN DESCRIPTION V.1.0 201

This system will have 3 levels of login

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Employee level usually perform the following tasks

Client level usually perform the following tasks

4. Check the driver history.

SOFTWARE DESIGN DESCRIPTION V.1.0 201

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Edit / view contact details

7.1 Module purpose and functionalities:

Admin: Admin is the main person by which every user will be

Login: Login differs the types of login we have in our system

Employee: Employees are the person who will serve the

Roster: Rosters are the employment term for the employees

Fleet Booking: The bookings can be created by filling up the

the employees will be in the hands of

Online Fleet Management System

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Feedback: The clients can give a feedback about the quality of

8. USE CASE DIAGRAM

Online Fleet Management System

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Online Fleet Management System

SOFTWARE DESIGN DESCRIPTION V.1.0 201

Online Fleet Management System

SOFTWARE DESIGN DESCRIPTION V.1.0 201

8.1 USE CASE DESCRIPTION: In a brief overview what the scenarios

USE CASE NAME:

Name of use Case.

Scenario if multiple use cases with different

What starts this use case?

Describe the use case.

Who uses the information from the use case?

What has to be true beforehand?

What has to be done afterwards?

1.1. Flow of Events.

2. For the actor.