Please use this identifier to cite or link to this item:
|Title:||A Design for Framework-Independent Model Components of Biophysical Systems|
|Authors:||DONATELLI Marcello; RIZZOLI Andrea|
|Citation:||Proceedings of the iEMSs 2008: International Congress on Environmental Modelling and Software - Integrating Sciences and Information Technology for Environmental Assessment and Decision Making p. 727-734|
|Publisher:||International Environmemntal Modelling and Software Society|
|Type:||Articles in periodicals and books|
|Abstract:||Development in the design of software frameworks for biophysical systems simulation has focused mainly on the compromise between domain specificity and use flexibility. Models in such frameworks have been traditionally categorized either as framework-specific, or as ¿legacy¿ code. In the former case, models implemented as software components can take full advantage of the framework services and they depend on the framework. In the latter case, components are seen as discrete units of software, in general of coarse granularity in modeling terms, and the dependency on the framework is minimal, but the use is limited to the algorithms implemented. Thus, modellers who want to use a modelling framework are faced with two choices: if the framework is extensible, implement a framework specific component (i.e. not reusable outside the specific framework); the alternative is to provide a component as a black-box, taking little or no advantage of the framework itself. The objectives of this paper are: 1) to present a software design of non-framework specific components, and 2) introduce real-world sample applications of the concept. The re-usability of software components can be enhanced by addressing the following requirements: 1. The component must target the solution of a sufficiently widespread modeling problem; 2. The published interface of the component must be well documented and it must be consistent, 3. The configuration of the component should not require excessive pre-existing knowledge and help should be provided in the definition of the model parameters 4. the model implemented in the component should be extensible by third parties, 5. The dependencies on other components should be limited and explicit, 6. The behavior of the component should be robust, and degrade gracefully, raising appropriate exceptions, 7. The component behavior should be traceable and such a trace should be scaleable (browsable at different debug levels), and 8. The component software implementation should be made using technologies with a widespread adoption. There are a number of solutions to address these requirements and we present the choices made for the design we have used in some components we have developed.|
|JRC Directorate:||Space, Security and Migration|
Files in This Item:
There are no files associated with this item.
Items in repository are protected by copyright, with all rights reserved, unless otherwise indicated.