Cas 1 : collaboration op´ erationnelle entre SDIS 56 et 35 ExigencesExigences

La premi`ere phase du processus concerne les exigences. La figure 4.2 du chapitre 4 structure les exigences de la collaboration op´erationnelle interd´epartementale. L’exigence principale est le SDIS 56 peut engager une ressource au SDIS 35 pour une intervention courante.

5.2. Mod´elisation de l’´etude de cas CODIS56 CODIS35 VTU35 VTU56 VTU56 Zone 2 Zone 1 Zone 3

Figure 5.4: OV-1a - collaboration op´erationnelle entre SDIS 56 et 35

OV-1a

La deuxi`eme phase du processus est la mod´elisation de l’architecture du niveau SdS et va se d´ecliner avec les vues qui suivent. La figure 5.4 pr´esente la vue OV-1a correspondant `

a la premi`ere configuration de l’´etude de cas. Il s’agit d’un diagramme informel qui d´ecrit statiquement le contexte du SdS avec les principales ressources et relations.

OV1-b : objectifs d’interaction de la collaboration op´erationnelle entre SDIS 56 et 35

La vue OV1-b est le diagramme de cas d’utilisation pr´esent´e dans la figure 5.5 . Elle montre que l’op´erateur CODIS utilise le SDS pour engager diff´erents types de res-source. On note que le d´eploiement d’une ressource implique des capacit´es de coordination op´erationnelle utiles `a l’op´erateur du CODIS pour g´erer toutes les interventions qui se d´eroulent sur son secteur. Cette capacit´e est utilis´ee par le chef d’agr`es pour avoir toutes les informations n´ecessaires pour diriger ses effectifs, et requiert un canal de communica-tion op´erationnelle.

OV-5 - les activit´es op´erationnelles

Les diagrammes d’activit´es montrent les activit´es associ´ees `a un cas d’utilisation. Elles d´ecrivent comment sont r´ealis´es les cas d’utilisation. Les figures 5.6 et 5.7 montrent les activit´es associ´ees au cas d’utilisation : collaboration op´erationnelle. Les partitions des diagrammes montrent les acteurs responsables de la r´ealisation des activit´es qu’ils en-globent. Les connecteurs entre les activit´es montrent leurs orchestrations dans le temps. Dans la figure 5.6, nous voyons que le chef d’agr`es 35 attend la fin des communications

5.2. Mod´elisation de l’´etude de cas

Figure 5.5: OV1-b : objectifs d’interaction de la collaboration op´erationnelle entre SDIS 56 et 35

5.2. Mod´elisation de l’´etude de cas

5.2. Mod´elisation de l’´etude de cas

Figure 5.8: OV-4 - synth`ese des syst`emes constituants

sur le canal op´erationnel pour envoyer son rapport. Nous voyons ´egalement que le pro-tocole de communication est le suivante : il doit s’identifier, attendre la confirmation de l’op´erateur CODIS et finalement envoyer son rapport. La figure 5.7 montre les activit´es qui concernent l’envoi d’instructions par l’op´erateur CODIS 56 au chef d’agr`es 35. Le diagramme montre aussi que l’op´erateur attend la fin des communications et le protocole pour envoyer ses instructions.

OV-4 - synth`ese des syst`emes constituants

La figure 5.8 montre la synth`ese des syst`emes constituants repr´esent´es dans le dia-gramme par les packages. Nous retrouvons les CSs impliqu´es dans le SdS. Ils sont iden-tifi´es dans les vues OV-1b et OV-5. Dans ce cas il s’agit des organisations qui d´eploient les ressources.

Validation

La troisi`eme phase du processus est la v´erification de l’exactitude de l’architecture du SdS. La 5.9 montre l’´etape de validation du point de vue du syst`eme de syst`emes. L’architecte v´erifie la partie du mod`ele d´evelopp´e et la correspondance avec les exigences. Pour cela l’architecte place une relation satisfy entre l’exigence et la partie du mod`ele correspondante.

5.2. Mod´elisation de l’´etude de cas

5.2. Mod´elisation de l’´etude de cas

Figure 5.10: SV-1 BDD de la collaboration op´erationnelle entre SDIS 56 et 35

SV-1 - configuration

Nous sommes `a la quatri`eme phase qui se concentre sur la composition des consti-tuants. La figure 5.10 montre la d´ecomposition du SdS dans le contexte d’une collabora-tion op´erationnelle entre SDIS. La figure 5.11 montre la r´esolution des d´ependances entre les composants. Nous voyons qu’un canal op´erationnel peut par exemple connecter un nombre quelconque de chef d’agr`es. La configuration int`egre la primitive architecturale Shield propos´ee par Zdun and Avgeriou (2008) qui permet `a un ensemble de composants de ne pas ˆetre acc´ed´e directement par un client externe, mais uniquement `a travers un shield. Ici nous remarquons que les chefs d’agr`es ne peuvent pas se connecter directement `

a l’op´erateur CODIS mais par l’interm´ediaire du canal op´erationnel. Finalement la figure 5.12 est le diagramme de package de cette collaboration.

5.2. Mod´elisation de l’´etude de cas

5.2. Mod´elisation de l’´etude de cas

Figure 5.12: SV-1 Diagramme de package de la collaboration op´erationnelle entre SDIS 56 et 35

5.2. Mod´elisation de l’´etude de cas

Figure 5.13: Activit´e “s’identifier” : envoi de message

SV-10c - Sc´enarios d’ex´ecution

Pour les sc´enarios d’ex´ecution nous utilisons des diagrammes d’interaction (s´equence ou communication). Ces diagrammes montrent les donn´ees ´echang´ees et les op´erations in-voqu´ees entre les acteurs pendant la r´ealisation des activit´es. Ils mod´elisent une ex´ecution possible avec les acteurs participants et les ressources physiques utilis´ees. Les connecteurs, entre l’acteur et une ressource, montrent que l’acteur utilise deux ressources physiques un envoi de message. La figure 5.13 est un diagramme de communication qui montre les en-vois de messages correspondant `a l’activit´e d’identification r´ealis´ee par le chef d’agr`es du SDIS 35.

Nous mod´eliserons aussi des comportements d’erreur dans le SDS. Par exemple, alors qu’un VTU a engag´e une communication avec l’op´erateur CODIS, un second VTU tente d’engager une communication.