Geen cache-versie.
Caching uitgeschakeld. Standaardinstelling voor deze pagina:ingeschakeld (code LNG204)Als het scherm te langzaam is, kunt u de gebruikersmodus uitschakelen om de cacheversie te bekijken.
UML : Les diagrammes de classes
Une classe est un concept qui reprend l'ensemble des propriétés (et non des valeurs de ces propriétés) communes à un ensemble d'éléments du domaine d'application ou de la machine.
Une classe est généralement une sorte de mode d'emploi, n'ayant pas d'existence propre. Le plus souvent, ce qui existe, ce sont les objets. Un objet est une entité réelle, qui correspond au mode d'emploi : nous retrouvons dans l'objet les attributs spécifiés dans la classe, et nous pouvons appeler sur l'objet les opérations (les méthodes) définies pour la classe.
Une classe est définie par son nom, ses attributs, et ses opérations. Nous représenterons donc la classe par un rectangle séparé en trois bandes horizontales.
[visibilité] attribut_2 [:type][=valeur initiale][{contrainte}]
...
[visibilité] attribut_n [:type][=valeur initiale][{contrainte}]
[visibilité] opération_2([[param:]type], ..., [[param:]type]) [:type]
...
[visibilité] opération_n([[param:]type], ...,[[param:]type]) [:type]
Nous pouvons dire que le diagramme de classe est un diagramme « statique » car il ne permet pas de représenter les aspects dynamiques et temporels de ses éléments.
Attributs
Chaque attribut comporte au minimum un nom. Si ce nom est souligné, cela signifie que la valeur de cet attribut est partagée par tous les objets de cette classe. Les autres renseignements sur l'attribut sont facultatifs.
La syntaxe complète des attributs est la suivante : [visibilité] nom [:type][=valeur initiale][{contrainte}], les éléments entre crochets étant facultatifs.
Visibilité
Le nom de l'attribut peut éventuellement être précédé par un type de visibilité (ou opérateur de visibilité), par exemple lors de la modélisation de classes d'un langage de programmation orienté-objet.
Exemples de type de visibilité en Java
Type
Nous pouvons faire suivre le nom de l'attribut par un double point et le type de l'attribut. Par exemple, nous pouvons avoir lastName : String, qui définit que les valeurs de l'attribut lastName sont de type String.
Multiplicité
Nous pouvons ensuite aussi spécifier une multiplicité entre crochets. Nous définissons alors soit une valeur unique, qui correspond au nombre exact de fois que cet attribut est présent, soit (aussi entre crochets) une valeur minimum et une valeur maximum.
Par défaut (quand nous ne renseignons pas de multiplicité) cela correspond à un attribut monovalué3 obligatoire.
Exemples de multiplicités
- [3] exactement 3 valeurs
- [0..1] de 0 à 1 valeur (quand nous avons un minimum égal à 0, l'attribut est facultatif) [0..*] de 0 à un nombre indéterminé
- [3..5] au moins trois valeurs et maximum 5
Valeur initiale
Nous pouvons spécifier la valeur que prendra cet attribut à la création d'un objet de cette classe.
Contrainte
Nous pouvons ajouter certaines contraintes entre accolades.
Par défaut les valeurs d'un attribut sont modifiables à la création d'un objet de cette classe. Si nous désirons pécifier que ces valeurs ne sont pas modifiables par la suite, nous pouvons ajouter la contrainte {frozen} après l'attribut dans le diagramme de classe.
Opérations
Chaque opération comporte au minimum un nom, suivi par des parenthèses. Les autres renseignements sur l'opération sont facultatifs.
Représentation
Par défaut, toute opération est concrète (c.a.d. qu'une implémentation existe au niveau de cette classe). Si nous désirons représenter une opération abstraite, nous devons écrire son nom en italique (et dans ce cas, la classe doit elle aussi être abstraite4).
Par défaut, toute opération est une opération d'instance (c.a.d. que nous devons avoir un objet de cette classe auquel nous pouvons demander d'exécuter l'opération). Si nous désirons représenter une opération de classe, nous devons souligner le nom. Cela signifie alors que nous pouvons demander à la classe elle-même d'effectuer l'opération, sans nécessairement devoir créer d'objet de cette classe.
Parties facultatives
La syntaxe complète des opérations est la suivante : [visibilité] nom ([[param:]type][,[param: ]*)[:type], les éléments entre crochets étant facultatifs.
Les valeurs que peut prendre la visibilité sont identiques aux valeurs de la visibilité des attributs.
Entre les parenthèses, nous pouvons retrouver des paramètres. Si ces derniers sont mentionnés, ce qui nous intéresse particulièrement est le type du paramètre, mais nous pouvons aussi spécifier le nom du paramètre avant son type.
Enfin, nous pouvons aussi spécifier, après la parenthèse fermante, le type de retour, qui est le type de la valeur renvoyée après un appel à cette opération.
Le diagramme de classe ne spécifie pas explicitement ce que fait l'opération; nous avons besoin pour cela d'un diagramme d'activité.
Interfaces
Nous avons aussi un type particulièr : l'interface, pour lequelle toutes les opérations (et les attributs5) ont une visibilité de type public. C'est tout à fait logique si nous considérons nos interfaces comme des « contrats » (tout dans le contrat doit être visible de tous) que les classes qui l'implémentent6 s'engagent à respecter. En UML, Une interface est un ensemble d'attributs et de méthodes publiques que des classes peuvent s'engager à fournir (“provide” ) ou exiger (“require” ) d'autres classes.
Nous représentons le fait que notre classe est une interface par le mot clé entre doubles chevrons ouvrants et fermants au dessus du nom. Nous pouvons aussi plus simplement représenter notre interface par un petit cercle ou un demi-cercle vide, mais nous ne devons pas oublier de mentionner son nom en dessous du cercle.
Nom
[+] opération_2([[param:]type], ..., [[param:]type]) [:type]
...
[+] opération_n([[param:]type], ...,[[param:]type]) [:type]
- Si la classe fournit (implémente) l'interface, nous le représentons par un cercle.
- Si la classe exige une interface, nous le représentons par un arc de cercle (un demi cercle vide) dans lequel peut se placer le cercle de l'interface de la classe qui fournit le service.
Nederlandse vertaling
U hebt gevraagd om deze site in het Nederlands te bezoeken. Voor nu wordt alleen de interface vertaald, maar nog niet alle inhoud.Als je me wilt helpen met vertalingen, is je bijdrage welkom. Het enige dat u hoeft te doen, is u op de site registreren en mij een bericht sturen waarin u wordt gevraagd om u toe te voegen aan de groep vertalers, zodat u de gewenste pagina's kunt vertalen. Een link onderaan elke vertaalde pagina geeft aan dat u de vertaler bent en heeft een link naar uw profiel.
Bij voorbaat dank.
Document heeft de 30/10/2006 gemaakt, de laatste keer de 07/03/2020 gewijzigd
Bron van het afgedrukte document:https://www.gaudry.be/nl/uml-class-diagram.html
De infobrol is een persoonlijke site waarvan de inhoud uitsluitend mijn verantwoordelijkheid is. De tekst is beschikbaar onder CreativeCommons-licentie (BY-NC-SA). Meer info op de gebruiksvoorwaarden en de auteur.
Notes
- ↑a,b UML : “Unified Modeling Language” (en français, « langage de modélisation unifié ») Plus d'informations sur UML.
- ↑ monovalué : une seule valeur
- ↑ Opération abstraite : Si la classe possède au moins une opération abstraite, nous sommes dans l'impossibilité de créer une unstance de cette classe (comment exécuter une méthode qui n'est pas implémentée ?). La classe doit donc dans ce cas être abstraite elle aussi.
- ↑ Interface et attribut : Une interface peut spécifier des attributs, mais comme toutes les parties de l'interface doivent avoir une vivibilité de type public et que nous avons l'habitude de restreindre la visibilité de nos attributs à private ou protected, nous ne les spécifierons normalement jamais dans nos interfaces.
- ↑ Implémentation versus héritage : Une sous-classe hérite d'une super-classe (elle reçoit quelque chose de la classe parent), mais elle implémente une interface (elle ne reçoit rien, et doit fournir une implémentation de ce qui est spécifié dans le contrat).
Referenties
IHDCB335 - AMSI : Patrick HEYMANS, Analyse et modélisation des systèmes d'information
(2009)
UML 2 Tutorial : Sparx Systems Pty Ltd., Class Diagram
UML Version 2.3 : Object Management Group, Inc., Infrastructure specification
(03/05/10)- UML Version 2.3 : Object Management Group, Inc.,
Superstructure specification
(05/05/10)
Deze verwijzingen en links verwijzen naar documenten die geraadpleegd zijn tijdens het schrijven van deze pagina, of die aanvullende informatie kunnen geven, maar de auteurs van deze bronnen kunnen niet verantwoordelijk worden gehouden voor de inhoud van deze pagina.
De auteur Deze site is als enige verantwoordelijk voor de manier waarop de verschillende concepten, en de vrijheden die met de referentiewerken worden genomen, hier worden gepresenteerd. Vergeet niet dat u meerdere broninformatie moet doorgeven om het risico op fouten te verkleinen.
