Iteration 5

• Phase: Construction
• Dates: Dec. 4 - Dec. 22, 2004

Tasks to be Completed

+ Core Modules

• Finish designing & documenting the interface for the Species module, and then write the code for it.
• Design and code the supporting utility modules that read input values from text files.
• Continue working w/Barry on integrating GeoSpatial Data Abstraction Library (GDAL) into L-II to implement the Raster I/O module.

+ Extension Components

• Finish writing the code for the wind module. The wind module is approximately 70% complete.
• Begin designing and documenting the Age-only and Biomass succession components.
• Begin designing the output extensions (Barry DeZonia).

+ Documentation

• Continue to produce documentation as necessary and update existing documents. In particular, work will continue on the Use Cases, which are now 60% completed. Feedback will be requested from Team Members.
• Add extensive commenting to the wind module. We have decided to publish a well-documented wind module on the Developers tab in lieu of a generic disturbance module.

Assessment

Overview: Iteration 5 was a lot of heavy coding, particularly the wind extension and the utility modules for text input. Some documentation was produced, namely a major revision of the use cases.

+ Hits and Misses:

Hit/Miss The design of Species Module is complete, but the code is not finished. The design was more complex than anticipated because of the need for two different interfaces for the module (see the section Lessons Learned below).

Hit/Miss The utility modules for input text files are only 90% completed. The major reason for not completing this code was the addition of unit tests. The original C++ code for the modules had no test code; as it was translated to C#, unit tests were created to ensure the new code was functioning correctly.

Hit/Miss A C# module that wraps the GDAL DLL was designed and coded; testing is currently underway. The next step in integrating GDAL into L-II is to use this C# interface to GDAL to implement the L-II Raster I/O module. However, progress on this step was stalled because Barry had problems with the C# programming tools (the tools were crashing).

Hit The wind extension coding has been completed.

Hit How extensions add site variables to the landscape has been significantly simplified. Nicer cleaner code!

Miss Wind extension is not commented enough for publication.

Hit The design of the Age-Only Succession extension was started. All the docs are completed. Given our experience with the wind extension, we've decided to complete the code for the Age-Only Succession extension before starting work on the Biomass Succession extension.

Hit/Miss The design of output modules was started but not completed because some of Barry's time was spent on the problems with the C# programming tools.

Hit A diagram of different levels of system scope was developed and added to the use-case document. This diagram initiated a major revision of the use cases themselves to better represent how users will interact with the Landis-II software independent of the type of user interface (console vs GUI).

+ Lessons Learned:

• C# does not have explicit memory management as does C++. Therefore, we do not need to adjust our designs to improve memory usage; we are dependent on .NET framework's memory management. Given the large memory requirements of Landis-II, it'll be very beneficial to measure the actual resource usage of our working code to see how efficiently our needs are being met by the .NET framework.
• Work on the wind extension revealed that we may need to track individual data per inactive site at some future time. In other words, a developer may want to store temporary values for inactive sites; the most likely example is the spatial extent for a disturbance event. This option for site variables has been designed, but is not currently implemented.
• Work on the Species module and the wind extension revealed that a group of parameters has two interfaces. The first, most obvious, interface is how an extension uses the parameter group (for example, how the wind extension uses species parameters). The second interface includes code to validate parameter values entered by the user. If this second interface is well-designed, it can be shared by the code that reads parameters from a text file, and by the GUI. Such a design will allow more rapid implementation of the GUI.