UML Essentials - UML at a Glance

3/12/2011 5:19:27 PM
Modeling is a key stage in any software project, but it is crucial for large, enterprise-class applications—exactly the class of applications that keep companies up and running. A model is essential where complexity is high. It helps to check correctness and adherence to specifications, and it helps to build and maintain the software more easily. A clear and well-designed model also helps developers—at any time—find the right place to intervene to fix a bug. In software, a model should be viewed the same as site maps, blueprints, and physical models in the construction of houses: a definite need more than an optional tool.

Like it or not, years of real-world experience demonstrate that large projects normally exceed their budgets, their deadlines, or both. This is just the real world, baby. Proper modeling is not a guarantee of success for the project. However, it can be seen as your insurance against a dramatic failure.

UML addresses this need for an effective modeling language—a need that arose back in the early days of object-orientated development.

1. Motivation for and History of Modeling Languages

The need for modeling languages is tightly related to the broad adoption of the object-oriented paradigm, which started in the early 1990s. Object-orientation led developers to abandon subroutines and structured programming and, instead, embrace a vision in which an application is seen as a collection of interacting objects. Each object can receive and send messages, process data, and invoke and control the behavior of other objects.

Quite naturally, the object-oriented paradigm led to devising systems as a web of related components rather than as something that could be represented with start-to-finish flowcharts. Describing and documenting the behavior of such systems became harder and required appropriate tools and methodologies for modeling.

1.1. UML Predecessors

In 1991, the need for a modeling language produced Object Modeling Technique (OMT). Developed by James Rumbaugh, OMT was a language for software modeling and analysis. More or less at the same time, Grady Booch of Rational Software (now part of IBM) created the so-called "Booch method," which was an object modeling language and methodology tailor-made for object-oriented design.

Around 1994, Booch, Rumbaugh, and Ivar Jacobson (the Three Amigos) set up the group that unified different but related modeling languages and methodologies into a single language. After that, an international consortium—the Object Modeling Group (OMG)—was created under the technical leadership of the amigos to formalize the Unified Modeling Language specification. This eventually happened in 1997.

Today, OMG governs the development of UML and has more than 800 organizations associated as members. You can learn more about OMG roles and initiatives at http://www.omg.org.

1.2. Versions and Standards of UML

Currently, there are two main versions of UML, only one of which is officially ratified as an international standard. Back in 2005, the International Organization for Standardization (ISO) appointed version 1.4.2 of UML with the rank of a recognized ISO standard with ISO/IEC 19501:2005. You can find out more about the UML ISO standard at http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=32620.


ISO is an international organization whose primary goal is reaching a general consensus on solutions that span an entire industry including, but not limited to, the software industry. Usually, ISO doesn’t actually define its own standards from scratch; rather, it draws on specifications from other organizations. However, once ratified as an ISO standard, a given specification is an effective standard worldwide. This has been the case for UML (as of version 1.4.2) since 2005.

ISO/IEC 19501:2005 officially presents UML to the world as a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software-intensive system. As a result, today UML is the standard way to write the blueprints for software systems.

Currently, the progress of UML within OMG has reached version 2.1.2. You can download the full paper at http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML. You should note, though, that this version has not been ratified as an ISO standard just yet.

So how does UML 2.x improve upon the previous, and standard, version?

In a nutshell, UML 1.x is a simpler language centered around the idea of modeling classes and objects. UML 2.x goes beyond this threshold and adds the capability to present not only behavioral models but also architectural models, as well as business process and rules. With version 2.x, UML ceases to be an object-oriented modeling language and begins to target models used in other areas of the computing world and even in noncomputing disciplines. UML 2.x reorganizes the contents of version 1.x in a broader perspective and introduces many new tools, including new types of diagrams. (We’ll say more about this in a moment.)

1.3. The Strengths and Weaknesses of UML

In the real world, nothing draws criticism like recognized standards built from a generalized consensus. It’s really hard to keep everybody happy. UML is no exception. Although it is by far the most widely used modeling language, UML lays itself open to criticism for being essentially a bloated language. Not surprisingly, the ISO standard version 1.x was seen as needing improvement, and improvement came in version 2.x. Some people, though, now consider UML 2.x as being too bloated and complex as well as significantly harder to learn.

We feel that the strengths and weaknesses of UML descend from the U in the name, which stands for Unified. In other words, UML attempts to be too many things to too many people. Because of its declared generality, UML can be used in nearly all areas of computing, but not always with the same effectiveness. The bottom line is that UML generates a model, whereas working and functional code is all that customers want—to start off, at least. Managing the gap between the model and the code is up to the team, and that is the natural habitat in which general criticism toward the language as a whole springs up.

Initially, the U in UML had a positive overtone—unifying different, but similar, approaches to object-oriented modeling. Now, the U in UML is more the crux of the problem. To turn the general feeling about the U back to positive, we should be able to easily and effectively restrict UML to a particular domain. How can we easily transform a model into another model without loss of information? How can we automa(g)ically start working with UML and end up with code? If you look around, you’ll see a number of ideas and some implementations, but no widely accepted and adopted solutions.

Today, profiles in UML 2.x offer a first formulation to adapt UML to a specific domain. Likewise, the idea of programming on the UML diagram is precisely the vision behind the model-driven architecture (MDA)—a design methodology launched by OMG a few years ago. MDA is being talked about a lot, but it is not yet in widespread use. A domain-specific language (DSL) is a possible alternative to UML and MDA, as far as generating code out of a model is concerned.

In summary, there are a lot of good things in UML. In particular, UML is primarily a standard language for modeling object-oriented systems through a graphical notation. Based on this key milestone (essentially achieved with version 1.x), other features have been added to build a richer modeling platform. And here’s where most of the shades begin to appear.

UML should be conceptually split in two parts: U and ML. A unified approach to modeling is welcome, but context-specific modeling languages that are really close to implementation languages and that have domain-specific expressivity are an unavoidable requirement.


UML is merely a modeling language; it is not a software development process. However, a few software development processes exist that fully and rigorously integrate UML modeling techniques. Examples are Agile Modeling and Unified Process.

1.4. UML in Practice

Abstractly speaking, to use UML you need a methodology to gather and analyze requirements and then a modeling tool to turn them into a designed model. Usually, UML modeling tools incorporate their own methodology so that, in the end, you just pick up the best tool for you. So, which tool?

You basically have two options—pick up a plain drawing tool that "does" UML, or pick up a comprehensive tool that offers a team-based modeling environment and embraces the full software development life cycle.

Microsoft Visio Professional is certainly a tool that belongs in the first category. There are several free, shareware tools and commercial tools that just draw UML diagrams. A nonexhaustive list can be found at http://en.wikipedia.org/wiki/List_of_UML_tools.

In the second category, we find tools such as Rational Rose XDE from IBM, Enterprise Architect from Sparx Systems and, last but not least, Microsoft Visio for Enterprise Architects. Microsoft Visio for Enterprise Architects is included in MSDN Premium Subscription. It extends Microsoft Visio Professional to perform round-trip engineering on software and databases, thus enabling you to generate code from your UML diagrams and generate databases from your database model diagrams. You can get the same capabilities, and even more, from the other products mentioned, which have different pricing models and scopes.

Note, though, that the round-trip engineering description here is a bit emphatic and might look like an excerpt from some commercial pamphlet. An effective implementation of round-trip engineering is the key to effective use of UML in the real world. The description here is definitely alluring; however, we admit the reality might be a bit different. To understand why, we need to introduce typical UML working modes first.


Even though UML 2.x is the current version of the language, not all modeling tools fully support it. In particular, if you use Microsoft Visio Professional, you might want to add some external stencils such as those from Pavel Hruby, which are available through the Web site http://www.softwarestencils.com. Note that these stencils and Visio vanilla stencils are mutually exclusive. In addition, the Pavel Hruby stencils are purely graphics tools and, unlike Visio standard stencils, do not perform any validation of the model being created.

2. UML Modes and Usage

Over time, three modes of using UML have emerged and gained more or less wide adoption. They are referred to as sketch mode, blueprint mode, and programming language mode. Let’s dig out more details about each.

2.1. UML as a Sketch

We’re pretty sure that every reader of this book, at least once in his or her life, has drawn something on a paper napkin to record the basics of an idea. This is pretty common among geeks, isn’t it? When drawing or writing on a sticky note, a napkin, a whiteboard, or the back of a paid bill, you are sketching an idea.


Did you know the venerable B-52 was in fact designed the evening before Boeing presented it to the US Air Force, and it was designed on a napkin? This is a true story. It still flies today, 50 years after its design. Now this is exactly the difference between recording the basics of an idea on a napkin and saving a napkin design!

"Section 2.1" works in the same way, except that you sketch out a preliminary model for a software system and commonly use a file rather than a piece of paper. Used in this way, UML is merely a formal and visual language to express and communicate an early and incomplete vision of the system. Tools such as Microsoft Visio Professional and Microsoft Office PowerPoint are commonly used to sketch out UML diagrams. (We have also seen handmade UML-like paper drawings scanned to files and incorporated in the project documentation as Microsoft Office Word files.)

"Section 2.1" allows you to render incomplete diagrams with the simplest form—for example, diagrams with limited details and covering only the principal aspects of a system. More often than not, UML sketches are collaboratively created by architects and developers during both forward-engineering and reverse-engineering phases.

In general, forward engineering is classic engineering—that is, an engineering approach wherein, to build a system, you start by formally defining how it should be done and how it should work. In forward engineering, you employ UML as the language to express ideas to be shared and discussed. Through UML high-level diagrams, you typically weigh alternatives, plan activities, and assign tasks.

In general, reverse engineering is when you take an existing system and figure out how it works. In reverse engineering, you get a UML model out of the actual source code of the system. The optimum situation is when the diagram you get from reverse engineering matches the diagram you created with forward engineering. Hitting this goal is the essence of round-trip engineering.

Do not be too surprised to see UML in action looking like the diagram shown in Figure 1.

Figure 1. A sketch representing a use case

You might reasonably wonder if there’s any benefit and added value in this approach. At first, you might think that it is a waste of time or, worse yet, clear evidence of poor professionalism. A sketched-out piece of UML like the one in the figure clearly has no formal value, and we are not saying that we would present it at a formal meeting with the customer.

However, designing a system is far too serious a thing to pretend you can sit down on day one, have a look at standardized requirements, and start producing fully detailed diagrams. As disappointing as it seems, things just don’t go this way. In the early stages of development, using UML as a sketch is highly productive because it provides a common, visual, and formal language to express ideas and brainstorm about the design. Getting the specifications of a system is an iterative process, and each iteration might require creating a number of informal and approximate sketches, whether drawn on napkins or saved digitally to a Visio or PowerPoint file.

With a "Section 2.1" approach, your goal as an architect is communicating information about the system being created and gathering good input for developers to code up. Using "Section 2.1" lets the proper design emerge progressively and collaboratively, in an agile manner. To enhance communication, you don’t need and don’t want to use UML at its fullest. You need a formal language for sure, but one used in a more loose fashion—just like sketches.


On the topic of UML, we gladly note Microsoft’s commitment to significantly improve UML support in the next version of Microsoft Visual Studio. According to the latest product Community Technology Preview (CTP), we’ll find a bunch of designers for UML diagrams integrated into the next version of Visual Studio, such as use-case, sequence, and class diagrams. Unlike Microsoft Visio for Enterprise Architects, UML support in the upcoming version of Visual Studio (codenamed Rosario at the time of this writing) will be limited to modeling and separated from code generation. This switch basically enables you to use "Section 2.1" scenarios in the next version of Visual Studio—a quantum leap in the right direction, we feel.

2.2. UML as a Blueprint

UML is as good at brainstorming the system design (a sketch) as it is good at realizing a formal and full description of the system that is ready for coders (a blueprint). In any case, UML is the tool that architects leverage to communicate with the development team.

"Section 2.1" and "Section 2.2" are two distinct modes of using UML that refer to different views of the design process. There are radically different philosophies underlying each approach. With a "Section 2.2" approach, your goal is to deliver a complete and exhaustive set of specifications to the development team. You need to have a maximum level of detail and accuracy in this type of UML diagram. The design is essentially done entirely up front.

We like to summarize the differences between the two approaches by using the following contrasts: emerging vs. up front, or perhaps collaborative vs. ipse dixit. We also tried to capture these differences between "Section 2.1" and "Section 2.2" in Table 1.

Table 1. UML Sketches vs. UML Blueprints
 UML as a SketchUML as a Blueprint
PhilosophyEmerging, collaborativeUp front, ipse dixit
FocusCommunicationCompleteness of design
GoalsHelp communicate ideas and alternatives about design choices, and focus on selected issues. Iteratively come to a stable, but still incomplete, design of the system that is meaningful to developers.Neat separation between design and coding.

Leave little or nothing to developer’s discretion.

Development must be a manual translation of UML into a programming language.
Level of detail in UML documentsLowHigh
Formal value of UML documentsLow/mediumHigh
ToolLightweight designers, PowerPoint, whiteboards, napkins, backs of paid bills, and so forthAd hoc rich, specific, and often expensive tools

In forward engineering, the team first writes the UML blueprints and then produces the related implementation code in the language of choice. Blueprints should be detailed enough to leave as little as possible to the developer’s discretion.

In reverse engineering, a blueprint is generated from the source code to describe the effective behavior of the system, typically in a graphical fashion.

With a "Section 2.2" approach, you need a specialized modeling tool. Ideally, the tool should assist the architect during the forward-engineering stage to generate a set of detailed and unambiguous diagrams that are easy to turn into code without open points and gaps for developers to fill. Likewise, the tool should also be able to minimize over time the costs of synchronization between the UML model and the software artifact. Tools that support both forward engineering and reverse engineering are said to be round-trip tools.

As you proceed with coding and refactoring, it is crucial that you keep the UML model in sync with the evolution of the code. As you refactor the code, you want an updated UML returned that reflects your changes (reverse engineering). The tool should provide this ability, and this is mostly what makes "Section 2.2" tools extremely sophisticated and also expensive.

Does the "perfect" tool exist? This is hard to say.

For sure, tools such as Rational Rose and Enterprise Architect give it a try and do roundtrips. The tools vary in the way in which they store internal information to sync up the model and the code. It is not unusual, though, that after a certain number of roundtrips the chain breaks up and you are left with the model and code out of sync. Manual intervention to restore synchronization is then required.

For sure, Microsoft Visio for Enterprise Architect does not provide much help in this regard. For sure, the upcoming Visual Studio version will not be of much help either, but probably for a different reason. In the upcoming version of Visual Studio, the focus is on the "Section 2.1" approach.


"Section 2.1" and "Section 2.2" are based on different philosophies and have different goals. We summarized this using the contrast of emerging vs. up front. This might lead you to believe that the "Section 2.1" approach is agile and "Section 2.2" is not. Agile is a methodology, and the project manager is responsible for the methodology. A project manager can certainly require detailed UML blueprints in the context of an agile methodology—and vice versa. You can pick up a waterfall-like methodology and still communicate sketched specifications to the development team.

2.3. UML as a Programming Language

The more you can come up with a detailed model, the closer you get to a new programming language. You have a formal, yet graphical, language and fully detailed behavior. What really keeps you from compiling that source into executable code? Nothing in theory. But, in practice, graphical programming is not manna from heaven.

Can UML ever replace C#? Or, better, will there ever come a day when you model your application using UML and then just pass it on to a tool to generate code? Does this really mean that all applications will be written in a fraction of the time they take today?

Honestly, we currently don’t think so. But we like the idea that this might be (effectively) possible one day. Everybody has a secret dream, don’t they?

In a certain way, "Section 2.3" is just the next step past "Section 2.2." The highest hurdle on the way to "Section 2.2" is the availability of tools that can perform loss-less roundtrips. A second, and nearly as high, hurdle exists on the way to "Section 2.3": the absence of a UML graphical language with a pseudocode syntax.

We don’t know what the future has in store, but in our humble opinion the general technology outlook is not favorable for the success of a pure model-driven architecture—the methodology that pushes the idea of using just UML as your programming language. But we probably will get to use UML in a much more powerful way than it’s used today and significantly reduce the impedance between the model and the code artifact.


OK, we just made a bold statement about MDA here and took a clear and reasoned stand. Only those who make predictions can make wrong ones. As the ancient Romans used to say, "The future is held on Jupiter’s knees." So only time will tell. However, if we’re wrong about MDA’s poor prospects for success, it will likely be because of significant technical innovations. If MDA fulfills its promise within a few years, we’ll be among the first to adopt it.

2.4. How We Use UML in Our Own Real World

So we got to know the three main modes of using UML exist in the industry. But what mode is the best? This is so hard to measure that we prefer to rephrase the question for clarity and to avoid misunderstandings. So what, in our humble opinion, is the best way to use UML? And how are we using it in our real-world projects?

We essentially iterate through cycles of UML sketches up to the point of reaching a sort of blueprint. More often than not, though, the blueprint is not as perfect and detailed as it should ideally be. What we deliver as architects is normally a model that is clear enough to communicate some key architectural details and can be easily understood by developers. The model contains at least the most significant use cases and class diagrams. It doesn’t usually contain all possible sequence and activity diagrams. Let’s say that we tend to put in all the most important sequences, especially those for which we don’t want to leave any doubt about the intended behavior. On the other hand, when you have well-written use cases, the risk of creating a misunderstanding with developers is really low.

What about reverse engineering? Most of the time, we always end up keeping the UML and code in sync through some doses of manual intervention.

Which tools do we use? Because we strongly believe in "Section 2.1," we stick to Microsoft Visio for Enterprise Architects. (And we are eagerly awaiting the next version of Visual Studio.)

Finally, some notes about UML in the industry. There’s a growing consensus in the industry toward using "Section 2.1." And the announced set of features slated for the next version of Visual Studio reflects this. We think that "Section 2.1" delivers an excellent cost/benefit ratio—a good specification created in a small amount of time, with no need to spend money to license ad hoc tools.

In our experience, "Section 2.2" is a sort of chimera. And the same holds true for "Section 2.3" and the related MDA approach. The UML we have today suggests that the best we can do is sketch out models iteratively, reach a good blueprint-like specification, and then start coding. This has worked well for us to date.

  •  Understanding Microsoft Exchange Server 2010
  •  Working with Email-Enabled Content in SharePoint 2010
  •  Enabling Incoming Email Functionality in SharePoint
  •  Getting the Most Out of the Microsoft Outlook Client : Using Outlook 2007 (part 3) - Using Group Schedules
  •  Getting the Most Out of the Microsoft Outlook Client : Using Outlook 2007 (part 2) - Sharing Information with Users Outside the Company
  •  Getting the Most Out of the Microsoft Outlook Client : Using Outlook 2007 (part 1)
  •  Implementing and Validating SharePoint 2010 Security : Using IPsec for Internal SharePoint Encryption
  •  Examining Integration Points Between SharePoint and Public Key Infrastructure
  •  Getting the Most Out of the Microsoft Outlook Client : Deploying Outlook 2007
  •  Getting the Most Out of the Microsoft Outlook Client : Implementing Outlook Anywhere
  •  Getting the Most Out of the Microsoft Outlook Client : Security Enhancements in Outlook 2007
  •  Getting the Most Out of the Microsoft Outlook Client : Highlighted Features in Outlook 2007
  •  Sharepoint 2010 : Deploying Transport-Level Security for SharePoint
  •  sharepoint 2010 : Verifying Security Using the Microsoft Baseline Security Analyzer
  •  sharepoint 2010 : Utilizing Security Templates to Secure a SharePoint Server
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment : Web Conferencing
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment : Installing and Using the Communicator 2007 Client
  •  Integrating Office Communications Server 2007 in an Exchange Server 2010 Environment : Exploring Office Communications Server Tools and Concepts
  •  SharePoint 2010 : Securing SharePoint’s SQL Server Installation
  •  SharePoint 2010 : Physically Securing SharePoint Servers
    Top 10
    Nikon 1 J2 With Stylish Design And Dependable Image And Video Quality
    Canon Powershot D20 - Super-Durable Waterproof Camera
    Fujifilm Finepix F800EXR – Another Excellent EXR
    Sony NEX-6 – The Best Compact Camera
    Teufel Cubycon 2 – An Excellent All-In-One For Films
    Dell S2740L - A Beautifully Crafted 27-inch IPS Monitor
    Philips 55PFL6007T With Fantastic Picture Quality
    Philips Gioco 278G4 – An Excellent 27-inch Screen
    Sony VPL-HW50ES – Sony’s Best Home Cinema Projector
    Windows Vista : Installing and Running Applications - Launching Applications
    Most View
    Bamboo Splash - Powerful Specs And Friendly Interface
    Powered By Windows (Part 2) - Toshiba Satellite U840 Series, Philips E248C3 MODA Lightframe Monitor & HP Envy Spectre 14
    MSI X79A-GD65 8D - Power without the Cost
    Canon EOS M With Wonderful Touchscreen Interface (Part 1)
    Windows Server 2003 : Building an Active Directory Structure (part 1) - The First Domain
    Personalize Your iPhone Case
    Speed ​​up browsing with a faster DNS
    Using and Configuring Public Folder Sharing
    Extending the Real-Time Communications Functionality of Exchange Server 2007 : Installing OCS 2007 (part 1)
    Google, privacy & you (Part 1)
    iPhone Application Development : Making Multivalue Choices with Pickers - Understanding Pickers
    Microsoft Surface With Windows RT - Truly A Unique Tablet
    Network Configuration & Troubleshooting (Part 1)
    Panasonic Lumix GH3 – The Fastest Touchscreen-Camera (Part 2)
    Programming Microsoft SQL Server 2005 : FOR XML Commands (part 3) - OPENXML Enhancements in SQL Server 2005
    Exchange Server 2010 : Track Exchange Performance (part 2) - Test the Performance Limitations in a Lab
    Extra Network Hardware Round-Up (Part 2) - NAS Drives, Media Center Extenders & Games Consoles
    Windows Server 2003 : Planning a Host Name Resolution Strategy - Understanding Name Resolution Requirements
    Google’s Data Liberation Front (Part 2)
    Datacolor SpyderLensCal (Part 1)