D’ARCHITECTURE - citepa.org5015].pdf · 04/07/2006 · Charte_Ergonomique_Application_Cart...

PROPOSITION DE

DOSSIER

D’ARCHITECTURE

LOGICIELLE ET

TECHNIQUE (D.A.1.)

en date du 24 novembre 2006 relatif à l’appel d’offre pour

la réalisation du lot 5 de l’inventaire national spatialisédes émissions de polluants dans l’air

Le présent D.A.1. comprend 42 pages numérotées de 1 à 42

DOSSIER D’ARCHITECTURE LOGICIELLE ET TECHNIQUE« Développement de l’Inventaire National Spatialisé (INS) »

2

SOMMAIRE

Documents applicables..................................................................................................................... 4Documents de référence .................................................................................................................. 4

1. Introduction..................................................................................................................................51.1. Objet .............................................................................................................................................. 51.2. Evolutions du document d’architecture................................................................................. 51.3. Audience du document ............................................................................................................ 51.4. Contenu du document.............................................................................................................. 51.5. Notation......................................................................................................................................... 5

1.5.1. Les diagrammes de classe.............................................................................................. 61.5.2. Les diagrammes de cas d’utilisation............................................................................. 71.5.3. Les diagrammes de processus....................................................................................... 71.5.4. Les diagrammes d’activités............................................................................................ 81.5.5. Les diagrammes de déploiement................................................................................. 9

1.6. Acteurs projet.............................................................................................................................101.7. Positionnement du document ................................................................................................10

2. Cadre d’élaboration d’architecture.........................................................................................112.1.1. Principes d’architecture ................................................................................................11

3. Cadre fonctionnel ...................................................................................................................123.1. Identifications des acteurs.......................................................................................................12

3.1.1. Les utilisateurs INS............................................................................................................123.1.2. Acteurs non nominaux...................................................................................................13

3.2. Modèle de domaine INS..........................................................................................................143.3. Système A et système B............................................................................................................153.4. Cycle d’alimentation des données INS ................................................................................153.5. Système A et système B............................................................................................................163.6. Cas d’utilisation..........................................................................................................................17

3.6.1.1. Cas d'utilisation « Administration » .......................................................................173.6.1.2. Cas d'utilisation « Gestion des extractions » ......................................................183.6.1.3. Cas d'utilisation « Mise à jour INS ».......................................................................193.6.1.4. Cas d'utilisation « Intégration données non spatialisées » ..............................203.6.1.5. Cas d'utilisation "Restitution accès libre»............................................................213.6.1.6. Cas d'utilisation "Restitution Utilisateurs habilités» .............................................213.6.1.7. Cas d'utilisation "Gestion des scénarios»............................................................22

3.7. Contraintes fonctionnelles.......................................................................................................233.7.1. Disponibilité de l’application........................................................................................233.7.2. Sécurité .............................................................................................................................233.7.3. Sécurité des échanges avec les systèmes connexes..............................................233.7.4. Temps de réponse des demandes interactives .......................................................233.7.5. Temps de réponse des requêtes non interactives ...................................................24

3.8. Eléments de volumétrie............................................................................................................243.8.1. Volumétrie de données non spatialisées (Système A) ............................................243.8.2. Volumétrie de données spatialisées (Système B).....................................................243.8.3. Profil des demandes interactives.................................................................................24

3.9. Trace et journalisation............................................................................................................243.10. Configuration des applications ...........................................................................................253.11. Formats de données dans les échanges...........................................................................253.12. Sauvegarde, archivage, purge des données ..................................................................25

3.12.1. Purge des données......................................................................................................253.12.2. Sauvegarde...................................................................................................................26


3

4. Architecture logique...............................................................................................................264.1. Le système A (INSA)...................................................................................................................264.2. Le système B (INSB)....................................................................................................................274.3. Communication Système A – Système B ..............................................................................27

4.3.1. Décomposition fonctionnelle du système B..............................................................274.3.2. Découpage logique du système B .............................................................................284.3.3. Communication entre INSB_UH et INSB_AL................................................................29

4.4. Architecture logicielle...............................................................................................................294.4.1. Architecture Web SIG ....................................................................................................29

4.5. Les logiciels de base préconisés(sgbd, serveurs applicatifs, systèmes d’exploitations)314.6. Le domaine de données INS...................................................................................................32

4.6.1. Catégories de données ................................................................................................324.6.1.1. Les données géographiques (GEO))..................................................................324.6.1.2. Les données des émissions (EMS) .......................................................................334.6.1.3. Les données des scénarios ou données de simulation (SIM).........................334.6.1.4. Les données précalculées (CALC)......................................................................33

4.6.2. Bases de données INS....................................................................................................33

5. Architecture de déploiement.................................................................................................355.1. N uds de déploiement ..........................................................................................................355.2. Déploiement des composants ...............................................................................................36

5.2.1. Plate forme INSA .............................................................................................................365.2.2. Plate forme INSB..............................................................................................................37

5.3. Eléments de dimensionnement..............................................................................................405.3.1. Spécification et dimensionnement des n uds de déploiement.........................40

5.4. Dimensionnement des espaces de stockage.....................................................................42


4

Documents applicables

Document Description Version Auteur Date

[DA1] Dossier d’architecture logicielle ettechnique 1.0 Synapse 27/10/2006

Documents de référence

Document Description Version Auteur Date

[DR1]

CCTP_ INS_20050629.doc : CCTP relatifà l’appel d’offre pour la réalisationd’un inventaire national spatialisé desémissions de polluants dans l’air

1.0 Ministère del’Ecologie 29/06/2005

[DR2] Referentiel_General_Interoperabilite_Volet_Technique_V0.90.pdf 0.90

Ministèredélégué au

budget07/04/2006

[DR3] Charte_Ergonomique_Application_Cartographie_Juin04.pdf MEDD Juin 2004

Table de matières des figures

Figure 1 - Exemple de diagramme de classe ........................................................................................ 6Figure 2 - Exemple de diagramme de cas d'utilisation........................................................................ 7Figure 3 - Exemple de digramme de processus .................................................................................... 8Figure 4 - Exemple de diagramme d'activité.........................................................................................9Figure 5 - Exemple diagramme de déploiement................................................................................10Figure 6 - Acteurs nominaux INS..............................................................................................................12Figure 7 - Acteurs non nominaux INS .....................................................................................................13Figure 8 - Acteurs non nominaux et leurs relations..............................................................................14Figure 9 - Entités du domaine INS ...........................................................................................................15Figure 10 - Cycle d'alimentation des données....................................................................................16Figure 11 - Décomposition INS en systèmes A et B..............................................................................17Figure 12 - Cas d'utilisation "Administration" .........................................................................................18Figure 13 - Cas d'utilisation "Gestion des extractions » .......................................................................19Figure 14 - Cas d'utilisation "Mise à jour INS" .........................................................................................20Figure 15 - Cas d'utilisation « Intégration données non spatialisées » .............................................21Figure 16 - Cas d'utilisation "Restitution en accès libre » ....................................................................21Figure 17 - Restitution vers Utilisateurs habilités ....................................................................................22Figure 18 -Cas d’utilisation « Gestion des scénarios » .........................................................................23Figure 19 - Alimentation du système A à partir des sources existantes...........................................26Figure 20 - Communication Système A - Système B ...........................................................................27Figure 21 -Modules fonctionnels INSB.....................................................................................................28Figure 22 - Décomposition logique du système B (INSB)....................................................................29Figure 23 - Mise à disposition des données vers le système INSB_AL ...............................................29Figure 24 - Architecture logicielle WEB SIG pour INS...........................................................................30Figure 25 - Catégories de données INS.................................................................................................32Figure 26 - Base de données du système A..........................................................................................34Figure 27 - Bases de données du système B.........................................................................................35Figure 28 - N uds de déploiement INS ................................................................................................36Figure 29 - Déploiement de la plate forme INSA.................................................................................37Figure 30 - Déploiement de la plate forme B.......................................................................................39Figure 31 - Exemple de dimensionnement des noeuds INSA............................................................40Figure 32 - Exemple de dimensionnement des noeuds INSB ............................................................41


5

1. Introduction

1.1. Objet

Ce document décrit les orientations en termes d’architecture logicielle et de déploiementpour l’Inventaire National Spatialisé des Emissions, projet initié par le Ministère de l’Ecologie etDu Développement Durable.

1.2. Evolutions du document d’architecture

Les orientations d’architecture contenues dans ce document devront être affinées lors de laphase de consolidation de besoin par le prestataire informatique retenu, aussi bien pourl’architecture logicielle que pour l’architecture de déploiement.

Parmi les éléments non définis à ce jour d’architecture logicielle, on peut notamment citer leSystème d’Information Géographique cible.

1.3. Audience du document

Les instances de pilotage de l’INS ainsi que le prestataire informatique du lot 5.

1.4. Contenu du document

Ce document s’articule autour des chapitres suivants :

Cadre fonctionnel

L’architecture d’un système doit répondre en premier lieu aux contraintes fonctionnelles decelui-ci. Ce chapitre fait un rappel des principaux éléments fonctionnels influant sur lesorientations d’architecture proposées. Ces éléments sont exprimés sous la forme de casd’utilisation, de la description des acteurs et de celle des principaux flux.

Architecture logicielle

Ce chapitre identifie les principaux modules et sous-systèmes de l’INS, ainsi que lesresponsabilités et les interactions entre ces modules.

Architecture de déploiement (technique)

Les éléments d’architecture logicielle identifiés précédemment sont associés à des n uds etdes machines (serveurs et postes clients). Ce chapitre fournit également un premierdimensionnement de la plate-forme de déploiement, quant aux machines et aux espacesde stockage associés.

1.5. Notation

La notation UML 2.01 est utilisée pour la plupart des schémas présentés dans ce document,afin de faciliter la communication entre les différents acteurs concernés par l’architecture del’INS.

Les différents types de diagrammes utilisés permettent d’exprimer plusieurs vues du système :

• une vue statique - à travers des diagrammes de cas d’utilisation, diagrammes declasse et diagrammes de déploiement ;

• une vue dynamique - à travers de diagrammes d’activité et de processus.

1 Unified Modeling Language : langage (conventionnel) pour la modélisation des systèmes sousforme graphique


6

1.5.1. Les diagrammes de classe

Les diagrammes de classe décrivent le système du point de vue statique.

Ils contiennent des entités ou des acteurs. Une entité est une notion forte du système.

Les acteurs sont des sujets bénéficiaires - des fonctionnalités - du système mais ils peuventreprésenter également des systèmes connexes. Comme les classes, les acteurs peuvent setrouver en relation d’association les uns avec les autres : en relation d’association simple, enrelation d’héritage s’ils partagent des caractéristiques communes.

Les classes et les acteurs peuvent être manipulés au niveau générique, mais aussi en termed’instances (exemple : « Polluant SO2 » est une instance de la classe « Polluant »).

Les classes et les acteurs peuvent être d’ordre abstrait (représenté en italique) ce qui signifiequ’ils sont là seulement pour permettre de classifier plus facilement l’information sans avoirpour autant une réalité en termes d’instance.

Les classes et les acteurs peuvent se trouver en relation d’héritage (ou généralisation si elleest observée dans le sens inverse), pour signifier que les caractéristiques et le comportementd’une classe sont hérités dans l’autre classe. Exemple : l’ « administrateur » est un « utilisateurhabilité » (i.e. l’administrateur hérite des caractéristiques d’un utilisateur habilité commel’identifiant, le mot de passe, les droits sur les fonctionnalités, etc.).

Dans la Figure 1, la « Classe n°2 » hérite de la classe « Classe n°1 », ou dans le sens inverse« Classe n°1 » est une généralisation de la « Classe n°1 ».

Figure 1 - Exemple de diagramme de classe


7

1.5.2. Les diagrammes de cas d’utilisation

Les diagrammes de cas d’utilisation montrent la manière dont les différents utilisateurs dusystème (les acteurs) bénéficient des différentes fonctionnalités du système, par desassociations entre les deux.

L’ensemble des cas d’utilisation décrit l’utilisation du système du point de vue de sesutilisateurs.

La notation permet également d’inclure les cas d’utilisation les uns dans les autres, d’étendreles cas en les « branchant » les uns dans les autres ou même d’utiliser des relations d’héritage(de manière similaire aux relations d’héritage entre les classes et les acteurs).

Nous utilisons ici les associations simples entre les acteurs et les cas d’utilisation, ainsi quel’inclusion des cas d’utilisation, pour signifier le découpage d’un cas d’utilisation en plusieurscas de niveau plus réduit.

Figure 2 - Exemple de diagramme de cas d'utilisation

1.5.3. Les diagrammes de processus

Les diagrammes de processus représentent les différentes tâches d’un processus, et mettenten évidence les groupements de ces tâches sur un même site ou même système. Les tâchespeuvent produire ou peuvent être alimentées par des objets.

Des événements de plusieurs types permettent de mettre en évidence le déclenchement oula terminaison de processus, ou des événements apparaissant pendant le déroulement duprocessus.

Le présent document utilise peu de diagrammes de processus. Ces derniers sonthabituellement utilisés dans les descriptions fonctionnelles des systèmes .


8

Figure 3 - Exemple de digramme de processus

1.5.4. Les diagrammes d’activités

Les diagrammes d’activités contiennent des activités qui s’enchaînent. Des objets peuvent setrouver en entrée ou en sortie de certaines activités. Les activités sont réalisées par unexécutant non spécifié, mais il est possible de spécifier des acteurs exécutant des activités ;dans ce cas, chaque exécutant (une instance de classe, d’acteur) bénéficie d’un « couloirde nage » contenant ses propres activités.


9

Figure 4 - Exemple de diagramme d'activité

1.5.5. Les diagrammes de déploiement

Les diagrammes de déploiement (ou d’implémentation) définissent les configurations dedéploiement du système, en montrant comment les artefacts sont répartis sur les n uds dusystème.

Les n uds de déploiement sont des machines, des équipements réseau ou de stockage. Untype de n ud est également utilisé (« environnement d’exécution ») pour représenter leslogiciels de base présents sur les machines, comme un système d’exploitation, un SGBD, unSIG.

Les n uds peuvent être reliés pour faire apparaître les connexions de communicationcomme par exemple la communication entre un serveur applicatif et un serveur de base dedonnées.

Comme pour les classes et les acteurs, les diagrammes de déploiement permettent detravailler à un niveau logique (les n uds type) et au niveau des instances des n uds.


10

Figure 5 - Exemple diagramme de déploiement

1.6. Acteurs projet

Les acteurs suivants sont identifiés au niveau du projet :

• le prestataire du lot 5 (MOE : Maîtrise d’ uvre) ;

• les prestataires des lots 1, 2, 3 et 4 ;

• le MEDD (MOA : Maîtrise d’Ouvrage) ;

• l’exploitant INS (EXP : Exploitant) ;

• le comité de pilotage du projet (Copil) ;

• le groupe de travail de suivi des travaux (GT5).

1.7. Positionnement du document

Ce document exprime les principales orientations d’architecture de l’Inventaire NationalSpatialisé. Ces orientations représentent des clauses techniques particulières pour la partiearchitecture du système, complétant les clauses de niveau fonctionnel et organisationnelcontenues dans le document DR1.

Pour atteindre le niveau d’une architecture opérationnelle pour un projet de développement(architecture détaillée), certains éléments peuvent nécessiter davantage de détails lors de laphase de conception ou des choix peuvent être ajustés par rapport à l’évolution ducontexte du projet.

De manière générale, l’architecture du système vit tout au long d’un projet et fait l’objetd’un travail permanent d’audit et d’évolutions, malgré son caractère fondateur dans lesphases amont du projet.


11

2. Cadre d’élaboration d’architecture

Ce chapitre répertorie les éléments à la base des orientations d’architecture, en termes deprincipes d’architecture (ingénierie), mais surtout du point de vue fonctionnel.

2.1.1. Principes d’architecture

L’adéquation fonctionnelle

Une architecture doit répondre avant tout à un besoin fonctionnel donné, qui va guider lesprincipaux choix et la structure. Les cas d’utilisation, ainsi que les principales contraintesfonctionnelles présentées dans ce document, synthétisent le besoin fonctionnel déterminantles choix d’architecture.

Modularité

Le système doit être modulaire afin de maîtriser sa conception initiale et sa maintenance parla suite.

Applications de standards

Les spécifications du système doivent être basées sur des standards techniques existants ousur des solutions standard incluant :

• protocoles de communication (http, SOAP) ;

• spécification des interfaces de services (Web services, composants J2EE)) ;

• formats de représentation externe des données (XML) ;

• standards et solutions industrielles pour la partie SIG, incluant :

o les services de présentation ;

o les services de données.

Orientation service

L’orientation service fait référence à l’architecture SOA (Architecture Orienté Service),devenue une orientation de fond des SI (Système d’Information) actuels.

Le futur système doit identifier une couche d’interaction de niveau service exposant sesfonctionnalités à ses propres modules (de présentation) et constituant également un pointd’interopérabilité du système.

Orientation composants

Le système sera structuré sous la forme de composants, implémentés de manière standarden fonction de la plate-forme cible.

Intégration dans l’infrastructure SI existante

La solution devra s’intégrer dans l’infrastructure SI existante à chaque fois que la réutilisationd’une brique existante du SI actuel peut apporter une réponse satisfaisante.

Intégration dans l’infrastructure d’exploitation

L’architecture de déploiement INS doit s’intégrer et bénéficier de l’infrastructure mise àdisposition par l’exploitant de la solution. Ceci inclut :

• les logiciels de sauvegarde pour les bases de données ;

• les systèmes de surveillance d’applications ;

• l’infrastructure réseau.


12

3. Cadre fonctionnel

3.1. Identifications des acteurs

On identifie un premier niveau d’acteurs du futur système, incluant les utilisateurs nominaux etles systèmes externes à INS.

3.1.1. Les utilisateurs INS

Les utilisateurs définissent un profil d’utilisation du système, en termes de fonctionnalitésutilisées et type d’utilisation.

Figure 6 - Acteurs nominaux INS

« intégrateur données INS »

Utilisateur spécialisé dans l’intégration des données en entrée de l’INS, en provenance dessystèmes alimentant INS.

« accès libre »

Utilisateur anonyme accédant par Internet pour consulter les rapports, cartes et données précalculées de l’INS mis à sa disposition.

« utilisateur habilité »

Il s’agit d’utilisateurs bénéficiant d’une habilitation pour accéder au système.

Les utilisateurs habilités ont accès à l’ensemble des données non confidentielles ainsi qu’àl’ensemble des fonctionnalités du système.

Les différentes spécialisations des utilisateurs habilités sont :

• « administrateur » : ce profil a accès à toutes les fonctionnalités INS, incluant lesfonctionnalités administratives ;

• « mission de service public » : ce profil a accès à l’ensemble des fonctionnalités INS,hormis les fonctionnalités administratives.


13

3.1.2. Acteurs non nominaux

Ce diagramme classifie les acteurs de type système, en identifiant :

• système INS - le système INS lui-même ;

• système externe INS - l’ensemble des systèmes à l’extérieur de l’INS. Ceci inclut lessystèmes alimentant INS en données d’inventaire et les systèmes destination de fluxde données en provenance de l’INS ;

• système source INS - les systèmes fournisseurs de données d’inventaire pour l’INS ;

• système destination INS - des systèmes ;

• système PREV’AIR - le système de prévisions de la qualité de l’air, un des clientsmajeurs de INS, représenté comme un cas particulier de « Système destination INS ».

Figure 7 - Acteurs non nominaux INS


14

Les trois systèmes sont positionnés du point de vue des flux échangés en amont/aval les unspar rapport aux autres :

Figure 8 - Acteurs non nominaux et leurs relations

3.2. Modèle de domaine INS

Le modèle de domaine capte les principales notions de l’INS sous la forme d’entités,comme :

• les données de référence (nomenclatures d’activités ou de spéciation, clés detemporalisation) ;

• les polluants ;

• les émissions et données associées telles que d’activité, les facteurs d’émission, etc. ;

• les scénarios de calcul ;

• les paramètres de scénario ;

• les sources d’émission ;

• la référence spatiale ;

• etc.

La Figure 9 présente un exemple de modèle de domaine pour, la spécification complète dece modèle devant être réalisée en mode projet.


15

Figure 9 - Entités du domaine INS

3.3. Système A et système B

En termes de traitement des données faisant l’objet de l’inventaire est prévue une phase deconsolidation et de validation des données en provenance des différentes sources dedonnées par le biais d’un système dédié :

• le système A (INSA) ne manipule pas des données spatialisées dans le sens SIG duterme ;

• la partie opérationnelle de l’inventaire spatialisé, incluant le support pour le calculdes scénarios et la restitution des données spatio-temporalisées, est assurée par undeuxième système, le système B (INSB).

Le diagramme suivant représente l’INS en tant qu’agrégats des systèmes A et B.

3.4. Cycle d’alimentation des données INS

Les données en entrée de l’inventaire rentrent dans deux grandes catégories :

• les données des émissions et les référentiels fonctionnels, en provenance des basesde données des inventaires existants au niveau national et régional ;

• les données de référence pour la partie SIG, en provenance des fournisseurs desbases de données SIG.


16

Ces deux catégories de données sont intégrées dans l’INS dans cet ordre et à des stadesdifférents, tel que présenté dans la Figure 10.

En final, sont mises à disposition des utilisateurs et du système PREV’AIR les données del’inventaire national spatialisé.

Figure 10 - Cycle d'alimentation des données

3.5. Système A et système B

En termes de traitement des données faisant l’objet de l’inventaire est prévue une phase deconsolidation et de validation des données en provenance des différentes sources dedonnées par le biais d’un système dédié :

• le système A (INSA) ne manipule pas des données spatialisées dans le sens SIG duterme ;


17

• la partie opérationnelle de l’inventaire spatialisé, incluant le support pour le calculdes scénarios et la restitution des données spatio-temporalisées, est assurée par undeuxième système, le système B (INSB).

Le diagramme suivant représente l’INS en tant qu’agrégat des systèmes A et B.

Figure 11 - Décomposition INS en systèmes A et B

3.6. Cas d’utilisation

Les cas d’utilisation captent les grandes fonctionnalités que le futur système de l’INS doitexposer, et considérées comme représentatives pour la définition de l’architecture.

Le dossier de conception générale du système contiendra l’intégralité des cas d’utilisation.

3.6.1.1. Cas d'utilisation « Administration »

L’ « administrateur » de l’INS gère les demandes des utilisateurs demandeurs d’un accèshabilité. Une acceptation de demande débouche ensuite sur la création d’un nouvelutilisateur habilité et des tâches administratives.

L’ « administrateur » supervise également l’exécution des requêtes lourdes, soumises par lesutilisateurs habilités en fonction de leurs droits.


18

Figure 12 - Cas d'utilisation "Administration"

3.6.1.2. Cas d'utilisation « Gestion des extractions »

Le système A doit mettre à disposition du système B les données non spatialisées.

Le système B doit mettre à disposition :

• les données de l’inventaire national spatialisé pour le système PREV’AIR ;

• les résultats des requêtes différées sur les sites de ses utilisateurs ;

• les requêtes en ligne relatives aux utilisateurs en « accès libre ».


19

Figure 13 - Cas d'utilisation "Gestion des extractions »

3.6.1.3. Cas d'utilisation « Mise à jour INS »

Le diagramme suivant identifie les responsabilités des acteurs systèmes lors d’une mise à jourde l’INS, au niveau des systèmes externes (sources INS) et des systèmes A et B.

Le diagramme offre une vue cas d’utilisation du diagramme concernant le cycled’alimentation de l’INS présenté dans le diagramme Figure 10 - Cycle d'alimentation desdonnées.


20

Figure 14 - Cas d'utilisation "Mise à jour INS"

3.6.1.4. Cas d'utilisation « Intégration données non spatialisées »

L’intégration des données non spatialisées dans le système A concerne un nombre restreintd’utilisateurs, effectuant l’importation et surtout la validation des données importées.

L’utilisateur « Intégrateur de données de l’INS » est amené à travailler avec des procéduresstandard mises à disposition par le système (batch d’importation), mais aussi par desrequêtes spécifiques sur la base de données du système A.


21

Figure 15 - Cas d'utilisation « Intégration données non spatialisées »

3.6.1.5. Cas d'utilisation "Restitution accès libre»

L’utilisateur « en accès libre » accède aux données de l’inventaire à travers une interface detype client SIG Web, lui permettant de spécifier les données à restituer et les paramètres deprésentation.

Le système applique pour l’utilisateur en « accès libre » des restrictions concernant larésolution des données consultables et le type des données consultables en termes deconfidentialité.

Figure 16 - Cas d'utilisation "Restitution en accès libre »

3.6.1.6. Cas d'utilisation "Restitution Utilisateurs habilités»

La restitution vers les utilisateurs « habilités » (i.e. « Mission de service public » et« administrateur ») est soumise à des restrictions en fonction des droits attribués parl’administrateur - fonctionnel - du système. En règle générale :

• l’ « administrateur » de l’INS a accès à toutes les fonctionnalités et au niveauconfidentiel des données ;


22

• les utilisateurs « Mission de service public » bénéficient d’un accès auxfonctionnalités réglementé par des droits attribués par l’ « administrateur », mais ilsn’ont pas accès au niveau confidentiel des données.

Figure 17 - Restitution vers Utilisateurs habilités

3.6.1.7. Cas d'utilisation "Gestion des scénarios»

Les requêtes de scénarios sont des requêtes lourdes en termes de :

• ressources consommées sur la base de données et du serveur de traitement (CPUnotamment) ;

• coûteuses en temps d’exécution ; elles peuvent durer plusieurs heures, voire plusieursjours.

Compte tenu de ces éléments, une requête de scénario passe par une demanded’exécution, traitée par l’ « administrateur » de l’INS pour les aspects :

• rejet / acceptation de la demande ;

• planification d’exécution de la demande ;

• restitution des résultats du scénario.


23

Figure 18 - Cas d’utilisation « Gestion des scénarios »

3.7. Contraintes fonctionnelles

3.7.1. Disponibilité de l’application

Le niveau de disponibilité varie en fonction des fonctionnalités de l’application.

Ainsi, les fonctionnalités accessibles par Internet sans habilitation doivent assurer une qualitéde service élevée vis à vis de l’utilisateur final, compatible avec les applications Internet.

Les fonctionnalités de la partie destinés aux utilisateurs habilités devront être disponibles aumoins dans une extension des heures ouvrables.

3.7.2. Sécurité

L’utilisateur « en accès libre » accède librement à l’INS, via Internet, bénéficiant seulementdes fonctionnalités de restitution restreintes.

Les autres profils utilisateur doivent être authentifiés, et en fonction de leur identité (leur profil)ils auront des restrictions d’accès sur les axes suivants :

• le niveau d’agrégation des données ;

• le périmètre des données ;

• les fonctionnalités (exemple : exécution des scénarios).

3.7.3. Sécurité des échanges avec les systèmes connexes

Parmi les systèmes connexes on peut énumérer PREV’AIR, les fournisseurs de donnéesd’émissions, les sites FTP utilisés pour le dépôt des résultats des requêtes.

Aucun mécanisme concernant l’authentification, l’intégrité ou la confidentialité de ceséchanges n’est prévu actuellement.

Les mécanismes de sécurité devront être négociés avec les systèmes connexes en modeprojet.

3.7.4. Temps de réponse des demandes interactives

Les temps de réponse pour la partie « en accès libre » doivent être compatibles avec lesapplications cartographiques accessibles sur Internet. La restitution d’une carte pourra ainsiprendre jusqu’à 10 secondes en fonction du nombre de couches demandées parl’utilisateur.


24

Les opérations d’administration ordinaires (par exemple : gestion des droits des utilisateurs) oules opérations de gestion des scénarios (hors exécution) se situeront en dessous de 5secondes.

3.7.5. Temps de réponse des requêtes non interactives

Les demandes non interactives peuvent donner lieu à des traitements lourds, nécessitant destemps de traitement prévisibles de l’ordre plusieurs heures (les requêtes de scénarionotamment).

3.8. Eléments de volumétrie

3.8.1. Volumétrie de données non spatialisées (Système A)

Le volume des données de référence non spatialisées est estimé actuellement à 60 Go, avecun stockage dans une base de données.

Cette base sera utilisée pour dimensionner l’espace de stockage dans la partie Architecturede déploiement.

3.8.2. Volumétrie de données spatialisées (Système B)

La base d’estimation pour les données spatialisées est de 3 To par année.

3.8.3. Profil des demandes interactives

Les demandes du système B sont hiérarchisées en plusieurs catégories.

Même si l’effort de calcul dans l’absolu reste difficile à évaluer à ce stade, la hiérarchisationdes demandes est une base pour la définition de l’architecture logique et de déploiementdu système B.

Les demandes utilisateur courantes sont présentées ci-dessous :

Tâche / Requête Niveau de la chargeinduite

Tâches d’administration applicative Faible

Création / modification de scénarios Faible

Restitution cartographique des données précalculées

Elevée

Restitution cartographique des données deréférence de l’inventaire

Moyen

Exécution des scénarios Elevé

3.9. Trace et journalisation

L’INS comprend une infrastructure de journalisation applicative, permettant de tracer :

• des événements fonctionnels configurables (exemple : la création d’un utilisateur,l’exécution d’un scénario, etc.) ;

• les erreurs survenues dans l’application ;

• des informations de support pour le diagnostic, à la demande.

Le format et le contenu des traces disponibles doivent être traités dans les dossiers deconception détaillée de l’application.


25

3.10. Configuration des applications

L’INS comprend une infrastructure de configuration, basée sur l’utilisation d’un fichier deconfiguration au niveau de chaque application déployée au niveau serveur. Ceci inclut lessystèmes INSB_AL et INSB_UH.

La spécification des paramètres de configuration doit être traitée dans les dossiers despécifications détaillées.

3.11. Formats de données dans les échanges

Les flux générés par l’INS utilisent le format XML et les standards XML 1.0.

La définition des schémas XML correspondant aux différents flux doit être traités dans ledossier de spécifications générales.

Des interfaces existantes dans les systèmes connexes à l’INS peuvent justifier l’utilisation deformats de données autres que XML.

3.12. Sauvegarde, archivage, purge des données

La sauvegarde opérationnelle des données (images de sites Web, sauvegardes de bases dedonnées) sont hors périmètre applicatifs (prise en charge par l’exploitant du système).

L’archivage des données et la purge des données font partie du périmètre applicatif. Laspécification des modules d’archivage et de purge doit être intégrée dans le dossier despécifications détaillées de l’application

3.12.1. Purge des données

La période de rétention des données est de 3 ans. A partir de la quatrième année untraitement de purge annuel doit être réalisé.

Le tableau suivant présente le nombre d’années en lignes pour les différents catégories dedonnées INS, en régime de croisière :

• A_Ref - l’année de référence de l’inventaire, l’année 2004 ;

• A-1, A-2, … - les deux dernières années disponibles, etc. ;

• A_Sup - une année supplémentaire pour le rechargement possible d’une annéearchivée.

Catégorie de donnéesAnnées

enligne

Détail des annéesde rétention

Données « en accèslibre »

4 A-1

A-2

A_Réf

A_Sup

Données en accèshabilité

3 A-1

A-2

A_Ref


26

3.12.2. Sauvegarde

Compte tenu des volumes importants des données, une sauvegarde systématique de toutesles données des bases peut être lourde à gérer.

Des techniques de sauvegarde incrémentale (proposés par le SGBD utilisé) combinées avecdes sauvegardes complètes lors de jalons d’extraction / intégration dans les sous-systèmesINS peuvent assurer une gestion efficace des sauvegardes.

En mode projet, le dossier de mise en exploitation doit spécifier une stratégie de sauvegardeappropriée pour éviter les pertes de données de l’INS.

4. Architecture logique

4.1. Le système A (INSA)

Le rôle du système A est la consolidation des données d’inventaire en provenance desdifférentes sources et l’homogénéisation de ces données.

Dans le système A, les données ne sont pas spatialisées dans le sens SIG du terme. Elles sontnéanmoins géoréférencées, afin de permettre leur spatialisation ultérieure dans le système B.

Le diagramme d’activité suivant présente l’alimentation de INSA à partir des flux générés parles systèmes sources.

Figure 19 - Alimentation du système A à partir des sources existantes


27

4.2. Le système B (INSB)

Le système B est le système « opérationnel » de l’INS, dont les principales fonctionnalités sontla restitution des informations de l’inventaire et le support pour la création des scénarios àpartir des données de l’inventaire.

4.3. Communication Système A – Système B

Le système A alimente le système B une fois par an, avec un flux contenant les données nonspatialisées et non temporisées de l’inventaire pour l’année précédente (A-1).

Figure 20 - Communication Système A - Système B

4.3.1. Décomposition fonctionnelle du système B

Le diagramme suivant présente une décomposition fonctionnelle (possible) de plus hautniveau du système B en plusieurs modules ou sous-systèmes. Ce découpage est à consoliderpar le futur prestataire du lot informatique.

Import / Export

Cette partie est responsable de l’intégration des données non spatialisées en provenance dusystème A (voir Communication INSA- INSB) et de l’export des données vers PREV’AIR.

Gestion diffusion

Ce module est responsable de la diffusion des requêtes de restitution, vers les systèmesdestinataires.

Restitution de l’INS

Il s’agit du sous-système central de l’INS, réalisant la restitution vers les utilisateurs nominaux(i.e. « en accès libre» et la catégorie des utilisateurs habilités). Ceci inclut les restitutionsinteractives de type SIG, les restitutions interactives des données numériques, les résultats desrequêtes de scénarii.

Gestion scénarios

La gestion des scénarios comprend la planification et la surveillance des requêtes descénario.

Habilitation

Le module Habilitation assure des fonctionnalités d’acceptation/rejet des demandesd’habilitation, la création de ces utilisateurs et la gestion de leurs droits


28

Figure 21 -Modules fonctionnels INSB

4.3.2. Découpage logique du système B

Les fonctionnalités du système B peuvent être groupées en deux grandes catégories ayantdes contraintes différentes en termes de disponibilité, d’habilitation et de traitements.

On distingue ainsi une partie spécialisée pour l’accès libre (AL) et une partie spécialisée pourles utilisateurs habilités (UH).

La décomposition du système B en deux systèmes séparés dédiés au service « en accèslibre » et des utilisateurs habilités est une orientation majeure d’architecture motivéeprincipalement par :

• les contraintes de disponibilité : l’utilisateur de la partie « AL » est un utilisateuranonyme, accédant via Internet à l’INS. Cette partie de l’application doit adopterune politique propre aux applications Internet en terme de disponibilité, les clientsde l’application n’étant pas identifiés (impossible de les notifier par exemple) ;

• la consommation de ressources sous-jacente : les ressources consommés par lesutilisateurs AL sont à priori moindres que celles consommées par une requête émisepar un utilisateur habilité. Ces données sont en effet pré calculées pour la plupart. Lefait de laisser en compétition l’utilisateur « en accès libre » avec les utilisateurshabilités pénalise systématiquement les utilisateurs « en accès libre » ;

• le périmètre de données accessible (sécurité) : dans la politique d’accès auxdonnées de l’inventaire on remarque une restriction forte lors du passage des profilshabilités (identifiés) au profil « en accès libre » (anonyme). La séparation en deuxsystèmes permet de simplifier les problèmes de sécurité en mettant à disposition desutilisateurs anonymes uniquement les données auxquelles ils ont droit, et de mettreen place une sécurité applicative traitant uniquement des utilisateurs identifiés.

On distingue ainsi deux systèmes :

• INSB_AL – la partie en accès libre ;

• INSB_UH – la partie en accès habilité.


29

Figure 22 - Décomposition logique du système B (INSB)

Dans la suite de ce document nous considérerons que le système B est constitué de ces deuxsystèmes séparés, cette séparation étant prolongée dans la partie Architecture dedéploiement également.

4.3.3. Communication entre INSB_UH et INSB_AL

La séparation en deux systèmes différents fait apparaître un flux d’alimentation de la partieINS_AL, contenant les données de mise à jour de l’inventaire à destination des utilisateurs « enaccès libre ». Ces données sont des données agrégées pour la plupart.

Figure 23 - Mise à disposition des données vers le système INSB_AL

4.4. Architecture logicielle

4.4.1. Architecture Web SIG

L’INS adopte une architecture de type WEB SIG, telle que présentée dans le diagrammesuivant :


30

Figure 24 - Architecture logicielle WEB SIG pour INS

Par rapport à une architecture Web n–tiers classique, on remarque la présence des servicesSIG applicatifs de type WMS et WFS, en suivant les orientations Open GIS.

Le client INS

Plusieurs types de clients sont envisageables, en fonction des profils d’utilisation del’application et du type d’application.

Un client Web (navigateur Web) permet d’accéder au Frontal Web pour le contenu Webclassique (pages HTML dynamiques) sur les applications des deux systèmes INS_AL et INS_UHou pour exploiter des services WMS en s’appuyant sur des plugins spécifiques.

Des clients lourds pourront exploiter également les services WFS pour des fonctionnalitésavancées.

Frontal Web

Le frontal Web assure la partie présentation des applications INS

Services SIG applicatifs

Structurer les services SIG applicatifs sous la forme de services WMS et WFS assurent unalignement sur les standards SIG actuels et un fort potentiel d’évolution des applications INSpar rapport à l’intégration avec des clients SIG capables de consommer des servicesstandards.

Moteur SIG

Le moteur SIG supporte aussi bien l’implémentation de services « métier » que celle desservices SIG créés par l’application. Le niveau de support diffère en fonction du périmètrecouvert par le produit. Par exemple, les fonctionnalités d’analyse nécessaires au calcul desscénarios peuvent ne pas être prises en compte par le produit SIG. Dans ce cas, les servicesmétier devront compenser ce manque de fonctionnalités.


31

Services métier

Cette couche assure des services comme les services d’habilitation, calcul de scénarios,gestion des diffusions, etc. On insiste sur l’orientation service de la couche, sans forcementfaire appel à une implémentation de type Web services (une implémentationconventionnelle sur la plateforme cible comme classes .net ou composants COM+ pourWindows, classes POJO ou EJB pour Java Entreprise peuvent suffirent).

Toujours au niveau implémentation, les services « métier » incluent une couche structuréed’accès aux données, non mise en évidence sur le schéma pour des raisons desimplifications.

Base de données

Il s’agit d’une base de données relationnelle.

Ressource système de fichiers

Compte tenu des volumétries manipulées par l’INS, l’espace de stockage des fichiers est uneressource significative. Les principales utilisations sont :

• espace FTP de mise à disposition des résultats de scénarios ;

• espace de réception des flux entrants et de production des flux sortants.

4.5. Les logiciels de base préconisés (sgbd, serveurs applicatifs, systèmesd’exploitations)

Les logiciels de base dépendent, d’une part, des solutions SIG et applicatives retenues et,d’autre part, du référentiel technique de l’exploitant.

Le tableau suivant liste les logiciels de base compatibles avec la solution, le choix précisrestant à faire en mode projet.

Logiciel de base Produit Systèmes cibles

Système d’exploitation Linux INSB_AL, INSB_UH

Windows INSA, INSB_AL, INSB_UH

SIG Non spécifié à ce jour INSB_AL et INSB_UH

Non spécifié à ce jour INSB_AL et INSB_UH

SGBD Non spécifié à ce jour INSB_AL, INSB_UH


32

4.6. Le domaine de données INS

La base de données INS (le domaine INS) est essentiellement une base SIG, supportantégalement les fonctionnalités décrites en §3.6.

Figure 25 - Catégories de données INS

4.6.1. Catégories de données

4.6.1.1. Les données géographiques (GEO))

Cette catégorie comprend l’ensemble des données décrivant la géométrie dans le sens SIGdu terme, incluant :

• les différentes classes d’entités décrivant les régions, les départements, lescommunes, etc. ;

• les topologies ;

• les réseaux.

Les données géométriques sont relativement stables dans le temps.


33

4.6.1.2. Les données des émissions (EMS)

Les données des émissions comprennent l’ensemble des données de référence pour lesémissions. Ce sont des données de référence de l’inventaire, elles ne changent pas dans letemps. Les données de référence sont géoréférencées. Dans la terminologie SIG ce sont desdonnées attributaires par rapport à la catégorie de données GEO.

A une fréquence annuelle, les données de référence sont :

• enrichies avec les données des émissions de la dernière année (A-2), enprovenance du système A ;

• purgées afin de limiter le périmètre à deux années glissantes plus l’année deréférence.

Les données de référence sont mutualisées par l’ensemble des utilisateurs, avec desrestrictions concernant :

• la résolution des objets géographiques auxquels ces données sont attachées(niveau région, département, commune, etc.) ;

• le périmètre de habilitation.

4.6.1.3. Les données des scénarios ou données de simulation (SIM)

Les données de simulation sont des données calculées à la demande des utilisateurs en« accès libre ». Elles n’ont pas un caractère permanent, mais une durée de vie limitée. Lesdonnées de simulation sont structurées en jeux de données de simulation, définis parl’utilisateur ayant initié leur calcul.

Les utilisations possibles d’un jeu de données de simulation sont :

• la création (le calcul) ;

• l’exportation (l’extraction) à destination de l’utilisateur du jeu de données, partéléchargement (ftp, http) ;

• la visualisation du jeu de données à travers les fonctionnalités cartographiques dusystème.

4.6.1.4. Les données précalculées (CALC)

Les données précalculées représentent le moyen d’accélérer les requêtes de restitution dansle système INSB, en simplifiant également l’implémentation de ces requêtes au niveau del’application.

4.6.2. Bases de données INS

Le découpage au niveau données suit le découpage en grands sous-systèmes présentéprécédemment.

Il y a ainsi trois bases de données logiques pour les système A et B.

Pour le système A :

• BD_INSA – La base de données du système A.

Pour le système B :

• BD_INSB_UH – la base de données de l’INS pour la partie dédiée aux utilisateurshabilités. Cette base est la base de référence de l’INS. Elle accueille les flux entrantsde l’INS et fournit les données pour les flux sortants de l’INS ;


34

• BD_INSB_AL – une base de données spécialisée pour la partie « en accès libre ».Cette base de données est essentiellement une base de données accédée enlecture uniquement. Elle contient une restriction des données de la baseBD_INSB_UH.

Les diagrammes suivants présentent les bases de données INS par grand sous-système, avecles principales catégories de données contenues dans chaque base.

Figure 26 - Base de données du système A


35

Figure 27 - Bases de données du système B

5. Architecture de déploiement

5.1. uds de déploiement

La configuration de déploiement INS contient les plates formes INSA et INSB, déployées surdeux sites distincts.

La plate forme du système A comprend une machine unique.

La plate forme B comprend :

• SGBD INSB - une machine évolutive, hébergeant toutes les bases de données de laplate forme B (i.e. partie « AL» et « UH ») ;

• serveur applicatif INSB_UH - hébergeant les modules applicatifs INSB_UH pour larestitution interactive et excluant les modules de calcul des scénarios ;

• serveur applicatif INSB_UH_SC - machine dédiée pour les modules de gestion/calculdes scénarii et mise à disposition des résultats ;

• serveurs applicatif INSB_AL - machine dédiée aux modules applicatifs de INSB_AL,hormis la base de données ;

• Switch Baie SAN et Baie SAN - les équipements de stockage SAN.

La plate forme B fait apparaître également une partie infrastructure, constituée d’un serveurd’infrastructure (de sauvegarde) et un robot de sauvegarde, assurés normalement parl’infrastructure du site d’exploitation


36

Figure 28 - N uds de déploiement INS

5.2. Déploiement des composants

5.2.1. Plate forme INSA

Sur le diagramme de déploiement INSA, l’unique machine de la plate forme héberge lesmodules applicatifs et la base de données du système.


37

Figure 29 - Déploiement de la plate-forme INSA

5.2.2. Plate forme INSB

Le diagramme de déploiement présente un déploiement possible des différents modulesapplicatifs. On distingue ainsi :

• les trois serveurs applicatifs de la plate forme, un pour la partie AL et deux autrespour la partie UH ;

• le serveur applicatif INSB_UH est spécialisé pour les traitements de restitutioninteractive, alors que INSB_UH_SC prend en charge :

o les traitements des flux d’alimentation ainsi que les exports vers PREV’AIR etINSB_AL ;

o les traitements (lourds) de calcul différé pour les scénarios ;

o la diffusion des résultats issus des calculs de scénarios.


38

Le partage des modules entre INSB_UH et INSB_UH_SC peut varier par rapport à laconfiguration présentée. Ce que la configuration propose de structurant est la séparationentre les traitements lourds de calcul et les traitements de restitution interactive. Elle favoriseégalement la disponibilité des ressources pour la partie interactive (SIG essentiellement) enplaçant tous les modules qui peuvent être décorélés des demandes interactives sur lamachine INSB_UH_SC (Import/ Export, Gestion des diffusions).

La machine INSB_SGBD est l’unique SGBD de la plateforme INSB. La machine INSB_UH_SCdevra être une machine évolutive, afin d’offrir l’option de montée en charge paraugmentation de la puissance de la machine (« scale up ») si nécessaire. La structuration dela base de données en deux bases logiques (AL et UH) offre également la possibilité demontée en charge par déploiement de la base AL sur une machine séparée (scale out).


39

Figure 30 - Déploiement de la plate forme B


40

5.3. Eléments de dimensionnement

5.3.1. Spécification et dimensionnement des n uds de déploiement

Les diagrammes suivants donnent un exemple de dimensionnement pour les élémentscomposant les deux plates formes avec des machines biprocesseurs et quadri-processeurs.

Figure 31 - Exemple de dimensionnement des n uds INSA


41

Figure 32 - Exemple de dimensionnement des n uds INSB


42

5.4. Dimensionnement des espaces de stockage

Les éléments à la base de ce dimensionnement sont :

• la taille des données non spatialisées de 60 Go dans le système INSA ;

• la base d’estimation pour les données spatialisées est de 3 To par année (systèmeINSB) ;

• la qualification du type de stockage comme temporaire et permanent, en fonctionde la nature des informations stockées ;

• l’utilisation des coefficients permettant de déduire les différents types d’utilisation.

Si l’évaluation proposée peut être fiable quant à la manière d’utiliser l’espace de stockage,la taille des données initiale et les coefficients doivent être revus en mode projet en fonctionde :

• la taille des données pré calculées ;

• la politique de gestion des jeux de données de simulation, issus des scénarii decalcul; en effet, des paramètres de type quotas ou de type durée de viedéterminera des volumes de données plus ou moins importantes.

D’ARCHITECTURE - citepa.org5015].pdf · 04/07/2006 · Charte_Ergonomique_Application_Cart...

Documents

Transcript of D’ARCHITECTURE - citepa.org5015].pdf · 04/07/2006 · Charte_Ergonomique_Application_Cart...