Page 337 -

308 PART THREE CONVENTIONAL METHODS FOR SOFTWARE ENGINEERING

FIGURE 12.7
An expanded
ERD Licenses Dealership Stocks

Manufacturer Builds Car

Contracts Transports

Shipper

the context implied by the ERD, the specification of the data object car (data object
table in Figure 12.6) would be radically different from the earlier specification (Figure
12.3). By examining the symbols at the end of the connection line between objects,
it can be seen that the modality of both occurrences is mandatory (the vertical lines).
Expanding the model, we represent a grossly oversimplified ERD (Figure 12.7) of
the distribution element of the automobile business. New data objects, shipper and
Develop the ERD dealership, are introduced. In addition, new relationships—transports, contracts,
iteratively by refining
both data objects and licenses, and stocks—indicate how the data objects shown in the figure associate with
the relationships that one another. Tables for each of the data objects contained in the ERD would have to
connect them. be developed according to the rules introduced earlier in this chapter.
In addition to the basic ERD notation introduced in Figures 12.6 and 12.7, the ana-
lyst can represent data object type hierarchies. In many instances, a data object may
actually represent a class or category of information. For example, the data object
car can be categorized as domestic, European, or Asian. The ERD notation shown
in Figure 12.8 represents this categorization in the form of a hierarchy [ROS85].
ERD notation also provides a mechanism that represents the associativity between
objects. An associative data object is represented as shown in Figure 12.9. In the fig-
ure, each of the data objects that model the individual subsystems is associated with
the data object car.