Developer Product Briefs

Take the Next Step in Modeling

Design patterns have been in use for a while, and for systems architecture they are used often in a copy-and-paste manner. See how aspect-oriented modeling takes patterns to a higher level.

• By Greg Gorman
• 12/22/2006

Take the Next Step in Modeling
Apply aspect-oriented modeling to improve architect and developer productivity in high-level, distributed enterprise systems.
by Greg Gorman

December 22, 2006

The use of design patterns in software programming has been a standard industry practice for many years. Patterns are used to represent an entity's common characteristics and allow repeated application or re-creation of that entity. Patterns are used throughout engineering disciplines and have recently been used in software modeling.

In fact, many unified modeling language (UML) modeling tools today have some kind of pattern support built in or are available as an add-on module, such as a large, user-modifiable library of classic software and systems engineering patterns that an architect or designer can access when creating a new model or modifying an existing one.

The application of patterns to modeling makes sense; there are many very useful patterns that can be expressed and used to build architectural and design models of complex, distributed systems and enterprise applications. Using design patterns for model-driven development can increase the productivity of the architect, designer, and developer, much like the benefits from using patterns when programming.

Using design patterns also significantly increases the readability, understandability, and maintainability of the models themselves—especially when being viewed and interpreted by large, distributed design teams. There have been dozens of useful software patterns already identified, many of which are in common use today. One of the most common is the Observer pattern that is used in almost every modern user-interactive software application (see Figure 1).

Applying patterns to systems architecture is an emerging technique as well, with a few authors and researchers now investigating and documenting them. Rather than focusing on detailed algorithmic or procedural issues, patterns at the systems or enterprise-level work with high-level concepts and network structures. These kinds of patterns can assist architects in creating more understandable views of their enterprise, systems, and applications.

Ad Hoc Pattern Application
Currently, state of the art for most pattern use in modeling tools is a simple copy-and-paste technique. That is, when a model builder recognizes that a particular diagram or system component might be addressed with a known pattern, he or she selects an appropriate pattern from a library and uses the modeling tool to apply it onto the diagram. The modeling tool may automatically access the pattern's definition and prompt the user to fill in the names for placeholder items.

In more advanced cases, it may even analyze the existing diagram in an attempt to automatically apply the pattern to elements already displayed or preselected by the user. These attempts at automation return varying degrees of success, but in all cases it greatly complicates what was once a simple model. There is even more confusion if the tool tries to apply a copy-and-paste pattern to dynamic parts of a model, such as executable activity diagrams and state machine diagrams.

While the copy-and-paste approach has some degree of practicality and success, it falls apart when the same pattern needs to be applied to a large number of model elements and/or diagrams (sometimes called a crosscutting pattern). Even with the previously described automation, there just isn't enough rigor to formally ensure or prove accurate and thorough coverage. Just one missed or inappropriately applied pattern can be enough to seriously undermine the modeled application's accuracy and efficiency.

The next major step in using patterns is borrowed from an emerging technique called aspect-oriented programming (AOP), where source code constructs are analyzed for crosscutting concerns, or common needs or edits, and matched with a set of advanced pattern-matching rules and model fragment templates (see Resources). When rules are matched, their corresponding templates are applied and filled out automatically. When applied to modeling, templates can be recursively applied to make significant changes to a model, from structure down to individual dynamic elements like function calls or signaling.

Additionally, since there are formal syntax specifications and rules about describing the patterns, their matching rules, and their precedence, a significant amount of automation can be supplied and audited with a high degree of confidence.

With the right patterns and automation, productivity can be improved dramatically. For example, an architect or designer could create models for just the positive case for many parts of a system. Then using an aspect pattern and automated application rules, crosscutting special case or error case model fragments (including dynamic parts of a model) can be applied across an entire system model. Figure 2 shows a simple example:

• Consider that a communication must happen between two cooperating tasks or instances of an application.
• In a UML model, this communication might be expressed in a clear, simple state machine diagram showing that a message is sent and a response is expected.
• Since a real-world message may not arrive or not receive a response, the architect or designer must add error checking, timer and time-out processing, and error handling to the model.
• The result is that the once simple, easy-to-understand diagram describing inter-process communications becomes very complex and quite difficult to understand.

Now consider the aspect-oriented model alternative:

• A set of rules is applied listing what to match (a signal send followed by a signal receive) and what to put in (a timer, wait state, timer timeout, or error-handling block).
• The model is modified automatically with the additional model data immediately before code is generated and the modifications are discarded, leaving the model in its pristine state, just as the architect or designer created it.

Added Benefits
Further gains can be achieved by applying aspect patterns across an entire model at the same time. For example, if a pattern is applied that does special timeout tests for inter-process communications, then the model and code that check for the timeout are consistent, correct, and complete in every single case where it is needed. This application also removes the burden of knowing, understanding, and applying huge libraries of patterns on the architects and designers. In many cases, designers will only use the patterns they are familiar with, even when another pattern might be more applicable, or miss some opportunities for pattern application altogether.

When using aspect-oriented modeling techniques, only a few pattern experts (at the project, system, or enterprise level) need to be intimately familiar with different kinds of patterns and their use. Application designers and developers can then work with simplified models, building the positive cases quickly, and allowing the aspect processing to add the repetitive details.

Aspect-oriented modeling is the next step in the use of patterns in model-driven development. Its application can tremendously improve developer productivity and improve the quality and fidelity of the developed model and its resulting application. Organizations wanting to take a more structured and quality-based approach to designing and developing complex systems and applications will benefit from its consistency and structure. Whether using pre-made patterns as is or developing them from scratch (or even something in between), organizations can quickly assemble a domain-specific patterns library that can not only increase productivity, but add another layer of consistency to the development process. Modeling tools that readily support patterns and provide pattern libraries can make this approach very easy and efficient for all concerned.

About the Author
Greg Gorman is vice president of product management for modeling and test products at Telelogic, where he has been employed for 15 years. Greg is responsible for managing the requirements for the Tau family of products, ensuring they meet the current and future needs of Telelogic's customers. He has an object-oriented software architecture and design background and was the lead architect of Tau's DoDAF capability.