I got back from San Antonio a week ago.   The jetlag was bad this time; I’d been in the USA for two weeks and it’s taken me a week to get back to normal. San Antonio was a nice place to go.  The river walk was very enjoyable, and we had some great meals looking at it.  I’d just installed Windows 7 on my laptop, and I must say I’ve been enjoying that – it was a seamless process and just about everything seems to work better.

The UML roadmap achieved several important things this time.  First, we had a productive workshop on the Sunday, where many of the RFI respondents presented their views on where UML should be going.  There was a lot of agreement that UML is too complicated and we need to find a way to simplify it for normal people.  But nobody wants to destabilize the market by making major changes to UML, so we need to be measured on how we go about simplifying it.  We agreed that the specification itself is too cumbersome and we need to make it easier to maintain, by reorganizing the document and making better use of tools: so we kicked off a working group to do that.  And pretty much everybody agrees that genuine tool interoperability is increasingly important as the UML market matures, and to get that interoperability to work we need to remove the ambiguities and bugs.

UML 2.3 is essentially done, so it’s now going into the organizational and voting process that will end up with it being formally adopted; and we’ve kicked off a task force to work on UML 2.4.  Hopefully we can get the specification itself tooled up and sorted out over the next year, so that we can nail those outstanding ambiguities and bugs.

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.

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:

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.

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.

Recently I have spend quite a lot of time working out proposals to fix problems in the definition of UML 2, especially in the area of Components; these proposals will make it into the next version UML 2.3.  I’m going to make some postings to explain these changes.

Because Components in UML are built on Structured Classes – the metaclass Component derives from the metaclass Class – I should start by explaining about Structured Classes and Parts.  I start with a small example.

Consider a simple message box, which using .Net can be displayed using this code:

MessageBox.Show("Do you want to save your changes?", "My Application", MessageBoxButtons.YesNoCancel);

Executing this code will put up a box like this:

Let’s consider how to model message boxes in UML.  A simple class diagram for that would look like this:

Aside: I am not modelling here the implementation of the MessageBox, I am modelling its conceptual structure.  Those are likely to be closely related, but are not the same thing.

Well, that class diagram was simple, but it didn’t say that this kind of message box contains three buttons, called Yes, No and Cancel.  Let’s have another go.

That’s better – we have modelled the three buttons, as well as their roles in the containing MessageBox.   Now let’s consider how we might model the tabbing relationship: when you tab, the focused button switches from Yes to No to Cancel and back to Yes.  One way to do it would be to introduce three new subclasses of Button called YesButton, NoButton and CancelButton and set up the tabbing relationships between those.  But that seems rather complicated.  We can do better by using Parts.

This figure shows a Structured Class. It contains three Parts, and so far is exactly equivalent to the previous picture: each Part shows that a Button plays a particular role in the composite structure.  However, now we have a place to draw the tabbing relationships.

These relationships are called Connectors in UML. They are sometimes called “contextual associations”, and they can be used to show how Parts work together in a larger context.  Now, things working together in a larger context is a very common situation, and is also applicable to Components.  But before we get there, we need to introduce Ports, which I will do in the next instalment.

There is a good article by Conrad Bock about this topic here.