Design and Planning

Sprint2 Report - Design and Planning

Team 16

Document Revision History

Rev. 1.0 2019-10-18 - Initial version

System Architecture

Components

• API gateway
• gRPC gateway
• User
• Group
• CarpoolRequest

API Gateway component in charges of communicating with client application with REST API. gRPC Gateway component comunicates with client application with gRPC. And all components are not dependent on each other. They just publish events and each component subscribe events through Event bus Redis.

Design Detail

Service Flow (Internal Interface)

Entity Relationship

REST Spec

HTTP Data Format

• RequestCarPool (CarpoolRequest) - POST /api/carpool

  • request

      {
      	"Authorization": <access_token>
      }
      ---
      {
      	user_id: number,
      	from: string,
      	to: string,
      	minimum_passenger: number
      }
    

  • response

      {
      	request_id: number,
      	rider: {
      		id: number,
      		created_at: date
      	},
      	created_at: date
      }
    

• CancelCarPool (CarpoolRequest) - DELETE /api/carpool

  • request

      {
      	"Authorization": <access_token>
      }
      ---
      {
      	user_id: number,
      	request_id: number
      }
    

  • response

      {}
    

• Login (User) - POST /api/auth/login

  • request

      {
      	email: string,
      	password: string
      }
    

  • response

      {
      	user_id: number,
      	access_token: string
      }
    

• Register (User) - POST /api/auth/register

  • request

      {
      	email: string,
      	password: string,
      	vehicleInfo: {
      		carType: string,
      		plate: string
      	}
      }
    

  • response

      {}
    

• OnTaxi (from Rider) (Group) - PUT /api/group/taxi/riders

  • request

      {
      	"Authorization": <access_token>
      }
      ---
      {
      	rider_id: number
      
      }
    

  • response

      {}
    

• Departure (from Driver) (Group) - PUT /api/group/taxi/departure

  • request

      {
      	"Authorization": <access_token>
      }
      ---
      {
      	group_id: number,
      	departure_time: date
      }
    

  • response

      {}
    

• NotifyDriverLocation (from Driver) (Group) - PUT /api/group/taxi/location

  • request

      {
      	group_id: number,
      	<google map API result>
      }
    

  • response

      {}
    

• ConfirmCost (from Driver) (Group) - PUT /api/group/cost

  • request

      {
      	"Authorization": <access_token>
      }
      ---
      {
      	group_id: number,
      	total_cost: number
      }
    

  • response

      {
      	total_cost: number,
      	premium_cost: number
      }
    

• ChargePoint (from User) (User) - PUT /api/user/point

  • request

      {
      	"Authorization": <access_token>
      }
      ---
      {
      	user_id: number,
      	point: number
      }
    

  • response

      {
      	current_point: number
      }
    

• PointToCash (from User) (User) - GET /api/user/cash

  • request

      {
      	"Authorization": <access_token>
      }
      ---
      {
      	user_id: number,
      	point: number
      }
    

  • response

      {
      	current_point: number
      	cash: number
      }
    

gRPC Data Format

• NotifyGroupCreated (Rider, Driver)

  • data

      {
      	group: Group,
      	created_at: date
      }
    

• NotifyRequestTimeout (Rider)

  • data

      {
      	rider: Rider,
      	request: Request
      }
    

• NotifyRiderOnTaxi (Driver)

  • data

      {
      	group: Group,
      	rider: Rider
      }
    

• NotifyDriverCanGo (Driver receive)

  • data

      {
      	group: Group
      }
    

• NotifyDriverDeparture (Rider receive)

  • data

      {
      	group: Group
      }
    

• NotifyDriverLocation (Rider)

  • data

      {
      	driver: Driver, 
      	<google map API result>
      }
    

• NotifyConfirmedCost (Rider)

  • data

      {
      	group: Group,
      	rider: Rider,
      	total_cost: number,
      	premium_cost: number, 
      	my_cost: number,
      	remaining_point: number
      }
    

Service UI (External Interface)

Functionality and requirements

• IntroPage
  • Functionality
    • Introduction & explanation of service, login, register
  • Requirements
    • LoginPage
      • User inputs email and password
      • On clicking confirm button, rider moves to Request Page
      • On clicking confirm button, driver moves to RequestCall Page
    • RegisterPage
      • User inputs email, password, password verification
      • If user is driver, user inputs vehicle info
      • If user is rider, user leaves vehicle info blank
      • On clicking confirm button, the Register tab disappears, leaving the user back on Intro page
• RequestPage
  • Functionality
    • Allows rider to request a carpool
  • Requirements
    • Rider inputs departure point, destination, minimum number of passengers
    • All inputs are made by clicking corresponding checkbox
    • On clicking Request button, rider moves to Waiting page
    • If the rider has insufficient funds, an alert message pops up
• WaitingPage
  • Functionality
    • Rider waits for a confirmation response from server
  • Requirements
    • Server sends response when riders and a driver form a group
    • When server responds, rider moves to Group Page
    • Max. waiting time is set to 3 minutes
    • If waiting time expires, rider returns to Request Page
    • If rider clicks Cancel button, rider returns to Request Page
• RequestCallPage
  • Functionality
    • Shows current groups waiting for a driver match
    • Allows driver to accept with voice recognition
  • Requirements
    • The screen shows a new carpool request every 5 seconds
    • If a request is shown on the screen, the driver clicks the accept button
    • Saying the required keyword can also activate the accept button
    • On clicking the accept button, driver moves to Group page
• GroupPage
  • Functionality
    • Shows the departure location, driver's current location and driver's vehicle info
    • Shows group members and onTaxi status
    • Allows driver to press Go button when required conditions are met
  • Requirements
    • When rider gets on taxi, rider clicks onTaxi button
    • On clicking onTaxi button, rider's onTaxi status becomes true
    • When all group members' onTaxi status become true, driver's Go button becomes activated
    • Max. waiting time is set to 3 minutes
    • If waiting time expires before all onTaxi status become true, driver's Go button becomes activated
• DetailPage
  • Functionality
    • For the rider, shows the estimated time of arrival and estimated fare
    • For the driver, allows driver to input actual fare and confirm it on arrival
  • Requirements
    • Driver inputs actual fare and clicks confirm button
    • On clicking confirm button, rider and driver move to Final Page
• FinalPage
  • Functionality
    • Shows all money-related details to riders/drivers
  • Requirements
    • The final taxi fare is shown to the driver
    • The fare charged to the riders (taxi fare / number of passengers) is shown to the rider

Front Component

Implementation Plan

Frontend

Backend

Testing Plan

• Unit Testing
  • Every components and modules should be tested.
  • A component will be tested after it is created.
  • By Sprint 3, we expect to create and finish testing of front end modules and components.
  • By Sprint 4, we expect to create and finish testing of User, Driver, Rider models.
  • By Sprint 5, we expect to create and finish testing of Group and CarpoolRequest models.
  • We expect the code coverage to be over 80%
    • React: redux-saga-tester, Jest, react-testing-library
    • Django: Python unit test
• Functional Testing
  • By Sprint 3, User and CarpoolRequest APIs should be tested.
  • By Sprint 4, Group API should be tested.
  • When we are testing service related with infra such as MySQL, Redis, we are going to use mocks to remove dependency.
  • We expect the code coverage to be over 80%
    • React: redux-saga-tester, Jest, react-testing-library
    • Django: Python unit test
• Acceptance & Integration Testing
  • We will use cucumber testing as shown in the slides.
  • We will use Travis CI, Husky and Coveralls for integration testing.
    • Acceptance Testing: Cucumber
    • Integration Testing: Travis CI, Husky, coveralls