5.3 Attribute Data Types

The set of values an attribute can take on constitutes its data type. Each attribute must have a data type.

Tools today capture this information through dialog screens and in some cases by data type definition as a part of the action language. Since there is no compact standard way to capture all this information, we shall use an informal textual notation.

Data types in Executable UML are based on a two-level scheme:

• Domain-specific data types, which define the type in terms of the domain. Hence, the online bookstore domain has attributes of type Currency and MailingAddress.

• Core data types, which are universal types defined by Executable UML.

Each data type has a domain-specific name, used on the class diagram, and a definition: the formal, detailed part.

5.3.1 Core Data Types

Definition: A core data type is a fundamental datatype from which other domain-specific datatypes can be defined.

Core data types include boolean, string, integer, real, date, and timestamp. We summarize these in Figure 5.3 overleaf.

Figure 5.3. Core Data Types

5.3.2 Domain-Specific Data Types

While attributes may be defined in terms of core data types, by defining attributes in terms of individual domain-specific data types, the developer can specify precisely the values that are legal for an attribute and can identify those attributes that can take on the same kinds of values.

Definition: A domain-specific data type is a definition of the set of legal values that can be assigned to attributes in a domain model.

Domain-specific data types can represent subsets of values of the core data type (for example, a range of positive integers). In addition, domain-specific data types can be defined to represent symbolic enumerations and composite values.

In all cases, the assignment of domain-specific data types to actual implementation data types is handled by the model compiler, based on the specific performance properties supported by that model compiler.

Numeric types.

Domain-specific numeric types provide for values that have units, range, and precision.

The data type Currency may be defined, in keeping with the example above:

type Currency is real range [0..100000] precision 0.01

which specifies that Currency is of type numeric, with a range from 0 to 100000, with a precision of 0.01.

String types.

String types provide for values that contain textual data. These can be specified in terms of a size and a pattern.

type NorthAmericanTelephoneNumber is symbolic pattern "nnn-nnn-nnnn"
type postalCode is symbolic length 6

A proper specification for a domain-specific type avoids stating how the value is to be stored because a type may be transformed into different implementations. For example, the Currency values between $0.00 and $1000.00 could be expressed as an integer between 0 and 100,000 it does not have to be stored as a real. Similarly, a SupplyVoltage that can vary between 0.7 and 25 volts can be represented as an integer 0..253 (and stored in a byte!).

Enumerated types.

Enumerated types are described by a list of values.

type CompassPoints is (North, East, South, West)

Composite values.

A type may be composite, but the corresponding attribute must always be treated by the domain as a single unit. For example, MailingAddress and TelephoneNumber are valid types, but no operations in the domain can access the city as a part of the mailing address, nor an area code as a part of the telephone number. (Another domain, on the other hand, may choose to treat these attributes as objects, and their components as separate attributes.)

5.3.3 Using Types

Each attribute has a type. These are shown in the class definition (and the class diagram as in Figure 5.4) as the attribute name, type, and an optional initial value.

Figure 5.4. Class Box with All Components

Hence, for a class Customer

purchasesMade : Count = 0

specifies that the attribute Customer.purchasesMade has a type, Count, and asserts an initial (default) value of zero.

Syntax vs. semantics.

Define attribute types in terms of the meaning of the data (the semantics), not merely in the form of the data. Good models should use domain-specific types as much as possible and refrain from using the core data types if more meaning is available. Hence, defining an attribute merely as real is not as good as using a domain-specific type, such as Currency or SupplyVoltage.