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) . 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
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
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
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.
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 contradict each other, because there is no value for the attribute
i that satisfies both constraints.
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.
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
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
Figure 6. Constraint Elicitation view
Figure 7. Diagram Editor (Model Explorer)
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
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
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.
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:
- 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
- Use one of the provided remedial patterns to fix the issue, as shown in Figure 12.
Figure 12. NoCyclicDependency model element
- 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).
- Generate the necessary constraint in OCL, as shown in Figures 13a and 13b.
Figure 13a. No cyclic dependency allowed
- 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.
- 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
- 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
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.
- By the same authors, read the tutorial Using the IBM Constraint Patterns and Consistency Analysis extension: A step by step guide.
- Visit the Rational software area on developerWorks for technical resources and best practices for Rational Software Delivery Platform products.
- Subscribe to the IBM developerWorks newsletter, a weekly update on the best of developerWorks tutorials, articles, downloads, community activities, webcasts and events.
- Subscribe to the developerWorks Rational zone newsletter. Keep up with developerWorks Rational content. Every other week, you'll receive updates on the latest technical resources and best practices for the Rational Software Delivery Platform.
- Subscribe to the Rational Edge newsletter for articles on the concepts behind effective software development.
- Browse the technology bookstore for books on these and other technical topics.
- Learn about strategic reuse with the Strategic Reuse with Asset-Based Development Redbook
- Discover MDD, PBE, and SOA in the Using model-driven development and pattern-based engineering to design SOA tutorial series.
- Apply your knowledge with information in the Formally speaking: How to apply OCL article.
- You can find additional information on OCL and the OCL specification at http://www.omg.org
- Take a Pattern Implementation Workshop with IBM Rational Software Architect V7.0
- Discover the Essentials of Rational Software Architect with this course.
- Learn how to architect services with this course.
-  Read the final OCL specification at the OMG Web site.
-  M. Wahler. Using Patterns to Develop Consistent Design Constraints. PhD thesis, ETH Zurich, 2008.
-  A. D. Brucker and B. Wolff. The HOL-OCL Book. Technical Report 525, ETH Zurich, Switzerland, 2006.
-  M. Gogolla, J. Bohling, and M. Richters. Validating UML and OCL Models in USE by Automatic Snapshot Generation. Software and Systems Modeling, 4(4):386â398, 2005.
-  Learn all about OCL in The Object Constraint Language. Second Edition by A. Kleppe and J. Warmer (Addison-Wesley, 2003).
-  Learn all about MDA in MDA Explained. The Model Driven Architecture: Practice and Promise by A. Kleppe, J. Warmer, and W. Bast (Addison-Wesley, 2003).
-  M. Wahler, J. Koehler, and A. D. Brucker. Model-Driven Constraint Engineering. Electronic Communications of the EASST, 5, 2007.
Get products and technologies
- Download trial versions of IBM Rational software.
- Download these IBM product evaluation versions and get your hands on application development tools and middleware products from DB2®, Lotus®, Tivoli®, and WebSphere®.
- Join the developerWorks Community in forums, blogs, podcasts, wikis, and more.
- Rational Software Architect, Data Architect, Software Modeler, Application Developer and Web Developer forum: Ask questions about Rational Software Architect and other architecture management products.