# UML : Introduction
__Samuel Michaux__
---
__Pour construire cette maison__
- Il faut établir un plan avant.
---
## La réalisation d’une application peut passer par plusieurs étapes
- Définition des besoins
- Analyse
- Conception
- Développement
- Test
- Validation
- Déploiement
- Maintenance
- ...
---
## Où est l'UML dans tout ça ?
UML permet de __modéliser__ toutes les étapes du développement d’une application de l’analyse au déploiement (en utilisant plusieurs diagrammes).
---
## UML : Unified Modeling Language
- Un langage de modélisation unifié
- Ce n’est pas un langage de programmation
- Indépendant de tout langage de programmation (objet ou autre)
- Un langage basé sur des notations graphiques
- Constitués de plusieurs graphes (__diagrammes__) permettant de visualiser l’application à réaliser de plusieurs angles différents
- Une norme maintenue par l’OMG (Object Management Group : organisation mondiale créée en 1989 pour standardiser le modèle objet)
---
# UML
#### Est un graphe ?
En mathématique, c'est un outil composé de :
- un ensemble de sommets, et
<!-- .element: class="fragment" data-fragment-index="1" -->
- un ensemble d'arêtes(arcs) reliant les sommets
<!-- .element: class="fragment" data-fragment-index="2" -->
#### Exemple de graphe :
<!-- .element: class="fragment" data-fragment-index="3" -->
<!-- .element: class="fragment" data-fragment-index="4" -->
---
# UML
#### Avant UML : plusieurs méthodes orientées objets (entre 1970 et 1995)
- Booch (présentée par Grady Booch)
- OMT (introduite par James Rumbaugh)
- OOSE (proposée par Ivar Jacobson)
- OOA, OOD, HOOD...
---
# Début d’UML
- En 1995, Booch, Rumbaugh et Jacobson commencent à travailler sur une méthode unifiée (Unified Method)
- En 1996, Création d’un consortium de partenaires pour travailler sur la définition d’UML
- En 1997, Normalisation de la méthode UML 1.1 par l’OMG
---
# Différente version d’UML
- UML 1.1 : 1997
- UML 1.2 : 1998
- ...
- UML 2.4 : 2011
- UML 2.5 : 2015
- UML 2.5.1 :2017
---
# Remarques
- 14 diagrammes depuis UML 2.3
- classés en deux catégories
- __7 diagrammes de structure (statiques)__ : permettent de décrire la structure d’un système selon plusieurs points de vue différents (classes, composants, noeuds, objets, packages...)
- __7 diagrammes de comportement (dynamiques)__ : permettent de décrire le comportement du système de plusieurs points de vue différents (temporel, changement d’état...)
---
## Diagrammes de structure (statiques)
- Diagramme de classes (class diagram)
- Diagramme d’objets (object diagram)
- Diagramme des paquets (package diagram)
- Diagramme de composants (component diagram)
- Diagramme de déploiement (deployment diagram)
- Diagramme de structure composite (composite structure diagram)
- Diagramme de profils (profile diagram)
---
## Diagrammes de comportement (dynamiques)
- Diagramme de cas d’utilisation (use-case diagram)
- Diagramme états-transitions (state machine diagram)
- Diagramme d’activité (activity diagram)
- Diagramme de séquence (sequence diagram)
- Diagramme de communication (communication diagram)
- Diagramme global d’interaction (interaction overview diagram)
- Diagramme de temps (timing diagram)
---
# Notations communes
- Classeur : a une forme rectangulaire et permet de représenter plusieurs éléments dans différents diagrammes UML
<!-- .element: class="fragment" data-fragment-index="1" -->
- Package (paquetage) : est un regroupement d’éléments de système ou de diagrammes
<!-- .element: class="fragment" data-fragment-index="2" -->
- Stéréotype : annotation entourée par «nomAnnotation» permettant d’ajouter une précision sur l’élément annoté
<!-- .element: class="fragment" data-fragment-index="3" -->
<!-- .element: class="fragment" data-fragment-index="4" -->
---
# Les flèches en UML
---
## Quelques logiciels pour faire la modélisation UML
- Power Designer (payant - version d’essai 30 jours)
- __StarUML__
- BoUML
- Visual Paradigm (payant - version d’essai 30 jours)
- Astah (payant - version d’essai 30 jours)
- Outil en ligne : https://app.diagrams.net
- ArgoUML (Open source)
- PlantUML
---
# UML - Diagramme d'activités
---
# Plan
- Introduction
- Activité
- Transition
- Condition de franchissement et noeud de décision
- Noeud de fusion
- Noeuds de bifurcation et d'union
---
# Diagramme d’activités?
- Un diagramme dynamique d’UML
- Permettant de représenter le comportement d’une méthode ou le déroulement d’un cas d’utilisation
- Utilisant des automates comme un diagramme états-transitions
- Comme un diagramme de séquence mais avec une attention particulière sur les opérations plutôt que les objets
---
# Mot-clés associés
- activité
- transition
- condition de franchissement noeud de décision
- noeud de fusion
- noeud de bifurcation
- noeud d’union
---
### Activité
Comportement défini par un groupe d’__instructions__ (action en UML)
__Comment représenter une activité en UML 2?__
<!-- .element: class="fragment" data-fragment-index="1" -->
<!-- .element: class="fragment" data-fragment-index="2" -->
__Exemple d’activité dans un processus de gestion d’emprunt (d’une bibliothèque)__
<!-- .element: class="fragment" data-fragment-index="3" -->
<!-- .element: class="fragment" data-fragment-index="4" -->
---
- Noeud (activité) initial d’un diagramme d’activité
<span style="background-color: white; display: inline-block;"></span>
- Noeud (activité) final d’un diagramme d’activité
<span style="background-color: white; display: inline-block;"></span>
---
# Transition
- Le passage d’une activité vers une autre
- Déclenchées automatiquement à la fin de l’activité source provocant ainsi le début immédiat de l’activité cible
- Représentée en UML par une flèche (arc)
---
# Activité + transition
<span style="background-color: white; display: inline-block;"></span>
---
# Exemple
<span style="background-color: white; display: inline-block;"></span>
---
# En ajoutant les noeuds initial et final, le diagramme devient
<span style="background-color: white; display: inline-block;"></span>
---
## Anomalies de la solution précédente
:::warning
- D’après notre système, on n’a pas besoin que la carte soit valide pour continuer à faire le reste du processus
- Si on ne trouve pas le livre que l’on cherche, on peut aussi enregistrer emprunt
:::
<br>
## Solution
<!-- .element: class="fragment" data-fragment-index="1" -->
:::info
Définir des conditions de franchissement.
:::
<!-- .element: class="fragment" data-fragment-index="2" -->
---
# Condition de franchissement (ou de garde) ?
- une transition peut avoir une condition
- expression booléenne exprimée en langage naturelle (mathématique, logique...)
- placée entre crochet `[condition(s)]`
- accompagnée souvent d’un noeud de décision
---
# Noeud de décision
- ou branchement conditionnel
- schématisée en UML par un losange
- permettant de faire un choix entre plusieurs sorties (au moins une entrée + plusieurs sorties)
- accompagnée souvent d’une condition de franchissement
---
<!-- .slide: data-transition="fade-in convex-out" -->
### Activité + transition + condition de franchissement + noeud de décision
---
<!-- .slide: data-transition="fade-in convex-out" -->
### Activité + transition + condition de franchissement + noeud de décision
---
# Exemple
---
### Exemple avec plusieurs conditions
---
# Noeud de fusion ?
- schématisé aussi en __UML__ par un losange
- permettant de fusionner plusieurs entrées (plusieurs entrées + une sortie)
---
# Noeud de fusion ?
---
### Exemple avec un noeud de fusion
---
## Hypothèse
Si on veut imprimer une fiche contenant les informations concernant l’emprunt (après avoir enregistré l’emprunt) et au même moment de l’affichage de la date de retour.
## Remarque
<!-- .element: class="fragment" data-fragment-index="1" -->
Impossible à le faire dans un diagramme séquentiel sans passer par les noeuds de bifurcation et d’union.
<!-- .element: class="fragment" data-fragment-index="2" -->
---
## Noeuds de bifurcation
- permettant de lancer des activités concurrentes (parallèles)
- schématisée en UML par un trait plein
- possédant une entrée et plusieurs sortie
## Noeuds d’union
- permettant de synchroniser des activités concurrentes (dites aussi parallèles)
- schématisée en UML par un trait plein
- possédant plusieurs entrée et une sortie
---
## Activités + transition + noeuds de bifurcation et d’union
---
### Exemple avec noeuds de bifurcation et d’union
---
# Exercice 1
Modifier le diagramme d’activités précédant pour qu’on puisse proposer à un utilisateur de rechercher un livre (ou pas) s’il n’a pas trouvé le livre qu’il cherchait.
----
## Correction
---
## Exercice 2
Elaborer un diagramme d’activités pour l’opération de retrait d’argent, il faut prendre en compte les cas suivants :
- carte non valide
- code incorrect
- solde insuffisant
- proposer à l’utilisateur de quitter à toute phase du processus
- proposer à l’utilisateur de ressaisir son code tant que le nombre de saisie erronée est inférieure à 3, sinon avaler la carte
- imprimer un récépissé en fin de processus
----
## Correction
---
# Diagramme de séquences
---
# Diagramme de séquences
1. Introduction
2. Ligne de vie
3. Message
4. Fragment combiné
---
# Diagramme de séquences ?
- Un diagramme dynamique d’UML
- Représentant l’interaction entre les acteurs et le système selon un ordre chronologique
- Pouvant servir à détailler un cas d’utilisation
----
- Le temps s’écoule selon une dimension verticale (non graduée) de haut en bas
- Les objets sont organisés horizontalement
- L’échange entre les différents éléments se fait moyennant des messages
---
## Mots-clés associés
- Ligne de vie (et activité)
- Message
- Fragment combiné
---
## Ligne de vie
- Rectangle au sommet contenant le nom de type (objet, acteur...) + ligne verticale pointillée
- Permettant de définir la zone d’envoi et de réception de messages échangés avec les autres lignes de vie
---
## Plusieurs représentations possibles en UML
---
## Exemple
:::info
L'acteur `Vendeur` peut être représenté comme un objet.
:::
---
## Etant donné l'exemple suivant :
#### Objectif
Détailler le cas d’utilisation Modifier prix article avec un diagramme de séquences.
---
### Déroulement
- Le vendeur va utiliser la page vendeur pour appeler une méthode _changerPrix(a, p) : a_ étant un objet de type _Article_ et _p_ le nouveau prix
- Pour modifier le prix de cet article, la page vendeur fera appel à la méthode _setPrix\(p\)_ de l’objet _a_
### Comment modéliser tout ça ?
- Les échanges entre deux lignes de vie se fait via des message
---
## Message
- Représenté par une flèche
- Définit une communication entre deux lignes de vie
- Déclenche une activité sur une ligne de vie
- Possède un nom (méthode, signal...)
- Peut avoir des paramètres
---
## Voici comment modéliser les messages en UML
----
### Remarque
La réception d'un message a déclenché une activité dans l'objet _:PageVendeur_.
---
#### Le diagramme de séquence correspondant au cas d’utilisation _Modifier prix article_
:::info
La ligne en pointillé correspond à la réponse au message synchrone.
:::
---
## Message Synchrone
- Bloque l’émetteur
- Le récepteur rend la main à l’émetteur par un message de retour (sa représentation est optionnelle)
- Peut spécifier le résultat de la méthode invoquée
----
---
## Message Asynchrone
- Ne bloque l’émetteur
- Représentée graphiquement par une flèche continue à extrémité ouverte
----
## Explication
- _:Objet1_ a envoyé un premier message à _:Objet2_ qui a déclenché une activité chez ce dernier
- Ensuite, il a envoyé un deuxième message à _:Objet3_ sans attendre ni la réponse de _:Objet2_ ni la fin de sans activité
---
## Qu’arrive t-il en cas de message concomitants?
- Si un objet est actif, la réception d’un message implique la création d’une nouvelle activité
- La nouvelle activité sera représentée par un rectangle chevauchant le premier
----
---
## Un objet peut créer et détruire un deuxième objet
- La création d’un objet se fait par l’envoi d’un message avec le Stéréotype _`<<create>>`_
- La destruction se fait par l’envoi d’un message avec le stéréotype _`<<destroy>>`_
----
---
## Qu’est ce qu’un message complet, perdu et trouvé?
- Complet : évènements d’envoi et de réception connus
- Perdu : évènement d’envoi connu mais pas la réception
- Trouvé : évènement de réception connu mais pas l’envoi
----
---
## Exercice
- Quand un courrier électronique est envoyé par l'émetteur, celui-ci ne veut pas attendre que destinataire l'ait reçu et il n'y a pas d'intermédiaire. Peut-on utiliser un message synchrone ? Complétez la figure ci dessous par des flèches représentant des messages.
----
---
## Exercice
- Un serveur de messagerie sert d'intermédiaire entre l'émetteur et le récepteur d'un email. Le serveur est toujours en fonction. Est-ce qu'on peut utiliser des messages synchrones pour l'envoi et la récupération de emails ? Complétez la figure ci dessous par des flèches représentant des messages.
----
---
## Question
Comment faire pour répéter une partie du diagramme de séquence ou pour ajouter un bloc conditionnel ?
## Solution<!-- .element: class="fragment" -->
Utiliser les fragments combinés<!-- .element: class="fragment" -->
---
## Fragment combiné
- Fragment d’interaction
- Utilisant un opérateur [et des opérandes]
- Exemple d’opérateurs :
- _alt_ : opérateur conditionnel à plusieurs opérandes (équivalent d’un bloc _if...else if...else_ en programmation)
- _opt_ : opérateur conditionnel à une seule opérande (_if_ sans _else_)
- _loop_ : opérateur répétitif acceptant au max deux valeurs min et max
- _par_ : opérateur d’exécution parallèle
- ....
---
## Structure d’un fragment combiné
Certains fragments n’ont pas besoin d’une condition ni de plusieurs
opérandes.
---
## Exemple de _alt_ avec un distributeur de billets
Si le code est incorrect, il faut recommencer (c’est répétitif) => On peut utiliser l’opérateur _loop_.
---
## Exemple de _alt_ avec un distributeur de billets
- En précisant un seul paramètre (3) pour loop, on a défini un nombre exact d’itération
- Si on ne précise aucun paramètre, alors il s’agit d’une boucle infinie
---
:::danger
__Remarque__
La solution précédente oblige l’utilisateur à refaire l’opération 3 fois même s’il saisit correctement le code.
:::
---
#### Pour corriger ça, on peut utiliser un fragment break qui sera exécuté avant de quitter la boucle :
---
#### On peut aussi définir le contexte comme un fragment principal :
---
### Exercice
Compléter le diagramme précédent en étudiant les différents cas possibles pour le retrait d’argent (solde insuffisant, possibilité d’imprimer un ticket...).
---
# UML : concept objet et diagramme de classes
---
1. Introduction
2. Evolution des langages
3. Le concept `objet`
4. La notion de classe
5. L'encapsulation
6. Les relations entre classes
- La navigabilité
- Les rôles
- Les classes liées par plusieurs associations
- L'auto-association
- Les associations n-aires
---
7. Les associations particulières
- L'héritage
- L'agrégation
- La composition
- La dépendance
8. La multiplicité
9. La classe d’association
10. Le polymorphisme
11. Les classes abstraite et finale
12. Les interfaces
13. Les contraintes avec UML
14. Comment construire un diagramme de classe ?
---
# Diagramme de Classe
---
# Diagramme de Classe
- Le diagramme de structure le plus important dans la réalisation d’un projet
- Utilisant le concept objet
- Pouvant être transformé, en respectant certaines règles, en MCD (le modèle conceptuel de données de Merise)
---
# Introduction
Les éléments de base dans un diagramme de classe
- Classe
- Attribut
- Méthode
- Association
- Multiplicité
---
# Histoire de la programmation
---
###### L'historique de la programmation
## Langage machine
- Le langage natif d’un processeur (langage de bas niveau)
- Les traitements (les instructions) et les données (les variables) sont tous codés en binaire (suite des 0 et 1)
<!-- .element: class="fragment" data-fragment-index="1" -->
## Remarque
<!-- .element: class="fragment" data-fragment-index="2" -->
:::warning
- La lisibilité est extrêmement difficile
- La réutilisation est quasi-impossible
- La notion de module n’existe pas
:::
<!-- .element: class="fragment" data-fragment-index="3" -->
---
###### L'historique de la programmation
## L’assembleur
- Une réécriture plus lisible du langage machine
- Une instruction est formée de nom de l’opération (mov, add...) et d’une ou plusieurs opérandes (variables)
- Un programme assembleur est traduit en langage machine
<!-- .element: class="fragment" data-fragment-index="1" -->
## Remarque
<!-- .element: class="fragment" data-fragment-index="2" -->
:::warning
- La lisibilité est légèrement meilleure mais reste difficile
- La réutilisation est toujours quasi-impossible
- La notion de module n’existe toujours pas
:::
<!-- .element: class="fragment" data-fragment-index="3" -->
---
<!-- .slide: style="font-size: 0.95em;" -->
###### L'historique de la programmation
## La programmation structurée (ou procédurale)
- Un programme est composé d’un ensemble d’appel à des procédures réalisant chacune une tâche bien définie
- Une procédure peut appeler plusieurs procédures (y compris elle-même, on parle dans ce cas de récursivité)
<!-- .element: class="fragment" data-fragment-index="1" -->
## Remarque
<!-- .element: class="fragment" data-fragment-index="2" -->
:::success
- La lisibilité est considérablement améliorée
- Une procédure peut être appelée plusieurs fois par plusieurs procédures différentes (la réutilisation est nettement améliorée)
- Apparition de notion de module
:::
<!-- .element: class="fragment" data-fragment-index="3" -->
---
<!-- .slide: style="font-size: 0.9em;" -->
###### L'historique de la programmation
## La programmation orientée objet
- Tout concept, idée, opération... est considéré comme un objet
- Un objet peut contenir certains autres objets et avoir des relations avec certains autres
- Chaque objet possède une structure interne et peut avoir plusieurs états différents
<!-- .element: class="fragment" data-fragment-index="1" -->
## Remarque
<!-- .element: class="fragment" data-fragment-index="2" -->
:::success
- Tout passe par des objets. Un programme correspond à un ensemble d’instanciation d’objets : facile à lire
- Un objet peut être instancié et utilisé par plusieurs autres objets (ce qui facilite la réutilisation des objets)
- Amélioration de la notion de module (Package)
:::
<!-- .element: class="fragment" data-fragment-index="3" -->
---
###### L'historique de la programmation
## Remarque
- Certains compilateurs traduisent les codes soit en langage machine, soit en assembleur, soit en langage de programmation d’un niveau inférieur
- Certains compilateurs sont implémentés avec d’autres langages de programmation (par example la machine virtuelle de Java qui est implémentée en C++...)
---
###### L'historique de la programmation
## Pourquoi autant de génération ?
- (Plus) de problèmes de mémoire
- Des processeurs plus rapides
- Besoins différents
- __COBOL__ : pour les systèmes de gestion
- __Java__ : pour les problèmes complexes
- __LISP__ : pour les programmes d’intelligence artificielle
- __PROLOG__ : pour les problèmes de logique
---
### L'historique de la programmation Orientée Objet
#### Évolution de LOO
- Simula (1967)
- Smalltalk (1971 puis 1980)
- C++ (1983)
- Python (1989)
- Java (1995)
- C# (2002)
- PHP (depuis la version 5 sortie en 2004)
- ...
La plupart des langages de programmation ont proposé une nouvelle
version orientée objet.
---
###### La programmation Orientée Objet
### Deux catégories de LOO
- Les langages à classes : Java, C++, Python...
- Les langages à prototypes : JavaScript
---
###### La programmation Orientée Objet
### Supporté par tous les systèmes d’exploitation
- Adopté par Microsoft
- Adopté par les universitaires (en enseignement et en recherche)
- Adopté par la communauté OPEN SOURCE
- Adopté par les grandes entreprises
- ...
---
# Le concept `objet`
---
###### Le concept `objet`
### Qu’est ce qu’un objet ?
- Une représentation miniature d’un objet réel
- Tout concept du monde réel est modélisé par un objet
- Un outil sur lequel se baser pour créer des choses qui n’existent pas encore
- Nous pouvons le considérer comme une boite noire : inaccessible directement qu’à travers une interface
---
###### Le concept `objet`
### Un objet est une entité autonome
- véritable petit programme
- possède une durée de vie
- possède un état : un ensemble de valeurs
- accessible au monde extérieur via une interface
Un programme est composé de plusieurs objets autonomes qui vont
interagir entre eux.
---
###### Le concept `objet`
### De quoi est composé un objet ?
- un ensemble d'attributs (chaque attribut a un nom et une valeur) = données (qui définissent l'aspect statique de l'objet)
- un ensemble de méthodes (des fonctions, comme en programmation procédurale, dédiées à un type d’objet) = traitements (qui définissent l’aspect dynamique de l’objet)
---
###### Le concept `objet`
### Les attributs
- un attribut, selon le contexte, peut être aussi appelé champ ou variable d’instance
- un attribut peut avoir un type (ce n’est pas une obligation, tout dépend du langage de programmation)
- chaîne de caractère
- entier
- booléen
- date
- ...
---
###### Le concept `objet`
### Remarque
:::warning
- Un objet peut avoir comme attribut un autre objet
- comme les fonctions en programmation procédurale, une méthode peut appeler plusieurs autres
- Contrairement à la programmation procédurale, les données et les traitements ne sont pas séparés
:::
---
###### Le concept `objet`
### Exemple : maVoiture
- Une voiture peut avoir comme attribut
- numéro d’immatriculation (chaîne ou entier)
- marque (chaîne)
- modèle (chaîne ou entier)
- puissance (entier)
- couleur (chaîne)
- ...
----
- Elle peut avoir comme méthode
- avancer
- reculer
- freiner
- klaxonner
- ...
----
- numéro d'immatriculation : LY069ON
- marque : Peugeot
- modèle : 3008
- puissance : 8
- couleur : blanche
<br>
<br>
- L’ensemble de valeurs d’un objet définit son état
- Si je repeins la voiture précédente en noir (couleur = noir) alors nous disons que l’objet a changé d’état
- La voiture peut donc changer d’état mais il s’agit toujours du même objet
---
###### Le concept `objet`
# Attention
:::warning
- <span style="color: red">Ne pas confondre objets __identiques__ et objets __égaux__</span>
- Deux objets sont égaux si, au moment de comparaison, leurs attributs respectifs ont les mêmes valeurs
- Deux objets sont identiques s’ils ont le même OID (Object IDentifier)
- Si deux objets sont identiques alors ils sont aussi égaux
- La réciproque est bien évidemment fausse
:::
---
###### Le concept `objet`
### Exercice d’application
* Définissons un objet monLivre de type Livre<!-- .element: class="fragment" data-fragment-index="1" -->
* Déterminons ses principaux attributs ainsi que leurs valeurs<!-- .element: class="fragment" data-fragment-index="2" -->
* Définissons ses méthodes de base<!-- .element: class="fragment" data-fragment-index="3" -->
---
###### Le concept `objet`
### Cycle de vie
- **Création** : se réalise via une méthode spécifique dite `constructeur`
- L’objet sera par la suite utilisé pour effectuer des tâches bien précises
- **Destruction** : selon le LOO soit d’une façon implicite quand on ne fait plus référence à l’objet (comme en Java, C#...), soit d’une façon explicite en appelant une méthode bien spécifique destructeur (comme en PHP, C++...)
---
###### Le concept `objet`
### Le garbage collector (ramasse miettes)
- C’est le destructeur d’objets en Java, C# et Smalltalk
- II détruit automatiquement les objets qui ne sont plus utilisés
- Un objet n’est plus utilisé s’il n’est plus référencé
- Lorsque le garbage collector se déclenche, il détruit les objets non-utilisés
---
# La notion de classe
---
###### La notion de classe
### Qu’est ce qu’une classe en POO?
- Ça correspond à un plan, un moule, une usine...
- C’est une description abstraite d’un type d’objets
- Elle regroupe un ensemble d’objets ayant les mêmes propriétés statiques (attributs) et dynamiques (méthodes)
<br>
<br>
### Qu’est ce que c’est la notion d’instance ?<!-- .element: class="fragment" data-fragment-index="1" -->
- Une instance correspond à un objet créé à partir d’une classe (via le constructeur)<!-- .element: class="fragment" data-fragment-index="2" -->
- L’instanciation : création d’un objet d’une classe<!-- .element: class="fragment" data-fragment-index="3" -->
- instance = objet<!-- .element: class="fragment" data-fragment-index="4" -->
---
###### La notion de classe
### Dans un diagramme de classes UML
Une classe est représentée par un **classeur** contenant trois parties :
- première partie dédiée au nom de la classe
- seconde partie dédiée aux attributs
- dernière partie dédiée aux méthodes
```graphviz
digraph obj{
node[shape=record];
rankdir="BT";
teacher [label = "{<f0> NomClasse|<f1> \nles attributs\n\n |<f2> \nles méthodes\n\n }"];
}
```
---
###### La notion de classe
## De quoi est composé une classe ?
- Attribut : visibilité + nom + type<!-- .element: class="fragment" -->
- LOO faiblement typé, comme PHP, Python..., n’exigent pas un type pour les attributs<!-- .element: class="fragment" " -->
- LOO fortement typé, comme Java, C++..., exigent un type pour chaque attribut<!-- .element: class="fragment" -->
- Méthode : nom + arguments + valeur de retour = signature : exactement comme les fonctions en procédurale<!-- .element: class="fragment" -->
---
###### La notion de classe
### Remarque
:::warning
- Un attribut ou une méthode peut être de classe (static) ou d’instance
- Un attribut (ou une méthode) est dit static si sa valeur est partagée par tous les objets de la classe
:::
---
###### La notion de classe
### Une classe
- peut cacher son implémentation
- ne montre aux autres objets que ce qu’elle autorise : interface
### Propriétés
- Les objets interagissent les uns avec les autres via les interfaces
- Ce qui n’est pas dans l’interface n’est ni visible ni accessible aux autres objets
> La dissociation de l’interface et de l’implémentation: **encapsulation**
---
###### La notion de classe
### L'encapsulation, pourquoi?
- Protection des données
- données inaccessibles de l’extérieur
- accès uniquement via l’interface
- possibilité de tracer tous les accès aux données
- focalisation sur les services rendus par les objets plutôt que sur leur structure
---
###### La notion de classe
### L'encapsulation, comment?
- En définissant des niveaux de visibilité
- Les méthodes comme les attributs sont concernés
### (Trois/Quatre) niveaux de visibilités
- public : visible par tous les autres objets
- protected : visible par certains objets (à voir plus tard)
- private : visible seulement depuis l’intérieur de l’objet
- package/internal : visible seulement depuis le même package
---
###### La notion de classe
### Dans un diagramme de classes
On peut utiliser :
- \+ : pour indiquer que la propriété a une visibilité public
- \- : pour indiquer que la propriété a une visibilité private
- \# : pour indiquer que la propriété a une visibilité protected
- \~ : pour indiquer que la propriété a une visibilité package
---
###### La notion de classe
```graphviz
digraph obj{
node[shape=record];
rankdir="BT";
Livre [label = "{<f0> Livre|<f1> - titre\l + nbrPages\l # datePublication\l |<f2> \n?\n\n }"];
}
```
### Dans cet exemple
- `titre` a une visibilité `private`
- `nbrPages` a une visibilité `public`
- `datePublication` a une visibilité `protected`
---
###### La notion de classe
### Certains langages, comme Smalltalk exige que :
- les attributs soient private
- les méthodes soient public
### En Java, PHP
- C’est juste une convention (une bonne pratique)
---
###### La notion de classe
```graphviz
digraph obj{
node[shape=record];
rankdir="BT";
personne [label = "{<f0> Personne|<f1> - nom\l - prenom\l - dateNaissance\l |<f2> + getNom()\l + getPrenom()\l + calculerAge() }"];
}
```
### Encapsulation
- Seules les trois méthodes `getNom()`, `getPrenom()` et `calculerAge()` sont visibles par les autres objets
- Les autres objets ignorent l’existence de l’attribut `dateNaissance`
---
###### La notion de classe
### Les méthodes publiques
- constituent l’interface de la classe
- sont accessibles de l’extérieur
<br><br>
### Les méthodes privées
- sont déclenchées par le biais d’autres méthodes privées ou publiques
- ne sont pas accessibles depuis l’extérieur
- ne sont accessible qu’au développeur de la classe
---
###### La notion de classe
## Question
Si les attributs sont toujours privés, comment modifier leurs valeurs?
## Réponse<!-- .element: class="fragment" -->
- Les getters (accesseurs) pour récupérer la valeur <br>(`getNomAttribut()`)<!-- .element: class="fragment" -->
- Les setters (mutateurs) pour modifier la valeur <br>(`setNomAttribut()`)<!-- .element: class="fragment" -->
---
###### La notion de classe
## Exercice
Définir les getters/setters de la classe `Personne`
```graphviz
digraph obj{
node[shape=record];
rankdir="BT";
personne [label = "{<f0> Personne|<f1> - nom\l - prenom\l - dateNaissance\l |<f2> \n?\n\n }"];
}
```
---
###### La notion de classe
## Comment créer un objet d’une classe ?
- en utilisant le constructeur de la classe
- en invoquant l’opérateur `new`
## Qu’est ce qu’un constructeur?
- une méthode particulière et spécifique à chaque classe
- elle porte le nom de la classe et n’a pas de valeur de retour
---
###### La notion de classe
# Exemple
- En java, C++, PHP, C#, TypeScript : `new Personne()`
- En Smalltalk : `Personne new`
---
###### La notion de classe
# Récapitulons
Une classe a :
- des attributs
- des méthodes dont
- le constructeur
- les getters
- les setters
---
# Relation entre les classes
---
###### Relation entre les classes
Considérons la classe `Adresse` :
```graphviz
digraph obj{
node[shape=record];
rankdir="BT";
adresse [label = "{<f0> Adresse|<f1> - rue\l - ville\l - codePostal\l |<f2> \n\n\n }"];
}
```
### Hypothèse
Supposant que chaque personne possède une adresse (objet créé à partir de la classe Adresse)
---
###### Relation entre les classes
### Comment schématiser cela en UML ?
En ajoutant dans la classe `Personne` un attribut `adresse` de type `Adresse`
```graphviz
digraph obj{
node[shape=record];
rankdir="BT";
personne [label = "{<f0> Personne|<f1> - nom\l - prenom\l - dateNaissance\l - adresse\l |<f2> \n\n\n }"];
adresse [label = "{<f0> Adresse|<f1> - rue\l - ville\l - codePostal\l |<f2> \n\n\n }"];
}
```
:::danger
Ce schéma n'est pas correct
:::
<!-- .element: class="fragment" -->
---
###### Relation entre les classes
### En reliant les deux classes (sommets d’un graphe) par une arête
Relation entre classes = association
----
L'association peut être nommée.
----
On peut aussi indiquer le sens de la lecture
----
On peut aussi ajouter deux noms à l’association : un pour chaque
sens de lecture
----
## Comment faire pour rendre la relation bidirectionnelle?
:::danger
- Pour une personne, on peut connaître son adresse
- Et pour une adresse, on peut connaître son propriétaire
:::
----
## L'association est maintenant bidirectionnelle
----
#### Les trois associations suivantes sont unidirectionnelles et équivalentes
---
## On peut définir des rôles
## Explication
- Le rôle d’une `Personne` dans une `Université` est enseignant
- Le rôle d’une `Université` pour une `Personne` est `employeur`
---
On peut définir une ou plusieurs associations entre deux classes
Deux associations possibles entre `Employé` et `Entreprise`.<!-- .element: class="fragment" -->
- Un `Employé` travaille dans une `Entreprise`.<!-- .element: class="fragment" -->
- Un `Employé` peut diriger une `Entreprise`.<!-- .element: class="fragment" -->
---
## Remarque
- Une association peut concerner une seule classe
<!-- .element: class="fragment" -->
## Comment lire ça?<!-- .element: class="fragment" -->
- Une personne est l’enfant d’une autre personne<!-- .element: class="fragment" -->
- Une personne est le parent d’une autre personne<!-- .element: class="fragment" -->
---
# Remarque
- Toutes les associations, qu’on a vu, sont binaires
- C’est-à-dire, elles relient au plus deux classes
- On peut aussi utiliser des associations ternaires voire n-aires
---
### Exemple d'association ternaire
Toute association non-binaire peut être transformée en un ensemble
d’associations binaires.<!-- .element: class="fragment" -->
---
## Quatre associations particulières
- héritage
- agrégation
- composition
- dépendance
---
## L'héritage, quand?
- Lorsque deux ou plusieurs classes partagent plusieurs attributs(et méthodes)
- Lorsqu’une `Classe1` est une sorte de `Classe2`
---
### Exemple
- Un enseignant a un nom, un prénom, une date de naissance, un salaire et une date de recrutement
- Un étudiant a aussi un nom, un prénom, une date de naissance et un niveau
- Sémantiquement, enseignant et étudiant sont une sorte de personne
- En plus, les deux partagent plusieurs attributs tels que nom, prénom et date de naissance
- Donc, on peut mettre en commun les attributs nom, prénom, date de naissance dans une classe Personne
- Les classes `Étudiant` et `Enseignant` hériteront de la classe `Personne`
---
## L'héritage, pourquoi?
Pour :
- réutiliser le code
- éviter la duplication de constituants (attributs, méthodes)
### Comment faire l’héritage en UML?
---
#### Étape 1 : Mettre les propriétés en commun (`nom`, `prénom` et `dateNaissance`) dans une nouvelle classe `Personne`
----
#### Étape 2 : Relier par une flèche les deux classes `Étudiant` et `Enseignant` à la Classe `Personne`
---
# Terminologie
- La classe `Personne` est appelée : classe mère, super classe, classe parente, classe racine...
- Les classes `Étudiant` et `Enseignant` sont appelées : classes filles, sous-classes, classes dérivées...
- On dit aussi que les classes `Étudiant` et `Enseignant` héritent de la Classe `Personne`
---
# L'héritage, pourquoi?
- Représenter l’ordre naturel des classes (hiérarchie)
- Organiser sémantiquement et symboliquement les classes
- Spécifier ou généraliser une classe
<br>
<br>
## Qu’est ce que la généralisation ?<!-- .element: class="fragment" -->
- ajouter une classe au dessus d’une autre<!-- .element: class="fragment" -->
<br>
<br>
## Qu’est ce que la spécialisation ?<!-- .element: class="fragment" -->
- ajouter une classe au dessous d’une autre<!-- .element: class="fragment" -->
---
# L'héritage : propriétés
- **Transitivité** : si A hérite de B et B hérite de C, alors A hérite de C
- **Non-réflexif** : une classe n’hérite pas d’elle même
- **Non-symétrique** : si A hérite de B, alors B n’hérite pas de A
- **Non-cyclique** : si A hérite de B et B hérite de C, alors C ne peut hériter de A
---
## Qu’est ce que l’héritage multiple?
- le fait d’hériter de plusieurs classes au même temps
## L'héritage multiple, est-il possible?
- autorisé par certains LOO comme : OCaml, Eiffel...
- interdit par certains autres : PHP, Java...
---
### Quel problème peut poser l’héritage multiple?
Un problème de confusion (nommage) : si une classe A hérite de deux
classes B et C qui ont un attribut ou une méthode en commun
<br>
<br>
### Les LOO qui interdisent l’héritage multiple proposent soit<!-- .element: class="fragment" -->
- les interfaces (PHP, Java, C#, TypeScript...)<!-- .element: class="fragment" -->
- les traits (PHP)<!-- .element: class="fragment" -->
- l’héritage virtuel (C++)<!-- .element: class="fragment" -->
---
# En Java
- Une classe mère peut-elle accéder aux attributs de sa classe fille?
- Une classe mère peut-elle avoir plusieurs classes filles?
- Deux classes héritant la même classe peuvent-elles avoir un attribut qui n’est pas dans la classe mère ?
- Une classe fille peut-elle avoir comme uniques attributs et méthodes ceux de la classe mère ?
---
# Remarque
- Dans certains LOO comme Java, C#..., toutes les classes héritent d’une classe racine appelée `Object`
- `Object` offre plusieurs services tels que la conversion d’un objet en chaîne de caractères, le clonage...
- `Object` : cette classe racine n’existe pas en PHP...
---
----
# Questions
- Existera t-il une méthode (autre que le constructeur) dans un objet de type `Poche` ?
- La classe `Broché` n'a pas d'attribut propre, pourrait-elle être implémentée ?
- Pourrait-on ajouter une relation d'héritage entre `Poche` et `Article` ?
- Un livre peut-il être `Broché` et de `Poche` ?
---
# L'agrégation
- C’est une association non-symétrique
- Modélisée par un losange vide coté agrégat
- Elle représente une relation de type ensemble/élément
----
# Exemple d'agrégation
---
# La composition
- C’est une agrégation forte modélisée par un losange noir coté agrégat
- L’élément n’existe pas sans l’agrégat (l’élément est détruit lorsque l’agrégat n’existe plus)
- L’élément ne peut être en relation qu’avec un seul agrégat
----
# Exemple de composition
---
# Questions
- Si une pièce est détruite, les chaises associées devraient-elles également être détruites?
- Si une pièce est détruite, les portes associées devraient-elles également être détruites?<!-- .element: class="fragment" -->
- Si un bâtiment est détruit, les portes associées à ses pièces devraient-elles également être détruites ?<!-- .element: class="fragment" -->
- Si un bâtiment est détruit, les chaises associées à ses pièces devraient-elles également être détruites ?<!-- .element: class="fragment" -->
----
---
# La dépendance
- Une première classe utilise une deuxième sans que cette dernière soit un membre de la première
---
## Exercice 1
Les classes suivantes sont liées par une agrégation ou une composition?
- but et gardien de but
- voiture et moteur
- forêt et arbre
- paragraphe et ligne
- cinéma et salle
- salle et chaise
- enseignant et cours
---
## Exercice d’application 2
Identifier le type de relation (héritage, composition, agrégation, dépendance, instanciation) qui relie chacun des couples suivants :
- Corps et Cœur
- Ford et ConstructeurAutomobile
- Tracteur et Véhicule
- Rectangle et Carré
- Homme et homme
- Entier et Nombre
- ChaîneDeCaractères et Caractère
- Homme et Humain
---
# Résumer
----
- Une **association** est une relation entre deux classes de même niveau conceptuel (aucune des deux n’est plus importante que l’autre) (**uses a**)
- Une **agrégation** est une relation ensemble/élément (**has a**)
- Une **composition** est une relation ensemble/élément tel que l’élément n’existe plus si l’ensemble est détruit (**owns a**)
- L’**héritage** est une relation entre deux classes dont une pouvant récupérer toutes les propriétés de la deuxième (**is a**)
- Une **dépendance** est une relation entre deux classes dont une propriété de la première fait référence à la deuxième (**references a**)
---
# Multiplicité
#### Définition
Permet de définir le nombre minimum et maximum de relation que chaque objet de classe peut avoir avec un (ou plusieurs) objet d’une (ou plusieurs) autre classe.
<br>
<br>
:::info
Equivalent en MCD : cardinalité
:::
<!-- .element: class="fragment" -->
---
## Six multiplicités possibles avec UML
- 0\.\.1 : aucune ou au plus un objet
- 1 : exactement un seul objet [par défaut]
- 0\.\.* ou * : 0 ou plusieurs objets
- 1\.\.* : au moins un ou plusieurs objets
- x\.\.x ou x : exactement x objets
- m\.\.n : Au moins m et au plus n objets
---
## Exemple
- Une personne peut avoir zéro ou plusieurs adresses
- Une adresse appartient à une ou plusieurs personnes
---
### Exercice 1 : définir les cardinalités entre les deux classes suivantes
- Une voiture comporte plusieurs pneus
- Un pneu appartient à une seule voiture
----
### Exercice 2 : définir les cardinalités entre les deux classes suivantes
- Une voiture a un et un seul moteur
- Un moteur appartient à une seule voiture
----
### Exercice 3 : définir les cardinalités entre les deux classes suivantes
- Un étudiant est inscrit dans une et une seule université
- Une université a plusieurs étudiants
----
### Exercice 4 : définir les cardinalités entre les deux classes suivantes
- Un livre est écrit par un ou plusieurs auteurs
- Un auteur a écrit un ou plusieurs livres
----
### Exercice 5 : définir les cardinalités entre les deux classes suivantes
----
### Exercice 6 : définir les cardinalités entre les deux classes suivantes
---
# La classe d'association
#### Etant donné l'exemple suivant
#### Question
Où peut-on placer la `quantitéCommandée` ?
---
### Dans `Article` ?
#### Impossible
<!-- .element: class="fragment" -->
Ainsi, une seule `quantitéCommandée` pour tous ceux qui commandent le même article.
<!-- .element: class="fragment" -->
---
### Dans `Commande` ?
#### Impossible aussi
<!-- .element: class="fragment" -->
Ainsi, une seule `quantitéCommandée` pour tous les articles d’une
même commande.
<!-- .element: class="fragment" -->
---
### Conclusion
La `quantitéCommandée` ne peut être, ni dans `Article` ni dans `Commande`.
##### Solution : créer une classe d'association
<!-- .element: class="fragment" -->
<!-- .element: class="fragment" -->
---
# Polymorphisme
#### Définition
- En grec : prendre plusieurs formes
- En POO : possibilité de définir plusieurs méthodes avec le même nom
- même si la même méthode existe dans la classe mère avec la même signature
- même si une méthode avec le nom existe dans la classe mais avec une signature différente
---
### Surcharge (overload)
- Définir dans une classe plusieurs méthodes portant le même nom et avec des signatures différentes
- Autorisée en Java mais pas par tous les LOO (comme PHP...)
### Redéfinition
- Redéfinir une méthode, héritée, dans la classe fille
- Autorisée par tous les LOO (un des objectifs de l’héritage)
- La signature de la méthode redéfinie doit être identique à celle de la méthode héritée dans la classe mère
---
# Remarque
- Lorsqu’une méthode est appelée, le compilateur commence par regarder dans la classe de l’objet où la méthode a été appelée
- S’il la retrouve, il l’exécute
- Sinon il la repasse au niveau supérieure (classe mère directe)
---
# Classe abstraite
- C’est une classe qu’on ne peut instancier
- Par exemple, on sait qu’un être humain est soit homme soit femme. Donc, la classe Humain peut être déclarée abstraite.
---
### En UML, le nom d'une classe abstraite est écrit en italique
---
### Méthode abstraite
- C’est une méthode indéfinie (elle n’est pas implémentée)
- Si une classe contient une méthode abstraite, elle doit être aussi
déclarée abstraite
- Si une classe hérite d’une classe abstraite, alors elle doit implémenter les méthodes abstraites de cette dernière
<br>
<br>
### Remarque
- Certains LOO, comme le C++, permettent de proposer une implémentation par défaut pour les méthodes abstraite
---
## Classe finale
- C’est une classe qu’on ne peut hériter
<br>
<br>
## Méthode finale
- C’est une méthode que les classes filles ne peuvent redéfinir
---
# Les Interfaces
### Une interface (un contrat)
Une classe abstraite définie par le mot clé interface et dont toutes les méthodes sont abstraites.
En UML, une interface est schématisée ainsi :
---
### En UML, voici comment dire qu’une classe hérite d’une interface
---
## Remarques
- Une classe qui hérite d’une interface doit implémenter toutes ses méthodes
- Une classe peut hériter de plusieurs interfaces
- Une interface peut hériter d’autres interfaces
---
# Les contraintes avec UML
### Etant donné l'exemple suivant
----
#### Comment lire ça ?
- Une personne peut avoir le rôle d'enseignement dans une université<!-- .element: class="fragment" -->
- Une personne peut avoir le rôle d'étudiant dans une université.<!-- .element: class="fragment" -->
- _Mais, elle peut aussi avoir les deux rôles._<!-- .element: class="fragment" -->
---
# Les contraintes avec UML
__Pour indiquer qu'une personne ne peut avoir les deux rôles à la fois, on rajoute une contrainte.__
:::info
__xor__ : eXclusive OR (OU exclusif)
:::
<!-- .element: class="fragment" -->
---
# Les contraintes avec UML
##### Etant donné l'exemple suivant :
----
### Comment lire ça ?
- Une personne peut avoir le rôle d'employé dans une entreprise
- Une personne peut avoir le rôle de dirigeant dans une entreprise
- _Mais est-ce qu'une personne qui n'est pas employé dans cette entreprise peut la diriger ?_
- D'après ce diagramme de classes : ___oui___
---
# Les contraintes avec UML
#### Pour indiquer qu’une personne qui dirige une entreprise est forcément un de ses employés, on rajoute la contrainte suivante.
---
# Les contraintes avec UML
##### Etant donné l'exemple suivant
----
### Comment lire ça ?
- Un client peut avoir 1 ou plusieurs comptes bancaires
- Un compte appartient à une ou deux clients 1..*
- _Mais comment dire que le solde de chaque compte peut être négatif mais sans dépasser la valeur maximale de découvert?_
---
# Les contraintes avec UML
#### Remarque
___Si on ajoute le nom d'association + les rôles, l'association deviendra trop dense et presque illisible.___
---
### Solution : utiliser OCL
- _Object Constraint Language_
- Initialement, un projet d’IBM
- Appartenant à UML depuis UML 1.1
- Langage formel d’expression
- Permettant de définir des contraintes sur les différents diagrammes d’UML, et en particulier le diagramme de classes
----
- Basé sur la théorie des ensembles et la logique des prédicats
- Permettant principalement d’exprimer 2 types de contraintes sur l’état d’un objet ou d’un ensemble d’objets
- Des invariants qui doivent être respectés en permanence
- Des pré et post-conditions pour une opération
---
#### Deux versions d’OCL
- OCL 1 : intégré dans UML 1.1 de l’OMG
- OCL 2 : intégré dans UML 2.0 et pouvant être généralisé sur d’autres modèles que ceux d’UML
---
### Avec OCL, les contraintes peuvent être définies un peu loin de l’association
##### Dans ce cas, il faut :
- préciser le contexte
- définir la contrainte
----
```
context Compte
inv : solde + valMaxDecouvert >= 0
```
##### Explication
- _context_ : indique l’élément concerné par la contrainte.
- _inv_ (pour invariant) : exprime une contrainte sur un élément qui doit être respectée en permanence.
---
#### On peut définir plusieurs contraintes
```
context Compte
inv : solde + valMaxDecouvert >= 0
context Compte::débiter(int somme)
pre : somme > 0 and solde + valMaxDecouvert >= somme
post : solde = solde@pre - somme
```
----
#### Explication
- _context_ : indique l’élément concerné par la contrainte (ici la méthode débiter ( ) de la Classe Compte).
- _pre_ : exprime une contrainte sur un élément qui doit être respectée pour que l’appel de la méthode soit valide.
- _post_ : exprime une contrainte sur un élément qui doit être respectée après l’appel de la méthode.
---
## 4 contraintes possibles pour les collections
- _Set_ : ensemble mathématique sans doublons et sans ordre.
- _Ordered_ : ensemble mathématique sans doublons et avec ordre.
- _Bag_ : ensemble mathématique avec possibilité de doublons et sans ordre.
- _Sequence_ : ensemble mathématique avec possibilité de doublons et avec ordre.
---
### Exemple 1 : un cours est composé d’une séquence ordonnée (sans doublons) de séances
----
### Exemple 2 : un fichierPPT contient une suite ordonnée (avec possibilité de doublons) de transparents
---
### Comment construire un diagramme de classe ?
#### Etapes
1. Préparer un dictionnaire de données.
2. Identifier les classes et conserver les classes pertinentes.
3. Identifier les associations et conserver les associations pertinentes.
4. Identifier les attributs.
5. Vérifier s’il est possible de simplifier en utilisant l’héritage.
6. Itérer et affiner le diagramme.
---
### Comment construire un diagramme de classe ?
#### Étape 1 : Préparer un dictionnaire de données
- Lire le texte.
- Extraire tout nom ou verbe pouvant participer à notre système d’information.
- Garder les synonymes tant qu’on n’a pas fini la lecture du texte.
- Vérifier que la liste ne contient pas de doublons.
---
### Comment construire un diagramme de classe ?
#### Étape 2 : Identifier les classes et conserver les classes pertinentes
- Éviter d’être trop sélectif.
- Ne pas chercher l’héritage à cette étape.
- Éliminer les classes redondantes, les synonymes, les classes vagues ou les classes sans lien avec le contexte.
---
### Comment construire un diagramme de classe ?
#### Étape 3 : Identifier les associations et conserver les associations pertinentes
- Justifier l’existence d’un cycle car c’est souvent redondant.
- Décomposer les associations n-aires en associations binaires.
- Vérifier si les associations définies par rapport aux classes filles peuvent être remontées à la classe mère.
---
### Comment construire un diagramme de classe ?
#### Étape 4 : Identifier les attributs
- Ne pas confondre attribut et classe.
- Ne pas pousser la recherche des attributs à l’extrême.
- Supprimer les synonymes.
- Faire attention aux attributs de classe association.
- Supprimer les attributs dérivé.
----
#### Source : UML 2 De l’apprentissage à la pratique de Laurent Audibert
Les attributs dérivés peuvent être calculés à partir d’autres attributs et de formules de calcul. Lors de la conception, un attribut dérivé peut être utilisé comme marqueur jusqu’à ce que vous puissiez déterminer les règles à lui appliquer.
Les attributs dérivés sont symbolisés par l’ajout d’un « / » devant leur nom.
---
### Comment construire un diagramme de classe ?
#### Étape 5 : Vérifier s’il est possible de simplifier en utilisant l’héritage
- Vérifier si certaines classes partagent certains attributs et/ou méthodes.
- Éviter les raffinements excessifs.
---
### Comment construire un diagramme de classe ?
#### Étape 6 : Itérer et affiner le diagramme
- Ne pas chercher un diagramme complet à la première passe.
- Faire des itérations continuelles.
- Vérifier le diagramme de classe après avoir fini les diagrammes d’états-transitions et de séquences.
- Revenir sur le diagramme de classe après avoir fini les diagrammes d’états-transitions et de séquences.
- Garder la possibilité de corriger des éventuelles anomalies du diagramme de classe pendant la phase de développement.
---
### Comment construire un diagramme de classe ?
#### Citation 1 : Jan van de Sneptscheut
La différence entre la théorie et la pratique, c’est qu’en théorie, il n’y a pas de différence entre la théorie et la pratique, mais qu’en pratique, il y en a une.
<br>
#### Citation 2 : Albert Einstein
La théorie, c’est quand on sait tout et que rien ne fonctionne. La pratique, c’est quand tout fonctionne et que personne ne sait pourquoi.
Ici, nous avons réuni théorie et pratique : Rien ne fonctionne... et personne ne sait pourquoi !
---
# Diagramme de cas d'Utilisation
---
1. Introduction
2. Le diagramme de contexte
3. Le diagramme de packages
4. Le diagramme de cas d’utilisation
5. Comment construire un diagramme de cas d’utilisation?
6. Exercices d’application
---
### Analyse et expression des besoins ?
- Un texte : long en taille (nombre de lignes, pages...), lent en temps (écriture ou lecture et compréhension)
- Un graphe (diagramme) : facile à comprendre, plus rapide à réaliser
----
### En UML 2, cela peut passer par plusieurs étapes
- Un diagramme de contexte
- Un diagramme de package
- Un diagramme de cas d’utilisation général
- Un diagramme de cas d’utilisation détaillé
---
### Diagramme de contexte
- Premier diagramme à faire pendant la phase d’analyse
- Ne faisant pas partie des 14 diagrammes UML
- Permettant de définir
- le système à modéliser
- les différents acteurs qui vont interagir avec le système
---
### Système?
- futur logiciel (ou application)
- ensemble de services ou de fonctionnalités
----
### Acteur?
- les utilisateurs de système
- ce n’est ni les développeurs ni les concepteurs ni les testeurs de système
- ce n’est pas forcément une personne physique
---
## Comment représenter un système ?
---
## Deux représentations possibles d’un acteur en UML
### Remarque
Pas besoin d’un stéréotype __«actor»__ dans la première représentation.
---
### Exemple : considérons un système d'achat et de vente en ligne
Les différents acteurs possibles sont :
- Client
- Vendeur
- Administrateur
- Banque
----
---
## Deux types d’acteurs en UML
- Principal : un acteur agissant directement sur le système
- Secondaire : un acteur sollicité par le système
## Revenant à notre exemple
- Tous les acteurs sauf la banque sont des acteurs principaux
- La banque est un acteur secondaire (sollicité par notre système pour valider le paiement)
---
## Représentation d’acteurs secondaires en UML
On utilise le stéréotype __«secondary»__ sur les fonctionnalités liées aux acteurs secondaires
---
### Le diagramme de contexte de l’exemple précédent en précisant les acteurs secondaires
---
## Diagramme de packages
- Diagramme de structure d’UML (statique)
- Permettant de rassembler un ensemble d’éléments (classes, fonctionnalités, fichiers...) sémantiquement proche
- Pouvant être vu comme un ensemble de dossier (physique ou logique) + les relations de dépendances entre eux
---
### Comment visualiser un package en UML?
### Exemple
En UML, un package = un répertoire (un dossier) sous Windows
---
### Si on décompose notre exemple en packages
---
### On peut définir des relations de dépendances entre les packages
---
## Pour obtenir le diagramme de packages, il faut
- remplacer les packages dans la partie Système du diagramme de contexte
- connecter les acteurs et les packages selon les droits
---
### Étape 1 : remplacer les packages dans la partie Système du diagramme de contexte
---
### Étape 2 : connecter les acteurs et les packages aux selon les droits
---
## Le diagramme cas d’utilisation
- un diagramme dynamique d’UML
- parmi les diagrammes les plus importants
- permettant de détailler le diagramme de package en remplaçant les packages par une liste des fonctionnalités (appelées cas d’utilisation)
## Dans certains cas, on peut créer
- un diagramme de cas d’utilisation général (Jacobson conseille de ne pas dépasser 25 cas d’utilisation par diagramme)
- un diagramme de cas d’utilisation détaillé pour (chaque) package
---
## Mots-clés associés
- acteur
- cas d’utilisation
- dépendance
- héritage
---
## Cas d’utilisation
- fonctionnalité fournie par le système
### Comment visualiser un cas d’utilisation en UML?
### Exemple
---
## Diagramme de cas d’utilisation
= contexte + acteurs + cas d’utilisation + associations
---
## Un acteur peut être en relation avec plusieurs cas d’utilisation
---
## Ajoutons les cas d’utilisation de tous les acteurs de notre exemple précédent
---
## Relations entre cas d’utilisation
- dépendance
- inclusion
- extension
- héritage
---
## La relation _include_
Si le cas B inclut le cas A, alors A est une partie obligatoire de B.
---
## La relation _extend_
Si le cas B étend le cas A, alors B est une partie optionnelle de A.
---
## La relation d’héritage
Un cas A est une généralisation d’un cas B si B est un cas particulier de A.
---
## Le diagramme de cas d’utilisation de notre exemple
:::danger
Pas d’ordre chronologique dans un diagramme de cas d’utilisation.
:::
---
## Relations entre acteurs : héritage
- Un acteur A hérite d’un acteur B si l’acteur A peut faire tout ce que l’acteur B a le droit de faire
- Tous les cas d’utilisation accessibles à B le sont aussi à A (la réciproque est fausse)
----
## Revenant à l’exemple précédent
- Si on suppose que le vendeur a aussi passer des commandes et commenter les articles
- Alors le vendeur peut hériter de client
----
## Nouveau diagramme de cas d’utilisation
---
## Comment construire un diagramme de cas d'utilisation
- Identifier les acteurs et les classifier
- Trouver les cas d'utilisation (et les classifier en package)
- Établir les relations entre les cas d’utilisation et les acteurs
- Identifier les relations de dépendance entre les cas d’utilisation
- Vérifier s’il est possible de simplifier le diagramme avec la relation d’héritage
- Identifier les cas d’utilisation les plus complexes pour les détailler avec les diagrammes de séquence et d’activité
---
----
## Exercice 1
- Le système permet-il au client de payer ses commandes ?
- Le système permet-il au client de suivre ses commandes ?
- Le client est-il obligé de valider son panier avant de payer?
- Le client est-il obligé de valider son panier pour passer sa commande ?
---
## Exercice 2
- Déterminer le diagramme de cas d’utilisation d’un distributeur de billets.
- On considère le scénario où le client désire retirer de l’argent en euro ou en dollar, bien sûr, cela nécessite une authentification.
- Il faut aussi traiter le cas où le stock de billet et/ou le solde sont insuffisants.
- Le client peut, s’il le désire, imprimer un récépissé.
<!-- ---- ## Solution Possible  -->
---
## Exercice 3
- Déterminer le diagramme de cas d’utilisation d’une caisse enregistreuse.
- Le caissier enregistre les articles. Ensuite, pour payer, il faut signaler la fin de vente.
- Une fois que la fin de vente est signalée, il est possible d’utiliser un bon de réduction.
- Trois modes de paiement sont autorisés : liquide, chèque et carte bancaire. Ce dernier nécessite de contacter le centre d’autorisations bancaires.
- Pour chaque vente, et après paiement, il faut transmettre les infos au gestionnaire de stock.
<!-- ---- ## Solution Possible  -->
---
# Diagramme états-transitions
---
## Plan
1. Introduction
2. État
3. Évènement
4. Transition
5. Condition de franchissement
6. Point de décision
7. Point de jonction
8. États Imbriqués
9. Comment construire les diagrammes états-transitions?
10. Exercices d’application
---
## Diagramme états-transitions?
- Un diagramme dynamique d’UML
- Permettant de représenter les différents états qu’un objet peut avoir et les transitions d’un état vers un autre
- Utilisant des automates déterministes à états-finis
- un graphe orienté
- déterministe : il y a toujours un chemin d’un état initial vers un état final
- états-finis : le nombre d’états est fini
---
## Un diagramme états-transitions pour chaque objet?
Non, que pour les classes ayant un comportement temporel significatif pour le système
### Exemples
- Livre (emprunté, disponible, réservé...) et Emprunteur (autorisé, bloqué, sanctionné...) dans un système de gestion de bibliothèque
- Article (disponible, vendu, expédié, livré...) dans un système de vente et achat en ligne
---
# Mots-clés associés
- état
- évènement
- transition
- condition de franchissement
- point de décision
---
# État
Abstraction de valeurs d’un objet
__Comment représenter un état en UML 2?__
__Exemple : un livre peut avoir un état disponible__
---
### Un objet de type __Livre__ peut avoir plusieurs états
Tout objet a un état initial (schématisé différemment)
Et un état final (schématisé aussi différemment)
---
## Un objet peut avoir
- plusieurs états
- état initial : lorsqu’un objet est créé, il a cet état initial.
- état final : lorsqu’un objet a cet état, il ne peut plus changer d’état.
:::danger
### Question
Comment passer d’un état à un autre?
:::
---
# Évènement
- Occurrence ou fait ayant lieu à un moment donné
- Générant un changement d’état chez l’objet
- Pouvant être
- appel d’une méthode
- signal
- changement temporel
---
## Exemple d’évènements pour un objet de type __Livre__
- Demande d’emprunt
- Enregistrement de retour
---
## Transition
- Le passage d’un état vers un autre suite à un évènement
- Pouvant être automatique si on ne précise pas l’événement déclencheur
- Représenté en UML par une flèche (arc)
---
### États + transition + évènement
### Exemple
---
## Plusieurs transitions entre deux états
---
## Remarques
:::warning
- D’après notre système, toute demande d’emprunt de livre est acceptée
- Dans le monde réel, il faut vérifier certaines conditions avant d’emprunter un livre
- Par exemple, il ne faut pas dépasser un nombre maximum d’emprunts par emprunteur
:::
## Solution
Définir des conditions de franchissement
---
## Condition de franchissement (ou de garde)
- une transition peut avoir une condition
- expression booléenne exprimée en langage naturelle(mathématique, logique...)
- évaluation uniquement lorsque l’événement se produit
- si l’expression est fausse => la transition ne s’effectue pas
- sinon, la transition s’effectue
- placée entre crochet `[condition(s)]`
---
## États + transition + évènement + condition de franchissement
## Exemple
---
### En réunissant tous les éléments précédents, on obtient le diagramme états-transitions suivant
---
## On peut même définir un contexte pour notre diagramme
---
# Hypothèse
Supposant qu’au retour d’un livre, le livre peut avoir deux états différents
- correct : on le remet à disponible
- autre (mouillé, déchiré...) : le livre doit être réparé
## Dans ce cas, on a un évènement et deux conditions complémentaires
Solution : utiliser les points de décision
---
# Point de décision
- Permettant de préciser sur quel état il faut aller quand l’évènement est déclenché et que la condition de franchissement soit vraie ou fausse
- Modélisé en UML 2 par un losange ayant une entrée et au moins deux sorties
---
## États + évènement + transitions + condition de franchissement + point de décision
----
## États + évènement + transitions + condition de franchissement + point de décision
---
# Exemple
---
## Remarques
- Lorsque l’évènement est déclenché, il faut que les conditions de franchissements couvrent tous les cas possibles
- Il est possible d’avoir plusieurs conditions différentes sur le même point de décision
---
## Point de jonction
- nœud permettant de partager certains transitions et de rendre le diagramme plus lisible
- Permettant de préciser sur quel état il faut aller quand l’évènement est déclenché et que la condition de franchissement soit vraie ou fausse
- Modélisé en UML 2 par un cercle plein
- Pouvant avoir une ou plusieurs entrée(s) et une ou plusieurs sortie(s)
---
# Exemple
---
### Intérêt des points de jonction
Source : __UML 2 de l’apprentissage à la pratique__ de Laurent Audibert
---
## Il est possible d'imbriquer les états
---
# Terminologie
- L’état _Disponible_ : état composite
- Les états _Commandé_, _Réparé_, _Livré_ et _Rangé_ : états imbriqués
---
# Étapes
- Identifier les classes ayant un comportement temporel significatif
- Déterminer les différents états de chaque objet de la liste précédente
- Trouver les évènements et les conditions de franchissement
- Élaborer le diagramme états-transitions
- Essayer de le simplifier avec les points de décision et les imbrications
---
# Remarques
:::danger
Chaque état doit avoir :
- une transition entrante
- une transition sortante
:::
---
## Exercice 1
- On est dans le case d’un système de gestion d’emprunt de livre pour une bibliothèque interne d’une entreprise. Le but de cet exercice est d’élaborer un diagramme états-transitions pour un objet de type Livre ayant les états suivants : disponible, réservé, emprunté, en réparation).
----
- Vérifier les conditions suivantes
- tout employé, dont le nombre d’emprunt et réservation n’a pas dépassé le nombre max, peut réserver un livre si ce dernier a un état disponible.
- un livre peut rester 24 heures sous réservation, s’il n’a pas été emprunté il reprendra son état disponible. Sinon il passe à l’état emprunté.
----
- Vérifier les conditions suivantes
- lors d’un retour, si la date de retour prévue n’a pas été respectée ou si le livre retourné est dans un état inacceptable, l’employé sera sanctionné. Il n’a donc plus le droit d’emprunter pour une durée bien déterminée
- un livre retourné dans un état inacceptable est soit réparable (délai de réparation = 15 jours), après réparation, il sera disponible, soit irréparable et dans ce cas il passe à l’état final
---
## Exercice 2
- En se basant sur l’exercice 1, élaborer un diagramme états-transitions pour un objet de type Employé ayant les états suivants : abonné, empruntant, sanctionné, bloqué
----
- Vérifier les conditions suivantes
- l’état de chaque employé n’ayant pas d’emprunt ou réservation encours est abonné
- après un certain nombre de sanction, un employé, qui n’a pas d’emprunt encours, n’a plus le droit d’emprunter ni de réserver de livre, il arrive donc à son état final
- un employé, ayant atteint le nombre max de sanction et ayant des emprunts encours, a l’état bloqué tant qu’il n’a pas retourné tous les livres empruntés. Lorsque cela est fait, il passe à l’état final
{"metaMigratedAt":"2023-06-15T20:05:38.631Z","metaMigratedFrom":"YAML","title":"UML","breaks":false,"description":"Formation UML","robots":"noindex, nofollow","slideOptions":"{\"theme\":\"white\",\"transition\":\"slide\",\"slideNumber\":true,\"previewLinks\":true,\"overview\":true,\"width\":1366,\"height\":768}","contributors":"[{\"id\":\"35198f6d-8c66-4636-8d98-b19eb0b4c48c\",\"add\":80279,\"del\":11849}]"}