I’ll be giving the next presentation at the Western Mass Dot Net Users Group on the basics of UML. Details:

Presentation:
Get an introduction to the Unified Modeling Language. Learn the basics of Class, Sequence, and Use Case diagrams.  The emphasis will be on UML sketching, but UML code generation will be discussed.

This session will be platform independent.  Please bring an open mind, your ideas, and experience to share with the group.  Software developers, project managers, students and anyone interested in software development on any platform are encouraged to attend.

Meeting Details:
Tuesday, February 7 at 6:00 PM
Fazzi Associates, Inc.
243 King St. Suite 236, Northampton

I’ve been playing around with ArgoUML, an open-source UML modeling and code generation program. So far, the major drawback for me is the non-standard UI elements because of Swing—I really hate Swing File dialogs—even the “Windows” look and feel ones.

My first impressions are very good. I have spent seven years with Rational Rose and like it very much, but it is out of my price range right now. I haven’t used any other products and I am only interested in packages with some kind of code generation and deep UML knowledge (that rules out generic drawing packages). And, price is an issue. So far, Argo meets all of my basic requirements.

One of the features I think I will like is what they call cognitive support. It manifests itself in a list of suggestions about your model. For instance, in playing around, I have a class with no non-static members or associations. In the to-do list, I see a suggestion to make this a Singleton. Argo also helped me understand some of its conventions by suggesting names for the packages I made. In general, Argo understands UML, and does a great job of helping you create it.

The code generation is in the early stages, and in inadequate for use on a project unless you are using an editor that will seamlessly fix the code into your standard tabbing style. Even when I use UML as a sketch, I like to generate the code as a sanity check to make sure the UML says what I think it says—it’s good enough for that.

Large multi-person projects might find the lack of external packages (packages each stored in their own file) a deal breaker. Rational has very good support for this, and it’s essential when you try to use UML as a programming language, since having one big file becomes a impediment to collaborative development. This extends to property sets as well, which I don’t see how to share between models.

Here’s my first model:

 

Created to mimic the design in this NUnit presentation.

Although UML is usually not associated with agile processes, there are two ways I think it can play a major role in an agile development project.

The first is a full adoption of a UML toolset, including full round-tripping through the entire implementation. In this case, UML becomes part of your programming language. It maps very well onto the constructs of Object-Oriented implementation languages, and there is nothing about it that will stop you from doing all of the things you do in an agile process (Simple Design, Test First, etc.) The benefit is that you have a up-to-date UML document at the end of the implementation (why you might want this, I’ll save for a future entry). I have done this with Rational Rose for C++ with great success, and if you want UML diagrams that actually match the implementation, this is the way to go.

The other use is to not even attempt to keep UML documents consistent with the implementation as it progresses, and just use UML to convey design ideas. This is more precise than a text description, and certainly a good supplement to one. Design Patterns by the GoF is a good example of a book that uses UML to convey design ideas. Martin Fowler’s Patterns of Enterprise Application Architecture uses it extensively as well, and he says this about the UML in his books.

Most UML diagrams shown in books, such as mine, are sketches. Their emphasis is on selective communication rather than complete specification. Hence my sound-bite “comprehensiveness is the enemy of comprehensibility”

Unless UML is the implementation language (where completeness is essential), then there is no need to include every detail in the drawing. In fact, inclusion communicates importance in this context.