Developer Product Briefs

Modeling and Patterns

Establishing good UML practices getting full MDA with regular pattern development and use takes time. Discover how it's worth the time and effort for better software development.

• By Peter Varhol
• 12/15/2006

Modeling and Patterns
Building models of applications and employing design and implementation patterns takes time but is usually worth the effort.
by Peter Varhol

December 15, 2006

Successful software and system modeling has been a goal of both researchers and industry. It is an outgrowth on the decades-long trend toward abstracting farther away from the hardware and closer to the business problem. Modeling hides more of the underlying implementation, enabling designers to focus on the problem rather than its implementation. Ideally, the successful model becomes the implementation, through transformations, code generation, or compilation that provides a means of directly executing the model of the solution.

In actuality, the modeling part of that equation has been feasible for years. However, what has limited its use is the difficulty in bridging the gap between the model and the implementation. In practice the application might have been modeled, but the model was set aside as the team coded the implementation. Most believe that there was value even in building a "throw-away model" because it showed the overall design of the application and the interactions of components in a visible way. However, the cost in software and project time was often deemed not worth the effort.

Today, the question surrounding modeling is not if you will adopt it, but when. Most developers and designers associate modeling in general with the Unified Modeling Language (UML), in particular, but that association is not necessarily the case. There are other approaches to modeling, although UML is by far the one known and used most commonly. There are a wide variety of tools available, and many software designers and developers have at least experimented with UML modeling.

Patterns and modeling can be complementary. Patterns refer to recurring solutions to the problems of design and implementation. They are generalized descriptions of how to go about doing a specific task, and are typically described in a combination with specific types of software scenarios.

The problem with patterns, at least from an industry and practical standpoint, is that they are even more nebulous than models. They tend to make good topics for books, presentations, and discussions, but lack a structure and approach that make them amenable to building software tools around. It is not impossible to do so, but the end result tends to be limited and more difficult to use than developers would prefer.

There is little or no automated support for pattern development and implementation. Enterprises that use patterns do so as a part of a methodology, painstakingly building pattern libraries and requiring the application of patterns during application design and development. While this approach works, and enterprises who practice it report significant efficiencies in using it, the level of commitment to get started is more than many IT organizations are willing to invest.

The challenge to development teams is to define specifically how modeling can help deliver higher quality software more quickly, how to integrate patterns into the design and development process, and how to create and apply a road map that enables the team to achieve the benefits of these approaches.

Building on UML
The basis for mainstream modeling today is UML. UML, standardized by the Object Management Group (OMG) and in version 2.0 of its life cycle, provides a comprehensive graphical language for the formal modeling of software and systems.

UML is unique in that it is a formal modeling approach. Unlike most previous modeling techniques, such as flowcharts and dataflow diagrams, UML is a true graphical language, with established syntax and unambiguous semantics. Thus, any correct UML model has only a single interpretation that unlike text-based specifications cannot be misunderstood.

Further, this unique approach means that UML models can be proven logically to be correct and consistent. Of course, just because they are correct doesn't necessarily mean they accurately reflect the desired application, but they follow a given internal logic unfailingly. It also means that it is possible to demonstrate some certainties about such models. For example, it can be proven logically whether or not all parts of the model are reachable from a given path through the system. If parts are not reachable, they represent dead code in the resulting application.

Because of these characteristics, it is also possible to generate code directly from UML diagrams. While there are certainly some limitations in doing so, UML provides a strong foundation for creating source code, especially more consistent and structured object-oriented code. A number of vendors have provided code-generation facilities based on UML.

Conversely, while flowcharts and dataflow diagrams could be useful in helping to understand an application, they have no well-defined syntax and semantics. The resulting diagrams can usually be interpreted in multiple ways, and they are not fully effective in getting rid of ambiguity. They are throw-away diagrams, in that they are not especially useful once coding has begun.

The biggest disadvantage of UML is its complexity. UML 2.0 consists of a total of ten types of diagrams. Taken together, these diagram types can enable a designer to completely describe a system or application (UML is not limited to software only; it can also be used to model hardware or hardware-software interaction). But it takes a significant effort to learn these diagrams and how to apply them.

In practice, it usually is not necessary for designers to know and apply all of the diagram types. Many rely on state, activity, and sequence diagrams to design the flow of data and logic in the application. Getting into more detail, they might then use class diagrams to create the object classes, with interfaces and methods needed to implement the data and logic flow. And if nothing else, many apply use case diagrams at the very beginning of a project to better understand the user needs and how the users intend to interact with the application to accomplish specific tasks.

Even a large language like UML has structural limitations. These limitations flow largely from the fact that different hardware and operating platforms have different ways of doing things. It is possible to have a correct and relatively complete set of UML diagrams, yet have that application implemented in a number of different ways, depending on the underlying platform.

In response, the modeling community introduced the Model-Driven Architecture (MDA). MDA purports to bridge the gap between the model and the platform-dependent implementation by defining a series of transformations from platform-independent model (PIM) to platform-specific model (PSM), and from PSM to code implementation. These transformations are highly dependent on the problem domain, and may be either manual or automated. Today, few automated transformations are available, possibly because of their highly specific nature.

For many, however, MDA adds an additional layer of complexity on top of the already complex UML. Today, acceptance and use of MDA by development teams remains in the single digits. A part of that usage level may be because of the lack of domain-specific transformations, and the small number of MDA tools in general. However, for the majority of developers who are just in the process of getting their arms around the concepts of UML, widespread MDA adoption remains years in the future.

Fitting in Patterns
Perhaps the best way of establishing the use of patterns is to tie patterns to modeling. The model represents the design, and the pattern represents the implementation. This approach makes it easier and more straightforward to build the application, even if the UML modeling environment doesn't do general-purpose code generation.

Of course, there are also design patterns (along with several other types of patterns). Both design and implementation patterns make sense for development teams to leverage. Design patterns may describe how a particular common component of an application is structured, while implementation patterns may provide a road map for implementing that component.

Design and implementation patterns can be delivered in higher-level modeling components and plugged into UML tools to provide prepackaged designs and functionality. This approach can further streamline the process of building models and generating the resulting applications.

In practice, automating patterns is much more difficult than straightforward code generation. Patterns are intended to be general descriptions of problems and working solutions, with example code or even pseudocode for demonstration purposes. It is not a trivial exercise to turn such patterns into useful model or code components that can be readily imported into a modeling environment. As a result, further use of patterns, especially in automated model construction and code generation scenarios, will take much longer to develop.

How to Begin
Modeling and pattern use are not techniques that can be picked up and used immediately and easily. The training and cultural acclimation necessary to adopt and use these approaches effectively is significant, and many fail on the first attempts. Many others look at the effort necessary and forego trying altogether.

Yet, as mentioned earlier, the question is not if but when. Modeling bridges the gaps between the requirements, specification, and implementation of an application. Code generation is fast and at least adequate in quality and performance when applied to specific parts of an application rather than the entire application, and patterns can fill in when code generation doesn't provide a good solution.

If you are not yet practicing UML modeling or a comparable formal modeling approach, it would be a mistake to attempt to adopt MDA immediately. Rather, create a multiyear road map that takes you there in gradual steps. Start with use cases at the beginning of the development process to understand user interaction with the application.

Once the team is proficient in creating, understanding, and working from use cases, you can move to modeling aspects of your implementation. Plan out the application's execution path with sequence diagrams, and get used to envisioning your objects as class diagrams. After working on one or two projects the team will likely start thinking about design and implementation in UML. Then you are on your way to achieving the benefits of modeling.

At the same time, provide a searchable repository for patterns, and encourage developers to document ways that they solve specific problems. They may not be immediately useful, but you have started saving and cataloging your solutions. After a year, have the team take a couple of days to go back and refine them so that they are more general in nature. With a few iterations, you have the beginnings of a patterns library.

This gradual adoption process can take a couple of years to establish good UML practices, and several more years to get to full MDA with regular pattern development and use. The end result, however, will be better software developed more quickly, which makes it worth the investment in time and effort.

About the Author
Peter Varhol is editor in chief of FTPOnline.