UML : Diagrammes de Classes

111
UML : Diagrammes de Classes Classes, attributs, opérations, méthodes, associations, généralisation, dépendance, interface, …

description

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. - PowerPoint PPT Presentation

Transcript of UML : Diagrammes de Classes

Page 1: UML : Diagrammes de Classes

UML : Diagrammes de Classes

Classes, attributs, opérations, méthodes, associations, généralisation,

dépendance, interface, …

Page 2: UML : Diagrammes de Classes

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.

Page 3: UML : Diagrammes de Classes

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

Page 4: UML : Diagrammes de Classes

La Classe : Notation

• Plusieurs notations possibles (normalement un rectangle).

Visual Studio 2005

Classe

Mode Esquisse

Classe

Mode Esquisse Visual Paradigm for UML

Page 5: UML : Diagrammes de Classes

La Classe abstraite : Notation

• Il existe une notation particulière pour les classes abstraites. Le nom de la classe apparaît en italique.

Page 6: UML : Diagrammes de Classes

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.

Page 7: UML : Diagrammes de Classes

Les Attributs : Représentation

Association

Association+

Texte

Texte

Page 8: UML : Diagrammes de Classes

Les Attributs : Visibilité

• En notation UML, les marques de visibilité sont :– « + » pour un attribut public – « - » pour un attribut privé

Page 9: UML : Diagrammes de Classes

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.

Page 10: UML : Diagrammes de 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}

Page 11: UML : Diagrammes de Classes

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;

Page 12: UML : Diagrammes de Classes

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

Page 13: UML : Diagrammes de Classes

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.

Page 14: UML : Diagrammes de Classes

Les Attributs : Notation pour le format Ligne d’association

– Les multiplicités possibles sont :

Classe référencée*

Zéro ou plus;plusieurs

Classe référencée1..*

Un ou plus

Classe référencée1..40

De 1 à 40

Classe référencée5

Exactement 5

Classe référencée3,5,8

Exactement 3,5 ou 8

Page 15: UML : Diagrammes de Classes

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.

Page 16: UML : Diagrammes de Classes

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

Page 17: UML : Diagrammes de Classes

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

Page 18: UML : Diagrammes de Classes

Les Attributs : Notation pour le format Ligne d’association

Page 19: UML : Diagrammes de Classes

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

Page 20: UML : Diagrammes de Classes

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

Page 21: UML : Diagrammes de Classes

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 { … }

Page 22: UML : Diagrammes de Classes

Symboles d’annotation : notes, commentaires, contraintes, …

ContrainteNote/Commentaire

Page 23: UML : Diagrammes de Classes

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}

Page 24: UML : Diagrammes de Classes

Opérations : NotationVisibilité 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()

Page 25: UML : Diagrammes de Classes

Opérations : Notation

Page 26: UML : Diagrammes de Classes

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 }

Page 27: UML : Diagrammes de Classes

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

Page 28: UML : Diagrammes de Classes

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.

Page 29: UML : Diagrammes de Classes

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

Page 30: UML : Diagrammes de Classes

Méthodes : Exemple

Utilisation d’une note pour le corps de la méthode

Page 31: UML : Diagrammes de Classes

Méthodes : Exemple

Utilisation de la documentation de l’opération

Page 32: UML : Diagrammes de Classes

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.

Page 33: UML : Diagrammes de Classes

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

Page 34: UML : Diagrammes de Classes

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

Page 35: UML : Diagrammes de Classes

Les Stéréotypes

Stéréotype Acteur

Stéréotype Boundary

Stéréotype Interface

Page 36: UML : Diagrammes de Classes

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 }

Page 37: UML : Diagrammes de Classes

Relations entre classes

• La généralisation• L’association• La composition et l’agrégation• La dépendance

Page 38: UML : Diagrammes de Classes

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.

Page 39: UML : Diagrammes de Classes

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.

Page 40: UML : Diagrammes de Classes

• L’association est représentée par une ligne continue.

• Les extrémités de l’association sont appelés rôles

L’association: Notation

rôles

Page 41: UML : Diagrammes de Classes

L’association: Notation• Les rôles peuvent avoir les caractéristiques optionnelles

suivantes :– Nom;– Multiplicité;– Navigabilité;– Chaîne de propriétés (contraintes).

Page 42: UML : Diagrammes de Classes

L’association: Notation

• Attention au sens de lecture

CMonitoring receive 0..* CPacket

CPacket is ordered

Page 43: UML : Diagrammes de Classes

L’association: Notation

• Attention au sens de lecture

CPacketIs received by 1CMonitoring

Page 44: UML : Diagrammes de Classes

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.

Page 45: UML : Diagrammes de Classes

Associations multiples : Notation

• Il peut exister plusieurs relations (associations) entre deux classes.

Page 46: UML : Diagrammes de 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.

Page 47: UML : Diagrammes de Classes

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

Page 48: UML : Diagrammes de Classes

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.

Page 49: UML : Diagrammes de Classes

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.

Page 50: UML : Diagrammes de Classes

Classes d’association : Notation

Une personne peut avoir un emploi dans plusieurs entreprises

Page 51: UML : Diagrammes de Classes

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.

Page 52: UML : Diagrammes de Classes

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

Page 53: UML : Diagrammes de Classes

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.

Page 54: UML : Diagrammes de Classes

Composition et Agrégation : Contre Exemple

Impossible !

Page 55: UML : Diagrammes de Classes

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.

Page 56: UML : Diagrammes de Classes

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.

Page 57: UML : Diagrammes de Classes

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

Page 58: UML : Diagrammes de Classes

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.

Page 59: UML : Diagrammes de Classes

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

Page 60: UML : Diagrammes de Classes

Dépendance : Notation

– Un paramètre/argument d’une méthode :

Page 61: UML : Diagrammes de Classes

Dépendance : Notation

– L’appel d’une méthode statique :

Page 62: UML : Diagrammes de Classes

Dépendance : Notation

– L’utilisation d’une variable membre/constante statique :

Page 63: UML : Diagrammes de Classes

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.

Page 64: UML : Diagrammes de Classes

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

Page 65: UML : Diagrammes de Classes

Notions avancées

• L’interface• Classes singleton• Classes et interfaces template

Page 66: UML : Diagrammes de Classes

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.

Page 67: UML : Diagrammes de Classes

Interface : Notation

• Une interface est représentée en UML par un petit cercle.

Symbole représentant l’interface

Page 68: UML : Diagrammes de Classes

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)

Page 69: UML : Diagrammes de Classes

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)

Page 70: UML : Diagrammes de Classes

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

Page 71: UML : Diagrammes de Classes

Interface : Notation

• La vision « utilisateur », « fournisseur » donne donc ceci :

Utilisateur de l’interface Fournisseur de l’interface(implémentation)

Interface

Page 72: UML : Diagrammes de Classes

Interface : Notation

• En UML 2.0, une nouvelle notation a été introduite pour les interfaces.

UML 1.0

UML 2.0Notation « Prise de courant » (socket)

Page 73: UML : Diagrammes de Classes

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.

Page 74: UML : Diagrammes de Classes

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

Page 75: UML : Diagrammes de Classes

Classes singletons : Notation

• Si l’outil ne le permet pas, il est possible de rajouter un stéréotype.

Page 76: UML : Diagrammes de Classes

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.

Page 77: UML : Diagrammes de Classes

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

Page 78: UML : Diagrammes de Classes

Classes et interfaces templates : Exemple

Page 79: UML : Diagrammes de Classes

Classes et interfaces templates : Notation

Interface template(montrée comme Décoration)

Classe template

Page 80: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs : Introduction

• Une chaîne de montage avec des capteurs.

Capteurs

Page 81: UML : Diagrammes de Classes

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.

Page 82: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

Page 83: UML : Diagrammes de Classes

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.

Page 84: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

Page 85: UML : Diagrammes de Classes

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.

Page 86: UML : Diagrammes de Classes

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

Page 87: UML : Diagrammes de Classes

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

Page 88: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

Page 89: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

• CEtatCapteur a la connaissance des différents types de capteurs.

Page 90: UML : Diagrammes de Classes

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.

Page 91: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

Devient complexe !!!Utilisation de plusieurs

schémas

Page 92: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

Page 93: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

Page 94: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

Page 95: UML : Diagrammes de Classes

Exemple : Chaîne de montage avec capteurs

• Etc.. Etc...

Page 96: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : Introduction

ScriptConf tInterface e0no source-routingEndwrite

Hosts

10.12.1.25410.13.1.25410.34.1.254…

Page 97: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : 1ère classe

• Première classe : CScript

Page 98: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : 1ère classe

Page 99: UML : Diagrammes de Classes

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.

Page 100: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : 2ème classe

Page 101: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : 2ème classe

Utilisation d’un stéréotype pour le constructeur

Page 102: UML : Diagrammes de Classes

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

Page 103: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : Relation entre classes

Page 104: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : Relation entre classes

Page 105: UML : Diagrammes de 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.

Page 106: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : Besoin du réseau

Première solution : TcpClient comme attributDeuxième solution : TcpClient comme classe

Page 107: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : Besoin du réseau

Dépendance de CTask et TcpClient vis-à-vis de IPEndPoint

Page 108: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : Besoin du réseau

Page 109: UML : Diagrammes de Classes

Exemple : Script multi-routeurs : …

• Etc… Etc...

Page 110: UML : Diagrammes de Classes

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.

Page 111: UML : Diagrammes de Classes

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.