email article printer friendly

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.