The neglected diagram

During the last JAOO conference, a couple of speakers (Eric Evans and James R. Coplien) eventually dropped a quote about UML experts forgetting to use the UML Object Diagram. It might have been a coincidence, but since I sometimes teach UML classes (and I normally tend to get through the Object Diagram quite quickly) this triggered some reflection "Am I doing something wrong?"-style.

It turned out that my slides were right – they were saying something like "this diagram us useful for explanation purposes" – but during classes the pitch tended to switch towards a more documentation-oriented version of UML. Many of the audiences were programmers or designers, interested in reading UML or in using UML tools, so the approach made sense. Still the main message was missing.

UML is a powerful communication tool. By establishing a standard, the three amigos opened the way to standard CASE tools, and a common language between software professionals. But the real point is that UML is a communication tool, and was designed to be flexible, to be used in different contexts. Designing a system in a CASE, or provide a non-ambiguous documentation for the development team, or using UML to generate code from a diagram is just one side of the medal. To design a successful application, requirement gathering and analysis are more crucial. In this phase UML can come in handy, but only as long as the all stakeholders are able to actively participate in the discussion.

Downsizing UML

To be successful in this information crunching phase, it's often better to stick on the minimal amount of UML that can be understood by the participants. People involved in this phase need to be aware of what's happening, and – most of all – creatively contribute to the result. Surprisingly the Object Diagram is one of the easiest to be understood by non software people, while Class Diagram, even simplified, still looks sometimes suspect to some.

Domain Specific Notation

The main goal is sharing the information. Forcing people to learn a simplified version of our language is a type of white-man-between-natives attitude. UML is definitely not "the message" but just a tool. If there's already a language in place, it's probably better to learn this one instead of forcing all the business people to learn UML. If there is no language in place, but UML simply doesn't quite fit the job, we can also define our Domain Specific Notation, if this is more easily understood than UML, and use it for a defined purpose.

Defining to what extent this extra language should be used is heavily dependent on the project context: an offshore development team will probably still prefer UML, because is standard and could have a more formal meaning. An in-house team, meeting the business people on a regular basis could find more efficient to grasp the information from the source in the specific notation.

Tags: OOA, UML, JAOO2007

Plea of a Together Orphan

Despite all the criticism surrounding it at JAOO, I am still working with UML sometimes (not that often, I am currently stuck between Excel, MsProject and – if I am lucky – PowerPoint). When asked about which UML tool to use, I used to answer “Together is the best choice, if you can afford it”. But in the last couple of years I simply tried to evade the answer.
In the recent past, Together proved itself the best for mainly 3 reasons:

1. Full roundtrip – despite some “not pure UML” tricks roundtrip really worked, so you could really keep in sync the model and the implementation code. You needed an OOP aware modeller to get all the benefits from it, but that’s what I used to be. Rose’s reverse engineering procedure really seemed terrible compared to this.


2. Code inspection features – the audit section was pretty interesting and made together a great tool for inspecting an unknown big project. As a consultant I used it proficiently every time I had to explore somebody else’s code (I am not a zealot in applying all of the rules, but you get quite a good outlook of the coding practices, or malpractices, the team used to adopt) in a CSI fashion.


3. Keyboard shortcuts – after a while, it really took me seconds to come out with a small domain model, almost without using the mouse. Adding classes, attributes, methods and interfaces was all done via keystrokes. Given that the classes’ source code was actually created at the same time, creating domain classes was faster than with an IDE. I ended up using it as a whiteboard, while discussing the model with the colleagues, cause it was faster than the whiteboard.

Clearly there were things that you couldn’t really do, even if they were available, like designing a GUI (Swing or Web), debugging, and so on. There were also a lot of annoying small bugs in generating PDF documentation, cutting and pasting images and so on.

Standing the test of time
Unfortunately, things never remain the same – panta rei – so did CASE tools as well. Well, Rose didn’t change that much in a few years, showing the same inconsistencies in the user interfaces over and over again. Together, meanwhile, blew it completely. They started a new version from scratch on the Eclipse platform. This was not a bad idea per se, given the weight of the original user interface, but they dropped all the keyboard shortcuts, and even if the GUI looks a bit nicer, it takes more and more time to come up with a model, cause you’re always selecting-dragging-dropping, exactly the things that made a lot of developers hate CASE tools in first place. Auditing tools are not such an advantage anymore, when you can include Checkstyle or PMD checks both in the IDE and in the build script, so you end up only with the roundtrip… but at the same price (

The only tool that really took modellers’ productivity seriously so far is Magic Draw UML, which added some nice features to the user interface that actually made drawing a model pretty faster. Still I can’t help myself… I don’t like it, it looks like a toy to me. It’s just a look and feel stuff… The guys at Visual Paradigm tried to replicate the solution, but they got it from the wrong side, and everything there looks counterintuitive, but shiny (they have plenty of colours and gradients, I guess it’s UML in Colors 2.0). Sparx’s Enterprise Architect looks promising, with an interesting price, but it’s not yet what I would like to have.

Back to basics
Given the new landscape, I’ll have to find another tool… I don’t need (and honestly I hate it) any code generation tool. I need only a fast modelling tool, so I am switching back to the whiteboard, and I’ll be using a camera to take pictures of it. Hope it’ll be readable.

Tags: Software Development, OOD, UML

A skeptic’s sight on Model Driven Architecture - part 1

Being dealing with MDA lately, I am currently trying to decide which side am I on. As the title above states, I found myself still somewhat skeptic (for reasons I’ll try to explain here). Anyway I am still digging in the MDA area, so my feelings of today will change or might result wrong.

MDA vs. Agile UML Philosophy
A crucial difference between UML modeling and MDA is that UML is a great tool to share a system vision with somebody who is not a programmer. Agile approaches focus on the UML as a tool to communicate so you tend to keep the model as simple as possible, to avoid information overload. Another agile principle is to avoid redundancy, for example including only a typical sequence diagram for a sample interaction with the system, without a detailed model of the others.
MDA goes quite straight in the opposite direction: a model must be formally correct in order to generate working code, so it must be complete. This means that all those not-so-different sequence diagrams now have to be modeled, instead of simply coded (which means also that’s going to be a designer’s job instead of a developer’s job). To be completely honest developers deal with small differences from the sample iterations in two ways: a) refactoring common code to an elegant schema, b) cutting and pasting. The latter – unfortunately – more frequently. Both ways are intended to save time; I guess there will be ways to abstract a common behavior at model’s level to reuse part of the already modeled behavior some way, but the efficiency of this part might not be comparable with what you can do with good refactoring tools on a recent Java IDE.

Another element that affects normal modeling is the adoption of the OCL as a way to define constraints in UML diagram. Bad news are that OCL is probably not so well readable to the domain experts (that’s the reason why you normally prefer plain language). On the other hand, this enables formal controls for completeness or consistency of the logic conditions, improving software robustness. A great burden here resides on the level of usability achieved by the development tools, that could make the difference from a toy to a really useful tool (the more you click, select and drag, the more you are probably faster in just typing java code).

Tags: MDA, Model Driven Architecture, Agile, UML