In my last two posts I outlined the basic ideas of Parts, Ports and Connectors as they appear in Structured Classes.  This time I’m going to discuss Components, and in particular the changes we’ve been making in UML 2.3 so that the Components chapter is well-defined.

In the UML metamodel, Component is defined to be a subclass of Class.  As a consequence, a Component can contain Parts, Ports and Connectors just like any structured Class.  So what is extra about Components? – very little, in fact; so little that I think that the two notions should really be combined into one.  But that’s a topic for another day.  In fact the major feature introduced by Components is the ability to do “ball-and-socket" wiring between ports and parts.  Here is a Component with ball-and-socket wiring that is semantically equivalent to the Ordering System I described in my last post.

image

You’ll see that the notation – which looks quite expressive - allows you to connect balls (representing provided interfaces) with sockets (representing required interfaces).  It shows that the :Ordering part requires the IQuery interface provided by the port on the Database components, and similarly the :Admin part requires the IAdmin interface.

This diagram looks like it connects interfaces to interfaces, and indeed the UML specification text frequently talks about connecting provided to required interfaces. The problem is that there is nothing in the UML metamodel that allows interfaces to be connected in this way.  Although visually the balls are connected to the sockets, in fact it is the ports and parts that are connected, and the depiction of the interfaces is just a notational convenience.  With the model above, this is ok.  But now consider a diagram like the following:

image

The diagram appears perfectly plausible.  But in fact the connectors between :First and :Second, and :Second and :Third, provide no way to identify the fact that :First consumes the interface that :Second provides, and :Second consumes the interface that :Third provides.  Because there is no way in UML to identify a connector with an interface and a direction, the diagram’s mapping to the model is ambiguous: the same model would also map to a diagram with the interface provision/consumptions reversed.  Semantically, of course, that would be a completely different system.

This is the kind of problem that the UML Revision Task Force frequently has to deal with.  For this particular problem, we identified three possible solutions:

  1. Abolish ball-and-socket wiring altogether;
  2. Restrict ball-and-socket wiring to simple ports, i.e. ports with only one provided or required interface;
  3. Enhance the UML metamodel so that a connector can be associated with an interface and a direction.

After much discussion and some voting, the Task Force decided on solution 2.  Abolishing ball-and-socket wiring altogether seemed rather draconian, although there were certainly strong advocates for doing it.  Enhancing the UML metamodel was thought suspect because the resulting structures would effectively duplicate the existing semantics of Ports.  So in UML 2.3, ball-and-socket wiring will only be valid between simple Ports.

In the Component designer of our VSTS 2010 Architecture product we do not implement ball-and-socket notation; instead we show balls and sockets on simple ports with connectors between them, which is a further notation option that is semantically identical to the figure above, but gives more layout flexibility and allows the diagrams to scale better.

image

Incidentally, the UML diagrams earlier in this sequence of posts were produced using Pavel Hruby’s excellent Visio stencils for UML 2, which I find very useful for rapidly creating no-frills UML drawings when no semantic model is needed.