Case Study:Metrobus Information System

Background Information(Client Requirement)

Metrobus wants a system that will provide timetable and route
information to visitors its website. Visitors will be able to view information
about all routes provided by Metrobus, including variant paths on those
routes. They'll be able to view timetables for services on the routes. But
more than that the system will take advantage of computer technology to
allow visitors to find the nearest bus stop to a street address or landmark,
or to plan journeys using the Metrobus network. When planning journeys
visitors will be able to decide if they want to minimise the distance
travelled, time taken or number of transfers made. Whatever information
they want they'll be able to print it in text-based or map-based format (as
appropriate), for future use. Obviously, over time the routes offered, stop
locations and and even the times between stops change. Sometimes the
changes are small, such as adding a new service on a route, sometimes
they are huge, such as adding a whole new route. So to keep the system
up to date administrators will need to be able to update route, path, stop
and timetable information.

Exercise 1: Inception: Vision Document

1.1 Identify the stakeholders and their interests.

Admin
need to be able to update route, variant path, stop and view all
timetable information.
User
will be able to view information about all routes provided by
Metrobus, including variant paths on those routes find the nearest
bus stop to a street address or landmark or to plan journeys using
the Metrobus network
decide if they want to minimise the distance travelled,time taken or
number of transfer made.

1.2 Identify the actors and their goals.

Actors
Admin manage timetable information,manage all company
information for customer.

User customer can know the time table of destination and can
make the own choice to booking seat,time and destination.
Customer are always notified of changes timetable of journey.
Goals

Facilitating the client to determine the travel time and destination to

be ditujudan save time in buying bus tickets

Exercise 2: Requirements Gathering: Use Case Diagrams

2.1 Create a first-cut use case diagram for the two key actors in
the system
User

Print ticket

Booking ticket

Registration

Admin
Check new update of
timetable schedule

Update company information

2.2 Identify areas of included and extended functionality in the

use case model, and refine it accordingly.
Admin

Want to make sure that the system will always up with new update
timetable and update company information.

User

customer can know all new information about metrobus system .

Exercise 3: Requirements Gathering: Use Case Descriptions

3.1 Describe the happy path for the "Add a Service" use case.

If the user wants to buy tickets online, users need to interface

metrobus system we provide, the user only needs to enter the
metrobus system interface and fill the important details such as
name, Their telephone number, date and time to be boarded by the
user user.If identified the decision to buy a ticket metrobus, the
user must click the button submit, After submit, it will display what
is required by the user such as user names, numbers their
telephone, date and time to be boarded, the license plate number of
buses and the number of seat, the user must print details
tersebut.All customer information to buy tickets online by metrobus
will go into admin.

3.2 Define the pre and post conditions.

Precondition :
Admin is identified and authenticated.
Postcondition:
The information of route, path, stop and timetable information is
updated.

3.3 Add alternate and exception scenario steps to the

description as apt.

Another alternate that can be add , customer can book the ticket
before the day of the journey.

Exercise 4: Prototyping: User Interface Sketching

4.1 Sketch the UI for "Add a Service".

4.0
ADD SERVICE

**Please input a service that you want in the box provided and
click OK

OK

4.2

CANCEL

4.2 Sketch the UI for "Plan a Journey".

METROBUS
BOOKING YOUR TICKET HERE

NAME

NO PHONE

TIME

DESTINATION :

RESET

Exercise 5: Analysis: Domain Modelling

5.1 Draw the domain model for the Metrobus Information

System.

Interface
Common function

+display company information

+display timetable destination,
time, seat
+display nearest bus stop

User
Admin
+view timetable
destination

Request

+booking
tiket,seat,destination

+update new company

information
+update timetable
destination
Request

+add service

Print

<output>
Resit
+time
+destination
+date
+bus plat number
+seat number

Exercise 6: Analysis: Sequence Diagrams

6.1 Draw the sequence diagram for "Add a Service" (happy

path). Make sure that it is consistent with the use case
description.

Web site

User

Customer
registration

Submit request
Process information

View timetable
Booking ticket

authorize
OK

Print resit/info

Admin

Exercise 7: Design: Class Diagram

7.1 Draw the overall class diagram for the Metrobus Information
System.

Route

Stop

Id
integer(10)
Fare

Id
integer(10)
Name
varchar(25)

Schedule
Routeid
varchar(25)
Id
integer(10)
Departure
date

Route_stop
Routeid
varchar(25)
Stopid
integer(10)

Bus
Scheduleid
integer(10)
Vehicle
integer(10)
Fleet_id

Exercise 8: Design: Logical Architecture

8.1 Sketch the logical architecture for the Metrobus Information

system.
Computer

Firewall
Moderm
intern
et

DatabaseFirewall

Database

Databa
se
Server

Firewall

Moder

Server

Printer

Compute
r
Printer

Computer

Exercise 8: Design: Logical Architecture

8.1 Sketch the logical architecture for the Metrobus Information

system.

User

Web Site

Admin

Portal Web

Submit

Customer Registration

Booking

View timetable

Process Information

Exercise 9: Design: Use of Pattern

9.1 Identify an area of the system where low coupling and high
cohesion

can

be

achieved

through

good

object-oriented

analysis and design. Briefly explain.

In software design cohesion means that class should do one thing

and one thing very well.High cohesion is closely related to single
responsibility principle.

Low coupling suggest that class should have least possible

dependencias that must exits should be week dependencies prefer
dependency cyon interface rather than dependency on concrete
class.

9.2 How appropriate is the Model-View Separation Principle for

this kind of system?

Do not put application (such as a tax calculation) in the UI object

methods .UI object should only initialize UI elements.,receive UI
event(such as a mouse click on a button).