{[ promptMessage ]}

Bookmark it

{[ promptMessage ]}

It is also possible to assign a type to f of the form

Info iconThis preview shows page 1. Sign up to view the full content.

View Full Document Right Arrow Icon
This is the end of the preview. Sign up to access the rest of the document.

Unformatted text preview: ct in the range must belong to a set of domains ft1 : : : tmg simultaneously. Ideally, t1 through tm must be constructed types, because a basic object can not belong to more that one domain at a time. This is called a multi-type single valued function. Similarly a multi-type set valued function has the type of the form 1 : : : k ! t1 : : : tmg. For example the attribute reeqp in !f md10 is such a function. It says reeqp is a multi-type set valued function of type md10 ! ftype1, heavydutyg. ! Hence, unlike other SDMs 36], we allow an attribute name to accept arguments and thereby forming an aggregation of di erent types. In this way OR model supports relation valued attribute since these functions represents n + 1;ary relations. Alternatively, it is clear that there is a close relationship between a one-argument attribute whose range is an aggregation type and an n;argument attribute. By allowing constructed type in the range of an attribute function, OR model supports 16 integer aircraft seat aircraft tseat [uses] section cost classcategory string (a) integer (b) classcategory integer aircraft aircraft tseat fireeqp classcategory type1 heavyduty (c) (d) Figure 2: Alternative approaches to attribute based inter-object relationships. complex typing (aggregation type) of objects. Some models (e.g., SDM, FDM, F-Logic, etc.) capture inter-object relationships using object attributes based on the notions of inversion and matching 36]. Although inversion and matching is possible in OR model, we do not view an attribute as a relationship mechanism among objects or entities, and we do not emphasize interobject relationships using either of these primitives. In OR model we emphasize type constructor based inter-object relationships. The use of type constructors allows information to be associated directly with schema abstractions. As an illustration, consider Figure 2 that uses standard SDM notations 36]. In Figure 2 (a) the relationship between aircraft, seat and classcategory is shown using inversion through the family of attributes uses]. A version of uses is de ned in each of these objects to capture the ternary relationship. Consider the same relationship implemented in Figure 1 using the aggregation type constructor { the relationship useseat. In models like OR, that stresses type constructors, relationships between types are essentially viewed as types and thus they are allowed to have attributes that further describe them 39]. In Figure 1, we have allowed attributes cost 17 and section in useseat. Contrast this with its inversion counterpart in Figure 2 (a). In this case a family of attributes section] are needed to be de ned in each of the objects (shown partially). Similarly, to capture the relationship between cost, section and others, a similar set of attributes has to be de ned. This is a major obstacle in models (e.g., SDM, FDM, F-logic, etc.) which stress inversion as inter-object relationship mechanism. The users either have to decide on the types of anticipated relationships or have to de ne all possible sets of inversions. Some models such as SDM and SmallTalk do not support an explicit type constructor and hence have no choice but to model inter-object relationships using attribute inversions only. It also implies that in such models, value based objects, or entities are not possible. In 68] similar observations have been made which supports our view point of not stressing inversion as a relationship primitive. In 68] it is argued that enforcement of inversion and matching constraints are not e cient particularly if it is enforced using methods. This is because the constraint is spread over multiple objects and the objects concerned must communicate through messages back and forth to enforce the constraint or to take corrective measures in case the constraint is violated possibly after a long chain of method invocations. Moreover, such constraints must be coded outside the objects concerned to have a global view of the constraints or in the method implementations sacri cing modularity and abstraction. This result supports our position of not using inversion as an inter-object relationship primitive. Thus we stress that attributes should only be used to describe the object's intrinsic characteristics (data and operations). In Figure 2 (b), tseat is shown as a binary function from aircraft and classcategory to integer which represents the method tseat in aircraft. Notice that it is not clear where the method is de ned, and it may be regarded as it is de ned either in aircraft, in classcategory, or in both. To make a distinction as to where a method is de ned, we use a notation derived from standard SDMs as shown in Figure 2 (c), where tseat is viewed as an attribute of the aggregation of aircraft and classcategory objects. Note that in such an aggregation, only one attribute is allowed (i.e., one outward solid arrow) and the solid arrow from a type to the aggregation shows where the attribute is de ned. In Figure 2 (c), tseat if de...
View Full Document

{[ snackBarMessage ]}