Comment montrer l'utilisation des méthodes statiques dans un diagramme de classes UML?
class A{
public static void test(){
}
}
class B{
public void b(){
A.test();
}
}
À quoi ressemblerait un diagramme de classes, qui montre la relation? UML 2.0 serait préparé, s'il y a une différence.
Pour montrer une méthode statique, vous soulignez le nom de la méthode statique - jetez un œil ici pour des informations plus détaillées.
Quant à naviguer dans cette relation; class B
dépend de l'existence de class A
. On peut dire que la classe B a une "dépendance d'utilisation" sur la classe A
class B ----uses----> class A
J'espère que cela t'aides.
@RobertMS a raison.
Une autre alternative consiste à utiliser les stéréotypes :
..............................................................
....+----------------------------------------------------+....
....| StringUtilityClass |....
....+----------------------------------------------------+....
....| [+] void: lowerCase() <<non virtual>> |....
....| [+] void: upperCase() <<non virtual>> |....
....| [+] String: toString() <<override>> |....
....+----------------------------------------------------+....
....| [+] String: LowerCaseCopy(String Value) <<static>> |....
....| [+] String: UpperCaseCopy(String Value) <<static>> |....
....| [+] String: ReverseCopy(String Value) <<static>> |....
....+----------------------------------------------------+....
..............................................................
Remarque Certaines bonnes pratiques en matière de langages de programmation, en particulier celles avec la syntaxe C
sensible à la casse, mettent en majuscule les fonctions statiques et laissent en minuscule le reste des fonctions.
À votre santé.
Pour afficher les méthodes et les attributs statiques, vous les soulignez dans un diagramme de classes UML: voir ML Distilled p.66 ou section 7.3.19 (Feature) du spécification UML Superstructure :
Les caractéristiques statiques sont soulignées.
Pour montrer la relation entre les classes B et A (où B utilise uniquement des méthodes statiques dans A), vous utilisez une dépendance, pas une association. Les associations sont toujours entre instances des classes à chaque extrémité, comme dans la section 7.3.3 (Association) de la spécification de superstructure UML:
Une association spécifie une relation sémantique qui peut se produire entre des instances typées.
Mais la classe B est dépendante de la classe A, comme dans la section 7.3.12 de la spécification:
Une dépendance est une relation qui signifie qu'un seul ou un ensemble d'éléments de modèle nécessite d'autres éléments de modèle pour leur spécification ou leur implémentation.
Il vaut probablement la peine de clarifier la nature de la dépendance avec un stéréotype. Vous pourriez utiliser un stéréotype use
, mais c'est très général et englobe en fait des associations standard entre les instances (bien que vous utilisiez évidemment normalement des associations pour explicitement montre leur). Comme le dit Fowler dans UML Distilled,
De nombreuses relations UML impliquent une dépendance. L'association navigable de la commande au client [dans l'un de ses exemples ...] signifie que la commande dépend du client.
Il ne semble pas y avoir de norme sur le stéréotype à utiliser. J'ai utilisé usesStatically
pour être clair sur la nature de la dépendance; C'est
B --usesStatically--> A
(Si, alternativement, la classe B avait une instance de A comme champ statique, j'utiliserais quelque chose comme B--containsStatically--> A
si je représente B explicitement dans le diagramme de classes; sinon, ayez simplement un attribut statique souligné de type A en B.)