How do i show the use of static methods in a UML class diagram?
class A{
public static void test(){
}
}
class B{
public void b(){
A.test();
}
}
How would a class diagram look like, which shows the relationship? UML 2.0 would be prepared, if there is a difference.
To show a static method you underline the name of the static method - have a look here for more detailed info.
As for navigating that relationship; class B
is dependent on the existance of class A
. We can say that class B has a "usage dependency" on class A
class B ----uses----> class A
Hope this helps.
@RobertMS is right.
Another alternative, is to use stereotypes:
..............................................................
....+----------------------------------------------------+....
....| 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>> |....
....+----------------------------------------------------+....
..............................................................
Note
Some programming languages best practices, especially those with C
case-sensitive syntax, capitalize static functions, and leave in camel-lowercase the rest of functions.
Cheers.
To show static methods and attributes you underline them in a UML class diagram: see UML Distilled p.66 or section 7.3.19 (Feature) of the UML Superstructure specification:
Static features are underlined.
To show the relationship between classes B and A (where B only uses static methods in A), you use a dependency, not an association. Associations are always between instances of the classes at each end, as in section 7.3.3 (Association) of the UML Superstructure spec:
An association specifies a semantic relationship that can occur
between typed instances.
But class B is dependent on class A, as in section 7.3.12 of the spec:
A dependency is a relationship that signifies that a single or a set
of model elements requires other model elements for their
specification or implementation.
It is probably worth clarifying the nature of the dependency with a stereotype. You could use a use
stereotype, but that's very general and actually encompasses standard associations between instances (though you obviously normally use associations to explicitly show them). As Fowler says in UML Distilled,
Many UML relationships imply a dependency. The navigable association
from Order to Customer [in one of his examples...] means that Order is
dependent on Customer.
There seems to be no standard on what stereotype to use. I've used usesStatically
to be clear on the nature of the dependency; that is
B --usesStatically--> A
(If, alternatively, class B had an instance of A as a static field, I'd use something like B--containsStatically--> A
if I'm representing B explicitly in the class diagram; otherwise just have an underlined static attribute of type A in B.)