UML supports collaborations
UML, the standard notation for software architecture from OMG [UML 1.1 and 1.3], has support for
collaborations and role modeling. This is important because collaborations are the reusable units of a
software system and collaborations need to be treated as first class citizens along with classes. A UML
collaboration captures structural relationships between its roles or participants (the structure) and the
interactions between the roles (the behavior). UML distinguishes between abstract collaborations and
concrete collaborations. Abstract collaborations have formal participants that are mapped to actual
participants when the collaborations are used. In UML, collaborations are used to realize use cases.
A collaboration consists of a set of ClassifierRoles and AssociationRoles. A ClassifierRole specifies one
participant of a collaboration. An AssociationRole defines a static relationship between classifier roles. The
collaboration states the associations that must exist between participants. The classifier roles and the
association roles are shown in a diagram that looks like a UML class diagram with the roles preceded by a
slash. Each participant specifies the required set of features a conforming instance must have. A
collaboration may be presented at two levels: specification-level and instance-level.
What is good about UML collaborations?
We agree with the following quote of Grady Booch (Aug. 31,
1999 in an email exchange)
From the perspective of software architecture, we have found that collaborations are the soul of an
architecture, meaning that they represent significant
design decisions that shape the systems overall architecture.
This matches with our experience. Collaborations should drive
a software architecture.
The UML captures the important structure of collaborations.
Connection to Adaptive Programming
Several of the concepts of Adaptive
Programming (AP) are collaborations in the UML sense: propagation patterns, Holland's executable contracts
based on the contracts by Helm and Holland et al., adaptive methods, and AP&PC. Characteristic of
adaptive collaborations is the focus on "important" participants, filtering out the unimportant ones. This
leads to defining for each collaboration an
idealized structural model with which the behavior of the
collaboration is formulated.
An adaptive program is written in terms of a partial class structure.
It may be used with any concrete class structure that
is "compatible" with the partial class structure.
The partial class structure expresses the assumptions the code
makes about the actual class graph.
Writing programs like this, that only make use of partial
knowledge about the actual class structure, is called structure-shy programming.
What is missing in UML collaborations?
The concept of connector is missing. Let's assume we have a class
library and a collaboration that we would like to add to the
class library. It is quite likely that the required
interface of the collaboration is not provided
exactly by the application but that some adaptation code is
needed. This adaptation code belongs to a connector
that provides the glue between the collaboration and
the class library. It also makes sense to have composite collaborations.
From the point of view of AP, connectors play the role of mapping a partial
class structure to a concrete class structure. In other words,
they fill in the structural information that was left out from the
structure-shy program. Connectors also provide functional detail that
was left out from the collaboration.
A connector for a collaboration specifies how the collaboration differs
from a concrete application of the collaboration. Connectors for collaborations are maps from participants to participants or from participants to classes
with code that implements the required interface of the collaboration.
How traversals are related to connectors
A connector embeds a "small" graph into a "large" graph.
The small graph is the structure of the collaboration and the large graph
is the structure of the application. The embedding is of the form
that one edge in the small graph is mapped into a set of paths
in the large graph. Such embeddings are conveniently expressed
in a domain specific traversal language as described in
DJ: A simple tool for Java programmers.
Alternatively, the embeddings can be expressed directly in Java
at the expense of more work and less flexibility.
How to explain collaborations
Collaborations have the flavor of type-oriented meta programs
[Ph.D. thesis by Kris De Volder (1998):
Type-Oriented Logic Meta Programs, Vrije Universiteit Brussel,
Programming Technology Laboratory]. Therefore, it is necessary
to make a clean separation between base level and meta level.
When explaining collaborations, it is important to separate
roles (meta level) and classes (base level).