UML and APIs using Java interfaces

[Calum MacLean]

Quite often, Java APIs are defined in terms of interfaces rather than
classes.

For example, the Java Debug Interface (JDI),
(http://java.sun.com/j2se/1.4.1/docs/guide/jpda/jdi/index.html) or
parts of the Eclipse API (e.g.
http://dev.eclipse.org:8080/help/co...g/eclipse/core/resources/package-summary.html).

In general, it can be useful to use interfaces instead of classes, so
you can hide the implementation and change it more easily.

So, my question is, if you're designing an API and are wanting to use
UML, how do you indicate associations etc. between interfaces?

As these are (Java) interfaces, there are no "real" associations etc.
between the interfaces. However, there is still might be a conceptual
association between interfaces.

Using JDI as an example, the VirtualMachineManager interface has an
allConnectors() method, which returns a List of Connectors. So there
is the concept of some sort of association between the
VirtualMachineManager interface and the Connector interface, but how
can you show this in UML?

So would a class diagram which contained (mainly) interfaces end up as
a collection of interface with possibly generalisation and dependency
links between them, but no associations etc. (which could presumably
carry more information)?

In general, how do you usefully use UML to model an API consisting of
(mainly) interfaces?

Thanks for your help,

Calum

 

[pete kirkham]

So would a class diagram which contained (mainly) interfaces end up as
a collection of interface with possibly generalisation and dependency
links between them, but no associations etc. (which could presumably
carry more information)?

The semantics of an association are primarily of navigation: if I have
an instance of (an implemenation of) interface Foo and can navigate to
an instance of interface Bar without intermediaries, then there would be
a direct association in the UML model.

In any Java, due to garbage collection, ownership associations
(aggregation and composition) don't map to the language level
constructs, but are useful.

If the interface 'Car' has a 'getWheels' method which returns a
collection of implementations of the 'Wheel' interface, and the concept
behind the Car is that it has some sub-parts which are Wheels, then that
could be represented by a composition in UML. This would capture the
intent of putting that method in the interface, instead of just writing
the method name in a little box with 'Car' at the top as a naive
Java->UML reverse engineering tool might.

The same can apply to UML attributes: if the interface has getMileage()
and a setMileage() methods, then the intent was probably to expose the
mileage attribute of the Car concept, so these pair of methods could be
represented as a public attribute in UML, possibly with a suitable
stereotype label to indicate the mapping.

How a UML construct maps to any particular programming language
construct is quite flexible, so use the one that best shows the intent.

In general, how do you usefully use UML to model an API consisting of
(mainly) interfaces?

By modelling the associations between the concepts the interfaces
expose, and using stereotypes to make the mapping to the language forms
explicit.


Pete

 

[Uncle Bob (Robert C. Martin)]

(e-mail address removed) (Calum MacLean) might (or might not) have
written this on (or about) 2 Jul 2003 12:15:04 -0700, :

Quite often, Java APIs are defined in terms of interfaces rather than
classes.

For example, the Java Debug Interface (JDI),
(http://java.sun.com/j2se/1.4.1/docs/guide/jpda/jdi/index.html) or
parts of the Eclipse API (e.g.
http://dev.eclipse.org:8080/help/co...g/eclipse/core/resources/package-summary.html).

In general, it can be useful to use interfaces instead of classes, so
you can hide the implementation and change it more easily.

So, my question is, if you're designing an API and are wanting to use
UML, how do you indicate associations etc. between interfaces?

Associations can come from data elements in classes, or from arguments
in methods. Since interfaces do not have data elements, associations
from interfaces cannot be from data elements; but they *can* still
come from method arguments.

We often draw associations from arguments as dashed arrows (i.e.
dependency arrows) or as regular associations with the <<parameter>>
stereotype.



Robert C. Martin | "Uncle Bob"
Object Mentor Inc.| unclebob @ objectmentor . com
PO Box 5757 | Tel: (800) 338-6716
565 Lakeview Pkwy | Fax: (847) 573-1658 | www.objectmentor.com
Suite 135 | | www.XProgramming.com
Vernon Hills, IL, | Training and Mentoring | www.junit.org
60061 | OO, XP, Java, C++, Python |

 

[Graham Perkins]

....

In general, it can be useful to use interfaces instead of classes, so
you can hide the implementation and change it more easily.

So, my question is, if you're designing an API and are wanting to use
UML, how do you indicate associations etc. between interfaces?

As these are (Java) interfaces, there are no "real" associations etc.
between the interfaces. However, there is still might be a conceptual
association between interfaces.

How about tagging them with "{abstract}" just like we do
for classes?

A more ugly solution I saw in one text book is to draw an
inheritance connection between the interface "association"
and the actual assoc. between the implementing classes.