How to show usage of static methods UML Class Diagram
@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 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.
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.)