The DEAT Business Rule Pattern Language

Russell R. Hurlbut, Ph.D.

Previous | Table of Contents | Next

Rule Pattern 6: Multiplicity

Problem Describing Cardinality and Collection Count Restrictions

The state of an entity may require that a value be assigned to an attribute because it provides crucial processing information. In certain situations, such an attribute represents a collection of values in which not only is at least one value required, but additional constraint as to exactly how may values should be present must be stipulated.


Multiplicity is one of the model elements defined in the Data Types package of the UML specification. The UML Multiplicity model element is defined as a collection of one or more ranges of integers representing upper and lower bounds. This representation allows modeling of the most general case, but cannot by itself represent all situations. Thus a required attribute can be specified as having a single multiplicity range with an upper and lower bound of one. However, specification or a scalar value can be more succinctly expressed as either required or optional. If a global default for all attributes is set to optional, then only the designation of mandatory is necessary.

Enumeration of common multiplicity types can also be defined using the Domain business rule pattern. Such a domain should include optional (0..1), required scalar (1..1), any (0..n), required vector (1..n). By integrating the use of an Interval business rule pattern repeating counts such as only even, or only divisible by five can be expressed in concise notation.

Example Employee Name

This example represents application of a mandatory scalar. A name is required for each employee. Although the name is comprised of several component parts, the presence of a name may be specified as required as a whole. Additional business rules may apply to these various parts that may also include reapplication of the multiplicity rule, such as first name and last name are required, but middle name, prefix (e.g. Dr.) and suffix (e.g. Jr.) are optional. In most cases, specification of the component parts is sufficient. This example specifies both for illustration purposes. Exceptional situations may occur where a person only has a first name or the name is an unpronounceable glyph and is captured only as an image. If these exceptional situations occur with sufficient frequency, then all fields may be optional and satisfactory combinations of component attributes may need to be specified using the Association business rule pattern.
Employee Name Parameters and Case Values


required scalar


required scalar

Employee.Name.First required scalar

Input Employee.First Russ
Employee.Last unknown
Employee.Suffix Ph.D.
Output   Invalid name

Example Excursion Booking

A high adventure excursion outfitter sponsors a rafting trip that can use one of two sized rafts. The first holds up to twelve people and the second up to thirty people. For economic reasons, a minimum of six is required on the smaller craft and a minimum of eighteen is required on the larger one. This example demonstrates how one parameter can be used to specify another. The capacity is fixed for a particular type of raft, but the lower end may vary depending on other factors, such as the break even cost and excursion fee for each person.

Excursion Booking Parameters and Case Values


[Breakeven bookings on small raft] - [small raft capacity]

[Breakeven bookings on large raft] - [large raft capacity]

Parameter Binding Input:
Breakeven bookings on small raft


Breakeven bookings on large raft


Small raft capacity 12
Large raft capacity 30

Parameter Binding Output:
Bookings 6 - 12; 18 - 30

UML Representation and Related Patterns

The Multiplicity business rule patterns may collaborate with the Domain and Interval business rule patterns to extend the expressive capabilities of UML notation.

UML Representation of Multiplicity Pattern

Previous | Table of Contents | Next

Copyright 1998 Expertech.Ltd. All Rights Reserved.