UML Structured Classes part 1

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:

image

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

image

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.

image

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.

image

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.

image

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.