Using IBM Constraint Patterns and Consistency Analysis

An Overview

This article discusses IBM® Constraint Patterns and Consistency Analysis, an extension to IBM® Rational® Software Architect. This tool facilitates pattern-based, consistency-preserving refinement of UML class models. It supports model developers in elicitation, concise specification, consistency analysis, and code generation of constraints in class models. In this way, you are able to simplify how you can create more precise models, leveraging OCL and constraints in a proven best practice and automated approach.


Michael Wahler (, Researcher, IBM

Michael Wahler is a doctoral student in the Business Integration Technologies group at the IBM Zurich Research Laboratory. He received a diploma in computer science from the Technical University of Munich, Germany, in 2003, and submitted a Ph.D. thesis in computer science at the Swiss Federal Institute of Technology Zurich, Switzerland, in January 2008.
Michael’s research focuses on engineering approaches for developing reliable software, particularly involving model-driven software development. He is currently working in the area of data modeling, for which he is developing a pattern approach for concise and consistency-preserving refinement of class models.

Lee Ackerman, Sr. Product Manager, IBM

Lee AckermanLee Ackerman is a Sr. Product Manager with the Rational Expertise Development & Innovation team. He focuses on creating intellectual capital assets that enable users of the Rational model driven development tooling to succeed in creating J2EE and SOA solutions.

developerWorks Contributing author

Scott Schneider (, Senior Software Engineer, IBM

Scott SchneiderScott E. Schneider, residing and working in close proximity to Research Triangle Park in North Carolina, leads pattern tooling development within IBM Rational, specializing on the specification and automation of model-operative patterns. Scott holds a B.S. in Electrical Engineering from the Georgia Institute of Technology, with a specialty in digital signal processing and computer science. Scott is an associate editor and columnist of the International Journal of Patterns, and is a frequent speaker at technical conferences such as EclipseCon, EclipseWorld, and the IBM Rational Software Development Conference.

20 May 2008

Also available in Chinese


When you use UML models as the blueprints for a system, or as input to a transformation -- for example, in Model Driven Architecture (MDA) -- a key for success is to provide appropriate levels of precision within the model. A proven approach to add precision to a model is through the use of constraints and OCL. However, refining class models with textual constraints is a time-consuming and error-prone task. At worst, constraint specifications can be inadvertently inconsistent because of contradictory constraints.

When you pursue a Model Driven Development (MDD) approach to software development, your success consistently relies on the use of abstractions. As such, you can look to use a number of models when creating a solution. Each of the models exists at a particular level of abstraction, highlighting certain aspects of the solution while leaving out details that are unimportant at that moment. In some cases, you can use automation to migrate between the levels of abstraction.

Typically, you use your models for three key purposes:

  • Capturing or documenting a design
  • Communicating a solution to others
  • Generating other artifacts

However, you often neglect (or are unable) to add in the appropriate level of precision into your models. As such, this restricts the effectiveness of models in all three categories. In the case of documenting a design, the value of the design is limited by how precise the model is. When you communicate with others, if the model is not precise enough, then it is open to multiple interpretations. Finally, in the case of generating artifacts from the model, a lack of precision in the model will limit the detail and completeness of the output, increase the complexity of associated automations, or both.

You can increase model precision through the specification and assemblage of model constraints. Model constraints are constraints that restrict models and their elements, further elaborating the intentions of the modeler. These constraints annotate models with an additional strengthening layer of semantics beyond what is expressible solely in base UML.

IBM has developed a novel MDD and pattern-based engineering (PBE) process, along with associated tooling, which simplifies and automates the use of constraints within a model. This means that you are able to overcome the hurdles that dissuade modelers from using constraints. This process and tooling lowers the skill requirement for using constraints, simplifies the application of constraints, and does so in such a way that the constraints are applied in a consistent manner. Applying constraints in a consistent manner means that you have a set of constraints that does not contain any contradictory constraints.

The core of this process comprises a pattern-based approach that allows you to refine class models with constraints while preserving the consistency of the models. Because the success of MDD strongly depends on tool support, this set of plug-ins for IBM Rational Software Architect enables consistency-preserving refinement of UML class models with constraints in the Object Constraint Language (OCL) [1]. These plug-ins are bundled as the IBM Constraint Patterns and Consistency Analysis asset. This article gives you an overview of its features and benefits. In addition, if you are interested in building your own patterns within Rational Software Architect, these patterns and automations will provide you with an idea of what is possible.

Overview of IBM Constraint Patterns and Consistency Analysis

The IBM Constraint Patterns and Consistency Analysis tool supports you in developing concise and consistent constraint specifications for class models. This results in models that are more precise, leading to:

  • Better Communication
  • Improved Designs
  • Successful generation of related artifacts

The tool is comprised of four key components that enable you to achieve these results. These components are built to take advantage of a number of components from Rational Software Architect, as well as the underlying Eclipse platform. The components and supporting Rational Software Architect elements are shown in Figure 1.

Figure 1. IBM Constraint Patterns and Consistency Analysis components
Solution above Rational Software Architect, Eclipse

Constraint Elicitation

When developing software, you often look to use patterns -- proven best practice solutions to known problems, within a given context -- as you build your solution. It is also important to keep in mind that there can be anti-patterns. An anti-pattern is a proven worst practice, such as "violating object state encapsulation with publicly exposed instance variables." As such, you look to leverage patterns while avoiding anti-patterns.

Typically, an anti-pattern naturally leads to one or more patterns that can be applied to remedy the undesirable situation. To remedy the previously mentioned anti-pattern, you can "hide the exposed instance variables and provide publicly exposed mutator and accessor methods as appropriate to access the object state."

The constraint elicitation component searches class models for occurrences of predefined anti-patterns. These anti-patterns comprise model elements that are too loosely defined, and thus potentially require refinement by adding textual constraints.

An example of an anti-pattern is an unlimited bound for the upper multiplicity of an association end (typically denoted by an asterisk). However, the multiplicity of associations often is not arbitrary, but depends on attribute values, which cannot be expressed with graphical modeling languages such as UML class models.

The Constraint Elicitation tab, shown in Figure 2, displays a view in which the analysis results (a listing of the anti-patterns detected) are presented in a table.

Figure 2. Detected anti-patterns
context, problem, priority, and remedial pattern

Each result comprises a context (for example, the class that matches an anti-pattern), and a description of the problem. Not all results represent actual problems; however, you should browse the list, ignore irrelevant results, and react to actual problems. To this end, each analysis result offers a context menu from which a pattern solution for the respective problem can be automatically instantiated, as explained in the following subsection.

Repository of Constraint Patterns

Constraints are not used as often as they should be when you model solutions. The reasons for this omission vary, but can include the following:

  • Awareness: People are not aware of constraints and the value that they add to a model
  • Time: People know that they should use constraints, but it can be time consuming to add them to the model
  • Expertise: Even having time and awareness, some will not use constraints because they lack the expertise to use them correctly. This can include both constraints in general (for instance, not knowing what makes a good constraint), as well as a lack of knowledge regarding how to implement a constraint in a model.

To address these issues, IBM Constraint Patterns and Consistency Analysis provides a repository of constraint patterns that encapsulate the expertise needed to easily and quickly add constraints to a model. Constraint patterns 7 are predefined constraint expressions that can be instantiated and subsequently configured for developing constraints in a concise way. They are an important complement to the constraint elicitation component, because you can couple each anti-pattern with a set of constraint patterns that can be instantiated to eliminate anti-patterns in the model.

Figure 3 provides an overview of the patterns supported by IBM Constraint Patterns and Consistency Analysis.

Figure 3. Supported Patterns
patterns listed in bracket form

Rational Software Architect provides a framework for arbitrary patterns with a standardized interface, both internally for developers and externally for users. IBM Constraint Patterns and Consistency Analysis builds on this framework and adds the library of composable constraint patterns introduced in Model-Driven Constraint Engineering7. This library is also extensible, which makes it possible to add further constraint patterns in the future.

Furthermore, your library of constraint patterns contains dependencies between each pair of patterns. To this end, you store with each pattern the assumptions under which the pattern can be instantiated in a consistency-preserving way. Whenever a parameter value of a pattern instance is changed, IBM Constraint Patterns and Consistency Analysis evaluates whether the instance preserves the consistency of the model.

Consistency Analysis

To this point, this article has discussed components that find issues with a model, and then make it quick and easy to fix them through constraint pattern application. However, you also need to ensure that the constraints within a model are applied consistently. Therefore, IBM Constraint Patterns and Consistency Analysis provides a consistency analysis that warns of inconsistencies in a given pattern-based constraint specification. Inconsistencies occur when constraints contradict each other. For example, the constraints i>=0 and i<0 contradict each other, because there is no value for the attribute i that satisfies both constraints.


Note: The reason that the analysis can only say "yes" or "don’t know" is that the semantics of the patterns is defined in terms of OCL, which is an undecidable language. This means that it defies automatic and complete consistency analysis.

In the case that consistency cannot be shown, you can export the model and use an external tool such as USE 4 or HOL-OCL 3 to prove or refute consistency, as described in 2. Alternatively, you can manually check whether constraints for which consistency cannot be shown are consistent. However, OCL expertise is required for this (refer to 2).

The analysis uses the consistency assumptions stored in the pattern repository. For each pattern, the analysis checks whether the assumptions hold or not. In the first case, the constraint specification is consistent; in the second case, no statement about consistency can be made.

Code Generation

Rational Software Architect contains a transformation framework that provides support for developing and executing model transformations. IBM Constraint Patterns and Consistency Analysis builds on this framework and provides model transformations that transform pattern instances into sentences in a formal language.

So far, you have implemented a transformation to OCL according to Model-Driven Constraint Engineering7. However, IBM Constraint Patterns and Consistency Analysis can be easily extended with transformations to specification languages such as Alloy, Eiffel, or Java™ Modeling Language (JML).

Using IBM Constraint Patterns and Consistency Analysis

At a high level, when using IBM Constraint Patterns and Consistency Analysis, you see a workflow as depicted in Figure 4.

Figure 4. Elicitation, specification, analysis, and then generation
workflow direction indicated with arrows

When using the tool within Rational Software Architect, you will interact with its components in the following views, shown in Figures 5, 6, and 7.

Figure 5. Pattern Explorer
Constraint Patterns is highlighted
Figure 6. Constraint Elicitation view
list in table
Figure 7. Diagram Editor (Model Explorer)
diagram with note

Click to view the larger version of this image

An example pattern that is included is NoCyclicDependency. This pattern is used to forbid cyclic dependencies between model elements (for example, there is no link from one object to itself).

Figure 8 shows a screenshot of Rational Software Architect with the IBM Constraint Patterns and Consistency Analysis plug-ins. The largest view contains a small class model and an instance of the NoCyclicDependency pattern. In this view, models can be manipulated and pattern instances be parameterized via drag-and-drop. Underneath, the Constraint Elicitation view shows the results of the constraint elicitation component. As explained, constraint patterns can be instantiated from this view using each item's context menu.

Figure 8. Screenshot of the IBM Constraint Patterns and Consistency Analysis prototype
window with four views

Click to view the larger version of this image

The bottom part of the window contains two more views. First, the results of the consistency analysis are shown in the bottom left part in the Problems view of Rational Software Architect. The second view is the aforementioned Pattern Explorer, which displays available patterns along with a description, and provides a drag-and-drop instantiation mechanism.

Following is a typical scenario for using IBM Constraint Patterns and Consistency Analysis.

Consider the following simple class diagram, shown in Figure 9. A quick glance at the diagram may lead the modeler to think that they have successfully modeled the relationship between Managers and Employees. However, as the model currently stands, it would be possible for a Manager to work for himself or herself. An experienced modeler may find this issue quickly, but others may not notice until after the code is generated.

Figure 9. Employee and Manager relationship diagram
model diagram with five elements

If you are comfortable in writing OCL, you can add a note to the model detailing the fact that a manager cannot manage herself, as shown in Figure 10.

Figure 10. No cyclic dependency allowed for property.
note on pink post-it

You have now added yet another level of required expertise. In addition to spotting the anti-pattern and knowing how to fix the solution, you also need to know how to detail the solution using OCL.

In contrast, by using IBM Constraint Patterns and Consistency Analysis, you can greatly simplify this scenario as follows:

  1. Use the Constraint Elicitation to identify anti-patterns in your model. In this case, the tool notes that you have a cyclic dependency in the model, as shown in Figure 11.
    Figure 11. List of anti-patterns
    property worksFor is part of reflexive association

    Click to view the larger version of this image

  2. Use one of the provided remedial patterns to fix the issue, as shown in Figure 12.
    Figure 12. NoCyclicDependency model element
    property=worksFor, context=Manager
  3. Use the consistency analysis feature to ensure that you have used constraints consistently in your model (this is overkill in this simple example, but included here for completeness).
  4. Generate the necessary constraint in OCL, as shown in Figures 13a and 13b.
    Figure 13a. No cyclic dependency allowed
    General tab with constraint Name, Language, Value
    Figure 13b.
    General tab with constraint Name, Language, Value
  5. There is a cheat sheet that is installed with IBM Constraint Patterns and Consistency Analysis that guides you (as a developer) through the whole process. You can display the cheat sheet by choosing Help > Cheat Sheets.
  6. In the Other category, you can find a cheat sheet labeled Refine class models with constraint patterns, as shown in Figure 14. Click OK.
    Figure 14. Select the cheat sheet to open
    Select from list or file
  7. A new view containing the cheat sheet opens, as shown in Figure 15. The cheat sheet guides you step-by-step through the whole process. Please consult the Rational Software Architect documentation if you need help with using cheat sheets.
    Figure 15. Refine class models with constraint patterns Cheat Sheet
    view with instructions and steps

Conclusion and Future Work

This article has presented IBM Constraint Patterns and Consistency Analysis, an extension to Rational Software Architect that allows for consistent model refinement using constraint patterns. By using the tool, you are able to make your models more precise, which results in better designs, clearer communication, and better code generation. In addition, you are able to accomplish these results while lowering the skill requirements needed for creating more precise models.

The tool is compatible with other specification languages (instead of OCL) by implementing additional model transformations and leveraging those in the code generation process.

For more information, please take a look at the step-by-step tutorial, as listed under Resources.



Get products and technologies



developerWorks: Sign in

Required fields are indicated with an asterisk (*).

Need an IBM ID?
Forgot your IBM ID?

Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name

The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.


All information submitted is secure.

Dig deeper into Rational software on developerWorks

ArticleTitle=Using IBM Constraint Patterns and Consistency Analysis