La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

UML : Diagrammes de Classes

Présentations similaires


Présentation au sujet: "UML : Diagrammes de Classes"— Transcription de la présentation:

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

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

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

4 La Classe : Notation Plusieurs notations possibles (normalement un rectangle). Classe Mode Esquisse Visual Paradigm for UML Classe Mode Esquisse Visual Studio 2005

5 La Classe abstraite : Notation
Il existe une notation particulière pour les classes abstraites. Le nom de la classe apparaît en italique.

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

7 Les Attributs : Représentation
Texte Association Association + Texte

8 Les Attributs : Visibilité
En notation UML, les marques de visibilité sont : « + » pour un attribut public « - » pour un attribut privé

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

10 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 à

11 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;

12 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

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

14 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ée 1..* Un ou plus Classe référencée 1..40 De 1 à 40 Classe référencée 5 Exactement 5 Classe référencée 3,5,8 Exactement 3,5 ou 8

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

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

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

18 Les Attributs : Notation pour le format Ligne d’association

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

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

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

22 Symboles d’annotation : notes, commentaires, contraintes, …
Note/Commentaire

23 Visibilité nom {liste de paramètres} {chaîne de propriétés}
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}

24 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()

25 Opérations : Notation

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

27 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

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

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

30 Utilisation d’une note pour le corps de la méthode
Méthodes : Exemple Utilisation d’une note pour le corps de la méthode

31 Méthodes : Exemple Utilisation de la documentation de l’opération

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

33 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

34 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

35 Les Stéréotypes Stéréotype Acteur Stéréotype Boundary
Stéréotype Interface

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

37 Relations entre classes
La généralisation L’association La composition et l’agrégation La dépendance

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

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

40 L’association: Notation
L’association est représentée par une ligne continue. Les extrémités de l’association sont appelés rôles rôles

41 L’association: Notation
Les rôles peuvent avoir les caractéristiques optionnelles suivantes : Nom; Multiplicité; Navigabilité; Chaîne de propriétés (contraintes).

42 L’association: Notation
Attention au sens de lecture CMonitoring receive 0..* CPacket is ordered CPacket

43 L’association: Notation
Attention au sens de lecture CMonitoring CPacket Is received by 1

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

45 Associations multiples : Notation
Il peut exister plusieurs relations (associations) entre deux classes.

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

47 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

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

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

50 Classes d’association : Notation
Une personne peut avoir un emploi dans plusieurs entreprises

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

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

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

54 Composition et Agrégation : Contre Exemple
Impossible !

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

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

57 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

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

59 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

60 Dépendance : Notation Un paramètre/argument d’une méthode :

61 Dépendance : Notation L’appel d’une méthode statique :

62 Dépendance : Notation L’utilisation d’une variable membre/constante statique :

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

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

65 Notions avancées L’interface Classes singleton
Classes et interfaces template

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

67 Interface : Notation Une interface est représentée en UML par un petit cercle. Symbole représentant l’interface

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

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

70 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

71 Fournisseur de l’interface
Interface : Notation La vision « utilisateur », « fournisseur » donne donc ceci : Fournisseur de l’interface (implémentation) Utilisateur de l’interface Interface

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

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

74 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

75 Classes singletons : Notation
Si l’outil ne le permet pas, il est possible de rajouter un stéréotype.

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

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

78 Classes et interfaces templates : Exemple

79 Classes et interfaces templates : Notation
Interface template (montrée comme Décoration) Classe template

80 Exemple : Chaîne de montage avec capteurs : Introduction
Une chaîne de montage avec des capteurs. Capteurs

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

82 Exemple : Chaîne de montage avec capteurs

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

84 Exemple : Chaîne de montage avec capteurs

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

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

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

88 Exemple : Chaîne de montage avec capteurs

89 Exemple : Chaîne de montage avec capteurs
CEtatCapteur a la connaissance des différents types de capteurs.

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

91 Exemple : Chaîne de montage avec capteurs
Devient complexe !!! Utilisation de plusieurs schémas

92 Exemple : Chaîne de montage avec capteurs

93 Exemple : Chaîne de montage avec capteurs

94 Exemple : Chaîne de montage avec capteurs

95 Exemple : Chaîne de montage avec capteurs
Etc.. Etc...

96 Exemple : Script multi-routeurs : Introduction
Conf t Interface e0 no source-routing End write Hosts

97 Exemple : Script multi-routeurs : 1ère classe
Première classe : CScript

98 Exemple : Script multi-routeurs : 1ère classe

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

100 Exemple : Script multi-routeurs : 2ème classe

101 Exemple : Script multi-routeurs : 2ème classe
Utilisation d’un stéréotype pour le constructeur

102 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

103 Exemple : Script multi-routeurs : Relation entre classes

104 Exemple : Script multi-routeurs : Relation entre classes

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

106 Exemple : Script multi-routeurs : Besoin du réseau
Deuxième solution : TcpClient comme classe Première solution : TcpClient comme attribut

107 Exemple : Script multi-routeurs : Besoin du réseau
Dépendance de CTask et TcpClient vis-à-vis de IPEndPoint

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

109 Exemple : Script multi-routeurs : …
Etc… Etc...

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

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


Télécharger ppt "UML : Diagrammes de Classes"

Présentations similaires


Annonces Google