Difference between revisions of "RICM4 2017 2018 - UltraTeamMV : UML"
Enzo.Molion (talk | contribs) (Application update by administrator) |
Enzo.Molion (talk | contribs) (Change label) |
||
Line 12: | Line 12: | ||
==Case details== |
==Case details== |
||
=== H === |
=== H === |
||
− | ===End user |
+ | === End user → Read self geolocation on map=== |
;Pre-condition : |
;Pre-condition : |
||
* Smartphone should be on, with a loaded map into the app |
* Smartphone should be on, with a loaded map into the app |
||
Line 40: | Line 40: | ||
− | === Read other hikers’ geolocation on |
+ | === End user → Read other hikers’ geolocation on map === |
;Pre-condition : |
;Pre-condition : |
||
* Smartphone should be on, with a loaded map into the app |
* Smartphone should be on, with a loaded map into the app |
||
Line 64: | Line 64: | ||
− | ===End user specific |
+ | === End user → Read specific hiker's 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 |
||
− | |||
− | ;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 |
||
− | # Smartphone loads map |
||
− | # Smartphone displays map |
||
− | # Smartphone loads geolocation from application |
||
− | # 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 |
||
− | |||
⚫ | |||
⚫ | |||
⚫ | |||
− | |||
− | === Read specific hiker’s geolocation on the map === |
||
;Pre-condition : |
;Pre-condition : |
||
* Smartphone should be on, with a loaded map into the app |
* Smartphone should be on, with a loaded map into the app |
||
Line 111: | Line 85: | ||
* If map can't be loaded or displayed, redirect to another page and display an error message |
* 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 |
* If an other hikers’ geolocation can't be loaded or displayed, proceed as if it did not exists |
||
+ | |||
⚫ | |||
⚫ | |||
⚫ | |||
− | === End user |
+ | === End user → Create a course === |
;Pre-condition : |
;Pre-condition : |
||
* Application is launched on home page. |
* Application is launched on home page. |
||
Line 138: | Line 116: | ||
− | === End user |
+ | === End user → Join a course === |
;Pre-condition : |
;Pre-condition : |
||
* Another physically near user shall have created a course, |
* Another physically near user shall have created a course, |
||
Line 160: | Line 138: | ||
− | === End |
+ | === End user → Display connected devices list === |
;Pre-condition : |
;Pre-condition : |
||
* Smartphone is on and on "display devices" page |
* Smartphone is on and on "display devices" page |
||
Line 176: | Line 154: | ||
− | === End user distress state signal === |
+ | === End user → Send a distress state signal === |
;Start: |
;Start: |
||
User is in a distress state. Only him knows about it. |
User is in a distress state. Only him knows about it. |
||
Line 190: | Line 168: | ||
− | === |
+ | === Administrator → Update application === |
;Pre-condition : |
;Pre-condition : |
||
* Administrator is able to push version to user's smartphone. |
* Administrator is able to push version to user's smartphone. |
||
;Start: |
;Start: |
||
− | Application version is at level X on user smartphone. |
+ | Application version is at level X on user's smartphone. |
;End: |
;End: |
||
− | Application version is at level Y with Y > X on user smartphone. |
+ | Application version is at level Y with Y > X on user's smartphone. |
;Normal execution |
;Normal execution |
Revision as of 12:02, 13 February 2018
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
Graphs
H
L
Case details
H
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
- 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
- Smartphone loads geolocation from application
- Smartphone loads relevant map part
- Smartphone displays map
- 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
- 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
- Smartphone loads other hikers’ geolocation from application
- Smartphone loads relevant map part
- Smartphone displays map
- 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
- 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
- Smartphone loads specific hiker’s geolocation from application
- Smartphone loads map
- Smartphone displays map centered on
- 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.
- Start
Course does not exist.
- End
A course was created. Application generated an AES encryption key.
- Normal execution
- User clicks on "Create course"
- AES encryption key is generated
- 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.
- Start
End user is not enrolled in the given course.
- End
End user is enrolled in the given course.
- Normal execution
- Users clicks on "Join course" button,
- Users clicks on "Via QRCode" or "Via NFC" button,
- Camera opens or NFC starts to listen, and code is received,
- 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
- Start
The page is blank.
- End
The page is filled with connected (or not) devices information.
- Normal execution
- Smartphone sniffs connected devices and their relevant info,
- Smartphone displays those information.
End user → Send a 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
- 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.
- Start
Application version is at level X on user's smartphone.
- End
Application version is at level Y with Y > X on user's smartphone.
- Normal execution
- Administrator detects a possible enhancement in application (debug, new feature,...),
- Administrator develops this enhancement,
- Administrator sends new version to end user,
- 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.
L
ESP32 BLE connection establishment with smartphone
- 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
- 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
- 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
- ESP32 receives signal, detects that it is a distress,
- 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
- 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.
- Start
ESP32 is aware of a geolocation information received from another ESP32 via LoRa;
- End
Smartphone is aware of this information.
- Normal execution
- ESP32 parses received geolocation signal.
- ESP32 sends BLE packet to smartphone.
- Smartphone parses received packet.
- Smartphone adds given information to its database.
Distress signal transfer from another ESP32 to broadcast via LoRa
- Start
ESP32 is aware of a distress signal.
- End
A distress signal was sent by broadcast via LoRa.
- Normal execution
- ESP32 parses a received LoRa distress signal.
- 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
- 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)