您的当前位置：首页 Category Classes Flexible Classification and Evolution in Object-Oriented Databases

Category Classes Flexible Classification and Evolution in Object-Oriented Databases

来源：宝玛科技网

CategoryClasses:FlexibleClassiﬁcationandEvolutionin

Object-OrientedDatabases

ErikOdberg

DepartmentofComputerScienceNorwegianInstituteofTechnology

Abstract

Object-orienteddatabases(OODBs)arebelievedtomorenaturallyreﬂectthebehaviorandorganizationofrealworldobjects.However,OODBsaremostlyconcernedaboutonlythestaticaspectsofobjectmodeling.Whilerealworldobjectstypicallymaybemulti-perspectivedandevolveovertimebychangingclassiﬁcationandbehavior,contemporaryOODBmodelstypicallyregardobjectsasinstancesofclassesinsuchawaythatclassiﬁcation(andthusbehavior)isﬁxedatthetimeofcreation.

Thispaperintroducesthenotionofanobjectroletodenoteaparticularperspectiveofanobject,correspondingtoaclassforwhichitisaninstance.Rolesmaybedynamicallyaddedandremovedfromobjectstoreﬂectthewayrealworldobjectsclassifyandevolveovertime,andsimultaneouslychangebehavior.Acategoryclassisaspecialclasswhichisassociatedwithapredicate,andinthiswaydescribeconstraintsonhowobjectsmayevolve,aswellashowobjectsmayautomaticallygainanddiscardrolesbasedonvariouscriteria.

1IntroductionandMotivation

Object-orienteddatamodels(andconsequentlyobject-orienteddatabases(OODBs))arebelievedtobetterandmorenaturallyreﬂectingthebehaviorandorganizationofrealworldphenomena,incorporatingmoreoftherealworldsemantics.Objectsseparateexternallyvisiblebehaviorfrominternalrepresentationandimplementation.Classesabstractovercommonalitiesbetweenobjects,deﬁningclassiﬁcationsofobjects.Classhierarchiesimposeanorganizationofclassesdescribingaconceptualspecialization(i.e.thatinstancesofoneclassmayalsoberegardedasinstancesofmoregeneralsuperclasses)andinheritanceofproperties(i.e.thatinstancesofoneclasswillalsocontainpropertiesasdeﬁnedforsuperclasses).

However,mostobjectmodelsareonlyconcernedaboutthestaticaspectsofmodeling,andnothowobjectsmayevolveovertime.Objectsarecreatedasaninstanceofoneclass,whichalsoservestoclassifytheobjectaccordingtothepredeﬁnedtaxonomy,andtodeﬁneitsproperties.Oncecreated,objectscannotchangeclassiﬁcationorpropertypossession.Naturally,thisdoesnotreﬂectverywellthewaythe“realworld”behaves:Real-worldobjects(“phenomena”)maytypicallyhavedifferentappearance(exhibitedbehavior)indifferentcontextsofexpectation,andmaybeperceivedtoclassifydifferently(dependentonexpectation).Phenomenaareoftenhighlydynamic,andevolveovertimebychangingclassiﬁcationandappearance.

Theremainingpartofthispaperdescribesanextensiontothetraditionalnotionofobject-orientationwhichnaturallyreﬂectsthebehaviorofthe“realworld”.Section2introducesthenotionofanobjectroleasaparticularperspectiveofanobject,anddiscusseshowrolesmaybeaddedtoandremovedfromobjectstoallowobjectstoevolve.Section3deﬁnesacategoryclassasaspecializationofthe

comparestheapproachwithrelatedwork,whileSection5concludesthepaperandpresentsdirectionsforfurtherwork.

2ObjectswithRoles

Thefundamentalobjectmodelis“traditional”inthatitadoptsC++astheprimarysourceofinﬂuence.Objectsarecreatedasinstancesofclasses,whichhaveanassociatedcollectionofproperties.Propertiesmaybeattributesormethods,deﬁnedinawaywhichissimilartoC++,andhaveavisibilitywhichiseitherpublic(accessiblebyexternalclientsoftheobject)orprivate(onlyaccessibletomethodimplementationsfortheclass).Thevisibilityisspeciﬁedbykeywordspublicandprivate,withpublicbeingdefault(incontrasttoC++).Anotionofexplicitrelationshipsissupportedtoprovidesymmetricassociations(withcardinalities)betweentwoclasses,andwithspecialfunctionalityfornavigatingoverthese.Aclassmayhaveoneormoresuperclasses(deﬁningtheclassasasubclassofthese).Thesubclassinheritsthepropertiesofthesuperclasses(retainingthevisibilitymode),andmaydeﬁneadditionalpropertiesorredeﬁneinheritedones.Thesubclassalsodeﬁnesaspecializationrelationshipwithitssuperclasses,andsothatinstancesofoneclassarealsoinstancesofallsuperclasses(transitively).NotethataclassClassistheimplicitsuperclassofallclassesforwhichnosuperclassisdeﬁned;inthiswayaschemawillconsistofoneconnectedclasshierarchy.

2.1Objectmanipulation

Persistentobjectsaremanipulated(created,modiﬁed,deleted)throughacorrespondingC++place-holderobject.PlaceholderobjectsareinstancesofC++persistentclasses,whicharegeneratedfromtheschemaspeciﬁcation.EachpersistentC++classdirectlycorrespondstoaschemaclass,havingthesamenameandproperties,andprovidingadditionalfunctionalityforpersistentmanipulation.Placeholdersareacquiredfromthedatabasebynavigationoverdatabaserelationships,byiterationoverasetofpersistentobjects(possiblyacquiredthroughanassociativequery),orasaresultfromamethodinvocation.

Objectscreatedasinstancesofpersistentclasseswillnotautomaticallypersistinthedatabase.ThismustbeexplicitlyrequestedbyinvocationofafunctionMakePersist,associatedwitheachpersistentclass.Inthiswayinstancesofpersistentclassesmaybebothpersistentandnon-persistent,butmaysmoothlyinteractwithinthesameapplicationprocess.Objectmodiﬁcationsarealso“committed”persistentlybyinvocationofMakePersist.

2.2Objectroles

Eachclassanobjectmayberegardedaninstanceofwillbedenotedaroleofthisobject.Eachobjectrolereﬂectsaparticularperspectiveoftheobject,acontextofbehaviorwhichmaybereferencedbyclients.Moreimportant,roles(i.e.classmemberships)reﬂectcharacteristicsofobjectswhichmaybeindependentlygainedandlost:Objectsmayevolveovertimebychangingrolepossession(i.e.theclassiﬁcationandassociatedproperties)dynamically.Somerolesmayreﬂectspecializationsofotherroles(correspondingtosuperclasses),howeveranimportantcharacteristicofthemodelistheabilityforobjectstopossessrolescorrespondingtosiblingclasses.Betweentwosiblingclassesthereisneitherasubclassingrelationship,noristhereacommonsubclassoftheseclasses.Wesaythatobjectsmaycontainmultiplemost-speciﬁcroles,orthatobjectsaremulti-perspectived.Thisisincontrastwithtraditionalobject-orientedmodelswhereeachobjectisaninstanceofoneclass

Thereisnoabilitytohaveobjectevolveorassumeadditionalmost-speciﬁcroles.

Thecreationofanobjectwillallocateacollectionofroles(forallclassestheobjectisaninstance),andsimultaneouslyassignauniqueobjectidentiﬁer(OID)tothenewobject.Newrolesmaybeadded,accordingtotheclasshierarchy,andinthisway“extending”theobjectdownwards.NonewOIDisassigneduponroleaddition,itisstillthesameobject.Anyrole(s)mayalsoberemovedfromtheobject(withoutdeletingtheobjectoraffectingtheOID),andwhichwillalsohavetheimpactthatallrolescorrespondingtosubclassesofthedenotedroleclassareremovedaswell.Thestrongnotionofidentitymeansthatnoobjectsetmaycontainmultipleoccurrencesofthesameobject,evenifdifferentrolesareregarded.Furthermore,twooperatorsforcheckingtheidentityofobjectreferencesareprovided:Twoplaceholdersareobjectidenticaliftheycorrespondtothesame(persistent)object,whileplaceholdersareobject-roleidenticaliftheycorrespondtothesameobjectandrole.

Figure1illustratesanexampleclasshierarchy.

Aperson’s“life”isdescribedbythewayrolesaregainedandlost,possiblypossessingmanydifferent(most-speciﬁc)rolessimultaneously.Somerolesmaybeautomaticallygainedandlost(forinstanceChildandTeenagerduetoage),whilesomemustbeexplicitlyadded(asforinstanceStudentandEmployee).Somerolesareinherentlyincompatible,andmaynotbepossessedatthesametime(forinstanceFemaleandMale,orRetiredandEmployee).Otherrolesmaybepossessedsimultaneously,asforinstanceafemaleteachingassistantwhichisaninstanceofFemale,EmployeeandStudent,andbehavesindifferentwaysinthesethreeroles.

2.3Objectrolemanipulation

Theintroductionoftherolenotionhaveimplicationstothefunctionalityprovidedforobjectmanip-ulation.

2.3.1Addingroles

Newrolesareaddedtopersistentobjectsthroughtheaddoperator,whichisapplicabletoallplaceholders:

Person*pers=...;

Student*stud=persaddStudent;

asanother“branch”oftheobject,andsothattheobjectdoesnothavetobeaninstanceofasinglemost-speciﬁcclass.Forinstance,thefollowingexampleillustratesapersonwhichissimultaneouslyalsoastudentandanemployee:

Employee*emp=studaddEmployee;

Itmustbenotedthatthereisnoconstraintonwhatistheclassoftheobjectwhichisthebasisfortheroleaddition:Inprincipleanyrolemaybeaddedtoanyobject,howeverSection3willshowhowrestrictionsmaybeimposed.

TheaddoperatorreturnsapointertoaC++placeholderobjectasaninstanceoftheclasscorrespond-ingtotheaddedrole.Thismeansthattheplaceholdersreferencedbypers,studandemp,whichcorrespondtothesamepersistentobject,neednotbethesameC++objects.Rather,theyreferencedifferentperspectivesofthesame(persistent)object.Applicationprogramsmustensure,inordertoavoidmutationconﬂicts,thatobjectsaremutatedthroughonlyoneperspective(placeholder)atthetime.Thatis,applicationsshouldpreferablysynchronizewiththedatabase(byinvokingMakePersist)beforethenewroleisadded.TheDBMShasnoothermeanstoensurethatmultipleplaceholderswithinthesameprocessaremaintainedconsistentlywrt.mutations.NotethataroleadditionisnotreﬂectedpersistentlyunlessMakePersistisexplicitlyinvoked.

Ifaroleisaddedtoanobjectwhichalreadydoespossessthisrole,theobjectisnotaffectedbytheaddition.Thismeansthatanobjectmayhaveonlyonerolecorrespondingtoeachclass.Ifaroleispossessedbyapersistentobject,butnotreﬂectedbytheactualplaceholder,anewplaceholdermustbereturned.Thisisbecausetheresultoftheaddoperationisexpectedtobeaninstanceoftheaddedclass.Consequently,forthefollowingoperationnonewroleisadded,butanotherplaceholder(whichmaybethesameasforstud)isreturned:

Student*stud2=empaddStudent;

Itmustbenotedthatsomeotherapproaches,notablyAspects[RS91]andClovers[SZ],allowsforinstantiatingmultiplerolesofthesameclass.Itisourpositionthatthisisunnaturalmodeling,andbetterreﬂectedbytheuseofrelationshipsbetweenobjects.Furthermore,thereisanimportantproblemwrt.identiﬁcationofroleswhichreﬂectthesameclass.

Anotionofaroleconstructorisprovidedfortheinitializationofnewroles.Roleconstructorsoperateasordinaryconstructors,butinitializeonlyattributesdirectlyassociated(i.e.non-inherited)withtheclassoftheroletobeadded.Zeroormoreroleconstructorsmaybeassociatedwitheachclass.Ifthereisnovisibleroleconstructordeﬁnedforaparticularclass,thismeansthattheclassmaynotbeaddedasaroletoanyexistingobject:

enum{male,female}Sex;

classPerson{char*name;enumSexsex;intage;

Person(char*,enumSex,int);};

classEmployee:Person{char*company;

Employee(char*,char*,enumSex,int);$Employee(char*);}

//Ordinaryconstructor//Roleconstructor

Similartoforobjectcreation,roleadditionwillthustakeargumentsasindicatedbytherolecon-structor:

Person*pers=newperson(‘‘DonaldDuck’’,male,60);

Employee*emp=persaddemployee(‘‘WaltDisneyCorp.’’);

Rolesmayalsoberemovedfromobjects,usingtheremoperator:

Employee*emp=...;

Person*pers=empremEmployee;

Theremoperatorremovestherolecorrespondingtotheindicatedclassfromtheobject(provideditiscontained),aswellasallcontainedrolescorrespondingtosubclasses.Apointertothesameobjectasaninstanceoftheimmediatesuperclassoftheremovedclassisreturned.Ingeneral,thismeansthatanotherplaceholder(anotherC++pointer)willbereturned.MakePersistmustbeinvokedtohavetheroleremovaltobepersistentlyreﬂected.Notethatitispossibletoremovearolefromanobjecteveniftheplaceholderisnotaninstanceofthecorrespondingpersistentclass,aslongastheroleispossessedpersistently:

Employee*emp=...;

Person*pers=empremStudent;

Anotionofaroledestructorisprovided,similarlytoordinarydestructors,to“cleanup”datastructureswhensomeroleisremovedfromanobject.Moreinterestingly,ifthereisnopublicroledestructorassociatedwithaclass,thecorrespondingrolemaynotberemovedfromtheobjectbyanyapplicationprogram.2.3.3Referencecoercion

Objectreferencesmaybecoercedtoanotherclass,inthesamewayasinC++.Inthiswaythesame(persistent)objectmaybeinspectedthroughanotherroleandthusexhibitingitselfdifferently.Coercionsmaybeperformedupwards(toasuperclass,andthusrestrictthesetofavailablepropertiesand/orchangebindingsforpropertiesoverriddenbysubclasses),downwards(toasubclass,andthusassumingadditionalproperties),ortoasiblingclass(aclasswhichisneitherasuperclassorsubclass,andthusmayprovideacompletelydifferentsetofproperties).ThefollowingaresomenaturalcoercionswhichmayoriginateusingtheclasshierarchyofFigure1:

Employee*emp=...;

Person*pers=(Person*)emp;

Professor*prof=(Professor*)emp;Student*stud=(Student*)emp;

//Upwardscoercion//Downwardscoercion//Siblingcoercion

ThecoercionwillreturnapointertoaC++placeholderobjectwhichisgenerallydifferentfromtheoriginal,astheyreﬂectthesameobjectasaninstanceofdifferentpersistentclasses.Notethatiftheobjectdoesnothavetherolecorrespondingtothecoercion,anexceptionwillberaised(andthereturnpointerisinvalid).Naturally,thismayonlybecheckedatruntime.2.3.4Placeholderconstruction

Whenaplaceholderisconstructedtoreﬂectapersistentcounterpart,itwillnormallybecreatedasaninstanceofthepersistentclasscorrespondingtothemost-speciﬁcclassofthepersistentobject(ratherthantheclassofthereference).However,accordingtothemodelofrolesanobjectmayhavemultiplemost-speciﬁcclasses.ThiscannotbeexpressedwithinC++,andthustheplaceholderobjects(reﬂectingreferencestopersistentobjects)mustbecreatedasinstancesofauniquepersistentclass.Differentpossibilitiesexisttodecideaboutthisclass:Itmaythesameastheclassofthereference,butthiswillnotworkcorrectlyinthepresenceofvirtualfunctions.Rather,anobjectshouldbereturnedasaninstanceofsomemost-speciﬁcclassforwhichthepersistentobjectisan

prioritybasedonforinstancewhichrolewasﬁrst(orlast)added.Anotherpossibilityistohaveapplicationprogramsdenotetheclassoftheplaceholderobjectbyexplicitcoercion.

Virtualmethodinvocationsareboundtoimplementationdynamically(latebinding),onthebasisoftheclassoftheobjectratherthanthereferencetotheobject.Asthereneednotbeauniquemost-speciﬁcclassofthe(persistent)object,virtualbindingwillbebasedontheplaceholderobject,inthiswaytakingadvantageofC++runtimeprovisions.Thismeansthatvirtualbindingisdependentonthestrategyforplaceholderobjectconstruction.Indeed,virtualbindingisaninherentproblemofthemodel,giventhetraditionalinterpretation.Amore“natural”solution,maybetohavevirtualmethodimplementationstakeintoconsiderationwhichsubclassesthe(persistent)objectisaninstanceof,andperformacomputationbasedonthisknowledge.Inthiswayspecial“combinationmethods”maybeimplementedintermsofmethodsofmultiplemost-speciﬁcclasses,orpossiblyexplicitlyselectingbetweenthese.

3CategoryClasses

Acategoryclassisaspecializationoftheclassconstructwithspecialabilitiestorestrictorenableobjectmembershipintheclassthroughtheassociationwithapredicate.Forordinaryclasses,therearenorestrictionsonobjectcreationanddeletion,orroleadditionandremoval,apartfromthepossibleinhibitiondescribedbyinvisible(role)constructorsordestructors.Fundamentally,anyrolemaybeadded(explicitly)toanyobject,andanyrolepossessedmayberemoved.Membershipincategoryclasses,however,dependsonsatisfactionofthecategoryclasspredicate.Foramanualcategoryclass,theexplicitadditionofthecorrespondingroletosomeobjectwillonlysucceedifthepredicateissatisﬁedatthetimeofaddition.Anautomaticcategoryclassisdifferentinthatsatisfactionofthepredicatewillautomaticallymaketherolebeaddedtotheobject,howeveritwillbelostifthepredicateislaterdis-satisﬁed.

Inmostrespectscategoryclassesaresimilartoordinaryclasses.Theyareorganizedinthesameclasshierarchy,andthusdeﬁneinheritanceandsubstitutabilityrelationshipswithsuperclasses.Categoryclassesassociatewithpropertiesasordinaryclasses,andobjectvariablesmayreferenceinstancesofcategoryclasses(throughtheplaceholder)justlikeinstancesofotherclasses.Categoryclassesandordinaryclassesaredifferentvariationsofthesameabstractionmechanism,withanadditionalabilityforcategoryclassestorestrictorenablemembershipinpowerfulways.Categoryclassesexpressspecialknowledgeaboutphenomenaevolutionandclassiﬁcationinthedomainofdiscourse,makingtheschemaabletoincludemoreaspectsofreal-worldsemantics.

3.1Categoryclassdeﬁnition

Thegeneralsyntaxofacategoryclassdeﬁnitiongoesasfollows:

classcatclass[:][WHEN[ON]]

[AND|OR][IF[ON]]

{

//classproperties};

Acategoryclass(catclass)mayhaveoneormoresuperclasses,whichmaybeordinaryorcategoryclasses.ManualcategoryclassesaredeﬁnedbyanIFexpression,forwhichpredicatedescribesarestrictiontobesatisﬁedtopermittheexplicitaddition(usingtheaddoperator)ofthecorrespondingroletosomeobject.AutomaticcategoryclassesaredeﬁnedbyaWHENexpression,forwhichpredicatedeﬁnesthecriterionforthecorrespondingroleautomaticallytobeaddedtosomeobject.IFandWHENexpressionsmayalsobecombined(usinglogicaloperatorsANDorOR),aswillbeexplainedbelow.

ONexpressionsdeﬁnethecandidateclassoftheparticularcategoryclass.Onlyobjectswhichpossessthecorrespondingrole(isaninstanceofthecandidateclass)arevalidcandidatesformembershipinthecategoryclass.Furthermore,categoryclasspredicatesmayonlyreferencepropertiesdeﬁnedforthecandidateclass(orsuperclassesofthis).Thespeciﬁcationofacandidateclassisoptional;ifnocandidateclassisdeﬁned,theimmediatesuperclassofthecategoryclasswillapplybydefault.Ifthecategoryclasshasmultiplesuperclasses,thelowestcommonsuperclasswillbetheeffectivecandidateclass.Mostoften,thecandidateclassisasuperclassofthecategoryclass,andsothatmembershipinthecategoryclasswillreﬂectaspecializationofthecandidateclassrole.Acandidateclassmayalsobeasiblingclassofthecategoryclass,andsothatacorrespondingroleadditionmayaddanadditionalmost-speciﬁcroleoftheobject.Acandidateclasswhichisasubclassofthecategoryclassismeaningless.Predicates

Categoryclasspredicatesmayreferencetwoaspectsofobjects;thepropertiesdeﬁnedforthecandidateclass,andtherolepossessionoftheobject.Bothpublicandprivateattributesmaybereferencedaspartofthepredicatespeciﬁcation.Whileclientsofobjectsmayonlyaccessthepublicpartofclassdeﬁnitions,categoryclasspredicatesareregardedapartofthedeﬁnitionoftheclassandthusmayreferenceinternalrepresentationaswell.Method-basedpredicatesarepermitted,butmustbeusedwithcareasmethodinvocationsmayhaveundesirableside-effects(Cfr.forinstance[Odb92]).Moreover,automaticcategoryclasspredicatesare(atleastconceptually)continuouslyevaluatedforallcandidateobjects,whichmeansthatside-affectmethodsmayhavearbitraryaffectsonobjects.

Property-basedpredicatesarespeciﬁedusingordinaryC++comparisonoperatorsandbooleanoperators&&(and),(or)and!(not),referencingthestateofobjectsaswellasconstantvalues.Predicatesareevaluatedinthecontextofobjectswhichareinstancesofthecandidateclass,withpredicateattributesboundtotheparticularobject.Role-basedpredicatesspecifyrequirementsontheobjectpossessionofroles.Rolepossessionisdenotedthroughthenameoftheclass,andusingC++booleanoperatorsanypredicateoverrolepossessionmaybedeﬁnedtoconstrain(formanual)orenable(forautomatic)membershipinthecategoryclass.Attribute-androle-basedexpressionsmayalsobecombinedinthesamepredicate.Examplesofthedifferentkindsofpredicatesareshownbelow.

3.2Manualcategoryclasses

ManualcategoryclassesaredeﬁnedthroughanIFexpression,givingapredicatewhichmustsatisﬁedtopermittheexplicitadditionofthecorrespondingroletoanobject(whichmustalsopossesstherolecorrespondingtothecandidateclass).Furthermore,forallsuperclassesofthecategoryclass,theobjectmusteitheralreadypossessthecorrespondingrole(beamember),oradditionmustbepermitted(i.e.predicatespossiblyassociatedmustbesatisﬁed).Thismeansthatmultiplerolesmaybeaddedinonego.Ifforsomereasonroleadditionisnotpermitted,theoperationfailsandanerrorcodeisset.Ifadditionsucceeds,theroleiscontaineduntiltheobjectisdeleted,theroleisexplicitlyremoved,orsomeautomaticsuperclasspredicateisnolongersatisﬁed(Cfr.below).However,thereisnorequirementthatmanualcategoryclasspredicatesaresatisﬁedafterasuccessfuladdition.Manualcategoryclassesaremostcommonlyusedtodeﬁneconstraintsonobjectevolution,andthusimplicitlydeﬁnevalidpatternsofmigration.Additionofaparticularroletosomeobjectrequiresthatitfulﬁllscertaincharacteristicsintermsofstateand/orthatitdoes/doesnotalreadypossessacertaincombinationofroles.Manualcategoryclassesgenerallyassociatewithadditionalproperties,sothatnewattributesaretypicallyinitializedbyaroleconstructor.Forinstancenopersonmaybecomeastudentifnotoldenough:

...};

Thispredicateisattribute-based,butmanualcategoryclasspredicatesmayalsobebasedonthepossessionofroles.Forinstance,allfullorassociateprofessorsmaybeaPhDpromoter(howeverdoesnothaveto),whileotherfacultymembersmaynot:

classPhDPromoter:FacultyMemberIFProfessor||AssocProfessor...};

NotethatPhDPromoterisneitherasubclassnorsuperclassofProfessororAssocProfessor.Manualcategoryclassesmayalsobedeﬁnedonthebasisofpredicatesreferencingbothattributesandrolepossession.Forinstance,toqualifyforprofessorshipyoumusthaveearnedaPhDdegreeandhavemorethan25publications,orhavebeenemployedattheuniversity(asafacultymember)morethan30years:

classPhD:Person{...};classEmployee:Person{...

intemployed_years;};

classProfessor:FacultyMemberIF(PhD&&publications>25)||

employed_years>30{

...};

Notethat,asProfessorisamanualcategoryclass,promotionisnotguaranteedevenifthepredicateissatisﬁed.

3.3Automaticcategoryclasses

AutomaticcategoryclassesaredeﬁnedbyWHENexpressions,whichdeﬁneacriterionforobjectstoautomaticallyassumetherolecorrespondingtothecategoryclass.Logically,allobjectswhichpossessthecandidateclassrole(i.e.isaninstanceofthecandidateclass)are(atleastconceptually)continuouslyevaluatedforpossiblepredicatesatisfaction.Ifthepredicateissatisﬁed,androlescorrespondingtosuperclasseseitherarepossessed,oradditionispermitted,thecategoryclassrole(andpossibly“missing”superclassroles)areassumedbytheobject.Ifatsometimethepredicatefortheclass,orforsomeautomaticcategorysuperclass,isnolongersatisﬁedtherolewillbecomeinvisible.Thesameappliesifthecandidateclassroleislost.However,iftherolepossessionislaterre-enabledthesamerole(withthesamestate)willreappear;theroleisnotpersistentlyremoved.Thesamealsoappliesforanysubclassesoftheautomaticcategoryclassaswell:Upondis-satisfactionofanautomaticcategorysuperclasspredicatesubclassroleswillbecomeinvisible(superclassmembershipisaprerequisiteformembershipinsubclasses),butwillreappearuponpredicatere-satisfaction.Notethat,incontrast,formanualcategoryclassespredicatesareonlyevaluateduponroleaddition,anduponroleremovalallroles(includingforsubclasses)arepersistentlyremoved.

Insomecases,anobjectmaysatisfythepredicateofmultipleautomaticcategoryclasses,althoughmembershipinthesemaybemutuallyexclusive.Inthiscasepredicateswillbeconﬂicting,andmembershipineithermayprohibitmembershipinothers.Thesystemwillmakeanarbitrarychoiceofclassmembershipinthesecases.Notethatthesystemisnotabletodetectthatsuchasituationmaypossiblyarise,andthusnowarningmaybegivenatschemadeﬁnitiontime.

Whileany(category)classmayassociatewithbothmethodsandattributes,automaticcategoryclassesoftentendnottoaddattributesinadditiontothoseinheritedfromsuperclasses.Thereasonisthatautomaticcategoryclassrolesareimplicitlyadded,andthusonlynon-argumentroleconstructorsmay

deﬁnenewmethods,orredeﬁneinheritedones.Inthiswayspecialbehaviormaybeassociatedwithobjectsasamemberofautomaticcategoryclasses,andforwhichtheassociationisdependentonpredicatesatisfaction.Automaticcategoryclassesaremostlyconcernedaboutthemembership(extent)dimensionandforwhichﬂexiblespeciﬁcationispossible.Thisalsoreﬂectsthetypicaluseofautomaticcategoryclasses,describedbelow.3.3.1Usingautomaticcategoryclasses

Automaticcategoryclassesmaybeusedindifferentways.Typicallytheyareusedtodescribeoneormorepartitionsofasuperclassbasedonvaluesforattributesofthesuperclass,andsothateachpartitionclasscontainasubsetoftheobjectsinthesuperclass.Partitionclassesmaybedisjointoroverlapping,andmaybecompleteornon-completepartitions.Speciﬁcationofcompletenessanddisjointnessislefttotheschemadesigner,andisdependentontheabilitytodeﬁnepredicateswhichreﬂectthesemanticsofthepartition.ThefollowingexamplesspecifypartitionclassesforPerson,inherentlyconstitutingacompleteanddisjointpartitionofPerson.

classChild:PersonWHENage<13{...};

classTeenager:PersonWHEN13<=age<20{...};classAdult:PersonWHEN...};

age>=20{

Addingthefollowingmeansthatthepartitionis(potentially)nolongerdisjoint:

classRetired:PersonWHENage>=67...};

{

AddingthefollowingimpliestherewillbemultiplepartitionsofPerson:

classMale:PersonWHENsex=male{...};classFemale:PersonWHENsex=female{...};

Automaticcategoryclassesmayalsobeappliedtodeﬁnevariouspropagationsofclassmembership,onthebasisofdifferentcriteria.Thesecategoryclassesaretypicallydeﬁnedbyrole-basedpredicates,andsothatpossessionofaspecialcombinationofrolesimpliesautomaticassumptionofanotherrole.Considerthefollowingexample:

classGroupLeader:EmployeeWHENProfessor{...};

Asageneralrule,everyfullprofessorisentitledtoherowngroup,inwhichtheprofessorauto-maticallybecomesthegroupleader.However,theclassGroupLeaderisnotaspecializationofProfessor:Thefactthatallgroupleadersareprofessors(andviceversa)isjustanotherrolethatinherentlyisplayedbyprofessors.GroupLeaderandProfessoraresiblingclassesintheclasshierarchy;botharesubclassesofEmployee.

MorecomplexpropagationspeciﬁcationsmaybedeﬁnedusingC++logicaloperators,e.g.todeﬁnenewclassesasintersections,unionsordifferencesbetweenothers.Duetothenotionofobjectrolesthereisnospecialrestrictionswrt.theplacementofsuchclassesinhierarchy.Forinstance,atemporaryemployeeisanyemployeewhichisnotafacultymemberoratechnical/administrativeperson:

Propertyandrole-basedpredicatesmaybecombined,andsothatmembershipinthecategoryclassisbasedonbothpropertyevaluationandrolepossession.Thismaybeconvenienttomodelconditionalpropagation.Forinstance,aresearcherisautomaticallypromotedtoaseniorresearcheraftertenyearsofemployment,providedshehasaPhDdegree:

classResearcher:Employee{...};

classSeniorResearcher:ResearcherWHENemployed_years>10&&PhD{...};

Two-waypropagationisusefulwhentwoclasses,whicharesiblingclasses,shouldcontainthesameobjects.Forinstance,fortheemployeesatsomeuniversity,alllecturersarefacultymembers,andviceversa:

classLecturer:EmployeeWHENFacultyMemberORIF...{...};classFacultyMember:EmployeeWHENLecturerORIF...{...};

LecturerandFacultyMemberaresiblingclassesintheclasshierarchy,sothatanypersonpossessingeitheroftheseroleswillalso(automatically)possesstheother(andgenerallybehaveindifferentwaysinthedifferentroles).ThedeﬁnitionofclassesLecturerandFacultyMemberalsoincludesanIFexpression,ensuringthatrolescorrespondingtotheseclassesmaybeexplicitlyaddedaswell;otherwisetherewillbenowayforanyobjecttobecomealecturerorfacultymember.Thecombinationofmanualandautomaticpredicateexpressionsiselaborateduponinthenextsection.

3.4Manualandautomaticcategoryclasses

Categoryclasseswhicharebothmanualandautomaticmayhavemembershipcriteriadeﬁnedbyaconjunction(AND)ordisjunction(OR)betweenIFandWHENexpressions(associatedwiththesameordifferentcandidateclasses):

classclass2:class1WHENpred1ONclassXANDIFpred2ONclassY{...};classclass3:class1WHENpred3ONclassXORIFpred4ONclassY{...};

class2isdeﬁnedbyconjunction,andthecorrespondingrolemaybeassumedbyanobjectuponexplicitadditiononly,andonlyinthecasethatbothpredicatespred1andpred2(deﬁnedonthecandidateclassclassXandclassY,respectively)aresatisﬁed.Therolewillberemovedfromtheobjectbyexplicitrequest(usingtheremoperator,andirrespectiveofpredicateevaluation),orimplicitlyifpred1isnolongersatisﬁed.Inthelattercasetherolemayreappearuponpossiblere-satisfactionofthepredicate.

Conjunction-basedcategoryclassesaremostinterestingincaseswheretherolemustbeexplicitlyadded,althoughmayalsobeautomaticallylost.Forinstance,onlypersonswhichareolderthaneighteenmaybecomeanemployee(assumingthisisthelawforsomeparticularwork).Whenanemployeeretires,theemployeeroleisautomaticallylost.

classEmployee:PersonWHEN!RetiredANDIFage>=18{...};

impliesthatsomeother(whichdoesnotreﬂectasuperclass)mustbelost.Anotherexamplesmodelshowanassociateprofessorroleisrevokedwhenpromotedtoafullprofessor(ProfessorisnotasubclassofAssocProfessor):

classAssocProfessorWHEN!ProfessorANDIFTrue{...};

class3isdeﬁnedbydisjunction,andthecorrespondingroleisaddedtosomeobjecteitherimplicitlybythesatisfactionofpredicatepred3oruponexplicitrequest(providedthatpredicatepred4issatisﬁed).Removaloftherolefromtheobjectisdependentonthewayitwasadded.Iftherolehasbeenimplicitlyadded(throughthesatisfactionofpred3)andpred3isnolongersatisﬁed,theroleisremovedfromtheobject.Ifroleremovalisexplicitlyrequested,theroleisremovedunlesspred3issatisﬁed.Notethatitisimpossibletoremoveexplicitlyarolewhichhavebeenimplicitlyadded.Furthermore,implicitlyremovedrolesmayreappearuponsomefuturere-satisfactionofthepred3predicate.

Anexampleofadisjunction-basedmanualandautomaticcategoryclassistheclassRetiredusedabove.InNorway,apersongenerallyretiresat67,butmaycontinueworkinguntil70whenshemustretire:

classRetired:PersonWHENage>=70ORIFage>=67{...};

3.5DisjointPredicates

Inmanycasesweﬁndthattherearenaturalrestrictionsonrolepossession,andwhichare,usingcategoryclasses,directlyassociatedwitheachclass.However,frequentlyweﬁndthattherestrictionismorenaturallyassociatedwithacompletecollectionofclasses,andsothatpossessionofarolecorrespondingtoeitheroftheseinhibitsthepossessionofothersfromthesamecollection.Forinstance,possessionofrolescorrespondingtoclassesChild,Employee,RetiredandDeadisinherentlydisjoint,andmaybespeciﬁedasfollows:

classclassclassclassChild:PersonIF!(Employee||RetiredEmployee:PersonIF!(Child||RetiredRetired:PersonIF!(Child||EmployeeDead:PersonIF!(Child||Employee||||Dead)||Dead)||Dead)Retired){{{{............};};};};

Asasimpliﬁedspeciﬁcationofthisrelationshipbetweenclasses,thenotionofadisjointpredicateisintroduced.Disjointpredicatesspecifythatnoobjectmaybeamemberofmorethanoneclassinaspeciﬁedcollectionatthesametime.Ifanobjectalreadyisaninstanceofoneoftheindicatedclasses(orasubclassofthisclass),itisnotpossibletoadd(explicitlyorimplicitly)anyoftheotherclasses,unlesstheformerclassiseventuallyremovedfromtheobject.Usingdisjointpredicates,thedeﬁnitionsabovemayberewrittenas:

disjoint(Child,Employee,Retired,Dead);

Disjointpredicatesmayrangeoverbothmanualandautomaticcategoryclasses,butmostfrequentlyapplyformanualcategoryclassesastheydeﬁneinherentrestrictionsonobjectevolutionandrolecombination.Automaticcategoryclassesareenablinginnature,andthusdeﬁnitionseasilymayconﬂictwithdisjointpredicates.Furthermore,disjointpredicatesaresolelyrolebased,andthuscannotreferencepropertiesofclassesparticipatinginthepredicate.Disjointpredicatesrepresentaconvenientshorthandspeciﬁcationmechanism,howevermayalwaysberewrittenintermsofequivalentrestrictionsdirectlyassociatedwiththeclassesinvolved.

Thenotionofanobjectroleisnotnew,andvariousapproachestoprovidingmoresupportformulti-perspectivedobjectsandﬂexibleobjectevolutionhavebeendescribediliterature.Inmosttraditionalobjectmodelsamulti-perspectivednatureofobjectsmayonlybedescribedthroughmultipleinheritance,deﬁningspecial“intersectionclasses”.However,theseclassesareconstructedabstractionswhichneednotreﬂectanynaturalabstractionfromtherealworld.Furthermore,asinglebehavioralcontextisimposed,whenmultipleindependentcontextsaremorenatural,andthereisapossibilityforacombinatorialexplosionofintersectionclassestomodelallpossiblecombinations.McAllester[MZ86]introduceanotionofbooleanclassestoalleviatethisproblem.Clovers[SZ]isparticularlyconcernedabouttheabilityforobjectstopossessmultipleindependentperspectives,howthesemaybeadded,andhowtheyareindependentlyreferenced.However,whilenewroles(orleavesinthe“clover”)maybeadded,theycannotberemoved.Consequently,Cloversmayhardlyberegardedtoproperlysupportevolvingobjects.OORASS[RAB92]ismoreconcernedabouttheroleasthefundamentalconcept,describingpatternsofcommunicationbetweenrolesandhowinstancesofdifferenttypesmayplayonerole.

Otherapproachesaremoreconcernedabouttheﬂexibleclassiﬁcationofobjectsthroughpredicate(overobjectstate)satisfaction.Inthiswayobjectsmayimplicitlyevolve,onthebasisofintensionaldescriptions.ManyapproachestoOODBviewshavebeenproposed,forwhichobjectsmayassumemembershipinvirtualclassesbasedonthesatisfactionofaselectionpredicate.However,virtual(view)classesoftencannotbemanagedinthesamewayasordinaryclasses.COCOON[SS91]isoneexample,andwillbedescribedbelow.ECR[EWH85]providesﬂexiblecapabilitiestodeﬁnehowinstancesofaclassmaybespecializedintosubclasses,andhowthesemaydeﬁnedisjoint/non-disjointandcomplete/non-completepartitionsofasuperclass.[Cha93]presentsanotionofpredicateclasses,whicharesimilartoordinaryclasses,butmembershipmayonlybeassumedautomaticallybypredicatesatisfaction.Specialrestrictionsonclassmembershipcombinationmaybeimposed.Predicateclassesaresimilartoourautomaticcategoryclasses,howeveraremostlyconcernedaboutthepossibilityforstate-speciﬁcobjectspecializationsfordispatchingpurposes(andassumptionofadditionalattributes).

Someapproachesareconcernedaboutobjectevolutiononexplicit(extensional)request.Aspects[RS91]allowsforarbitraryadditionandremovalofspecial“aspects”(chunksofstateandbehavior)toexistingobjects.Multipleaspectsmaybeaddedtoobjects,whichthusmaybehaveinamulti-perspectivedmanner.Theaspectdeﬁnitionisregardedasanextensiontosomeordinaryclass,butwillnotinheritstrictlyfromthisclass.Thismeansthataspectsdonotintegrateproperlywiththeordinaryclasshierarchy,withthepossibleimplicationthatanemployeeaspectadditiontoapersonmaynolongerbeacceptableasaperson.Iris[FBC87]alsoallowsforarbitraryadditionandremovaloftypesdynamically,howeverthereisonlyonecontextofbehavior,andthusnonotionofrole.[Zdo90]allowsforrolestobeaddedandremoved,providingspecialabilitiestospecifythatsomerolesarenotremovable(“essentialtype”),andthatsomerolesmayonlybeacquireduponcreation(“exclusionarytype”).Basedonthese,otherrestrictionsonevolutionmaybespeciﬁed,althoughinanawkwardandunnaturalway.[Ara]deﬁnesconversions(changeclass)andenhancements(addclass)toobjectsthroughspecialfunctionsassociatedwiththesourceclassofthemigration,andwhichdeﬁneallvalidmigrationpatternsofobjects.

Finally,[Vel93,SS91]provideabilitiesforbothimplicitandexplicitevolution(classiﬁcation)ofobjects.[Vel93]allowsobjecttobespecialized/generalized(toasubclass/superclass)upontheoccurrenceofanevent(amethodinvocation),providedthatanassociatedassertionissatisﬁed.Asboththeseareoptional,atransitionmaybecompletelyimplicit(noevent),orexplicit(noassertion).Lifecycles(sequencesofvalideventoccurrences)maybedeﬁnedtorestrictvalidpatternsofevolution.Tomodelthefactthatinstancesofdifferentclassesmayplaythesamerole,atransitiontooneclassmayoriginatefromdifferentsourceclasses.However,inthiswaythedestinationclass(denotedaphase)willbehavedifferentlyfromordinaryclasseswrt.inheritanceand

theclass.COCOON[SS91,SLT91]describesanOODBviewmechanismwhichdistinguishestype(interface)andclass(collectionofobjectswiththesametype).Theseareorganizedindifferent(butoftencorrelating)hierarchiesforpropertyinheritanceandsubsetting,respectively.Classesmaybeassociatedwithapredicate(overthestate),statingnecessary(correspondingtoourmanual)ornecessaryandsufﬁcient(correspondingtoourautomatic,andreﬂectingaselectquery)conditionsonmembership.Inthiswayobjectsmaydynamicallyevolve(bygaining/losingclassmembership)implicitlyoruponexplicitrequest,whichmayalsoimplytheassumptionofmoretype.However,thesetypesarevirtual(i.e.derivedfromothertypes),andthusobjectscannotassumenewstate.COCOONalsoprovidesspecialset-theoreticoperatorsforthedeﬁnitionofviewclasses,withspecialrulesforhowthesearetobeplacedintheclasshierarchy).Noarbitrarypropagationofmembershipintosiblingclassesare,however,possible.Furthermore,nocombinationofmanualandautomaticspeciﬁcations(whichwasfoundtobeveryusefulinSection3.4)maybegiven.COCOONisprimarilyaviewapproach,andthusmoreconcernedabouthowvirtualclassesandtypesaretobelocatedintheclass/typehierarchies,andhowtheymapontobaseclasses/types.

5Conclusions,ContributionsandFurtherWork

Anotionofanobjectrole,describingaperspectiveofanobjectasaninstanceofaparticularclass,hasbeenpresented.Rolesmaydynamicallybeaddedorremovedfromobjects,accordingtohowreal-worldobjectsevolveandexhibitthemselvesthroughmultipleperspectives.Categoryclassesdescribeconstraintsonvalidevolutionpatternsandcombinationofroles,aswellasdeﬁninghowthepossessionofarolemaybeautomaticallyenabled.Finally,categoryclassesconstituteapowerfulvehicleforconceptualmodeling,withﬂexiblemeansforobjectclassiﬁcation.Whilethemodelhasbeenpresentedinadatabasecontext,theimportantaspectshavemoregeneralapplicabilityasapowerfulmodelingframeworkorpartofaprogramminglanguage.

Themajorcontributionsoftheapproachrelatetothewayﬂexibleclassiﬁcation,objectevolutionandthemulti-perspectivednatureofobjectsaresmoothlyintegratedwithinanobjectmodelbasedonC++.Thisisachievedbyretainingthesameabstractionmechanism(theclass)asthebasisforclassiﬁcationandaddition/removalofroles.Inthiswaytheimportanceoftheclasshierarchyasanorganizationofreal-worldknowledge(conceptualspecializationandpropertyinheritance)isnotaffectedbytheaddedmodelingpower.Theapproachintegratesmultipleclassiﬁcationmechanisms:Class-basedclassiﬁcationisdeﬁnedbyordinaryclasses,andset-basedclassiﬁcationmaybedeﬁnedextensionally(bymanualcategoryclasses)andintensionally(byautomaticcategoryclasses).Membershipindifferentclassesmayberegardedindependently,asdifferentperspectivesofthesameobject.Aparticularlyusefulprovisionistheabilitytopropagateobjects(possiblyconditionally)intootherclasses,i.e.acquiringnewrolesonthebasisofsomeparticular(combinationof)role(s)possessed.Theapproachallowsobjectstoevolveovertimewithspecialfacilitiestorestrictandenableobjectevolutionbasedonboththestateandrolepossessionoftheobject.Inthiswayobjectsmayexplicitlyandimplicitlygainandloserolesandpropertiesdynamically,withoutcompromisingtheclasshierarchyastheconceptualorganizationofreal-worldknowledge.

AprototypeOODB,incorporatingthenotionsofobjectroleandcategoryclasses,isbeingimple-mentedtodemonstratetheapplicabilityoftheideas.Preliminaryresultsarepromising.However,theprimaryfocusofourworkiswithintheareaofschemaversioning,andhowdifferentschemaversionsmaycontaindifferentversionsofthesameclass.[Odb94]willshowhowtheevolutionaryandmulti-perspectivednatureofobjectshavemanytraitswhicharesimilartotheevolutionaryandmulti-perspectivednatureofclasses,andhowmanyprinciplesofmanagementarethesame.

AcknowledgmentsSveinErikBratsbergandReidarConradiareacknowledgedforcommentsanddiscussions.

[Ara]

ConstantinArapis.TypeConversionandEnhancementinObject-OrientedSystems.InD.Tsichritzis:ObjectOrientedDevelopment,pages191–205.CentreUniversitaired’Informatique,Universit´edeGen`eve,July19.CraigChambers.PredicateClasses.InECOOP’93.EuropeanConferenceonObject-OrientedProgramming,Kaiserslautern,Germany,July1993.

[Cha93]

[EWH85]R.Elmasri,J.Weeldreyer,andA.Hevner.TheCategoryConcept:AnExtensiontotheEntity-RelationshipModel.InternationalJournalofData&KnowledgeEngineering,1,May1985.[FBC87]D.H.Fishman,D.Beech,H.P.Cate,E.C.Chow,T.Conners,J.W.Davis,N.Derrett,

C.G.Hoch,W.Kent,P.Lyngbaek,B.Mahbod,M.A.Neimat,T.A.Ryan,andM.C.Shan.Iris:AnObject-orientedDatabaseManagementSystem.ACMTransactionsonDatabaseSystems,January1987.Alsoin[ZM90].

[MZ86]

DavidMcAllesterandRaminZabih.BooleanClasses.InProceedingsoftheConferenceonObject-OrientedSystems,LanguagesandApplications(OOPSLA),Portland,Oregon,USA,pages417–423,September1986.

ErikOdberg.What\"What\"isandisn’t:OnQueryLanguagesforObject-OrientedDatabases.Or:ClosingtheGap-Again.InTOOLSUSA’92(TechnologyofObject-OrientedLanguagesandSystems),SantaBarbara,California,USA,August1992.ErikOdberg.MultiPerspectives:ObjectEvolutionandSchemaModiﬁcationManage-mentinObject-OrientedDatabases.PhDthesis,DepartmentofComputerScience,NorwegianInstituteofTechnology,1994.Inpreparation.

[Odb92]

[Odb94]

[RAB92]TrygveReenskaug,EgilP.Andersen,ArneJørgenBerre,AnneHurlen,AntonLandmark,

OddArildLehne,ElseNordhagen,EirikNæss-Ulseth,GroOftedal,AnneLiseSkaar,andP˚alStenslet.OORASS:SeamlessSupportfortheCreationandMaintenanceofObject-OrientedSystems.JournalofObject-OrientedProgramming,5(6):27–41,October1992.

[RS91]

JoelRichardsonandPeterSchwarz.Aspects:ExtendingObjectstoSupportMultiple,IndependentRoles.InProceedingsofACM/SIGMOD(ManagementofData),Denver,Colorado,pages298–307,1991.

MarcH.Scholl,ChristianLaasch,andMarkusTresch.UpdatableViewsinObject-OrientedDatabases.InProceedingsoftheSecondInternationalConferenceonDeduc-tiveandObject-OrientedDatabases(DOOD91),Munich,Germany,December16-18,1991,pages1–207,December1991.

MarcH.SchollandH.-J.Schek.SupportingViewsinObject-OrientedDatabases.IEEEDataEngineeringBulletin,14(2),June1991.

LynnAndreaSteinandStanZdonik.Clovers:TheDynamicBehaviorofTypesandIn-stances.Technicalreport,BrownUniversity,DepartmentofComputerScience,Novem-ber19.TechnicalReportNo.CS--42.

AmandiodeJesusC.VazVelho.FromEntity-RelationshipModelstoRole-AttributeModels.InProceedingsofthe12thInternationalConferenceontheEntity-RelationshipApproach,Arlington,Texas,December1993.

StanleyB.Zdonik.Object-OrientedTypeEvolution.InFranc¸oisBancilhonandPeterBuneman(Eds.):AdvancesinDatabaseProgrammingLanguages,chapter16,pages277–288.Addison-Wesley,1990.

StanleyB.ZdonikandDavidMaier,editors.ReadingsinObject-OrientedDatabaseSystems.TheMorganKaufmanseriesinDataManagementSystems.MorganKaufman,1990.ISBN0-55860-000-0.ISSN1046-1698.

[SLT91]

[SS91][SZ]

[Vel93]

[Zdo90]

[ZM90]

因篇幅问题不能全部显示，请点此查看更多更全内容

查看全文