NAME : Jamuna Sundrum Romilla Thekkethala HOST : Binoy Samuel ACCOUNT NUMBER : sundrum 012-80-9481 romilla 100-80-8102 PROJECT : CHECK FOR OBJECT EQUIVALENCE BETWEEN 2 CLASS DICTIONARIES. DESCRIPTION : This project checks two class dictionaries for object equivalence. Two graphs G1 and G2 are said to be object equivalent if the following conditions holds true. 1) The construction vertex set VC1 of G1 = the construction vertex set VC2 of G2. 2) For every vertex v in VC1, PartClusters (v) of G1 = PartClusters (v) of G2 Our project validates the above conditions for any 2 CD graphs and displays a message saying whether the two graphs are object equivalent or not. DIRECTORY : /proj/demsys/com3360-f97/romilla/project/final /proj/demsys/com3360-f97/romilla/project/README-project GROWTH PHASES : /proj/demsys/com3360-f97/romilla/project/Growth-phases/superclass /proj/demsys/com3360-f97/romilla/project/Growth-phases/associations /proj/demsys/com3360-f97/romilla/project/Growth-phases/partclusters /proj/demsys/com3360-f97/romilla/project/Growth-phases/matches CREDITS : The project is based on the case study in the text book Adaptive Objet-Oriented Software . The Demeter Method with Propogation Patterns by Karl J. Lieberherr. We would like to thank Professor Karl J. Lieberherr and our host Binoy Samuel for their time. CLASS DICTIONARY : objequiv.cd GROWTH PLANS MOTIVATION : We were very interested in getting a better grasp of the power of DemeterJava and hence had decided to choose a project that involved the use of this tool. INCEPTION : Out of the list of proposed projects coincedentally we both chose the project to check object equivalance and on talking to each other after the lecture decided to work on it as a team. ELABORATION : * Requirement Risks : We clearly understood what the deliverable from this project was. As the requirements were also outlined in the case study in our text book, the risk involved was minimal. * Skills Risks : As we are novice object oriented programmers, we were concerned about having to learn Demeter java and implement the theory that we had learnt in the lectures within the stipulated time constraints. *Political Risks : There were none in this project. PLANNING : We planned to split the project into several phases. The phases were * Find all super classes for a given class * Find all immediate parts of a class * Find all parts of all super classes * Find associations for each part class * Find partclusters * Determine if 2 clusters are equivalent We did put together a time schedule however we ran into a stumbling block in the phase that involved finding the parts of super classes and this upset the schedule. However, with several long hours of work we managed to complete the project on time. CONSTRUCTION : The project was developed in phases. At each phase, the program was tested to ensure that the design specifications of the phase was met. We created a separate directory for each phase. The phases were 1)Find all Super Classes of a given class: find_super_classes2(vertex,cd-graph) Here we use a traversal CV from Cd graph to vertex via Adjacency and pass it a PrintSuperVisitor which takes a vertex as an argument. ( All alternatives of alternation classes in the cd graph are passed in as vertex objects.) The function is called recursively till all the super classes of a vertex are found. The Cd graph is passed in to facilitate the recursive calls. 2) Find Immediate parts The immediate parts of a class are found in the partsVisitor as part of its traversal before an adjacency. The parts are appended to a labeled vertex list. 3)Find Inherited Parts : find_inh_parts(Cd graph) This method creates an InhPartVisitor and does a traversal VV from vertexlist to vertex.The InhPartVisitor when it finds the right vertex, calls another function find_inh_parts2 which creates a visitor AdjPartVisitor and sends it on a traversal from AL from Adjacency to Labled Vertex. The visitor then appends the parts to the labeld vertex list. 4)Insert Associations : The AssocVisitor and the AssocClassVisitor are associated with this phase. The idea behind this phase is to replace all alternation classes with their alternatives.This call is recursive untill you get all instantiable subclasses of a given class. 5)Check if two CLusters match: graph1.check_equivalence(graph2) The outcome of the previous phases is a cluster which is a list of part clusters for a given cd graph. The traversal CLPCL is from Cluster to partCluster and uses a Visitor ClusterCompVisitor.For every Source in the first cluster it checks to see if all the labeled vertices match the corresponding source in the second cluster. This matching on parts is done by another visitor FindClusterVisitor. A count of the number of parts of graph1 and the number of matches is maintained.If the two do not match an error flag is set in the ClusterCompVisitor. If all the parts of every part cluster match, and cluster 2 does not have more parts than cluster 1, the 2 CDs are said to be object equivalent. If the second CD graph has all the parts of the first CD graph but in addition has a few more parts, then graph2 is said to be a weak extension of graph1. ENHANCEMENTS : Given more time we would have liked to have added the following features to our project. * Change the Cd to handle the current demjava cd * Determine if an extension relation is a weak extension or an extension relation * Check for syntactically and semantically incorrect class dictionary graphs. eg. A violation of the unique label rule. * Better Exception Handling * Better naming Conventions * KNOWN BUGS 1). The input class dictionaries must have the string "*common*" even if they do not have a common part. eg. A : B|C *common*. is a valid input. A : B|C. is invalid 2). Currently, the is_constr_class() function in the ClusterCompVisitor class which checks if a part cluster source is a construction class is called after the traversal . A more elegant way is to perform the check prior to the traversal namely before the part cluster could result in a performance gain for large graphs. NAME OF TEST INPUT FILES : objequiv.input objequiv1.input, ex2.input ex1.input ( Case study example ) NAME OF OUTPUT FILES : out_equiv ( objequiv.input, objequiv1.input) out_nonequiv ( ex1.input, objequiv.input) out_ex_extension ( ex1.input, ex2.input) INPUT/OUTPUT PAIR : Input : objequiv.input Furnace = ProbeTempSensor FurnaceTempSensor NormSensor. ProbeTempSensor = Temperature . FurnaceTempSensor = Temperature. NormSensor : OilSensor|FaultSensor *common*. Temperature : Kelvin|Celsius *common*. Kelvin = Number . Celsius = Number. OilSensor = . FaultSensor = . Number = . Dummy = . Input File : objequiv1.input Furnace = ProbeTempSensor FurnaceTempSensor NormSensor. TempSensor : ProbeTempSensor|FurnaceTempSensor *common* Temperature. NormSensor : OilSensor|FaultSensor *common*. Temperature : Celsius |Kelvin *common* Number. Kelvin = . Celsius = . OilSensor = . FaultSensor = . Number = . ProbeTempSensor = . FurnaceTempSensor = . Output ======= ---------------------------------------------------------------- *clusters* *source* Furnace ( < probetemp > ProbeTempSensor < furnacetemp > FurnaceTempSensor < norm > OilSensor, FaultSensor ) *source* ProbeTempSensor ( < temp > Kelvin, Celsius ) *source* FurnaceTempSensor ( < temp > Kelvin, Celsius ) *source* NormSensor ( ) *source* Temperature ( ) *source* Kelvin ( < value > Number ) *source* Celsius ( < value > Number ) *source* OilSensor ( ) *source* FaultSensor ( ) *source* Number ( ) *source* Dummy ( ) ---------------------------------------------------------------- *clusters* *source* Furnace ( < probetemp > ProbeTempSensor < furnacetemp > FurnaceTempSensor < norm > OilSensor, FaultSensor ) *source* TempSensor ( < temp > Celsius, Kelvin ) *source* NormSensor ( ) *source* Temperature ( < value > Number ) *source* Kelvin ( < value > Number ) *source* Celsius ( < value > Number ) *source* OilSensor ( ) *source* FaultSensor ( ) *source* Number ( ) *source* ProbeTempSensor ( < temp > Celsius, Kelvin ) *source* FurnaceTempSensor ( < temp > Celsius, Kelvin ) ------------------------------------------------------------------------- PART CLUSTER OF Furnace MATCHED PART CLUSTER OF ProbeTempSensor MATCHED PART CLUSTER OF FurnaceTempSensor MATCHED PART CLUSTER OF Kelvin MATCHED PART CLUSTER OF Celsius MATCHED PART CLUSTER OF OilSensor MATCHED PART CLUSTER OF FaultSensor MATCHED PART CLUSTER OF Number MATCHED PART CLUSTER OF Dummy MATCHED ------------------------------------------------------------------------- PART CLUSTER OF Furnace MATCHED PART CLUSTER OF Kelvin MATCHED PART CLUSTER OF Celsius MATCHED PART CLUSTER OF OilSensor MATCHED PART CLUSTER OF FaultSensor MATCHED PART CLUSTER OF Number MATCHED PART CLUSTER OF ProbeTempSensor MATCHED PART CLUSTER OF FurnaceTempSensor MATCHED **** BOTH CLASS DICTIONARIES ARE OBJECT EQUIVALENT!!!! SOFTWARE REUSE : * Possible Integration into AP Studio. No we did not change the generated Java Code.