Memoire Online - Intégration d'un observatoire urbain sur Google Maps

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.

3.3.1. Définition et principe d'UML

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.

3.3.2. Le formalisme 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'étatstransitions 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.

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	Souvent, certaines activités
Synchronisation	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.

Intégration d'un observatoire urbain sur Google Maps

3.3 MODELISATION UML

3.3.1. Définition et principe d'UML

3.3.2. Le formalisme UML