Cours UML

Wajdi BOUAJILA

Institut Supérieur des Etudes Technologiques de DjerbaDépartement technologies de l’Informatique

Plan Qu’est que UML?

Diagramme de cas d’utilisation

Diagramme de classes

Diagramme de séquences

Diagramme de communication

Diagramme d’état-transition

Diagramme d’activité

Diagramme de paquetage

Diagramme de déploiement

Diagramme de composant

Correction du projet Sivex

Proposition d’une correction de concours (2009)

La modélisation : Pourquoi

Pourquoi réaliser des modèles?

A quoi cela peut-il vraiment servir à part me faire perdre du temps alors qu’il serait plus rapide de passer directement au codage?

Vous avez peut être aussi travaillé à partir de modèles réalisés par les autres et vous n’avez pas vraiment saisie l’intérêt?

Voire vous vous êtes dit « mes ces modèles sont faux, je ne fais pas comme cela dans mon code »?

Un modèle est avant tout une représentation abstraite du monde réel.

=> Un modèle va donc nous servir à communiquer et échanger des points de vue afin d’avoir une compréhension commune et précise d’un même problème.

Un modèle ?

Pour un problème complexe, il est conceptuellement impossible de l’appréhender d’un seul bloc=> dégrossir le problème

Ce mode de résonnement est à la base même des niveaux d’abstraction que l’on retrouve dans les méthodes :

Merise (niveau conceptuel, niveau logique, niveau physique)

RUP1 (niveau fonctionnel, niveau analyse, niveau conception).

=>enrichir un modèle de niveau N par l’analyse de niveau N+1.

C’est un outil pour documenter

Les niveaux d’abstraction

Historique d'UML

Booch-93 Rumbaugh( OMT2)

Oct-950.8

Jacobson (use case - sdl)

Juillet-960.9

Janv-971.0

Nov-971.0

Sept-971.1 (OMG)

20001.4

20052.0

20062.1

UML 1.x

UML 2.0

UML 2.3

C’est quoi UML?

Objectifs : spécifier, construire, visualiser et documenter les systèmes à base de logiciel

Pour communiquer, travailler à plusieurs

Pour Comprendre la «big picture»

Par approche orientée objets

Avec différents modèles pour différentes vues

UML : Langage et non simple notation graphique (ni méthode)

UML est Indépendant des méthodologies

UML Support des systèmes concurrents et répartis, à base de composants

UML: un méta-langage de modélisation pour unifier les modèles utilisés dans les méthodes

Diagramme de Use case

La notation UML

D. Cas d’utilisation : les acteurs

Un acteur est un rôle d’un ou plusieurs objetssitués à l’extérieur du système et qui interagissentavec lui pour remplir une fonctionnalité donnée de ce système.Un acteur caractérise le rôle joué par un objet àl’extérieur du système.

Uti lisateur

• Un acteur parle au système (Acteur principal)• Le système parle à un acteur (Acteur secondaire)• Un acteur est :

• Un humain (via une IHM)• Du soft• Du hard

<<actor>>

Autre Système

Use Case :Use Case

Un Cas d’utilisation ( use case ) est une fonctionnalité remplie par le système et qui semanifeste par un ensemble de messages échangésentre le système et un ou plusieurs acteurs.

UtilisateurVerifierBonneMarche

CapteurTemperat

ure

Exemple

Consulter solde

compte

Client

Technicien

Distributeur de billets

Retirer de l ’agent

Mettre en marche / arrêter

Ravitailler le coffre

visualise

débite

Cas d ’utilisation objectif du système motivé par un

besoin

Acteurpersonne ou système externe à l ’origine d ’une interaction avec le systèmes

Paquetage

regroupe des éléments de modélisation

Nature de l ’interaction

Le technicien éteint le distributeur avant de ravitailler le coffre

On ne peut retirer de l ’argent que dans la limite du stock

<<actor>>

SI Banque

Acteur secondaire

Liens entre cas d ’utilisation

Trois types de liens entre cas d’utilisation : Extension (<<extends>>) : comportement optionnel du

système (variation d’un comportement « normal ») Inclusion (<<includes>>) : un cas intègre le

comportement d’un autre (raffinement ou factorisation) Utilisation (<< uses>>) : spécialisation avec héritage

(ajout ou remplacement de comportement)

Extends ou uses utilisent l’idée de factorisation, mais : Dans l’extension, un acteur réalise le cas de base et ses

extensions Dans l’utilisation, il n’y a pas en général d’acteur associé

au cas commun

Stéréotypes

Cas d ’utilisation et scénarios

Un scénario est une série d ’événements ordonnés

dans le temps, simulant une exécution particulière du

système

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.

Appelant Appelé

téléphoner

communication directe

ligne occupée

sans réponse

communication par répondeur

ligne en dérangement

etc...

Transition vers les objets

La réalisation d ’un cas d ’utilisation nécessite la

collaboration de plusieurs objets

•Chaque objet de la collaboration participe à la réalisation des scénarios.

• Chaque scénario peut être décrit par rapport aux interactions entre les objets de la collaboration à travers

• un diagramme de collaboration

• ou

• un diagramme de séquence

exempleUne société de vente par correspondance vous demande de développer sonsystème informatique. Ce système doit pouvoir prendre en compte descommandes passées par la poste et des commandes passées par internet. Ildoit suivre les expéditions qui ne sont effectuées que si le paiement est OK.Les paiements se font par carte bancaire dans le cas d'internet et par chèquedans le cas de la poste. Les paiements sont validés par un système bancaireappartenant à la société et existant. Il faut récupérer ce système. Lenouveau système est chargé aussi de la gestion de stocks, lorsqu'un articleatteint un seuil minimal, alors il faut passer une nouvelle commande aufournisseur adéquat. A la réception de la commande, la mise à jour de labase est faite par un employé. Dans le cas d'un paiement accepté et de stockdisponible, l'expédition est faite par un robot existant au quel il suffit depasser les coordonnées du client, et la liste des produits achetés. En casd'indisponibilité, une lettre doit être envoyé au client.

Ce qui nous demande généralement

Un tableau dont les noms des colonnes sont:

Scénarios pour chaque cas d’utilisation

Nom d’ acteur Description Rôle

correction

Robot

ClientPoste

ClientInternet

Verifier StockFournisseur

Passer Commande Internet

include

Passer Commande Posteinclude

SystemBancaireVerifier Paiement

Include

Include

Expedier Commande

Extend

Diagramme de séquences

La notation UML

Diagramme de séquences

Un diagramme de classe permet de décrire les intéractions entre différentes entités et/ou acteurs : par exemple des objets dans un modèle d'un logiciel, des sous-systèmes dans un modèle d'un système complet.- Le temps est représenté comme s'écoulant du haut vers le bas le long des "lignes de vie" (lifeline) des entités.- Des flèches représentent les messages qui transitent d'une entité vers l'autre. Le nom des message apparaît sur chaque flèche. Si l'extrémité de la flèche est pleine, le message est synchrone. Si l'extrémité de la flèche est creuse, le message est asynchone.

Événements et messages

Message Asynchrone :

Message Synchrone :

Les fragments combinés

Un fragment combiné représente des articulations d'intéractions.

Il existe 10 opérateurs définis dans la notation UML2.0

permettent de décrire des diagrammes de séquence de manière compacte

Opérateur "Alternative“ -- AltL'opérateur "alt" désigne un choix, une alternative. Il représente deux comportements possibles : c'est en quelque sorte l'équivalent du SI...ALORS...SINON

Opérateur"Option“ -- Opt

L'opérateur "opt"désigne un fragment combiné optionnel comme son nom l'indique : c'est à dire qu'il représente un comportement qui peut se produire... ou pas. Un fragment optionnel est équivalent à un fragment "alt" qui ne posséderait pas d'opérande else (qui n'aurait qu'une seule branche)

Opérateur "Break"

L'équivalent de ce diagramme de séquence sans l'opérateur break correspond aux deux diagrammes de séquence dans le diapositive suivant:

Opérateur "Parallel“ -- par

L'opérateur "par" est utilisé pour représenter des intéractionsayant lieu en parallèle

Opérateur "Loop"

L'opérateur "Loop" (boucle) est noté "loop". Cet opérateur est utilisé pour décrire un ensemble d'intéraction qui s'exécutent en boucle. En général, une contrainte appelée garde indique le nombre de répétitions (minimum et maximum) ou bien une condition booléenne à respecter.

Fragment combiné -- mixte

Diagramme de communication

La notation UML

Définition

Un diagramme de communication est un diagramme d'interaction qui présente les messages échangés en fonction de la structure.

un diagramme de communication rend compte de l'organisation spatiale des participants à l'interaction

Il est souvent utilisé pour illustrer un cas d'utilisation ou pour décrire une opération.

Le diagramme de communication aide à valider les associations du diagramme de classe en les utilisant comme support de transmission des messages.

Éléments composant une collaboration:1. Objets: Instance d’une classe.

Rectangle avec étiquette de la forme nomObjet:nomClasse ou :nomClasseOn représente uniquement les objets pertinents i.e. interagissant dans le cas d’utilisation ou le scénario qu’on veut décrire.

2. Liens: Instances de certaines associations dans le diagramme de classes. On ne représente que les instances d’associations pertinentes pour la collaboration décrite.

3. Acteurs: On peut représenter les acteurs participant au cas d’utilisation ou scénario décrit. L’acteur initiant un cas d’utilisation est appelé initiateur.

Exemple sans lien

mb:MembreBiblio

unExemplaire:Exemplaire

leLivre :Livre

unMembre: Emprunteur

Ajout des messages sur les liens...

On indique les messages à côté des liens appropriés sur le diagramme de collaboration.

La flèche est issue de l’émetteur et pointe vers le destinataire.

L’association correspondante dans le diagramme de classe doit être navigable dans la même direction que la flèche.

Le destinataire doit pouvoir comprendre le message (opération appropriée?)

n°, cond, …: message

Représentation des interactions Numéro du message: Lorsqu’un objet O reçoit un

message (synchrone), le numéro de ce message est utilisé comme préfixe pour tous les messages envoyés par O… jusqu’à ce que O réponde à ce message.

En général, les messages de retour n’apparaissent pas explicitement dans les diagrammes de collaboration.

Types de messages: simple, synchrone, asynchrone…

Aussi: garde, itération, etc.

Attention (cohérence des divers diagrammes) :

methodeR doit être une méthode de la Classe A dans le diagramme de Classes, MéthodeS doit être une méthode de la Classe B dans le diagramme de Classes MéthodeT doit être une méthode de la Classe D dans le diagramme de Classes

Représentation des messages Un message est spécifié sous la forme suivante :

cond est une condition sous forme d’expression booléenne entre crochets. séq est le numéro de séquence du message. On numérote les messages par

envoi et sous-envoi désignés par des chiffres séparés par des points : ainsi l’envoi du message 1.4.3 est antérieur à celui du message 1.4.4 mais postérieur à celui du message 1.3.5. La simultanéité d’un envoi est désignée

par une lettre : les messages 1.6.a et 1.6.b sont envoyés en même temps. iter spécifie (en langage naturel, entre crochets) l’envoi séquentiel (ou en

parallèle, avec ||). On peut omettre cette spécification et ne garder que le caractère "*" (ou "*||") pour désigner un message récurrent envoyé un certain nombre de fois.

r est la valeur de retour du message, qui sera par exemple transmise en paramètre à un autre message.

msg est le nom du message. par désigne les paramètres (optionnels) du message.

Représentation des messages

A

B

1: message()

Message

A

B

1: [cond] message()

A

B

1: res:= message()

A

B

1: *[i:=1..n] message()

BB

A

B C

1: m1()

1.1: m2()

1.2: m3()

2: m4() 1.a: m1()

A

B C

1.b: m2()

Message conditionnel Message avec retour

Itération Invocations synchrones Concurrence

Exemple avec interactions

leMembre:MembreBiblio

cetExemplaire:Exemplaire

leLivre :Livre

unMembre: Emprunteur

emprunter(cetExemplaire)

1: okPourEmprunter()

2: emprunter

2.1: est_emprunté

Création et destruction dynamiques d’objets

Ajout d’une contrainte ({new} ou {destroyed}) après l’étiquette dans le rectangle représentant l’objet créé ou détruit.

Si au cours des interactions représentées par le diagramme, un objet est créé puis détruit, on utilise la contrainte {transient}.

Les messages de création et de destruction d’objets: new, destroy…

exemple

:ProfAgrégé {new}

:ProfAdjoint {destroyed}

: Doyen

1: k : = obtenirNom()

2: new ProfAgrégé(n)

3 : destroy()

Message avec garde

concurrence

Le message 1 est un message simple itératif.

Les messages 2.a et 2.b sont des messages synchrones concurrents.

Les messages 3.a et 3.b sont des messages asynchrones concurrents

t:TourDeContrôle

b:Boeing747

a1:Avionétat = à_terre

position = piste

a2:Avionétat = à_terre

position = piste

:Pompiers1: * alerte()

3.b: atterrir(piste)

3.a: envoyer(piste)

2.b: déplacer(piste,parking)

2.a: déplacer(piste,parking)

Diagramme d’état-transition

La notation UML

Introduction

Permet de décrire le cycle de vie d’un Objet :

Les différents états qu’il peut atteindre

Les règles régissant le passage d’un état à un autre

Au niveau métier permet de décrire les règles de

gestion assurant comment sont utilisés les objets du

monde (ex. facture).

Au niveau logique :

Transposition au niveau des objets concrets (ie futur code)

Spécification de règles de comportement des objets « concrets » (ex. objet graphique).

État :

Objet: caractérisé en principe par l’ensemble des valeurs prises par les attributs de l’objet à un instant t. Mais selon cas peut se réduire à l’étude de certains attributs.

Métier: caractérise l’état d’une entité au sens large : état stable, en cours d’exécution, attente d’un évènement…

Transition :

traduit le passage possible d’un état à un autre avec éventuellement des conditions sur l’événement à l’origine de l’activation de la transition (condition de garde).

Type d’état

Type d’État :

État initial : traduit l’initialisation du diagramme d’état (1 seul par diagramme).

État final : caractérise la fin du diagramme (0..n).

État simple : caractérise l’état d’un objet

État composite: permet de gérer l’abstraction en définissant un « super » état dans lequel une séquence d’état et de transition peuvent décrire plus finement ce qui se passe dans cet état (ex. l’état Inscription peut être décomposé en état saisi, état frais inscription calculés, frais payés, inscrit).

Type d’évènement

Type d’évènement pouvant déclencher une transition :

Réception d’un signal : envoi d’un message asynchrone par un autre objet ou par un acteur (point de vue métier)

Appel de méthode (call event) sur l’objet modélisé (synchrone ou asynchrone). (point de vue objet)

Écoulement d’une durée (time event) relative (10 sec) ou absolue (date précise). Utilisation du mot clé after

Changement de condition (change event) : décrite par une expression booléenne sur des variables (état d’une variable, d’un objet, d’une valeur globale) mot clé when

Exemple

Etat et transition interne

Diagramme actif: possibilité de spécifier des actions…

Action : opération associée à un état non interruptible

Activité : idem mais interruptible.

Ces opérations peuvent être exécutées :

Dés l’entrée dans l’état

A la sortie de l’état

Pendant l’activation de l’état interruptible)

Les transitions peuvent également réaliser des actions

Point de décision

Il est possible de représenter des alternatives pour franchir une transition, on utilise soit:

Point de jonction ( représenter par )

Elle permet de partager des segments de transition.

Tous les chemin sont potentiellement valides.

Point de choix ( représenter par )

Saisie formulaire

Afficher problèmes

Demander confirmation

Go/valideEntrée() Entrée valide

[else]

Etat composite

Un état composite est graphiquement composé en deux ou plusieurs sous-état.

Exemple cabinet téléphonique

Début

Entry/tonalité « prêt »Exit/cesse tonalité

Numéroter

Entry/numéro.apprend(n)

Chiffrer (n)

Chiffrer (n) [Num.valid]

Composer numéro

Composer numéro

Gestion de la concurrence

Les diagramme d’état permettent de décrire efficacement les mécanismes concurrents.

fork join

état historique

Exemple de diagramme possédant un état historique profond permettant de reprendre le programme de lavage ou de séchage d'une voiture à l'endroit où il était arrivé avant d'être interrompu.

Diagramme de paquetage

La notation UML

Définition

Un diagramme de paquetage est un diagramme de structure qui montre les paquetages et, éventuellement, les relations entre eux.

Un paquetage étant un conteneur logique permettant de regrouper et d'organiser les éléments dans le

modèle UML (classes, use cases, etc.)

le Diagramme de paquetage sert à représenter les dépendances entre paquetages, c’est-à-dire les dépendances entre ensembles de définitions.

Utilité

Très utilisé, indispensable pour les grands modèle

Indispensable pour définir l’architecture d’un modèle, pour gérer un modèle et son développement par une équipe

Utile dès l’analyse et fondamentale en conception

Dépendance

un paquetage est dépendant d’un autre s’il l’utilise…

SimpleChat

ClientCommon

OCSF

ClientServer

<<import>>

Diagramme de composant

La notation UML

Définition

Un composant doit fournir un service bien précis

Les fonctionnalités qu’il encapsule doivent être cohérentes entre elles et génériques

Un composant est une unité autonome représentée par un classeur structuré, stéréotypé «component», comportant une ou plusieurs interfaces requises ou offertes.

Son comportement interne, généralement réalisé par un ensemble de classes, est totalement masqué : seules ses interfaces sont visibles.

Pour montrer les instances des composants, un diagramme de déploiement doit être utilisé

Composant

Composants et interfaces

Composant

Commande

EntréeCmdes

PaiementComptes

Personne

composantinterface requise interfaces offertes

Commande

<<provided interfaces>>

EntréeCmdes

PaiementComptes

<<required interface>>

Person

Composants et relations

Une flèche de dépendance permet de mettre en relation des composant via les interfaces requises et fournies

Système de

commande

AccèsProduit

RechercheClient

Système

d’inventaire

Repositoire

ClientsRechercheClient

AccèsProduit

(3) dépendance

(1) composant

(2) interface

Composants et relations

Planificateur

réservations

GUI

Gestionnaire

d’horairesréservations

mise à jour

mise à jour

Réunions_BD

accèsBD

accèsBD

Composants – Vue de la structure interne

Pour montrer la structure interne d’un composant

:CommandePersonne

:Produit

:Client

ItemCommandable

Magasin

EntréeCmdes

<<delegate>>

Compte

Compte

EntréeCmdes

<<delegate>>

port

Assembly

connector

Entête

LigneCmde*

Diagramme de composants MVC

Diagramme de déploiement

La notation UML

Définition

Un diagramme de déploiement décrit la disposition physique des ressources matérielles qui composent le système

Il montre la répartition des composants sur chaque matériels

Chaque ressource étant matérialisée par un nœud

Chaque ressource est matérialisée par un nœud représenté par un cube comportant un nom

Un nœud est un classeur et peut posséder des attributs (quantité de mémoire, vitesse du processeur, …).

Exemple

GPS satellite

M1:MachineX

M2:MachineX

C1:Client

C2:Client

S:Serveur

Communication

sans fil

TCP/IP

noeuds

lien

Exemple 2

Machine de Joe:PC

:Planificateur

GUI

mise à jour

Admin:MachineHote

:Gestionnaire

Horaires

:Réunions_BD

réservations

Accès_bd

internet

Exemple 3