Uml bliki

In UML Distilled, I bemoaned the fact that there isn't a good book on teaching UML's activity diagrams. There still isn't, but I recently came across Conrad Bock's articles on UML 2.0 . Amongst these there is a series of articles on activity diagrams that go into more depth than I was able to cover in Distilled. (For those who don't know, Conrad Bock is one of the leaders of the activity diagram work in UML 2.)

One of the new notations that appeared in UML 2 was the socket notation to show interfaces required by a class. The origins of this was the 'lollipop' notation that was popularized by Microsoft to show a class implementing multiple interfaces. So I can show that the Array class implements multiple interfaces like this.

This is a useful notation for showing this kind of thing. Using the realization arrow would result in a much more messy diagram.

Classes don't just implement interfaces, you can also think of them requiring interfaces. Let's imagine I write a class that can provide various information about my digital music playlists, such as the total length of the playlist. In order to get information about individual music files I need to get the data from somewhere. Since I'm a reasonably hip dude I can get it from iTunes - but since I'm aware that there are other possibilities (such as reading directly from an mp3) I use an interface so that I can easily substitute another implementation.

The required interface notation allows me to show this required interface with a compact socket notation.

With the ball and socket so close to each other, it only seems natural that they should mate. So the UML specification that I saw when writing UML Distilled let them do so.

Now although this was allowed in those UML specifications, Bran Selic kindly let me know that the UML committee has decided this was an error and you shouldn't be able to use the ball and socket notation in this way. Ball and socket notation is still in the UML, but it can only be used for connectors within Composite Structure Diagrams - which is a separate topic area.

This leaves the question of how you should show this link between required and provided interfaces. The way we did it in UML 1 was with a dependency.

Jim Rumbaugh's reference manual shows another way.

For an example like this, I think I prefer the UML 1 style, since there's less notation to convey the same meaning. However the Rumbaugh style shines when you want to show something more complicated, such as multiple classes implementing a single required interface.

When I first saw the mated ball and socket notation I rather liked it. Since then, however, I've found no great inclination to use it. For simple cases the UML 1 style with sockets works well, but when things get more complicated I prefer to have explicit class boxes for the interfaces.

I draw a lot of UML diagrams, but I don't use CASE tools. The reason is that I'm interested in UmlAsSketch, not in all the repository stuff. So far my regular choice has been Visio. Although Visio comes with UML templates I don't use the built in ones - I prefer those of Pavel Hruby.

Visio has worked very well for me, and it's still my first choice. But I'll admit to a wandering eye. Visio only works on Windows - and I also use Macs and Unixen, so it would be nice to have a tool that worked on all (or actually a common data format). I like to collaborate with others, so something open source would allow them to draw diagrams if they don't have access to Visio.

I've played a little with OmniGraffle on my Mac, not enough to really evaluate its capabilities - although it does produce lovely looking anti-aliased output. UMLet is an interesting looking project too.

The biggest thing I would like however is to specify my UML diagrams as text. That may sound strange - after all UML diagrams are diagrams, so why use text? Text has some advantages. Much of diagram layout is tedious to fiddle with in diagrammatic form, and would be much easier to do textually - using the diagrams as a visualization rather than an editing mechanism. Also text formats allow you to easily track changes over time with cvs and diff.

As a result I was intrigued by UmlGraph. The part of this that most grabs me is the sequence diagram editor which uses the venerable pic program. This page shows show the pic macros create a nice textual representation of a sequence diagram. Of course there are some limitations of what you can do in a pic macro and I can imagine a textual representation that's even more compact and clear.

objects 
  thread, t:thread
  tool, :Toolkit
  peer, p:Peer, unborn

trace 
  found: a1:run(3) -> 
    thread: 
      run() -> 
        tool: 
           callbackLoop() -> self
           create -> peer
           handleExpose() -> 
             peer: 
               return      
           delete -> peer

That's just off the top of my head. I don't know how well that would really work in practice. In any case I intend to experiment with UmlGraph as it stands to see how it would work for me. The pic program is so small I could easily tweak it if I wanted some changes.

UmlGraph's class diagram generator is nice in that it can produce stuff from Java source files. However for just a diagram syntax it looks rather awkward - and I would like some control over placement of classes. Enough to say Customer is to the left of Order. So perhaps represent this diagram with something like this:

layout
  row: Controller, EmbeddedAgent, URLStreamHandler, ChannelIterator
  SetTopController below: URLStreamHandler
  PowerManager below: SetTopController

interface URLStreamHander 
  operations 
    OpenConnection()
    parseURL()
    setURL()
    toExternalForm()

class SetTopController
  specializes
    Controller
    EmbeddedAgent
  implements
    URLStreamHandler
  attributes
    authorizationLevel
  operations
    startUp()
    shutDown()
    connect()
  associations
    -> PowerManager

class ChannelIterator
  dependencies
    -> SetTopController keyword:friend

Again this is just off the top of my head. The important thing is that I'm glad to see someone going in this direction - and would like to see more.

Here's some similar sketch-like tools that people have told me about

• MetaUml
• TWiki Draw Plugin
• Sequence
• Agent UML Tool

Some people think that Model Driven Architecture (MDA) will be biggest shift in software development since the move from assembler to the first high level languages. Others think that it's nothing more than Night of the Living Case Tools. I'm in the latter camp but feel the need for more than a slick saying.

Much of what's being said now for MDA was the same things that the CASE tool community talked about in the 80's. I think CASE tools failed for a number of reasons, but underlying it all was the fact that they couldn't come up with a coherent programming environment that would allow people to build general enterprise applications more effectively than the alternatives. Certainly CASE tools can help, often considerably, for particular tasks. I'd rather draw up a database schema with a graphical schema designer than typing SQL into TextPad. But too many things were either not possible or much harder with CASE environments.

So my question is whether MDA alters this. The UML grew out of notations that are pretty reasonable for sketching to convey design ideas. I use UmlAsSketch heavily, but the degree of formality and cohesion that's required to turn UML into the complete solution that's needed for MDA to work is much tougher. Certainly with UML 2 many people have worked hard to try to make the UML computationally complete. But much of this is done on paper, without clear examples and experience of what a platform using the UML would be like in practice. Even if the UML is computationally complete, it has to be a more effective environment for software development than the alternatives. As one who is familiar with both the UML and the alternatives, I have to say I don't see this.

As an example, consider behavioral logic. I can't see that drawing sequence diagrams or activity diagrams is as good, let alone better, than writing code in a modern language. I find this is true even when I have to write code to a greater degree of precision than the diagrams, as I do if I want to execute and test them.

Even if the UML forms an effective programming environment, it still needs to become a popular one. As an ex-Smalltalker I know only too well that even the best languages don't always make it into the mainstream.

Other arguments for the MDA are secondary, but also unconvincing.

• Having an OMG standards stack is certainly something that the 80's CASE tools lacked, but we'll see how well people stick to it. One thing that's struck me is how many MDA fans seem to see UML as the UnwantedModelingLanguage.
• MDA proponents talk about platform independence, but I've already dismissed this as a PlatformIndependentMalapropism.
• I've heard about how MDA will simplify development by allowing automatic generation of patterns. But I don't see a difference between what you can do in UML and what can be done with good libraries and frameworks. (As well as the fact that generating pattern implementations is missing at least half the point of patterns.)
• Much of the boosting of UML seems to be based on the statement that pictures are better than text. In cases this is true, but I see no evidence for that in general - anyone who has compared flow charts to pseudo code can form their own conclusions.

In many ways I'd love to be wrong about this. I would really like to see software development raised by a level of abstraction. (Not to mention that the UML's success would be good for me personally.) But I don't see that the UML provides this abstraction jump - and without it the MDA will not succeed.

Interestingly there is a growing sense that a broader group of people want to do MDA without the OMG standards. I'm hearing more about Model Driven Development using tools other than the OMG's MDA stack.

Here's some other thoughtful criticism of the MDA:

• Steve Cook talks about Microsoft's views on MDA and the broader issues of Model Driven Development. Steve was a central contributer to the UML as well as a leader in the early days of OO in the UK.
• "Bedarra" Dave Thomas gave a spectacular display of energetic skepticism at the MDA panel at OOPSLA 2003. Sadly I don't have a video of his performance, but an older jot column captures some of the depth of his argument.

How do you represent derived information in the UML?

Consider a simple example, you have a class that represents a rectangle and you want to know its height, width, and area. How do you show that the area is derivable from the height and width?

A common way is to show the height and width as attributes and the area as an operation. People do this because that's how they would implement it; fields for the height and width, and a method to calculate the area.

UML also has a notation for derived properties, you prefix the name with a '/'. So you could use this for the area.

Both of these approaches are reasonable and different teams do different things. Some only use attributes for fields; such teams don't use derived notation, or only do it when derivable information is cached in a field. Others use derived markers when they follow the same naming standard for derived values that they do for fields, such as a getArea() operation or using properties in languages like C# or Ruby.

My preference is to think about this slightly differently. One of the key properties of an object is that they are encapsulated. If I'm the user of the rectangle class I actually should not know or care that the circumference is calculated. The implementor might store the height and circumference and calculate the width - I shouldn't be able to tell. So that would leads me to use an identical naming convention for fields and for derived information on the implementation, and to represent them all as properties on the class diagram.

Does that mean I wouldn't use the derived marker? Actually no. I'm happy to mark the circumference as derived, but it indicates that there's a constraint between the three values, it doesn't specify what is calculated and what is stored. So in a similar argument I would say that if you have three side properties for a triangle it's reasonable to mark one of them as derived.

In fact it matters less which approach you take than it does that you follow a consistent style within your team. It's also important to remember that different people do different things, so this is something you'll need to figure out when looking at a foreign diagram. (I use derivation less than I would in my books because of this inconsistency of interpretation.) It's one of the many cases where the UML is less rigorous than it would like to think it is.

The UML means different things to different people, which is why I find the notion of people using a different UmlMode useful. Most people I talk to are interested in UmlAsSketch and this group isn't very impressed with UML 2.

The reason for this unhappiness is that the drive for UML 2 was to formalize and complete the UML to support MDA; primarily for UmlAsProgrammingLanguage (and secondarily for UmlAsBlueprint). As a result sketchers were pretty much ignored. This was largely their own fault as sketchers aren't interested enough in the UML to take an active role in the UML committees.

All this didn't surprise me. Something new that I discovered in the last couple of weeks (that included visiting UML 2003 and OOPSLA) was that disdain for UML is pretty rampant amongst the UmlAsProgrammingLanguage community too. After my talk at UML 2003 (broadly an appeal to not ignore the need of sketchers) several people came up to me to point out that people active in the MDA weren't particularly interested in the UML either.

Even on the MDA panel at OOPSLA, the pro-MDA speakers based their assumptions on the fact that they would be using a simplified subset of UML, and emphasized that you should not judge MDA on the UML. (Which didn't save them from a blistering attack by Dave "OTI" Thomas.)

I wonder where this will leave the UML in the future. I hear more mutterings from sketchers about the growing irrelevance of UML standards. In the MDA community it seems that we will see a rise of tools all using different subsets of the UML standards, probably extended subsets using profiles. What will this mean for the UML as an interchange mechanism between MDA tools? Some people are saying that the UML will not be the interchange mechanism - that the OMG MOF will play that role. This is all very well, but will users of MDA tools get portability in practice, or will each tool turn into its own proprietary language?