Adding Associations and Attributes
Domain Model: Adding Associations
Introduction
It is useful to identify those associations of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development, and which aid in comprehending the domain model.
Associations
An association is a relationship between types (or more specifically, instances of those types) that indicates some meaningful and interesting connection. In the UML associations are defined as "the semantic relationship between two or more classifiers that involve connections among their instances."
Criteria for Useful Associations
Associations worth noting usually imply knowledge of a relationship that needs to be preserved for some duration—it could be milliseconds or years, depending on context. In other words, between what objects do we need to have some memory of a relationship? For example, do we need to remember what SalenLineItem instances are associated with a Sale instance? Definitely, otherwise it would not be possible to reconstruct a sale, print a receipt, or calculate a sale total.
The UML Association Notation
An association is represented as a line between classes with an association name. The association is inherently bidirectional, meaning that from instances of either class, logical traversal to the other is possible.This traversal is purely abstract; it is not a statement about connections between software entities.
The ends of an association may contain a multiplicity expression indicating the numerical relationship between instances of the classes.
An optional "reading direction arrow" indicates the direction to read the association name; it does not indicate direction of visibility or navigation.
If not present, it is conventional to read the association from left to right or top to bottom, although the UML does not make this a rule.
Finding Associations—Common Associations List
High Priority Associations
Here are some high-priority association categories that are invariably useful to include in a domain model:
• A is a physical or logical part of B.
• A is physically or logically contained in/on B.
• A is recorded in B.
Roles
Each end of an association is called a role. Roles may optionally have:
• name
• multiplicity expression
• navigability
Multiplicity
Multiplicity defines how many instances of a class A can be associated with one instance of a class B.
For example, a single instance of a Store can be associated with "many" (zero or more, indicated by the * ) Item instances. some examples:
The multiplicity value is dependent on our interest as a modeler and software developer, because it communicates a domain constraint that will be (or could be) reflected in software.
Naming Associations
Association names should start with a capital letter, since an association repre- sents a classifier of links between instances; in the UML, classifiers should start with a capital letter. Two common and equally legal formats for a compound association name are:
• Paid-by
• PaidBy
In Figure 11.6, the default direction to read an association name is left to right or top to bottom. This is not a UML default, but a common convention:
Multiple Associations Between Two Types
Two types may have multiple associations between them; this is not uncommon. There is no outstanding example in our POS case study, but an example from the domain of the airline is the relationships between a Flight (or perhaps more precisely, a FlightLeg) and an Airport (see Figure 11.7); the flying-to and flying- from associations are distinctly different relationships, which should be shown separately.
|
Case Study: NextGen POS Domain Model Associations |
Domain Model: Adding Attributes
Introduction
It is useful to identify those attributes of conceptual classes that are needed to satisfy the information requirements of the current scenarios under development.
Attributes
Attributes are the logical data value of an object.
|
Include the following attributes in a domain model: Those for which the requirements (for example, use cases) suggest or imply a need to remember information. |
For example, a receipt (which reports the information of a sale) normally includes a date and time, and management wants to know the dates and times of sales for a variety of reasons. Consequently, the Sale conceptual class needs a date and time attribute.
UML Attribute Notations
Valid attribute types
There are some things that should not be represented as attributes, but rather as associations.
Keep attributes simple
Intuitively, most simple attribute types are what are often thought of as primitive data types, such as numbers. The type of an attribute should not normally be a complex domain concept, such as a Sale or Airport. For example, the follow- ing currentRegister attribute in the Cashier class in Figure 12.2 is undesirable because its type is meant to be a Register, which is not a simple attribute type (such as Number or String). The most useful way to express that a Cashier uses a Register is with an association, not with an attribute.
The attributes in a domain model should preferably be simple attributes or data types.
- Very common attribute data types include: Boolean, Date, Number, String (Text), Time
- Other common types include: Address, Color, Geometries (Point, Rectangle), Phone Number, Social Security Number, Universal Product Code (UPC), SKU, ZIP or postal codes, enumerated types
To repeat an earlier example, a common confusion is modeling a complex domain concept as an attribute. To illustrate, a destination airport is not really a string; it is a complex thing that occupies many square kilometers of space. Therefore, Flight should be related to Airport via an association, not with an attribute, as shown in Figure 12.3.
Relate conceptual classes with an association, not with an attribute.
Conceptual vs. Implementation Perspectives: What About Attributes in Code?
The restriction that attributes in the domain model be only of simple data types does not imply that C++ or Java attributes (data members, instance fields) must only be of simple, primitive data types. The domain model focuses on pure conceptual statements about a problem domain, not software components.
Later, during design and implementation work, it will be seen that the associations between objects expressed in the domain model will often be implemented as attributes that reference other complex software objects. However, this is but one of a number of possible design solutions to implement an association, and so the decision should be deferred during domain modeling.
Data types
Attributes should generally be data types. This is a UML term that implies a set of values for which unique identity is not meaningful (in the context of our model or system) [RJB99]. For example, it is not (usually) meaningful to distin- guish between:
• Separate instances of the Number 5.
• Separate instances of the String 'cat'.
• Separate instances of PhoneNumber that contain the same number.
• Separate instances of Address that contain the same address.
In terms of software, there are few situations where one would compare the memory addresses of instances of Number, String, PhoneNumber, or Address; only value-based comparisons are relevant. By contrast, it is conceivable to compare the memory addresses of Person instances, and to distinguish them, even if they had the same attribute values, because their unique identity is important.
By contrast, it is meaningful to distinguish (by identity) between two separate instances of a Person whose names are both "Jill Smith" because the two instances can represent separate individuals with the same name.
Thus, all primitive types (number, string) are UML data types, but not all data types are primitives. For example, PhoneNumber is a non-primitive data type.
The notion of data types can get subtle. As a rule of thumb, stick to the basic test of "simple" attribute types: Make it an attribute if it is naturally thought of as number, string, boolean, date, or time (and so on); otherwise, represent it as a separate conceptual class.
Non-primitive Data type classes
The type of an attribute may be expressed as a non-primitive class in its own right in a domain model. For example, in the POS system there is an item identifier. It is typically viewed as just a number. So should it be represented as a non-primitive class? Apply this guideline:
|
|
Applying these guidelines to the POS domain model attributes yields the follow- ing analysis:
• The item identifier is an abstraction of various common coding schemes, including UPC-A, UPC-E, and the family of EAN schemes. These numeric coding schemes have subparts identifying the manufacturer, product, coun- try (for EAN), and a check-sum digit for validation. Therefore, there should be a non-primitive ItemID class, because it satisfies many of the guidelines above.
• The price and amount attributes should be non-primitive Quantity or Money classes because they are quantities in a unit of currency.
• The address attribute should be a non-primitive Address class because it has separate sections.
The classes ItemID, Address, and Quantity are data types (unique identity of instances is not meaningful) but they are worth considering as separate classes because of their qualities.
Where to Illustrate Data Type Classes?
Should the ItemID class be shown as a separate conceptual class in a domain model? It depends on what you want to emphasize in the diagram. Since ItemID is a data type (unique identity of instances is not important), it may be shown in the attribute compartment of the class box, as shown in Figure 12.4. But since it is a non-primitive class, with its own attributes and associations, it may be interesting to show it as a conceptual class in its own box. There is no correct answer; it depends on how the domain model is being used as a tool of communication, and the significance of the concept in the domain.
Design Creep: No attributes as foreign Key
Attributes should not be used to relate conceptual classes in the domain model. The most common violation of this principle is to add a kind of foreign key attribute, as is typically done in relational database designs, in order to associate two types. For example, in Figure 12.5 the currentRegisterNumber attribute in the Cashier class is undesirable because its purpose is to relate the Cashier to a Register object. The better way to express that a Cashier uses a Register is with an association, not with a foreign key attribute. Once again, relate types with an association, not with an attribute.
Modeling attributes quantities and Units
Most numeric quantities should not be represented as plain numbers. Consider price or velocity. These are quantities with associated units, and it is common to require knowing the unit, and to support conversions. The NextGen POS soft- ware is for an international market and needs to support prices in multiple currencies. In the general case, the solution is to represent Quantity as a distinct conceptual class, with an associated Unit [Fowler96]. Since quantities are considered data types (unique identity of instances is not important), it is accept- able to collapse their illustration into the attribute section of the class box (see Figure 12.6). It is also common to show Quantity specializations. Money is a kind of quantity whose units are currencies. Weight is a quantity with units such as kilograms or pounds.
Attributes in the NextGen Domain Model
