Constraints: An Agile Introduction

A constraint is a restriction on the degree of freedom you have in providing a solution. Constraints are effectively global requirements, such as limited development resources or a decision by senior management that restricts the way you develop a system. Constraints can be economic, political, technical, or environmental and pertain to your team resources, schedule, target environment, or to the system itself. Figure 1 presents several potential constraints for the university system. Constraints are documented in a similar manner to business rules and technical requirements.Figure 1. Constraints (summary form).

  • C24 The system will work on our existing technical infrastructure – no new technologies will be introduced.
  • C56 The system will only use the data contained in the existing corporate database.
  • C73 The system shall be available 99.99% of the time for any 24-hour period.
  • C76 All master’s degree programs must include the development of a thesis.

An interesting thing about Figure 1 is that it contains two constraints, C73 and C76, that could also be identified as a technical requirement and a business rule respectively. Constraints can be a little confusing because of their overlap with business rules and technical requirements. Don’t worry about it. The important thing is that you’ve identified the requirement, if you happen to mis-categorize it as a constraint instead of a business rule that’s perfectly okay, the world isn’t going to end as a result (unless of course you’re working on a nuclear missile guidance system). I wouldn’t identify the same requirement as both a business rule and a constraint, that would be busy work, but I wouldn’t waste any time arguing over whether something is a constraint or another type of requirement.

As with business rules, you identify constraints as you are developing other artifacts, such as your use case model and user interface.

The Object Constraint Language (OCL)

One way to describe business rules, technical requirements, or constraints, is via the Object Constraint Language (OCL). The OCL is a formal language similar to structured English to express side-effect-free constraints within UML models (Warner and Kleppe 1999). OCL can appear on any UML diagram or in the supporting documentation describing a diagram, such as business rule definitions. It can even be used on non-UML diagrams for that matter. OCL can be used for a wide variety of purposes, including specifying the invariants of classes, preconditions and postconditions on operations, and constraints on operations. The reality is that a graphical model, such as a UML class diagram, isn’t sufficient for a precise and unambiguous specification. You must describe additional constraints about the objects in the model, constraints that are defined in your supplementary specification.

I rarely use OCL when I’m modeling. First, few people know how to read OCL, let alone write it, so you’re restricting the audience of your models when you use it. Second, it’s complex. OCL statements are depicted on UML diagrams in the format “{constraint description},” where the constraint description may be in any format, including predicate calculus. I personally find that free-form text is far more effective. Third, if I want to describe rules in such a way that I can generate working software from them I’ll use a real programming language such as Java or C# to do it.

The OCL was an interesting concept but it hasn’t been adopted by the industry. Because it shows no signs of being adopted any time soon in my opinion it isn’t worth the effort to learn.

 

Source

This artifact description is excerpted from Chapter 7 of The Object Primer 3rd Edition: Agile Model Driven Development with UML 2.