|
|
-
-
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.
|
-
Reminder: the closing date for submissions to the Future Development of UML RFI is the 17th August.
There will be an all-day workshop to discuss the responses to this RFI on Sunday 13th September in San Antonio. If you wish to present at this workshop, please make a proposal by email to uml-roadmap-workshop@omg.org by 17th August.
|
-
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.
|
|
|
|