Smart Taxi Case Study

ToBe Analysis

This case study describes the Smart Taxi Application system which is designed to manage normal situations (i.e. SMS arrival and SMS proximity scenario) as well as the handling of  link building special cases (i.e. arrival of unexpected events or Traffic Info Events). Such special cases include several different actions, such as the adaptation of the process flow as well as the management of Operator intervention. The actors involved in this case study are Customers, Drivers and Taxi Operator.

The S-Cube approach suggests a way to describe and classify case studies with the objective to make them comparable and reusable in the context of different projects. In this toBe Analysis, we will use the S-Cube formalism. According to the methodology, a case study is described in terms of:

• Business Goals and Domain Assumptions for the case study.
• Domain description.
• List of Scenario descriptions

These items are listed and explained below.

Business Goals

Business Goals define objectives to be pursued and functionalities to be offered. The following tables describe business goals relevant to the Smart Taxi Application.

Table BG1. Business Goal TAXI-BG-01
Field	Description
UniqueID	TAXI-BG-01
Short Name	Put in relationship a customer and a Taxi driver (from a taxi company)
Type	Business Goals.
Rationale	Need to put in relationship Customer and driver finding the closest driver and optimized driver's path to provide the most efficient service.
Involved Stakeholders	Taxi Company, Drivers , Customers
Priority of accomplishment	Must have.

Table BG2. Business Goal TAXI-BG-02
Field	Description
UniqueID	TAXI-BG-02
Short Name	Improve the Quality of Service by managing unexpected events and traffic jam events
Type	Business Goals.
Description	The system should react on different changed Taxi situations. For instance, the system shall properly react and be able to manage the case of Taxi accidents and unexpected events, as well as major traffic jam conditions. In those situations, the system shall execute new control and management strategies.
Rationale	Need to react autonomously on unexpected and unforeseen situations.
Involved Stakeholders	Taxi Company, Drivers , Customers
Priority of accomplishment	Must have.

Table BG3. Business Goal TAXI-BG-03
Field	Description
UniqueID	TAXI-BG-03
Short Name	Facilitate the relationship by detecting proximity between the taxi and the customer
Type	Business Goals.
Description	The system shall react by managing the proximity between the Taxi and the Customer.
Rationale	The Customer is alerted when the taxi is very close.
Involved Stakeholders	Taxi Company, Drivers , Customers
Priority of accomplishment	Must have.

Table BG3. Business Goal TAXI-BG-04
Field	Description
UniqueID	TAXI-BG-04
Short Name	Human intervention
Type	Business Goals.
Description	The system notices that no taxi will be available in the near future and a new call arrives from a customer: The system must react by giving the control to an Operator that will choose the right decision
Rationale	Taxi Operator chooses the decision to keep taxis available for emergency issues.
Involved Stakeholders	Taxi Company, Drivers, Customers
Priority of accomplishment	Must have.

Domain Assumptions

Domain Assumptions describe properties that are assumed to be true in the domain. The following tables describe domain assumptions relevant to the Smart Taxi Application.

Assumption TAXI-DA-01
Field	Description
UniqueID	TAXI-DA-01
Short Name	Devices : Smartphone's
Type	Domain assumption
Description	The Customers and the Taxi drivers use Android smartphones. The smartphones send and receive Location info, Presence info and Messages
Involved Stakeholders	Taxi driver, Customer
Supporting Material	Smartphones

Assumption TAXI-DA-02
Field	Description
UniqueID	TAXI-DA-02
Short Name	Location & Presence Services must be running to deliver Events.
Type	Domain assumption
Description	Service provided by the Telco Operator
Involved Stakeholders	Telco Supplier
Priority of accomplishment	Must have.

Assumption TAXI-DA-03
Field	Description
UniqueID	TAXI-DA-03
Short Name	GIS Service
Type	Domain assumption
Description	A GIS Service must be available to calculate and deliver routes to the Taxi Application
Involved Stakeholders	Taxi Company, Telco Supplier, Customer
Priority of accomplishment	Must have.

Assumption TAXI-DA-04
Field	Description
UniqueID	TAXI-DA-04
Short Name	Info Traffic Center
Type	Domain assumption
Description	An Info Traffic Service must be available to deliver traffic information
Involved Stakeholders	Traffic Info Server hosted by the Telco Operator
Priority of accomplishment	Must have.

Domain Analysis

Domain analysis is used to define the application domain, collect information about the domain, and produce a domain model.

Strategic Dependency Model

These diagrams are used to model the dependencies between the different actors in the context. They especially help to model user (roles) together with their relations.

The following Figure 28 illustrates the strategic dependency diagram mapped to our context. The diagram puts in evidence the business goals shared among the related actors.

Figure 28: Dependency Diagram

Context Diagram

Figure 29 illustrates the context diagram of the current case study. In the context diagram, all the actors that appear in the business goals and scenarios are agents.

Figure 29: Context Diagram

Domain Model

The figures below illustrate the domain model of the current case study, smart taxi.

Event types

The following picture, Figure 30, describes incoming and outgoing Events from the smart taxi use case perspective. The event class (com.orange.play.eventData.event) is the root class. All events inherit from this class and are sub-classified as inEvents (incoming events) or outEvents (outgoing events).

Figure 30: Event Type Hierarchy

High Level Interaction - Customer's View

Figure 31: Sequence Diagram, Customer Interaction

Description

This sequence diagram, Figure 31, shows how the customer application interacts with the DCEP through the PLAY Platform (federated middleware). The customer Application starts sending a presence event with the "registerCustomer" message to receive a sessionId for the future transactions. The customer needs to get the available companies, so the customer application calls the "getCompanies" service to retrieve the company list. Through his application the Customer selects the company and sends his choice in a "chooseCompany" message. The Customer application can now start the geolocation sending the "startLocalize" message. The Customer application is now able to regularly send the Customer location using "receiveInEvent" with a geolocation event as "inEvent".

In backEnd the PLAY Platform forwards the events to the DCEP platform integrating the scenario rules. According to incoming events the DCEP will trigger actions or events. When the customer is done with his request or service needs, he can use his application to stop the geolocation and unregister his session.

High Level Interaction - Driver's View

Figure 32: Sequence Diagram, Driver Interaction

Description

The driver starts working, Figure 32, and run his Driver's application on his smartphone. The application starts registering the Driver within the "TaxiService" platform. The Driver's application gets a sessionId for the future transactions and start sending the Driver's geolocation with a "startLocalize" message.

The Driver can now start working and his application will send events such like "geolocation" events or status events to the Federated middleware which will forward the information to the DCEP backend triggering events or actions.

Whenever the Driver wants to stop the service he can send a "stopLocalize" message to the "TaxiService" interface and unregister his current session.

Scenarios

Figure 33: Taxi Use Case

Scenario 1 - SMS Arrival

Table S1: Scenario TELCO-S-1
Field	Description
UniqueID	TELCO-S-1 - SMS Arrival
Involved Actors	Customer , Taxi Driver
Detailed Operational Description	A Call or a SMS is sent to a Taxi company number (which is supplied by Orange - Taxi Application), by a customer expecting a taxi. Based on the phone number, a location request is sent. As a result, a location event (X, Y) is received, associated with the customer request. In parallel, Taxi Availability Events, IMS presence Events, and Taxi Location are sent to Taxi application, producing a list of available taxis and their Location. From those information, using the GIS partner services to compute and compare the Customer-Taxis Path, the proper Taxi can be chosen (the available one, whose path is shortest to the Customer) and the proper Path (the shortest, where no TAXI Event has occurred) the taxi should use. Then, an SMS is sent to the Customer to inform him about the Taxi, a MMS is sent to the Taxi with the map & Path to pick up the Customer, and the references of this treatment are stored.
Additional Material	The following diagrams describe the process: Use Case diagram Sequence Diagram

Figure 34: Use Case, SMS Arrival

Description

This Use Case diagram represents the SMS arrival case where the Customer sends a taxi query, via SMS, to the Play Platform. The "CustomerLocation" is retrieved through a "GeoLocFromNum" third part service exposed by the Telcos supplier.

According to the localization of the customer the Platform will select the closest available taxi, through the SIG Partner service (which is a traffic info service providing path calculation/optimization from a point A/point B itinerary information), and advise the Customer and Taxi with the relevant information such like the road path (in the MMS sent to the Driver).

Figure 35: Sequence Diagram, SMS Arrival

Description

This sequence diagram represents the same scenario as before but in sequence. The Customer starts sending a "taxiQuery" to the federated middleware (FM) which uses a telco supplier service to retrieve the customer location through his phoneNumber.

The FM gets the closest available taxi checking the distance between taxis and customer through the SIG Partner.

The FM finishes sending SMS information to the customer and MMS information, including map, to the Driver.

Scenario 2 - SMS Proximity

Table S2: Scenario TELCO-S-2
Field	Description
UniqueID	TELCO-S-2 - SMS proximity
Involved Actors	Customer , Taxi Driver
Detailed Operational Description	Taxi Application keep receiving Taxis location, and using the stored reference compute regularly the distance between the selected Taxi and the requesting Customer. When the distance between them is close enough, an SMS is sent to the Customer to inform him of the Taxi arrival.
Additional Material	The following diagrams describe the process: Use Case Diagram Sequence Diagram

Figure 36: Use Case, SMS Proximity

Description

This use case diagram describes the SMS proximity scenario. When the Play Platform (FM) receives the driver location, the Platform checks the distance between the taxi and its assigned customer. The Customer current location is retrieved through the Telco provider service. When this distance gets small the Platform sends an SMS to the Customer to advise him about the taxi proximity.

Figure 37: Sequence Diagram, SMS Proximity

Description

This sequence diagram describes the same scenario but in sequence. The Taxi Driver's application sends regularly its current location. If the Taxi is on the road to pick up a customer, the Platform gets the customer location through the telco supplier service. The Platform can now compute the distance between the Customer and his assigned taxi. When they are very close, the customer get notified via SMS.

Scenario 1 - Path Optimization

Table S3.1: Scenario TELCO-S-3.1
Field	Description
UniqueID	TELCO-S-3.1 - Path Optimization
Involved Actors	Customer , Taxi Driver
Detailed Operational Description	Taxi Application is also receiving in parallel TAXI Information. For each path known to have a Taxi-Customer treatment running, it requests GIS partner to check whether or not a problem was detected in this route. If yes, a new path is requested to the GIS Partner, an Event is sent to update the concerned stored treatment, an updated Path is sent by MMS to the Taxi, and information of delay is sent to the Customer.
Additional Material	The following diagrams describe the process: Use Case diagram Sequence Diagram

Figure 38: Use Case, Path Optimization

Description

This use case diagram describes how the path optimization works. The goal is to regularly check the shortest path between the taxi and its assigned customer. The federated middleware uses a third part service proposed by the SIG Partner to get the traffic jam status on a road. When the taxi driver, on the road to pick up a customer, sends his current location, the Play Platform calls the third party to get the traffic jam status on this road. If the path isn't the shortest anymore the Platform will advise the taxi driver about his new route and the customer will be notified for the delay.

Figure 39: Sequence Diagram, Path Optimization

Description

This sequence diagram shows how the path optimization does work. First, the taxi driver is regularly sending his position through the currentPosition(X,Y) message. The Play Platform knows if the taxi is on the road to pick up a customer. So, the Play Platform uses the SIG Partner service to check the known path. If there is an incident on the road, a better path is found and sent to the taxi driver as a newPath. The Customer gets also notified via SMS about the delay.

Table S3.2 : Scenario TELCO-S-3.2
Field	Description
UniqueID	TELCO-S-3.2 - Unexpected event
Involved Actors	Customer , Taxi Drivers
Detailed Operational Description	Taxi Application is also receiving in parallel Information from Taxi Company and Taxi in case a problem occurs to the Taxi that is on the way to pick up a Customer. When such an event occurs, a SMS is sent to the Customer to inform him (delay, Taxi changes) and depends on the Application decision, a MMS is sent to a requested new Taxi.
Additional Material	The following diagrams describe the process: Use Case diagram Sequence Diagram

Figure 40: Use Case, Unexpected Event

Description

This use case diagram describes the unexpected event use case (an unexpected event could be a broken down taxi).

The taxi driver sends the event through his application notifying the Play Platform.

The Platform restarts the taxi selection process checking the closest customer to the taxi through the SIG Partner which returns the selected taxi and his path. The broken down taxi is removed from the available taxis list.

The customer gets notified of the delay via SMS and the new selected taxi gets the fare description including the path via MMS.

Figure 41: Sequence Diagram, Unexpected Event

Description

The corresponding sequence diagram shows how the sequence works. It starts with the taxi sending his unexpected event to the Play Platform which computes the new taxi selection using the SIG Partner, like in the SMS arrival scenario. The Platform can then send the MMS to the new taxi and a SMS with the new Taxi information is sent to the customer.

Scenario 4 - Human Decision

Table S4: Scenario TELCO-S-4
Field	Description
UniqueID	TELCO-S-4 - Human Decision
Involved Actors	Customer , Taxi Operator, Taxi Driver
Detailed Operational Description	The last Taxi has been allocated to another customer, so an event is sent to the Application. It automatically sends a "noMoreTaxi notification" to the taxi operator. The next query will be forwarded to the taxi application (which is a console interface to manage/control the application behaviours in live. It is also an interface to interact with the system, so the operator can use it to manage the system).A new taxi query is sent by a customer and the query is forwarded to the taxi operator via the taxi application. In parallel the Application sends a SMS to notify the customer about the delay. The taxi operator tries to find a taxi, via radio, that will be free soon. If there is a taxi that can handle the query, the taxi information is sent to the customer through the platform (SMS). Otherwise an apology message plus a list of partners is sent to the customer through the middleware (SMS).
Additional Material	The following diagrams describe the process: Use Case diagram Sequence Diagram

Figure 42: Use Case, Human Decision

Description

This Use Case diagram describes what happens when there is no more available taxi. When the taxi application finds out that there are no more available taxis, an event is sent to the Play Platform to activate the forwarding service. When the next customer sends his taxi query the forwarding process get triggered.

The query gets forwarded to a taxi operator who manually handles the query. The taxi operator tries to find an available taxi through the radio. If he gets a solution he can send the event to the Play Platform, which will advise the customer, otherwise an event is sent to the Play Platform which will forward an apologize message along with a partner list that the customer can contact.

Figure 43: Sequence Diagram, Human Decision

Description

Here is a representation of the previous use case but in a sequence diagram. The taxi application starts sending a "noMoreTaxi" event to advise the Federated Middleware (FM) of the current situation. The Platform according to a rule activates the forwarding mode.

The next incoming SMS taxi query is forwarded to the taxi operator through the taxi application and the customer is notified about the situation.

The taxi operator tries to find a taxi via radio. If he gets one, he sends a "taxiFound" event to the taxi application which will forward the information to the customer via SMS through the Platform. Otherwise, a "reject" event is sent by the taxi operator to the taxi application which will forward the event to the Platform. In that case, the FM sends an apologetic SMS to the customer with a taxi company partner list.