Many relations are, however, relations between properties that belong to different entities. Since direct relations between properties of different entities are not allowed, such relations must be expressed as rules. Rules can be represented as functions or logical expres- sions, either in the resource model graph or in a special rule section. Two examples are given in Fig. 7.20. Example 1: *dye Type DyeRun *exposureTime(dyeType,fabricType) *fabricType Fabric Example 2: Hatch *hatchState{open,close} Dyeing Tank hatchState=open -> valveState=closed Dye Valve *valveState{open,close} Fig. 7.20 Specifying rules in resource model graphs Both examples are excerpts from a larger resource model of a fabric dyeing processing system that is described (in natural language) in Selic et al. (1994). Example 1 says that when a dyeing process is run for a particular combination of dye and fabric, the time the fabric must be exposed to the dye is a function of both the type of fabric and the type of dye. This relation is visualized in the graph by defining exposure time as a property of a dye run, and expressing that property as a function. When this function is computed for a particular type of dye and fabric, it returns a value for exposure time. Example 2 shows that the tank used to dye the fabric consists of a hatch through which the fabric is inserted in the tank, and a valve for filling dye into the tank. The valve must be closed as long as the hatch is open. This requirement is mod- elled as a relation between Hatch and DyeValve, expressed as a rule. 7.3 Resource Model Notation 7.3.4 Property Specification Figure 7.21 defines all syntactical elements used in property specifications. identifier Names for properties and values. Initial letter is lowercase. The list symbol. Used to list properties or values, e.g. the properties firstName and lastName: {firstName, lastName} or some values of firstName, e.g. Thomas, Nelson and Mahatma: {"Thomas", "Nelson", "Mahatma"} Note that such statements can be ambiguous, unless you prefix