WACHEMO UNIVERSITY

No loss or minimum loss, Privacy and Security of data is major concerned which can be achieved
by regular backup of database and by applying concept of OOPs (such as Encapsulation,
Abstraction and Inheritance).

CHAPTER THREE

[Link] ANALYSIS

1
3.1 USE CASE DIAGRAM
INTRODUCTION

A. The use case model for any system consists of a set of use cases.
B. The use cases represent the different ways in which a system can be used by the users.
C. The use cases correspond to the high-level functional requirements.
D. The use cases partition the system behavior into transactions, such that each transaction
performs some useful action from the user‟s point of view. Each transaction to complete, may
involve multiple message exchanges between the user and the system.
A simple way to find all the use cases of a system is to ask the question “What all can the user
do by using the system?”
REPRESENTATION OF USE CASES

b. A use case model is documented by drawing a use case diagram and writing an accompanying
text elaborating the drawing.
c. Use case diagram
d. Each use case is represented by an ellipse.
e. The name of the use case is written inside the ellipse.
f. The use cases should be named from the users‟ perspective.
g. All the ellipses (i.e. use cases) of a system are enclosed within a rectangle which represents the
system boundary.
h. The name of the system being modeled appears inside the rectangle.
i. Actor: An actor is a role played by a user with respect to the system use.

Actors are represented by using stick person icons.

6.1.1 TRAFFIC MANAGEMENT USE CASE DIAGRAM

As shown in the given (fig 6.1.1) use case diagram, Traffic Management has following
functionalities.

2
 Figure 6.1.1: Use Case Model of Traffic Management

3.2 TABLE STRUCTURE

Table structure transforms ER diagram into a table which is intersection of rows and columns.
Here each column is a depicted form of an attribute and entity into table name. Here database”
Traffic and management system” is used in which two table user, surveillance record.
USER

Field Type Null Key Default Extra

Username varchar(40) No NULL

Passwd varchar(20) No NULL

Table 6.2.1: User table

13

3
 SURVEILLANCE RECORD

Field Type Null Key Default Extra

date datetime NO PRI NULL

bike_with_helmet bigint(8) YES NULL

bike_without_helmet bigint(8) YES NULL

total_vehicle varchar(20) YES NULL

Table 6.2.2: Surveillance Record Table

3.4.1 DATA FLOW DIAGRAM (DFD)/ (UML):

Data flow diagrams (DFDs) reveal relationships among and between the various components in a
program or system. DFDs are an important technique for modeling a system’s high-level detail
by showing how input data is transformed to output results through a sequence of functional
transformations.

4
3.4.2 DFD:

A data flow diagram is a graphic representation of a system or part of system. It consist of

entities, data flows, process, sources, distinctions, and stores that Can facilitate the readability of
the system and also shows how data moves through an information system but doesn’t show
program logic or processing steps. A set of DFDs provides a logical model that shows what the
system does, not how it does it. Several different versions of DFDs exist, but they all serve the
same purpose. We will use to identify our DFDs levels in the following symbols:

Entity Data Store

Process
Data Flow

Figure 1: DFD Symbols

12

5
 Recorded

CAR ACCIDENT
Register car info
REGISTRATION RECORD

registered

Successfully recorded TRAFFIC Record the car’s accident

MANAGEMENT
Created
SYSTEM

Request record taxations

TAX
Create admin Create Admin

Figure 2: Context diagram level 0 d f ds

13
 Create Admin

Admin id password

username

Admindin--IDID UserNameserae Passwordassord

Created check

check
Process
ckeck

Yes THAN SAVE

Admin’s Database

Figure 3: Level 1 creating of admin user

14
 Car
Registeration Owner’s tell
Targo no
Owner’s name
Colour of the car
Car model
Car Name

T_NO Tellell

C_NAM
Registered Ownerer
E MODELL CAR Clourlr
Nameae

Check

Check Check
Check Check
YES THAN
Chek Process SAVE

Car registration database

SAVED

Figure 4: Level 2 car registration

15
 Accident record
Accident’s date
Targo no
Punishment
Accident type
Driver Name
T_NO

Recorded
D_NAME Punishmentiset
ACC_TYPE
DATE Check

Check

Check
Check
YES THAN
Chek Process SAVE

Accident record database

Recorded

Figure 5: Level 3 recording accidents

16
 TAX
Trismitale/license/book

Amount
Owner name
Driver Name

Successfully record the tax

D_NAME Ownerer nameae Amountt Purposerse

Check
Check

Check
Check
YES THAN
Process SAVE

Taxation record database

Recorded

Figure 6: Level 4 taxation

17
3.5.1 UML

The Sequence Diagram is a UML diagrams that are used to model interaction between objects of a
system, showing time sequence of collaboration (IBM, 2004). The diagram presents processes and
their operations with one another, in the order in which the operations occur. The diagram shows
objects and classes that participate in the collaboration as well as the arrangement of messages
exchanged between objects. A Sequence diagram has lifelines – which are parallel vertical lines, the
objects and horizontal arrows that show the messages exchanged.

The UML is a tool for specifying software systems. Standardized diagram types to help you describe
and visually map a software system's design and structure. Using UML it is possible to model just
about any kind of application, both specifically and independently of a target platform.

The use of UML as a tool for defining the structure of a system is a very useful way to manage large,
complex systems. Having a clearly visible structure makes it easy to introduce new people to an
existing project.

3.23 ER DIAGRAM
The entity Relationship Diagram (ERD) depicts the relationship between the data objects.

a. The ERD is the notation that is used to conduct the date modeling activity the attributes
of each data
b. Object noted is the ERD can be described resign a data object descriptions.
c. The set of primary components that are identified by the ERD are
d. Data object
e. Relationships
f. Attributes
g. Various types of indicators.

The primary purpose of the ERD is to represent data objects and their relationships.

14
Figure 6.3.1: ER Diagram
 CHAPTER FOUR

SYSTEM DESIGN

4.1 INTRODUCTION

Design is the most important phase of software development. It requires a careful planning
thinking on parts of the system designer. This phase frequently described as being divided into
two main phases, which might be described as "business design" and "technical design".

Business design generally specifies the "why" of the system, indicating how data will be used
and how it will flow. Technical design generally specifies the "how" of the system, or how its
components will be arranged, what their features will be, and what kind of hardware the system
will require.

Designing a software means to plan how various party of the software are going to achieve the
desired goal, it should be done with at most care because if the phase contains any error, then
that will affect the performance of the system.

4.2 DESIGN GOALS

There are many aspects to consider in the design of an every project. The importance of each
should reflect the goals the system is trying to achieve. Some of these aspects are: A. Efficiency
– It is generally considered to be the most important. Given a piece of hardware on which the
system will run and a piece of software to run it, the design should make full and efficient use of
the facilities provided. The users should interact with the system without any delay.

B. Integrity - this means that the system should be accurate as possible. The problem of
preserving the integrity of data can be viewed at a number of levels

C. Extensibility - New capabilities can be added to the system without major changes to the
underlying architecture.

D. Reliability - The system is able to perform a required function under stated conditions for a
specified period of time.
E. Security – The system, once loaded, should be safe from physical corruption whether from
hardware or software failure or from unauthorized access.

4.3 DATABASE DESIGN

Designing a Database Like most tasks, building a database starts with a design. Having a good
design for your database is a major first step in creating a successful project.
In designing a database application, you must set up not only the program’s routines for

maximum performance, but you must pay attention also to the physical and logical layout of the
data storage. A good database design does the following:

a. Provides minimum search times when locating specific records.

b. Stores data in the most efficient manner possible to keep the database from growing too
large.
c. Makes data updates as easy as possible.
d. Is flexible enough to allow inclusion of new functions required of the program.
When you’re creating the design for your database, you must keep several objectives in

mind although meeting all these design objectives is desirable, sometimes they are mutually
exclusive.
The primary design objectives are as follows:

a. Eliminate redundant data

b. Be able to locate individual records quickly
c. Make enhancements to the database easy to implement
d. Keep the database easy to maintain
Creating a good database design involves the following seven key activities:

a. Modeling the application

b. Determining the data required for the application
c. Organizing the data into tables
d. Establishing the relationships between tables

e. Setting index and validation requirements for the data

f. Creating and storing any necessary queries for the application
g. Reviewing the design
4.4 ENTITY RELATIONSHIP DIAGRAM

ERD is a detailed, logical representation of the entities, associations and data elements for an
organization or business. ERD is a graphical modeling tool to standardize ER modeling; the
modeling can be carried out with the help of pictorial representation of entities, attributes and
relationships.

The basic building blocks of ERD are Entity, Attributes, Relationship and lines entity is an
object that exists and is distinguishable from other object in other words.

The building blocks of an entity relationship diagram in Key terms:

A. Entity: an entity is an object that exist and distinguishable from other objects a person,
place object event or concept in the user environment about which the organization wishes
to maintain.
B. Entity Type: a collection of entities that share common properties or characteristics

C. Attributes: A named property or characteristic of an entity that is of interest to an

organization
D. Relationship: is an association of entities where that association includes one entity from
each participating entity type where relationship type is a meaningful association between
entity types.
4.4.1 De-normalization of entity relational diagram
The word ‘de-normalization’ is used to describe changes to the table design that cause the
physical tables to differ from the normalized entity relationship diagram.

4.4.2 Normalization

Database Normalization, or simply normalization, is the process of organizing the columns

(attributes) and tables (relations) of a relational database to reduce data redundancy and improve
data integrity. Normalization is also the process of simplifying the design of a database so that it
achieves the optimum structure. It reduces and
eliminates redundant data. In normalization, data integrity is assured. It was first proposed by Dr.
Edgar F. Codd, as an integral part of a relational model.

Purpose of normalization

a. To avoid redundancy by sorting each fact within the database only once
b. To put data into the form that is more able to accurately accommodate change
c. To avoid certain updating "anomalies"
 d. To facilitate the enforcement of data constraint
e. To avoid unnecessary coding.

Most popular Normalization stages include:

a. First Normal Form (1st NF)

First Normal Form: is a relational table, by definition, is in first normal form. All values
of the columns are atomic. That is, they contain no repeating values.
nd
b. Second Normal Form (2 NF)
Second Normal Form: The definition of second normal form states that only tables with
composite primary keys can be in 1NF but not in 2NF. A relational table is in second
normal form 2NF if it is in 1NF and every non-key column is fully dependent upon the
primary key.
c. Third Normal Form (3rd NF)
Third Normal Form: The third normal form requires that all columns in a relational

table are dependent only upon the primary key. A more formal definition is: A relational
table is in third normal form (3NF) if it is already in 2NF and every non-key column is
none transitively dependent upon its primary key. In other words, all non-key attributes
are functionally dependent only upon the primary key.
Targo No Car Name Car Model Car Color Owner Name Tell
AG0001 Harrier Last Model White Abdinasir Mohamed 0618569422
AG0002 Ferrari Ferrari GTS White Mowlid Mohamud 0615266151
AG0004 Lloyd 650 Black Mohamed Salad Hirse 0615110220
st
Table 5: 1 Normal Form

ID Targo No Car Name Car Model Car Color Owner Name Tell
2 AG0001 Harrier Last Model White Abdinasir Mohamed 0618569422
3 AG0002 Ferrari Ferrari GTS White Mowlid Mohamud 0615266151
4 AG0004 Lloyd 650 Black Mohamed Salad Hirse 0615110220
nd
Table 6: 2 Normal Form

ID Targo No Owner Name

2 AG0001 Abdinasir Mohamed
3 AG0002 Mowlid Mohamud
4 AG0004 Mohamed Salad Hirse
rd
Table 7: 3 Normal Form

4.5 DATA DICTIONARY

Data dictionary, or data repository, is central store house of information about System’s

data. We will use it to collect, document, and organize specific facts about system include the data
flows, data stores, external entities, and processes. The data dictionary also defines and describes all
data elements and meaningful combinations of data elements.

4.6 TABLE DESIGN

Table- A set of data arranged in rows and columns. Field- Each

space that holds a single piece of information

Record- Is composed of fields, each of which contains one item of information

Column Type Null

Username Varchar(22) No

Password varchar(33) No

Table 8: Admin

Column Type Null

ID int(55) No

Targo_No varchar(55) No

Car_Name varchar(77) No

Model Varchar(66) No

Car_colour Varchar(88) No

OwnerName Varchar(55) No

Tell Int(88) No

Table 9: car registration

Column Type Null

ID int(22) No

Targo_No varchar(55) No

Driver_Name varchar(88) No

Accident_Type Varchar(88) No

Punishment Varchar(99) No

Date date No

Table 10: Accident record

Column Type Null

ID int(33) No

ownerName varchar(55) No

DriverName varchar(44) No

Amount float No

Purpose Varchar(66) No

Table 11: Taxation record

4.7 FORM DESIGN

Form design is where the developer of the system is deeply explains this system and how forms
of the system are working together by observing the sequential flows, In the design we will talk
the main pages and the operator will use these forms, including textboxes and dropdowns. The
page design will be consist of the following forms:
Admin form, Car Registration form, Accident Record form, Event form, Tax record form and
Contact us form.
Admin form:

The Admin form is a form, which administrator use this system can login at the first time. In the
login page there is two labels which is intended (indicated) the administrator’s name password,
also this form has a text Field which administration can write his/her username and password
respectively .
Figure12: Admin Form

Figure 13: Car registration

Figure 14: Accident record

Figure 15: Tax record

Figure 16: event

4.8 REPORT DESIGN:

The most effective method of online data entry is a form filling, in which a blank form that duplicates or resembles
the source document is completed on the [Link] user en ters: the data and then moves to the next field. The
form can have many control features such as Menu bars, toolbars, dialog boxes, text boxes, command buttons, list
boxes, scroll bars drop-down, group boxes, check boxes, and more others.

23
 CHAPTER 5

Implementation and Testing

5.1 INTRODUCTION
Testing is the process of detecting errors. Testing performs a very critical role for quality assurance and for
ensuring the reliability of software. The results of testing are used later on during maintenance also.

5.2 PSYCHOLOGY OF TESTING

The aim of testing is often to demonstrate that a program works by showing that it has no errors. The basic purpose
of testing phase is to detect the errors that may be present in the program. Hence one should not start testing with
the intent of showing that a program works, but the intent should be to show that a program doesn‟t work. Testing
is the process of executing a program with the intent of finding errors.

5.3 TESTING OBJECTIVES

The main objective of testing is to uncover a host of errors, systematically and with minimum effort and time.
Stating formally, we can say,
3 Testing is a process of executing a program with the intent of finding an error.
3 A successful test is one that uncovers an as yet undiscovered error.
3 A good test case is one that has a high probability of finding error, if it exists.
3 The tests are inadequate to detect possibly present errors.
3 The software more or less confirms to the quality and reliable standards.

5.4 LEVELS OF TESTING

In order to uncover the errors present in different phases we have the concept of levels of testing.
The basic levels of testing are as shown below.

Acceptance
24
 Testing
Client Needs

System Testing

Integration Testing

Unit Testing

5.4.1 SYSTEM TESTING:

The philosophy behind testing is to find errors. Test cases are devised with this in mind. A strategy
employed for system testing is code testing.

5.4.2 CODE TESTING:

This strategy examines the logic of the program. To follow this method, we developed some test data that resulted
in executing every instruction in the program and module i.e. every path is tested. Systems are not designed as
entire nor are they tested as single systems. To ensure that the coding is perfect two types of testing is performed
or for that matter is performed or that matter is performed or for that matter is performed on all systems.

5.4.3 UNIT TESTING

Unit testing focuses verification effort on the smallest unit of software i.e. the module. Using the detailed design
and the process specifications testing is done to uncover errors within the boundary of the module. All modules
must be successful in the unit test before the start of the integration testing begins.
In this project each service can be thought of a module. There are so many modules like Login, HW Admin, Master
Admin, Normal User, and Manager. Giving different sets of inputs has tested each module. When developing the
module as well as finishing the development so that each module works without any error. The inputs are validated
when accepting from the user. In this application developer tests the programs up as system. Software units in a system
are the modules and routines that are assembled and integrated to form a specific function. Unit testing

25
is first done on modules, independent of one another to locate errors. This enables to detect errors. Through this
error resulting from interaction between modules initially avoided.

5.4.4 LINK TESTING

Link testing does not test software but rather the integration of each module in system. The primary concern is
the compatibility of each module. The Programmer tests where modules are designed with different parameters,
length, type etc.

5.4.5 INTEGRATION TESTING

After the unit testing we have to perform integration testing. The goal here is to see if modules can be integrated
properly, the emphasis being on testing interfaces between modules. This testing activity can be considered as
testing the design and hence the emphasis on testing module interactions.
In this project integrating all the modules forms the main system. When integrating all the modules I have checked
whether the integration effects working of any of the services by giving different combinations of inputs with which the
two services run perfectly before Integration.

5.4.6 SYSTEM TESTING

Here the entire software system is tested. The reference document for this process is the requirements
document, and the goal us to see if software meets its requirements.

5.4.7 ACCEPTANCE TESTING

Acceptance Test is performed with realistic data of the client to demonstrate that the software is working
satisfactorily. Testing here is focused on external behavior of the system; the internal logic of program is not
emphasized.
In this project „Network Management of Database System‟ I have collected some data and tested whether project
is working correctly or not.
Test cases should be selected so that the largest number of attributes of an equivalence class is exercised at once.
The testing phase is an important part of software development. It is the process of finding errors and missing
operations and also a complete verification to determine whether the objectives are met and the user requirements
are satisfied.

26
5.4.8 WHITE BOX TESTING

This is a unit testing method where a unit will be taken at a time and tested thoroughly at a statement level to find
the maximum possible errors. I tested step wise every piece of code, taking care that every statement in the code is
executed at least once. The white box testing is also called Glass Box Testing.
I have generated a list of test cases, sample data which is used to check all possible combinations of execution paths
through the code at every module level.

5.4.9 BLACK BOX TESTING

This testing method considers a module as a single unit and checks the unit at interface and communication with
other modules rather getting into details at statement level. Here the module will be treated as a block box that will
take some input and generate output. Output for a given set of input combinations are forwarded to other modules .

5.5 CRITERIA SATISFIED BY TEST CASES

Test cases that reduced by a count that is greater than one, the number of additional test cases that much be
designed to achieve reasonable testing.
Test cases that tell us something about the presence or absence of classes of errors, rather than an error associated
only with the specific test at hand.

27
 CHAPTER SIX

CONCLUSION

RECOMMENDATION & CONCLUSION

6.1 INTRODUCTION

This chapter includes the works that have been done during the previous documentations of this project. In addition, this
chapter was recover the objectives of the project and illustrates how the work of this project meets the project’s
objectives. Also, it discusses the experiences that have been gained during this project and it includes the future
recommendation which capture how to extend this project in the future.

6.2 CONCLUSION

In this book, we discussed about how our system is working; we also provided some guidelines of how the user will deal
to this system and what strengths or weakness it has.

Strengths

Every project has some strengths and weakness; so, we would like to mention some of the strengths and good
features that Traffic Management System will provide to the industrial educations.

This system is very friendly system and it has a good interface that can be usable by every person who is computer
literate.

What is more, if the user make a mistake it generate an error message that easily understandable by the user and it
gives you the solution of that problem.
Weaknesses

On the other hand, every system has its own weaknesses, so, In this project, only problems that you might face is
alerting messages that appear whenever you misuse to the system, and if you are not familiar with this system you
might find it difficult to
manage it, please don’t confuse, just read carefully what the message is carrying out and then you will get the
solution easily.

Achievement of the Project Objective

28
The main objective for this project is to develop an Online Traffic Management System for the Ministry of
Transportation in Somalia.
Moreover, here are the details of the project objectives that have been achieved:

a. To design an Online Traffic Management System for the Ministry of Transportation in Somalia.
j. To develop the proposed system and test it.

All the objectives stated above have been achieved and the requirements of the users have been met through the
project
A. Limitations
During the process of developing this project, some difficulties and constraints were faced. Some of these
difficulties are related to the writing of the report and others are related to the implementation and design.
The most important challenges faced are highlighted as follows:
a. Writing the code of the project was the difficult challenged to face.
b. Difficulties were faced during design the project of the project, such as normalization and etc.
c. Difficulties were faced during design the project of the project, such as normalization and etc.
d. Following JOBKEY thesis format was one of the most difficult tasks to encounter during the documentation of
the report.
e. Lack of time was also one of the challenges faced during the implementation of the system.
B. Future Enhancement

It has been achieved the final phase development of Online Traffic Management System and it is like any other
system. It needs improvements and maintenance.

29
REFERENCES:

Alam, J.B., Jaigirdar, M. A. and Rahman, M.H. (1999). Analysis of Behavioral Value of Travel Attributes and
Their Implications on Urban Transport Policies, Journal of Civil Engineering, I.E.B., Vol. CE 27, No. 1, 1999.

Arumala, J. O. And Akpokodje, E. G., 1987. Soil Properties and Pavement Performance in the Niger Delta.
Quarterly Journal of Engineering Geology and Hydrogeology, Vol. 20, pp. 287-296.

Bailey, L., Mokhtarian, P. L., Little, A. (2008). The Broader Connection between Public Transportation, Energy
Conservation and Greenhouse Gas Reduction. Report prepared as part of TCRP Project J-11/ Task 3 Transit
Cooperative Research Program, Transportation Research Board submitted to American Public Transportation
Association in [Link] accessed 17 April 2008.

Bartone, E; Branstein, J; Eigen, J. (1994). Urban Management Program toward Environmental Strategies for Cities,
World Bank Technical Report.

Ewing, R. and Cervero, R. (2001). Travel and the Built Environment: A Synthesis.
Transportation Research Record 1780, Washington, D.C: TRB, National Research Council.

Goldberg, M. A. (1970). Transportation, Urban Land Values, and Rents: A Synthesis Land Economics, 46, 2
(May), 153-162.

Mannering, Fred L.; Walter P. Kilareski; Scott S. Washburn (2004). Principles of Highway Engineering and Traffic
Analysis. 3rd ed. NJ: John Wiley & Sons; 170 – 219.

Owen, W., 1964. Strategy for Mobility. The Brooking Institute, Transport Research Program, Washington D.C.,
249p.

Oyesiku, O. O. (2002). From Womb to Tomb. 24th Inaugural Lecture at Olabisi Onabanjo University on 27 August
2002. Ago-Iwoye: Olabisi Onabanjo University Press. 26

Polzin, S. E. (2004). Relationship between Land Use, Urban Form and Vehicle Miles of Travel: The State Of
Knowledge and Implications for Transportation Planning. University of South Florida, Tampa; Florida Department of
Transportation; Federal Highway
Administration in [Link] pubs/Trans-LU%20White%20Paper%[Link]

30
Queiroz, C and Gautam, S., 1992. Road Infrastructure and Economic Development: Some Diagnostic Indicators. Policy
Research Working paper Series 921, The World Bank 37p.

Said, M. N. and Shah, M. Z. (2008). GIS as a Supporting Tool in The Establishment of Land Use- Road Density
Model in [Link].

World Bank, 1996. Expanding Labor-Based Methods for Road Works in Africa.
Environmentally Sustainable Development Division, World Bank, Washington, D.C., 74p.

31