Keine Cache-Version
Caching deaktiviert Standardeinstellung für diese Seite:aktiviert (code LNG204)Wenn die Anzeige zu langsam ist, können Sie den Benutzermodus deaktivieren, um die zwischengespeicherte Version anzuzeigen.
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.
Deutsche Übersetzung
Sie haben gebeten, diese Seite auf Deutsch zu besuchen. Momentan ist nur die Oberfläche übersetzt, aber noch nicht der gesamte Inhalt.Wenn Sie mir bei Übersetzungen helfen wollen, ist Ihr Beitrag willkommen. Alles, was Sie tun müssen, ist, sich auf der Website zu registrieren und mir eine Nachricht zu schicken, in der Sie gebeten werden, Sie der Gruppe der Übersetzer hinzuzufügen, die Ihnen die Möglichkeit gibt, die gewünschten Seiten zu übersetzen. Ein Link am Ende jeder übersetzten Seite zeigt an, dass Sie der Übersetzer sind und einen Link zu Ihrem Profil haben.
Vielen Dank im Voraus.
Dokument erstellt 30/10/2006, zuletzt geändert 07/03/2020
Quelle des gedruckten Dokuments:https://www.gaudry.be/de/uml-class-diagram.html
Die Infobro ist eine persönliche Seite, deren Inhalt in meiner alleinigen Verantwortung liegt. Der Text ist unter der CreativeCommons-Lizenz (BY-NC-SA) verfügbar. Weitere Informationen auf die Nutzungsbedingungen und dem Autor.
Aufzeichnungen
- ↑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).
Referenzen
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)
Diese Verweise und Links verweisen auf Dokumente, die während des Schreibens dieser Seite konsultiert wurden, oder die zusätzliche Informationen liefern können, aber die Autoren dieser Quellen können nicht für den Inhalt dieser Seite verantwortlich gemacht werden.
Der Autor Diese Website ist allein dafür verantwortlich, wie die verschiedenen Konzepte und Freiheiten, die mit den Nachschlagewerken gemacht werden, hier dargestellt werden. Denken Sie daran, dass Sie mehrere Quellinformationen austauschen müssen, um das Risiko von Fehlern zu reduzieren.
