Préface
Il existe de nombreux types de diagrammes UML, mais il n'est pas nécessaire de maîtriser tous les diagrammes UML pour mener à bien l'analyse et le travail de conception du système. D'une manière générale, dans les diagrammes UML, tant que vous maîtrisez l'utilisation des diagrammes de classes, des diagrammes de cas d'utilisation et des diagrammes de séquence, vous pouvez effectuer la plupart du travail . Autrement dit, si vous maîtrisez 20 % d’UML, vous pouvez faire 80 % des choses. Pour les programmeurs, le plus fréquemment utilisé est le diagramme de classes .
Table des matières
1. Qu'est-ce qu'un diagramme de classes ?
2. Représentation des classes dans les diagrammes de classes
Représenter des classes concrètes dans des diagrammes de classes UML
Représentation des classes abstraites dans les diagrammes de classes UML
Représentation des interfaces dans les diagrammes de classes UML
Représentation des packages dans les diagrammes de classes UML
4. Représentation des relations dans les diagrammes de classes
La différence entre l'agrégation et la composition dans le développement Java
1. Qu'est-ce qu'un diagramme de classes ?
Le diagramme de classes est le diagramme le plus couramment utilisé et le plus important dans la modélisation de systèmes orientés objet et constitue la base pour définir d'autres diagrammes. Le diagramme de classes est principalement un modèle statique utilisé pour afficher les classes, les interfaces du système ainsi que les structures statiques et les relations entre elles. Les éléments les plus fondamentaux d’un diagramme de classes sont les classes et les interfaces. Une fois que le concepteur du logiciel a conçu le diagramme de classes, le programmeur peut utiliser du code pour implémenter le contenu contenu dans le diagramme de classes.
2. Représentation des classes dans les diagrammes de classes
L'icône de classe se compose de trois parties : la première partie est le nom de la classe , la deuxième partie est les attributs et la troisième partie est l'opération.
- "+" signifie
public;- "-" signifie
private;- "#" signifie
protected;- Représenté sans symboles
default
Un nom de classe est unique dans son espace de noms. Les noms de classe commencent par une lettre majuscule , en omettant les espaces entre plusieurs mots.
Les propriétés et les opérations doivent être sans ambiguïté dans le cadre de la classe. Les attributs et les opérations commencent par une lettre minuscule , la première lettre des mots suivants est en majuscule et les espaces sont également omis.
- Format de spécification de propriété :
Nom de la propriété de visibilité : type[multiplicité] = default{property string}
- Format de spécification d'opération :
Nom de l'opération de visibilité (nom du paramètre : type) : valeur de retour {chaîne de propriété}
3. Représentation de classes concrètes, d'abstractions, d'interfaces et de packages dans des diagrammes de classes
Représenter des classes concrètes dans des diagrammes de classes UML
Une classe spécifique est représentée par une boîte rectangulaire dans le diagramme de classes. La boîte rectangulaire est divisée en trois couches : la première couche est le nom de la classe. Le deuxième niveau correspond aux variables membres de la classe ; le troisième niveau correspond aux méthodes de la classe. Les variables membres et les modificateurs d'accès avant les méthodes sont représentés par des symboles :
Représentation des classes abstraites dans les diagrammes de classes UML
Les classes abstraites sont également représentées par des cases rectangulaires dans les diagrammes de classes UML, mais les noms de classe et les noms de méthodes abstraites des classes abstraites sont représentés en italique.
Représentation des interfaces dans les diagrammes de classes UML
L'interface est également représentée par une boîte rectangulaire dans le diagramme de classes, mais ce qui est différent de la représentation de la classe est que l'interface est représentée par le constructeur « interface » en haut de la première couche du diagramme de classes. Ci-dessous se trouve le nom de l'interface. La deuxième couche est la méthode.
De plus, il existe une autre représentation de l'interface, communément appelée représentation en sucette, qui est une sucette (cercle + ligne continue) au-dessus de la classe. À côté du cercle se trouve le nom de l'interface et les méthodes d'interface apparaissent dans la classe d'implémentation.
Représentation des packages dans les diagrammes de classes UML
Les classes et les interfaces apparaissent généralement dans des packages. La représentation des packages dans les diagrammes de classes UML
4. Représentation des relations dans les diagrammes de classes
Il existe une certaine relation entre les classes, les classes et les interfaces, et les interfaces. Il existe généralement des connexions dans les diagrammes de classes UML pour indiquer les relations entre elles. Il existe six types de relations, à savoir les relations de mise en œuvre, les relations de généralisation, les relations d'association, les relations de dépendance, les relations d'agrégation et les relations de combinaison.
réaliser une relation
La relation d'implémentation fait référence à la relation entre l'interface et sa classe d'implémentation. Dans les diagrammes de classes UML, les relations d'implémentation sont représentées par des flèches composées de triangles creux et de lignes pointillées, pointant de la classe d'implémentation vers l'interface. Dans le code Java, les relations d'implémentation peuvent être directement traduites en mots-clés implements
relation de généralisation
La généralisation fait référence à la relation d'héritage entre les objets. Si la relation "est une" entre l'objet A et l'objet B est établie, alors il existe une relation d'héritage entre les deux. L'objet B est l'objet parent et l'objet A est l'objet enfant. Par exemple, si un employé avec un salaire annuel "est un" employé, il est évident qu'il existe une relation d'héritage entre l'objet Salaire de l'employé avec salaire annuel et l'objet Employé. L'objet Employé est l'objet parent et l'objet Salaire est l'objet enfant. objet.
Dans le diagramme de classes UML, la relation de généralisation est représentée par une flèche composée d'un triangle ouvert et d'une ligne continue, pointant de la classe enfant vers la classe parent. Dans le code Java, les relations généralisées entre les objets peuvent être directement traduites en mots-clés extends.
relation de connexion
L'association fait référence à la connexion entre des objets, qui permet à un objet de connaître les propriétés et les méthodes d'un autre objet. En Java, la représentation code d'une association est qu'un objet contient une référence à un autre objet. Autrement dit, si le code de classe d'un objet contient une référence à un autre objet, alors les deux objets sont associés.
Il existe une association à sens unique et une association à double sens. Si deux objets connaissent (c'est-à-dire peuvent appeler) les propriétés et opérations publiques de l'autre, alors les deux objets ont une association bidirectionnelle. Si un seul objet connaît (c'est-à-dire peut appeler) les propriétés publiques et les opérations d'un autre objet, alors il s'agit d'une association à sens unique. La plupart des associations sont des associations à sens unique, plus faciles à établir et à maintenir et qui aident à trouver des classes réutilisables.
Il existe également une auto-corrélation entre les deux associations
Dans les diagrammes UML, les relations bidirectionnelles sont représentées par des lignes pleines avec des doubles flèches ou des lignes doubles pleines sans flèches. Une association unidirectionnelle est représentée par une ligne continue avec une flèche pointant vers l'objet associé. C'est la navigation (Navigatity).
Ce qui suit indique que Employee est associé à TimeCard, qui est une association à sens unique.
Un objet peut contenir un tableau ou une collection d’autres objets. En UML, cela est représenté en plaçant une expression de multiplicité à la fin de la ligne d'association. Une expression de multiplicité peut être un nombre, une plage ou une combinaison de ceux-ci. Des exemples d'expressions autorisées par la multiplicité sont :
- Numéro : Quantité exacte
*Ou0..*: signifie 0 à plus0..1: représente 0 ou 1, souvent implémenté avec une référence nulle en Java1..*: Indique 1 à plusieurs
Les relations d'association sont divisées en trois types : association de dépendance, association d'agrégation et association combinée.
Dépendances
La relation de dépendance est une relation d’association faible. Si l'objet A utilise l'objet B, mais que la relation avec B n'est pas trop évidente, cette relation peut être considérée comme une relation de dépendance. Si l'objet A dépend de l'objet B, alors A "utilise a" B. Par exemple, la relation entre un conducteur et une voiture : lorsque le conducteur utilise la voiture, il existe une relation de dépendance entre les deux.
Dans le diagramme de classes UML, la relation de dépendance est représentée par une flèche en pointillé, pointant de l'utilisateur vers la partie utilisée, indiquant que l'objet utilisateur contient une référence à l'objet utilisé.
L'expression de code spécifique de la dépendance en Java est que B est une variable locale dans le constructeur ou la méthode de A , un paramètre d' une méthode ou d'un constructeur , la valeur de retour d'une méthode , ou A appelle une méthode statique de B.
Ci-dessous, nous utilisons le code Java présenté dans la liste de codes 1 et la liste de codes 2 pour démontrer la dépendance entre les objets et les objets.
代码清单1所示的B类定义了一个成员变量 field1，一个普通方法 method1() 和一个静态方法 method2()。
//代码清单1 B.java
public class B {
public String field1; //成员变量
public void method1() {
System.println("在类B的方法1中");
}
public static void method2() { //静态方法
System.out.println("在类B的静态方法2中");
}
}
代码清单2所示的A类依赖于B类，在A类中定义了四个方法，分别演示四种依赖形式。
/* 代码清单2 A.java
A依赖于B
*/
public class A {
public void method1() {
//A依赖于B的第一种表现形式：B为A的局部变量
B b = new B();
b.method1();
}
public void method2() {
//A依赖于B的第二种表现形式： 调用B的静态方法
B.method2();
}
public void method3(B b) {
//A依赖于B的第三种表现形式：B作为A的方法参数
String s = b.field1;
}
//A依赖于B的第四种表现形式：B作为A的方法的返回值
public B method4() {
return new B();
}
}relation d'agrégation
L'agrégation est un cas particulier de relation d'association. Elle reflète la relation de propriété entre le tout et la partie, c'est-à-dire la relation « a un ». A cette époque, le tout et les parties sont séparables. Ils peuvent avoir leurs propres cycles de vie ( tout comme les voitures et les pneus, lorsque la voiture est détruite, cela ne veut pas dire que les pneus sont également détruits ) . Les parties peuvent appartenir à plusieurs ensembles. Il peut également être partagé par plusieurs objets globaux, c'est pourquoi les relations d'agrégation sont souvent appelées relations de partage. Par exemple, dans la relation entre les services de l'entreprise et les employés, un employé peut appartenir à plusieurs services et si un service est retiré, les employés peuvent être transférés vers d'autres services.
Dans le diagramme UML, la relation d'agrégation est représentée par un losange creux plus une flèche pleine. Le losange creux est sur tout le côté et la flèche pointe vers le côté partie.
Relation de combinaison
La composition est également un cas particulier d'association. Elle incarne également la relation d'inclusion entre le tout et ses parties, c'est-à-dire la relation « contient un ». Mais à cette époque, le tout et la partie sont inséparables, et la partie ne peut pas être partagée avec d'autres touts. L'objet dans son ensemble est responsable du cycle de vie de l'objet partiel. Cette relation est plus forte que l’agrégation et est également appelée agrégation forte. En cas Ade combinaison B, Avous devez connaître Bla durée de vie qui peut être Aresponsable de la génération ou de la publication B, ou Aconnaître la génération et la publication d'une manière ou d'une autre B.
Par exemple, une personne contient une tête, un tronc et des membres, et leurs cycles de vie sont cohérents. Lorsqu’une personne naît, la tête, le tronc et les membres naissent en même temps. Lorsqu’une personne meurt, la tête, le tronc et les membres qui font partie du corps humain meurent en même temps.
Dans le diagramme UML, la relation de combinaison est représentée par un losange plein et une flèche pleine. Le losange plein est sur tout le côté et la flèche pointe vers le côté pièce.
La différence entre l'agrégation et la composition dans le développement Java
Sous forme de code Java, l'objet partiel dans la relation d'agrégation et de combinaison est une variable membre de l'objet global. Cependant, dans le développement d'applications réelles, il est parfois difficile de distinguer si la relation entre deux objets est une agrégation ou une combinaison. En Java, l'agrégation et la composition ne peuvent être distinguées du code de classe lui-même. S'il faut le distinguer, alors si une partie de l'objet doit être supprimée lors de la suppression de l'objet entier, alors il s'agit d'une relation de combinaison, sinon il peut s'agir d'une relation d'agrégation. D'un point de vue commercial, si l'objet dans son ensemble nécessite la participation de certains objets afin de remplir ses responsabilités, alors la relation entre les deux est une combinaison, sinon il s'agit d'une relation d'agrégation.
Par exemple, les voitures et les pneus, les voitures dans leur ensemble et les pneus en tant que pièces. S’il est utilisé dans un environnement commercial de vente de voitures d’occasion, il existe une relation d’agrégation entre les deux. Étant donné que le pneu fait partie intégrante de la voiture, lui et la voiture peuvent être produits séparément, puis assemblés et utilisés, mais la voiture peut être remplacée par des pneus neufs, et les pneus peuvent également être retirés pour être utilisés par d'autres voitures. Si elle est utilisée dans l'environnement commercial des systèmes de conduite, la voiture ne peut pas accomplir la tâche de conduite sans pneus. Il existe une relation combinée entre les deux. Un autre exemple est la relation entre les commandes et les articles de commande dans le secteur des librairies en ligne. Si la commande ne contient pas d'article de commande, l'activité de commande ne peut pas être complétée, la relation entre les deux est donc une combinaison. Quant à la relation entre le panier et le produit, étant donné que le cycle de vie du produit n'est pas contrôlé par le panier et que le produit peut être partagé par plusieurs paniers, il existe une relation d'agrégation entre les deux.