This preview shows page 1. Sign up to view the full content.
Unformatted text preview: e to the users and to other objects. In OR model every attribute is visible by default unless speci ed as private. In contrast, in most of the OO models, state variables are private by default and methods have to de ned to access them. 26 2.3.12 Method Polymorphism
Methods in the OR model are polymorphic. Let us consider the family of methods \tseat". The method tseat in aircraft and in all its subclasses wherever it is applicable, computes the total number of seats in the aircraft. Yet again, tseat(classcategory) re nes the method tseat, by overloading it by giving it the argument classcategory, which then computes the total number of seats in certain classes in a given aircraft. On the other hand, the method tseat in the class seat represents the total number of seats that are in use in di erent aircraft, and, hence, has a completely di erent meaning than the previous versions. All these forms of overloading of method names are known as method polymorphism. Polymorphism aids re nement and extension of behavior through overloading, and enhances re-usability. Rede nition is also possible in the OR model. For example, in Figure 1, the attribute range in MD10A is rst inhibited (withdrawn), and then rede ned with a di erent type, i.e. real. In general, rede nition only shares the attribute or method name in immediate superclasses. It can completely change the type or the signature of the corresponding attribute or method, as well as its implementation. Contrast this with a re-de nition of signatures using overriding. Note that if overriding is used, the data component of the method will still be inherited (if not overridden), while if withdrawal is used, both signature and data will be withdrawn if the signature is withdrawn. 2.3.13 Constraints
Type de nition of attributes and signature of the methods can be viewed as constraints on the type of value that attributes can have and the type of input/output arguments the methods may accept and return. Since the type of objects, or relationships, is the composite of their attribute types and method signatures, the type constraints above also impose corresponding constraints on the scheme or type of the objects or relationships. Other forms of constraints include integrity constraints (IC), inclusion dependency, etc. Some ICs may only involve attributes/methods applicable to a class or relationship, or only to classes participating in a relationship. E.g., functional dependencies and referential ICs t into this category. Other ICs may involve several classes, methods, and relationships. For example, we may de ne the following constraints: (i) a global constraint saying all aircraft should be able to cross the Atlantic (range > width of the Atlantic) and a set of local constraints such as (ii) 27 the total number of seats in aircraft should be more than 100, and (iii) no passenger seats are allowed in a cargoaircraft, etc. Similar to attributes and methods, the local constraints in objects get inherited down the SG hierarchy. There can be con icts among di erent constraints that the objects and relationships must satisfy. For instance, if in our example we move constraint (ii) to the global level, the cargo liners will not be able to satisfy that constraint. In the example, constraint (ii) is meaningful for all passenger aircraft. But since MD10A is basically a passenger aircraft that is being redesigned as a cargo carrier, constraint (ii) does not make sense here. The situation can be more complex. Constraint (iii) de ned for cargo aircraft is in clear con ict with constraint (ii) if they are both monotonically inherited in MD10A. Such con icts are resolved by attaching priority to constraints. In the OR model constraints are placed in di erent strata. The lower the stratum the higher the priority. Global constraints are placed in stratum 0 and, hence, have the highest priority. The local constraints are in stratum 1 and the inherited constraints in stratum 2. Thus, if an inherited constraint is in con ict with the local one, the local one is given preference. E.g., to solve the con ict in our running example, we copy constraint (iii) from cargoaircraft to MD10A, which makes it local, giving it a higher priority than constraint (ii). In the case of multiple inheritance, con icts may also arise between inherited attributes because of di erences in types, values, implementations or the semantic meaning. This form of con ict can be e ectively resolved using inhibition and blocking. In our example, the method cockpit which is inherited from cargoaircraft and MD10 is in con ict in MD10A. So we selectively inhibit MD10.cockpit (notice the pre xing of the class name in front of the attribute name) in MD10A to favor the inheritance of cockpit from cargoaircraft. Similarly, selective blocking shown in the class MD10A and discussed earlier, can also be used to resolve such con icts. 2.3.14 Virtual Objects and Relationships
An object in the OR model may be derived from the database contents. Its type and values (or...
View Full Document