CHAPITRE II. ANALYSE CONCEPTUELLE DE DONNEES

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 :

• Possibilité d’extension des besoins du système ;
• La réutilisation des objets ;
• La souplesse de la conception ;
• La rapidité et l’efficacité.

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 :

• Les modules ne fonctionnent pas ensemble ;
• Le produit est non conforme aux besoins ;
• Le produit est difficile à maintenir et à faire évoluer;
• Le produit présente beaucoup d’anomalies et de bugs.

Mais aussi c’est pour :

• Visualiser le système ;
• Spécifier sa structure et son comportement ;
• Aider à sa construction ;
• Travailler en équipe.

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 :

• Itérative et incrémentale (grâce aux niveaux d’abstraction), car il est plus efficace de construire et valider par étape, ce qui est difficile à cerner et à maîtriser ;
• Centré sur l’architecture, car il s’agit de la clé de voûte qui conditionne la plupart de des qualités d’une application informatique ;
• Guidé par la prise en compte des besoins des utilisateurs (à l’aide des cas d’utilisation), car ce qui motive l’existence même du système à concevoir, c’est la satisfaction des besoins de ses utilisateurs.

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.

1. ACTEUR

Le mot acteur a différentes significations que voici :

• Utilisateur interne ou externe direct du système ;
• Objet ou ensemble d’objets communiquant directement avec le système sans en faire partie ;
• Tout ce qui interagit directement avec le système.

1. CAS D’UTILISATION

Nous utiliserons l’expression « cas d’utilisation » pour signifier :

• Identification des fonctionnalités pouvant être fournies par un système en interagissant avec les acteurs ;
• Organisation des fonctionnalités selon le point de vue utilisateur.

Ainsi pour notre système, les acteurs sont les suivants :

• Clients
• Administrateur
• Compagnie

II.3.3. Description des cas d’utilisation d’un acteur

• Le Client :
• Consulte l’horaire
• Effectue une réservation
• L’administrateur :
• Enregistre l’horaire
• Visualise les réservations
• La CompagnieSoumet l’horaire à l’administrateur

II.4. LES SCENARIO PAR CAS

Un scénario c’est :

• La séquence d’événements se produisant lors d’une exécution particulière d’un système ;
• La représentation de l’histoire de l’exécution d’un système réel existant ou d’un prototype d’exécution d’un système envisagé ;
• Une portée variée : comprenant tous les événements du système, ou n’incluant que les événements affectant certains objets ou générés par certains objets.

II.4.1. Présentation des Scénarios

1. Client :

• Consulter l’horaire : le client, à partir du site, il visualise l’horaire de l’avion appartenant à la compagnie de son choix ;
• Effectuer une réservation après avoir payé la totalité ou le ¾ du billet, le client écrit son identité via internet.

1. Administrateur :

• Mettre à jour l’horaire : vérifier si l’horaire complété par le gestionnaire de la compagnie est conforme à celui donné par la compagnie ;
• Visualiser les réservations : si les réservations sont prêtes, l’administrateur les visualise.

1. Compagnie :

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 :

• Unité de Temps: le déroulement d’un scénario doit se réaliser  dans un délai relativement bref. A l’inverse, une interaction ne peut pas durer plusieurs mois.
• Unité de lieu: on évite le changement de lieu au cours d’un déroulement d’un scénario (on débute par le scénario au bureau pour le terminer à domicile) ;
• Unité d’acteur (un acteur bénéficiaire) : le service est rendu par un seul acteur (acteur principal) qui est souvent la source du déclenchement du cas d’utilisation. Les autres acteurs qui interagissent avec le cas d’utilisation sont des acteurs secondaires. Ils participent aux scénarios, mais ne sont pas bénéficiaires des services.

Effectuer une réservation

Mise à jour de l’horaire

Visualiser les réservations

Donner l’horaire à l’admin

Consulter l’horaire

Client

• Non interruptible : il n’est pas possible dans une utilisation normale d’interrompre le déroulement d’un scénario pour le reprendre plus tard. Le scénario s’arrête lorsque le service est rendu. Typiquement, un acteur ne va pas prendre ses congés au milieu du déroulement d’un scénario. Les critères ci-dessous mettent l’accent sur le caractère atomique des cas d’utilisation. Il ne s’agit pas des critères formels, mais ils constituent une aide pour la compréhension, la validation et la construction des cas d’utilisation.Notre diagramme d’utilisation se présente de la manière suivante :

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.

• Diagramme d’activité d’authentification administrateur

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

• Diagramme d’activité d’insertion de données dans la base

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

• Diagramme d’activité de mise à jour (Modification/suppression)

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

                                                                                                                      

II.7. LE DIGRAMME DES CLASSES

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:

• Les attributs (on parle parfois de propriétés): Il s'agit des données caractérisant l'objet. Ce sont des variables stockant des informations d'état de l'objet,
• Les méthodes (appelées parfois fonctions membres): Les méthodes d'un objet caractérisent son comportement, c'est-à-dire l'ensemble des actions (appelées opérations) que l'objet est à même de réaliser. Ces opérations permettent de faire réagir l'objet aux sollicitations extérieures (ou d'agir sur les autres objets). De plus, les opérations sont étroitement liées aux attributs, car leurs actions peuvent dépendre des valeurs des attributs, ou bien les modifier,
• L'identité: L'objet possède une identité, qui permet de le distinguer des autresobjets, indépendamment de son état.

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°°