RICM4 2017 2018 - UltraTeamMV : UML

=Usecase= Use case are here divided into two parts :
 * A higher level one (referred to as H), more user centered and especially understandable by the client. It will be called H.
 * A lower level one (referred to as L), centered on in-solution communication, depicting how users (ESP32, smartphone) make use of the implemented protocol. It will

End user → Read self geolocation on 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

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

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


 * 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).

End user → Read other hikers’ geolocation on 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

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

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


 * 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 → Read specific hiker's geolocation on 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

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

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


 * 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


 * 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).

End user → Create a course

 * Pre-condition :
 * Application is launched on home page.

Course does not exist.
 * Start:

A course was created. Application generated an AES encryption key.
 * End:


 * 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 → Join a course

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

End user is not enrolled in the given course.
 * Start:

End user is enrolled in the given course.
 * End:


 * 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 user → Display connected devices list

 * Pre-condition :
 * Smartphone is on and on "display devices" page

The page is blank.
 * Start:

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


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

End user → Send a distress state signal
User is in a distress state. Only him knows about it.
 * Start:

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


 * Normal execution
 * 1) User clicks on ESP's button or Smartphone SOS button


 * Non-functional constraint
 * User should be physically able to click button

Administrator → Update application

 * Pre-condition :
 * Administrator is able to push version to user's smartphone.

Application version is at level X on user's smartphone.
 * Start:

Application version is at level Y with Y > X on user's smartphone.
 * End:


 * Normal execution
 * 1) Administrator detects a possible enhancement in application (debug, new feature,...),
 * 2) Administrator develops this enhancement,
 * 3) Administrator sends new version to end user,
 * 4) User updates application.


 * Non-functional constraint
 * Update should be as transparent to user as possible,
 * Bugfixes should be done as fast as possible,
 * New version should allow retro-compatibility.

ESP32 BLE connection establishment with smartphone

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

ESP32 and smartphone are disconnected.
 * Start:

ESP32 and smartphone are connected via BLE.
 * End:


 * 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.

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

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


 * 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

ESP32 is aware of another user's distress state.
 * Start:

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


 * 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:

The geolocation information was sent by LoRa.
 * End:


 * 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.

Geolocation signal forward from another ESP32 to smartphone via BLE

 * Pre-condition :
 * ESP32 & smartphone are connected.

ESP32 is aware of a geolocation information received from another ESP32 via LoRa;
 * Start:

Smartphone is aware of this information.
 * End:


 * Normal execution
 * 1) ESP32 parses received geolocation signal.
 * 2) ESP32 sends BLE packet to smartphone.
 * 3) Smartphone parses received packet.
 * 4) Smartphone adds given information to its database.

Distress signal transfer from another ESP32 to broadcast via LoRa
ESP32 is aware of a distress signal.
 * Start:

A distress signal was sent by broadcast via LoRa.
 * End:


 * Normal execution
 * 1) ESP32 parses a received LoRa distress signal.
 * 2) ESP32 sends a LoRa packet in broadcast with same data.


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

Template

 * Pre-condition :


 * Start:


 * End:


 * Normal execution


 * Alternative execution

[Suggestions :]
 * Non-functional constraint
 * 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 =