Les diagrammes de déploiement

Définitions et rôle du diagramme de déploiement

Ce diagramme porte sur l’architecture matérielle de l’application, en présentant les différents périphériques intervenant dans le fonctionnement du système. Le but ici est de mettre en avant la répartition des différents composants logiciels et les relations et liens qu’ils partagent. On a donc en relation grâce à des chemins de communication, des manifestations logiques et des spécifications de déploiement, des nœuds mettant en relation des artéfacts (OMG, 2015). Un artefact représente une portion d’information concrète sollicitée ou générée pendant la réalisation et surtout le fonctionnement d’un logiciel. Il s’agit soit de fichiers exécutables (.exe ou .jar), de bibliothèques (.dll), de sources (.java,.php ou .cpp), de fichiers de configuration utilisés par le système (.xml ou. proprerties). Les nœuds quant à eux font référence aux lieux ainsi qu’aux dispositifs où sont déployés ou exécutés les artéfacts (Wrycza et al., 2014).

Mise en œuvre dans l'application

Le système à envisager devra présenter les fonctionnalités suivantes. Tout d’abord, il s’agira d’une application hybride et multiplateforme (sous HTML5, Androïd et iOS), à la fois pour le citoyen et pour l’administrateur. En effet, pouvoir s’affranchir aujourd’hui des contraintes liées aux systèmes d’exploitation (sans oublier bien sûr d’en cibler les plus populaires) permet d’assurer une pérennité et un usage sur du long terme à l’application et de pouvoir s’en servir même si on ne dispose pas de smartphone. On pourra donc renseigner et alimenter le système sans avoir vraiment besoin de l’installer grâce à un serveur web. Ce dernier détient toutes les informations du système (dans la base de données du système MySQL), gère l'ensemble des services (gestionnaire de services - JSON) et des applications (gestionnaire d'applications - scripts PHP / Java) dans le système, accepte les demandes à la fois de l’administrateur système et du citoyen capteur et déclenche l'envoi des SMS. Tout cela marche comme une version jumelle de l'application installable sur le smartphone. Envisager également un serveur cartographique, une base de données repartie sur différentes machines ou dans le cloud ainsi qu’un serveur SMS autonome, sont des éléments dont il faudra également tenir compte (à l'image du problème survenu pour SAIP le 14 juillet 2016). Il s’agit d’un bon moyen pour répartir équitablement la charge de travail afin d’accélérer le traitement des requêtes. La mise en œuvre d’UML dans le cadre de ce travail a permis d’aboutir à un diagramme de déploiement assez cohérent (Fig. 5.20).

Conclusion du chapitre 5

Ce chapitre a permis de conceptualiser le plus possible les solutions espérées pour développer une application qui contribuerait à améliorer le dispositif d’alerte aux crues rapides, en ayant recours à une participation citoyenne. Cet objectif a été concrétisé grâce à plusieurs diagrammes conceptuels :

- le diagramme de structure permet d'avoir une idée plus précise des blocs utilisateurs, matériels et logiciels devant constituer le système,

- le diagramme de comportement décrit individuellement le rôle de ces blocs

- le diagramme d'interaction donne un autre aperçu des flux d’informations et des actions échangées entre les différents acteurs du système.

Un accent particulier a été porté à la réalisation des diagrammes de cas d’utilisation, qui ont constitué la base de ce travail de modélisation rendant compte au départ des subtilités et des difficultés qui pouvaient apparaître lors des interactions homme-machine dans une application smartphone. Il est évident que le passage des idées au monde réel ne peut pas prendre en compte toutes les attentes. Cette approche reste donc sujette à caution. Elle met aussi à jour des contraintes qui pourraient se poser lors de la réalisation, la mise en service et l'amélioration de l'application. L'authentification et la validation des messages émis, la gestion du degré de crédibilité des alertes, l’identification du rôle réel des acteurs du système et des dynamiques qu’ils induisent en sont de bons exemples. Tous ces éléments ont néanmoins constitué le socle sur lequel va ensuite s'appuyer la réalisation pratique de l’application, que nous allons présenter dans le chapitre suivant.

Chapitre 6

Mise en œuvre, développement du prototype

et test d'application

Introduction du chapitre 6 ________________________________________________________________ 183

. . Choix et présentation de l'armature technique _________________________________

. . Mise en œuvre du prototype et paramètres retenus ____________________________

. . Gestion et traitement des données collectées ___________________________________

. . Test d'application et premiers enseignements tirés ____________________________

Introduction du chapitre 6

Ce chapitre 6 vient donner vie aux choix conceptuels présentés auparavant, et présente le fruit de nos réflexions : l'application Al’in. Celle-ci essaie d’apporter une réponse aux difficultés auxquelles

l'État doit faire face dans le champ de l'alerte face aux crues rapides potentiellement dommageables. L'application accorde une place majeure aux citoyens en tant que « ressource » d’information et de connaissance dans le dispositif en place tout en confirmant la place des autorités comme source « référence ». Deux choix étaient possibles : faire fi de toutes les contraintes réglementaires et proposer une solution uniquement technique ; a contrario, mettre en place un système d’information intégrant une application collaborative pour / avec les citoyens en respectant pleinement le cadre réglementaire actuel, mais aussi en laissant le choix à d'autres acteurs (comme les chargés de sécurité civile et les prévisionnistes par exemple) d'apporter leurs compétences et leurs expériences au centre de décision. C'est cette seconde piste qui a été poursuivie : elle est, certes, plus contraignante et moins libre, mais elle vient répondre à un besoin réel et conforte la position prise depuis le début de nos travaux.

Ce chapitre aborde dans un premier point une justification de l'armature technique (§6.1), en décrivant le système d’exploitation sollicité pour la réalisation du prototype de l’application (Androïd) et l’outil de développement utilisé (App Inventer). Le traitement et la gestion des données collectées (§6.2) ainsi que les principaux menus déroulants créés (§6.3) sont dans un deuxième temps détaillés. Ce chapitre se conclut en analysant les leçons tirées à la suite de premières expérimentations menées dans deux communes du Var et du Vaucluse : Pourrières et de Cabrières-d’Avignon (§6.4).