|
|
|
|
Hierarchical Modular SystemModular program design and model construction has received considerable attention from software engineers {Timlin, 1996 #1981}. The importance of modularity comes only partially from the ability to decompose complex systems into manageable parts, more important is the advantage that modularity has of isolating the information needed to construct a module from other modules. Hodges et al., (1992) {Reynolds, 1989 #1837}described a modular structure for the International Benchmark Sites for Agrotechnology Transfer (IBSNAT) models that enhances the ability to modify the model for new applications or improvements. A modular structure can be developed following accepted guidelines for modular software design or object orientated (OOP) paradigms. Wimovac is coded as a series of inter-linked model objects which represent real World processes. These objects are coded as procedural modules with tightly defined internal and external properties expressed in the form of driving, auxiliary and output variables. Each code module consists of one or more subroutines relating to individual sub-processes within an object. The subroutines therefore represent the mechanisms of the object. The "scope" and "visibility" of variables in wimovac model objects are set to reflect the hierarchical structure of the model and the information flows expressed within the model. Detailed leaf biochemical properties for example are stored in internal leaf variables that have a scope and visibility that is restricted to the leaf only. These properties are not visible and cannot be used or modified outside of the leaf level. Careful attention to the scope and visibility of program variables and therefore informational flows in a model is paramount to maintaining the integrity of a complex model. Where informational flows between hierarchical levels are required in wimovac, global scope variables are used. These are visible at all model levels and whilst this is not ideal because the scope of the variables does not adequately reflect the informational flows of the model it is the only practicable approach and does not affect the functionality of the program. Whilst it is programmatically possible to modify the visibility of variables by declaring them all locally and preferentially passing local variable values to the specific subroutines that require them as part of the subroutine or function definition this approach is both time consuming and difficult to administer in large projects with many subroutines. This approach would also be a step further away from the concept of clearly defined objects with identifiable properties at the program code level. Property based object linked data structures have been established in wimovac which provide an identifiable structure for global scope variables. The object/property orientated concept of constructing a model programmatically is very important in determining the re-usability of an object within a model
Hierarchical scaling of model objects indicating treatment of auxiliary, driving and output variables. A scheme of internal and external object properties can be readily overlaid onto the driving, auxiliary and output variables used with traditional relational diagrams. |
Send mail to humph@essex.ac.uk with questions or comments about this web site.
|
