UML
(Unified Modeling Language) langage de modélisation objet unifié
Philippe Chochois 2007/2008
UML: historique
Né de la fusion des méthodes objet dominantes (OMT, Booch et OOSE), puis normalisé par l'OMG en 1997, UML est rapidement devenu un standard
incontournable.
UML n'est pas à l'origine des concepts objet, mais il en donne une définition plus formelle et apporte la dimension méthodologique qui faisait défaut à l'approche objet.
3
UML: historique
1997: Version 1.1 d’UML adopté par l’OMG.
1998-1999: Versions 1.2 et 1.3 d’UML.
2001: Sortie des versions suivantes 1.4
2003: Versions 1.5
2002-2003: Préparation de la V2
2004: Sortie de la version V2.1 le 10 octobre 2004
Sortie de la version 2.1.1 le 5/02/07
4
UML: Définition
UML (Unified Modeling Langage) est un langage graphique de modélisation objet qui permet à divers intervenants d'échanger de l'information.
Le langage a été normalisé par l'OMG –Object Management Group).
Il ne s'agit pas d'une méthode, mais d'un outil de communication.
UML offre 9 diagrammes principaux différents (Version1), couvrant divers domaines touchant aux systèmes d‘Information.
Dans sa version 2, 13 diagrammes sont disponibles
5
UML: caractéristiques
Un standard incontournable et incontesté
En évolution permanente mais avec une stabilité grâce à l’OMG (réunit les principaux acteurs du monde objet)
UML n’est pas une méthode mais un langage
UML permet de cadrer l’analyse
UML est un support de communication
Avantages d’UML: langage de communication formel, normalisé et performant
Inconvénients: Nécessite une période d’apprentissage et UML ne se suffit pas à lui-même.
6
UML: les diagrammes
Vue statique du système
Diagramme d’objets Briques de base
Diagramme de classes Vue statique du système
Diagramme de composants Organisation des composants
Diagramme de déploiement Déploiement des composants
Diagramme de paquetage Vue d’ensemble du système
Diagramme de structure composite Vue des liens entre les sous-ensembles
UML: les diagrammes
Vue dynamique du système
Diagramme de cas d’utilisation Les besoins
Diagramme de collaboration (ou communication) Interactions entre objets
Diagramme de séquences Interactions entre objets
Diagrammes d’états-transitions Comportement (Etat des objets en réaction aux événements)
Diagrammes d’activités Cycle de vie
Diagramme global d’interaction Vue générale des interactions (Séquence + activité)
Diagramme de temps Etats et interactions avec le temps comme contrainte primordiale
UML: les diagrammes
Utilisation des diagrammes:
Compte-tenu du nombre important de diagrammes, tous les diagrammes ne sont pas systématiquement utilisés. Il faut choisir les diagrammes les mieux adaptés au cas étudié, au niveau de détail souhaité et aux habitudes des utilisateurs et organisations concernées
Les diagrammes peuvent être enrichis de manière incrémentale. Au fur et à mesure de l’avancement du projet, les diagrammes sont affinés, complétés, voire corrigés.
Les règles d’utilisation sont donc souples.
C’est un langage: Pour exprimer une idée, il y a une infinité de façons de le faire… mais certaines sont évidemment préférables à d’autres !
9
UML: les diagrammes
Premier diagramme: Les cas d’utilisation (Use Case)
10
UML: Cas d’utilisation (use-case)
Deux formes : Une forme graphique (très typique), et une forme textuelle.
La finalité du use-case est de détecter et de décrire les besoins fonctionnels -> Comment un système est utilisé par un utilisateur pour atteindre ses objectifs.
Il y a toujours un (ou plusieurs) acteur(s), et le use-case montre les scénarii entre ce(s) acteur(s) et le système décrit. Certains scénarii sont des succès, et d'autres des échecs...
Les use-cases peuvent être abrégés, ou plus détaillés...
Le cas d’utilisation est un diagramme qui convient parfaitement au dialogue avec les utilisateurs car son formalisme est simple et proche du langage naturel.
11
UML: Cas d’utilisation
Mettre en évidence les fonctionnalités du système existant ou à mettre en œuvre
Point de vue des utilisateurs.
Fil à plomb.
Acteurs externes du système
Interactions entre le système et les acteurs externes
Un même acteur peut jouer plusieurs rôles
Enregistrer un mandat
Délivrer une lettre recommandée
12
UML: Exemple de cas d’utilisation
Le ou les acteurs principaux sont habituellement à
gauche, les acteurs auxiliaires à droite. Le cas
d'utilisation est indiqué dans un ovale.
Exemple de description textuelle
Saisie d’une commande dans une grande surface
Acteur principal : le vendeur
Pré-condition : le vendeur peut se loguer au système
Déclencheur : un client commande un appareil
Niveau : utilisateur
Scénario nominal :
1. Le vendeur demande un formulaire de commande
2. Le système retourne le formulaire de commande
3. Le vendeur sélectionne le produit commandé
4. Le système indique l’état de stock et le date de disponibilité
5. Le vendeur saisit les informations du client
6. Le système demande la confirmation de la commande
7. Le vendeur confirme la command
8. Le système enregistre et imprime la commande
Extensions :
4.1 Le système indique en plus un état de stock d’alerte du fournisseur
4.1.1 Le vendeur alerte la gestion de stock
4.2 Le client annule sa commande. Fin
Cas d’utilisation: cas « include »
Cas « GAB » (Guichet Automatique Bancaire)
Cas d’utilisation: Retrait d’argent
Acteur: Client
Scénario nominal:
1. Le client saisit son code 2. Le système contrôle le code 3. Le client saisit son montant 4. …
Cas d’utilisation: Visualisation du compte
Acteur: Client
Scénario nominal:
1. Le client saisit son code 2. Le système contrôle le code 3. Le client saisit la période de visualisation 4. …
Des interactions sont factorisables
15
Cas d’utilisation: cas « include »
Les cas « include » sont exécutés systématiquement !
On ne peut pas retirer de l’argent ou visualiser un compte si le login n’est pas contrôlé !
Retrait
Visualisation
Contrôle login
« include »
« include »
16
Cas d’utilisation: cas « extends »
Cas « Saisie d’un sinistre immobilier »
Scénario nominal:
1 L’assureur saisit les références de l’assuré
2 Le système retourne le dossier de l’assuré
3 L’assuré saisit les éléments du sinistre
4 Le système retourne le montant évalué
5 L’assureur transmet le dossier au gestionnaire
Extensions:
4.1 Le montant dépasse le plafond sans expertise
4.1.1 L’assureur contacte l’expert.
4.1.2 …
17
Cas d’utilisation: cas « extends »
Cas « Saisie d’un sinistre immobilier »
L’ampleur des extensions autorise à faire apparaître un cas spécifique
« étendant » le cas d’origine
Les cas « Extends » répondent à des cas particuliers.
La demande d’expertise n’a pas lieu pour tous les sinistres ! Saisie d’un sinistre
Demande d’expertise
« extends »
Point d’extension: Montant dépassant le plafond
18
Cas d’utilisation: Exercice
Cas « Bonveto »:
Un vétérinaire veut créer une application informatique qui lui permettrait de gérer l’activité de son cabinet.Il reçoit en consultation des animaux pour lesquels il établit, lors de la première visite, une fiche individuelle de renseignements. Chaque consultation est enregistrée sur un journal chronologique des consultations et mentionnée sur la fiche de l’animal. Les hospitalisations sont consignées dans un classeur particulier. Lorsque quelqu’un amène un animal trouvé, le vétérinaire doit parfois rechercher le maître de l’animal en consultant le fichier National des animaux domestiques (en saisissant le numéro de tatouage de l’animal ou en lisant sa puce d’identification). Si cette première recherche est infructueuse, il peut aussi s’adresser au fichier international d’identification.
a) Recherchez les acteurs du cas « Bonveto »
b) Etablissez la liste des fonctionnalités auxquelles devrait répondre une application qui gérerait cette activité
c) Représentez le diagramme des cas d’utilisation de « bonveto » d) Ecrivez le cas d’utilisation « Identifier un animal » sous forme textuelle. On précise que la procédure d’identification au fichier national ne doit pas excéder 30 secondes pour être acceptable.
Cas d’utilisation: Exercice corrigé
V étéri na i re
<< a cteu r> >
A cte ur O NI A p pl i cati o
n "V E T O "
E nreg i strer u n an i m a l
E nreg i strer u ne co nsu l ta ti on
E n re gi stre r u n e ho spi ta l i sa ti o n
Ide nti fi er un a n i m al
A cte ur e xterne
< < acte u r>>
A cte ur O II
Cas d’utilisation: exercice corrigé
Cas d’utilisation : « Identifier un animal » Acteur : Le vétérinaire
Evénement déclencheur : demande de recherche de l’identité d’un animal (perdu par exemple) But : Retrouver le propriétaire de l’animal
Niveau : Utilisateur Portée/Priorité : Moyenne
Pré-conditions : L’animal est tatoué ou porte une puce d’identification et l’adresse du propriétaire n’a pas changé
Scénario nominal :
1. Le vétérinaire relève le numéro d’identification de l’animal avec le lecteur de puce ou lit le tatouage
2. Le vétérinaire saisit le numéro
3. L’application demande une recherche sur ce numéro auprès du fichier national d’identification 4. L’animal est reconnu
5. Le fichier national renvoie les coordonnées du propriétaire de l’animal Extensions
Alternatives :
1.1 Le fichier national ne connaît pas ce numéro
1.2 Le système indique au vétérinaire de faire une recherche sur le fichier international Exceptions :
1.1 Le numéro est illisible 1.2 Le cas s’arrête 5.1 L’animal n’est pas reconnu 5.2 Le cas s’arrête
Contraintes non fonctionnelles : La recherche du point 3 ne doit pas excéder 30 secondes
21
Cas d’utilisation: Généralisation
Cas « GAB »:
Nouvelle règle à prendre en compte: Seuls, les clients de la banque propriétaire du GAB peuvent visualiser leur compte mais tous peuvent retirer de l’argent.
Il faut donc différencier les acteurs.
22
Cas d’utilisation: Généralisation
Cas « GAB »:
Nous avons représenté les 2 types d’utilisateurs.
Le client de la banque est un porteur de carte. A ce titre, il bénéficie de toutes les possibilités offertes au porteur de carte (Dans notre exemple, il n’y en a qu’une mais il pourrait y en avoir plusieurs).
Nous allons dire que l’utilisateur « Client Banque » est un porteur de carte spécial. C’est la notion de spécialisation.
Par opposition, on peut dire que le porteur de carte est un cas général qui regroupe les clients et les non clients. C’est la notion de généralisation.
23
Cas d’utilisation: Généralisation
Cas « GAB »:
Nous allons dire que l’utilisateur « Client Banque » est un porteur de carte spécial.
C’est la notion de spécialisation.
Par opposition, on peut dire que le porteur de carte est un cas général qui regroupe les clients et les non clients. C’est la notion de généralisation.
On dit que « Client Banque » hérite de « Porteur de Carte ».
Un utilisateur qui hérite d’un autre hérite automatiquement de ses droits. On peut donc supprimer la représentation « Client Banque effectue un retrait ».
24
Cas d’utilisation: Généralisation
Cas « GAB »:
On peut utiliser la notion d’héritage pour les cas d’utilisation eux-mêmes.
Nous pouvons spécialiser le cas « Visualisation » en 2 sous cas: 1 pour les comptes courants et l’autre pour les comptes épargnes.
Si la cas d’utilisation général ne peut pas se produire sans le cas d’utilisation spécialisé, on dit que ce cas est abstrait. On fait figurer le terme « abstract » au niveau du cas d’utilisation.
Cas d’utilisation: Exercice
Cas « Réservation »:
Dans un établissement scolaire, on désire gérer la réservation des salles de cours ainsi que du matériel pédagogique (ordinateur portable ou/et Vidéo projecteur).
Seuls les enseignants sont habilités à effectuer des réservations (sous réserve de disponibilité de la salle ou du matériel).
Le planning des salles peut quant à lui être consulté par tout le monde (enseignants et étudiants).
Par contre, le récapitulatif horaire par enseignant (calculé à partir du planning des salles) ne peut être consulté que par les enseignants.
Enfin, il existe pour chaque formation un enseignant responsable qui seul peut éditer le récapitulatif horaire pour l’ensemble de la formation.
Modéliser cette situation par un diagramme de cas d’utilisation
Cas d’utilisation: Exercice
Cas « Hippodrome »:
Un hippodrome offre à ses clients la possibilité de suivre les courses et/ou de parier.
Pour suivre les courses, il faut payer son billet d’entrée.
Pour parier, il faut miser. En cas de pari gagnant, on peut toucher un prix.
On peut différencier les différentes épreuves (galop, trot, obstacle…).
Modéliser cette situation par un diagramme de cas d’utilisation
