Learn about an important O-O standard: Unified Modeling Language

The Unified Modeling Language (UML) standard is an important component of object-oriented methodologies. Find out what UML is and why you should care.

Most application development professionals understand the importance of having a methodology to follow during the life of any development project. One problem we have, however, is keeping up with the methodology du jour. Happily, the Unified Modeling Language (UML) may make everyone’s job a little easier. As you’ll see, UML isn’t itself a methodology but a set of tools that enables developers to document and describe projects in a standardized way. Let’s begin with a look at how UML got its start. Then, we’ll explore some of the ways UML can aid development efforts and benefit the enterprise.

Where did UML come from?
In the late 1980s, programming techniques shifted from procedural to object-oriented (O-O), and the need for new methodologies became readily apparent. During the 1990s, we saw approaches from Booch, Jacobson, Rumbaugh, and Coad & Yourdon, among others. An effort to create a standard methodology for O-O analysis and design began to materialize in 1995. In 1997, the first version of UML was submitted to the Object Management Group (OMG) as one of the proposals for a new standard for the documentation portion of the methodology. The OMG ultimately adopted the UML as its official standard.

UML is the result of many contributors; however, the main architects were Grady Booch, Jim Rumbaugh, and Ivar Jacobson of Rational Software, an e-business software tools developer in Cupertino, CA. Booch, Rumbaugh, and Jacobson also created a standard for the process of O-O analysis and design known as the Rational Unified Process (RUP). However, UML can be used without the RUP.

What is UML?
Before we explain what UML is, we need to understand a bit about methodology in general. There are two parts to an analysis and design methodology. The first is the process we follow during the development phase. By process, I mean the approach or steps we take as we delve into a business/technology problem. For example, with a “top-down design methodology” (a.k.a., “Yourdon design methodology”), the steps and phases of continual refinement represent the process.

The second aspect of a complete methodology is the language we use to document and communicate our efforts to ourselves or others. Among the tools commonly used in conjunction with a top-down process are things such as entity-relationship diagrams (ER diagrams), flow charts, data flow diagrams, and hierarchy charts. These tools represent the language we use to communicate and document the development effort.

UML fits into this second aspect of methodology. It is a process-independent language used to capture, describe, document, and communicate what happens during application development. Among the tools you will find in UML are use-case diagrams. These diagrams describe the typical interaction a user might have with the system under analysis. They are labeled in terms the user can understand and are generally thought of as representing a single function. For example, the function “modify profile” on an order screen might be represented in a use-case and would include the steps to accomplish the task, as well as people/roles that interact with the system (called “actors”).

Besides use-cases, UML includes these tools:
  • Class diagrams
  • State diagrams
  • Interaction diagrams
  • Activity diagrams
  • Component diagrams
  • Deployment diagrams

Class diagrams, common to most O-O methods, show the types of objects in the system as well as the types of relationships that exist between them. State diagrams show the “behavior” of an object by describing all of the possible states a single object can be in. Interaction diagrams, as the name implies, show the interaction between objects. This can be done with sequence diagrams or collaboration diagrams. Activity diagrams, like flowcharts, show the sequence of activities but also provide for parallel activities. Component diagrams show the physical modules of code and any dependencies between them. Deployment diagrams show where components reside on the physical system and the paths by which they interact.

So what’s in it for me?
So why the big deal? So what if the methodology wars are over? Here are some reasons why a programmer or analyst should care about UML:
  • Having a standard allows you to communicate with your peers in a manner that you know they will understand. Of course, you may also now stand a chance of understanding their documentation as well.
  • UML applies a structure to the information that comes from the design effort. By using the tools of UML, you have a better chance at completeness and clarity.
  • UML standardizes communications with stakeholders. I’m certainly not suggesting that business managers become experts at understanding all documents associated with an object-oriented development project, but it does provide a framework for an analyst to explain the system to users and managers. Besides, would it hurt if key users actually sat down and studied some use-cases (which I think they would easily understand)?
  • Learning UML can help O-O programmer/analyst wannabes adjust the way they think about systems, which will facilitate learning other aspects of O-O technology.

Here are some reasons why the enterprise should care about UML:
  • Communications between team members and between teams will improve because they’re using a common language. This alone will smooth many of the potholes found on the road to successful project completion.
  • Having stable documentation over time (in a common language) can go a long way toward managing the knowledge gained during the development process.
  • There is a greater likelihood of outside contractors understanding the in-house documentation.
  • Adopting an accepted standard will mean reduced training costs.

The field of application development has a great deal to gain from standards and best practices. And combined with a process, UML can provide IT professionals with the tools they need to standardize their methodologies, develop a more efficient approach to design, and create a more structured development environment.

Does UML have a place in your organization?
Would/does UML provide any benefit to your development effort? Are there other tools you think are better? Send us an e-mail with your ideas and experiences with UML.


Editor's Picks