Cours UML les diagrammes d’objets
Cours UML les diagrammes d’objets
...
Pourquoi UML pour la modélisation Objet?
UML opte pour l'élaboration des modèles, plutôt que pour une approche qui impose une barrière stricte entre analyse et conception. Les modèles d'analyse et de conception ne diffèrent que par leur niveau de détail, il n'y a pas de différence dans les concepts utilisés. UML n'introduit pas d'éléments de modélisation propres à une activité (analyse, conception...) ; le langage reste le même à tous les niveaux d'abstraction.
Cette approche simplificatrice facilite le passage entre les niveaux d'abstraction. L'élaboration encourage une approche non linéaire, les "retours en arrière" entre niveaux d'abstraction différents sont facilités et la traçabilité entre modèles de niveaux différents est assurée par l'unicité du langage.
n UML favorise donc le prototypage, et c'est là une de ses forces. En effet, modéliser une application n'est pas une activité linéaire. Il s'agit d'une tâche très complexe, qui nécessite une approche itérative, car il est plus efficace de construire et valider par étapes, ce qui est difficile à cerner et maîtriser.
n UML permet donc non seulement de représenter et de manipuler les concepts objet, il sous-entend une démarche d'analyse qui permet de concevoir une solution objet de manière itérative, grâce aux diagrammes, qui supportent l'abstraction.
Pour exprimer les diverses perspectives de l’architecture d’un système, les auteurs d’UML proposent 4+1 vues, selon le schéma suivant :
Cette approche propose que plusieurs perspectives concourent à l’expression de l’architecture d’un système et explique qu’il est nécessaire de garantir la séparation et l’indépendance des différentes perspectives; l’évolution de l’une des perspectives ne doit pas avoir impact (sinon limitée) sur les autres.
- La vue logique : cette vue exprime la perspective abstraite de la solution en termes de classes, d’objets, de relations, de machine à états de transition etc.. de manière indépendante des langages de programmation et des environnements de développement utilisés pour les mettre en œuvre. Il s’agit d’exprimer le problème de façon abstraite. Les concepts utilisés incluent les concepts de la majorité des méthodes orientés objets existantes. Cette vue concerne l’intégrité de conception
- La vue des composants : cette vue exprime la perspective physique de l’organisation du code en terme de modules, des composants et surtout des concepts du langage et de l’environnement d’implémentation. Cette perspective dépend du choix du langage utilisé. Dans cette perspective, le concepteur est surtout intéressé par des aspects de gestion de codes, d’ordre de compilation, de réutilisation.
UML offre des concepts adaptés comme les modules, l’interface, les composants, les relations de dépendance ect... Malheureusement la plus part des concepteurs ignorent cette vue. Cette vue concerne l’intégrité de gestion
- La vue des processus : cette vue exprime la perspective sur les activités concurrentes et parallèles (tâches et processus) du système. On y trouve les activités parallèles, et leur communication et synchronisation. Cette vue concerne l’intégrité d’exécution.
- La vue de déploiement : elle exprime la répartition du système à travers un réseau de calculateurs et de nœuds logiques de traitement. Cette vue est utile pour décrire la répartition du système réparti, elle concerne l’intégrité de performance
- La vue des cas d’utilisation : cette vue guide et justifie les autres en ce sens que la modélisation fondée sur les scénarios (cas d’utilisation) constitue ce que l’on fait de mieux aujourd’hui. Cette approche constitue l’unique moyen de guider la modélisation, de trouver le bon modèle,
UML propose 13 diagrammes pour modéliser un système. Selon la vue que l’on veut décrire, statique ou dynamique, ces diagrammes sont :
Représentation statique du système :
Le diagramme de cas d’utilisation
Le diagramme Objets
Le diagramme de classes
Le diagramme des composants
Le diagramme de déploiement
Diagramme de packages
Diagramme de structure composite
Représentation dynamique du système
Le diagramme de collaboration
Le diagramme de séquences
Le diagramme d’état de transition
Le diagramme d’activités
Diagramme de communication
Le diagramme de cas d’utilisation : (Use case)
Définitions
Les cas d’utilisation décrivent le comportement du système du point de vue de l’utilisateur. Ils permettent de définir les limites du système et les relations entre le système et son environnement. Un cas d’utilisation est une manière spécifique d’utiliser le système. C’est l’image d’une fonctionnalité en réponse à la stimulation d’un acteur externe
Objectifs des cas d'utilisation
Permettent de structurer les besoins des utilisateurs et les objectifs correspondants d'un système.
Ils centrent l'expression des exigences du système sur ses utilisateurs Ils se limitent aux préoccupations "réelles" des utilisateurs ; ils ne présentent pas de solutions d'implémentation et ne forment pas un inventaire fonctionnel du système.
Ils identifient les utilisateurs du système et leur interaction avec celui-ci
Un cas d’utilisation est un ensemble de séquences d’actions qui sont réalisées par le système et qui produisent un résultat observable pour un acteur particulier du système. Il permet de décrire ce que le futur système devra faire sans spécifier comment il le fera.
Acteur : entité externe qui agit sur le système. Un acteur peut consulter et /ou modifier l’état du système en émettant et/ou en recevant des messages susceptibles d’être porteurs de données.
En réponse à l'action d'un acteur, le système fournit un service qui correspond à son besoin. Un acteur peut être une personne (utilisateur humain) ou les autres systèmes connexes qui interagissent directement avec le système.
Représentation
Les noms des cas d’utilisation doit être un verbe à l’infinitif suivi d’un complément du point de vue de l’utilisateur
Comment identifier les acteurs?
- Les utilisateurs humains (opérateur, administrateur, l’utilisateur, le formateur ...)
- Les autres systèmes connexes qui interagissent directement avec le système.
Comment identifier les cas d’utilisation?
- Chaque cas d’utilisation doit décrire les exigences fonctionnelles du système.
- Chaque cas d’utilisation correspond à une fonction métier du système (besoins des utilisateurs et possibilités du système).
- Il convient donc de rechercher pour chaque acteur
o Les différentes intentions métier avec lesquelles il utilise le système
o Déterminer les services fonctionnels attendus du système. Exemple
Description textuelle des cas d’utilisation
Les cas d’utilisation ont besoin d’être décrits soit textuellement, soit en utilisant un autre diagramme. Deux parties sont importantes lors de la description d’un cas d’utilisation.
1) Le sommaire d’identification
- Le titre
- Résumé
- Acteurs
- Date de création
- Version
- Date de mise à jour
- Responsable
2) Le scénario nominal.
- Préconditions
- Scenario nominal (enchaînement des opérations dans le cas où le cas d’utilisation se déroule normalement.)
- Scénario alternatif
- Enchaînement des erreurs
- postconditions
Exemple. Caisse enregistreuse
Le déroulement normal des opérations d’une caisse enregistreuse (point de vente) est le suivant :
Un client arrive à la caisse avec des articles à payer
n Le caissier enregistre le n° d'identification de chaque article, ainsi que la quantité si elle est supérieure à 1
n La caisse affiche le prix de chaque article et son libellé.
n Lorsque tous les achats sont enregistrés, le caissier signale la fin de la vente.
n La caisse affiche le total des achats.
n Le client choisit son mode de paiement.
- Liquide: le caissier encaisse l'argent reçu, la caisse indique la monnaie à rendre au client.
- Carte de débit
- Carte de crédit: un terminal bancaire fait partie de la caisse. Il transmet une demande d'autorisation en fonction du type de la carte.
n La caisse enregistre la vente et imprime un ticket.
n Le caissier donne le ticket de caisse au client.
Lorsque le paiement est terminé, la caisse transmet les informations sur le nombre d'articles vendus au système de gestion des stocks.
Tous les matins, le responsable du magasin initialise les caisses pour la journée.
Voici le diagramme des cas d’utilisation (non complété) de la caisse enregistreuse.
Description des cas d'utilisation
Titre: Traiter le passage à la caisse
Brève description: Un client arrive à la caisse avec des articles qu'il souhaite acheter. Acteurs: Caissier (principal), Le client (secondaire)
Préconditions:
- Le terminal de point de vente est ouvert
- Un caissier y est connecté
- La base de données des produits est disponible
Postcondition.
La vente est enregistrée dans le terminal de vente.
...
Scénarios alternatif
A1:Numéro d'identification du produit inconnu.
L'enchaînement de A1 démarre au point 3 du scénario nominal le terminal de vente indique que le numéro du produit est inconnu. L'article ne peut être prix en vente. Le scénario reprend au point 2 s'il y a d’autres produit ou au point 4 s’il n’yen a pas
A2: le client demande l'annulation de l'article (article trop cher) L'enchaînement de A2 démarre au point 2du scénario nominal
2- le caissier demande l'annulation de l'article
3- le terminal de vente supprime l'article de la vente. Le scénario nominal reprend au point 2, s'il y a d'autres articles ou au point 4 sinon.
Relation entre les cas d’utilisation
Relation d'inclusion:«include» ou «utilise» ou «use»
Un cas d'utilisation de base (Emprunter un livre) incorpore explicitement un autre cas d'utilisation (s'identifier) de façon obligatoire à un endroit précis de son enchaînement. Le but est d'éviter de décrire plusieurs fois le même cas d'utilisation
Exemple:
Un client du GAB
Relation d'extension: B est la suite logique de A
Un cas d'utilisation A (consulter la liste des abonnés) peut étendre son action, pas obligatoire, sur un autre cas d'utilisation B (imprimer la liste des abonnés). Les deux cas peuvent s'exécuter de manière indépendante.
Exemple:
Les cas d’utilisation Retirer argent et Consulter son solde sont deux cas indépenadants, en ce sens qu’un client du GAB peut consulter son solde sans retirer de largent ou qu’il peut retirer de l’argent sans effectuer d’interrogation de solde.
Cependant le cas Consulter son solde peut etendre son action au cas Retirer de l’argent. Un client après avoir consulter son solde peut décider de retirer de l’argent.
Quelque soit le cas d’utilisation à exécuter (Retirer argent ou Consulter son solde), ils doivent faire appel (utilise) au d’utilisation Identifier le client (carte débit et nip). On ne peut retirer de l’argent si nous n’avons pas de carte bancaire valide et un nip valide
La relation de généralisation. Un cas A est une généralisation d’un cas B si B est un cas particulier de B
Cette relation de généralisation/spécialisation est présente dans la plupart des diagrammes UML et se traduit par le concept d’héritage dans les langages orientés objet.
Exemple :
Modélisation statique
Introduction :
Le diagramme de classes est sans doute le diagramme le plus important à représenter pour les méthodes d’analyse orientées objet. C’est le point central de tout développement orienté objet.
On peut voir le diagramme de classes à différents niveau de développement. En analyse il permet de décrire la structure des entités manipulées par les utilisateurs. En conception, il permet de représenter un code orienté objet.
Définition :Le diagramme de classes
Un diagramme de classes est une collection d'éléments de modélisation statique qui montre la structure d'un modèle. Une classe représente la description d’un ensemble d’objets possédant les mêmes caratéristiques.
Un diagramme de classes fait abstraction des aspects dynamiques et temporels du système
Représentation d’une classe
Une classe est représentée par un rectangle séparé en trois parties:
Nom de la classe
Étudiant
Attributs Méthodes
NumEtudiant:int Nom :string Prénom:string
Inscrire() Consulter ()
Un attribut ou une méthode peut être de type :
Protégé, il est précédé du symbole #, visible aux sous classes de la classe Privé, il est précédé du symbole –, visible à la classe seule
Public, il est précédé du symbole +, visible à tous les clients de la classe
Liens entre classes ou association entre classes.
L’association est la relation la plus évidente qui existe entre classes, elle exprime une connexion sémantique bidirectionnelle entre deux classes.
Une association est une relation entre deux classes qui décrit les connexions structurelles entre leurs instances. Une association indique donc qu’il peut y avoir des liens entre des instances des classes associées.
Exemple1, association simple :
Comment représenter une personne qui travaille dans une seule compagnie? Ou encore dans une compagnie, nous avons plusieurs employés?
Compagnie
Personne
Idpersonne:string Nom:string Prénom:string Employé
1..*- 1 Nom:String
NbreEmployes():int Chiifre_Affaire():folat
Saisir Info()
CalculerSalaire():float
Figure 1: Diagramme de classes (représentation 1)
Dans ce diagramme, le nom de l’association est Employé, le nom du rôle de la classe Personne pour l’association est: Employé.
Le diagramme se lit comme suit :
Une personne travaille pour une seule entreprise. Dans une entreprise il y 'a une à plusieurs personnes:
Personnel
Idpersonne:string Nom:string Prénom:string Employeur:Compagnie
Saisir Info()
CalculerSalaire():float Compagnie
Nom:String
Employe:Personnel [*]
NbreEmployes():int
Chiffre_Affaire():folat
Figure 2: Diagramme de classes: Représentation2
Remarque:
Entre la représentation de la figure 1 et la représentation de la figure 2, pour la représentation des associations entre les classes UML opte pour la représentation de la figure1
Notion de cardinalité ou multiplicité
Une cardinalité est le nombre de fois minimum et maximum qu’une instance d’une classe participe à l’association. Ou encore c’est le nombre d’instances de l’association pour une instance de la classe. On l’appelle également la multiplicité
Nous distinguons :
1 un et un seul
0..1 Zéro ou un
m..n De m à n (entier)
* Plusieurs
0..* De zéro à plusieurs
1..* d'un à plusieurs
Question 1 : Comment représenter qu’une pièce a une seule forme? Réponse :
Notion de rôle : un rôle spécifie la fonction d'une classe pour une association donnée
Relation navigable:
On représente graphiquement la navigabilité par une flèche du côté de la terminaison navigable et on empêche la navigabilité par une croix du côté de la terminaison non navigable
Par exemple, sur la figure la terminaison du côté de la classe Tableau n’est pas navigable : cela signifie que les instances de la classe Colonnes ne stockent pas de liste d’objets du type Tableau. Inversement, la terminaison du côté de la classe Colonnes est navigable : chaque objet Tableau contient 7 colonnes.
Par défaut, une association est navigable des deux côtés.
Agrégation :
Est un type d’association, elle est symbolisé par
Elle définit la relation «partie de ».
Exemple2 : un document fait partie d’une bibliothèque
Une composition est une agrégation forte, elle est représentée par le symbole Exemple3 :un tableau est composé de colonnes
La composition, également appelée agrégation composite, décrit une contenance structurelle entre instances. Ainsi, la destruction de l’objet composite implique la destruction de ses composants
Dans les relations de composition ou agrégation, nous parlons d’objet composite et d’objet composant. Ainsi une instance de la classe Tableau est dit objet composite et une instance de la classe colonne est dit objet composant
Différences entre une agrégation et une composition : Pour la relation de composition :
- La destruction de l’objet composite implique la destruction de ses composants.
- La multiplicité du côté composite ne doit pas être supérieure à 1 (i.e. 1 ou 0..1).
- La composition est une agrégation non partagée.
Question 2 : comment représenter «un livre est composé de chapitres»?
- Réponse
Généralisation, super-classe, sous-classe
La généralisation : définit une relation de classification entre une classe plus générale (super¬classe0 et une classe plus spécifique(sous-classe). Il s’agit de prendre des classes existantes (déjà) mise en évidence et de créer de nouvelles classes qui regroupent leurs parties communes, il faut aller du plus spécifiques au plus général, c’est une démarche ascendante. La spécialisation : il s’agit de sélectionner des classes existantes (déjà) identifiées et d’en dériver de nouvelles classes plus spécialisées en spécifiant simplement les différences. Il s’agit d’une démarche descendante
Une classe abstraite est une classe qui ne s’instancie pas directement, mais qui représente une simple abstraction afin de factoriser les propriétés communes des sous-classes. Elle se note en italique.
Exemple4 : Comment représenter qu’un moyen de transport peut être un avion, un train ou une voiture?
Moyen de transport
+Modèle : string +Marque : string +NbrePlace : string +VitesseMax : string
Voiture Train Avion
-Immatriculation : string -NBreVoiture : int -Altitude : int
La classe Moyen de transport est une classe abstraite. Voici quelques propriétés de la relation d’héritage :
- La sou- classe possède toutes les caractéristiques des ses super-classes , mais elle ne peut accéder aux caractéristiques privées de cette dernière.
- Toutes les associations de la super-classe s’appliquent aux sous-classes dérivées.
- Une instance d’une classe peut être utilisée partout où une instance de sa super-classe est attendue. Par exemple, toute opération acceptant un objet d’une classe Moyen de transport doit accepter un objet de la classe avion.
- Une classe peut avoir plusieurs parents, on parle alors d’héritage multiple
En UML, la relation d’héritage n’est pas propre aux classes. Elle s’applique à d’autres éléments du langage comme, les acteurs ou les cas d’utilisation
Question3 : Comment représenter la situation suivante :
- Des documents sont soit des journaux soit des volumes ou des BD (bandes dessinées)
- Les volumes sont soit des dictionnaires soit des livres
- Les documents ont un titre et un numéro.
- Les volumes ont en plus un auteur, les BD ont en plus le nom du dessinateur, les journaux ont une périodicité.
Réponse
Classe d’association
Il s'agit d'une classe qui réalise la navigation entre les instances d'autres classes. Elle sert connecter les classes entre elles
Exemple 5
Parfois, une association doit posséder des propriétés. Par exemple, l’association Inscription entre un élève et un cours possède comme propriété la date d’inscription. Cette propriété n’appartient ni aux cours, ni aux étudiants Il s’agit donc bien de propriétés de l’association Inscription
Les associations ne pouvant posséder de propriété, il faut introduire un nouveau concept pour modéliser cette situation : celui de classe-association.
Une classe-association possède les caractéristiques des associations et des classes : elle se connecte à deux ou plusieurs classes et possède également des attributs et des opérations.
Une classe-association est caractérisée par un trait discontinu entre la classe et l’association qu’elle représente
Question4
Reprendre l’énoncé de la question précédente et représenter la situation suivante :
- Seuls les livres sont empruntables.
- Un adhérent peut emprunter plusieurs livres. On gardera la date de prêt et la date prévue pour le retour.
Réponse
Notion de package
Le package est un mécanisme regroupant plusieurs éléments d’UML (peut regrouper des classes, des cas d’utilisation, des interfaces....).
Le diagramme de package sert à :
- Avoir une vision globale des différents sous systèmes du système à l’étude.
- Représenter l’architecture globale du système
- Aider à organiser du code (java ou C#) .
- modulariser les diagrammes (UML) les plus complexes.
Le découpage d’un modèle (de classes ou de cas d’utilisation) est une activité délicate. Il faudra regrouper les classes d’un point de vue sémantique c'est-à-dire :
- Les classes d’un même package doivent rendre des services de même nature aux utilisateurs.
- Minimiser les dépendances entre les packages.
- Les dépendances entre packages doivent refléter des relations internes au système.
- Il ne doit pas y avoir de dépendance cyclique entre des packages
Exemple 6:
Gestion des Joueurs
Chaque package doit être décrit par son diagramme de classes.
Question5
Reprendre l’énoncé des questions3 et 4, puis donner le des packages Réponse
Modélisation dynamique : le diagramme de séquence
Définition et exemple
Un diagramme de séquence montre les interactions entre les objets, arrangés en séquence dans le temps. En particulier ils montrent les objets participants dans l’interaction par leur ligne de vie et les messages qu’ils s échangent ordonnancés dans le temps. Il ne montre pas les associations entre les objets.
L’ordre d’envoi des messages est déterminé par sa position sur l’axe vertical (l’axe du temps) du diagramme. Le temps s’écoule de haut en bas.
Les diagrammes de séquences permettent entre autre de faire une description graphique d’un cas d’utilisation
Exemple :
Sur un diagramme de séquence, il est possible de représenter de manière explicite les différentes périodes d'activité d'un objet au moyen d'une bande rectangulaire superposée à la ligne de vie de l'objet. Un objet peut être activé plusieurs fois au cours de son existence. Un objet non actif n’est pas un objet détruit.