Mise en place d'une plateforme de cartographie dynamique

Choix d'une méthode d'analyse

I. Définition des concepts

L'analyse permet de lister les résultats attendus, en termes de fonctionnalités, de performance, de robustesse, de maintenance, de sécurité, d'extensibilité, etc. L'analyse répond donc à la question « que faut-il faire ? » et a pour but de se doter d'une vision claire et rigoureuse du problème posé et du système à réaliser en déterminant ses éléments et leurs interactions. Elle met l'accent sur une investigation du problème et des exigences, plutôt que sur une solution. A ce niveau d'abstraction, on doit capturer les besoins principaux des utilisateurs en identifiant les éléments du domaine, ainsi que les relations et interactions entre ces éléments : les éléments du domaine sont liés au(x) métier(s) de l'entreprise, ils sont indispensables à la mission du système, ils gagnent à être réutilisés (ils représentent un savoir-faire) ^(II).

La conception permet de décrire de manière non ambiguë, le plus souvent en utilisant un langage de modélisation, le fonctionnement futur du système, afin d'en faciliter la réalisation. La conception menée à la suite de la phase d'analyse répond donc à la question « comment faut-il faire ce qu'il faut faire ? ». Elle met l'accent sur une solution conceptuelle qui satisfait aux exigences plutôt que sur une implémentation^6(*). Le processus de conception a ainsi pour but de figer les choix techniques (outils, langages, frameworks^7(*)). Il permet ainsi de modéliser tous les rouages d'implémentation et de détailler tous les éléments de modélisation issus des niveaux supérieurs. Les modèles sont optimisés, car destinés à être implémentés.

Ainsi, l'analyse sert à la découverte et à la compréhension et a pour but d'élaborer les spécifications tandis que la conception sert à structurer et à développer une solution ^(II).

II. Pourquoi utiliser une méthode ? ^(II)

Les systèmes d'information ont beau gagné en complexité, les temps de développement n'en sont pas pour autant extensibles. Il faut, dès lors, privilégier l'approche métier, associer utilisateurs et informaticiens, optimiser les ressources et la technologie pour garantir délais et budget. Les méthodes répondent à ces exigences et permettent la construction d'applications fonctionnellement et techniquement conformes aux attentes des divers intervenants du projet.

L'impératif est clair : plus vite, moins cher et de meilleure qualité. Le succès d'un projet dépend désormais de deux facteurs essentiels : l'implication des utilisateurs et une méthode garantissant la réussite du projet tout autant que la qualité de l'application.

Nous devons noter qu'avec les progrès du génie logiciel plusieurs méthodes ont vues le jour. Nous allons, dans le paragraphe suivant, les décrire et les classifier.

III. Classification des méthodes d'analyse et de conception

Les méthodes d'analyse et de conception peuvent être divisées en quatre grandes familles :

1. Les méthodes cartésiennes ou fonctionnelles ^(II)

Avec ces méthodes (SADT, SA-SD), le système étudié est abordé par les fonctions qu'il doit assurer plutôt que par les données qu'il doit gérer. Le processus de conception est vu comme un développement linéaire. Il y'a décomposition systématique du domaine étudié en sous domaines, eux-mêmes décomposés en sous domaines jusqu'à un niveau considéré élémentaire.

2. Les méthodes systémiques ^(II)

Dans les méthodes systémiques (Merise, REMORA^8(*), etc.), le système est abordé à travers l'organisation des systèmes constituants l'entreprise. Elles aident donc à construire un système en donnant une représentation de tous les faits pertinents qui surviennent dans l'organisation en s'appuyant sur plusieurs modèles à des niveaux d'abstraction différents (conceptuel, organisationnel, logique, physique, etc.)

3. Les méthodes objets ^(II)

L'approche objet permet d'appréhender un système en centrant l'analyse sur les données et les traitements à la fois. Les stratégies orientées objet considèrent que le système étudié est un ensemble d'objet coopérant pour réaliser les objectifs des utilisateurs. Les avantages qu'offre une méthode de modélisation objet par rapport aux autres méthodes sont la réduction de la « distance » entre le langage de l'utilisateur et le langage conceptuel, le regroupement de l'analyse des données et des traitements, la réutilisation des composants mis en place.

4. Approche orientée aspect

Bien qu'en étant encore à ses débuts, la Programmation Orientée Aspect commence à se faire connaître et séduit. C'est un principe novateur qui permet de résoudre les problèmes de séparation des préoccupations d'une application. Le code résultant devient plus lisible, réutilisable et le remplacement de composants se fait rapidement et à moindre coût du fait de la séparation des préoccupations. Cette séparation se fait par la création d'aspects contenant le code à greffer à l'application. Un programme appelé « tisseur » greffe ensuite les aspects de façon statique après la compilation, ou de façon dynamique au moment de l'exécution.

Il existe déjà des tisseurs matures, comme AspectJ pour Java, qui est parfaitement intégré à Eclipse grâce au plug-in AJDT. La plateforme .NET possède aussi des tisseurs très prometteurs, tels que AspectDNG qui permet déjà une utilisation professionnelle.

· Définition de quelques mots -clés

Code cible ou code de base : Ensemble de classes qui constituent une application ou une bibliothèque. Ces classes n'ont pas connaissance des aspects (il n'y adonc aucune dépendance), elles ne se "doutent" pas qu'elles vont constituer la cible d'un tissage.

Aspect : Il s'agit du code que l'on souhaite tisser. Selon les tisseurs, un aspect peut être une simple classe ou constituer un élément d'un langage spécifique.

Zone de greffe : Ce sont les "endroits" dans le code cible dans lesquels aura lieu le tissage.

Tissage : Processus qui consiste à ajouter (tisser, greffer, injecter) le code des aspects sur les zones de greffe du code cible.

Tisseur : Programme exécutable ou framework dynamique qui procède au tissage. Le tisseur peut être invoqué:

- statiquement avant la compilation du code cible (le tisseur travaille sur le code source),

- statiquement pendant la compilation du code cible (le tisseur intègre un compilateur du langage de programmation),

- statiquement après la compilation du code cible (le tisseur travaille sur le code précompilé: bytecode),

- dynamiquement avant exécution du code (au moment de la compilation Just-In-Time),

- dynamiquement pendant l'exécution du code (par la technique d'interception d'invocation de méthode, utilisée intensivement par les frameworks d'inversion de contrôle).

· Avantages et inconvénients

Le couplage entre les modules gérant des aspects techniques peut être réduit de façon très importante, en utilisant ce principe, ce qui présente de nombreux avantages :

Maintenance aisée : les modules techniques, sous forme d'aspect, peuvent être maintenus plus facilement du fait de son détachement de son utilisation,

Meilleure réutilisation : tout module peut être réutilisé sans se préoccuper de son environnement et indépendamment du métier ou du domaine d'application. Chaque module implémentant une fonctionnalité technique précise, on n'a pas besoin de se préoccuper des évolutions futures : de nouvelles fonctionnalités pourront être implémentées dans de nouveaux modules qui interagiront avec le système au travers des aspects.

Gain de productivité : le programmeur ne se préoccupe que de l'aspect de l'application qui le concerne, ce qui simplifie son travail.

Amélioration de la qualité du code : la simplification du code qu'entraine la programmation par aspect permet de le rendre plus lisible et donc de meilleure qualité.

Par contre le tissage d'aspect qui n'est finalement que de la génération automatique de code inséré à certains points d'exécution du système développé, produit un code qui peut être difficile à analyser (parce que généré automatiquement) lors des phases de mise au point des logiciels (débogages, test). Mais en fait cette difficulté est du même ordre que celle apportée par toute décomposition non linéaire (fonctionnelle ou objet par exemple).

IV. Choix d'une méthode d'analyse et de conception

Dans cette partie nous allons présenter deux démarches d'analyses et de conceptions. Il s'agit de UP et de la méthode RAD.

1. Le Processus Unifié (UP)

a. Définition

Le processus unifié est un processus de développement logiciel itératif, centré sur l'architecture, piloté par des cas d'utilisation et orienté vers la diminution des risques.

C'est un patron de processus pouvant être adaptée à une large classe de systèmes logiciels, à différents domaines d'application, à différents types d'entreprises, à différents niveaux de compétences et à différentes tailles de l'entreprise.

ü UP est Itératif

L'itération est une répétition d'une séquence d'instructions ou d'une partie de programme un nombre de fois fixé à l'avance ou tant qu'une condition définie n'est pas remplie, dans le but de reprendre un traitement sur des données différentes.

Elle qualifie un traitement ou une procédure qui exécute un groupe d'opérations de façon répétitive jusqu'à ce qu'une condition bien définie soit remplie.

Une itération prend en compte un certain nombre de cas d'utilisation et traite en priorité les risques majeurs.

Figure 3.1 : Illustration du caractère itératif de UP

ü UP est centré sur l'architecture

Une architecture adaptée est la clé de voûte du succès d'un développement. Elle décrit des choix stratégiques qui déterminent en grande partie les qualités du logiciel (adaptabilité, performances, fiabilité...).

Figure 3.2 : Modèle représentant les 4+1 vues de Kruchten

ü UP est piloté par les cas d'utilisation d'UML

Le but principal d'un système informatique est de satisfaire les besoins du client. Le processus de développement sera donc accès sur l'utilisateur.

Les cas d'utilisation permettent d'illustrer ces besoins. Ils détectent puis décrivent les besoins fonctionnels (du point de vue de l'utilisateur), et leur ensemble constitue le modèle de cas d'utilisation qui dicte les fonctionnalités complètes du système.

b. Vie du processus unifié

L'objectif d'un processus unifié est de maîtriser la complexité des projets informatiques en diminuant les risques. UP est un ensemble de principes génériques adapté en fonctions des spécificités des projets.

UP répond aux préoccupations suivantes : QUI participe au projet ?, QUOI, qu'est-ce qui est produit durant le projet ?, COMMENT doit-il être réalisé ?, QUAND est réalisé chaque livrable ?

UP gère le processus de développement par deux axes.

L'axe vertical représente les principaux enchaînements d'activités, qui regroupent les activités selon leur nature. Cette dimension rend compte l'aspect statique du processus qui s'exprime en termes de composants, de processus, d'activités, d'enchaînements, d'artefacts et de travailleurs.

L'axe horizontal représente le temps et montre le déroulement du cycle de vie du processus; cette dimension rend compte de l'aspect dynamique du processus qui s'exprime en terme de cycles, de phases, d'itérations et de jalons.

Figure 3.3 : Architecture bidirectionnelle du PU

UP répète un certain nombre de fois une série de cycle qui s'articule autours de 4 phases qui sont : analyse des besoins, élaboration, construction, transition.

Pour mener efficacement un tel cycle, les développeurs ont besoins de toutes les représentations du produit logiciel  qui sont : un modèle de cas d'utilisation, un modèle d'analyse détaillant les cas d'utilisation et procéder à une première répartition du comportement, un modèle de conception ,finissant la structure statique du système sous forme de sous-systèmes de classes et interfaces, un modèle d'implémentation, intégrant les composants, un modèle de déploiement ,définissant les noeuds physiques des ordinateurs, un modèle de test, décrivant les cas de test vérifiant les cas d'utilisation, et une représentation de l'architecture

c. Les Phases

Pour bien mener un projet du début à la fin, UP préconise les phases suivantes :

ü Expression des besoins

L'expression des besoins comme son nom l'indique, permet de définir les différents besoins : inventorier les besoins principaux et fournir une liste de leurs fonctions, recenser les besoins fonctionnels (du point de vue de l'utilisateur) qui conduisent à l'élaboration des modèles de cas d'utilisation, appréhender les besoins non fonctionnels (technique) et livrer une liste des exigences.

Le modèle de cas d'utilisation présente le système du point de vue de l'utilisateur et représente sous forme de cas d'utilisation et d'acteur, les besoins du client.

ü Analyse

L'objectif de l'analyse est d'accéder à une compréhension des besoins et des exigences du client. Il s'agit de livrer des spécifications pour permettre de choisir la conception de la solution. Un modèle d'analyse livre une spécification complète des besoins issus des cas d'utilisation et les structure sous une forme qui facilite la compréhension (scénarios), la préparation (définition de l'architecture), la modification et la maintenance du futur système.

Il s'écrit dans le langage des développeurs et peut être considéré comme une première ébauche du modèle de conception.

ü Conception

La conception permet d'acquérir une compréhension approfondie des contraintes liées au langage de programmation, à l'utilisation des composants et au système d'exploitation. Elle détermine les principales interfaces et les transcrit à l'aide d'une notation commune. Elle constitue un point de départ à l'implémentation :

- elle décompose le travail d'implémentation en sous-système

- elle crée une abstraction transparente de l'implémentation

ü Implémentation

L'implémentation est le résultat de la conception pour implémenter le système sous formes de composants, c'est-à-dire, de code source, de scripts, de binaires, d'exécutables et d'autres éléments du même type. Les objectifs principaux de l'implémentation sont de planifier les intégrations des composants pour chaque itération, et de produire les classes et les sous-systèmes sous formes de codes sources.

ü Tests

Les tests permettent de vérifier des résultats de l'implémentation en testant la construction. Pour mener à bien ces tests, il faut les planifier pour chaque itération, les implémenter en créant des cas de tests, effectuer ces tests et prendre en compte le résultat de chacun.

2. La méthode RAD

Aujourd'hui, qualité et réactivité font partie des objectifs généraux de beaucoup d'entreprises. Cela entraîne un certain nombre de projets, qui tout en apportant satisfaction aux utilisateurs, doivent être menés dans un délai court. C'est à cela que répond la méthode RAD. RAD est une méthode basée sur le partenariat. L'utilisateur s'affirme le vrai maître de son application et, par sa participation active, il s'en approprie la réalisation. Le RAD et le prototypage permettent de réaliser en concevant, tout en testant ce que l'on réalise. La méthode RAD propose de remplacer le cycle de vie classique par un autre découpage temporel. Le déroulement est d'abord linéaire, puis il suit le modèle de la spirale. Les étapes sont au nombre de cinq :

ü La phase d'Initialisation

Cette phase permet de définir le périmètre général du projet, de structurer le travail par thèmes, de sélectionner les acteurs pertinents et d'amorcer une dynamique de projet. Elle représente environ 6% du projet en charge.

ü La phase Expression des besoins

Cette phase permet de spécifier les exigences du système lors des entretiens avec les utilisateurs et de définir la solution globale sur les plans stratégique, fonctionnel, technologique et organisationnel. Cette phase représente environ 9% du projet.

ü La phase de Conception

Cette phase permet de concevoir et de modéliser le futur système avec le concours des utilisateurs pour l'affinage et la validation des modèles. C'est aussi dans cette phase que nous validons le premier niveau de prototype présentant l'ergonomie et la cinématique générale de l'application. Cette phase représente environ 23% du projet.

ü La phase de Construction (développement itératif).

Durant cette phase, notre équipe développe l'application module par module. L'utilisateur participe toujours activement aux spécifications détaillées et à la validation des prototypes. Plusieurs sessions itératives sont nécessaires. Cette phase représente environ 50% du projet.

ü La phase de mise en oeuvre

Des recettes partielles ayant été obtenues à l'étape précédente, il s'agit dans cette phase d'officialiser une livraison globale et de transférer le système en exploitation et maintenance. Cette phase représente environ 12% du projet.

V. Le langage UML

La modélisation est incontournable pour permettre aux différents acteurs de coopérer et de dialoguer efficacement. Ainsi Il est donc important de connaître le langage et les techniques de modélisation et de savoir quels modèles sont les plus appropriés dans chaque situation. En effet, de la même manière qu'il n'est pas judicieux d'utiliser tous les éléments de la langue française pour écrire un article, il n'est pas non plus obligatoire d'utiliser tous les concepts du langage UML dans un projet.

Nous allons, dans les paragraphes suivants, présenter l'intérêt d'utiliser UML dans la conception d'un SIG ainsi que les différents diagrammes utilisés par ce langage.

1. Pourquoi UML ?

Nombreuses sont les tentatives d'application des méthodes de conception des systèmes d'information pour la mise en oeuvre des systèmes d'information géographique. Les raisons les plus significatives de leur inefficacité dans la conception des systèmes d'information géographique sont entre autres les suivantes.

Ces méthodes reposent sur deux approches distinctes, privilégiant soit les données, soit les traitements. Or le fonctionnement d'un système d'information géographique repose justement sur une interdépendance étroite entre les données et les traitements.

L'information géographique s'organise hiérarchiquement et les traitements qui sont appliqués sont souvent complexes et reposent aussi sur des processus d'agrégation de l'information. Or les méthodes proposées par les systèmes d'information d'entreprise ne prennent en compte que des traitements simples de type flux ou échange de données.

L'utilisation des méthodes de conception des SI présuppose que soient, au préalable, clairement identifiés les besoins des applications et que l'on ait la maîtrise de leur évolution. Or en matière d'analyse spatiale, de gestion et de planification territoriale, les besoins s'identifient le plus souvent en fonction des données dont on dispose, des résultats issus des traitements réalisés, et de l'évolution des requêtes adressées par les utilisateurs. Il est certain que la modélisation UML ayant été élaborée pour répondre aux besoins des systèmes d'information classiques n'est donc pas conçue, a priori, pour répondre aux spécificités des systèmes intégrant de l'information géographique Ces derniers gérant à la fois des données graphiques et des données non graphiques sont considérés comme un cas particulier des SI.

Toutefois, il semble qu'a priori les principaux concepts proposés par UML soient pertinents pour l'analyse et la conception des systèmes de gestion et d'analyse des territoires. Cette approche peut constituer un support intéressant en termes d'acquisition des connaissances, de structuration de l'information géographique à intégrer dans l'outil à concevoir, et de spécification des fonctionnalités de l'outil.

2. Diagrammes structurels (les vues statiques)

Ces diagrammes permettent de visualiser, spécifier, construire et documenter l'aspect statique ou structurel du système d'information. Il s'agit outre les diagrammes de cas d'utilisation, des diagrammes de classes, d'objets, mais aussi de déploiement et de composants

a. Les cas d'utilisation (uses cases)

Les cas d'utilisation sont une technique de description du système étudié privilégiant le point de vue de l'utilisateur. Ils décrivent sous la forme d'actions et de réactions, le comportement d'un système et servent, par conséquent, à structurer les besoins des utilisateurs et les objectifs correspondants du système.

La détermination et la compréhension des besoins sont souvent difficiles car les intervenants sont noyés sous de trop grandes quantités d'informations. Or, comment mener à bien un projet si l'on ne sait pas où l'on va ?

Les uses cases ne doivent pas chercher l'exhaustivité, mais clarifier, filtrer et organiser les besoins. Ils ne doivent donc en aucun cas décrire des solutions d'implémentation. Leur but est justement d'éviter de tomber dans la dérive d'une approche fonctionnelle, où l'on liste une litanie de fonctions que le système doit réaliser.

b. Les diagrammes d'objets

Ce type de diagramme UML montre des objets (instances de classes dans un état particulier) et des liens (relations sémantiques) entre ces objets. Les diagrammes d'objets s'utilisent pour montrer un contexte (avant ou après une interaction entre objets par exemple). Il sert essentiellement en phase exploratoire, car il possède un très haut niveau d'abstraction.

c. Les diagrammes de classes

Les diagrammes de classes expriment de manière générale la structure statique d'un système, en termes de classes et de relations entre ces classes.

Une classe permet de décrire un ensemble d'objets (attributs et comportement), tandis qu'une relation ou association permet de faire apparaître des liens entre ces objets.

d. Les diagrammes de paquetages (ou package)

Les paquetages sont des éléments d'organisation des modèles. Ils regroupent des éléments de modélisation, selon des critères purement logiques. Ils permettent d' encapsuler des éléments de modélisation et de structurer un système en catégories ( vue logique) et sous-systèmes ( vue des composants).  Ils servent de « briques » de base dans la construction d'une architecture.

e. Les diagrammes de composants et de déploiement

Les diagrammes de composants permettent de décrire l'architecture physique et statique d'une application en termes de modules : fichiers sources, librairies, exécutables, etc. Ils montrent la mise en oeuvre physique des modèles de la vue logique avec l'environnement de développement.

Les diagrammes de déploiement montrent la disposition physique des matériels qui composent le système et la répartition des composants sur ces matériels. Les ressources matérielles sont représentées sous forme de noeuds, connectés entre eux à l'aide d'un support de communication.

3. Diagrammes comportementaux (les vues dynamiques)

Ils modélisent les aspects dynamiques du système, c'est à dire les différents éléments qui sont susceptibles de subir des modifications. Parmi eux on distingue, les diagrammes de séquence, de collaboration, d'états - transitions et d'activités.

Ils représentent la dynamique du système, à savoir, non seulement les interactions entre le système lui même et les différents acteurs du système, mais aussi, la façon dont les différents objets contenus dans le système communiquent entre eux.

a. Les diagrammes de séquence

Les diagrammes de séquences permettent de représenter des collaborations entre objets selon un point de vue temporel, on y met l'accent sur la chronologie des envois de messages. Les diagrammes de séquences peuvent servir à illustrer un cas d'utilisation

b. Les diagrammes de collaboration

Les diagrammes de collaboration montrent des interactions entre objets (instances de classes et acteurs). Ils permettent de représenter le contexte d'une interaction, car on peut y préciser les états des objets qui interagissent.

c. Les diagrammes d'états- transitions

Ces diagrammes servent à représenter des automates d'états finis, sous forme de graphes d'états, reliés par des arcs orientés qui décrivent les transitions. Ils permettent de décrire les changements d'états d'un objet ou d'un composant, en réponse aux interactions avec d'autres objets/composants ou avec des acteurs.

Un état se caractérise par sa durée et sa stabilité, il représente une conjonction instantanée des valeurs des attributs d'un objet.

Une transition représente le passage instantané d'un état vers un autre. Une transition est déclenchée par un événement. En d'autres termes : c'est l'arrivée d'un événement qui conditionne la transition. Les transitions peuvent aussi être automatiques, lorsqu'on ne spécifie pas l'événement qui la déclenche. En plus de spécifier un événement précis, il est aussi possible de conditionner une transition, à l'aide de "gardes" : il s'agit d'expressions booléennes, exprimées en langage naturel (et encadrées de crochets).

d. Les diagrammes d'activités

UML permet de représenter graphiquement le comportement d'une méthode ou le déroulement d'un cas d'utilisation, à l'aide de diagrammes d'activités (une variante des diagrammes d'états-transitions). Une activité représente une exécution d'un mécanisme, un déroulement d'étapes séquentielles. Le passage d'une activité vers une autre est matérialisé par une transition. Les transitions sont déclenchées par la fin d'une activité et provoquent le début immédiat d'une autre (elles sont automatiques).

En théorie, tous les mécanismes dynamiques pourraient être décrits par un diagramme d'activités, mais seuls les mécanismes complexes ou intéressants méritent d'être représentés.

Conclusion : Le langage UML, offre ainsi de nombreux avantages pour l'analyse et la conception d'un système d'information géographique. Par conséquent, nous combinerons UML au Processus Unifié pour mener à terme notre système d'information.

CHAPITRE

4

* ⁶ Implémentation : Elle consiste à réaliser le programme conformément aux critères définis dans les phases d'analyse et de conception.

* ⁷ Framework : Infrastructure logicielle facilitant la conception et le développement d'applications.

* ⁸ REMORA : Méthode qui met l'accent sur les événements qui affectent l'état du système à travers l'exécution d'opérations, sur leur ordonnancement dans le temps, leur synchronisation et leurs dépendances causales.