The Unified Modeling Language (UML)
No matter how good a coder you may consider yourself to be, you still need some structure during the process of building a system. If you want your new solution to be a success, you need to keep the quality high, and make sure it meets the needs of the users. If the designers, developers, and users do not speak the same language, you can be certain you will have problems in the end. One of the worst things that can happen in a big project is when people think they mean the same thing, but they really don’t. Eventually this might lead to disagreement over which features to include in the solution, and thus make a perfectly functional system a failure. As consultants, we cannot afford to let this happen. If our customers are not happy with the result, we will have difficulties getting an assignment from them again. This is why it is so important to agree about the real requirements of the system. For such an agreement to occur in a project, you need to describe the system so that various groups of people involved will understand how it should function.
Take a simple example. Say your friend is building a house. In this process, he has carpenters, painters, plumbers, electricians, you name it, involved. If only one set of blueprints exists and they only showed the exterior of the house, he would have serious problems. Why is this?
Well, different workers need different views of what they are trying to build and many of your friend’s workers will need to see the inside of the house. The same thing is true when it comes to software engineering. To get consensus, you need a technique, and this technique is called modeling. Modeling has proven to be a success factor in many projects over the years. The other day, we saw a TV show about a man in Sweden realizing his lifelong dream. He was building a real Batmobile, the car Batman drives around in, and he and his friends were just finalizing this impressive vehicle. The team started the project by modeling an exact replica of it in Styrofoam so they would have a good view of what to build. The model simplified the reality and made it easier to get everybody on the same page. Even though a model does not have to be this extreme, you are better off creating at least one (or more) model.
In the book The Unified Modeling Language User Guide by Grady Booch, James Rumbaugh, and Ivar Jacobson (Addison-Wesley, 1998. ISBN: 0-201-57168-4.), modeling achieves four aims:
1. Helps you visualize the system as it is or how you want it to be.
2. Permits you to specify the structure or behavior of a system.
3. Gives you a template that guides you in constructing a system.
4. Documents the decisions you have made.
As you can see, you have much to gain by using this technique. And large, complex systems are not the only ones that benefit from modeling either. Modeling helps even smaller systems, as many systems have a tendency to grow and become more and more complex as they go along. With a model, you can grasp this complexity, even after a long time has passed since the inception of the first version of the system. So, if you don’t model at the start of a project, you probably will regret it later on, when it is too late. A good thing, proven over and over again in many projects, is to have an object-oriented mind-set when designing and building software solutions.
Another thing that having a good set of UML diagrams can help you with is finding bottlenecks early in the design process. The sooner you eliminate them the less they cost to get rid of.
You must also think about modeling at different levels. Sometimes you need a high-level view of the system, and sometimes you need a low-level view. You need, for example, one view when showing the solution to decision makers and another one when talking to developers. Modeling can be difficult, however. If you aren’t careful when you choose what to model, you might be misled by your models and thus focus on the wrong things. Because models are
a simplification of reality, it might be easy to hide important details. To avoid this, you need to make sure you connect your models to reality. If you have a weaker connection in one place, you must at least be aware of it.
Don’t think that one model is necessarily enough, either. Going back to the example of your friend’s house, recall that different workers will need different views. This is true here, too. By using the Unified Modeling Language (UML), you can achieve all of this. UML is a standard for writing software blueprints, and as the name implies, it is a language. UML can be used to visualize, specify, construct, and document the deliveries (or artifacts) of a software-intensive system. But remember that because UML is only a language, it is just one part of the development cycle.