Bus Station Project

Kombolcha Bus Station Online Ticket Reservation SystemPart one: Introduction 1.1Overview/ BackgroundKombolcha 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. It is the main industry center in Amhara region and has its own administration structure to organize, control and manage the local communities. In addition to this, in the town there are governmental and nongovernmental organizations which facilitate the development of the town and provide services to the community. From those governmental institutions Bus stations are one of the public centers which give transportation service for journeys. There is only one bus station in kombolcha, and it was established in 2002 E.C for the purpose of serving the local communities getting service in their own village. Before this bus station established the local communities had to go to dessie bus station for journey, this results the people to spend unwanted wastage of resource, money as well as time. This bus station is second level bus station that have only medium bus (that have number of chairs between 24 to 44) minibuses (that have number of chairs between 7 to 23). The bus station starts their work with small number of cars, now the station will have 104 minibus and 15 medium bus, overall 119 buses. The station receives cars from 4 source places:

Harbu Dessie kemisie BatiAnd also the station has responsible for arranging cars to 13 destination places Using manual distribution and ticketing system. The destination places are: Dessie Bati Harbu Kemisie Mekoy Karaqorie Shewarobit Debrebirhan Degan Gerba Ataye Worsaye CheqortiThe last 2 destination place serves only for market days.1.2 Statement of the problemThe bus station s system that are using currently is an internal system (applies manual) and just used to sell the bus ticket at the counter. Customer has to go to the counter to buy bus ticket. Due to this reason the following problems are observed currently. Customers vulnerable to wastage of money and time when always went to the station office to know the to get ticket. Customersneed to queue up long time to get the bus ticket. The station is vulnerable to high material resource wastage (written materials) and much cost is must be spend for handling records. File control mechanism is very tedious, Complicated and not secured.

1.3 Objective of the projectThe general and specific objectives of the project are described below.1.3.1 General objectiveThe general objective of this project is to develop Online Bus Ticket Reservation System for Kombolcha Town bus station.1.3.2 Specific ObjectivesTo achieve the general objectives of the project, we are able to know the following specific objectives: design a database design user friendly interface Able to know how to test the system maintain our system1.4 Scope and limitation of the project1.4.1 Scope of the projectThe scope of the proposed system is the following:- The online system is an easy-to-use self-service system which enables the customer buys bus ticket online and pays the bus ticket from their balance through their account. The system requires LAN. Passengers view the schedule of bus station system. The administrator able to make report of the database content The system cannot arrange bus distribution itself, rather bus distribution schedule is from the manual system input then distribution schedule is generated on web page for customer viewing service. The system is applicable on recording, deleting and updating and retrieving of customer information.Out of scopeThe proposed system does not perform the following issues: It does not concern other stations to be online. It does not concern about the towns transportation system (taxis, cabs). The manual system is available for unregistered members.1.4.2 LimitationsThe following limitations are facing during development time: Material such as reference books in library, and Internet access in computer laboratory rooms. Shortage of hours to use computer in the computer center Time line for the final year project allocated Shortage of information and documentations on the bus station.

1.5 MethodologyIn developing online bus ticket reservation system, the following development methodologies will be applied.1.5.1 Data collectionData collection was one of the important tasks to analyze how activities done in existing system and developed the new system. Data for developing this system obtained from different sources. These data sources were system users (personnel of bus station), different forms and documents used in the office, procedure manuals, and reports of the office.Data collection methodsA) Interview: - was used to gather required data for the project by contacting different employees of the bus station.B) Observation:-was used to gather additional data by observing the actual work being done by the staff and consolidated with what was obtained through Interview. C) Document Analysis (Document & literature review):-consulted and analyzed written materials that describe the operations conducted in the station to further strengthen and support the information that applied the above technique.1.5.2 System analysis and designThe methods of the system analysis and design can do through OOSAD (object-oriented system analysis and development). we use the OOSAD modelling for our project because it is considered OOSAD are easier to develop and maintain and also it is considered that the transition Object oriented analysis to Object oriented design can be done easily.1.5.2 System Development /ImplementationThe implementation phase is described as those activities that begin when the system design has been completed. These phases are producing software code according to plan, analysis and system design that have been done. Coding and debugging is the act of creating the final system. The requirements documentation should be referred to throughout the rest of the system development process to ensure the developing project aligns with the needs and requirements or scope. The system also is tested to evaluate its actual functionality in relation to expected or intended functionality.Development tools: Database Tools :- XAMPP V 3.1.0 Drawing tool for Diagrams :- Rational Rose Documentation :- Microsoft Word 2007 Programming Tools :- Adobe Dreamweaver CS 5.5 , Net Beans 7.2.1 Programming Languages: - HTML, PHP, JavaScript, Jquery, CSS. Operating System: - Microsoft Windows XP, Windows 7. Interface Language: - Amharic, English.1.6 Significance and Beneficiaries of the projectThe Kombolcha town bus station system is not using computerized data processing System; hence it is a serious problem in time management and to perform their work efficiently. So making the system online will investigate the technological problems and to find ways and means to enable the station computerized working system that could help to work efficiently.The proposed system will have many advantages like:- The system will perform fast service and minimize stated problems. It minimizes the workload of employees. It minimizes loss of documents and data fragments. It minimizes time to retrieve search and update files.BenefitsThese benefits are classified as tangible and intangible benefits Tangible benefits are usually measured in terms of profits to the Bus station.

Time consuming activities(tasks) will be reduced Reduce man power & material budget allocations Avoid document missing and material wastage

Intangible benefits are benefits that cannot be measured in terms of money.

Avoid tiredness of customers because ticketing is online. Avoid tiredness to separate the dead file from the no dead files.1.7 Feasibility analysisFeasibility study is used to investigate the proposed system in multiple dimensions. It used to indicate whether the system feasible or not. Our system can be seen according to the following literals.1.7.1 Operational feasibilityThe new system can be easily operated and accessed by the users anywhere who interact to the system. It contains user friendly commands which leads users interact to the system interfaces. And have Amharic language interface to interact with users who cant read English language.

1.7.2 Technical feasibilityTechnical feasibility is the measure of practicality of the specific technical solution and the availability of technical resources and expertise. Our system can be easily maintained and repaired without requiring high Experts or technical assistants.

1.7.3 Economical feasibility (Cost Benefit Analysis)The project that we are going to develop is economically feasible than the manual system that the bus station currently use. After finishing online bus ticket reservation system so many resources are feasible. The manual system use large amount of document for ticket this implies economically infeasible, our System changes this into computerized manner so no wastage of resource for ticket booking.1.7.3.1 Benefits of the Projecta) Tangible benefitsSince this project is going to be dynamic web site, there is reduction cost for material that used for manual operation, save time and make comfortable working environment for the users.b) Intangible benefitsThe intangible benefits we have pointed out the system development are the following:- Easily access information. Increased flexibility Increase speed of activity Improves the confidence of the employees.

1.7.3.2 Cost of the Projecta) Tangible costsThe tangible costs to be acquired in developing the system are:-i. Hardware development costii. Software development costiii. Miscellaneous Cost i. Hardware development costHardwarePerformancePrice

1 ComputerPentium 43.2 GHz2 Gb RAM1800 Mhz Bus Speed120 Gb Hard DiskStandard DisplayStandard mouseStandard Key Board10,000 Birr

1 PrinterLaser Ink JetA4 Size8,000

Network Coverage256 KbBroad Band ConnectionCan Be Extended24/7 Service1,100 Birr Per Year

Table 1.1 Hardware development cost And 1,100 ETB per year for network coverageii. Software development costFor this particular project we will be using different software but the software are provided by the university.Software costs

Software DescriptionPrice

Microsoft windows XP Sp2250 Birr

Microsoft office 2007200 Birr

Microsoft SQL server 2008200 Birr

Adobe Dreamweaver CS5.5150 Birr

Net Beans 7.2.1150 Birr

Total950 Birr

Table 1.2 Software costSalvage value = [(195/4yrs)*3monts]/12monts = 12.1875BirrAnnual depreciation cost = 195-12.1875/4yrs= 191.95BirrMonthly depreciation cost= 191.95/12 Monts= 15.99BirrSoft development cost=15.99 *3 Monts = 47.97 Birriii. Miscellaneous Cost The following table lists the different miscellaneous costs that we spent in the process of the development of the system. Miscellaneous Costs

MaterialAmountPrice

PrintingMinimum 100 pages200 Birr

Pen510 Birr

PaperONE DESTA60 Birr

Flash disk1200 Birr

Total------------470 Birr

Table1.3.Miscellaneous costsb) Intangible costsThe intangible costs to be acquired in developing the system are:- Human KnowledgeThe Human knowledge that we spent to develop the system is defined in terms of money as follows. Payment for 1 person/days = 50 birr 5 persons work on the project each 60 daysThereforeHuman Knowledge cost = 50br/hr * 5persons * 60 days = 15,000 Birr1.5.3.3 Total costTotal cost = tangible cost + intangible cost ButTangible cost = Hard ware cost + Miscellaneous Cost + Software cost + software development costSince the software and hardware costs are covered by the university, their cost is 0 Birr. = 19,100 birr + 470 birr + 950 birr+ 47.97 birr=20567 .97BirrIntangible cost = human knowledge Cost = 15,000BirrTotal Cost = 20567 .97 Birr + 15,000 Birr= 35567.97Birr1.7.4 Schedule FeasibilitySchedule feasibility is making sure whether the potential time frames and Completion date can be met or not .The project team members expected the Project to be completed on time without any delay. This represented by giant chart under project schedule, see giant chart1.1.8Communication planCommunication plan describes the schedule of group member or the time of communication plan to develop project with the schedule described in the giant chart. The group member communicates two days Tuesdays and Thursday for each week. While the member meets on specified time at least communicate for 3 hours.

R.NoNameIDRole

1AntehunTiruneh010/02 Information Gatherer

2H/eyesusTassew024/02Implementation

3Kiberetu H/mariam030/02Proposal developer

4MelakGezahegn036/02System and Object designer

5MerkebuYiteyaw038/02Business Area Analyst

6TadiyosHailu049/02Object Oriented Analyst

Table 1.4 Communication Plan

1.9 Task break down and deliverablesProject schedulePhasesTasksStarting TimeFinishing TimeSingle Time EstimateWhole Time Estimate

System ProposalWriting ProposalFebruary 25March 1924 Days24 Days

System AnalysisProblem DefinitionMarch 20March 277 Days29 Days

Candidate Solution IdentificationMarch 28April 47 Days

Selection Good SolutionApril 5April 128 Days

Data ModelingApril 13April 208 Days

System DesignDB DesignApril 21April 233 Days12 Days

Input DesignApril 24April 263 Days

Output DesignApril 27April 293 Days

Interface DesignApril 30May 23 Days

System ImplementationCodingApril 30May 2324 Days30 Days

TestingMay 24May 263 Days

MaintenanceMay 27May 293 Days

Table 1.5 Time Schedule

TasksFebruary1 25 30March1 19 30April 1 20 30May1 15 30

System Proposal

System Analysis

System Design

System Implementation

Table1.6 Giant chart

Part Two: Business Area analysisDefinitionSystem Analysis is the detailed study of the various operations performed by the system and their relationships within and outside the system. Analysis is the process of breaking something into its parts so that the whole may be understood. System analysis is concerned with becoming aware of the problem, identifying the relevant and most decisional variables, analyzing and synthesizing the various factors and determining an optimal or at least a satisfactory solution. During this a problem is identified, alternate system solutions are studied and recommendations are made about committing the resources used to design the system.2.1 Description of the existing systemThe existing system refers the manual system that is available currently.The existing system forces customers of the bus station to come over to the bus station personally To buy or get tickets To know journey schedules To get information about the bus stationAnd also the record keeping & the bus distribution handled manually.Detailed Description of the existing systemAs described later the current system use manual system. Customers come to the bus station office in order to get ticket, after these customers are queuing up long time in front of the office. Then ticket sale man hosts the customer one by one for large amount of time. The ticket sale man record customer data on the ticket paper and on the agenda book. The ticket is given for customer but the data recorded on the agenda is saved in the office for different purpose. Bottlenecks of the existing system Customers faced a problem of money & time wastage Ticket sellers waste time & energy The record keeping system wastes much resources Records might not correctly handled Records might lostAs mentioned on chapter 1 the existing system has many drawbacks that are why we try to build an automated system.But in this case we try to see the limitations of the existing system in terms of Pieces framework.

The performance of the existing system can be evaluated by the time duration of the items waiting to be purchased by the customers and the number of customers served at a time, and this depend on the number of customers and the number of employees who give the service. If the numbers of the customers are a lotAll the above statements are full filled if the employees can handle all the customers effectively and quickly, but the existing system has a problem like: The numbers of employees needed to handle the customers are limited. It takes lot of time to calculate price of each items and serve many customer at the same time.Problems around Input The tickets are not secured The authenticity of the tickets are not assured Time wastage matters a lotProblems around output In terms of getting remained information

Practices to be preserved from the existing systemEven though the existing system has many drawbacks it is also undeniable that it have good features too. Like: The way of attracting customers in a good approach Controlling and registering ticket details The reliability of the system because of appealing to administrative office in case of errors 2.2 Alternative solutionsWe (the members of our group) try to find solutions in many ways and get two options.1. The first one is to try solving problems while using the existing (manual) system by taking some measures like: Adding extra ticket seller on the counter to minimize the queue of the customers To employee additional record keeper to increase the performance of the record keeping part To post the daily journey schedules on public notice boardsEven though these measures can minimize the problem of the customers they have their own problems like: Money wastage of the bus station for employing extra employees Time and resources of the station will be wasted for posting daily schedules on public notice boards2. The second option is to make the bus station web based and try not to affect the existing system structure.The second option (the newly proposed) system is much more appropriate solution for our problem rather than the first one because: The proposed system dont cost like the first option The proposed system can work more efficiently than the first one Nowadays human being is become more attracted to technology So, we choose the second option as an appropriate solution for our problem. 2.3 Requirement definition (Description of the new system)Description of the newly proposed systemThe newly proposed system needs a web based system that customers can access the webpage wherever they are by using WWW (Internet) to get (buy) tickets, to know journey schedules & to get information about the bus station in detail and the has enormous database to control the record keeping & to generate bus distribution schedule (the schedule is entered from administrator input).Advantages of the newly proposed system Customers dont have to waste time & money because of they can access the webpage wherever they are whatever they are doing Ticket sellers exhaustive work will be reduced by the system Resources that spent on the newly proposed systems are less costly & efficient Records will be handled correctly because this task handled with computers efficient system (software) Loss of records is unimaginable unless the system crashes with some reasons 2.3.1 Functional Requirement Membership registration Bus owner registration Validates data entry for correctness. Updates itself when it gets new data. Sell coupons to customers with account Provide ticket Display updated journeys schedule online Display updated buses information

2.3.2 Essential use Case modeling (Description)An essential use case (Constantine and Lockwood 1999), sometimes called a business use case, is a simplified, abstract, generalized use case that captures the intentions of a user in a technology and implementation independent manner. A fully documented essential use case is a structured narrative, expressed in the language of the application domain and of users, comprising a simplified, abstract, technology-free and implementation-independent description of one task or interaction. An essential use case is complete, meaningful, and well designed from the point-of-view of users in some role or roles in relation to a system and that embodies the purpose or intentions underlying the interaction. Actor:1. Customer2. System Administrator

Fig 2.1 Essential use case diagram Essential Use case Description Essential use case for Customer RegistrationUC- nameCustomer Registration

Use case numberUC1

ActorSystem Administrator

DescriptionNew customer registration for membership of bus station system service.

Basic course of action Actor ActionStep1: System Administrator wants to register the new customer.Step3: System Administrator enters all required information for registration by via member registration form Customer pay cash for coupon greater than 1000 Br while registering.Step4: SA submits the information filled.Step7: Customer gets the coupon (having serial number), user name and password.System ResponseStep2: System displays customer registration form.Step 5: System checks the validity the filled information.Step 6: the system accepts customer data and stored in to DB

Alternative courses of action Step 5: if the information filled is not valid, then enter the customer data again (Return step 2).

Pre-conditionSAstarts the process of new customer membership registration

Post conditionNew customer registered successfully and data stored to the database.

Table 2.1 essential use case documentation for customer registration

Essential use case for Bus owner RegistrationUC- nameBus owner Registration

Use case numberUC2

DescriptionBus ownership is registered without payment.

Basic course of action Actor ActionStep1: System Administrator wants to register the bus owner.Step3: System Administrator enters all required information in bus owner registration form.Step4: SA submits the information filled.System ResponseStep2: System displays bus owner registration form.Step 5: System checks the validity the filled information.Step 6: the system accepts bus owner profile and stored in to DB

Alternative courses of action Step 5:if the information filled is not valid, then enter the bus owner data again (Return step 2).

Pre-conditionSA starts the process of new bus owner registration

Post conditionNew bus owner profile registered successfully and store in to the database.

Table2.2 essential use case documentation for bus owner registration

Essential use case for Generate TicketUse case nameGenerate Ticket

Use case numberUC3

DescriptionSystem Administrator generate tickets for different level of bus for different destination

Basic course of action Actor ActionStep1: customer opens customer ticket request formStep3: customer fills there request in customer ticket request form.Step5: customer sees the request sent successfully.

System ResponseStep2: System display customer ticket request form.Step 4: the system check the validity and availability of customer request.

Alternative courses of action Step 4: the system identifies customer by checking the database.

Pre-conditionIdentifying customer request.

Post conditionSending response for customer request

Table 2.3essential use case documentation for generate ticket Essential use case for Amount confirmationUC-nameAmount confirmation

Use case numberUC4

DescriptionThe System administrator confirms customer ticket request if having enough balance for the required journey distance.

Basic course of action Actor ActionStep1: System Administrator wants to confirm customer ticket request.Step3: System Administrator confirms customer ticket request if the remaining balances enough required journey distance.

System ResponseStep2: customer ticket request confirmation form displayedStep 4: the system updates the DB by the confirmed data.

Alternative courses of action Step 3: if the customer balance in there account is not enough for the required journey invalid message is sent to customer.

Pre-conditionViewing customer ticket request

Post conditionConfirmation or unconfirmation customer ticket request

Table 2.4Essential use case documentation for amount confirmation

Essential use case for Ticket RequestUse case nameTicket request

Use case numberUC5

Actor(s)Customer

DescriptionOnly membered customer for bus station can ask online ticketing.

Basic course of action Actor ActionStep1: customer wants ask online ticket.Step3: customer fills there request in customer ticket request form.Step5: customer waits until the response come.

System ResponseStep2: System display customer ticket request form.Step 4: the system check the validity and current customer balance with the cost of required journey. Step6: the system generates required ticket with detailed information.

Alternative courses of action Step4: if the information filled is not valid, then enter the data again (Return step 2). If the customer hasnt enough balance for the required journey the response is error message.

Pre-conditionCustomer request wants to process to get ticket online.

Post conditionViewing the required ticket.

Table 2.5 Essential use case documentation for ticket request Essential use case for view ticketUse case nameViewTicket

Use case numberUC6

Actor(s)Customer

DescriptionFirst customer register as member for bus station then get service online ticketing while sending request for get ticket online the response view the ticket with detailed information on the ticket.

Basic course of action Actor ActionStep1: customer opens ticket request form and fills the data to get ticket..

System ResponseStep2: the system checks the privilege of customer to get online service. Step 3: if request is true then the system display ticket for customer.

Alternative courses of action .Step 2:the system checks customer whether they have privilege to get online ticketing service if not generate error message and commands to be member first for this service.

Pre-conditionCustomer must be member of bus station.

Post conditionCustomer views the ticket online.

Table 2.6Essential use case documentation for View ticket Essential use case for view journey scheduleUse case nameview Journey Schedule

Use case numberUC7

Actor(s)Customer

DescriptionEvery customer can view the schedule of bus station without go to station office

Basic course of action Actor ActionStep1: customer knows the website of station then access the webpage.Step3: customer opens journey schedule since free.

System ResponseStep2: System displays the webpage.Step4: the system displays the schedule.

Pre-conditionCustomer must know the bus station website

Post conditionCustomers view journey schedule.

Table 2.7 Essential use case documentation view journey schedule

Essential use case for ViewBusInformationUse case nameView BusInformation

Use case numberUC8

Actor(s)Customer

DescriptionEvery customer can view bus information that the bus station arranges.

Basic course of action Actor ActionStep1: customer knows the website of station then access the webpage.Step3: customer opens the profile of bus information

System ResponseStep2: System displays the webpage.Step4: the system displays bus information with detailed information.

Post conditionCustomers view bus information this is used for customer select the bus while registering.

Table 2.8essential use case documentation for view bus information

Essential use case documentation for Add manual ScheduleUC-nameAdd manual Schedule

Use case numberUC10

DescriptionThe System administrator shows the manual schedule on the web page.

Basic course of action Actor ActionStep1: System Administrator wants to show schedule.Step3: System Administrator fills the form then click Save.

System ResponseStep2: Add manual order form displayed.Step 4: System checks the validity the filled information.Step 5: the system save data filled to DB, finally the schedule is Shown for every customer.

Alternative courses of action Step 4: if the information filled is not valid, then enter data again (Return step 2).

Pre-conditiondone manual schedule

Post conditionGenerate manual schedule on the webpage.

Table 2.9 essential use case for Add manual Schedule2.3.3Essential user interface prototypeThere are a number of forms and documents which are used in the existing system. The first one is the ticket that sold by the sale man and bought by customer that assure the customer to take the allocated journey.Ticket Image

The other one is a registration form that used for the administrative office to make sure how many tickets have been given to the sale man this form is useful for both the sale man and administrative office for the case of auditing.Registration form Image

2.3.4Domain modeling using CRCClass Responsibility Collaborator (CRC) Modelling is a method to gather and define the user requirements for an object-oriented application. The output of CRC Modelling is a CRC Model which is a collection of CRC cards that represent the whole or part of an application or problem domain. Each CRC Card in the model represents a class in the solution. A class represents a person, place, thing, event, concept, screen, or report that is relevant to the system at hand. The name of the class appears across the top of the card. A responsibility is anything that a class knows or does. Class name

ResponsibilityCollaborator

Table 2.10 structure of CRC cardNameThe name, located at the top of the card, describes the class that the CRC card represents. ResponsibilityA responsibility is something that a class knows or does, represented along the left side of the card. CollaboratorsResponsibilities will collaborate with one or more other classes to fulfill one or more Scenarios. Collaborators are listed on the right hand side of the CRC card, next to the responsibilities that they are helping to realize.1. CRC card for System AdministratorSystem Administrator

Maintain bus informationUpdate databaseCreate customer AccountChange accountconfirmation

customer

customer request

Table 2.11 CRC card for System Administrator2. CRCcard customer registrationCustomer Registration

FnameLnameUnamePasswordEmailId notelephoneInitial balanceCurrent balance

Ticket

Table 2.13 CRC card customer registration3. CRC card for bus owner registrationBus owner

OwnernameBus idAddressTelephone Id

System administrator

Table 2.14 CRC card for busowner Registration4. CRC card for bus registrationBus owner

Bus typeDistanceDriverElapsedIdLevelPriceRoteSeat number

System Administrator

Table 2.14 CRC card for bus Registration5. CRC card for orderorder

FnameLnameCustomer IdCurrent amountRouteRoute idSeat numberSeat reserveuname

System Administrator

Table 2.14 CRC card for order6. CRC card for ticketBus owner

DateNumber of passengerRouteUser name

Customer

Table 2.14 CRC card for ticket

2.4 Non Functional Requirements Error Handling Exception the system should be able to handle any exceptions(like input mismatch exception) Security the system should be secured from unauthorized access by any means(for example from un authorized access) Performance the system should give service with maximum performance Accuracy the system should be accurate and error free Reliability the system should be reliable all the time the users accesses the system No redundancy the system should avoid repetition of data on the database Availability all the data on the system should be available all the time Efficiency the system must give service using minimum cost, memory storage, time and human power as much as possible User friendly interface the system should target the users need and user friendly

Part Three: Object Oriented AnalysisIntroductionDefinition: -The use of modelling to define and analyse the requirements necessary for success of a system. Object-oriented analysis is a process that groups items that interact with one another, typically by class, data or behaviour, to create a model that accurately represents the intended purpose of the system as a whole. Object-oriented analysis does not factor implementation limitations into the model.. Because the Object oriented system development approach gives easier and natural way to break down problems into simple, small and manageable components so that it reduces the vague appearance of the big problem. Moreover, it is predominately used and popular method in present software development trend.The major activities described in this chapter are Constructing a use case model ,Documenting the use case course of events, constructing sequence and activity diagram analysis level class diagram and user proto type about the proposed system.3.1 System Use CasesSystem use case describes the interaction between the user and system in a more detailed way than an essential use case.While still trying to avoid referencing any UI specific features when possible, usually certain aspects of the technology to be used can be assumed.For instance, when writing a system use case, it is usually known whether the user will interact with a telephonic system, an internet application, or a piece of manufacturing equipment.Similarly, system use cases provide more detailed description of the steps that the system will perform to fulfill the need of the user.In order to avoid committing to a specific UI design, this detail should still be expressed in logical terms.However, it paints a clearer picture of the requirements that the GUI must satisfy.

Figure 3.0System use case diagram

3.1.1 Use case documentation1.Use case documentation for LoginUse case nameLogin

Use case numberUC1

Actor(s)System administrator, Customer

DescriptionThe authentication for authorized users in the system and deliver them the right to visit their specified windows

Basic course of action Actors actionStep 1 User initiate to loginStep 2 : User enter user name and password systems responseStep 2: The system displays the login form.Step 4: The system checks the validity of the entry and then verifies whether the user is authenticated and authorized. Step 5: If the user is authenticated & authorized for the tasks the system displays the main page for further action.

Alternate courses of action Step 3: If the users entry (user name and Password) is not validated and verified the system displays error message and return to step 2.

Pre-condition The user should be registered.

Post condition User able to access the required main page.

Table 3.0 use case documentation for login use case Documentation for Customer RegistrationUC- nameCustomer Registration

Use case numberUC1

DescriptionNew customer registration for membership of bus station system service.

Basic course of action Actor ActionStep1: System Administrator wants to register the new customer.Step3: System Administrator enters all required information for registration by via member registration form Customer pay cash for coupon greater than 500 Br while registering.Step4: SA submits the information filled.Step7: Customer gets the coupon (having serial number), user name and password.System ResponseStep2: System displays customer registration form.Step 5: System checks the validity the filled information.Step 6: the system accepts customer data and stored in to DB

Alternative courses of action Step 5: if the information filled is not valid, then enter the customer data again (Return step 2).

Pre-conditionSA starts the process of new customer membership registration

Post conditionNew customer registered successfully and data stored to the database.

Table 3.1 use case documentation for customer registration use case Documentation forBus owner RegistrationUC- nameBus owner Registration

Use case numberUC2

DescriptionBus ownership is registered without payment.

Basic course of action Actor ActionStep1: System Administrator wants to register the bus owner.Step3: System Administrator enters all required information in bus owner registration form.Step4: SA submits the information filled.System ResponseStep2: System displays bus owner registration form.Step 5: System checks the validity the filled information.Step 6: the system accepts bus owner profile and stored in to DB

Alternative courses of action Step 5: if the information filled is not valid, then enter the bus owner data again (Return step 2).

Pre-conditionSA starts the process of new bus owner registration

Post conditionNew bus owner profile registered successfully and store in to the database.

Table 3.2 use case documentation for bus owner registration use case Documentation for generate ticketUse case nameGenerate Ticket

Use case numberUC3

DescriptionSystem Administrator generate tickets for different level of bus for different destination

Basic course of action Actor ActionStep1: customer opens customer ticket request formStep3: customer fills there request in customer ticket request form.Step5: customer sees the request sent successfully.

System ResponseStep2: System display customer ticket request form.Step 4: the system check the validity and availability of customer request.

Alternative courses of action Step 4:the system identifies customer by checking the database.

Pre-conditionIdentifying customer request.

Post conditionSending response for customer request

Table 3.3 use case documentation for generate ticket use case Documentation forTicketRequestUse case nameTicket Request

Use case numberUC4

Actor(s)Customer

DescriptionOnly membered customer for bus station can ask online ticketing.

Basic course of action Actor ActionStep1: customer wants ask online ticket.Step3: customer fills there request in customer ticket request form.Step5: customer waits until the response come.

System ResponseStep2: System display customer ticket request form.Step 4: the system check the validity and current customer balance with the cost of required journey. Step6: the system generates required ticket with detailed information.

Alternative courses of action Step4: if the information filled is not valid, then enter the data again (Return step 2). If the customer hasnt enough balance for the required journey the response is error message.

Pre-conditionCustomer request wants to process to get ticket online.

Post conditionViewing the required ticket.

Table 3.4 use case documentation for ticket request UsecaseDocumentation forView TicketUse case nameView Ticket

Use case numberUC5

Actor(s)Customer

DescriptionFirst customer register as member for bus station then get service online ticketing while sending request for get ticket online the response view the ticket with detailed information on the ticket.

Basic course of action Actor ActionStep1: customer opens ticket request form and fills the data to get ticket..

System ResponseStep2: the system checks the privilege of customer to get online service. Step 3: if request is true then the system display ticket for customer.

Alternative courses of action .Step 2:the system checks customer whether they have privilege to get online ticketing service if not generate error message and commands to be member first for this service.

Pre-conditionCustomer must be member of bus station.

Post conditionCustomer views the ticket online.

Table 3.5 use case documentation for view ticket use case Documentation for view journey scheduleUse case nameView JourneySchedule

Use case numberUC6

Actor(s)Customer

DescriptionEvery customer can view the schedule of bus station without go to station office

Basic course of action Actor ActionStep1: customer knows the website of station then access the webpage.Step3: customer opens journey schedule since free.

System ResponseStep2: System displays the webpage.Step4: the system displays the schedule.

Post conditionCustomers view journey schedule.

Table 3.6 use case documentation for view journey schedule use case Documentation for ViewBusInformationUse case nameView Bus Information

Use case numberUC7

Actor(s)Customer

DescriptionEvery customer can view bus information that the bus station arranges.

Basic course of action Actor ActionStep1: customer knows the website of station then access the webpage.Step3: customer opens the profile of bus information

System ResponseStep2: System displays the webpage.Step4: the system displays bus information with detailed information.

Post conditionCustomers view bus information this is used for customer select the bus while registering.

Table 3.7 use case documentation for view bus information use case Documentation for Amount confirmationUC-nameAmount confirmation

Use case numberUC8

DescriptionThe System administrator confirms customer ticket request if having enough balance for the required journey distance.

Basic course of action Actor ActionStep1: System Administrator wants to confirm customer ticket request.Step3: System Administrator confirms customer ticket request if the remaining balances enough required journey distance.

System ResponseStep2: customer ticket request confirmation form displayedStep 4: the system updates the DB by the confirmed data.

Alternative courses of action Step 3:if the customer balance in there account is not enough for the required journey invalid message is sent to customer.

Pre-conditionViewing customer ticket request

Post conditionConfirmation or unconfirmation customer ticket request

Table 3.8 use case Documentation for Amount confirmation Use case documentation for Add manual ScheduleUC-nameAdd manual Schedule

Use case numberUC10

DescriptionThe System administrator shows the manual schedule on the web page.

Basic course of action Actor ActionStep1: System Administrator wants to show schedule.Step3: System Administrator fills the form then click Save.

System ResponseStep2: Add manual order form displayed.Step 4: System checks the validity the filled information.Step 5: the system save data filled to DB, finally the schedule is Shown for every customer.

Alternative courses of action Step 4: if the information filled is not valid, then enter data again (Return step 2).

Pre-conditiondone manual schedule

Post conditionGenerate manual schedule on the webpage.

Table 3.9 Use case documentation for Add manual Schedule

3.2 Sequence DiagramsDefinitionA sequence diagram is an interaction diagram that details how operations are carried out: what messages are sent and when. Sequence diagrams are organized according to time. The time progresses as you go down the page. The objects involved in the operation are listed from left to right according to when they take part in the message sequence.

1. Sequence diagram for Login

Fig 3.1 Sequence diagram for login

2. Sequence diagram for customer registration

Fig 3.2 Sequence diagram for customer registration

3.Sequence diagram for bus owner registration

Fig 3.3 Sequence diagram for bus owner registration

4. Sequence diagram for generate ticket

Fig 3.4 Sequence diagram for generate ticket

5.Sequence diagram for ticket request

Fig3.5Sequence diagram for ticket request

6. Sequence diagram for view ticketFig 3.6Sequence diagram for view ticket

7. Sequence diagram for ViewSchedule

Fig 3.7sequence diagram for view schedule

8. Sequence diagram for ViewBusinformationFig 3.8 Sequence diagram for view bus information

9.Sequence diagram for Amount confirmation

Fig 3.9 sequence diagram for amount confirmation

10. Sequence diagram for Add manual Schedule

Fig 3.10 sequence diagram for Add manual schedule

3.3 Conceptual modeling using class diagram

Fig 3.11 conceptual modeling using class diagram

3.4 Activity diagramDefinitionActivity diagram is another important diagram in UML to describe dynamic aspects of the system. Activity diagram is basically a flow chart to represent the flow form one activity to another activity. The activity can be described as an operation of the system. So the control flow is drawn from one operation to another. This flow can be sequential, branched or concurrent. Activity diagrams deals with all type of flow control by using different elements like fork, join etc. In projects in which use cases are present, activity diagrams can model a specific use case at a more detailed level.1. Activity diagram for login

Fig 3.12 activity diagram for login

2. Activity diagram for customer registration3.

Fig 3.13 Activity diagram for customer registration

3. Activity diagram for Bus owner registration

Fig 3.14 Activity diagram for Bus owner registration

4. Activity diagram for generate ticket

Fig 3.15 Activity diagram for Generate ticket

5. Activity diagram for customer ticket request

Fig 3.16 Activity diagram for ticket request

6. Activity diagram for View ticketFig 3.17 Activity diagram view ticket

7.Activity diagram for ViewSchedule

Fig 3.18 Activity diagram for view schedule

8. Activity diagram for View bus information

Fig 3.19 Activity diagram for view bus information

9. Activity diagram for amount confirmation

Fig 3.20 Activity diagram for amount confirmation

10. Activity diagram for Add manual Schedule

Fig 3.21 Activity diagram for Add manual Schedule

3.5User interface prototypingThe user interface prototype is built early, before the whole system is analyzed, designed and implemented. The main purpose of creating a user-interface prototype is to be able to expose and test both the functionality and the usability of the system before the real design and development starts. This way, you can ensure that you are building the right system, before you spend too much time and resources on development.User interface (UI) prototyping is an iterative analysis technique in which users are actively involved in the mocking-up of the UI for a system. UI prototypes have several purposes: As an analysis artifact that enables you to explore the problem space with your stakeholders. As a requirements artifact to initially envision the system. As a design artifact that enables you to explore the solution space of your system. A vehicle for you to communicate the possible UI design(s) of your system. A potential foundation from which to continue developing the system (if you intend to throw the prototype away and start over from scratch then you dont need to invest the time writing quality code for your prototype).The user inter face prototype is that shown below have used to explore an achievable and suitable user inter face design. It helps us to test the user inter face design our system, including before the development starts. The following diagram describes the user interface prototyping of bus station .when user use the system first the main page will be displayed the use what he/she require based on their given privilege. If customers havent account only viewing information displayed without login

Fig 3.22 user interface prototyping3.6Supplementary specification3.6.1 Business rules of the new system Definition:A business rule is a statement that describes a business policy or procedure. Business rules are usually expressed at the atomic level -- that is, they cannot be broken down any further.A business rule is a statement that describes a business policy or procedure. Business logic describes the sequence of operations that is associated with data in a database to carry out the rule. Kombolcha bus station have their own business rules that customer follow. Every customer paying cash or store balance coming in to the office to get service of online ticketing system. When customer commands ticket for journey there balance is reduced by the amount of journey cost. If balance is finish trying online ticket does not get service rather adding balance by going to station office. Returning ticket is no fully got there balance.3.5.2ConstraintsDefinitionConstraint is the element factor or a subsystem that works as a bottleneck. It restricts an entity, project, or system (such as a manufacturing or decision making process) from achieving its potential (or higher level of output) with reference to its goal. Kombolcha bus stations have constraints while providing services for the customer. The station gives service as second level. There is no long distance journey. The bus station arranges only minibus and medium bus. There is no enough staffs for customer service Shortage of civil servant for station.3.5.3Change caseDefinition Change cases used to describe the potential requirements of our system. They are developed during requirement gathering and also during analysis as well as design phases. It enables us to document requirement and our system may need to full fill future changes Kombolcha bus station established in 2002 E.C as mentioned earlier, a lot of change or improvement is shown from day to day activities. Now peoples are satisfied based on the station service. The following are the change case of the Bus station for the feature that the station improves. Additional destination countries results changing the system (adding features of destination places). If the bus station starts to give High level bus journey service there is obligated to add this feature.

Part Four: System and Object design4.1 IntroductionsSystemdesign is to involve converting the description of the proposed system into logical and then physical design specification. We expect one can understand our new system implementation because it gives full description about whole system. Also one can understand easily and enable to answer how the system developed and functioned in simplified manner.The goal of system design according to the proposed project is to manage complexity by dividing the system into smaller, manageable pieces and to increase the system:- Efficiency: the system doing something well and thoroughly without waste of money and time. Flexibility : the system able to change to suite new condition or situation Security: the system should be secured, i.e. not allow unauthorized users to access the system. Reliability: the system should be reliable.This design system is to involve converting the description of the proposed system into logical and then physical design specification. We expect one can understand our new system implementation because it gives full description about whole system. Also one can understand easily and enable to answer how the system developed and functioned in simplified manner.

4.2 Class type Architecture

Fig 4.1 class type Architecture4.3 class modelingThe class diagram of UML is the central piece in a design or model. As the name suggests, these diagrams describe the classes that are there inthe design. As the final codes of an OO implementation are mostly classes, these diagrams have a very close relationship with the final code. There are many tools that translate the class diagrams to code skeletons, thereby avoiding errors that might brief introduced if the class diagrams aremanuallytranslated to class definitions byprogrammers (An_Integrated_Approach_to_Software_Engineering_By_Pankaj_Jalote).Fig 4.2 class diagram4.4 State Chart ModelingState chart diagram is one of the five UML diagrams used to model dynamic nature of a system. They define different states of an object during its lifetime. It describes the flow of control from one state to another state. States are defined as a condition in which an object exists and it changes when some event is triggered.Following are the main purposes of using State chart diagrams: To model dynamic aspect of a system. To model life time of a reactive system. To describe different states of an object during its life time. Define a state machine to model states of an object.

1. State chart diagram for Login

Fig 4.3State chart diagram for Login

2. State chart diagram for Customer registration

Fig 4.4State chart diagram for Customer registration

3. State chart diagram for bus owner registration

Fig 4.5 State chart diagram for bus owner registration

4. State chart diagram for Add manual schedule

Fig 4.6 State chart diagram for Add manual schedule

5. State chart diagram for ticket request

Fig 4.7 State chart diagram for Ticket request

4.5 Component modelingComponent diagrams show how the physical components of a system are organized. And also shows which component or objects will be accessed by whom and what type of security infrastructures it is using. The diagram is simulated below

DatabaseFig 4.8 component diagram4.6 Deployment modelingA UML Deployment diagrams are used to depict the relationship among runtime components and hardware nodes. Components are Self-contained entities that provide services to other components or actors (Object-Oriented Software Engineering, 2nd Edition).

Fig 4.9 Deployment diagram

4. 7 User interface design

The blueprint for a house (its architectural design) is not complete without representation of doors, windows, and utility connections for water, electricity, and telephone (not to mention cable TV). The doors, windows, and utility connections for computer software make up the interfacedesign of a system.Interface design focuses on three areas of concern: (1) the design of interfaces between software components, (2) the design of interfaces between the software and other nonhuman producers and consumers of information (i.e., other external entities), and (3) the design of the interface between a human (i.e., the user) and the computer. In this chapter we focus exclusively on the third interface design categoryuser interface design (Software Engineering Roger S. Pressman, Ph.D.)

User Interface For Home Page

Fig 4.10 user interface for home page

User Interface ForUser Login Page

User Interface ForAdmin Login Page

User Interface ForAdminPage

Part Five: System Construction/ImplementationSYSTEM CONSTRACTION/IMPLEMENTATION5.1IntroductionSystem implementation gives the physical coding of the system, the coding was done in HTML, PHP, JavaScript, Jquery, and CSS language .the selection of those languages is because we are developing the dynamic website. In this chapter the sample coding for implementation and testing ways will be described.5.2 Coding (coding as annex)After other phases of the system development is completed coding takes next position. Coding includes implementation of user interface, implementation of database and logical implementation.In the following interface implementation, database implementation and logicalimplementation are discussed in context of the whole system.Implementing InterfaceIn this part implementation of pages of each page is done. Pages are divided in to interface and user interface. That is for security measurement. Rather than using same interface its better using independent one is better.Database ImplementingWe have used MySQL Database. It supports different activities like deleting, updating, retrieving, searching, displaying and other functionalities. The data base used for database implementation is XAMPP V 3.1.0...

Sample code for implementation coding for Main page

$("#slideshow >div:gt(0)").hide();

setInterval(function() { $('#slideshow >div:first').fadeOut(1000).next().fadeIn(1000).end().appendTo('#slideshow');}, 3000);

//functionmakeTwoChars(inp) {return String(inp).length < 2 ? "0" + inp :inp;}

functioninitialiseInputs() {// Clear any old values from the inputs (that might be cached by the browser after a page reload)document.getElementById("sd").value = "";document.getElementById("ed").value = "";

// Add the onchange event handler to the start date inputdatePickerController.addEvent(document.getElementById("sd"), "change", setReservationDates);}

varinitAttempts = 0;

functionsetReservationDates(e) {try {varsd = datePickerController.getDatePicker("sd");vared = datePickerController.getDatePicker("ed");} catch (err) {if(initAttempts++ < 10) setTimeout("setReservationDates()", 50);return;}

vardt = datePickerController.dateFormat(this.value, sd.format.charAt(0) == "m");

returnif(dt == 0) return;varedv = datePickerController.dateFormat(document.getElementById("ed").value, ed.format.charAt(0) == "m");

ed.setRangeLow(dt );if(edv

Destination

Comment

Contact Us

About

Vision

Mission

Aim Of The Web Page

User Sign INUser Name:
Password:

Admin Login

Username:
Password:

Specials OffersAircon Bus
Come in and experience
Ournew Bus Type
specials today!

New RouteFrom Kombolcha to Kemise Vice versa
Spend a relaxing evening in our Brand New hotel, steeped in Hospitality.

5.3Algorithm DevelopmentWe have the following sample algorithm development to implement our system. User Login AlgorithmOpen home pageGo to the user login form Insert username and passwordIf User name and password correctRedirect to User pageElseMessage Display=Invalid User name or password; Stay at home page End if

Admin Login AlgorithmGo to Home pageGo to Admin Login formInsert username and passwordIf User name and password correctRedirect to Admin pageElseMessage Display=Invalid User name or password; Stay at home page End if

5.4 Flow chartingA flowchart is a diagrammatic representation that illustrates the sequence of operations to be performed to get the solution of a problem. A flowchart is a common type of chart that represents an algorithm or process showing the steps as boxes of various kinds, and their order by connecting these with the arrows. Flowcharts are used in designing or documenting a process or program in various fields Flow chart is a diagram that depicted or explaining the logic flow of single process or method.

Home page

Choose

User Login Form

Go to Admin Form

Sign In>

Ticket booking form

ChooseAction

Fill form

Bus owner Registration pageBus owner Registration pageCustomer Registration page

Fill form

If Customer have sufficient Account Balance And The Bus Ordered is Not Full Save

False True

Ticket Viewer pageError Message Displayed

5.5Hardware and Software acquisitionsWe need hardware and software to implement the application software i.e. client-server web based application ofOnline Bus Ticket Reservation System for Kombolcha Town.The hardware and software we used for developing this project are listed below.To do this project the team use different hardware and software parts like that of:Hardware Desktop computer for doing all activity ,implementing the software Different reference Printer for printing all document part Flash to transfer data from one computer to other.Software Edraw max for the drawing of some diagrams like use case diagram PHP (XAMPP) server and MYSQL to develop our data base system. Microsoft word for any requirements like that of writing our documentation. Macro Dreamweaver to develop the static web page of our project and to done dynamic page 5.6.Data preparation and installation 5.6.1 Data preparationData Preparation involves checking or logging the data, checking the data for accuracy, entering the data into the computer, transforming the data and developing and documenting a database structure that integrates the various measures. 5.6.2 Installation Because our project is a web based application installation of the system is not needed .the way to use the website is hosting on the web server by giving a public IP address.

5.7. Testing strategiesDeveloping software is a complex business. No matter how hard we try, we wont be able to eliminate all faults simply by going through the phases of requirements, analysis, design, specification, and implementation .however through good practice we can make sure that the most series fault does not occur in the first place. In addition we need a separate testing phase, with the goal of elimination all remaining faults before release.Testing a code and other artefacts as we go along the development of the system help us to acquire the following advantage:It improves the quality of the software It reduces the cost of the testing phases It shows the programmers that they are making real progressIt reduces the number of faults that are linked to the program during the testing phase.It helps programmers to reorganize their code, for style performance reasons, without breaking anything that has already written.To simplify the testing process the project team followed the different types of tests that break the testing process up into the distinct levels. These types testing are unit testing integration testing and system testing.Unit test: Each module is tested alone in attempt to discover any error in its code but since modules exist and work with other modules in programs and system they must be tested in longer groups.Integration test: The process of bringing together all of the modules that a program comprises for testing purposes. Modules are typically integrated in top won incremental fashion.System testing: a test performed on an entire system ensures that application programs written and tested in isolation work properly when integrated into the total system.

5.8. Start up strategy.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 services provided by the website. There are two type of user: 1. Membered customer: this customer must go to the station office in order to be a member.2. Un-membered customer: Customer that is not registered as member of the bus station can view information about bus station, bus profile, and schedule.Part Six: Conclusion and Recommendation6.1.ConclusionsIt is known that developing a system for an organization is not easy. But the team have tried its best and developed interesting system of online bus ticket reservation for kombolcha town. It is flexible, accurate and attractive with easy GUI approach. Generally, the team confidently can say that the software is completed successfully with negligible errors. Finally the team expects the software will change the general business atmosphere of the Organization and market it more profitable than the previous manual system.6.2. RecommendationAccording to scope of our project the team develops web application .Because of the time constraint we cannot do beyond to our scopes, but in the future the team believes that this system can be fully operational by having enough time and fully information. Finally 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 ticketing system, for those who would like to work online bus ticket reservation system its recommended to do more work on the functionalities such as:- Alert expired date of product Alert if products are short Integrating visa card with the systemAppendixAppendix A: List of references1. An_Integrated_Approach_to_Software_Engineering_By_Pankaj_Jalote2. JEDI Slides-2.1 Object-oriented Concepts3. Object-Oriented Software Engineering, 2nd Edition4. Constantine and Lockwood 1999Appendix B: Internet Site www.google.com www.yahoo.com www.codeproject.com www.htmldrive.net www.stackoverflow.com www.w3schools.com www.filehorse.com www.easycodephp.net

1 | Page

Customer

Sequence

Bus station

Customer initiate to browse

Enter website in web search engine

Journey schedule

Web browser

If correct webpage is displayed

If incorrect

If correct from webpage click on journey schedule

Schedule displayed

View schedule

Procedure1.Every customer initiate to browse bus station.2.enter website in web search engine.3.if website is correct bus station page is displayed 4.finally customer view journey schedule.

Customer

Sequence

Bus station

Customer initiate to browse

Enter website in web search engine

Journey schedule

Web browser

If correct webpage is displayed

If incorrect

If correct from webpage click User page then click on Bus profile

Bus profile is displayed

View buses information

Procedure1.Every customer initiate to browse bus station.2.enter website in web search engine.3.if website is correct bus station web page is displayed 4.then go to user page and click on bus information5.bus information is generated.6.finally every customer can view about bus profile.

Client:BrowserSystem Administrator

Member costomer

Web ServerDatabase ServerCustomer Registration

Bus owner Registration

Add manual Schedule

Generate Ticket

Amount Confirmation

Ticket request

Non-Member Customer

View Schedule

View Bus Information

Persistence

Documents

Bus Station Project