CSC302 Winter ’09

jfreechartTeam 2: IFHUML

Status: Completed

Period: Winter 2009

Project Members: Edward Chau, Maciej Kozlowski, James Ma, Victoria Mui, Jacky Seto

Description: Implement various change requests and feature requests for the open source charting application JFreeChart

CSC302 : Engineering Large Software Systems is a course  taught by Professor Steve Easterbrook here at UofT. CSC302 is:

An introduction to the theory and practice of large-scale software system design, development, and deployment. Project management; advanced UML; reverse engineering; requirements inspection; verification and validation; software architecture; performance modeling and analysis.

For the duration of the semester, students work in teams of 6 (+/- 1) members to analyze JFreeChart and ultimately develop change and feature requests for the project.  Throughout the semester, we were given 4 assignments to help us accomplish these goals.

Assignment 1: Reverse Engineering & Design recovery

Details can be found in my previous post here.

To do the UML diagrams and analysis, our team used a mixture of round-trip UML tools like Altova, NetBeans UML, and Visual Paradigm.   These tools ran into the problem of either giving us too much information, or not being able to infer abstract structures in the API.  As such, manual editing and code-reading was required to perform a higher-level analysis.

An enormous amount of code reading was required to discover the minimum of three design patterns within the library.  Thankfully, all of our members came out of CSC301 with a clear understanding of design patterns.  It didn’t hurt to have this book on hand either.

Assignment 2: Implementing Change Requests

Details about the work that I did can be found in my previous post here.

The difficulty with this iteration of the project was selecting which change request to select.  Because of the limited time (2 weeks), we were forced to balance time vs difficulty.  Fixing trivial change requests would require very little time, but would award us very few marks.  On the other hand, fixing extremely difficult change requests would award us more marks but they require time and resources that we did not have.

Our team was able to select two change requests that we deemed to be both non-trivial and fixable within the allotted amount of time.  Using the pair-programming paradigm, we were able to implement our changes quickly and efficiently.  While the fix was being implemented, I began working on the test rig that would allow us to properly test the proposed features.

Assignment 3 & 4: Requirements Analysis for New Features, Implementation

Assignment 3 and 4 was given to us with the ultimate goal of selecting and implementing a single feature request for the JFreeChart project.  After much consideration, our team decided to select the the following feature request:

Currently, to plot a mathematical function you need to first sample it to create a dataset and then plot that (See for example XY Charts, Function2DDemo1.java in the Demo collection). As suggested in the demo, a better way to do this would be to create a new renderer to plot mathematical functions directly by passing in an object that contains the function and the input ranges to plot. The renderer should do the necessary sampling and make intelligent decisions about how to plot it.

As a part of A3, our team performed a requirements analysis, generated a set of possible use cases, and completed a set of robustness diagrams for our selected.  We had to do a lot of legwork to before we could even hit the keyboard and fire up an IDE.

Once A4 came around, it was up to us to use the work that we did in A3 to implement the feature in A4.  From past experience, we knew that the division of labour that we set out in A2 worked very well, so we re-used the same setup.  Victoria and Maciej were on coding duty, I did QA/coding, Edward helped with testing and the write-up, and Jacky was in charge of the full writeup.

Our first task was to select a third-party library (preferably open-source) that could help us parse and evaluate functions.  Although we all had a very good idea on what it takes to do write such an algorithm, our limited time constraints required that we look for a well tested, and well used library to help us do the work.  Looking through the Sourceforge repositories, we looked at the following libraries:

After some discussion, our team decided on JEP.  It had an extensive library full of features, had great documentation, and is still being actively developed and maintained.

Implementation of the feature was made significantly easier with the help of the JEP parser.  We extended the org.jfree.data.function package to include our new classes: FunctionDatasetGenerator and Function2DDatasetGenerator.  Using Function2DDatasetGenerator, users will be able to pass in a function as a String and get back a compatible XYSeriesCollection object which can be graphed by JFreeChart.  Users have the ability to manually change the upper and lower bounds of where the function is graphed, and also the sampling interval to increase the graph’s resolution.

Another portion of the assignment required that we create a well rounded test suite of the feature that we implemented.  Our team decided to attack this problem using a combination of white-box and black-box testing.

White-box testing was done using a combination of code-review sessions and JUnit tests.  Informal code-reviews were almost always completed within 24 hours of a commit into the repository.  We allowed up to 48 hours for discussion and implementation of the necessary fixes.  We were able to catch approximately 18 genuine using this method.

JUnit tests were also written in hopes of attaining 100% code test coverage.  Using the ECL Emma coverage plug-in tool for Eclipse, we were able to attain 81.1% coverage on the Function2DDatasetGenerator class, and 93.5% on the FunctionDatasetGenerator class.  Using our JUnit test suite, we were able to uncover 15 defects, the majority of which were algorithmic in nature.  It also served as a good tool for regression testing each revision of the codebase as the coders checked-in more code.

Finally, in order round out the testing suite, we created a black-box testing rig similar to the ones generated for Assignment 2.  However, due to the increased complexity of this change request, we completely re-wrote the rig from the ground-up to accommodate our needs.

a4-autotester

As you can see, the tester has the familiar side-panel controls where the tester can adjust various parameters such as: window dimensions, function to be graphed, upper/lower X bounds, and sampling interval.  The tester also has the option of loading a test script file that will automatically generate pre-recorded graphs for regression testing.  The tester can then accept or reject graphs by performing visual inspections on them.

2 Trackbacks