What is wrong with UML Design Tools (part 1)

Over the years I’ve become less and less enamored with software design tools, what we used to call CASE (computer aided software engineering) tools. That’s not to say that I don’t like and use design diagrams. I make UML diagrams all the time. Mostly class diagrams and sequence diagrams. But generally opt for very simple tools to make my diagrams such as PowerPoint or Visio, rather than full up UML modeling tools. Actually my design tool of preference (which I can’t convince anyone to buy) is a portable whiteboard that can print out hardcopies of what’s been drawn. People seem to be using regular whiteboards and cell phone cameras for this purpose. My artwork and penmanship are awful, and the results weren’t very pretty, but that brings me to my first major point. Design is an activity, not a set of diagrams. The whiteboard is a great tool because it supports the design activity.

I’m not going to try to come up with a comprehensive definition of software design. If anybody could do that, I’d be out of a job along with everyone else who designs software. But I will try to characterize some key features of the activity of software design and how design tools can be obstacles rather than aids.

So what are we doing when we design? We’re weighing various, often conflicting concerns and selecting between solution alternatives to balance them out. These are often called design trades. Design involves making many small decisions, which interact with each other to form a larger solution pattern. These larger solutions need to be evaluated and compared as a whole with regard to all the concerns that drive the design. This is one area where design tools fall down. Most of these tools only attempt to capture the latest design. They can’t track multiple candidate designs, which may share many components and even merge. I would argue that if you’re using a tool to capture the (single) most current design, then you aren’t using it to design, since you’ve already made all the design decisions.

That’s why a whiteboard with a means to make a record of the drawing is a great design tool. You can draw and redraw as quickly as you think of new approaches, and then go back and compare alternatives, combine features, etc. I’ve actually sat through a design session where someone tried to create designs in real-time using a UML tool. The tool brought the process to a standstill. When I use a whiteboard as a design tool, I don’t limit myself to UML diagrams. I sometime use code sketches or fragments, tables, taxonomies and whatever else I can think of to express my designs. I also freely mix UML and other symbology. Tools like Visio allow me to capture this mix in finished diagrams (after that phase of design is done).

While UML modeling tools don’t support the kind of real-time collaboration you get from a bunch of engineers standing around a whiteboard, they have the potential for supporting other modes of collaboration. Unfortunately, they don’t realize this potential. The web has been hugely successful in providing dynamic, collaborative access to complex information. Most UML tools are desktop application that store models in file-based projects. They all provide some mechanism to create diagrams that can be put into web pages, but these are static views. In order for a user to be able to navigate through the model, and customize their views, they need to have access to the desktop application and the project files (most tools don’t support concurrent access). Reviews and other collaborative design meetings usually take place in conference rooms, sometimes at off-site locations. Installing tools and copying project files is not very practical

A tool that truly supports design should store its models as a set of versioned (branching) objects in a shared repository, and have powerful web-based navigation tools with explicit support for comparing versions and alternatives. Model elements should also be web resources (URL) that can be linked from other tools and models. Current modeling tools are firmly stuck in an ‘80s model.

In the next part, we’ll talk about what function design diagrams serve, how tools fail to support and even confuse disparate functions, and the value proposition for design tools (do you get more out than you put in).

 

Tags: CASE tool, collaborative design, design repository, object-oriented, OOA, OOD, UML, whiteboard