Home
CS501 VOTE: Visual Object Tracing Engine
Contents
1. CS501 VOTE Visual Object Tracing Engine The Internal Documentation Carrer Marco mcl20 cornell edu Chang Thomas hc75 cornell edu Lin Paul pil3 cornell edu Stein Chris cas38 cornell edu December 5 1997 Table of Contents Some Information ooo repere vete tbe En E Rape FF CY Fn FF 4 system Architecture m FM 5 Subsystem Diagram Preprocessor cease ie aa OY sae eta een ds ets 6 The Preprocessing Engin erre treten nae ee vent oU PE eet to Poe erae eo eee tao seo e UR on enne epa pra YDD 6 Tel Dkand E ion nct ettet etia e at cack A 8 Preprocessor Flow Chart tists inca uae O tolto GG O EF 9 Order of Events in the Preprocessor eee ee esee esee eese eese en neta ne tn aetas eto setae ODD ete sete stas ena sta 9 Cl PreptOCeSsOE suit eoe eue diam odas FY ecu tue opas uM p E da av ene tpe 11 Tnheritan CO MN M 11 iid E TE e m 11 ling n rase 11 Configuration INGEL DREGE ag cdd ete titi nr Mini de ona Reit ha diets quieto 13 cl PreiSet once Y iat acted GU Y YM Deed eu 14 Tit erfAcoS uu PES 14 lii ci CH HR FYN NR Y HR A PY FAR Y HD SR RY AR 14 el R n96et sitse i y Y cestode In Y een ets 16 TnterfacoS iei iy i Y YS 16 LL aiu RF FR AFAN SUT HEN EF FE ND RF AN RF RD EE M 16 cl ClassFlash uu Du NY monte Y Yd NOAH 17 IES u ACES Y HR FY FN NR HF A I FR FD 17 liz n rime 17 gi
2. HP 18 um C 19 TM erTaco ec S 19 lii i Me M T 20 el TimeLine S cl bos Event uu ene coeno d tendeiuna li tete ies 21 cl TimeLine Interface ncc ri rp edyn DN YNYR oneri oY YSW FODYDD Pape 21 cl TO SEVEN D CUTE CERT RE 21 CIA SEI eT ORCI AOR octo UR add tmc e iquat unde a DAS 23 lS Y EE T M 23 Tniternals T 23 cl Linebile5tr aimi iui et de tete Hei Yg ies 24 TInteErTacG se ENTRE 24 Rendering Engine cl MSCDra wer irit tte tioni te Siete ua a gea en t denen 25 iiu aun ree 26 iiu Lu TR LYFU HN FRYN TH RF EFA HF RN 27 Limitations and Ass mbptiOn ceterae ie en rene eran eror eoe o roa E Nana NER DES ER ie Sene PENNE rb ERE ee ee opas 27 ud Co ET H 28 Fnternalsc ANE 28 Interfaces e YE seese o Cosor Eee GN EEF NE DF Ce dened 28 Subsystem Diagram Main GU uu gid RO GARU NGR GGDS La Rentas 29 The Main GUL ret 29 Mam GUI Flow Chart eu ed GY GN DO YY Fo 31 Order of Events in the Main GUI vai ccessisssssevanscssetsancelsossceusasestesiorisovstetvasvagsonssvsuetsubsonscaessedeans 31 Limitations and Assutpblobls ua ga a GOR DN Seemann 32 TOS ELIS FT NNDR RT HAYS UF FFF CN NN FEN CH UN WYD Y ER ans 33 TNGIVIidUALSUDSYSLEMS 5 s5scccsesccssoetecsensssrcsssnessOsvccsseccsonssscvedssessvoseseCssectssestonedacssccaseestosenasesscsse
3. Parameters set to new Values from file values Default Settings stored in INI file Save changes to INI file 13 cl PrefSet Cl_PrefSet is responsible for maintaining the preference parameters specified by the user A group of private member static data fields are used for storing the data Three major public methods will be provided for other classes to access the parameters Two methods are created to transport data member variables to and from the Tcl Tk script The data member variables and public methods are defined as static The cl_PrefSet class is never instantiated by other classes Access to the preference parameters is achieved by invoking the static member methods Interfaces cl PrefSet SetPar FieldName char Value Other classes can use this function to update any setting field Field is an enumerated data type with the names of all the fields in cl_PrefSet cl PrefSet GetPar FieldName char Value This method is used for retrieving the current setting of preferences Field and FieldType are described above static int SetAllPar Clientbata Data Tcl_Interp interp int argc char argv static int GetAllPar Clientbata Data Tcl_Interp interp int argc char argv These two methods are invoked in Tcl Tk script to acquire or modify the preference parameters The correspondence between the order of arguments from Tcl Tk script and that of global variables in C code is coordinated
4. function links a Tcl procedure called DoFile same name to keep things clear to In the Tcl script we can then invoke this function by simply calling DoFile This function in turn calls an internal function called Do after checking that the file has not been modified Internals Private Data Members Private member objects used to store all the locations of where to look for function definitions so the modifier can insert code into the functions A helper class used is the cl_IndexPair that denotes a pair of indices in the string what the file has been read into where the function name is likely to appear Another data structure that was useful was the cl_Entry that stores a class name with a method name that belongs to the class This may introduce duplicates in the class names This is a concern only from a memory space minimization standpoint not one of our key design concerns The private data fields are cl Entry m eTable MAX NUM FUNCS This stores each entry that was parsed i e each function that was read by the parser cl IndexPair m ipTable MAX NUM FUNCS This stores each pair that was parsed This is useful when looking for functions because the function name of a function will always be between a close braces and an open braces int m iNumEntries int m iNumIndexPairs This keeps track of how many of which are in the arrays 11 Prioate Methods Most functions of this c
5. engine the log file parser the MSC renderer and the configuration interpreter The interfaces between subsystems whether a standard file format or set of public methods were well defined and agreed upon before implementation This allowed the subsystems to be developed in parallel by different designers The subsystems were tested in isolation before the merge This allowed the merge to proceed very smoothly with few problems Considering that the system stands at over 7500 lines of code the fluid merge was a real accomplishment Individual Subsystems What strategies did we use to test the subsystems Early on we drafted documents specifying the interfaces between components Master copies were made public on one of our subdirectories These docs were referred to freguently as we designed test cases for the individual subsystems Each of us did both white box and black box testing on our subsystems The white box testing involved stepping through code and watching execution unfold keeping an eye out for strange or unexpected behavior With black box we specified an input executed the system and checked that any output and the final state of the object were correct For most VOTE subsystems the input space is very large Just take a look at the preprocessing engine it is designed to take most C programs as input With such a vast test space we had to be very smart selecting test cases that seemed most likely to present probl
6. VOTE are the vote exe executable and the vote tcl Tcl Tk script The main mode of interaction is done through calls to Tcl_CreateCommand in the main function Every call to Tcl_CreateCommand will set up a link between a static method of some class and a proc name that will be used in the script The word script really refers to the main vote tcl and all the other Tcl files that it sources The following are descriptions of such interactions grouped by modules The Preprocessor As mentioned before the preprocessor is both in Tcl Tk and C Tcl Tk handles the front end while C takes care of the back end The main entry point for the work of the Preprocessor is through a static member function of the aforementioned cl_Preprocessor class called DoFile This instantiates a new cl_Preprocessor and calls its Do function on the selected file The PrefSet Module The PrefSet class offers two method SetAllPref and GetAllPref for the Tcl Tk script to update and acguire the preferences parameters In the beginning of vote tcl GetAllPref is invoked to load the global parameter variables in C module into global variables in Tcl Tk script After the user makes changes to the parameters in the preference window and OK button is clicked SetAllPref is invoked to transport the new settings back to the C module The RunSet Module The available and viewable classes and methods are kept in two hash table structures in C module T
7. must possess the ability to interpret user commands We focus on three main windows The canvas on which the MSC is drawn the list box where the class names appear and the list box where the methods appear With the other auxiliary control buttons we also need an auxiliary manager to help smooth the communications Conseguently we have three sub modules the Class Manager the Canvas Manager and the Auxiliary Manager Class Manager The Class Manager juggles inputs from the user as well as other procedures of the Tcl script to maintain the two list boxes containing the class names and their methods The manager that handles user inputs will automatically update the methods list box when a class name is selected The other manager who receives internal commands mainly take care of updating the list of classes usually following some user file selection The implementation of the Class Manager is stored into two modules vote tcl where the implementation of the GUI widgets is defined and which is interpreted at boot time and in handling tcl which implements the necessary procedures to populate pop up menus and listboxes following from a user action Canvas Manager The Canvas Manager is responsible for handling the updates of the canvas It is closely bound to the C module that handles the generation of Tcl script that the canvas sources An interpreter lets this manager know that the canvas is to be updated so that it can perform the neces
8. parse subsystem then we will give detailed descriptions of the interfaces internal workings and the limitations assumptions of the key classes The log file subsystem is responsible for hiding the log file from the rest of the system The MSC renderer interfaces with the cl_Log class asking it for events and time line information Events are the arrows in the MSC diagram and time lines are the vertical lines On instantiation a cl Log object will parse the log file The cl tl stack StringTokenizer cl_LineFileStream and by inheritance ifstream are all used during the parsing The cl_tl_stack is used to store cl_LogEvents The cl_StringTokenizer and cl_LineFileStream condition the log file input cl_LineFileStream inherits from ifstream The cl_graph class with its cl edges class members is used by the cl_Log class in its graph theoretic heuristic for clustering time lines for the MSC diagram The OMT diagram below describes the relationships between the classes The methods getNextTimeLine getNextEvent and the booleans hasMoreEvents and hasMoreTimeLines are used by the MSC renderer to iterate through the cl TimeLines and cl_LogEvents respectively ifstream StringTokenizer cl_LineFileStream O O cl_LogEvent 18 cl Log Interface cl_Log char This constructor takes the char filename of the log file as a parameter and parses it filling the m_logEventArr array with log events and th
9. 914 cl RequestHandler cl_RequestHandler cl_Server theServer DrawOu DrawIn DrawOu DrawIn DrawMe prefsFile DrawMe thod thod prefFile DrawMe 11 DrawMe thod thod prefFile t 0x0006p914 cl RequestHandler cl_ReguestHandler cl_Server theServer 0x0006b918 cl ConfServer cl ConfServer t 0x0006p918 cl ConfServer cl ConfServer 0x0006b908 cl Server cl Server const char prefFile 0x0006b908 cl Server 0x0006D918 cl ConfServer LoadPrefs const char 11 0x0006b918 cl ConfServer 0x0006b908 cl Server cl Server const char 01 0x0006b908 cl Server 0x0006D918 cl ConfServer PrintStatus ostrstream amp ostr 0x0006b918 cl ConfServer 0x000650908 cl Server cl Server const char 01 We identify five commands 1 2 TimeLine Iter ResetCanvas clears the canvas and reinitialize the local Tcl variables for a new drawing DrawInstance creates a new timeline starting from the class name and the object memory address pair The representation will be a box on the top of the canvas and a vertical line DrawIn displays a trace representing the entering of a method The actual sender of such a message is unknown in this case This might be due to the fact that we did not trace the sender no auto log class has been inserted DrawOut displays a trace representing the exiting of a method The actual class we are returning to is unknown in this case This might be due to the fact that we did not trac
10. am char filename ifstream filename char getLine 24 Rendering Engine cl MSCDrawer The rendering engine will be implemented into the cl MSCDrawer class The cl MSCDrawer class is responsible for translating a cl Log structure into an MSC diagram that can be plotted on a Tcl Tk canvas The idea behind is based on the possibility offered by Tcl Tk to source code at running time The Tcl interpreter lets you therefore generate code that will be dynamically loaded at running time adding capabilities to your program The approach taken is to exploit this possibility and generate the Tcl code necessary to plot the MSC corresponding to the given cl_Log structure Once the code has been generated cl MSCDrawer will trigger an event in the GUI which will then show the new MSC to the user by loading it into the Canvas widget The diagram below shows the information flow among the major components involved into the process cl_PrefSet cl MSCDrawer generates xxx tcl file code The first step of the process is performed by the cl_Log class which parses the log file and extracts a seguence of events from it While iterating through this information repository with cl_Log s getNextEvent cl MSCDrawer generates the appropriate Tcl code into a new file The code consists of a seguence of Tcl commands that use a Canvas widget to perform the actual drawing A set of abstraction routines are pre programmed in Tcl to reduce the
11. amount of the code to be generated The latter also provide a level of abstraction over the verbose Tcl Tk syntax necessary to actually get the drawing During the rendering operation cl MSCDrawer takes into consideration the current user preferences for basic element properties as background and or foreground colors and for the filtering of classes and methods which the user want to hide in the current rendering triggers Tcl_Interpreter Such a widget lets the developer assign an area of a window as a canvas conventional and simple commands such as createline and createbox will be used to the do the actual depicting We use the canvas widget and its command syntax to plot the final MSC However the abstraction offered by these procedures can be seen as a high level drawing language customized for our needs This use of such a language ensure that our rendering will not be bound to Tcl In the future we could use alternative renderers interpreting this drawing language appropriately An example of the generated code follows ResetCanvas DrawInstance cl_RequestHandler 0x0006b910 DrawInstance cl_FullRequestHandler 0x0006b910 DrawInstance cl_Server 0x0006b908 DrawInstance cl_ConfServer 0x0006b918 DrawInstance cl_ReguestHandler 0x0006b914 DrawIn 0x0006b910 cl FullRequestHandler cl FullRequestHandler cl Server server DrawOut 0x0006b910 cl FullRequestHandler cl FullRequestHandler cl Server server 25 DrawIn 0x0006b
12. ate Cmd Ready to generate MSC on canvas Generate MSC Canvas shows updated MSC Order of Events in the Main GUI This isolated flow chart reveals the order of updating the three main windows of the GUI The canvas where the MSC goes the list box for the class names and the list box for the methods The windows remain inactive until outside sources trigger change These changes include a Update command from the Preprocessor a Compile command from the user which may or may not be coupled with the Execute command and finally the Generate MSC command With the Update command the two windows containing the class name and associated method names will be updated accordingly When a user clicks on a class name to select it the windows with method names should change its contents to reflect the methods of the current selected class This can be done easily with simple procedures and the hash table mentioned in the documentation of the Preprocessor The flow is similar to that of the Preprocessor until the point where the log file analyzer comes in The termination of the analysis will trigger the updating of the Canvas window by sourcing another Tcl file generated during analysis After updating the MSC we re back to the initial state awaiting further requests from the user 31 Limitations and Assumptions As any other project is subject to the triple constraint VOTE contains many limitations in the f
13. ation file defaultini in the working directory If the user modified the preference setting a new initialization file user ini will be saved Subsequent executions will look for the file user ini first If it is not found defaultini will be used instead If both are not found in the current working directory execution will be terminated and error reported since VOTE needs preference parameters which specify the behavior of most actions PrefSaveFile will overwrite user ini every time 15 cl RunSet During execution after extracting information from the log file all the available classes and the methods will be identified Two lists will be kept to track this information The first one list keeps track of all the existing classes and methods in the log file The user has the freedom to choose which classes and methods to be shown in the MSC diagram The second list holds the selections The lists implemented using hash tables are maintained by this class cl_RunSet Two instances of cl_ClassHash sm_ClassHash and sm_FilterHash are kept as static private members Class cl_ClassHash will be discussed in detail in a later section This class provides public access to the contents of above two lists Due to the fact that cl_RunSet will interact closely with Tcl Tk script a dispatcher is created to invoke all the class methods to avoid passing multiple interpreter dependent variables to each member method Inte
14. ay of char Error GetMethod char char int Retrieve all the methods for a certain class Error ExistClass char Error ExistMethod char char Check the existence of a class and a method in a certain class Error DeleteClass char Error DeleteMethod char char Delete class or one method of a certain class from the hash table Error PrintAll Print the whole structure to standard output Internals Essentially cl_ClassHash is structured as a two dimensional array with class names in the first dimension and method names in the other dimension Each dimension is implemented using a hash table There is a key field and a value field in each element of a hash table In the hash table for first dimension class names are stored in the key fields and pointer to the second dimension hash table stored in the value field In the second dimension methods names are stored in the key fields Locating a class in the cl_ClassHash involves searching through the first dimension hash table Finding a method for a specific class on the other hand involves searching through both dimensions Two private members exist in cl_ClassHash These are Tcl_HashTable tblPtr Pointer to the Tcl Tk hash table object maintained by this class Error InsertMethod Tcl_HashTable char Method for inserting a method in the second hash table 17 Log File First we will give an overview of the structure of the log
15. by the enum type FieldNames static Error PrefLoadFile static Error PrefSaveFile The two functions are for loading and saving preferences parameters on disk to preserve persistent setting in every execution PrefLoadFile is automatically invoked at the beginning of execution and PrefSaveFile is called when user clicked the OK button in the preference window in GUI Internals Private member objects exist to contain all the preference settings All the public member functions are to access the private data members The private data fields are char fileExt possible file extensions char LastPath the last path where the user include the source files char compilerCommand application executable name of the compiler to use and arguments char linkerCommand application executable name of the linker to use 14 char logFileName file name of the log file char execFileName file name of the log file char compileDir compile directory for the executable char bgColor Background Color RGB values for example black 000000 white ffffff char bxColor Box Color char retArrowColor return arrow color char entArrowColor enter arrow color char timeLineColor timeline color char textColor textcolor char xSpacing space in pixels between 2 time lines char ySpacing space in pixels between two adjacent events The first time when VOTE is executed PrefLoadFile will look for the default initializ
16. e indices we insert not only the braces themselves but also the snippets of code to enable logging Error WriteToFile ofstream amp ofstr char szBuf 12 Configuration Interpreter Preference Setting Classes cl_PrefSet cl_RunSet Reset Reset Update Update Get Get There are two sets of configuration parameters that specify the run time preferences controlling all the available functionalities There are two classes which provide the data storage all the parameters in each set and offer public access of the data The cl_PrefSet contains the environmental settings that users specify at the beginning and do not change For example the user is allowed to specify the type of compiler and linker to generate executables File extension cc cpp or c of the source code is also specified at the beginning Parameters that users adjust regularly such as the visible classes in the MSC are stored in cl_RunSet Each class consists of three components Reset Set and Get Reset is used for setting all the values back to the default ones stored in the default objects Set and Get are responsible for accessing the data In RunSet a hash table class is needed to maintain a list of class information Flow Chart Parameters Parameters Finished Setting variables initialized to ready for retrieval allocated default values Input from log request file Default Settings User updates the values Load default
17. e m_timeLineArr array with time lines Here is the structure of a line of the log file classname 0x00000000 enter return timestamp methodname classname the name of the class 0x00000000 the memory address of the object class instance enter return enter on AutoLog allocation signaling method invocation return on AutoLog deallocation signaling method return timestamp system time at log event methodname the name of the method The parsing is not a simple task In order to draw message passing lines from time lines to time lines we must know what we are returning to We need a stack for this For example in the log file we may see the lines cl_FullReguestHandler 0x0006b910 ENTER 0090 HndleGetHeadRequest cl Request reg cl ConfServer 0x0006b918 ENTER 0090 IsToBeRidirected const char src cl ConfServer 0x0006b918 RETURN 0090 IsToBeRidirected const char src cl RequestHandler 0x0006D910 ENTER 00008000 ResolvePath cl Request reg After LINE 3 we return to the cl FullRequestHandler at memory address 0x0006b910 Function call return is context free We keep track of where we are with a cl tl stack object pushing and popping cl LogEvents as we parse the log file The cl tl stack supports push pop and peek Error getNextEvent cl LogEvent amp leFrom cl LogEvent amp leTo Two cl LogEvents are passed to this routine by reference This routine copies over the next two events in the m logEven
18. e the receiver no auto log class has been inserted DrawMethod displays the actual delivering of a message from one instance to another one Both instances are identified by the parameter list The same command can be used to express the returning from a method call the last two parameters are used to discriminate between the two cases cl MSCDrawer ofstream LogEvent Iter Internals The internal data structures of cl MSCDrawer are exposed in the above OMT class diagram Every cl MSCDrawer will accesses an instance a cl Log object The data stored in such an object will be then rendered into the MSC diagram The cl Log is queried repeatedly for events which are transformed into new Tcl commands which are saved into the Tcl Tk generated file This file is sourced at run time causing the refresh of the MSC canvas cl MSCDrawer inherits from the cl Gui class this is motivated by the fact the cl MSCDrawer interacts with the GUI The parsing of the log file can fail in which case the user must be notified This is done through the cl GUI ErrorDialog method 26 Interfaces The following MSC yes we use them in our design too shows a typical execution flow during the rendering of a new MSC diagram The Draw logFileName method triggers the interpreting of the supplied structure and generation of the corresponding Tcl drawing code Draw While hasMoretimeLine getNextTimeLine While hasMoreEvents getNextEven
19. e user will click on the Run menu item that initiates the execution of the altered program This will dump logging information in a file with a preset name According to the user s preferences this file will be copied to the name that he specified 10 cl Preprocessor The class cl_Preprocessor is the core of the preprocessing engine It plugs in to the Tcl Tk script like the other modules and uses information provided by the other classes like the cl_PrefSet class The main functionality that this class exports is the DoFile function It is the entry point of access to and from the Tcl Tk script The link between C and Tcl Tk is set up in the main function in main cpp The function DoFile parses files and inserts snippets of code into them specifically at the beginning of every function to log the entrance and exiting of each function As the requirements of Tcl Tk indicate this method is made static It instantiates an instance of the cl_Preprocessor class and calls an internal function Do for each file Inheritance This class inherits from the cl_Gui class because via that class error messages can be directed to message boxes in Tcl Tk Other classes such as cl MSCDrawer and cl_RunSet all inherit from this class for the same reason To have it function correctly we need to add some lines to set up a link inside the static method DoFile Interfaces static DoFile char szFileName As mentioned above this is what the main
20. ems For example with the cl_Log we made sure that we tested the parsing with input seguences that reached the bottom of the stack freguently forcing the generation of dummy events As well knowing that the cl Log objects expand the size of their m_logEventArr and m_timeLineArr arrays exponentially when they fill up we made sure to force exponential expansion with large log files with many time lines Once we had performed in depth smart testing corrected the revealed bugs and were guite confident in the correctness of our subsystems we began the merge Merged System We reached a stable state with the merged system much faster than with the individual components Most of the problems that we encountered during merge were superficial and easily fixed We reused many of the test log files from the subsystem testing phase concentrating on studying the correctness of the MSC diagram comparing it with the original log file This technigue worked guite well Early on we discovered that some events were not properly represented in the MSC diagram We corrected this guickly by parsing the log file with a stack and generating dummy events when we leave and re enter the top level of execution After this we had few problems and we feel very confident in the correctness of our final system 33
21. has been defined This log file is written to by AutoLog objects as the system executes 4 Log File Parser This parser reads in the log file and synthesizes the log file information into a series of events This information is made available to the MSC renderer through a simple iterator interface 5 Rendering Engine The rendering engine queries the log file parser for event information and draws with the canvas widget of Tcl Tk 6 In addition our system has a GUI subsystem In the following sections we offer a detailed introduction to each of the modules presented above For each section we offer some architecture diagrams class diagrams and flow diagrams The interfaces supported of key classes are also introduced Subsystem Diagram Preprocessor Preprocessor File Selector File Manipulator Program Handler Front end Parses Source File Selection through the Compiler source files Back end File and insert New Program Name List Autolog Code Executer The Preprocessing Engine The front end of the Preprocessor is implemented in Tcl Tk and the backend is done in C This subsystem of VOTE handles the preparation of relevant data before the actual analysis which will in the end generate the MSC output This step goes from the parsing transforming of source files to the compilation and execution of the program In the process it cooperates with the PrefSet module that keeps track of all the user selected preferences T
22. hat files he wants VOTE to parse and modify and use to draw an MSC The last directory scanned by the user is saved and exported to the PrefSet module for future default settings The set of files that the user chooses marks the first filtering stage of VOTE As this is less frequent the information is more static and therefore persistent we dump this information to a file along with other fields of the preferences This is also covered in the description of the PrefSet class At the request of the user by clicking on the Modify Sources menu item the core of the Preprocessor kicks in Using the class cl_Preprocessor the files selected in Tcl Tk are modified by the preprocessor through a static method that this class exports called DoFile The modifications made to the files as described earlier will enable the logging functionality while executing the program later So now that the files are ready to compile we need to rely on the user s preferences on what to execute when building his project Unfortunately there are certain limitations that we must adhere to All these will be further elaborated in the Limitations and Assumptions The user specifies this as part of the general preferences When he clicks on the Build menu item the building processes initiates using the user s preferences for compiler linker commands and compiling directory The status box at the bottom of the window will let the user Know when building is done Finally th
23. he RunSet class provides two methods GetClassList and GetMethodList to acquire information on all available classes Access to the viewable classes are achieved by a series of public methods which are FilterInsertClass _ FilterlnsertMethod _ FilterDeleteClass FilterDeleteMethod All the actions are invoked thorough a command dispatcher DispatchRunSet The MSC Module The MSC module takes the information analyzed from the log file and generates a Tcl Tk script file that will be run This choice was taken in that we will use Tcl Tk for our GUI which naturally includes the final output Preprocessor Flow Chart Initial State Idle before Select Sources is clicked Select Sources Has list of files to parse stored in ources a linked list preprocessor Update last path file filter and list of files selected PrefSet module has updated preferences Files in linked list asked by the user Modify are parsed by the Build Preferences are updated in PrefSet Module Ask PrefSet Source Files are modified and ready to compile Compile Source Files Executable built and ready to run Run Program Ready to Gather Info from Log Order of Events in the Preprocessor The main menu button that is associated with the Preprocessor is the Build menu button The following steps all involve the user s interaction with menu items under this The user first clicks on Select Sources to select w
24. he word preprocessor is a something of a misnomer because it doesn t preprocess source files in the conventional use of the word Instead it generates log files for the drawing engine of VOTE File Selector The File Selector Module is the first part that is implemented in Tcl Tk It is responsible for letting the user specify which files he wishes us to act on For example the user can point to a directory and specify a file filter to insert files into a storage place for the names The purpose of this is to have a default set of file names for every run draw of our tool The user can add or remove file names from this list with button clicks This is implemented using two list boxes one specifying files in the directory and one specifying the cumulative list of files the user has chosen There are two buttons in the middle to facilitate the user in moving files from one list box to the other This will be described further in the user manual File Manipulator The File Manipulator Module is the only part of this subsystem that is implemented in C The class responsible for this is cl_Preprocessor It scans each of the files that the File Selector gives it for all the function definitions saves this information and insert snippets of code in each implementation to trace function calls The code that is inserted is just an Autolog object declaration For purposes of not conflicting with the code already there we have chosen the c
25. lass name _mc120_hc75_pil3_cas38_cl_Autolog The concept behind the AutoLog code insertion as described in our description of the project is to statically construct an AutoLog object in the beginning of the function which will automatically log the entrance into the function Leaving of the function will also be logged by the destructor of the AutoLog class as the object goes out of scope In addition to the snippets of code the File Manipulator also inserts a line in the beginning of the file lt include mc120 hc75 pil3 cas38 cl Autolog h gt This file contains inline methods that handle all the logging Program Handler The Program Handler Module is responsible for compiling the altered source code that the File Manipulator Module outputted as well as running the newly compiled program This can all be done easily with a script Therefore it is done in Tcl Tk We need however information from the PrefSet module like build options to be able to have a functional compile run phase Attaining this information is also through Tcl Tk using a set of global variables since the PrefSet module also plugs in the Tcl Tk script Tcl Tk and C Since the project is done in both Tcl Tk and C we should discuss how the two languages work together The intuition is to have the Tcl script generate the main interface with the user providing the GUI and have the C modules do all the dirty work The two main modules that make up
26. lass are kept private because we only export one function The list of private methods of this class includes the following 1 This is called by DoFile to really modify the file with the name szFileName It first does a backup and then does the parsing inserting Error Do char szFileName char szBackup 2 This method parses the file and records where all the open braces and close braces are to set the stage for the next step involving parsing inserting Error ReadIndexPairs char szBuf 3 This method searches for the class name given a starting index where the is Thus the search is backwards Error FindClassName char szBuf char szName int iStart 4 This method searches for the method name plus the signature of the method also given a starting index where the is Unlike the class name searcher this being the one to search after the class name has been found returns an indicator of where it was found This is in the form of an index into the m_ipTable and will be stored together with the class name and method name of the current entry Error FindMethodName char szBuf char szName int iStart int amp iIndex 5 This writes the modified string back to the file The insertion is taken care of easily because while inserting we check if we hit an index where we need to insert by looking into the m_eTable remember that an entry in m_eTable stores an index to a corresponding m_ipTable entry At thos
27. nfortunately this is a very hard problem So rather than seeking to globally optimize we use a heuristic approach to select a good approximation to the optimal layout We now describe our clustering heuristic Clustering Heuristic Select the maximal weight edge from the graph Delete this edge If no list exists then create one with these two elements as the first two members of the list Continue extracting the maximal edge from the graph Every time we see an edge that has not already been put in to the list then scan the list from head to tail computing the net impact of the node insertion on the sum of all the edge weights across the linked list Insert the vertex where it will have the maximal impact Finding the maximal edge is implemented in O n time in the getMaximalEdge method of the cl graph class Scanning the list for each vertex will take at most O n time So in total our approximation runs in O n time Our experience with this heuristic has been very successful our profiles have been well clustered 20 cl TimeLine amp cl LogEvent cl TimeLine Interface cl_TimeLine objects represent the vertical time lines of the MSC diagram Error copy cl_TimeLine amp copies the values of the referenced object into our own members char m_className the name of the class char m memAddr the memory address of the object int m monotonicStamp a stamp used to differentiate between objects of the same class that
28. orm of assumptions made as well as performance metrics As we have done most of our development on Windows NT the program needs to be modified before running on Unix This is a higher level limitation of VOTE The following is a list of these limitations per module as they will be fixed enhanced in the next version of VOTE e The preprocessor currently assumes that the files that the user specifies contain method implementations and not only class declarations It only searches for the actual body of the function and insert the AutoLog code there In other words it does not handle in line functions that may appear in a class declaration e During source file modification the preprocessor makes a backup of the file appending the extension backup after the original file name The way it works now the preprocessor won t operate on a file if its backup already exists thus disallowing double processing of files This leads to two consequences when a user wishes to change his code If the change that the user wants to perform does not involve additions of functions then the user can operate on the modified file and everything will still work fine However if the change involves adding one or more functions the user needs to copy the backup file to the original file start editing from there and modify that file again by selecting the Modify Sources With this way of preprocessing one assumption that we have is that if a user wants to modify a s
29. ource file of name foo cpp he must make sure that he has no files with the name foo cpp backup in the same directory Otherwise that file will not be changed e If the user exits the program using any other way than selection from the Quit command button of the File menu the the changed files won t be restored e During the building and running phases of the preprocessing stage the preprocessor takes in user preferences from the Tcl script provided by the PrefSet module This automatically implies that the two have to be done via the command line Our assumption that the user will provide a makefile for the building is not always justified but it does simplify things a lot e We assume that the user is working in a directory where he has read and write access Numerous system calls are invoked in the Tcl script and they assume the user can create copy and delete files in the directories he specified Other small miscellaneous assumptions we made include the compiler and linker commands that the user specify must be a single command i e there cannot be more than one command given even separated by semicolons and the directories given in the preferences dialog should be existent e The log file name should not conflict with any existing file in the working directory VOTE will overwrite any file with the same name 32 Testing Our software architecture consists of several subsystems the GUI the preprocessor substitution
30. ple cl_RunSet extends the Tcl basic language by adding seven new commands A single dispatcher will be invoked whenever one of those commands is executed in Tcl The dispatcher will then extract the correct number of parameters and call the method supposed to handle the event The parameters are then returned back to Tcl through the interfaces offered by cl_Gui Interfaces cl_Gui offers interfaces to reset the parameter list returned to Tcl and methods to actually add a new string into such a list A particular convention has been used into the implementation for the error management and notification The first parameter returned to Tcl from a command implemented into C is an error code The client Tcl code is responsible for checking for an OK value on such a parameter before going on with the normal execution If an error is detected than a error dialog box has to be shown to the user and the execution should take a different path All this is achieved by making use of the cl Gui ErrorDialog method 28 Subsystem Diagram Main GUI Main GUI Class Manager Canvas Manager Aux Manager User Cmd Internal Cmd Internal Cmd Button Click Interpreter Interpreter Interpreter Interpreter List of Class Methods for a Canvas Information Names given Class Drawer Export The Main GUI The main GUI will be primarily implemented in Tcl Tk scripts It communicates with other parts of the Tcl script for most of its inputs Of course it also
31. rfaces DispatchRunSet ClientData Data Tcl_Interp interp int argc char argv TCL TK command dispatcher LoadClassList const char fileName Load in the log file and extract all the class information to sm_ClassHash and sm_FilterHash ResetClassList Reset both class list GetClassList GetMethodList char Acquire class names and method names from the sm_ClassHash FilterExistClass char FilterExistMethod char char FilterInsertClass char FilterInsertMethod char char FilterDeleteClass char FilterDeleteMethod char char Acguire information from and update to sm_FilterHash PrintClass PrintFilter Printing the contents of both lists to standard output for checking purposes Internals Two static instances of cl_ClassHash contain the information of all available and selected classes and methods Static cl ClassHash sm ClassHash All the available classes and methods Static cl ClassHash sm FilterHash Selected classes and methods will be updated dynamically 16 cl ClassHash We decided to implement the list structure used to store the information of classes and methods using hash tables The availability of Tcl Tk hash table routines facilitate the maintenance of the lists Hash table structure provides efficient look up and updates of the list Interfaces Error Insert char char Error GetClass char int Retrieve all the classes storing the list in an arr
32. rn the index of the appropriate existing one If this function creates a new cl TimeLine then it adds it to the m_timeLineArr array adjusting the size of the array if necessary The routine creates a new cl_TimeLine object in the following cases 1 On encountering a constructor call If an object of the same class has existed at this objects memory address before we will have a previous cl_TimeLine with the same class name memory address pair The field monotonicStamp is used to distinguish such cl TimeLines This cl_TimeLine is assigned the incremented monotonicStamp value of the most recent cl_TimeLine sharing the same class name and memory address 2 On encountering a new class name memory address pair Error orderTimeLinesForMscDiag This routine is called by the constructor to compute the ordering of the cl_TimeLines in the MSC diagram Over the course of the trace each time line will send a certain number of messages to each of the other time lines We can think of the number of messages as the weight of an edge connecting two time line vertices We want to group together those time lines that communicate with each other freguently for the benefit of the user trying to make sense out of the diagram Selecting an optimal such layout is eguivalent to a well known problem selecting the maximal hamiltonian path or if the graph is not fully connected selecting the maximal hamiltonian paths over the disconnected subgraphs U
33. s 33 Merced Meri WR YH HY RH I Y A GI HN 33 Some Information Status of Project Tested documented and ready for download from http www csuglab cornell edu Info People hc75 initSpec htm Technologies Used Tcl Tk release 8 0 C with Microsoft Visual C 5 0 Purify to check for memory leaks Lines of Code C code 4 800 Tcl Tk 3 000 System Architecture Preprocessor Substitution Engine LogFile C LogParser Configuration Interpreter Renderer As highlighted in the first project proposal the software architecture of VOTE consists of five subsystems The above diagram depicts the subsystems and their high level interconnections 1 Preprocessor and Substitution Engine This collects the names of all the methods declared in a class We use the regular expression functionality of Tcl in our approach to parse method declarations To do this we call the Tcl Interpreter within our C C code The preprocessor also parses and replaces the method declaration line inserting an AutoLog object declaration immediately afterward in the body of the routine 2 Configuration Interpreter Sets up the configurations of the tool so that it knows how to rebuild the project and run it This is done through a GUI dialog box where the user is asked for the commands to accomplish this We also require the command to run the project because the log file is produced at run time 3 Log File A log file format
34. sary operations The CanvasLib tcl collects all the necessary procedures to reset and clean a canvas and perform all the drawing operations The implementation of DrawInstance and DrawMethod the commands generated from the cl MSCDrawer are kept in this module 29 Auxiliary Manager There are buttons called Start Stop and Run which are the controls for other modules as well There needs to be naturally an interpreter that translates each of the commands internal and external for the GUI Conversely information that GUI holds may be useful for other modules so we need to have a part that exports information outwards Most of these auxiliary widgets are collected into the menu bar and the drawing tool bar This includes both buttons which let the user select the starting and ending method for a new drawing and the draw and reset button The actual declaration of those widgets is stored into the vote tcl module Additional modules and dialog boxes are defined for handling the user preferences and the run time settings Those are collected into the Prefs tcl build tcl and select tcl 30 Main GUI Flow Chart Idle before command from Preprocessor Update Cmd Has updated class an Source files are Log is generated information Source compiled amp await Execute and awaiting Fles Frosr mn Name with and les execution Canvas Togram analysis methods for each is still empty Log File Analysis Upd
35. share the same memory address over time int m locMscDiag the physical location in the msc diagram computed by heuristic to maximize clustering cl LogEvent Interface Individually cl LogEvents represent one end of an MSC message arrow Error copy cl LogEvent amp copies the values of the referenced object into our own members int isDummyEvent returns if this is a dummy event 0 otherwise A dummy event is used to mark events int m timeLineIndx the index ofthe time line associated with this event char m methodName the method name of this event char m timestamp the timestamp int m direction the direction O for method return 1 for method enter Sometimes we need cl LogEvent placeholders These are known as dummy events Consider the log cl ConfServer 0x0006b918 ENTER 000007000 cl ConfServer cl ConfServer 0x0006b918 RETURN 000008000 cl ConfServer When clients ask the cl Log for events we give out the next two in the m LogEventArr If the log file contained only those two lines immediately above then the cl Log would on parsing create a dummy event that we come from on entering cl ConfServer So the sequence of log events would be DUMMY EVENT cl ConfServer 0x0006b918 ENTER 000007000 cl ConfServer cl ConfServer 0x0006b918 RETURN 000008000 cl ConfServer DUMMY EVENT Dummy cl LogEvents do not belong to a time line They are just placeholders In the MSC diagram we see d
36. t PEERS DrawlInstance Limitations and Assumption Currently the criteria used for identifying timelines in a canvas uses a className memAddress pair This can be extended in the future in order to take advantage of the time stamp associated with each timeline during the parsing of the log file 27 cl Gui c Gui is the class offering the hook from the Tcl Tk code to the C core of VOTE It provides a set of methods abstracting on the communication between the C code and Tcl Tk Defining such a class let us group the common implementation of all those classes which need to send feedback to the Tcl Tk gui Internals The implementation of cl Gui is currently a set of static methods which embed the syntax of the communication between Tcl Tk and C The following inheritance diagram shows the relatioships of cl_Gui with other components of the system cl_RunSet cl MSCDrawer All the three derived classes above have to interact with the Tcl The way this is achieved is common for all of them No matter how many new Tcl commands each of these classes extend from the basic Tcl all those commands will be addressed to a single method in their code Such a method will then dispatch accordingly to the first argument passed command name to the appropriate method into the class If necessary the dispatcher will also take care of the marshalling of the command by type casting all the parameters of the handling method As an exam
37. tArr and moves the iterator forward Taken together these two events contain the information to draw an arrow in the MSC diagram from one time line to another Error getNextTimeLine cl TimeLine amp This routine is used to iterate through the cl_timeLine objects stored in m_timeLineArr Error getTimeLine cl_TimeLine amp int Alternatively we can extract a cl_TimeLine object from the m_timeLineArr by specifying an index in to the array int hasMoreTimeLines This routine returns 1 if more timeLines remain to be iterated through 0 otherwise int hasMoreEvents This routine returns 1 if more cl_LogEvents remain to be iterated through 0 otherwise 19 log_state currentState The cl Log constructor does a lot of work it opens the log file parses it and inputs all the information into the m_logEventArr and m_timeLineArr arrays void resetLogEventIter The user calls this routine to reset the m_logEventArr iterator void resetTimeLineIter The user calls this routine to reset the m_timeLineArr iterator void printLog char The user calls this routine to print out the contents of the log Internals Error addToEventArr cl LogEvent amp Add this event to the m logEventArr This function adjusts the size of the array if necessary int getTimeLineIndex char char char int This function is called by the constructor to either create a new cl_TimeLine object if appropriate or retu
38. ummies as interrupted arrows 21 22 cl StringTokenizer This class takes a string and breaks it up into a seguence of tokens The cl_LogFile constructor has a local cl_StringTokenizer object which it uses to parse the log file Interface StringTokenizer char str char 0 char 0 The constructor takes three arguments the string to be tokenized the string of delimiters and the string of delimiters which are to be returned during parsing int countTokens The number of tokens in the string int hasMoreTokens Returns 1 if the class has more tokens 0 otherwise char nextElement char 0 Returns a pointer to the next element char restOfString Returns the rest of the string Internals char m Delims This string contains all the delimiters Delimiters are characters that cannot be members of tokens char m_RtrnDelims This string contains all the delimiters that are to be returned when encountered on calls to nextElement char m_Str The string under analysis int m StrLen The length of m Str int m_StrOffset Our current position in m_Str a 0 based index int inDelims char Returns 1 if the char parameter is in the m Delims string 0 otherwise int inRtrnDelims char Returns if the char parameter is in the m_RtrnDelims string 23 cl LineFileStream This class inherits from ifstream adding the method getLine for reading a file line by line Interface cl LineFileStre
Download Pdf Manuals
Related Search
Related Contents
Calibratore di loop Druck UPS-III MX Component Version 3 Operating Manual Whynter BH-2000 User's Manual Braun MULTIQUICK 3 MR 4050 CA User's Manual e Instructions f Mode d`emploi S Instrucciones - Fisher Manual - Extech Instruments Manuale di servizio GH6 Service manual GH6 Conservare per sp a - Les nouvelles esthétiques Canada MC40 Regulatory Guide [Japanese] (P/N 72-166942 T'nB USB2AMBM03 Copyright © All rights reserved.