Personal Opinion: UML Diagrams

Over the years, I have used several types of UML diagrams, including the essential class diagram, package diagrams (my favorite) and the less often seen, deployment diagram.

Then, there are ones that I am not a fan of, such as the popular sequence diagram diagrams. I don't like this diagram because I find it gets complex and cumbersome quickly. However, I'll be the first to tell you that I do not have better/alternative ways to do what some of these diagrams do (at least not yet anyways but eventually I hope to as I'm currently conducting some research in better ways to model/diagram -- check this website for updates periodically, if you are interested).

Meanwhile, I do use UML diagrams when appropriate because I do think they add value when used in the right place and at the right time. In fact, I feel UML diagrams are most useful when generated using reverse engineering tools to document the system already built (perhaps during a system handover).

I hope I don’t come across as being dismissive about UML, because this isn't quite my intention, especially since it took a lot of work over a number of years from some intelligent people to make a standard such as UML even possible (in fact, this is precisely why I'm basing all my research on work that has already been done instead of simply trying to reinvent the wheel).

My main complaint about UML is that it requires special tools, which can be expensive for an organization due to software licensing costs. In addition, some of these tools can have a steep learning curve and hence require potential training for the people using these tools (one common example being Rational Rose), resulting in additional cost to the organization.

Furthermore, simpler tools such as OpenOffice.org, Microsoft PowerPoint, Microsoft Visio and other similar tools provide the ability to connect a variety of shapes (rectangles, for example) using connectors, which are essentially straight or curved lines that connect two objects and stay tied to those objects when you move them around. This is a powerful feature since it enables you to create flowchart-like diagrams. I use connectors extensively as you will see in many free-form diagrams in my work (books, articles, etc.).

Also, I tend to follow practices recommended by Agile Modeling such as modeling with a purpose and producing good enough artifacts. Furthermore, I only update these when it hurts, since many artifacts can be thrown away after they have served their purpose – after implementing a design in code, you already have your documentation… yes, the code (as I mentioned earlier, code can be reverse engineered to produce pretty class and other diagrams).

What makes the idea of heavy documentation seem like sheer madness, is the fact that I cannot recall one software development project where the documentation was maintained till the very end and matched the end product. This is the case because we live in a fast-paced world with sometimes unrealistic software delivery deadlines and it becomes a difficult task to keep the documentation up to date.

In summary, use UML diagrams when appropriate but don't be shy or hesitant about using simple yet effective, free-form diagrams. Let me end by providing the same blurb from the agilemodeling.com website, "your goal is to build a shared understanding, it isn’t to write detailed documentation".