II.1. INTRODUCTION
UML (UnifiedModelingLanguage) est une méthode de modélisation orientée Objet et développée en réponse à l’appel à proposition lancée par l’OMG (Object Manager Group) dans le but de définir la notation standard pour la modélisation des applications construites à l’aide d’objets. Elle est utilisée pour spécifier un logiciel et ou pour concevoir un logiciel. Dans la spécification, le modèle décrit les classes et les cas d’utilisation vus de l’utilisateur final du logiciel. Il est nécessaire de préciser qu’une méthode telle qu’UML ne suffit pas à produire un développement de logiciel de qualité à elle seule.En effet, UML n’est qu’un formalisme, ou plutôt un ensemble de formalisme permettant d’appréhender un problème ou un domaine et de modéliser, ni plus ni moins. Un formalisme n’est qu’un outil.
Le succès du développement du logiciel dépend évidemment de la bonne utilisation d’une méthode comme UML (mais il dépend surtout de la façon dont on utilise cette méthode à l’intérieur du cycle de développement du logiciel. Selon certains auteurs, UML n’est pas une méthode mais un langage. Il peut donc être utilisé sans pour autant remettre en cause les procédés habituels de conception de l’entreprise. En particulier les méthodes les plus concernées telles que proposées par OMT sont tout à fait utilisables.
II.2. ETUDE COMPARATIVE DES SOLUTIONS POSSIBLES
Cette partie de l’étude a pour objet de faire une analyse des choix conceptuels de notre application. Pour ce faire nous allons procéder à la comparaison de deux approches de modélisation d’un système informatique afin de faire un choix objectif justifié. Nous avons donc l’approche systématique et l’approche orientée Objet.
II.2.1. L’approche Systématique
Elle définit un système comme un ensemble d’éléments en interaction dynamique, organisée en fonction d’un but. Le concept de base de cette approche est la séparation des données et des traitements. Ce type d’approche est efficace lorsque les interactions sont non linéaires et fortes. Mais en cas d’évolution elle rend la maintenance des systèmes complexe et implique une lenteur dans le développement des logiciels.
II.2.2. L’approche Orientée Objet
Dans cette approche on note qu’elle conduit à une conception dans laquelle il y a un fort couplage des données et des traitements grâce au principe d’encapsulation. Le problème de maintenance en cas d’évolution relevée dans l’approche systématique est résolu à ce niveau du fait qu’avec cette méthode on maitrise mieux la complexité du système et on a une facilité d’évolution des modèles conçus (il est plus facile de rajouter des objets dans un modèle objet).Pour mener bien notre choix, nous optons pour les critères de base suivants :
Pour la conception du système, nous optons pour la méthode orientée objet du fait des avantages qu’elle offre. Cette approche offre une technique qui est une aide efficace pour résoudre certains problèmes liés à la notion de réutilisation des objets (bibliothèques de classes) en se basant sur des mécanismes fondamentaux tels que l’héritage et le polymorphisme.
De plus, l’approche objet est permet une conception qui facilite la maintenance des applications (encapsulation des données et des traitements). Cela est dû au fait qu’il est possible par exemple de modifier une méthode sans toucher à son interface ou de créer une sous classe héritée de celle qui nous intéresse.
L’adoption d’une approche objet pour la conception s’appuie sur une méthode ou un langage efficace pour modéliser le système d’information. La qualité d’une conception est intimement liée à la méthode utilisée pour sa conduite. Ces trois méthodes ont été mis au point autour des années 90 ; elles ne sont pas imposées entant que telles, mais faisant partie des méthodes les plus dominantes de cette époque. Une de leurs limites était due au fait qu’elles ne disposaient d’aucune dimension méthodologique dans la conception. Mais pourquoi analyser et modéliser ? C’est pour éviter les résultats négatifs suivants :
Mais aussi c’est pour :
II .3. MODELISER AVEC UML
Un modèle est une abstraction de la réalité, alors que l’abstraction est un élément essentiel de l’approche objet. L’abstraction désigne aussi un processus qui consiste à identifier les caractéristiques intéressantes d’une entité retenue par un observateur en vue d’une utilisation précise. Un modèle est une vue subjective mais pertinente de la réalité. Bien qu’un modèle ne reflète une réalité absolue, il représente au moins les aspects importants de la réalité. Il se caractérise par la réduction de la complexité du système étudié, c'est-à-dire qu’il facilite sa compréhension, il représente aussi le système étudié et reproduit ses comportements. UML étant un langage qui représente le modèle, nous avons remarqué qu’il ne définit pas le processus d’élaboration de ce modèle. Modéliser une application n’est pas une activité linéaire, il s’agit d’une tache très complexe, qui nécessite une approche :
Le langage UML fournit un ensemble d’outils permettant de représenter l’ensemble d’éléments du mode objet ainsi que les liens qui les relient. Toutefois, étant donné qu’une seule représentation est trop subjective, UML fournit un moyen astucieux permettant de représenter diverses projections d’une même représentation grâce aux vues. Une vue est constituée d’un ou plusieurs diagrammes. On distingue deux types de vues : vues statiques qui représentent le système physiquement, et vues dynamiques qui montrent le fonctionnement du système.
II.3.1. Diagramme de flux
C’est une représentation graphique du flux de données à travers un système d’information. Il peut aussi être utilisé pour la visualisation des traitements des données en conception structurée.
Réponse à la requête |
BDD |
CLIENT |
ADMIN |
COMPAGNIE |
Consulte l’horaire |
Soumission de l’horaire à l’admin |
FIGURE
Enregistrement de l’horaire
Réponse du système
Interprétation du digramme de flux
Le client consulte l’horaire et effectue une réservation, l’administrateur enregistre l’horaire et visualise la réservation, la compagnie soumet l’horaire à l’administrateur.
II.3.2. Cas d’utilisation par acteur
Avant d’entamer ce point, il nous est indispensable de définir les mots qui le composent.
Le mot acteur a différentes significations que voici :
Nous utiliserons l’expression « cas d’utilisation » pour signifier :
Ainsi pour notre système, les acteurs sont les suivants :
II.3.3. Description des cas d’utilisation d’un acteur
II.4. LES SCENARIO PAR CAS
Un scénario c’est :
II.4.1. Présentation des Scénarios
La compagnie soumet l’horaire à l’administrateur : Il s’agit ici de donner l’horaire à l’administrateur pour qu’il le mette en ligne.
II.5. Diagramme des cas d’utilisation
Un cas d’utilisation représente une interaction entre acteur et système dans le but de répondre à un besoin fondamental. Il est décrit par un ensemble des scénarios qui précisent le dialogue entre le système et les acteurs. Un cas d’utilisation doit rendre un service réel, complet, apportant une valeur ajoutée à l’acteur. C’est sa caractéristique essentielle. A l’inverse des fonctions comme « saisir son code secret » ou choisir le montant ne sont probablement pas des cas d’utilisation. Un cas d’utilisation est un élément atomique, qui doit satisfaire aux critères suivants :
Effectuer une réservation |
Mise à jour de l’horaire |
Visualiser les réservations |
Donner l’horaire à l’admin |
Consulter l’horaire |
Client |
Administrateur |
Compagnie |
FIGURE
II.6. DIAGRAMME D’ACTIVITE ET DE SEQUENCE
Le digramme d’activité donne une vision des enchaînements des activités propres à une opération ou à un cas d'utilisation. Le diagramme d'activité est attaché à une catégorie de classes et décrit le déroulement des activités de cette catégorie. Il indique la part prise par chaque objet dans l'exécution d'un travail. Dans les lignes qui suivent, nous allons donner les digrammes qui représentent les activités à réaliser pour chaque objet spécifié. [1]
Il est important de signaler, pour ce cas, que nous présenterons seulement les diagrammes nécessaires de notre système.
Ce diagramme nous permet de voir le comportement du système lorsqu’une personne veut se connecter en tant qu’administrateur du site. L’espace administrateur sera affiché si le login et le mot de passe sont corrects et non dans le cas contraire. Il se présente de cette manière :
FIGURE
Le diagramme ci-dessus donne celui de séquence que voici :
admin |
Système |
Envoi du Login et du Password |
Test des coordonnées |
Confirmation |
FIGURE
Ce petit diagramme nous montre les évènements qui se déroulent avant et après l’insertion de nouveaux enregistrements dans la base.
Le diagramme de séquence relatif à ce diagramme d’activité est le suivant :
Utilisateur |
Système |
Soumission des données |
Test des données |
Insertion au cas où ces données n’existent pas |
FIGURE
Contrairement au précédent, ce diagramme nous montre les évènements qui se déroulent avant et après la mise à jour des enregistrements se trouvant dans la base.
FIGURE
Utilisateur |
Système |
Soumission de la requête |
Test de la requête |
Affichage du résultat |
Mise à jour |
En fin, il donne aussi le diagramme de séquence suivant :
FIGURE
La modélisation objet consiste à créer une représentation abstraite sous forme d'objets, d'entités ayant une existence matérielle (arbre, personne, téléphone, ...) ou bien virtuelle (sécurité sociale, compte bancaire, ...). Une classe est caractérisée par plusieurs notions:
On construit généralement cette identité grâce à un identifiant découlant naturellement du problème.
Présentation du diagramme de classe
[1] Http://uml.free.fr/cours/p18.html, consulté le 2 Avril 2015 à 13h°°