|
|
-
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: - Abolish ball-and-socket wiring altogether;
- Restrict ball-and-socket wiring to simple ports, i.e. ports with only one provided or required interface;
- 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.
|
-
Last time I explained about Parts using a small example. But the idea of Parts can extend equally well, if not better, to large examples. Let’s say we have an ordering system that contains a couple of databases, and an ordering module, and an administration module. Using Parts this can be depicted thus: 
This shows that the Admin part is connected to the Customers and Orders databases, and the Ordering part is also connected to the Customers and Orders databases. The classes Admin, Ordering and Database need to be defined somewhere. They could be defined as nested classes of OrderingSystem, or elsewhere. Let’s put them elsewhere, into a couple of Packages. 
In a case like this we’d like to say more, in particular which aspects of the databases each module connects to. This is where Ports come in. Let’s add some Ports to the Database parts. 
Now to do that, in fact we have to add the Ports to the Database class itself. The apparent Ports on the Parts are not really Ports; they are actually usages within the context of the OrderingSystem of Ports defined on the Database class. 
The Database class defines two Ports: a, which provides the IAdmin interface, and q, which provides the IQuery interface. You’ll see in a moment why I have used such short names. Ports have types, and provide and require Interfaces as a consequence. The simplest kind of port is one whose type is a single interface, in which case the port provides that interface, as for both of the ports here. Now we can put this additional information into the definition of OrderingSystem, to show which Ports are hooked up to which Connectors. 
It gets quite busy visually with all of those labels (and there are other adornments I could have put on the connector ends if I’d wanted, such as multiplicities). Still, the model now shows how the Ordering and Admin parts hook up to the databases via Ports. The Connectors represent communication links, and the Ports show which interfaces the communications can use. Next time we’ll look at Components and how they extend these capabilities.
|
-
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.
|
-
Keith Short has announced that the next Oslo CTP will include support for loading UML models into the Oslo repository. I've been helping Keith and his team to unravel some of the complexities of the UML specification. As Keith says, in due course we plan to be able to store UML models created using the Architecture Edition UML tools in the Oslo repository.
|
-
Following close on the heels of VS2010 Beta1, we've announced the corresponding DSL SDK (oh those acronyms) - see Jean-Marc's blog.
|
-
I see I haven't written anything here since February. I've been very busy on two main fronts - lots of work on getting Team Architect ready for Beta 1 of Visual Studio Team System 2010, as well lots of work on making changes to the Components part of the forthcoming UML 2.3 specification.
Well, Beta 1 is out now. We use Visual Studio to build itself (we call it "dogfooding", a typically Microsoftian neologism), and one of the things that sometimes slows us down is performance. Rico Mariani always has interesting things to say about this, including now.
I'll write some details about the UML Component changes over the next few weeks.
|
-
Alan Cameron Wills has started blogging about UML for Agile Development. This should be interesting.
|
-
Last week I attended the OMG's technical meeting in Santa Clara. I was pleased that the Analysis and Design Task Force voted to issue a Request For Information on the Future Development of UML. The RFI can be found here and I strongly encourage anybody interested in the future of UML to respond, especially users.
|
-
Datum is singular. Data is plural. So we ought to talk about these data and many data and fewer data, right? It sounds all wrong to me. Data is like sand, water or furniture: a " mass noun". I am very happy saying this data, much data and less data. Much metadata, even.
|
-
Cameron has been blogging about new features in our product.. In a recent post he used the term Explicit Design. I've been reflecting on this, and I like it. In software development we really do need to capture design data that is not just the code, but should be saved and versioned just like the code. What do we call it? We could call it "models" but "model" and "model driven development" are subject to so much historical baggage and methodology and terminology arguments. "Model" just seems to imply baked-in code generation and round tripping, when there is so much more that you can do with it: planning, verifying, testing, refactoring. We need new vocabulary that represents our ability to capture versioned design data at a more abstract level than the code without simultaneously implying the history of CASE.
|
-
-
Stuart has blogged about the new features expected in DSL Tools in VS 2010. There's plenty new there: DSL libraries, DSL extensibility, read-only models, forms-based UI, ModelBus, precompiled templates, movable labels, sticky tools, copy/paste and more.
|
-
So what really is the difference between syntax and semantics in UML?
Firstly there is the notation, or concrete syntax. This defines what shapes are allowed on the diagrams: rectangles, ovals, lines, arrows, solid, dashed, compartments, annotations, adornments etc, and a set of rules about how these shapes combine and appear.
Then there is the abstract syntax. This defines a set of concepts that the shapes correspond to: classes, components, usecases, activities etc. What makes it abstract is that it is independent of which shapes are used to represent the concepts, or where those shapes appear.
Then there is the semantics. This supposedly defines the meaning of models, and this is where things get tricky.
There are many ways of defining the semantics of computer languages. Essentially, they involve systematically mapping expressions in the language to expressions in another language that you believe already has well-understood semantics. The other language might be some combination of arithmetic, logic, and set theory. In practice, though, the semantics of programming languages are defined by the compiler, and hopefully all compilers for a given language give the same result.
So for models that generate programs, the semantics of the models are defined by the programs they translate to, which are in turn defined by the compiler.
But UML is supposed to be able to map to multiple languages. UML class diagrams ought to be able to map accurately to programs in VB.Net, Java, C#, C++, possibly as well as JavaScript, COBOL, and Python. Similarly, UML sequence diagrams linked to those class diagrams ought to be able to visualize execution traces for all of these programs, and component models ought to be able to represent ports implemented by interfaces on those class diagrams.
Today, such an accurate mapping can't be done without bending the rules. But let’s be hopeful and assume that it becomes possible. In such a world, what are the semantics of UML? There must be some, otherwise all we can say about UML is that it is a language of shapes and lines which can be used for anything.
Well, there are some absolute basics which should apply regardless of how UML is applied. We could call these axioms.
One aspect of the UML definition is well-formedness rules, such as: Elements in the same package must be uniquely named; The slots in an instance of a class must be related to features in the class or one of its superclasses; The edges coming into and out of a fork node must be either all object flows or all control flows. These well-formedness rules are the axioms of UML. UML really has no built-in semantics apart from these axioms and what can be derived from them (the theorems, if you like). Additional semantics only appear when UML is mapped into some target language or platform, either explicitly through a generator or transformation, or implicity in your head when you draw it on a whiteboard or sketching tool.
|
-
-
The most familiar UML diagram is the class diagram. A class diagram can mean many different things. If you look around a room in which developers are writing software, you’ll often see whiteboards with UML class diagrams on. This is UmlAsSketch. The rectangles on these diagrams are 1:1 with the code. But this raises something of a conflict with the UML specification. Let’s say the code is C# - which it often is, where I work. C# only has single inheritance of classes, while UML has multiple. C# has fields, properties, methods, events, indexers, constructors and destructors, while UML has attributes and operations – actually C# has attributes too, but they mean something completely different. UML defines visibility to be public, private, protected and package: C# agrees on the first three, but also has internal and protected internal and does not have package.
A second popular use for UML class diagrams is conceptual object models (often called analysis models). The classes in these models don’t represent actual classes in the code; instead they represent conceptual entities that interact to represent the behaviour of the proposed software without thinking much about implementation issues like persistence, user interaction, performance, or security. Many authors wrote about using such diagrams for “object oriented analysis” during the 1990s: indeed that was the impetus behind the “unification” of the UML. Proponents of Model Driven Development frequently generate code from these diagrams, and it’s this use of class diagrams that is best catered for by the current UML specification.
Another popular use for these diagrams is conceptual data models. For example, a software designer who uses use cases to represent the interactions between system components needs to say what kinds of data traverse the lines in their diagram. UML diagrams can be used to represent entities and relationships for this – although again, there are problematical mismatches between the specification and the way that the diagrams are used in practice.
Pragmatically, the UML class diagram is a successful reusable syntax, covering the uses I’ve listed above and more. But the current scheme of UML profiles falls short of representing these uses. For example you can't change the visibility scheme, and it's very hard to find an effective way of representing C# properties that is consistent with the UML semantics. So in Visual Studio we keep the physical and conceptual representations separate: the Class Designer looks rather like UML but directly represents the code, and we will also have the Logical Class Designer, which implements the UML specification and is used for logical (conceptual, analysis) class design.
What do you use Class Diagrams for?
|
|
|
|
