UML

UML guide de formation avec exemples

…

UML (Unified Modeling Language)

• Résultat de la fusion de plusieurs modèles de conception objet comme :

 OMT (J. Rimbaugh),

 BOOCH (G. Booch),

 BOOCH (G. Booch),

 OOSE (I. Jacobson), etc.

• Adopté et normalisé par l’OMG (Object Management

Group) en 1997.

• Représentation standardisée d’un système orienté objet.

UML (Unified Modeling Language

)

• UML ≠ Méthode de conception
• UML = notation graphique normalisée de présentation de certains concepts pour modéliser des systèmes objets.
• Peut être utilisée avec tout processus de développement objet.

Les 7 diagrammes UML de structure

 Use cases : description des fonctionnalités du point de vue user

 Classes : structuration des entités manipulées par les utilisateurs (classes, interfaces)

 Packages : hiérarchie des modules du système (UML 2)

 Objets : illustration des structures de classe complexes en montrant des exemples d’instances et leurs relations

 Structure composite : description de la composition d’un objet complexe lors de son exécution (UML 2)

 Composants : architecture des composants physiques du système

 Déploiement : description de l’installation des composants du système sur le matériel et sur le réseau

Les 6 diagrammes UML de comportement

 Etats : représentation du cycle de vie commun aux objets d’une même classe.

 Activités : règles d’enchaînement des activités du système.

 Séquences : description d’échanges de messages entre objets

dans le cadre d’un fonctionnement particulier du système; représentation des scénarios d’utilisation du système.

 Communication (ou collaboration ) : représentation simplifiée du diagramme de séquence.

 Global d’interactions : association entre diagrammes de séquence et d’activités (UML 2).

 De temps : description de contraintes tps-réel délicates (UML 2).

…

Use cases d’UML

• Modélisation de processus métiers en les découpant en cas d’utilisation.
• Représentation des fonctionnalités du système.
• Composé :

 d’acteurs :

 utilisateursdu système à représenter

 rôle joué par une personne ou une chose extérieure qui interagit avec le système

 de cas d’utilisation :

 fonctionnalitésproposées par le système

 « classes » dont les instances sont des scénarios

Cas d’utilisation d’un GAB

Exemple tiré de « Introduction à UML, Y. Laloum, CNAM »

Les acteurs

• Représentent la frontière entre :

 les éléments constitutifs de l’application

 les éléments extérieurs à l’application

• Un acteur est un élément extérieur au système qui interagit avec ce dernier.
• L’identification des acteurs permet d’avoir une vue orientée utilisateur du système.
• Acteurs primaires: utilisateurs du système
• Acteurs secondaires: administrateurs du système
• Un acteur possède un rôle.

Représentation UML des acteurs / système

Exemple d’une application bancaire

Guichetier(enregistre les Opérations courantes) Responsabl e des devises (fournit les infos sur le Directeur (fait le bilan journalier) infos sur le cours des devises)

RQ :On ne représente pas les relations entre les acteurs.

Les use cases (cas d’utilisation)

• Quelles sont les vues que les acteurs identifiés ont du système ?

 Identifier les fonctionnalités du système

• Use case :

 représente une fonctionnalité déclenchée suite à une action initiée par un acteur.

 correspond à une manière spécifique d’utiliser le système.

 suite d’interactions entre un acteur et le système

 décrit un ensemble de scénarios

Acteur et use case

Représentation textuelle d’un use case

• Pour documenter les CA, la description textuelle est indespensable afin de communiquer facilement avec les utilisateurs.
• Rubriques habituelles obligatoires :

 Nom : verbe à l’infinitif décrivant une intercation entre un acteur et le système.

 Résumé : brève description du CA.

 Acteurs : liste des acteurs interagissant avec le CA.

 Description : texte explicatant le CA.

Représentation textuelle d’un use case

• Rubriques habituelles optionnelles :

 Pré-conditions : conditions nécessaires pour déclencher le CA.

 Post-conditions : conditions remplies après l’exécution du CA (état du système après réalisation du CA).

 Exceptions : décrit les éventuelles exceptions levées.

(Un CA décrit le comprtement du système lorsqu’il n’y a pas d’exception.)

Exemples de diagramme de use cases

Exemples de diagramme de use cases

La Relation extends

• Tous les use cases fils
• sont des cas particuliers du use case père
• héritent des caractéritisques du père

La Relation uses

• Permet de décomposer un use case complexe en plusieurs use cases plus simples.

Relations entre use cases : exemple tiré de Y. Laloum

Les use cases (cas d’utilisation)

 L’ensemble des cas d’utilisation d’un système contient:

 les exigences fonctionnelles attendues ou existantes

 les acteurs

 les relations qui unissent acteurs et fonctionnalités.

 Les cas d’utilisation servent de support pour les étapes de modélisation, de développement et validation.

 Référentiel du dialogue entre les informaticiens et les clients.

 Base pour l’élaboration du cahier des charges.

Exemple : distributeur automatique

On considère un distributeur automatique de produits courants (bonbons, boissons, etc.).

Une fois qu’il a choisi les produits qu’il désire acheter, le client doit ensuite payer ses achats, soit en espèces, soit par carte bancaire.

Lors de l’achat d’un produit alimentaire, le client verifier la date limite de consommation du produit.

Exemple : distributeur automatique

Les scénarios

Scénarios

• “Série d’évènements ordonnés dans le temps simulant une éxécution particulière du système”, Lopez, Migueis,

Pichon.

• “Ensemble ordonné de messages échangés par des objets (instance de classe ou d’acteur)”, Roques, Vallée.
• Instance de cas d’utilisation.
• Permettent d’expérimenter les exécutions du système

 très utiles lors des tests.

Scénarios

 Pour chaque cas d ’utilisation, il existe un ou plusieurs scénarios dont la description permet d’expliciter le comportement du système pour une situation donnée.

Exemple (tiré de Y. Laloum)

Représentation d’un scénario

Un scénario peut être représenté par un diagramme de séquence.

Exemple de diagramme de séquence

Le diagramme de séquence se focalise sur les aspects temporels.

Représentation d’un scénario

Un scénario peut être aussi représenté par un diagramme de communication (diagramme de collaboration dans UML 1).

Exemple de diagramme de communication

Le diagramme de communication se focalise sur la représentation spatiale.

Le diagramme de séquence

Diagramme de séquence

• Décrit la dynamique d’une sous-fonction du système.
• La dynamique globale d’un système nécessite plusieurs diagrammes de séquences.
• Modélise les messages échangés entre objets en mettant l’accent sur la chronologie des messages.
• Décrit les interactions entre un groupe d’objets en montrant, de façon séquentielle, les envois de message qui interviennent entre les objets.

Diagramme de séquence : messages

• Pour interagir entre eux, les objets s’envoient des messages.

 Lors de la réception d’un message, un objet devient actif et exécute la méthode appropriée.

 Envoi de message = appel de méthode

• Message : spécification d’une communication unidirectionnelle entre objets qui transporte de l’information avec intention de déclencher une réaction chez le récepteur.

Diagramme de séquence : ligne de vie

• Le diagramme de séquence fait entrer en action les instances des classes intervenant dans la réalisation de la sous-fonction qui lui est liée.
• A chaque instance est associée une ligne de vie qui montre ses actions et réactions, ainsi que les périodes durant lesquelles elle est active.

Diagramme de séquence : ligne de vie

nom objet : Classe nom de l’objet et de sa classe

Le nom de l’objet est optionnel période d’activité de l’objet ligne de vie de l’objet

Un diagramme de séquence contient plusieurs lignes de vie.

Diagramme de séquence : messages

• Les envois de message sont représentés par des flèches horizontales reliant la ligne de vie de l’objet émetteur à celle de l’objet destinataire.

objet_1 : Classe objet_2 : Classe

objet_1 : Classe objet_2 : Classe message

Diagramme de séquence : messages

• La transmission d’informations est possible.

objet_1 : Classe objet_2 : Classe

objet_1 : Classe objet_2 : Classe message (donnee1, donnee2)

Diagramme de séquence : messages

3 catégories de messages :

• Synchrone (appel) : invocation d’une opération; l’émetteur donne la main au récepteur et est bloqué jusqu’au traitement effectif du message.
• Asynchrone (signal) : communication explicite entre 2 objets; l’émetteur n’est pas bloqué et peut poursuivre son exécution. (cas des systèmes multi-thread).
• De retour : retour du résultat d’une fonction

Diagramme de séquence : messages

Auto-envoi de message :

Un objet peut s’envoyer un message.

objet : Classe

Diagramme de séquence : messages

Creation et destruction d’un objet :

• Création d’objet : message spécifique qui donne lieu au début de la ligne de vie du nouvel objet.
• Destruction d’objet : message envoyé à un objet existant et qui donne lieu à la fin de sa ligne de vie.

Représenté par une croix.

Diagramme de séquence : messages

Creation et destruction d’un objet :

objet_1 : Classe

objet_2 : Classe

Exemple : distributeur automatique

1. Lo – Introduction à UML – 02/2008 48

Le diagramme de classes

Diagramme de classes : représentation d’une classe

public class Etudiant {

public String nom;

public String prenom;

private String numero_ins;

public Etudiant(String nom) {

this.nom = nom;

}

1. Lo – Introduction à UML – 02/2008 51

public String getNumIns() { return this. numero_ins; }

public void setNumIns(String numero_ins) {

if (numero_ins==null || numero_ins.length!=11) return;

this.numero_ins = numero_ins;

}

public void afficher(){

System.out.println(“etudiant :”+ nom);

}

}

Diagramme de classes : représentation d’une classe

Nom Classe

attribut1 : type

attribut2 : type = valeur

methode1(args)

methode2():type

Diagramme de classes : visibilité

• (+) public : accessible par toutes les classes.
• (-) private : accessible que par les seules méthodes de sa classe.
• (#) protected : accessible par les classes du même package.

Diagramme de classes : association

• Une association représente une relation structurelle entre classes d’objets.
• On représente une association en traçant une ligne entre les classes associées.

1. Lo – Introduction à UML – 02/2008 54

Diagramme de classes : association

• Association ternaire :

Classe1 Classe2

1. Lo – Introduction à UML – 02/2008 55

Classe3

Diagramme de classes : association

Types de multiplicité des associations

1 : un et un seul

0 .. 1 : zéro ou un

1. Lo – Introduction à UML – 02/2008 56

m .. n : de m à n

* : de zéro à plusieurs

0 .. * : de zéro à plusieurs

1 .. * : de un à plusieurs

N : exactement N

Diagramme de classes : association

• Classe Association :

Classe1 Classe2

ClasseAssociation

Diagramme de classes :

composition/agregation

• Composition :

 Les composants font partie de l’objet composé.

 Chaque composant ne peut être partagé entre plusieurs objets composés.

• Agregation :

 Composition faible.

 Les composants peuvent être partagés par plusieurs composés.

Diagramme de classes :

composition/agregation

Diagramme de classes : héritage

Diagramme de classes : interfaces

Les diagrammes d’objets et de structure composite

• Complètent le diagramme de classe.
• Les diagrammes d’objets servent à illustrer des structures de classes compliquées en montrant des structures de classes compliquées en montrant des exemples d’instance.
• Les diagrammes de structure composite permettent de décrire la composition d’un objet complexe lors de l’exécution.

Diagramme de packages

• Un package est un ensemble de classes et d'autres packages regroupés sous un nom.
• C'est l'adaptation du concept de librairie ou de bibliothèque.
• Servent à structurer l’ensemble des classes et interfaces.
• Permet de structurer un système en plusieurs parties,

chacune représentée par un package .

Diagramme de packages

Diagramme de packages

Le diagramme d’états

Représente le cycle de viecommun aux objets d’1 même classe.

Exple : Situation professionnelle d’une personne

Le diagramme d’états : état

• Moment du cycle de vie d’un objet.
• Dans un état, un objet peut être Actif ou Inactif :
• Inactif : attend un signal provenant d’autres objets
• Inactif : attend un signal provenant d’autres objets
• Actif : réalise une activité (exécution d’une série de méthodes liée à un objectif)
• Le changement d’état est déclenché par un évenement : réception d’un message.

Le diagramme d’états : transition

• Lien orienté entre 2 états qui exprime le fait que l’objet a la possibilité de passer d’un état d’origine à un état de destination.
• Généralement associée à un évènement.

Le diagramme d’états : exemple

Lettre recommandée

Le diagramme d’activités

• Permet de représenter graphiquement le comportement d’une méthode ou le déroulement d’un cas d’utilisation.
• Il est composé :
• d’un noeud initial
• d’activités liées entre elles par des évènements
• se termine par un noeud final

Le diagramme d’activités

• Forme spécifique du diagramme d’états-transitions dans lequel :

 chaque état est associé à une activité

 toutes les transitions sont automatiques (enchaînements)

• Activité : série d’actions.
• Action :

 Affecter une valeur à un attribut,

 Créer ou détruire un objet,

 Effectuer une operation, etc.

Le diagramme d’activités : exemple

• Authentification d’un utilisateur.

Le diagramme de composants

• Décrit les composants et leurs dépendances dans l’environnement de réalisation.
• Vue statique de l’implémentation des systèmes qui montrent les choix de réalisation.
• En général, il n’est utilisé que pour des systèmes complexes.

Diagramme de composants

Modélisation de l’architecture logicielle et sa structuration en composants.

Les diagramme de déploiement

• Montre la disposition physique des différents matériels

– les noeuds – qui entrent dans la composition d’un système et la répartition des instances de composants, processus et objets qui « fonctionnent » sur ces matériels.

• Modélisation de l’architecture matérielle.
• Très utile pour des systèmes distribués.

Le diagramme de déploiement

1. Lo – Introduction à UML – 02/2008 76