ISVis Adaptation Study Report Peterdocisvis适应研究报告peterdoc.doc

ISVis Adaptation Study Individual Report Peter CalvertIntroductionISVis 1 is a piece of software written in C+ that visually displays execution scenarios for an instrumented program to aid in analysis. However, ISVis was created around ten years ago and since then various changes to the C+ standard as well as external libraries meant that ISVis no longer compiled. The main objective of this project was to make the necessary changes to ensure that ISVis could be compiled again on the SunOS system “lennon”. A secondary object was to improve the portability of ISVis such that it would compile on other systems as well. ContributionThe main task that I was responsible for was the updating the persistence element of ISVis. After analysis it was decided to remove the dependency of the Rogue Wave 2 library and replace it with standard C+ library code and standard template library (STL) classes.Below is a list of the number of changes made to each file within ISVis when removing the Rogue Wave dependency. These values were obtained using diffstat 3 and CVS. File# changes actor.C 323 actor.H 238 actor_list_view.C 937 actor_list_view.H 50 disk_file.C 75 disk_file.H 52 event.C 8 event.H 14 event_reader.C 4 event_reader.H 11 event_writer.C 14 hash.C 6 hash.H 12 instrumentor.C 8 instrumentor.H 4 interaction.C 116 interaction.H 79 io_shell.C 14 io_shell.H 10 main_view.C 79 main_view.H 4 mural.C 20 mural.H 4 program_model.C 1069 program_model.H 109 scenario.C 403 scenario.H 171 scenario_view.C 738 scenario_view.H 23 static_analyzer.C 289 static_analyzer.H 51 static_info.C 6 static_info.H 24 trace.C 75 trace.H 60 trace_analyzer.C 72 trace_analyzer.H 27 view.C 4 view.H 12 view_manager.C 183 view_manager.H 26 xapp.C 41 xapp.H 13 43 files changed, 2974 insertions(+), 2514 deletions(-)Further to this hash.C and hash.H were removed from the program as they were no longer required. Also, ISVisCollectable.C and ISVisCollectable.H were added. It is clear that the changes required to remove Rogue Wave were extensive. Regarding the group report I added 269 lines of textWith regards to time, below is a summary of where time was spent based on the information in my time log 4.TaskTime (hours)Persistence121Measurement/Metrics8CVS9.5Finding/Reading papers27Other tasks 1Total166.5This does not take into account meeting time and helping other team members, where several hours have been spent attempting to find a solution to produce instrumented files for ISVis to use as it appeared that sbdump was no longer available. Also time as spent giving advice on how to fix compilation warning that appeared. Time was also spent debugging ISVis to try and get the program to actually run now that it has been built.Current statusThere has been a great deal of progress in updating ISVis; however, there still remain some outstanding issues. When first inspecting the changes needed for ISVis to work it was decided that removing all aspects of Rogue Wave was the best solution as it was an old library and the version that was used was no longer available on lennon. Also it appeared that this library was only available on SunOS machines and therefore if the library continued to be used then it would limit the portability of ISVis. The proposed solution was to replace all the Rogue Wave code with C+ STL equivalents. There were three main areas where changes were required.1) Strings2) Container classes3) PersistenceWhilst there were a large amount of changes required for 1) and 2) most of the changes were simple to make and the only issue was the number involved. However, the changes required for persistence were more complex and have proved to be a challenge.The problemThe main issue with changing the ISVis code for persistence is the solution that is required does not tie in with the current ISVis design and as such would require a large amount of changes to incorporate it. Also because of the complex relationship amongst different ISVis objects it is difficult to ensure that all the objects and the links between the objects will be preserved correctly.SolutionThere are two possible solutions for implementing persistence within ISVis.1) Complete the changes to use just C+ based on the design described at /c+-faq-lite/serialization.html#faq-36.11. This defines how to serialize objects that have complex relationships such as those of the Actor classes in ISVis. The main issue here is implementing a two-pass algorithm as this does not fit the current design of the serialization in ISVis.2) Use a different library to perform the serialization of ISVis objects. This would make the implementation easier, but it would mean relying on a third party library. The best library to use would be the serialization in the Boost library (/libs/serialization/doc/index.html), as this would still be portable to most platforms, but it would mean that the Boost library would have to be installed on any machine that ISVis was compile on, and Boost is a large library. Another alternative would be to use libs11n (/), which is a library specifically for serialization. It offers similar functionality to the Boost serialization library, but is a lot smaller library. The drawback is that it may not work using compilers other than gcc.Overall it comes down to a choice of either trying to implement serialization solely using C+, which is a lot more work and may cause more problems, or using an external library, which would be easier to implement, however, one of the main reasons for removing Rogue Wave was to remove the dependency, and this would add a dependency again.Other IssuesCurrently, whilst ISVis will compile and start it immediately crashes on startup. Debugging the problem seems to indicate a problem in the X Windows call to allocation colours from the global palette (call to XAllocColorPlanes). It seems that not a single colour can be allocated from the global colour palette. This suggests that this is a more fundamental X Windows issue, however, this is just intuition and there is no solid proof that this is the case.Also as the program has not been run there is no way to be sure that the changes that have been made are correct and preserve the functionality that was present in ISVis.Issues RaisedThe main issue with this project has been the lack of documentation for ISVis has led to difficulties in understanding the complexity of ISVis. Furthermore, not having a version of the code that compiles meant it was difficult to understand the complete functionality of the program. This meant that it was difficult to estimate the amount of effort it would take to make the changes to ISVis so that it would compile.For the most part all members of the group would work independently and would only really present their findings during weekly meetings. It would have been better if there was more collaboration amongst team members. It may have been useful to two or more people share each task so that more of us got a better understanding of more aspects of ISVis as well as learning more. Another advantage of this would have been to distribute the work more evenly as each of the main tasks required a vastly different amount of effort. Whilst there was a project plan created at the beginning of the project, it was not mentioned following this. By tracking the project plan more closely we may have been able to allocate resources more effectively and therefore achieved more of our objectives. I believe more time should have been spent upfront ensuring that we all had a thorough understanding of what was required and more insight into what was required. This may have avoided the potential showstopper of not being able to find sbdump appearing until late in the project. There was possibly too much emphasis placed on making ISVis compile with the Sun CC, particularly as the version that is on lennon is still five years out of date, and if we were planning on making this portable and up to date we should have concentrated more on the g+ compiler which is both newer and is available on a lot more platforms and would be a better choice for future proofing the program, so hopefully this same issue does not arise again in a few more years.Lessons LearnedOverall, this project has been a good learning experience when dealing with updating old projects. This is always a difficult area as was demonstrated in some of paper that we had read. As with all projects there are some positives and some negatives. First the positives. Significant progress was made towards updating ISVis, there is now a version of ISVis that will compile, whilst there are still issues with the persistence side and actually running ISVis a large portion of the changes required have been made. The fact that ISVis will compile on both SunOS and Linux is a large step towards portability. A more significant step would be to compile on Windows, but that would require more effort.Furthermore, reading papers that were directly or indirectly related to this project help everyone get a better feel for ways to proceed with a project like this. Also, whilst I have used Eclipse for several Java projects previously I have found there to much more useful functionality that helped to improve my productivity and I shall consider using Eclipse again for future C+ projects. CVS was also a very valuable asset for this project as is some form of source control for any project particularly of there are several developers contributing as it eases the combining of different code branches greatly. Another vital feature is the logging which allows the changes that are made to be captured clearly and was useful for me in finding exactly how many changes were made.As for the negatives, the main issue for me is that I was not able to complete the changes to enable persistence to work. There are several reasons for this, but it is mainly because I underestimated the amount of work required. This was in part due to the lack of documentation for ISVis which meant I did not realize how complex it actually was, and as ISVis could not be run it was difficult to see understand all the functionality by just viewing the code. But this is something I will bear in mind when estimating the effort required for future projects. Further to this, I believe I may have become too single-minded in trying to remove dependencies from ISVis when deciding to