The document discusses specialization and generalization hierarchies and lattices in object-oriented modeling. It explains that a specialization hierarchy only allows each subclass to have one parent class, forming a tree structure, while a specialization lattice allows subclasses to have multiple parent classes. It also discusses category subclasses, which represent a union of entities from multiple superclasses, unlike regular subclasses which represent entities belonging to a single superclass.
The document discusses specialization and generalization hierarchies and lattices in object-oriented modeling. It explains that a specialization hierarchy only allows each subclass to have one parent class, forming a tree structure, while a specialization lattice allows subclasses to have multiple parent classes. It also discusses category subclasses, which represent a union of entities from multiple superclasses, unlike regular subclasses which represent entities belonging to a single superclass.
The document discusses specialization and generalization hierarchies and lattices in object-oriented modeling. It explains that a specialization hierarchy only allows each subclass to have one parent class, forming a tree structure, while a specialization lattice allows subclasses to have multiple parent classes. It also discusses category subclasses, which represent a union of entities from multiple superclasses, unlike regular subclasses which represent entities belonging to a single superclass.
The document discusses specialization and generalization hierarchies and lattices in object-oriented modeling. It explains that a specialization hierarchy only allows each subclass to have one parent class, forming a tree structure, while a specialization lattice allows subclasses to have multiple parent classes. It also discusses category subclasses, which represent a union of entities from multiple superclasses, unlike regular subclasses which represent entities belonging to a single superclass.
Download as DOC, PDF, TXT or read online from Scribd
Download as doc, pdf, or txt
You are on page 1/ 4
Specialization and Generalization Lattices and Hierarchies
A specialization may be a subclass, and also have a subclass specified on it.
For example, in the figure above, Engineer is a subclass of Employee, but also a super class of Engineering Manager. This means that every Engineering Manager, must also be an Engineer. Specialization Hierarchy has the constraint that every subclass participates as a subclass in only one classsubclass relationship, i.e. that each subclass has only one parent. This results in a tree structure. Specialization Lattice has the constraint that a subclass can be a subclass of more than one classsubclass relationship. The figure sho!n above is a specialization lattice, because Engineering"Manager participates has more than one parent classes. #n a lattice or hierarchy, the subclass inherits the attributes not only of the direct superclass, but also all of the predecessor super classes all the !ay to the root. A subclass !ith more than one super class is called a shared subclass. This leads to multiple inheritance, !here a subclass inherits attributes from multiple classes. #n a lattice, !hen a superclass inherits attributes from more than one superclass, and some attributes are inherited more than once via different paths $i.e. Engineer, Manager and %alaried Employee all inherit from Employee, that are then inherited by Engineering Manager. #n this situation, the attributes are included only once in the subclass. Modeling Union Types using Categories #n the subclass&superclass relationship types !e have seen so far, each has a single superclass. Employee %ecretary Technician Engineer Manager %alaried"Emp 'ourly Emp Engineering Manager d d This means that in a particular subclasssuper class relationship $Engineer, Engineering Manager( even though the subclass has more than one subclasssuper class relationship, each relationship is bet!een a single super class and subclass. There are situations !hen you !ould li)e to model a relationship !here a single subclass has more than one super class, and !here each super class represents a different entity type. The subclass !ill represent a collection of ob*ects that is a subset of the +,#-, of the distinct entity types. This type of subclass is a union type, or category subclass. See Text Example, page 99. A category has t!o or more super classes that may be distinct entity types, !here other super classsubclass relationships have only one super class. #f !e compare the Engineering Manager subclass, it is a sub class of each of the three super classes, Engineer, Manager and %alaried employee, and inherits the attributes of all three. An entity that exists in Engineering Manager exists in all three super classes. This represents the constraint that an Engineering Manager must be an Engineer, a Manager, A,. a %alaried Employee. #t can be thought of as an A,. condition. /y contrast, a category is a union of its subclasses. This means that an entity that is a subclass of a union, exists in -,01 -,E of the super classes. An o!ner may be a 2ompany, -3 a /an) -3 a 4E3%-,, but not more than one. A category can be partial or total. A total category holds the union of A00 its super classes, !here a partial category can hold a subset of the union. #f a category is total, it can also be represented as a total specialization. Comparison of Registered Vehicle Category to Vehicle 5. 6. The first example implies that every car and truc) is also a vehicle. #n the second example, a registered vehicle can be a car or a truc), but every car and truc) is not a registered vehicle. -ther examples7 +niversity $3esearcher(
8ehicle 2ar Truc) d 3egistered"8ehicle 2ar Truc) u Example 9.65 .esign a database to )eep trac) of information for an art museum. Assume that the follo!ing re:uirements !ere collected. The museum has a collection of A3T"-/;E2T% . Each art ob*ect has a uni:ue #.,o, and Artist, if )no!n, a 1ear $!hen created, if )no!n( a Title and a .escription. The art ob*ects are categorized in several !ays, as discussed belo!. A3T"-/;E2T% are categorized based on types. There are three main types, 4ainting, %culpture and %tatue, plus an <-ther= category for those that don=t fit into one of the categories above. A 4A#,T#,> has a 4aintType $oil, !atercolor, etc( a material on !hich it is 2ra!n-n $paper, canvas, !ood( and %tyle $modern, abstract etc( A %2+04T+3E or a %TAT+E has a Material from !hich it !as created $!ood, stone, etc( 'eight, ?eight and %tyle. An art ob*ect in the -T'E3 category has a Type$print, photo, etc( and %tyle. A3T"-/;E2T% are also categorized as 4E3MA,E,T"2-00E2T#-,, !hich are o!ned by the museum $.ateAc:uired, !hether it is -n.isplay or %tored and 2ost( or /-33-?E., !hich has information on the 2ollection $!here it !as borro!ed from(, .ate/orro!ed, and .ate3eturned. A3T"-/;E2T% also have information describing their country&culture using information on countryculture of -rigin $#talian, Egyptial, American, #ndian etc( and 4eriod$3enaissance, Modern, Ancient( The museum )eeps trac) of A3T#%T%=s information, if )no!n7 ,ame, .ate/orn, .ate.ied, 2ountry-f-rigin, 4eriod, Main%tyle and .escription. The name is assumed uni:ue. .ifferent E@'#/#T#-,% occur, each having a ,ame, %tart.ate and End.ate. E@'#/#T#-,% are related to all the art ob*ects that !ere on display during the exhibition. #nformation is )ept on other 2-00E2T#-,% !ith !hich the museum interacts, including ,ame $uni:ue(, Type $museum, personnel etc(, .escription, Address, 4hone and 2ontact4erson. .ra! an EE3 schema for this application. 3ecord any assymptions you ma)e.