Why the UML Is Both a Very Good Thing and a Lost Opportunity
- Why the UML Is Both a Very Good Thing and a Lost Opportunity
- The Lost Opportunity
- The Bottom Line
This article discusses why the Unified Modeling Language (UML) is a good thing for the software industry. It looks at the need for such a notation, why software engineers should use it, and, finally, where UML sits relative to the numerous methodologies propounded within the industry. However, I believe that the Unified Modeling Language (UML) has failed in one of its main objectives. In fact, I would argue that it fails in the very area that should be its greatest promise, that of notation.
UML: A Very Good Thing
First, the UML is a good thing for the following reasons.
Unified
-
Traditionally, software engineering has had a proliferation of design methods. Even where broad agreement has existed as to the method, there have often been multiple notations proposed to document these methods. This situation is entirely opposite of that pertaining in most engineering disciplines. In other disciplines, there is an agreed notation and a variety of methods (or, in many cases, no formal method at all!). This lack of uniformity within the software industry has resulted in a situation where virtually no two software engineers use the same set of notations, and we thus spend a large proportion of our time communicating notations rather than designs!
With the advent of UML, we at last have an opportunity to standardize on a single notation across the software industry. It may not be perfect, but the benefits of a single standard design notation far outweigh the imperfections. -
One benefit of a standard design notation is in the communication of patterns. Engineers can focus on capturing design decisions and passing these on to others. The result is that we can start to recognize repeated design patterns much more easily than is currently the case.
Hopefully we can progress to the stage of having a rich set of design patterns to choose from, rather like our electronics cousins who, with books such as Horowitz' classic Art of Electronics, can select from hundreds of working design fragments.
Modeling
-
Models illustrate principles. Models are small-scale representations of a larger, more complex structure. They serve to make the thing modeled more comprehensible to the viewer. In this respect, the UML, like any design notation, is not only a communications mechanism, but also a teaching tool. It acts as a means of explaining the designer's ideas and thoughts in a comprehensible way.
-
Models should be executable. In an ideal world, models should be usable, whether that's in a directly executable form or simply a format that permits walkthroughs of the operation of the system. It would be great if we could build a UML model and then start an automatic simulation of our system to prove that our design works as expected. Indeed, that is possible with some other design tools such as SDL. Maybe someday it will be possible using UML, too. Executable models are powerful tools for identifying design bugs early. With the right tools, they are faster to construct and more powerful than throw-away prototypes because we are exercising a model of the final system rather than just demonstrating an idea.
-
Models are not the real thing. Models are not the same as the thing being modeled. They simply represent the parts of reality that we as engineers are interested in. As a result, behavior may not be exactly representative of the real world. Most times that doesn't matter; sometimes it does. Building a model that can be inspected and executed before building a final solution is a good thing, but not a guarantee of success. It's a good idea to remember that.
Language
-
Notations as more important than methods—As already stated, the notation is the means of communication in a design. This is the end product of the design stage. It doesn't matter what method has been applied to arrive at the design the representation of that design—in a notation, this is all that will be seen. For that reason we can state that notation is more important than method.
Methods try to codify the design process, although to do so is, in my opinion, impossible because good design is as much a creative process as a step-by-step formula. We can provide guidance and checklists so that important considerations are not ignored. We can codify good practice (such as loose coupling of components), but at the end of the day, each design requires a creative spark that cannot be captured in a repeatable process.
Most, if not all, other engineering disciplines recognize that and allow their engineers to design within a loose framework of guidance. You can demonstrate this easily if you visit a bookshop and compare the software engineering shelves with the civil or mechanical engineering shelves—there will be few, if any, process-oriented books on the nonsoftware shelves. UML is a notation, not a method, and for that we can all be thankful. -
Communication between different user communities—Notations assist communication not only between different developers, but also between the developers and the deployment teams, the maintainers, the help desk staff, and sometimes even the customers and users. This communications exercise is greatly simplified when every community uses a common language, and UML provides the basis for that lingua franca.
-
Communication between developers—The most common use for a design notation is, of course, to share ideas among the developers themselves. This is increasingly important in distributed developments, such as those carried out in the Open Source movement and where development of components is outsourced, possibly offshore. If all the components are to come together smoothly, it is imperative that everyone shares a common view of the syntax and semantics of the component interfaces. UML provides mechanisms for clearly defining components and the interfaces between them.
This begs the question: Why, then, is UML so little in evidence within the Open Source community? It would appear to be an ideal mechanism for coordinating design over a widely dispersed team. Or am I simply looking at the wrong examples? I would be interested to hear from readers of any examples of the use of UML within Open Source projects.