Previous | Table of Contents | Next
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.
Solution
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.
Parameters:
|
Employee.Name
|
required scalar |
|
Employee.Name.Last |
required scalar |
|
Employee.Name.First |
required scalar |
Case:
|
Input |
Employee.First |
Russ |
|
Employee.Last
|
unknown | |
|
Employee.Suffix
|
Ph.D. | |
|
Output |
|
Invalid name |
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.
Parameters:
|
Bookings
|
[Breakeven bookings on small raft] - [small raft capacity] |
|
[Breakeven bookings on large raft] - [large raft capacity] |
Parameter Binding Input:
|
Breakeven bookings on
small raft |
6 |
|
Breakeven bookings on large raft |
18 |
|
Small raft
capacity |
12 |
|
Large raft
capacity |
30 |
Parameter Binding Output:
|
Bookings |
6 - 12; 18 - 30 |
The Multiplicity business rule patterns may collaborate with the Domain and Interval business rule patterns to extend the expressive capabilities of UML notation.
Previous | Table of Contents | Next