Memoire Online - Intégration d'un observatoire urbain sur Google maps : cas des infrastructures de la santé de la ville de Douala

La mise en oeuvre d'un Systèmes d'Information Géographique dans une démarche d'analyse spatiale au même titre qu'un système d'information classique requiert la clarification et la définition des objectifs à atteindre ainsi qu'une analyse objective du domaine du besoin à solutionner.

La mise en oeuvre d'une méthodologie formelle (Méthode) permet de formaliser clairement les étapes préliminaires du développement d'un système afin de rendre le résultat plus fidèle aux besoins du demandeurPour y arriver, tout part d'une expression des besoins brute de la part de l'utilisateur (demandeur) ensuite ces besoins bruts sont complétés par les recherches d'information par des techniques de recueil d'information (interviews, observations, études des documents) ainsi que de l'analyse de l'existant éventuel (c'est-à-dire comment les acteurs et le système se comportent actuellement). Nous partirons des généralités sur les méthodes d'analyse, en passant par la classification des principales méthodes existante, pour présenter sommairement la méthode retenue : l'approche UML (Unified Modelling Langage) qui propose de nombreux modèles permettant d'identifier les structures statiques et dynamiques des systèmes informatiques. Après avoir présenté globalement cette approche, nous étudierons son application aux SIG et nous terminerons par la présentation des étapes de notre projet.

Une méthodologie d'analyse propose au concepteur des modèles, des méthodes et des outils.

· Un modèle, est un ensemble de concepts et de lois (de complétude, de cohérence, de transformation ...) unissant ces concepts, qui permettent de décrire "intelligemment" une réalité. A titre subsidiaire, un modèle comporte des formalismes, qu'il ne faut pas croire limités aux seuls schémas graphiques ou diagrammes dont, à l'instar de tout concepteur, les informaticiens sont friands.

· Une méthode propose des démarches et des règles de bon usage. Idéalement, elle se fonde sur des modèles éprouvés et vise à en exploiter les potentialités en vue de fabriquer des objets répondant à certains critères de qualité.

· AGL (Atelier de génie logiciel) Depuis la fin de la décennie 1980-90 sont apparus sur le marché des outils logiciels d'aide à l'analyse. Ces outils ont reçu le nom de "CASE tools" ("Computer Aided Software Engineering") ou, en français, d'ateliers de génie logiciel. Ces outils facilitent les tâches au niveau des éléments ci après :

- support (enregistrement et restitution) des formalismes, particulièrement des dessins;

- application (vérification) des règles de syntaxe, de cohérence, de complétude ...;

- exploitation des lois de transformation spécifiques des modèles, se basant sur les propriétés des objets déjà définis pour définir de nouveaux objets

Pour mener à bon port un projet informatique, une méthode est nécessaire pour :

ü Pour sortir la construction des systèmes d'information de l'empirisme individuel et la fonder sur une coopération efficace entre informaticiens et utilisateurs;

ü pour permettre la communication entre les membres de l'équipe de conception;

ü pour permettre d'évaluer le système à tout moment de son cycle, tant sur le plan de son efficacité technique que sur celui de sa pertinence par rapport aux besoins des gestionnaires;

ü pour améliorer les coûts, les délais et la productivité des activités de développement.

Comme le mentionne le Dr Nkenlifack dans ses notes de cours et confirmé par notre expérience sur le terrain, quelque soit l'approche méthodologique, Le cycle de vie d'un projet SI comprend généralement au minimum les activités suivantes :

En général on divise les méthodes d'analyse et de conception en trois grandes familles (approches):

Cette approche est basée sur le principe de la décomposition hiérarchique des processus et des flux de données afin de mettre en oeuvre le système d'information. Le système étudié est ainsi abordé par les fonctions qu'il doit assurer plutôt que par les données qu'il doit gérer. Les méthodes de conception de première génération (SADT, SA-SD) sont basées sur cette approche, qui préconise un développement linéaire.

L'approche systémique consiste à élaborer des modèles capables de décrire ou de simuler globalement ou partiellement le comportement des systèmes étudiés. En se basant sur le modèle entité relation. L'approche cartésienne n'étant pas efficace pour des systèmes complexes comme l'entreprise, les méthodes d'analyse de seconde génération sont nées et basée essentiellement sur l'approche systémique des systèmes. Un objet complexe se caractérise par un nombre important de relations entre les éléments qui le constituent, alors qu'un objet compliqué est caractérisé par un nombre important d'éléments. D'où la pertinence de cette approche qui a vu naître les Les méthodes d'analyse comme Merise, REMORA etc.. basées sur une représentation de tous les faits pertinents qui surviennent dans une organisation en matérialisant les relations entre les entités de l'organisation

Dès lors qu'un système d'information est appelé à évoluer dans le temps, l'approche fonction se trouve butée à la complexité de la maintenance et de l'évolution d'où la pertinence d'une nouvelle approche basée sur les objets. Cette approche permet d'appréhender un système en centrant l'analyse sur les données et les traitements à la fois par le concept d'objet et leurs fonctions (appelées ici méthodes). 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. La plus value qu'offre l'approche objet est qu'elle est fondée sur la modularité, la flexibilité et surtout la réutilisabilité qui favorisent la maintenance et l'évolution des applications informatique.

Entre 1970 et 1990, plusieurs méthodes objet ont vu le jour parmi les quelles trois ont marqués les esprits :

Ce n'est que vers la fin des années 90 que les trois méthodes ont fusionné pour donner naissance à UML (Unified Modeling language) que nous avons retenu dans le cadre de notre travail.

La modélisation étant un moyen efficace de bien définir et analyser les besoins pour espérer aboutir au résultat escompté, nous avons jugé important de présenter le langage de modélisation que nous avons choisis UML. Nous commencerons par sa définition, ensuite par ses différentes vues d'abstraction du monde réel.

UML, Unified Modeling Language, langage de modélisation objet unifié est une démarche orientée objet. Elle est née comme nous l'avons dit de la fusion de trois méthodes orientées objet Booch, OMT Object Modeling Technique et OOSE Object Oriented Software Engineering, conçues respectivement par Grady Booch, James Rumbaugh et Ivar Jacobson.

Les 3 experts ont focalisé leur attention sur les deux aspects : modélisation et formalisation afin de concevoir un langage de modélisation standard et universel utilisé notamment pour le développement informatique en langage objet.

La modélisation et la formalisation à l'aide d'un vocabulaire standardisé et de surcroît orienté objet conferent à la méthode tout son intérêt. La formalisation et la modélisation facilitent en effet la définition du problème à traiter et la compréhension par l'ensemble des principales parties prenantes, sous réserve que chaque partie maitrise son formalisme.

Une fois le modèle bien défini, il est plus aisé de s'y référer lors du développement afin de s'assurer de la conformité de ce dernier. Un outil précieux qui explique à lui seul l'essor de la démarche UML.

Les spécifications d'UML son disponibles sur le site de Rational Software (RATIONAL 1999).

UML est un langage de modélisation de données orienté objet basé sur l'utilisation de neuf types de diagrammes : les diagrammes de classes, les diagrammes d'objets, les diagrammes de composants, les diagrammes de déploiement, les diagrammes de cas d'utilisation, les diagrammes de collaboration, les diagrammes de séquence, les diagrammes d'états-transitions et les diagrammes d'activités.

Les parties statiques d'un système sont décrites à l'aide des quatre premiers diagrammes, tandis que les cinq autres servent à détailler les aspects dynamiques du même système.

Au sein des diagrammes statiques, on distingue ceux décrivant les aspects conceptuels d'un système, et ceux décrivant les aspects physiques ou d'implémentation. Nous nous limiterons ici à la présentation du formalisme des 04 diagrammes suivant : Cas d'utilisation, Séquences, Classes et déploiements qui à notre avis suffisent pour modéliser un système de l'ensemble des points de vue.

Il représente les fonctions du système du point de vue de l'utilisateur et décrit sous la forme d'actions et de réactions, le comportement d'un système. Il sert enfin à structurer les besoins des utilisateurs et les objectifs correspondants du système. Il faudra ici distinguer les acteurs, les cas d'utilisation et enfin le diagramme des cas d'utilisation proprement dit.

UML parle d'acteur et non d'utilisateur pour décrire les entités externes qui interagissent avec le système en envoyant des événement comme par exemple « saisir les coordonnées géographiques d'un site », « cliquer sur le bouton Ok » ou encore envoyer un Fichier KML. Les acteurs reçoivent aussi des informations de la part du système comme par exemple « affichage d'une carte géographique ». Bref un acteur représente un rôle que les utilisateurs du futur système auront à jouer. L'inventaire objectif de tous les potentiels acteurs d'un système est capital pour le succès de l'interface et donc du système à produire.

Un acteur sera représenté par le bonhomme suivant dont l'étiquette devra porter son nom :

Les cas d'utilisation représentent les actions possibles entre un ou plusieurs acteurs avec le système. Le cas d'utilisation est représenté par une ellipse, portant en contenu un texte le décrivant. Un exemple est matérialisé par la figure ci-dessous :

Lorsque tous les acteurs et tous les cas d'utilisation ont été inventoriés ainsi que les différentes types de relations entre eux l'ensemble dans un package forme le diagramme des cas d'utilisation matérialisé comme indique l'exemple ci-dessous.

Il se concentre sur la séquence temporelle des interactions entre les objets. Avec les objets « acteur » et « système », il permet de représenter le déroulement des scénarios (instances des cas d'utilisation).

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. Ils peuvent servir à illustrer un cas d'utilisation. L'ordre d'envoi d'un message est déterminé par sa position sur l'axe vertical du diagramme ; le temps s'écoule "de haut en bas" de cet axe.

Dans un souci de simplification, on représente l'acteur principal à gauche du diagramme, et les acteurs secondaires éventuels à droite du système. Le but étant de décrire comment se déroulent les actions entre les acteurs ou objets.

Remarque : Le diagramme des séquences peut être représenté en considérant le système comme une espèce de boite noire lors de la phase d'analyse. Mais lorsqu'il faudra passer à la conception, il sera nécessaire d'éclater cette boite noire par des objets logiciels.

Figure 15. Exemple de Diagramme des séquences avec le système vu comme une boite noire

Les diagrammes d'activité sont utilisés pour documenter le déroulement des opérations dans un système, du niveau stratégique au niveau opérationnel. L'usage général des diagrammes d'activité permet de faire apparaître les flots de traitements induits par les processus internes par rapport aux évènements externes.

Processus	Description	Symbole représentatif
Etat d'activité	l'état d'activité marque une action faite par un objet. Il est représenté par un rectangle arrondi.
Transition	quand un état d'activité est accompli, le traitement passe à un autre état d'activité. Les transitions sont utilisées pour marquer ce passage. Les transitions sont modélisées par des flèches
Couloir *(Swimlane)*	Dans un diagramme d'activité, on peut placer les activités dans des couloirs (Swimlanes) qui représentent des systèmes. Les objets sont énumérés au dessus de la colonne, et les barres verticales séparent les colonnes pour former les swimlanes.
Etat initial	l'état initial marque le point d'entrée la première activité. Il est représenté, comme dans le diagramme d'état, par un cercle plein. Il ne peut y avoir qu'un seul état initial sur un diagramme.
Etat final	L'état final marque la fin du déroulement des opérations modélisées. Il peut y avoir des états finaux multiples sur un diagramme. Ils sont représentés par un cercle plein entouré d'un autre cercle.
Barre de Synchronisation	Souvent, certaines activités peuvent être faites en parallèle. Pour dédoubler le traitement "Fork", ou le reprendre quand des activités multiples ont été accomplies ("join"), des barres de synchronisation sont utilisées. Celles ci sont modélisées par des rectangles pleins, avec des transitions multiples entrantes ou sortantes.

Les diagrammes de classes permettent de représenter la structure statique d'un système, en termes de classes et de relations entre ces classes. Une classe étant un ensemble d'objets (attributs et comportement), tandis qu'une relation ou association permet de faire apparaître des liens entre ces objets. Il est l'équivalent du modèle conceptuel des données (MCD) en Merise.

UML ne propose pas de méthode de réalisation. UML est totalement indépendant des langages objet de développement. Une fois la problématique modélisée, une méthode de conduite de projet axée sur la qualité est généralement suffisante pour mener à bien le projet. Les méthodes dites AGILES sont indiquées pour les projets informatiques comme le notre.

Les méthodes agiles sont axées sur les éléments suivants qui privilégient le dialogue entre tous les acteurs du projet à savoir :

Les grands principes de la modélisation terminés nous croyons légitime de les appliquer à notre cas. Le chapitre suivant traite justement de l'analyse et de la conception de notre plate-forme nommée « VisioCity ».

Intégration d'un observatoire urbain sur Google maps : cas des infrastructures de la santé de la ville de Douala

CHAPITRE 3. APPROCHE METHODOLOGIQUE