Unified Modeling Language (UML) has been around for several years, but UML-based modeling tools use is still at only around 10 percent. And among companies that use UML today, most employ only three of the 12 available model types: use case, class, and interaction (see the sidebar, "UML 101"). In this article, I'll look at the challenges facing UML, the role of modeling in the enterprise, and potential market directions.

The constant drive to improve the application developers' productivity and increase their application code's consistency provides the foundation for considering model-driven development approaches (see Figure 1). Although the concept of software from pictures is appealing, it has underdelivered for the most part. Early object-modeling tools were simply drawing environments with specialized shapes and extremely high prices. Unlike data modeling, which has a more specific focus, object models are hard to check for consistency and accuracy. Also, because of their cost and lack of integration with application-development environments, modeling tools are used now only by the proud and the few—the architects.

Moreover, architects' plans are frustrated frequently because developers build the code they believe is needed to create the application. Over time, modeling tools began to support the ability to forward engineer or produce source code, so the architect could provide a starting point for the developer. Later, the tools gained the ability to reverse engineer, so the architect could learn what the developer built. But the disconnect between the model and the code limited this functionality's value.

Figure 1 Define the Use Case

Convincing the World to Draw Pictures
In 1994, Peter Coad, among others, began to develop tools that would change the way modeling worked. His company introduced a new way to think about UML: Don't separate models from the code. Keeping models and source synchronized supports an iterative life cycle. Although this connection makes modeling more approachable to developers, it doesn't provide a way to enforce decisions on architect sets. As development environments continue to evolve, I expect them to pick up more team-oriented functionality. This might introduce the ability to set overall architectures and enforce decision policies, but it's more likely that a split will continue. Architects will use UML to set overall strategic directions, and developers will use it to help document and design implementations.

Software development is often compared with several other technical disciplines, such as building architecture or hardware development. The goal of most UML proponents is to follow an approach to creating software similar to that used in creating buildings: Architects define infrastructure and plans, and various craftspersons then turn those plans into finished buildings. In architecture, there's an understanding that building a shed in the back yard requires much less detail than constructing a 30-story tower. Modeling advocates often push beyond the role the plans play in the creation of a building. Buildings don't get generated from drawings automatically; the drawing is a guide that various craftspersons use to understand structural and functional requirements.

Another challenge modeling tools continue to face is how to use them effectively with a team. The white board is still more efficient than the monitor when it comes to sketching out designs rapidly. Again, depending on a project's size, there's a sliding value to taking these "models" and transcribing them into a modeling tool. Collaborative environments enable teams to share applications that have been integrated into its environment. The META Group believes this type of functionality will appear in IDEs by 2004, but the impact on modeling will be limited. In general, group design will continue on white boards, and the final decisions will then be transcribed, as needed, into a UML environment.

Keeping Up With Technology
When UML first appeared, the Internet era was still developing, and Java was running toasters. Concepts such as container-managed persistence and entity, session, and message-driven beans were far off. .NET introduced Web services and a growing set of XML standards recently. UML has often struggled to keep pace with such changes. Several new UML proposals are in process, but UML faces challenges in certain areas with alternative Web service assembly and orchestration models. Also, the models used in development are different from those used by business users to describe process or in most packaged software, such as enterprise resource planning (ERP) and customer relationship management (CRM) solutions.

Although overall use of UML will continue to rise, the use of visual models and development techniques will grow at a faster rate. In addition to UML, the Object Management Group has defined a few other standards around the metadata and ways to exchange and persist this data. Tools can exchange information about models by using XML Metadata Interchange (XMI). This provides a way different types of models can be harmonized.

About the Author
Thomas Murphy is a senior program director with the META Group, an IT research and advisory service, where he focuses on enterprise application-development methods, tools, and architectures.