EN CONSTRUCTION https://www.cs.mcgill.ca/~joerg/taosd/TAOSD/TAOSD_files/taosd_call_for_papers.pdf

The broad domain of the case study is crisis management systems, i.e. software that facilitate coordination of activities and information flow between all stakeholders and parties that need to work together to handle a crisis. Crisis management systems can be used to handle many types of crises (e.g., natural disasters, epidemics, accidents, attacks, etc…) and may have to interface and interoperate with different types of external services (e.g., military systems, police systems, government, medical services, etc…). Crisis management systems also exhibit many non-functional properties, e.g. they must be highly available, dependable and secure.

Objectifs :

• Modéliser une application un peu plus complexe en utilisant à bon escient vos connaissances sur la modélisation en UML.
• Mettre en oeuvre les principes GRASP et SOLID au travers de seulement la conception.

Déroulé :

• Les étudiants se mettent par deux pour pouvoir échanger.
• Ils modélisent au choix sur papier ou sur un outil de modélisation de leur choix l'application.
• Ils explicitent en quoi leurs choix répondent aux principes SOLID et GRASP.
• Ils s'assurent de la complétude de leur modélisation en regard de l'énoncé.

Ce travail fera l'objet d'un rendu ultérieur qui sera précisé plus tard.

Etude de cas

1. Il existe plusieurs types de crises. Certaines sont des accidents, d'autres des inondations, … A un type de crise est associé un guide de résolution qui précise les missions à mettre en place, les numéros de téléphone utiles, etc. Il s'agit d'un document.
2. A une crise sont associées des missions. Une mission peut correspondre à plusieurs crises dans le cas où plusieurs crises doivent être simultanément gérées (par exemple, un accident et un incendie). Voici des exemples de missions : alerter les secours, alerter la population, évacuer la population, stopper la circulation.
3. A la création d'une mission sont automatiquement associées les tâches idoines en attente de validation. Par exemple, à la mission “évacuer la population” sont associées par défaut les tâches : déclencher la sirène et notifier les services de polices. Les tâches peuvent être dynamiquement allouées ou retirées à une mission. En cas d'inondation, on ajoutera à la mission “évacuer la population”, la tâche “déclencher des appels téléphoniques pour alerter directement les personnes du village”.
4. Aux tâches sont associées des ressources. Une ressource ne peut pas être affectée à plusieurs tâches en même temps. Par exemple, à une tâche de transport sont associés un véhicule et un chauffeur.
5. Une tâche peut être invalidée ou terminée. Selon les types de tâches, elles commencent/terminent sur demande ou automatiquement quand des conditions sont vérifiées. DLa tâche “envoyer un transport ambulancier” débute dès que l'ambulance et le chauffeur sont affectés à la tâche.
6. Une ressource affectée à une mission est en permanence localisée. S'il s'agit d'un engin, la localisation est obtenue en utilisant le GPS intégré. S'il s'agit d'un être humain, la localisation est la dernière qu'il a renseigné dans le système. Il peut aussi utiliser son téléphone pour se faire localiser automatiquement.
7. Il est possible de connaître les ressources qui sont libres.
8. Lorsqu'une crise est déclarée, elle est enregistrée dans le système et en fonction de son type, les missions à réaliser lui sont automatiquement associées. Le coordinateur de la crise a alors la charge de contrôler la situation d'urgence en identifiant les missions nécessaires pour faire face à la situation. Il peut ainsi mettre une mission prévue par défaut en attente, commencer une mission ou ajouter une mission non prévue initialement.
9. Lorsqu'une mission est commencée, la date de début de la mission est automatiquement renseignée. Lorsqu'elle est terminée, la date de fin de la mission est renseignée. Il est possible de connaitre le temps effectif et prévisionnel d'une mission. Le temps prévisionnel de la mission dépend de son type et de la durée prévisionnelle des tâches qui lui sont associées. Elle peut donc varier en fonction de l'avancement dans le traitement de la mission. A la fin de la mission, les durées prévisionnelles et effectives ont la même valeur. Une mission est considérée comme commencée dès qu'une tâche qui lui est associée est commencée.
10. Pour les crises, missions et tâches terminées, il est possible de connaitre le nombre de ressources utilisées.
11. Une ressource est considérée comme libre dès qu'elle n'est plus associée à une tâche en cours.
12. La durée effective d'une tâche correspond au temps passé entre le début et la fin de la tâche.
13. A tout moment un expert peut demander au système quelles sont les crises en cours et obtenir pour chacune la durée prévue. En sélectionnant une crise, il peut alors la visualiser.
14. L'expert peut visualiser une crise particulière. Dans ce cas, toutes les missions sont affichées avec leur état (en attente, commencée, terminée, etc).
15. Un système central permet à l'expert d'évaluer la fréquence et la durée effective de gestion des crises dans le temps.