08.Diagrammes De Classes

Report
UML : Diagrammes de Classes
Classes, attributs, opérations,
méthodes, associations, généralisation,
dépendance, interface, …
Notions de base
•
•
•
•
•
La classe
Les attributs
Les symboles d’annotation
Les opérations
Les mots-clés, stéréotypes et propriétés.
La Classe : Définition
• Une classe est un classificateur
– Un classificateur UML est
un élément de modèle qui décrit des caractéristiques
structurelles et comportementales.
• Une « classe » peut être soit :
– une classe conceptuelle (‘abstraite’, au sens Analyse),
– une classe logique (indépendante d’un langage de
programmation),
– une classe physique (Java/ C#/ C++).
La Classe : Notation
• Plusieurs notations possibles (normalement
un rectangle).
Classe
Mode Esquisse
Visual Paradigm for UML
Classe
Mode Esquisse
Visual Studio 2005
La Classe abstraite : Notation
• Il existe une notation particulière pour les
classes abstraites. Le nom de la classe apparaît
en italique.
Les Attributs : Définition
• Les attributs d’une classe (également nommés
propriétés structurelles en UML) peuvent se
représenter de différentes façons :
– Texte, par exemple m_driver : CWifiDriver
– Ligne d’association
– Une combinaison des deux.
Les Attributs : Représentation
Texte
Association
Association
+
Texte
Les Attributs : Visibilité
• En notation UML, les marques de visibilité sont :
– « + » pour un attribut public
– « - » pour un attribut privé
Les Attributs : Type
Pour les types « classes », on utilisera de préférence une ligne
d’association afin de mieux visualiser les relations entre classes.
Les Attributs : Notation pour le format
Texte
• La syntaxe complète de la notation d’un attribut sous forme texte
est la suivante :
Visibilité nom : type [multiplicité] = défaut {chaîne de propriétés}
–
–
–
–
–
+
…
m_Driver : CWifiDriver [0..1] = null
m_Paquets : CPacket [0..*] {ordered}
m_Paquets : ListePackets {list, ordered}
DefTimeOut : integer = 20 {readonly}
• Les attributs sont supposés privés si aucune
visibilité n’est précisée.
– m_Paquets : CPacket [0..*] {ordered}
est équivalent à
– - m_Paquets : CPacket [0..*] {ordered}
Les Attributs : Notation pour le format
Texte
• UML permet d’employer la syntaxe de
n’importe quel langage de programmation
pour déclarer les attributs (pourvu que
l’utilisateur et/ou l’outil en soient informés).
–
–
–
–
- m_Delay : UInt32
- m_Packets : ArrayList = null
- m_Packets : List<CPacket> = null
private List<CPacket> m_Packets;
Les Attributs : Notation pour le format
Ligne d’association
• Pour les lignes d’associations, on a :
– Une flèche de navigabilité pointant de la source
(CMonitoring) vers l’objet cible (CWifiDriver)
indiquant que CMonitoring a un attribut qui est
une référence sur une instance de CWifiDriver
Les Attributs : Notation pour le format
Ligne d’association
• Pour les lignes d’associations, on a :
– Une indication de multiplicité du côté cible, mais
non du côté source.
Les Attributs : Notation pour le format
Ligne d’association
– Les multiplicités possibles sont :
*
1..*
1..40
5
3,5,8
Classe référencée
Zéro ou plus;
plusieurs
Classe référencée
Un ou plus
Classe référencée
De 1 à 40
Classe référencée
Exactement 5
Classe référencée
Exactement 3,5 ou 8
Les Attributs : Notation pour le format
Ligne d’association
• Pour les lignes d’associations, on a :
– Un nom de rôle (m_Driver) seulement du côté
cible pour mentionner le nom de l’attribut.
– Pas de nom d’association.
Les Attributs : Notation pour le format
Ligne d’association
• En résumé, une ligne d’association est définie
par :
– une flèche de navigabilité,
– un nom de rôle (optionnel), officiellement
appelée nom d’extrémité d’association, pour
indiquer le nom de l’attribut,
– une valeur de multiplicité,
– ainsi qu’une chaîne de propriétés telle que
{ordered} ou {list,ordered}.
Les Attributs : Notation pour le format
Ligne d’association
• Une chaîne de propriétés a la forme suivante :
– { <mot-clé> <mot-clé>* }
– Autrement dit, une suite de mots-clés situés à
l’intérieur d’accolades.
– Les mots-clés sont :
• soit définis par UML : ordered, unique, …
• soit définis par l’utilisateur : list (faisant référence à
l’interface List d’un langage orienté objet).
Les Attributs : Notation pour le format
Ligne d’association
Les Attributs : Format Texte vs Format
Ligne d’association
• Les types de données courants sont primitifs :
– Int, float, double, DateTime, Date, Color, string,
PhoneNumber, …
– Pour les attributs correspondants à ces types, on utilisera
de préférence la notation sous forme de texte.
• Pour les types de données définis par une classe, on
utilisera de préférence la notation sous forme de
ligne d’association.
– Permet de mieux visualiser les relations entre classes
(accentue les connexions).
Symboles d’annotation : notes,
commentaires, contraintes, …
• Les symboles d’annotation sont possibles dans
n’importe quel diagramme UML mais ils sont
particulièrement courants dans les diagrammes de
classes.
• Un symbole d’annotation a la forme d’un rectangle
au coin corné relié par une ligne pointillée à
l’élément annoté.
Symboles d’annotation : notes,
commentaires, contraintes, …
• Un symbole d’annotation peut représenter
plusieurs choses, par exemple :
– Une note ou un commentaire UML qui, par
définition n’a pas d’impact sémantique.
– Une contrainte UML, auquel cas elle doit être
placée entre accolades { … }
Symboles d’annotation : notes,
commentaires, contraintes, …
Contrainte
Note/Commentaire
Opérations : Notation
• Le format complet de la syntaxe officielle d’une
opération est le suivant :
Visibilité nom {liste de paramètres} {chaîne de propriétés}
• En UML 2.0, le type de retour a été supprimé
de la notation. Néanmoins, il est plus judicieux
de continuer à utiliser le format avec le type de
retour.
Visibilité nom {liste de paramètres} : type de retour
{chaîne de propriétés}
Opérations : Notation
Visibilité nom {liste de paramètres} : type de
retour {chaîne de propriétés}
• + StartCapture(delay : integer) : void
• + StartCapture(delay : integer)
• + StartCapture(delay)
• + StopCapture() : void
• + StopCapture()
• + GetCurrentPacket() : CPacket
• + SetInterface(name : string) : boolean
• - RetrieveInternalPacket()
Opérations : Notation
Opérations : Notation
• Les opérations sont considérées comme publiques
lorsque la visibilité n’est pas explicitement spécifiée.
• Les chaînes de propriétés contiennent des
informations supplémentaires arbitraires, par
exemple les exceptions qui doivent être lancées,
l’indication qu’une opération est abstraite, etc.
- InternalStartCapture() { Exception : InvalidInterfaceException }
Opérations : Notation
• Outre la syntaxe officielle des opérations, UML
permet d’écrire les signatures des opérations dans
n’importe quel langage, Java par exemple, pourvu
que le lecteur ou l’outil en soient informés.
– + StartCapture(delay : integer) : boolean { exception
InvalidInterfaceException }
– public bool StartCapture(int delay) throws
InvalidInterfaceException
Opérations vs Méthodes
• Une opération n’est pas une méthode. Une
opération UML est une déclaration, avec un nom,
des paramètres, un type de retour, une liste
d’exceptions et éventuellement un ensemble de
contraintes sous forme de pré- et de postconditions.
• Mais ce sont les méthodes qui sont les
implémentations.
Méthodes : Définition
• Une méthode UML est l’implémentation d’une
opération. Si des contraintes sont définies, la
méthode doit les satisfaire. Une méthode peut être
représentée de différentes façons :
– Dans les diagrammes d’interactions, par les détails et la
séquences des messages;
– Dans les diagrammes de classes, avec un symbole de note
UML assortie du stéréotype « méthod ».
Méthodes : Exemple
Utilisation d’une note pour le corps de la méthode
Méthodes : Exemple
Utilisation de la documentation de l’opération
Méthodes
• Lorsque nous utilisons une note UML pour
représenter une méthode, nous mélangeons
les vues statique et dynamique dans le même
diagramme.
• Le corps de la méthode, qui définit un
comportement dynamique, ajoute un élément
dynamique au diagramme de classes statique.
Les Mots-clés
• Un mot-clé UML permet de catégoriser un élément de
modèle avec du texte.
• Exemple : interface, abstract, actor, ordered, …
• La plupart des mots-clés sont placés entre guillements (UML
2.0) « … » comme « actor », « interface », …
• Certains figurent entre accolades { … }, comme {abstract} qui
est une contrainte.
– Généralement utilisés pour les chaînes de propriétés.
– Possibilité d’avoir des termes définis par l’utilisateur
Les Stéréotypes
• Un stéréotype représente un raffinement d’un
concept de modélisation existant.
– = Mécanisme d’extension
– Stéréotypes
• prédéfinis par UML (défini au sein d’un profil UML)
• ou définis par l’utilisateur
– Placés entre guillemets « … »
– Exemples :
• « interface », « actor », « boundary » pour les classes.
• « destroy » dans les diagrammes de séquences
Les Stéréotypes
Stéréotype
Acteur
Stéréotype
Boundary
Stéréotype Interface
Propriétés et Chaînes de propriétés
• En UML, une propriété est « une valeur nommée qui dénote
une caractéristique d’un élément ».
– Une propriété a un impact sémantique
– Peuvent être soit :
• Prédéfinies par UML : visibilité attr./opér.
• Définies par l’utilisateur
– Peuvent être présentées de nombreuses façons
• L’approche textuelle consiste à employer la chaîne de propriétés UML {
nom1 = valeur1, nom2 = valeur2 }
• Certaines propriétés n’ont pas de valeur (booléenne).
• Exemple : { abstract, visibility = public }
• Ou : { abstract = true, visibility = public }
Relations entre classes
•
•
•
•
La généralisation
L’association
La composition et l’agrégation
La dépendance
La généralisation : Notation
• En UML, on représente la généralisation (l’héritage) par une
ligne continue et une flèche formant un triangle blanc, allant
de la sous-classe vers la super-classe.
L’association: Notation
• L’association est souvent utilisée très tôt dans la modélisation
(modélisation du domaine) afin de montrer qu’il existe une
connexion entre deux classes et qu’il est important de la
mémoriser
(même
très
brièvement).
Par contre, l’association pourra dans l’application devenir :
– Une clé étrangère dans une table,
– Une référence vers un objet,
– …
• Nous n’aborderons pas ici l’association en temps qu’élément
abstrait de connexion. Nous le ferons lorsque nous verrons la
modélisation du domaine.
• Nous nous intéresserons uniquement à la notation.
L’association: Notation
• L’association est représentée par une ligne
continue.
rôles
• Les extrémités de l’association sont appelés
rôles
L’association: Notation
• Les rôles peuvent avoir les caractéristiques optionnelles
suivantes :
–
–
–
–
Nom;
Multiplicité;
Navigabilité;
Chaîne de propriétés (contraintes).
L’association: Notation
• Attention au sens de lecture
CPacket is
ordered
CMonitoring
receive 0..* CPacket
L’association: Notation
• Attention au sens de lecture
CMonitoring
Is received by 1
CPacket
L’association: Notation
• L’association peut être également nommée.
• Si aucune flèche n’est présente, la convention
consiste à lire de gauche à droite ou de haut en bas :
CMonitoring capture des paquets.
Associations multiples : Notation
• Il peut exister plusieurs relations (associations)
entre deux classes.
Associations qualifiées : Définition
• Une association qualifiée possède un
qualificateur qui sert à sélectionner un objet
(ou plusieurs) dans un ensemble plus vaste
d’objets apparentés.
• Du point de vue logique, cela se traduit par
une recherche sur une clé, par exemple, la
recherche d’objets dans une ArrayList.
Associations qualifiées : Notation
Catalogue produit sans association qualifiée
Catalogue produit avec association qualifiée (sur CodeArticle)
Qualificateur
Nouvelle multiplicité, reflétant la
sélection d’une seule instance
Associations qualifiées : Notation
• Normalement, le qualificateur est une
propriété de la classe cible. Il est possible
d’utiliser une classe implémentant la logique
de sélection.
Classes d’association : Définition
• Une classe d’association permet de traiter
une association comme une classe, et de la
modéliser avec des attributs, des opérations
et d’autres caractéristiques.
• En UML, cela est représenté par une ligne
pointillée joignant l’association et la classe
d’association.
Classes d’association : Notation
Une personne peut
avoir un emploi dans
plusieurs entreprises
Composition et Agrégation : Définition
• L’agrégation est un type d’association flou qui
suggère vaguement une relation tout-partie (à
l’instar
de
nombreuses
associations
ordinaires).
• Elle ne possède pas de sémantique distincte et
significative par rapport à une simple
association.
Composition et Agrégation : Définition
• La composition, également nommée agrégation composite, est une forme
plus contraignante d’agrégation tout-partie.
• Une relation de composition implique les contraintes suivantes :
– Une instance de la partie (par exemple doigt) appartient à seulement une
instance composite (par exemple main) à la fois.
– La partie doit toujours appartenir à un tout composite (pas de doigts flottant
librement dans l’air) .
– L’élément composite est responsable de la création et de la destruction de ses
composants, soit en réalisant l’opération lui-même, soit en collaborant avec
d’autres objets. De plus, si l’objet composite est détruit, ses composants
doivent l’être aussi (toujours pas de doigts flottant).
Composition et Agrégation : Exemple
CMonitoring crée une instance de CCapture afin d’y stocker les
paquets capturés. On a une relation d’agrégation par valeur
(composition).
CCapture est la
classe qui stocke et
détruit les paquets.
Détruire CCapture,
c’est détruire tous
les paquets stockés.
CMonitoring dépend de CPacket pour la création d’un nouveau paquet. Une fois
créé, le paquet est « délégué » à CCapture.
Composition et Agrégation : Contre
Exemple
Impossible !
Dépendance : Définition
• On peut utiliser des lignes de dépendances dans n’importe
quel type de diagrammes, mais elles sont particulièrement
courantes dans les diagrammes de classes et les diagrammes
de package.
• UML comprend une relation de dépendance générale qui
indique qu’un élément client (classe, package, cas
d’utilisation, …) a connaissance d’un autre élément
fournisseur, et que toute modification du fournisseur peut
affecter le client.
• Définition très large !
• La dépendance est représentée par une ligne pointillée et
fléchée allant du client au fournisseur.
Dépendance : Définition
• Il existe un grand nombre de types de dépendance logiciel
pour désigner la situation dans laquelle un élément est couplé
à une autre ou en dépend.
– Posséder un attribut du type du fournisseur;
– Envoyer un message au fournisseur. La visibilité vers le fournisseur
peut être :
• Un attribut, une variable paramètre, une variable locale, une variable
globale;
• ou une visibilité de classe : invocation de méthodes statiques.
– Recevoir un paramètre du type du fournisseur
– Le fournisseur est une super-classe ou une interface.
Dépendance : Notation
• Pour ce qui est d’une variable membre
(attribut), on utilisera plutôt l’association,
même si l’association est une forme de
dépendance.
Association
Dépendance : Notation
• Pour l’héritage, on utilisera plutôt la
généralisation, même si la généralisation est
une forme de dépendance.
Dépendance : Notation
• On utilisera plutôt la dépendance de classes
dans les cas suivants :
– Une variable locale d’une méthode :
Dépendance
Dépendance : Notation
– Un paramètre/argument d’une méthode :
Dépendance : Notation
– L’appel d’une méthode statique :
Dépendance : Notation
– L’utilisation d’une variable membre/constante
statique :
Dépendance : Notation
• Il est possible d’ajouter une étiquette portant
des mots-clés ou des stéréotypes.
Généralement utilisé pour faciliter la lecture.
Dépendance : Notation
• D’une façon générale, la dépendance sera utilisée
pour montrer le couplage entre deux éléments
lorsqu’il n’existe pas un lien sémantiquement plus
riche que la dépendance (ex : association,
agrégation, généralisation, …).
• On essaye également d’éviter la redondance; par
exemple, variable membre et variable locale 
seulement l’association (sauf dans des cas très
spécifiques).
Notions avancées
• L’interface
• Classes singleton
• Classes et interfaces template
Interface : Définition
• Une interface est un ensemble d’opérations (de
propriétés et d’ événement) définissant un contrat
entre une classe qui utilise l’interface et une classe
qui implémente l’interface.
• Nous avons donc :
– la définition de l’interface,
– l’implémentation de l’interface par une classe,
– l’utilisation de l’interface par une autre classe.
Interface : Notation
• Une interface est représentée en UML par un
petit cercle.
Symbole représentant
l’interface
Interface : Notation
• En UML, l’implémentation d’une interface se nomme
officiellement réalisation d’interface. Elle se matérialise soit
par un trait plein lorsque l’interface est affichée comme un
cercle.
Réalisation d’interface
(implémentation)
Interface : Notation
• Elle peut se matérialiser également par une ligne
discontinue et une flèche formant un triangle blanc.
Réalisation d’interface
(implémentation)
Interface : Notation
• En UML, le fait qu’une classe « utilise » une
interface, autrement dit requiert une interface
(interface requise), est schématisé avec une
relation de dépendance.
CNetworkEngine utilise l’interface sans
se soucier de qui l’implémente réellement
Interface : Notation
• La vision « utilisateur », « fournisseur » donne
donc ceci :
Fournisseur de l’interface
(implémentation)
Utilisateur de l’interface
Interface
Interface : Notation
• En UML 2.0, une nouvelle notation a été
introduite pour les interfaces.
UML 1.0
UML 2.0
Notation « Prise de
courant » (socket)
Classes singletons : Définition
• Singleton est un pattern que nous verrons plus
tard.
• Une classe singleton est une classe pour
laquelle il ne peut exister, à un moment
donné, qu’une seule instance de la classe,
jamais plus.
Classes singletons : Notation
• Avec la notation standard, on marque une
classe singleton avec un 1 dans le coin
supérieur droit de la classe.
1
Classes singletons : Notation
• Si l’outil ne le permet pas, il est possible de
rajouter un stéréotype.
Classes singletons : Remarque
• Par définition, une classe singleton ne peut
avoir qu’une seule instance à un moment
donné.
• Ne perdons pas de vue que la notion
d’instance est liée à un processus et que deux
processus différents pourraient chacun avoir
une instance d’une classe singleton.
Classes et interfaces templates :
Définition
• Les langages de programmation orientée objet
supportent des types templates, également
appelée types paramétrés ou types
génériques.
• Ils sont le plus communément employés pour
les types « collections » : ArrayList, LinkedList,
Collection, …
Classes et interfaces templates :
Exemple
Classes et interfaces templates :
Notation
Interface template
(montrée comme Décoration)
Classe template
Exemple : Chaîne de montage avec
capteurs : Introduction
• Une chaîne de montage avec des capteurs.
Capteurs
Exemple : Chaîne de montage avec
capteurs
• La chaîne de montage utilise différents capteurs :
après analyse, on se rend compte que deux types de
capteurs existent :
– les capteur binaires, du style interrupteur,
– et les capteurs linéaires qui renvoient une valeur
numérique (niveau de lumière, poids, …)
• On décide de créer des interfaces pour traduire les
fonctionnalités que doivent assumer ces différents
capteurs.
Exemple : Chaîne de montage avec
capteurs
Exemple : Chaîne de montage avec
capteurs
• Ensuite, on crée les classes qui vont
implémenter ces différentes interfaces.
Certaines classes supplémentaires
apparaissent afin d’encapsuler la complexité
de certains types de capteurs.
Exemple : Chaîne de montage avec
capteurs
Exemple : Chaîne de montage avec
capteurs
• Ensuite vient le cœur du système : la classe qui va
gérer les capteurs et vérifier leurs états. Cette classe
générera des événements lorsqu’une différence sera
détectée sur un des capteurs :
– par exemple, un changement On/Off pour un capteur de
style binaire,
– ou un changement de valeur pour un capteur linéaire.
Exemple : Chaîne de montage avec
capteurs
• Pour ce faire, la classe ‘cœur du système’ va
avoir besoin de mémoriser l’état courant de
chaque capteur. Le changement ne peut se
faire qu’en comparant la valeur courante et la
nouvelle valeur que renvoie le capteur.
• Comment mémoriser ces différents états (un
état par capteur) ?
Exemple : Chaîne de montage avec
capteurs
• Le choix se porte sur une seule classe mémorisant
l’état du capteur (hiérarchie également possible).
• La classe mémorisant l’état d’un capteur devra être
associée au capteur et offrir les méthodes de
vérification de changement.
• De plus, cette classe aura la connaissance de la
diversité des types de capteurs (binaires/linéaires).
Exemple : Chaîne de montage avec
capteurs
Exemple : Chaîne de montage avec
capteurs
• CEtatCapteur a la connaissance des différents
types de capteurs.
Exemple : Chaîne de montage avec
capteurs
• Maintenant, on peut passer au ‘cœur du
système’, autrement dit la classe qui va gérer
les différents capteurs.
• Cette classe aura besoin d’une liste de
CEtatCapteur et aura la connaissance de la
notion de capteur au plus haut niveau, c’est-àdire l’interface CCapteur.
Exemple : Chaîne de montage avec
capteurs
Devient complexe !!!
Utilisation de plusieurs
schémas
Exemple : Chaîne de montage avec
capteurs
Exemple : Chaîne de montage avec
capteurs
Exemple : Chaîne de montage avec
capteurs
Exemple : Chaîne de montage avec
capteurs
• Etc.. Etc...
Exemple : Script multi-routeurs :
Introduction
Script
Hosts
Conf t
Interface e0
no source-routing
End
write
10.12.1.254
10.13.1.254
10.34.1.254
…
…
Exemple : Script multi-routeurs :
1ère classe
• Première classe : CScript
Exemple : Script multi-routeurs :
1ère classe
Exemple : Script multi-routeurs :
2ème classe
• Une nouvelle classe va permettre de gérer un
routeur (un host) particulier et d’exécuter le
script sur ce host.
• Cette classe s’appellera CTask.
Exemple : Script multi-routeurs :
2ème classe
Exemple : Script multi-routeurs :
2ème classe
Utilisation d’un
stéréotype
pour le
constructeur
Exemple : Script multi-routeurs :
Relation entre classes
• Quelle est le type de relation entre les deux
classes ?
• Généralisation, association, composition, ... ?
• Composition : non, ce n’est pas réellement
une composition !
•  Association
Exemple : Script multi-routeurs :
Relation entre classes
Exemple : Script multi-routeurs :
Relation entre classes
Exemple : Script multi-routeurs :
Besoin du réseau
• CTask va devoir utiliser une classe afin
d’accéder au réseau.
• Plusieurs classes sont disponibles, telles que
TcpClient, Socket, …
• Le choix se porte sur la classe de plus haut
niveau, à savoir TcpClient.
Exemple : Script multi-routeurs :
Besoin du réseau
Première
Deuxièmesolution
solution: TcpClient
: TcpClientcomme
commeattribut
classe
Exemple : Script multi-routeurs :
Besoin du réseau
Dépendance de CTask et TcpClient
vis-à-vis de IPEndPoint
Exemple : Script multi-routeurs :
Besoin du réseau
Exemple : Script multi-routeurs : …
• Etc… Etc...
Diagrammes de classes :
Conclusion
• Dans notre exemple avec le script et les tâches, on
reste sur notre fin :
– Comment le script va-t-il lancer les différentes tâches ?
– Y aura-t-il un pool ou plusieurs pools de threads ?
– Comment les opérations vont-elles se déroulées ?
• Ces questions n’ont pas de réponses dans un
diagramme de classes car celui-ci montre
uniquement la partie statique de la solution.
Diagrammes de classes : Conclusion
• Le diagramme de classes montre la
constitution des classes et les relations qui
existent entre elles.
• Nous avons donc besoin d’un autre type de
diagramme pour montrer la dynamique,
l’enchaînement des opérations. Ce sont les
diagrammes d’interaction.

similar documents