RICM4 2017 2018 - UltraTeamMV : UML

From air
Revision as of 13:50, 12 February 2018 by Enzo.Molion (talk | contribs) (Geolocation information sending by ESP32 via LoRa)
Jump to navigation Jump to search

Usecase

Graph

UltrateamMVUseCaseUML.png

Case details

End user own geolocation reading on the map

Pre-condition
  • Smartphone should be on, with a loaded map into the app
  • The geolocation should be stored in the app
  • The UI should be on map page
Start

The smartphone does not display anything, the page is blank.

End

The smartphone displays the map with a marker on end user's geolocation

Normal execution
  1. Smartphone loads geolocation from application
  2. Smartphone loads relevant map part
  3. Smartphone displays map
  4. Smartphone displays end user's geolocation as a marker
Alternative execution
  • If map can't be loaded or displayed, redirect to another page and display an error message
  • If geolocation can't be loaded, display a loaded map and display an error message
Non-functional constraint
  • Loading should take less than 2 seconds as it is a main feature hence frequently used.
  • Map should be readable even in a non urban area (a acceptable default zoom level shall be used).


Read other hikers’ geolocation on the map

Pre-condition
  • Smartphone should be on, with a loaded map into the app
  • The other hikers’ geolocation should be stored in the app
  • The UI should be on map page
Start

The smartphone does not display anything, the page is blank.

End

The smartphone displays the map with a marker on every other hikers’ geolocation

Normal execution
  1. Smartphone loads other hikers’ geolocation from application
  2. Smartphone loads relevant map part
  3. Smartphone displays map
  4. Smartphone displays other hikers’ geolocation as a marker
Alternative execution
  • If map can't be loaded or displayed, redirect to another page and display an error message
  • If an other hikers’ geolocation can't be loaded or displayed, proceed as if it did not exists


End user own geolocation reading on the map

Pre-condition
  • Smartphone should be on, with a loaded map into the app
  • The geolocation should be stored in the app
  • The UI should be on map page
Start

The smartphone does not display anything, the page is blank.

End

The smartphone displays the map with a marker on end user's geolocation

Normal execution
  1. Smartphone loads map
  2. Smartphone displays map
  3. Smartphone loads geolocation from application
  4. Smartphone displays end user's geolocation as a marker
Alternative execution
  • If map can't be loaded or displayed, redirect to another page and display an error message
  • If geolocation can't be loaded, keep map displayed and display an error message
Non-functional constraint
  • Loading should take less than 2 seconds as it is a main feature hence frequently used.
  • Map should be readable even in a non urban area (a acceptable default zoom level shall be used).


Read specific hiker’s geolocation on the map

Pre-condition
  • Smartphone should be on, with a loaded map into the app
  • The other hiker’s geolocation should be stored in the app
  • The UI should be on map page
Start

The smartphone does not display anything, the page is blank.

End

The smartphone displays the map centered on a marker displaying other hiker’s geolocation

Normal execution
  1. Smartphone loads specific hiker’s geolocation from application
  2. Smartphone loads map
  3. Smartphone displays map centered on
  4. Smartphone displays other hikers’ geolocation as a marker
Alternative execution
  • If map can't be loaded or displayed, redirect to another page and display an error message
  • If an other hikers’ geolocation can't be loaded or displayed, proceed as if it did not exists


End user course creation

Pre-condition
  • Application is launched on home page.
Start

Course does not exist.

End

A course was created. Application generated an AES encryption key.

Normal execution
  1. User clicks on "Create course"
  2. AES encryption key is generated
  3. A QRCode is displayed on screen or smartphone starts to send data via NFC
Alternative execution
  • If something goes wrong, smartphone should display a "cancel | recreate course" button
Non-functional constraint
  • Course should be under 10 seconds
  • Smartphone display should be large and bright enough for other users to flash it or smartphone should be equipped of an NFC chip


End user course join

Pre-condition
  • Another physically near user shall have created a course,
  • Application is launched on home page.
Start

End user is not enrolled in the given course.

End

End user is enrolled in the given course.

Normal execution
  1. Users clicks on "Join course" button,
  2. Users clicks on "Via QRCode" or "Via NFC" button,
  3. Camera opens or NFC starts to listen, and code is received,
  4. Received code is stored into the application.
Alternative execution
  • If nothing is received in a given time, display a help message


End users connected devices display

Pre-condition
  • Smartphone is on and on "display devices" page
Start

The page is blank.

End

The page is filled with connected (or not) devices information.

Normal execution
  1. Smartphone sniffs connected devices and their relevant info,
  2. Smartphone displays those information.


End user distress state signal

Start

User is in a distress state. Only him knows about it.

End

User is in a distress state. The smartphone or ESP32 is aware of this situation.

Normal execution
  1. User clicks on ESP's button or Smartphone SOS button
Non-functional constraint
  • User should be physically able to click button


ESP32 BLE connection with Smartphone establishment

Pre-condition
  • ESP32 & Smartphone are on, with BLE running,
  • ESP32 & Smartphone are near enough to communicate via BLE.
Start

ESP32 and smartphone are disconnected.

End

ESP32 and smartphone are connected via BLE.

Normal execution
  1. User pairs devices via its smartphone's OS settings, as any other BLE device.
Non-functional constraint
  • BLE on ESP32 & on smartphone should be technologically able to communicate


Distress signal transmission from ESP32 to smartphone via BLE

Pre-condition
  • ESP32 & Smartphone should be connected via BLE,
  • The end user has generated a distress signal on its ESP.
Start

ESP32 is aware of a user distress state. Smartphone is not aware of this situation.

End

Both ESP32 and smartphone are aware of a user distress state.

Normal execution
  1. ESP32 sends a BLE packet to smartphone to inform it of distress state.


Distress signal transfer from another ESP32 to smartphone via BLE

Pre-condition
  • ESP32 & Smartphone should be connected via BLE
  • Another ESP32 sent a distress signal
Start

ESP32 is aware of another user's distress state.

End

Both smartphone and ESP32 are aware of the other user's distress state.

Normal execution
  1. ESP32 receives signal, detects that it is a distress,
  2. ESP32 sends a BLE packet to smartphone to inform it of distress state.


Geolocation information sending by ESP32 via LoRa

Pre-condition
  • ESP32 is on and has a geolocation information to send.
Start

∅

End

The geolocation information was sent by LoRa.

Normal execution
  1. ESP32 sends a LoRa packet containing geolocation information, by broadcast.


Non-functional constraint
  • ESP can not talk more than 1% of the time via LoRa.


Template

Pre-condition
Start


End


Normal execution
Alternative execution
Non-functional constraint

[Suggestions :]

  • Time
  • Cost
  • Direct environment constraints (physical environment, connections, interfaces, safety, testability, deployment...)
  • Indirect environment constraints : PESTLE analysis (Political, Economic, Social, Technological, Environmental, Legal)

Sequence diagram

Deployment diagram

Activity diagram

Relationship diagram

Retrieved from "https://air.imag.fr/index.php?title=RICM4_2017_2018_-_UltraTeamMV_:_UML&oldid=39731"