Bus Station Project

Kombolcha Bus Station Online Ticket Reservation System

Part one: Introduction 1.1Overview/ Background Kombolcha town found in the north western parts of Addis Ababa at 376 kilometers from the capital city of Ethiopia and 25km far apart from Dessie town. t is the main industry center in Amhara re!ion and has its own administration structure to or!ani"e# control and mana!e the local communities. n addition to this# in the town there are !o$ernmental and non!o$ernmental or!ani"ations or!ani"ations which facilitate the de$elopment of the town and pro$ide ser$ices to the community. community. %rom those !o$ernmental institutions &us stations are one of the public centers which !i$e transportation ser$ice for 'ourneys. (here is only one bus station in kombolcha# and it was established in 2))2 E.* for the purpose of ser$in! the local communities !ettin! ser$ice in their own $illa!e. &efore this bus station established the local communities had to !o to dessie bus station for 'ourney# this this results the people to spend unwanted unwanted wasta!e of resource# resource# money as well well as time. (his (his bus station is second le$el bus station that ha$e only medium bus +that ha$e number of chairs between 2, to ,,- minibuses +that ha$e number of chairs between 7 to 23-. (he bus station starts their work with small number number of cars# now the station will will ha$e ), ), minibus and and 5 medium medium bus# o$erall / / buses. (he station recei$es recei$es cars from , source source places0 

1arbu  Dessie  kemisie  &ati And also the station has responsible for arran!in! cars to 3 destination places sin! manual distribution and ticketin! system. (he destination places are0  Dessie  &ati  1arbu  Kemisie  ekoy  Kara4orie  hewarobit a!e


     

Debrebirhan De!an 8erba Ataye 9orsaye *he4orti

(he last 2 destination place ser$es only for market days.

1.2 Stateme Sta tement nt of the problem proble m (he bus station s system that are usin! currently is an internal system +applies manualand 'ust used to sell the bus ticket at the counter. *ustomer *ustomer has to !o to the counter to buy bus ticket. Due to this this reason the followin! followin! problems problems are obser$ed currently. currently.  *ustomers $ulnerable to wasta!e of money and time when always went to the station office to know the to !et ticket. *ustomer:sneed to 4ueue up lon! time to !et the bus ticket.  *ustomer:sneed 

(he station is $ulnerable to hi!h material resource wasta!e +written materials- and much

cost is must be spend for handlin! records.  %ile control mechanism is $ery tedious# *omplicated and not secured.

1. Ob!e Ob!ectiv ctivee of the pro!ect pro!e ct (he !eneral and specific ob'ecti$es of the pro'ect are described below.

1..1 1. .1 "ene "eneral ral ob!ectiv ob!e ctivee (he !eneral ob'ecti$e of this pro'ect is to de$elop ;nline &us (icket
(o achie$e achie$e the !eneral ob'ecti$es of the pro'ect# we are able to know the followin! specific ob'ecti$es0 o desi!n a database o desi!n user friendly interface o Able to know how to test the system o maintain our system

1.$ Scope and limitation limitat ion of the pro!ect 2a!e


1.$.1 Scope of the pro!ect

(he scope of the proposed system is the followin!0= (he online system is an easy=to=use self=ser$ice system which enables the customer buys bus ticket online and pays the bus ticket from their balance balance throu!h their their account. (he system re4uires >A?. assen!ers $iew the schedule of bus station system. (he administrator able to make report of the database content (he system cannot arran!e bus distribution itself# rather bus distribution schedule is from the the manu manual al syst system em inpu inputt then then dist distri ribu buti tion on sche schedu dule le is !ene !enera rate ted d on web web pa!e pa!e for for customer $iewin! ser$ice. (he system is applicable on recordin!# deletin! and updatin! and retrie$in! of customer information.

Out of #cope (he proposed system does not perform the followin! issues0 o t does not concern other stations to be online. o o

1.$.2

t does not concern about the town:s transportation transportation system +ta@is# cabs-. (he manual system is a$ailable for unre!istered members.

%imitation#

(he followin! limitations are facin! durin! de$elopment time0 aterial such as reference books in library# and and nternet access in computer laboratory rooms. horta!e of hours to use computer in the computer center •

• •

(ime line for the final year pro'ect allocated

•

horta!e of information and documentations on the bus station.

1.& 1.& 'ethod 'et hodolo olog( g( n de$elopin! online bus ticket reser$ation system# the followin! de$elopment methodolo!ies methodolo!ies will be applied. 1.&.1 )ata collection

Data collection was one of the important tasks to analy"e how acti$ities done in e@istin! system and de$eloped the new system. system. Data for de$elopin! this this system obtained obtained from different different 3a!e


sources. (hese data sources were system users +personnel of bus station-# different forms and documents used in the office# procedure manuals# and reports of the office.

)ata collection method# A- Interview0 = was used to !ather re4uired data for the pro'ect by contactin! different employees of the bus station. &- Ob#ervation0=was used to !ather additional data by obser$in! the actual work bein! done by the staff and consolidated with what was obtained throu!h nter$iew. *- )ocument *nal(#i# +)ocument , literature review-: consulted and analy"ed written materials that describe the operations conducted in the station to further stren!then and support the information that applied the abo$e techni4ue. 1.&.2 S(#tem anal(#i# and de#ign

(he methods of the system analysis and desi!n can do throu!h ;;AD +ob'ect=oriented system analysis and de$elopment-. we use the ;;AD modellin! for our pro'ect because it is considered ;;AD are easier to de$elop and maintain and also it is considered that the transition ;b'ect oriented analysis to ;b'ect oriented desi!n can be done easily. 1.&.2 S(#tem )evelopment /Implementation

(he implementation phase is described as those acti$ities that be!in when the system desi!n has been completed. (hese phases are producin! software code accordin! to plan# analysis and system desi!n that ha$e been done. *odin! and debu!!in! is the act of creatin! the final system. (he re4uirements documentation should be referred to throu!hout the rest of the system de$elopment process to ensure the de$elopin! pro'ect ali!ns with the needs and re4uirements or scope. (he system also is tested to e$aluate its actual functionality in relation to e@pected or intended functionality.

)evelopment tool#: •

)ataba#e ool# : 0*'PP  .1.

•

)rawing tool for )iagram# : 3ational 3o#e

•

)ocumentation : 'icro#oft 4ord 25 Programming ool# : *dobe )reamweaver 6S &.& 7 8et Bean# 5.2.1 Programming %anguage#:  9'%7 P9P7 avaScript7 ;uer(7 6SS. Operating S(#tem:  'icro#oft 4indow# 0P7 4indow# 5. ,a!e


Interface %anguage:  *mharic7
(he Kombolcha town bus station system is not usin! computeri"ed data processin! ystem hence it is a serious problem in time mana!ement and to perform their work efficiently. o makin! the system online will in$esti!ate the technolo!ical problems and to find ways and means to enable the station computeri"ed workin! system that could help to work efficiently. (he proposed system will ha$e many ad$anta!es like0= 

(he system will perform fast ser$ice and minimi"e stated problems.  t minimi"es the workload of employees.  t minimi"es loss of documents and data fra!ments.  t minimi"es time to retrie$e search and update files.

Benefit# (hese benefits are classified as tan!ible and intan!ible benefits (an!ible benefits are usually measured in terms of profits to the &us station. 

(ime consumin! acti$ities+tasks- will be reduced





A$oid document missin! and material wasta!e

ntan!ible benefits are benefits that cannot be measured in terms of money. 

A$oid tiredness of customers because ticketing is online .



A$oid tiredness to separate the dead file from the no dead files.

1.5 >ea#ibilit( anal(#i# %easibility study is used to in$esti!ate the proposed system in multiple dimensions. t used to indicate whether the system feasible or not. ;ur system can be seen accordin! to the followin! literals. 5a!e


1.5.1 Operational fea#ibilit(

(he new system can be easily operated and accessed by the users anywhere who interact to the system. t contains user friendly commands which leads users interact to the system interfaces. And ha$e Amharic lan!ua!e interface to interact with users who can:t read En!lish lan!ua!e. 1.5.2 echnical fea#ibilit(

(echnical feasibility is the measure of practicality of the specific technical solution and the a$ailability of technical resources and e@pertise. ;ur system can be easily maintained and repaired without re4uirin! hi!h E@perts or technical assistants. 1.5.
(he pro'ect that we are !oin! to de$elop is economically feasible than the manual system that the bus station currently use. After finishin! online bus ticket reser$ation system so many resources are feasible. (he manual system use lar!e amount of document for ticket this implies economically infeasible# our ystem chan!es this into computeri"ed manner so no wasta!e of resource for ticket bookin!. 1.5..1 Benefit# of the Pro!ect a- angible benefit#

ince this pro'ect is !oin! to be dynamic web site# there is reduction cost for material that used for manual operation# sa$e time and make comfortable workin! en$ironment for the users. b- Intangible benefit#

(he intan!ible benefits we ha$e pointed out the system de$elopment are the followin!0= 

Easily access information.  ncreased fle@ibility  ncrease speed of acti$ity  mpro$es the confidence of the employees. 6a!e


1.5..2 6o#t of the Pro!ect

a-

angible co#t# (he tan!ible costs to be ac4uired in de$elopin! the system are0= i. ii. iii.

i.

1ardware de$elopment cost oftware de$elopment cost iscellaneous *ost

9ardware development co#t

Hardware

Performance

Price

Pentium ! "#$ %H& $ %b R'( 1)** (h& Bus Seed 1 Comuter

1*,*** Birr 1$* %b Hard +isk Standard +islay Standard mouse Standard Key Board

7a!e


-aser .nk /et 1 Printer

),*** '! Si&e $23 Kb Broad Band Connection

0etwork Coverae

1,1** Birr Per 8ear

Can Be 45tended $!67 Service able 1.1 9ardware development co#t *nd 171 <B per (ear for network coverage

ii.

Software development co#t %or this particular pro'ect we will be usin! different software but the software are pro$ided by the uni$ersity. Software costs Software Description Price icrosoft windows C p2

25) &irr

icrosoft office 2))7

2)) &irr

icrosoft > ser$er 2))

2)) &irr

Adobe Dreamweaver CS5.5

5) &irr

Net Beans 7.2.1

5) &irr a!e


Total

950 Birr

(able .2 oftware cost al$a!e $alue F G+/5H,yrs-I3mont:sJH2mont:s ? 12.1875&irr Annual depreciation cost F /5=2.75H,yrs ? 191.95&irr onthly depreciation costF /./5H2 ont:s ? 15.99&irr oft de$elopment costF 1&.@@ I3 ont:s ? 47.97 Birr

iii.

'i#cellaneou# 6o#t (he followin! table lists the different miscellaneous costs that we spent in the process of the de$elopment of the system. Miscellaneous Costs Material Amount Price Printing Pen Paper >la#h di#k otal

'inimum 1 page# & O8< )
2 Birr 1 Birr = Birr 2 Birr $5 Birr

(able.3.iscellaneous costs

b- Intangible co#t# (he intan!ible costs to be ac4uired in de$elopin! the system are0=  Human

Knowledge

(he 1uman knowled!e that we spent to de$elop the system is defined in terms of money as follows.

/a!e


•

ayment for  personHdays F 50 birr

•

5 persons work on the pro'ect each 6) days

(herefore 1uman Knowled!e cost F 5)brHhr I 5persons I 6) days F 15,000 Birr 1.&.. otal co#t

(otal cost F tan!ible cost  intan!ible cost &ut (an!ible cost F 1ard ware cost  iscellaneous *ost  oftware cost  software de$elopment cost ince the software and hardware costs are co$ered by the uni$ersity# their cost is ) &irr. F /#)) birr  ,7) birr  /5) birr ,7./7 birr ?2&=5 .97 &irr

ntan!ible cost F human knowled!e *ost ? 15,000&irr otal 6o#t ? 2&=5 .97 Birr  1&7 &irr ? &&=5.@5&irr 1.5.$ Schedule >ea#ibilit(

chedule feasibility is makin! sure whether the potential time frames and *ompletion date can be met or not .(he pro'ect team members e@pected the ro'ect to be completed on time without any delay. (his represented by !iant chart under pro'ect schedule# see !iant chart. 1.A6ommunication plan

)   a ! e


*ommunication plan describes the schedule of !roup member or the time of communication plan to de$elop pro'ect with the schedule described in the !iant chart. (he !roup member communicates two days (uesdays and (hursday for each week. 9hile the member meets on specified time at least communicate for 3 hours.

R.No

Name

D

Role

1 2  $ & =

*ntehuniruneh 9/e(e#u#a##ew iberetu 9/mariam 'elak"eCahegn 'erkebuDite(aw adi(o#9ailu

1/2 2$/2 /2 =/2 A/2 $@/2

Information "atherer Implementation Propo#al developer S(#tem and Ob!ect de#igner Bu#ine## *rea *nal(#t Ob!ect Oriented *nal(#t

(able ., *ommunication lan 1.@ a#k break down and deliverable#

   a ! e


Pro!ect #chedule

!as"s

P(ases

Startin* !ime

#inis(in* !ime

Sin*le !ime +stimate

System Proosal

9ritin :ebruary (arch 1; $! +ays Proosal $2 Problem (arch $* (arch $7 7 +ays +e
,(ole !ime +stimate

(able .5 (ime chedule

$! +ays

$; +ays

1 &'

Ma% 15

1$ +ays

"* +ays

on (able.6 8iant chart

Part wo: Bu#ine## *rea anal(#i# )efinition 2   a ! e


ystem Analysis is the detailed study of the $arious operations performed by the system and their relationships within and outside the system. Analysis is the process of breakin! somethin! into its parts so that the whole may be understood. ystem analysis is concerned with becomin! aware of the problem# identifyin! the rele$ant and most decisional $ariables# analy"in! and synthesi"in! the $arious factors and determinin! an optimal or at least a satisfactory solution. Durin! this a problem is identified# alternate system solutions are studied and recommendations are made about committin! the resources used to desi!n the system.

2.1 )e#cription of the eEi#ting #(#tem (he e@istin! system refers the manual system that is a$ailable currently. (he e@istin! system forces customers of the bus station to come o$er to the bus station personally (o buy or !et tickets (o know 'ourney schedules (o !et information about the bus station • • •

And also the record keepin! B the bus distribution handled manually.

Detailed Description of the existing sste! As described later the current system use manual system. *ustomers come to the bus station office in order to !et ticket# after these customers are 4ueuin! up lon! time in front of the office. (hen ticket sale man hosts the customer one by one for lar!e amount of time. (he ticket sale man record customer data on the ticket paper and on the a!enda book. (he ticket is !i$en for customer but the data recorded on the a!enda is sa$ed in the office for different purpose.

Bottleneck# of the eEi#ting #(#tem     

*ustomers faced a problem of money B time wasta!e (icket sellers waste time B ener!y (he record keepin! system wastes much resources
As mentioned on chapter  the e@istin! system has many drawbacks that are why we try to build an automated system. &ut in this case we try to see the limitations of the e@istin! system in terms of ieces framework. 3   a ! e


(he performance of the e@istin! system can be e$aluated by the time duration of the items waitin! to be purchased by the customers and the number of customers ser$ed at a time# and this depend on the number of customers and the number of employees who !i$e the ser$ice. f the numbers of the customers are a lot All the abo$e statements are full filled if the employees can handle all the customers effecti$ely and 4uickly# but the e@istin! system has a problem like0  (he numbers of employees needed to handle the customers are limited. 

t takes lot of time to calculate price of each items and ser$e many customer at the same time. Problem# around Input o (he tickets are not secured o (he authenticity of the tickets are not assured o (ime wasta!e matters a lot

Problem# around output o n terms of !ettin! remained information

Practice# to be pre#erved from the eEi#ting #(#tem E$en thou!h the e@istin! system has many drawbacks it is also undeniable that it ha$e !ood features too. >ike0  (he way of attractin! customers in a !ood approach  *ontrollin! and re!isterin! ticket details  (he reliability of the system because of appealin! to administrati$e office in case of errors

2.2 *lternative #olution# 9e +the members of our !roup- try to find solutions in many ways and !et two options. . (he first one is to try sol$in! problems while usin! the e@istin! +manual- system by takin! some measures like0 o Addin! e@tra ticket seller on the counter to minimi"e the 4ueue of the customers

,   a ! e


o

(o employee additional record keeper to increase the performance of the

o

record keepin! part (o post the daily 'ourney schedules on public notice boards

E$en thou!h these measures can minimi"e the problem of the customers they ha$e their own problems like0 o oney wasta!e of the bus station for employin! e@tra employees o (ime and resources of the station will be wasted for postin! daily schedules on public notice boards 2. (he second option is to make the bus station web based and try not to affect the e@istin! system structure. (he second option +the newly proposed- system is much more appropriate solution for our problem rather than the first one because0 o (he proposed system don:t cost like the first option o (he proposed system can work more efficiently than the first one o ?owadays human bein! is become more attracted to technolo!y o# we choose the second option as an appropriate solution for our problem.

2. 3e;uirement definition +)e#cription of the new #(#tem)e#cription of the newl( propo#ed #(#tem (he newly proposed system needs a web based system that customers can access the webpa!e where$er they are by usin! 999 +nternet- to !et +buy- tickets# to know 'ourney schedules B to !et information about the bus station in detail and the has enormous database to control the record keepin! B to !enerate bus distribution schedule +the schedule is entered from administrator input-.

*dvantage# of the newl( propo#ed #(#tem 

*ustomer:s don:t ha$e to waste time B money because of they can access the

webpa!e where$er they are whate$er they are doin!  (icket sellers e@hausti$e work will be reduced by the system 



>oss of records is unima!inable unless the system crashes with some reasons

2..1 >unctional 3e;uirement        

embership re!istration &us owner re!istration Lalidates data entry for correctness. pdates itself when it !ets new data. ell coupons to customers with account ro$ide ticket Display updated 'ourneys schedule online Display updated buses information

2..2 <##ential u#e 6a#e modeling +)e#criptionAn essential use case +*onstantine and >ockwood ///-# sometimes called a business use case# is a simplified# abstract# !enerali"ed use case that captures the intentions of a user in a technolo!y and implementation independent manner. A fully documented essential use case is a structured narrati$e# e@pressed in the lan!ua!e of the application domain and of users# comprisin! a simplified# abstract# technolo!y=free and implementation=independent description of one task or interaction. An essential use case is complete# meanin!ful# and well desi!ned from the point=of=$iew of users in some role or roles in relation to a system and that embodies the purpose or intentions underlyin! the interaction. Actor0 . *ustomer 2. ystem Administrator

6   a ! e


%i! 2. Essential use case dia!ram

<##ential F#e ca#e )e#cription "ssential #se case for $#sto!er %egistration

*= name

6u#tomer 3egi#tration

se case number

*

Actor

ystem Administrator

Description

?ew customer re!istration for membership of bus station 7   a ! e


system ser$ice. &asic course of action

*ctor *ction

S(#tem 3e#pon#e

Step10 ystem Administrator

Step20 ystem displays

wants to re!ister the new

customer re!istration form.

customer.

Step &: ystem checks the

Step0 ystem Administrator

$alidity the filled information.

enters all re4uired information

Step =: the system accepts

for re!istration by $ia

customer data and stored in to

!e!&er registration for!

D&

•

*ustomer pay cash for coupon !reater than ))) &r while re!isterin!.

Step$: A submits the

information filled. Step5: *ustomer !ets the

coupon +ha$in! serial number), user name and

Alternati$e courses of action re=condition ost condition

password . Step &: if the information filled is not $alid# then enter the

customer data a!ain +
   a ! e


Table 2.1 essential use case documentation for customer re!istration

"ssential #se case for B#s o'ner %egistration

*= name

B#s o'ner %egistration

se case number

*2

Actor


Description

&us ownership is re!istered without payment.

&asic course of action

*ctor *ction

S(#tem 3e#pon#e


Step20 ystem displays bus

wants to re!ister the bus

owner re!istration form.

owner.





Step =: the system accepts bus

in bus o'ner registration

owner profile and stored in to

for!.

D&


Alternati$e

information filled. Step &:if the information filled is not $alid# then enter the bus

courses of action re=condition ost condition

owner data a!ain +
"ssential #se case for (enerate Ticket /   a ! e


se case name

(enerate Ticket

se case number

*3

Actor


Description

ystem Administrator !enerate tickets for different le$el of bus for different destination *ctor *ction S(#tem 3e#pon#e Step10 customer opens Step20 ystem display customer ticket re4uest form customer ticket re4uest form. Step0 customer fills there Step $: the system check the re4uest in customer ticket $alidity and a$ailability of re4uest form. customer re4uest. Step&: customer sees the re4uest sent successfully.


Alternati$e Step $: the system identifies customer by checkin! the courses of action database. re=condition dentifyin! customer re4uest. ost condition endin! response for customer re4uest (able 2.3essential use case documentation for !enerate ticket

"ssential #se case for )!o#nt confir!ation *=name

*mount confirmation

se case number

*,

Actor


Description

(he ystem administrator confirms customer ticket re4uest if ha$in! enou!h balance for the re4uired 'ourney distance.

2)   a ! e



*ctor *ction

S(#tem 3e#pon#e


Step20 customer ticket re4uest

wants to confirm customer

confirmation form displayed

ticket re4uest.

Step $: the system updates the


D& by the confirmed data.

confirms customer ticket re4uest if the remainin! balances enou!h re4uired 'ourney distance. Alternati$e

Step : if the customer balance in there account is not enou!h

courses of action

for the re4uired 'ourney in$alid messa!e is sent to customer.

re=condition Liewin! customer ticket re4uest ost condition *onfirmation or unconfirmation customer ticket re4uest (able 2.,Essential use case documentation for amount confirmation

"ssential #se case for Ticket %e*#est se case name

icket re;ue#t

se case number

*5

Actor+s-

*ustomer

Description

;nly membered customer for bus station can ask online

&asic course of

ticketin!. *ctor *ction

action

Step10 customer wants ask

Step20 ystem display

online ticket.

customer ticket re4uest form.

Step0 customer fills there

Step $: the system check the

re4uest in customer ticket

$alidity and current customer

S(#tem 3e#pon#e

2   a ! e


re4uest form.

balance with the cost of

Step&: customer waits until

re4uired 'ourney.

the response come.

Step=0 the system !enerates

re4uired ticket with detailed Alternati$e

information. Step$: if the information filled is not $alid# then enter the data

courses of action

a!ain +
'ourney the response is error messa!e. re=condition *ustomer re4uest wants to process to !et ticket online. ost condition Liewin! the re4uired ticket. Table 2.5 Essential use case documentation for ticet re!uest

"ssential #se case for +ie' ticket se case name

ie'Ticket

se case number

*6

Actor+s-

*ustomer

Description

%irst customer re!ister as member for bus station then !et ser$ice online ticketin! while sendin! re4uest for !et ticket online the response $iew the ticket with detailed information on the ticket.

22   a ! e



*ctor *ction

S(#tem 3e#pon#e

Step10 customer opens ticket

Step20 the system checks the

re4uest form and fills the data

pri$ile!e of customer to !et

to !et ticket.

online ser$ice.

.

Step : if re4uest is true then

the system display ticket for customer. Alternati$e

.Step 2:the system checks customer whether they ha$e

courses of action pri$ile!e to !et online ticketin! ser$ice if not !enerate error messa!e and commands to be member first for this ser$ice. re=condition *ustomer must be member of bus station. ost condition *ustomer $iews the ticket online. (able 2.6Essential use case documentation for Liew ticket

"ssential #se case for +ie' -o#rne sched#le

se case name +ie' o#rne /ched#le se case

*7

number Actor+sDescription

*ustomer E$ery customer can $iew the schedule of bus station without !o to station office

23   a ! e



*ctor *ction

S(#tem 3e#pon#e

Step1: customer knows

Step2: ystem displays

the website of station then

the webpa!e.

access the webpa!e.

Step$0 the system displays

Step: customer opens

the schedule.

'ourney schedule since free.

re=condition ost condition

*ustomer must know the bus station website *ustomers $iew 'ourney schedule.

Table 2." Essential use case documentation #iew $ourne% sc&edule

"ssential #se case for ie'B#snfor!ation se case name

ie' B#snfor!ation

se case number

*

Actor+s-

*ustomer

Description

E$ery customer can $iew bus information that the bus station arran!es.

2,   a ! e




*ctor *ction

S(#tem 3e#pon#e

Step1: customer knows the

Step2: ystem displays the

website of station then access

webpa!e.

the webpa!e.

Step$0 the system displays bus

Step: customer opens the

information with detailed

profile of bus information

information.

*ustomer must know the bus station website *ustomers $iew bus information this is used for customer select

the bus while re!isterin!. (able 2.essential use case documentation for $iew bus information

"ssential #se case doc#!entation for )dd !an#al /ched#le *=name

)dd !an#al /ched#le

se case number

*)

Actor


Description

(he ystem administrator shows the manual schedule on the

&asic course of

web pa!e. *ctor *ction

action


Step20 Add manual order form

wants to show schedule.

displayed.


Step $: ystem checks the

fills the form then click a$e.


S(#tem 3e#pon#e

Step &: the system sa$e data

filled to D&# finally the 25   a ! e


schedule is hown for e$ery customer.

Alternati$e

Step $: if the information filled is not $alid# then enter data

courses of action

a!ain +

done manual schedule 8enerate manual schedule on the webpa!e.

Table 2.' essential use case for )dd !an#al /ched#le

2..<##ential u#er interface protot(pe (here are a number of forms and documents which are used in the e@istin! system. (he first one is the ticket that sold by the sale man and bou!ht by customer that assure the customer to take the allocated 'ourney.

icket Image

26   a ! e


(he other one is a re!istration form that used for the administrati$e office to make sure how many tickets ha$e been !i$en to the sale man this form is useful for both the sale man and administrati$e office for the case of auditin!.

3egi#tration form Image

27   a ! e


2..$)omain modeling u#ing 636 *lass
3e#pon#ibilit(

6ollaborator

Table 2.10 structure of (( card 8ame (he name# located at the top of the card# describes the class that the *<* card represents.

3e#pon#ibilit( A re#pon#ibilit( is somethin! that a class knows or does# represented alon! the left side of the card.

6ollaborator#
. *<* card for ystem Administrator S%stem A-ministratorActor// Maintain $us information 0p-ate -ata$ase customer Create customer Account C(an*e account customer reuest conrmation 2   a ! e


Table 2.11 (( card for *%stem +dministrator

2. *<*card customer re!istration Customer Re*istration0// #name 3name 0name !ic"et Passwor+mail - no telep(one nitial $alance Current $alance Table 2.1 (( card customer registration

3. *<* card for bus owner re!istration Bus owner0// 4wnername Bus iA--ress !elep(one S%stem a-ministrator (able 2., *<* card for busowner
,. *<* card for bus re!istration Bus owner0// Bus t%pe Distance Driver +lapse3evel Price Rote Seat num$er (able 2., *<* card for bus
S%stem A-ministrator

2/   a ! e


5. *<* card for order or-er0// #name 3name Customer Current amount Route Route iSeat num$er Seat reserve uname

S%stem A-ministrator

(able 2., *<* card for order

6. *<* card for ticket Bus owner0// Date Num$er of passen*er Route 0ser name (able 2., *<* card for ticket

Customer

2.$ 8on G >unctional 3e;uirement# 
the system should be able to handle any e@ceptions+like

input mismatch e@ception Securit( M the system should be secured from unauthori"ed access by any means+for     

e@ample from un authori"ed accessPerformance M the system should !i$e ser$ice with ma@imum performance *ccurac( M the system should be accurate and error free 3eliabilit( M the system should be reliable all the time the users accesses the system 8o redundanc( M the system should a$oid repetition of data on the database *vailabilit( M all the data on the system should be a$ailable all the time

3)   a ! e



minimum cost# memory stora!e# time

and human power as much as possible  F#er friendl( interface M the system should tar!et the users need and user friendly

Part hree: Ob !ect Oriented *nal(#i# Introduction )efinition: (he use of modellin! to define and analyse the re4uirements necessary for success of a system. ;b'ect=oriented analysis is a process that !roups items that interact with one another# typically by class# data or beha$iour # to create a model that accurately represents the intended purpose of the system as a whole. ;b'ect=oriented analysis does not factor implementation limitations into the model. . &ecause the ;b'ect oriented system de$elopment approach !i$es easier and natural way to break down problems into simple# small and mana!eable components so that it reduces the $a!ue appearance of the bi! problem. oreo$er# it is predominately used and popular method in present software de$elopment trend. (he ma'or acti$ities described in this chapter are *onstructin! a use case model #Documentin! the use case course of e$ents# constructin! se4uence and acti$ity dia!ram analysis le$el class dia!ram and user proto type about the proposed system.

.1 S(#tem F#e 6a#e# ystem use case describes the interaction between the user and system in a more detailed way than an essential use case. 9hile still tryin! to a$oid referencin! any  specific features when possible# usually certain aspects of the technolo!y to be used can be assumed. %or instance# when writin! a system use case# it is usually known whether the user will interact with a telephonic system# an internet application# or a piece of manufacturin! e4uipment. imilarly# system use cases pro$ide more detailed description of the steps that the system will perform to fulfill the need of the user. n order to a$oid committin! to a specific

3   a ! e


 desi!n# this detail should still be e@pressed in lo!ical terms. 1owe$er# it paints a clearer picture of the re4uirements that the 8 must satisfy.

32   a ! e


%i!ure 3.)ystem use case dia!ram

.1.1 F#e ca#e documentation 1.se case doc#!entation for ogin se case name

>o!in

se case number

*

Actor+s-

ystem administrator# *ustomer

Description

(he authentication for authori"ed users in the system and

&asic course of

deli$er them the ri!ht to $isit their specified windows *ctor# action #(#tem# re#pon#e

action

Step 1 ser initiate to lo!in

Step 2: (he system displays

Step 2 : ser enter user name

the lo!in form.

and password

Step $:

(he system checks

the $alidity of the entry and then $erifies whether the user is

authenticated

authori"ed. Step &:

and

f the user is

authenticated B authori"ed for the tasks the system displays the main pa!e for further action. Alternate courses Step : f the user:s entry +user name and assword- is not of action

$alidated and $erified the system displays error messa!e and return to step 2. 33   a ! e



(he user should be re!istered. ser able to access the re4uired main pa!e.

Table .0 use case documentation for login

#se case Doc#!entation for $#sto!er %egistration *= name

*ustomer
se case number

*

Actor


Description

?ew customer re!istration for membership of bus station

&asic course of

system ser$ice. *ctor *ction

action


Step20 ystem displays

wants to re!ister the new

customer re!istration form.

customer.





Step =: the system accepts

for re!istration by $ia

customer data and stored in to

!e!&er registration for!

D&

•

S(#tem 3e#pon#e

*ustomer pay cash for coupon !reater than 5)) &r while re!isterin!.


information filled. Step5: *ustomer !ets the

coupon +ha$in! serial number), user name and password . 3,   a ! e


Alternati$e

Step &: if the information filled is not $alid# then enter the

courses of action re=condition ost condition

customer data a!ain +
Table .1 use case documentation for customer registration

#se case Doc#!entation forB#s o'ner %egistration *= name

B#s o'ner %egistration

se case number

*2

Actor


Description

&us ownership is re!istered without payment.


*ctor *ction

S(#tem 3e#pon#e


Step20 ystem displays bus

wants to re!ister the bus

owner re!istration form.

owner.





Step =: the system accepts bus

in bus o'ner registration

owner profile and stored in to

for!.

D&


Alternati$e courses of action re=condition ost condition

information filled. Step &: if the information filled is not $alid# then enter the bus owner data a!ain +

Table .2 use case documentation for bus owner registration

#se case Doc#!entation for generate ticket se case name

(enerate Ticket

se case number

*3

Actor


Description

ystem Administrator !enerate tickets for different le$el of bus for different destination *ctor *ction S(#tem 3e#pon#e Step10 customer opens Step20 ystem display customer ticket re4uest form customer ticket re4uest form. Step0 customer fills there Step $: the system check the re4uest in customer ticket $alidity and a$ailability of re4uest form. customer re4uest. Step&: customer sees the re4uest sent successfully.


Alternati$e Step $:the system identifies customer by checkin! the database. courses of action re=condition dentifyin! customer re4uest. ost condition endin! response for customer re4uest Table . use case documentation for generate ticet

#se case Doc#!entation forTicket%e*#est se case name

icket 3e;ue#t

se case number

*,

Actor+s-

*ustomer

Description

;nly membered customer for bus station can ask online

&asic course of

ticketin!. *ctor *ction

action

Step10 customer wants ask

S(#tem 3e#pon#e Step20 ystem display 36   a ! e


online ticket.

customer ticket re4uest form.

Step0 customer fills there

Step $: the system check the

re4uest in customer ticket

$alidity and current customer

re4uest form.

balance with the cost of

Step&: customer waits until

re4uired 'ourney.

the response come.

Step=0 the system !enerates

re4uired ticket with detailed Alternati$e

information. Step$: if the information filled is not $alid# then enter the data

courses of action

a!ain +
'ourney the response is error messa!e. re=condition *ustomer re4uest wants to process to !et ticket online. ost condition Liewin! the re4uired ticket. Table .- use case documentation for ticet re!uest

secaseDoc#!entation forie' Ticket se case name

ie' Ticket

se case number

*5

Actor+s-

*ustomer

Description

%irst customer re!ister as member for bus station then !et ser$ice online ticketin! while sendin! re4uest for !et ticket online the response $iew the ticket with detailed information on the ticket.

37   a ! e



*ctor *ction

S(#tem 3e#pon#e

Step10 customer opens ticket

Step20 the system checks the

re4uest form and fills the data

pri$ile!e of customer to !et

to !et ticket.

online ser$ice.

.

Step : if re4uest is true then

the system display ticket for customer. Alternati$e

.Step 2:the system checks customer whether they ha$e

courses of action pri$ile!e to !et online ticketin! ser$ice if not !enerate error messa!e and commands to be member first for this ser$ice. re=condition *ustomer must be member of bus station. ost condition *ustomer $iews the ticket online. Table .5 use case documentation for #iew ticet

#se case Doc#!entation for +ie' -o#rne sched#le se case name

ie' o#rne/ched#le

se case number

*6

Actor+s-

*ustomer

Description

E$ery customer can $iew the schedule of bus station without !o

&asic course of

to station office *ctor *ction

action




webpa!e.

the webpa!e.

Step$0 the system displays the

Step: customer opens

schedule.

S(#tem 3e#pon#e

'ourney schedule since free.

3   a ! e


re=condition *ustomer must know the bus station website ost condition *ustomers $iew 'ourney schedule. Table . use case documentation for #iew $ourne% sc&edule

#se case Doc#!entation for ie'B#snfor!ation se case name

ie' B#s nfor!ation

se case number

*7

Actor+s-

*ustomer

Description

E$ery customer can $iew bus information that the bus station

&asic course of

arran!es. *ctor *ction

action




webpa!e.

the webpa!e.

Step$0 the system displays bus

Step: customer opens the

information with detailed

profile of bus information

information.


S(#tem 3e#pon#e

*ustomer must know the bus station website *ustomers $iew bus information this is used for customer select the bus while re!isterin!. 3/   a ! e


Table ." use case documentation for #iew bus information

#se case Doc#!entation for )!o#nt confir!ation *=name

*mount confirmation

se case number

*

Actor


Description

(he ystem administrator confirms customer ticket re4uest if

&asic course of

ha$in! enou!h balance for the re4uired 'ourney distance. *ctor *ction S(#tem 3e#pon#e

action


Step20 customer ticket re4uest

wants to confirm customer

confirmation form displayed

ticket re4uest.

Step $: the system updates the


D& by the confirmed data.

confirms customer ticket re4uest if the remainin! balances enou!h re4uired 'ourney distance. Alternati$e

Step :if the customer balance in there account is not enou!h

courses of action

for the re4uired 'ourney in$alid messa!e is sent to customer.

re=condition Liewin! customer ticket re4uest ost condition *onfirmation or unconfirmation customer ticket re4uest Table ./ use case ocumentation for )!o#nt confir!ation

se case doc#!entation for )dd !an#al /ched#le *=name

)dd !an#al /ched#le

se case number

*)

Actor


,)   a ! e


Description

(he ystem administrator shows the manual schedule on the

&asic course of

web pa!e. *ctor *ction

action


Step20 Add manual order form

wants to show schedule.

displayed.


Step $: ystem checks the

fills the form then click a$e.


S(#tem 3e#pon#e

Step &: the system sa$e data

filled to D&# finally the schedule is hown for e$ery Alternati$e

customer. Step $: if the information filled is not $alid# then enter data

courses of action

a!ain +
re=condition done manual schedule ost condition 8enerate manual schedule on the webpa!e. Table .' se case documentation for )dd !an#al /ched#le

.2 Se;uence )iagram# )efinition A se4uence dia!ram is an interaction dia!ram that details how operations are carried out0 what messa!es are sent and when. e4uence dia!rams are or!ani"ed accordin! to time. (he time pro!resses as you !o down the pa!e. (he ob'ects in$ol$ed in the operation are listed from left to ri!ht accordin! to when they take part in the messa!e se4uence.

. Se;uence diagram for ogin

,   a ! e


%i! 3. *e!uence diagram for login

,2   a ! e


2. Se;uence diagram for cu#tomer regi#tration

ig .2 *e!uence diagram for c#sto!er registration ,3   a ! e


3.Se;uence diagram for &#s o'ner registration

,,   a ! e


%i! 3.3 *e!uence diagram for &#s o'ner registration

,5   a ! e


,. Se;uence diagram for generate for generate ticket

%i! 3.- *e!uence diagram for generate ticket

,6   a ! e


&.Se;uence diagram for ticket re*#est

%i!3.5*e!uence diagram for ticket re*#est

,7   a ! e


6. Se;ue Se;uence nce diagra di agram m for view v iew ticket

%i! 3.6*e!uence diagram for +ie' ticket

,   a ! e


7. Se;uence diagram for ie'/ched#le

,/   a ! e


ig ."se!uence diagram for #iew sc&edule

5)   a ! e


. Se;uence diagram for ie'B#sinfor!ation

5   a ! e


%i! 3. e4uence dia!ram for +ie' &#s infor!ation

@.Se;uence diagram for *mount confirmation

ig .' se!uence diagram for amount confirmation

52   a ! e


1 . Se;uence diagram for )dd !an#al /ched#le

53   a ! e


ig .10 se!uence diagram for +dd manual sc&edule

5,   a ! e


. 6onceptual modeling u#ing cla## diagram

ig .11 conceptual modeling using class diagram

.$ *ctivit( diagram )efinition 55   a ! e


Acti$ity dia!ram is another important dia!ram in > to describe dynamic aspects of the system. Acti$ity dia!ram is basically a flow chart to represent the flow form one acti$ity to another acti$ity. (he acti$ity can be described as an operation of the system. o the control flow is drawn from one operation to another. (his flow can be se4uential# branched or concurrent. Acti$ity dia!rams deals with all type of flow control by usin! different elements like fork# 'oin etc. 3n pro$ects in w&ic& #se cases are present, acti+it diagra!s

can model a specific use case at a more detailed le#el.

1. *ctivit( diagram for login

ig .12 acti#it% diagram for login

2. *ctivit( diagram for c#sto!er registration 56   a ! e


.

ig .1 +cti#it% diagram for customer registration

57   a ! e


. *ctivit( diagram for Bu# owner regi#tration

ig .1- +cti#it% diagram for Bus owner registration

5   a ! e


$. *ctivit( diagram for generate ticket

ig .15 +cti#it% diagram for 4enerate ticet

5/   a ! e


&. *ctivit( diagram for cu#tomer ticket re;ue#t

ig .1 +cti#it% diagram for ticet re!uest

6)   a ! e


=. *ctivit( diagram for iew ticket

ig .1" +cti#it% diagram #iew ticet

6   a ! e


5.*ctivit( diagram for iewSchedule

ig .1/ +cti#it% diagram for #iew sc&edule 62   a ! e


A. *ctivit( diagram for iew bu# information

ig .1' +cti#it% diagram for #iew bus information

63   a ! e


@. *ctivit( diagram for amount confirmation

6,   a ! e


ig .20 +cti#it% diagram for a!o#nt confir!ation

1. *ctivit( diagram for *dd manual Schedule 65   a ! e


ig .21 +cti#it% diagram for )dd !an#al /ched#le

66   a ! e


.&F#er interface protot(ping (he user interface prototype is built early# before the whole system is analy"ed# desi!ned and implemented. (he main purpose of creatin! a user=interface prototype is to be able to e@pose and test both the functionality and the usability of the system before the real desi!n and de$elopment starts. (his way# you can ensure that you are buildin! the ri!ht system# before you spend too much time and resources on de$elopment. ser interface +- prototypin! is an iterati$e analysis techni4ue in which users are acti$ely in$ol$ed in the mockin!=up of the  for a system.  prototypes ha$e se$eral purposes0  As an analysis artifact that enables you to e@plore the problem space with your    

stakeholders. As a re4uirements artifact to initially en$ision the system. As a desi!n artifact that enables you to e@plore the solution space of your system. A $ehicle for you to communicate the possible  desi!n+s- of your system. A potential foundation from which to continue de$elopin! the system +if you intend to throw the prototype away and start o$er from scratch then you don:t need to in$est the time writin! 4uality code for your prototype-. T&e user inter face protot%pe is t&at s&own below &a#e used to eplore an ac&ie#able and suitable user inter face design. 3t &elps us to test t&e user inter face design our s%stem, including before t&e de#elopment starts .

(he followin! dia!ram describes the user interface prototypin! of bus station .when user use the system first the main pa!e will be displayed the use what heHshe re4uire based on their !i$en pri$ile!e. f customers ha$en:t account only $iewin! information displayed without lo!in

67   a ! e


ig .22 user interface protot%ping

.=Supplementar( #pecification .=.1 Bu#ine## rule# of the new #(#tem Definition3 A business rule is a statement that describes a business policy or procedure. &usiness rules are usually e@pressed at the atomic le$el == that is# they cannot be broken down any further. A business rule is a statement that describes a business policy or procedure. &usiness lo!ic describes the se4uence of operations that is associated with data in a database to carry out the rule. Kombolcha bus station ha$e their own business rules that customer follow.  E$ery customer payin! cash or store balance comin! in to the office to !et

ser$ice of online ticketin! system. 6   a ! e




9hen customer commands ticket for 'ourney there balance is reduced by the

amount of 'ourney cost.  f balance is finish tryin! online ticket does not !et ser$ice rather addin! balance by !oin! to station office. 
.&.26on#traint# )efinition *onstraint is the element factor or a subsystem that works as a bottleneck. t restricts an entity# pro'ect# or system +such as a manufacturin! or decision makin! process- from achie$in! its potential +or hi!her le$el of output- with reference to its !oal. Kombolcha bus stations ha$e constraints while pro$idin! ser$ices for the customer.  (he station !i$es ser$ice as second le$el.  (here is no lon! distance 'ourney.  (he bus station arran!es only minibus and medium bus.  (here is no enou!h staffs for customer ser$ice  horta!e of ci$il ser$ant for station.

.&.6hange ca#e )efinition *han!e cases used to describe the potential re4uirements of our system. (hey are de$eloped durin! re4uirement !atherin! and also durin! analysis as well as desi!n phases. t enables us to document re4uirement and our system may need to full fill future chan!es Kombolcha bus station established in 2))2 E.* as mentioned earlier# a lot of chan!e or impro$ement is shown from day to day acti$ities. ?ow peoples are satisfied based on the station ser$ice. (he followin! are the chan!e case of the &us station for the feature that the station impro$es.  Additional destination countries results chan!in! the system +addin! features of

destination places-.  f the bus station starts to !i$e igh le+el &#s 'ourney ser$ice there is obli!ated to add this feature.

6/   a ! e


Part >our: S(#tem and Ob!ect de#ign $.1 Introduction# ystemdesi!n is to in$ol$e con$ertin! the description of the proposed system into lo!ical and then physical desi!n specification. 9e e@pect one can understand our new system implementation because it !i$es full description about whole system. Also one can understand easily and enable to answer how the system de$eloped and functioned in simplified manner. (he !oal of system desi!n accordin! to the proposed pro'ect is to mana!e comple@ity by di$idin! the system into smaller# mana!eable pieces and to increase the system0= 

Efficiency0 the system doin! somethin! well and thorou!hly without waste of money and

time.  %le@ibility 0 the system able to chan!e to suite new condition or situation  ecurity0 the system should be secured# i.e. not allow unauthori"ed users to access the system. 
7)   a ! e


$.2 6la## t(pe *rchitecture

ig -.1 class t%pe +rc&itecture

$. cla## modeling 7   a ! e


(he class dia!ram of > is the central piece in a desi!n or model. As the name su!!ests# these dia!rams describe the classes that are there inthe desi!n. As the final codes of an ;; implementation are mostly classes# these dia!rams ha$e a $ery close relationship with the final code. (here are many tools that translate the class dia!rams to code skeletons# thereby a$oidin! errors that mi!ht brief introduced if the class dia!rams aremanuallytranslated to class definitions bypro!rammers + )nntegrated)pproachto/oft'are"ngineeringB6anka-alote -.

%i! ,.2 class dia!ram

$.$ State 6hart 'odeling tate chart dia!ram is one of the fi$e > dia!rams used to model dynamic nature of a system. (hey define different states of an ob'ect durin! its lifetime. t describes the flow of control from one state to another state. tates are defined as a condition in which an ob'ect e@ists and it chan!es when some e$ent is tri!!ered. 72   a ! e


%ollowin! are the main purposes of usin! tate chart dia!rams0 (o model dynamic aspect of a system. •

•

(o model life time of a reacti$e system.

•

(o describe different states of an ob'ect durin! its life time.

•

Define a state machine to model states of an ob'ect.

1. /tate chart diagra! for ogin

73   a ! e


>ig $.tate chart dia!ram for >o!in

2. /tate chart diagra! for $#sto!er registration 7,   a ! e


>ig $.$tate chart dia!ram for *ustomer re!istration

75   a ! e


. /tate chart diagra! for &#s o'ner registration

76   a ! e


>ig $.& tate chart dia!ram for bus owner re!istration

4. /tate chart diagra! for )dd !an#al sched#le

>ig $.= tate chart dia!ram for Add manual schedule 77   a ! e


5. /tate chart diagra! for ticket re*#est

7   a ! e


>ig $.5 State chart dia!ram for (icket re4uest

7/   a ! e


$.& 6omponent modeling *omponent dia!rams show how the physical components of a system are or!ani"ed. And also shows which component or ob'ects will be accessed by whom and what type of security infrastructures it is usin!. (he dia!ram is simulated below

Database

ig -./ component diagram

$.= )eplo(ment modeling A > Deployment dia!rams are used to depict the relationship amon! runtime components and hardware nodes. *omponents are elf=contained entities that pro$ide ser$ices to other components or actors +;b'ect=;riented oftware En!ineerin!# 2nd Edition-. )   a ! e


ig -.' eplo%ment diagram

$. 5 F#er interface de#ign (he blueprint for a house +its architectural desi!n- is not complete without representation of doors# windows# and utility connections for water# electricity# and telephone +not to mention

   a ! e


cable (L-. (he Ndoors# windows# and utility connectionsO for computer software make up the interfacedesi!n of a system. nterface desi!n focuses on three areas of concern0 +- the desi!n of interfaces between software components# +2- the desi!n of interfaces between the software and other nonhuman producers and consumers of information +i.e.# other e@ternal entities-# and +3- the desi!n of the interface between a human +i.e.# the user- and the computer. n this chapter we focus e@clusi$ely on the third interface desi!n cate!oryPuser interface desi!n +oftware En!ineerin! 3oger S. Pre##man7 Ph.).-

=ser .nterface :or Home Pae

%i! ,.) user interface for home pa!e

2   a ! e


=ser .nterface :or=ser -oin Pae

=ser .nterface :or'dmin -oin Pae

3   a ! e


=ser .nterface :or'dminPae

art %i$e0 ystem *onstructionHmplementation ,   a ! e


SDS<' 6O8S3*6IO8/I'P%<'<8*IO8 5.Introduction ystem implementation !i$es the physical codin! of the system# the codin! was done in 9'%7 P9P7 avaScript7 ;uer(7 and 6SS lan!ua!e .the selection of those lan!ua!es is because we are de$elopin! the dynamic website. n this chapter the sample codin! for implementation and testin! ways will be described.

5.2 6oding +coding a# anneEAfter other phases of the system de$elopment is completed codin! takes ne@t position. *odin! includes implementation of user interface# implementation of database and lo!ical implementation. n the followin! interface implementation, database implementation and lo!icalimplementation are discussed in conte@t of the whole system. mplementin! nterface n this part implementation of pa!es of each pa!e is done. a!es are di$ided in to interface and user interface. (hat is for security measurement. Database. t supports different acti$ities like deletin!# updatin!# retrie$in!# searchin!# displayin! and other functionalities. (he data base used for database implementation is 0*'PP  .1....

Sample code for implementation coding for 'ain page QRphp HHtart session sessionSstart+- HHnset the $ariables stored in session unset+TSE;?GUESE&E* Y=HH93*HHD(D C1(> .) trictHHE?Y Yhttp0HHwww.w3.or!H(

Qmeta http=e4ui$FY*ontent=(ypeY contentFYte@tHhtml charsetF(%=Y HV QtitleV1omeQHtitleV Qlink hrefFYmenu.cssY relFYstylesheetY typeFYte@tHcssY HV Qlink relFYstylesheetY typeFYte@tHcssY [email protected] HV Qlink relFYiconY typeFYima!eHpn!Y hrefFY@resHima!esHfa$icon.pn!Y HV QW==Gif E 6JVQstyle typeFYte@tHcssYV I html im!Z beha$ior0 url+Y@[email protected] [QHstyleVQW GendifJ==V Qscript typeFYte@tH'a$ascriptY srcFY@resH'sHsaslideshow.'sYVQHscriptV Qscript typeFYte@tH'a$ascriptY srcFY@resH'sHslideshow.'sYVQHscriptV Qscript srcFY'sH'4uery=.5.min.'sY typeFYte@tH'a$ascriptY charsetFYutf=YVQHscriptV Qscript srcFY$allenatoH$allenato.'sY typeFYte@tH'a$ascriptY charsetFYutf=YVQHscriptV Qlink relFYstylesheetY hrefFY$allenatoH$allenato.cssY typeFYte@tHcssY mediaFYscreenY charsetFYutf= YV Qscript typeFYte@tH'a$ascriptYV T+Y\slideshow Vdi$0!t+)-Y-.hide+- setnter$al+function+- Z T+U\slideshow Vdi$0firstU.fade;ut+))).ne@t+.faden+))).end+.append(o+U\slideshowU- [# 3)))- QHscriptV QW==sa calendar==V Qscript typeFYte@tH'a$ascriptY srcFY'sHdatepicker.'sYVQHscriptV Qlink hrefFYcssHdemo.cssY relFYstylesheetY typeFYte@tHcssY HV Qlink hrefFYcssHdatepicker.cssY relFYstylesheetY typeFYte@tHcssY HV Qscript typeFYte@tH'a$ascriptYV HHQWG*DA(AG functionmake(wo*hars+inp- Z return trin!+inp-.len!th Q 2 R Y)Y  inp 0inp [ functioninitialisenputs+- Z HH *lear any old $alues from the inputs +that mi!ht be cached by the browser after a pa!e reloaddocument.!etElement&yd+YsdY-.$alue F YY document.!etElement&yd+YedY-.$alue F YY

6   a ! e


HH Add the onchan!e e$ent handler to the start date input dateicker*ontroller.addE$ent+document.!etElement&yd+YsdY-# Ychan!eY# setow+dt - if+ed$Qdt- Z document.!etElement&yd+YedY-.$alue F YY [ [ functionremo$enputE$ents+- Z dateicker*ontroller.remo$eE$ent+document.!etElement&yd+YsdY-# Ychan!eY# set

HHJJV QHscriptV QHheadV Q bodyV Qdi$ idFYwrapperYV Qdi$ idFYheaderYV QhVQa [email protected]!srcFY@resHima!esHlo.'p!Y altFY]ames &uchanan ub and
   a ! e


Qh2 classFYaccordion=headerY styleFYhei!ht0 p@ mar!in= bottom0 5p@ color0 r!b+255# 255# 255- back!round0 none repeat scroll )p@ )p@r!b+53# ,# ,-YVser i!n ?QHh2V Qdi$ classFYaccordion=contentY styleFYmar!in=bottom0 5p@YV Qform actionFY*heck>o!.phpY methodFYpostY styleFYmar!in=bottom0noneYV Qspan styleFYmar!in=ri!ht0 p@YVser ?ame0 Qinput typeFYte@tY nameFYusernameuY styleFYwidth0 65p@ mar!in=left0 5p@ border0 3p@ double \****** paddin!05p@ )p@YHVQHspanVQbrV Qspan styleFYmar!in=ri!ht0 p@YVassword0 Qinput typeFYpasswordY nameFYpassworduY styleFYwidth0 65p@ mar!in=left0 5p@ border0 3p@ double \****** paddin!05p@ )p@YHVQHspanVQbrVQbrV Qinput typeFYsubmitY idFYsubmitY $alueFYi!n nY styleFYhei!ht0 3,p@ mar!in=left0 5p@ width0 /p@ paddin!0 5p@ border0 3p@ double r!b+2),# 2),# 2),-Y HV QHformV QHdi$V Qh2 classFYaccordion=headerY styleFYhei!ht0 p@ mar!in= bottom0 5p@ color0 r!b+255# 255# 255- back!round0 none repeat scroll )p@ )p@r!b+53# ,# ,-YVAdmin >o!inQHh2V Qdi$ classFYaccordion=contentY styleFYmar!in=bottom0 5p@YV Qform actionFYlo!in.phpY methodFYpostY styleFYmar!in= bottom0noneYV Qspan styleFYmar!in=ri!ht0 p@YVsername0 Qinput typeFYte@tY nameFYusernameY styleFYwidth0 65p@ mar!in=left0 5p@ border0 3p@ double \****** paddin!05p@ )p@YHVQHspanVQbrV Qspan styleFYmar!in=ri!ht0 p@YVassword0 Qinput typeFYpasswordY nameFYpasswordY styleFYwidth0 65p@ mar!in=left0 5p@ border0 3p@ double \****** paddin!05p@ )p@YHVQHspanVQbrVQbrV Qinput typeFYsubmitY idFYsubmitY classFYmedium !ray buttonY $alueFY>o!inY styleFYhei!ht0 3,p@ mar!in=left0 5p@ width0 /p@ paddin!0 5p@ border0 3p@ double r!b+2),# 2),# 2),-Y HV QHformV QHdi$V QHdi$V QHdi$V QHdi$V /   a ! e


Qdi$ idFYfeaturedYV Qdi$ idFYitemsYV Qdi$ classFYitemYVQa hrefFYmain=course.phpYVQim!srcFY@resHima!esH)Sfeatured.'p!Y altFYY HVQHaV Qh3VQa hrefFYmain=course.phpYVpecials ;ffersQHaVQHh3V QpVQa hrefFY\YVQstron!VAircon &usQHstron!VQbr HV *ome in and e@perienceQbr HV;ur new &us (ypeQbr HV specials todayWQHaVQHpV QHdi$V Qdi$ classFYitemYVQa hrefFYlod!in!.phpYVQim!srcFY@resHima!esH)2Sfeatured.'p!Y altFYY HVQHaV Qh3VQa hrefFYlod!in!.phpYV?ew
5.3Al!orithm De$elopment 4e have the following #ample algorithm development to implement our #(#tem.

ser ogin )lgorith!

6pen &ome page 4o to t&e user login form 3nsert username and password 3f ser name and password correct edirect to ser page Else /)   a ! e


7essage ispla%893n#alid ser name or password9: *ta% at &ome page End if

)d!in ogin )lgorith!

4o to Home page 4o to +dmin ;ogin form 3nsert username and password 3f ser name and password correct edirect to +dmin page Else 7essage ispla%893n#alid ser name or password9: *ta% at &ome page End if

5., %low chartin! A flowchart is a dia!rammatic representation that illustrates the se4uence of operations to be performed to !et the solution of a problem. A flowchart is a common type of chart that represents an al!orithm or process showin! the steps as bo@es of $arious kinds# and their order by connectin! these with the arrows. %lowcharts are used in desi!nin! or documentin! a process or pro!ram in $arious fields %low chart is a dia!ram that depicted or e@plainin! the lo!ic flow of sin!le process or method.

/   a ! e


1ome pa!e

*hoose

ser >o!in %orm

8o to Admin %orm

Sign In HH&utton

Sign In HH&utton

(icket bookin! form *hoose Action QQ>inkVV %ill form *ustomer
&us owner
&us owner
a$e

%ill form /2   a ! e


f *ustomer ha$e sufficient Account &alance And (he &us ;rdered is ?ot %ull

a$e

%alse

Error essa!e Displayed

(rue

(icket Liewer pa!e

5.51ardware and oftware ac4uisitions 9e need hardware and software to implement the application software i.e. client=ser$er web based application of Online Bu# icket 3e#ervation S(#tem for ombolcha own. (he hardware and software we used for de$elopin! this pro'ect are listed below. (o do this pro'ect the team use different hardware and software parts like that of0 1ardware  Desktop computer for doin! all acti$ity #implementin! the software  Different reference  rinter for printin! all document part  %lash to transfer data from one computer to other .

Software 

Edraw ma@ for the drawin! of some dia!rams like use case dia!ram  1 +CA- ser$er and X> to de$elop our data base system.  icrosoft word for any re4uirements like that of writin! our documentation.  acro Dreamwea$er to de$elop the static web pa!e of our pro'ect and to done dynamic pa!e

5.6.Data preparation and installation 5.6. )ata preparation

Data reparation in$ol$es checkin! or lo!!in! the data# checkin! the data for accuracy# enterin! the data into the computer# transformin! the data and de$elopin! and documentin! a database structure that inte!rates the $arious measures. /3   a ! e


5.6.2 nstallation &ecause our pro'ect is a web based application installation of the system is not needed .the way to use the website is hostin! on the web ser$er by !i$in! a public  address.

&.5. e#ting #trategie# De$elopin! software is a comple@ business. ?o matter how hard we try# we won:t be able to eliminate all faults simply by !oin! throu!h the phases of re4uirements# analysis# desi!n# specification# and implementation .howe$er throu!h !ood practice we can make sure that the most series fault does not occur in the first place. n addition we need a separate testin! phase# with the !oal of elimination all remainin! faults before release. (estin! a code and other artefacts as we !o alon! the de$elopment of the system help us to ac4uire the followin! ad$anta!e0 t impro$es the 4uality of the software t reduces the cost of the testin! phases t shows the pro!rammers that they are makin! real pro!ress t reduces the number of faults that are linked to the pro!ram durin! the testin! phase. t help helpss pro! pro!ra ramm mmer erss to reor reor!a !ani ni"e "e thei theirr code code## for for styl stylee perf perfor orma manc ncee reasons# without breakin! anythin! that has already written.

/,   a ! e


(o simplify the testin! process the pro'ect team followed the different types of tests that break the testin! process up into the distinct le$els. (hese types testin! are unit testin! inte!ration testin! and system testin!.

Fnit te#t0 Each module is tested tested alone in attempt attempt to disco$er disco$er any error in its code but since modules e@ist and work with other modules in pro!rams and system they must be tested in lon!er !roups.

Integratio Integration n te#t0 (h (hee proc proces esss of brin brin!i !in! n! to!e to!eth ther er all all of the the mo modu dule less that that a pro! pro!ra ram m compri comprises ses for for testin testin! ! pu purpo rposes ses.. od odule uless are typica typically lly inte! inte!rat rated ed in top won increm increment ental al fashion.

S(#te S(#tem m te#tin te#ting: g: a test performed on an entire system ensures that application pro!rams written and tested in isolation work properly when inte!rated into the total system.

&.A. Start Gup #trateg(. After the website is launched on the internet user with an internet connection can access the website by its keyword and can use the online ser$ices pro$ided by the website. (here are two type of user0 . embered customer0 this customer must !o to the station office in order to be a member. member. 2. n=membered customer0 *ustomer that is not re!istered as member of the bus station can $iew information about bus station# bus profile# and schedule.

art i@0 *onclusion and

=.2. 3ecommendation 3ecommendation Accordin! to scope of our pro'ect the team de$elops web application .&ecause of the time constraint we cannot do beyond to our scopes# but in the future the team belie$es that this system can be fully operational by ha$in! enou!h time and fully information. %inally the team would recommend that further work should done on the system in order to make the system perform better for interested customers who would like to use online ticketin! system# for those who would like to work online bus ticket reser$ation system its recommended to do more more work on the functionalities functionalities such as0= as0= 

Alert e@pired date of product  Alert if products are short  nte!ratin! $isa card with the system

*ppendiE *ppendiE *: *: %i#t of reference# . AnSnte!ratedSApproachStoSoft AnSnte!ratedSApproachStoSoftwareSEn!ineer wareSEn!ineerin!S&ySanka'S in!S&ySanka'S ]alote 2. ]ED ]ED lides=2. lides=2. ;b'ect= ;b'ect=orie oriented nted *oncepts *oncepts 3. ;b'ect=; ;b'ect=;rien riented ted oftware oftware En!ineer En!ineerin!# in!# 2nd Edition ,. *onstantine and >ockwood ///

*ppendiE B: Internet Site 

www.!oo!le.com www.(ahoo.com www.codepro!ect.com www.htmldrive.net www.#tackoverflow.com /6   a ! e


www.w#chool#.com www.filehor#e.com www.ea#(codephp.net

/7   a ! e

Bus Station Project

Recommend Documents