Why Model With UML?

Abstract

The purpose of the Unified Modeling Language (hereinafter referred to as UML) is to provide a language-independent and platform independent modeling notation. UML tools are as versatile as the UML is foundational. This article serves as a primer for the basic concepts of UML while providing an understanding of the purposes of modeling. It is not meant to be a how-to manual, but links are provided, where appropriate, to take you to well-executed tutorials to illustrate the steps on how to use the UML features offered in the NetBeans IDE.

This article is written for those engineers who can never find time to model a project before starting to code and for those engineers who have not yet considered creating models of their systems prior to coding them. This article presents some methods and strategies to help you be more efficient and possibly even save time. The information in this article might even enable you to challenge the rationale, "We never have time to do it right, but always have time to do it again."

Contents

Introduction

At the coffee shop, when you envisioned "an amazing" piece of software, you excitedly grabbed a napkin and drew pictures to add clarity to your thoughts. Your pictures were most likely a collection of chicken scratches that meant nothing to anyone but yourself.

But it did mean something to you: Those chicken scratches were the explanation of an idea that you might dedicate the next two years of your life to seeing realized. What you created was a rudimentary model. In your mind, the boxes represented one element, while the circles, triangles and lines represented another element. You invented a modeling language on the back of a napkin. If you could just compile and run the napkin, you would be done. This is not as impossible as it might sound. If you spent the next couple of months teaching the computer what each napkin object represented and how to generate source code for each object, compiling the napkin would be possible.

Throughout the last 25 years of napkin modeling, a handful of very good modeling languages have been created. Enter the Unified Modeling Language (UML). Modelers gathered all their napkins and agreed on the definitions of each object and the relationships between the objects. With this Unified Modeling Language, language-specific programmers started developing templates to create code for the different objects. Now, as long as you draw objects on your napkin that are part of UML, your napkin can be compiled.

"Why should I model?" This is a great question! In this article, two answers are submitted for your consideration: Think of them as UML use cases. The first answer, under “Compiling the Napkin,” focuses on the engineer sketching ideas on the whiteboard or coffee shop napkin. The objective of this section is to show you the benefits of modeling during the planning stages of your project. Multiple tutorials linked throughout the section can lead you through the details of performing the modeling.

The second answer to “why model” question, found in “What Were They Thinking” section, focuses on that frustrated sustaining engineer who was handed 300,000 lines of code and given the task to maintain it and fix bugs. He is happy to see that the original programmer knew about packages, but still does not see how it all fits together. If this is you and you are visual, you long to see a diagram of the system to get an idea of what the original programmer was thinking. This is a common use case for UML tools. You effectively parse the code to create a model (called “reverse engineering”), from which you can create diagrams.

Use Case Diagram		Primarily consists of actors and use cases. Use Case diagrams help capture the functional requirement of your system. This is always a great diagram with which to start a project.	view tutorial
Component Diagram		Primarily consists of major system components and their relationships. This is meant to be a high-level overview diagram of your complicated system. Whether in your head, on a napkin, or with a UML tool, this diagram has been created for every project you have ever worked on.	tutorial coming soon
Class Diagram		Primarily consists of classes, interfaces, and their relationships. The classes and interfaces are fairly straightforward, but the relationships can grow a bit complicated with multiplicity, generalizations, and associations. After you know what the components in your system are, the natural progression is to diagram the classes that make up the components	view tutorial
Activity Diagram		Primarily consists of activities and decisions. These diagrams are essentially flowcharts and data flow diagrams that you use to get the general flow of the code	view tutorial
Collaboration Diagram		Primarily consists of objects and messages. This diagram focuses on the communication between objects and is similar to the Sequence Diagram.	view tutorial
Deployment Diagram		Primarily consists of deployment elements, such as servers, and their relationships. This is a logical topography of your system.	tutorial coming soon
Sequence Diagram		Primarily consists of objects(with lifelines) and invocation messages. Sequence diagrams depict the order of invocations in your system as well as the creation of the different objects.	view tutorial
State Diagram		Primarily consists of states, transitions, events, and actions. State diagrams are seldom necessary except when logic is very complicated.	tutorial coming soon

top

Compiling the Napkin

You return from the coffee shop with your ideas sketched on a napkin. You need to describe a solution to your group or your boss. So you transcribe your ideas from the napkin to your whiteboard and drag all your colleagues into your cube to show them. No software tool will ever replace the conversations that happen around the whiteboard, but if you have to send your idea out of the office, it is generally frowned on to mail Polaroids or send an email with digital photos of your whiteboard. The whiteboard does not make it easy to document your ideas so you can refer to them later. You might not like it, but you have to locate a UML tool and create the model that describes your idea.

Though a model is simply a collection of model elements and their relationships, these elements can be grouped to form diagrams. These diagrams are greater than the sum of the elements as they provide various views of your model. The different views can be used to tell a story about how the application is structured. The type of diagrams you use to visualize your model depends on your problem.

As you are getting started, you might choose to create a Use Case Diagram. This is a good overview diagram that identifies the major components of your project. Though the Use Case Diagram can be made as complicated as needed, it really has only two major parts: the Actor and the Use Case. An Actor represents an entity that will interact with your system. An example of an entity might be a “Customer” or “Bank Teller” that interacts with your program. The actor could even be a third-party library or a piece of hardware. The main idea of the Use Case diagram is to show these actors can interact with your program. For example, a Bank Teller might “Deposit Money” or “Withdraw Money.” In this case, the Deposit Money” and “Withdraw Money” are Use Cases. No code is directly related to the Actor or Use Cases, but these interactions expose the need for certain components in your project.

Thinking through the use cases is frequently skipped during planning and as any programmer knows, a use case analysis will have to happen eventually. Thinking through what your project requirements are saves implementing unnecessary features and forgetting others. Creating a Use Case diagram might well expose any overlooked points. The diagram can't keep you from adding features that are unnecessary, but it at least tells you that they are not needed. So, the first step is to perform a use case analysis and create Use Case diagrams. A tutorial guides you through the process of creating a Use Case diagram.

Completion of the use case analysis and diagrams leads naturally to sketching out the components of your system. Whether in the mind, on a napkin, or with a UML tool, this step has never been skipped in the development of a successful system. The benefit of formally creating a Component diagram is that it can help you define the classes and interfaces that will make up your components. If you completed the Use Case diagram tutorial, you can see how important that analysis is. From the Use Case diagram at the conclusion of the tutorial, some of the necessary components become evident: a Customer component, an Account component, and a Database component. The interactions between components can be further defined with Collaboration and Sequence diagrams. These components represent the deliverable pieces of your system. These are the pieces that your boss, your customer, or both parties must sign off on as sufficient. Until the components are agreed on, the architect and programmers are shooting at a moving target. But after the components are set, fine-grain structural work can begin.

This fine-grain design is started by creating the Class Diagram. Again, a ready-made tutorial will lead you through the details of creating a Class Diagram. If you went to the effort to creating Use Case and Component diagrams that were accurate, you might be tempted to just sit down and start coding. But remember the last time you did that and later had to re-create interfaces and superclasses because you did not see the necessary relationships when you started coding?

As you create your Class diagram, you are forced to make all the pieces fit together, reflecting on where you need interfaces, superclasses, and even entire design patterns. So, you see, the benefit to these diagrams is that they expose structures of inheritance before you write several classes and see that you are writing the same methods repeatedly.

Using the NetBeans UML tool adds another great dimension to the Class Diagram, namely design patterns. If you know that a certain component of your system will utilize a design pattern or set of patterns, simply dragging and dropping the pattern onto the canvas creates the basic component for you. Better yet, the tool creates it correctly. Forget about trying to remember how the design pattern is actually structured. The NetBeans UML feature provides the Gang of Four (GoF) and Enterprise Java Beans (EJB) design patterns ready for use. If you use a custom design pattern often, you can save it for future use.

The best news is that none of this work will be wasted. If you are using the NetBeans UML feature, a Class diagram can be turned into Java source code with the click of a button. You can even set the options for how the code is to be generated: headers, comments, variable placement, and other formatting. These settings would even include adding copyright information to all the generated files. The code generation alone should make this step worth doing during your development cycle. Therefore, it is worth your time to create the model first and let the tool generate all the basic code.

Everyone diagrams in one form or another. The difference is that those who diagram by using a UML tool have something to show for their planning effort when the diagrams are completed. Napkins have a tendency to be used to clean up spilled drinks and thrown away. Every project that is well thought out will have some form of Use Case diagrams, Component diagrams, and Class diagrams that can live long after “imagineering” at the coffee shop has ended.

top

What Were They Thinking?

UML is simply a modeling language and is independent of any coding language. Therefore, just as UML can be translated into a coding language, so can a coding language be translated into UML. This process is known as “reverse engineering.” There are numerous uses for this process, but the most common is to simply get a view of how code is structured: What are the objects and how are they related? Seeing diagrams of the code can expose design patterns and other complexities that might not be obvious while reading the code. For the “how-to” tutorial using the NetBeans UML tool, see the tutorial named Reverse Engineering Java Applications

Though this article is not meant to be a tutorial, if you are using NetBeans to do your reverse engineering, a couple of steps are worth noting. You start with a free formed Java code base. The first step in reverse-engineering this code base is to create a NetBeans “Java Project with Existing Sources.” Wizards in NetBeans can help you with this process. After the project is created, a menu item is added to the project to reverse-engineer it. Even with large projects, this process only takes a few moments. When complete, a UML Project appears in the project tree.

This project can now be manipulated at will. Diagrams can be created from the generated model elements. If alterations need to be made to the diagrams, simply make the alterations and regenerate the code (called “forward engineering”). You can either replace the code from which the model came or store it somewhere else. Notice the power in these features. You can develop your code from the model itself. This flexibility enables you to retain all the visual and reporting abilities of the model while also being able to compile and run your code. It really is the best of both worlds. If you like typing your code instead of creating it from diagrams, you can do exactly that. When your manager asks for a code review, simply reverse-engineer your code to update your model and take the diagrams into the meeting.

Though reverse engineering is a tremendously useful tool to help you understand legacy code, it does not provide answers to all the questions. For instance, use cases cannot be drawn from a model that has been created by reverse engineering. You would not expect this outcome, as the code contains a different level of information than that required by the use cases. Other diagrams that do not make sense to create from reverse engineered model are Component, Activity, Collaboration, State, and Deployment. But, because the class elements and relationships are all known, any of these diagrams can be quickly created and you can then deduce the answers to the questions that naturally follow: What are the use cases? What is the deployment structure? What are the major components? You only need to supply the missing information pertinent to that diagram  to have a fully developed model.

top

Summary

UML is a language. Even though great tools exist for working in UML, it is still a language. If you do not understand the structures of the language, the design palettes in the tools can only frustrate you. To make the language “unified,” UML has encompassed a great deal of functionality. This bulk can make the UML tools cumbersome and hard to use. Sun Microsystems offers a class to learn UML in the context of object-oriented analysis and design. Using your understanding of the context of the different elements in UML, your models can take on a high level of practicality and efficiency. If you are creating models by using the wrong elements, your models will not translate into code.

Whether you are an architect or a programmer, modeling is a necessary step in any project that is more complicated than HelloWorld. Some modeling languages, for example, are tuned for things like database design, but if you only have time to learn one modeling language, UML has become the industry-standard for modeling. The UML tools, such as the NetBeans UML feature, have evolved so far that modeling is no longer a waste of  cycles or simply an academic exercise that is tossed after the programming starts. The tools can and do actually help you get your programming done, giving you a chance to start the cycle again at the coffee shop.

This article was last updated October 19, 2007

top