UML3

INTRODUCTION A UMLINTRODUCTION A UMLINTRODUCTION A UMLINTRODUCTION A UML

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

Moussa LO

UFR de Sciences Appl. & de Technologie

UGB de Saint-Louis

Bibliographie

• Intégrez UML dans vos projets, N. Lopez, J. Migueis, E. Pichon, Eyrolles, 1998.

• Modélisation objet avec UML, P. Muller, Eyrolles, 1998.

• UML 2 en action, P. Roques, F. Vallée, Eyrolles, 2004


• UML 2, Initiation, exemples et exercices corrigés, L. Debrauwer, F. V. der Heyde, ENI, 2005.

• UML 2, Entraînez-vous à la modélisation, L. Debrauwer, N. Karam, ENI, 2005.

Webographie

• UML @ site de l’OMG, http://www.uml.org/ .

• UML en français, http://uml.free.fr/ .

• UML @ developpez.com, http://uml.developpez.com/


• UML @.wikipedia, http://fr.wikipedia.org/wiki/Unified_Modeling_Language

• Support de cours UML de F. Julliard, Université de Bretagne Sud, 2002.

• Support de cours UML de Y. Laloum, CNAM.

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 ≠≠≠≠ Méthode de conception

• UML = notation graphique normaliséede présentation de certains concepts pour modéliser des systèmes objets.


de certains concepts pour modéliser des systèmes objets.

• Peut être utilisée avec tout processus de développement objet.


• La version actuelle de UML (2) s’articule autour de 13

diagrammes.

� 4 ont été introduits dans UML 2, Juillet 2005.


• Chaque diagramme fournit une représentation du systèmesuivant un point de vueparticulier.


• UML modélisele système suivant 2 modes de représentation(nécessaires et complémentaires):

� Mode statique(ou structurel) : concerne la structure du système pris au repos.


� Mode dynamique(ou comportemental) : concerne la dynamique de fonctionnement du système.

� UML schématise la manière dont le système est composé et comment ses composantes sont liées.

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


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;


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).

Quelques outils UML

� Rational Rose, http://www-306.ibm.com/software/rational/

� WinDesign, http://www.win-design.com/

� Objecteering/UML, http://www.objecteering.com/

� Poseidon


� Poseidon, http://www.gentleware.com/

� ArgoUML , http://argouml.tigris.org/

� EclipseUML, http://www.eclipsedownload.com/

Les cas d’utilisation d’UML

analyse


spécifications Use cases

tests

Use cases d’UML

• Modélisation de processus métiersen 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érieurau 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)

Responsable 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 acteurs

• Humains :

� Utilisateurs du logiciel (via l’interface graphique)

• Logiciels :

� Autres logiciels qui interagissent avec le logiciel


• Matériels :

� Matériels qui exploitent les données du logiciel ou qui sont pilotés par le logiciel

� Ne pas confondre acteuret personneutilisant le système :

� Une même personnepeut jouer plusieurs rôles

� Plusieurs personnespeuvent jouer un même rôle

Définition d’un acteur

• Pour chaque acteur :� choisir un identificateur représentatif du rôle

� mettre, éventuellement, une brève description textuelle


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:


• 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.


• 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.)


� Use case “ Retrait en espèces “

• Nom : Retrait en espèces

• Acteurs : Guichetier

• Description :


Description :

� Le guichetier saisit le numéro de compte du client.

� L’application vérifie la validité du numéro de compte et demande le type d’opération au guichetier.

� Le guichetier sélectionne un retrait d’espèces d’un certain montant.

� L’application vérifie que le montant est disponible dans le compte. Si oui, elle débite le compte et informe le guichetier qu’il peut donner la somme au client.

Exemples de diagramme de use cases


Exemples de diagramme de use cases


Relations entre use cases

� 2 types de relations:

• Extension (extends)

• Utilisation (usesou include)


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


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.



Les scénarios


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.


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 aspect s 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 re pré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.


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

objet_1 : Classe objet_2 : Classe



message


• La transmission d’informations est possible.




message (donnee1, donnee2)


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


Auto-envoi de message :

Un objet peut s’envoyer un message.

objet : Classe


objet : Classe


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.


Creation et destruction d’un objet :

objet_1 : Classe

objet_2 : Classe


objet_2 : Classe

X



Le diagramme de classes


Diagramme de classes

• Permet de définir l’ensemble des classes et leurs relations.

• Une classe est représentée par un rectangleséparé en 3 parties :


parties :� La 1ière partie contient le nom de la classe

� La 2e partie contient les attributs de la classe

� La 3e partie contient les méthodes de la classe

• Pour des raisons de lisibilité, on peut masquer ou non une de ces parties

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;

}


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 : typeattribut2 : type = valeur

methode1(args)


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.


entre les classes associées.


• Association ternaire:

Classe1 Classe2


Classe3


Types de multiplicité des associations

1 : un et un seul

0 .. 1 : zéro ou un


m .. n : de m à n

* : de zéro à plusieurs

0 .. * : de zéro à plusieurs

1 .. * : de un à plusieurs

N : exactement N


• 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.


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 desstructuresde classescompliquéesen montrantdes


structuresde classescompliquéesen montrantdesexemples d’instance.

• Les diagrammes de structure composite permettentde décrire la composition d’un objet complexe lorsde l’exécution.

Diagramme de packages

• Un package est un ensemble de classes et d'autrespackages regroupés sous un nom.

• C'est l'adaptation du concept de librairie ou debibliothèque.


bibliothèque.

• Servent à structurer l’ensemble des classes etinterfaces.

• Permet de structurer un système en plusieurs parties,chacune représentée par un package .





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 êtreActif ou Inactif :

• Inactif : attendunsignalprovenantd’autresobjets


• Inactif : attendunsignalprovenantd’autresobjets

• Actif : réalise une activité (exécution d’une série demé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é :


• 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-transitionsdans 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 dansl’environnement de réalisation.

• Vue statique de l’implémentation des systèmes quimontrentleschoixderéalisation.


montrentleschoixderéalisation.

• En général, il n’est utilisé que pour des systèmescomplexes.

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’unsystème et la répartition des instances de composants,processus et objets qui « fonctionnent » sur cesmatériels.


matériels.

• Modélisation de l’architecture matérielle.

• Très utile pour des systèmes distribués.

Le diagramme de déploiement


Documents

UML3