This document proposes conceptual microarchitectures for hydrologic simulation models to address issues like a lack of flexibility in configuring simulation scenarios and integrating models with environmental information systems. It discusses how hydrologic models work and the different types of parameters and methods used. Conceptual microarchitectures are defined based on a general conceptual architecture for environmental information systems to provide flexibility in the conceptual and design models for hydrologic modeling software. This will help maintain knowledge about simulation strategies and parameters collected by environmental organizations.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online from Scribd
Conceptual Microarchitectures For Hydrologic Simulation Models
This document proposes conceptual microarchitectures for hydrologic simulation models to address issues like a lack of flexibility in configuring simulation scenarios and integrating models with environmental information systems. It discusses how hydrologic models work and the different types of parameters and methods used. Conceptual microarchitectures are defined based on a general conceptual architecture for environmental information systems to provide flexibility in the conceptual and design models for hydrologic modeling software. This will help maintain knowledge about simulation strategies and parameters collected by environmental organizations.
This document proposes conceptual microarchitectures for hydrologic simulation models to address issues like a lack of flexibility in configuring simulation scenarios and integrating models with environmental information systems. It discusses how hydrologic models work and the different types of parameters and methods used. Conceptual microarchitectures are defined based on a general conceptual architecture for environmental information systems to provide flexibility in the conceptual and design models for hydrologic modeling software. This will help maintain knowledge about simulation strategies and parameters collected by environmental organizations.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online from Scribd
Download as pdf or txt
0 ratings0% found this document useful (0 votes)
16 views18 pages
Conceptual Microarchitectures For Hydrologic Simulation Models
This document proposes conceptual microarchitectures for hydrologic simulation models to address issues like a lack of flexibility in configuring simulation scenarios and integrating models with environmental information systems. It discusses how hydrologic models work and the different types of parameters and methods used. Conceptual microarchitectures are defined based on a general conceptual architecture for environmental information systems to provide flexibility in the conceptual and design models for hydrologic modeling software. This will help maintain knowledge about simulation strategies and parameters collected by environmental organizations.
Copyright:
Attribution Non-Commercial (BY-NC)
Available Formats
Download as PDF, TXT or read online from Scribd
Download as pdf or txt
You are on page 1of 18
1
Conceptual Microarchitectures for Hydrologic
Simulation Models Urciuolo Adriana Universidad Nacional de la Patagonia San Juan Bosco Darwin esq. Canga- 9410 Ushuaia, Argentina, 54-2901-443533 urciuolotdIuego.com Iturraspe Rodolfo Universidad Nacional de la Patagonia San Juan Bosco Darwin esq. Canga -9410 Ushuaia, Argentina, 54-2901-432217 iturraspetdIuego.com Parsn Ariel Universidad Nacional de la Patagonia San Juan Bosco Darwin esq. Canga, 9410 Ushuaia, Argentina, 54-2901-430892 a-parsoninIovia.com.ar ABSTRACT Mathematical Hydrologic models simulate real world environmental processes through diIIerent strategies. Each process is calculated by means oI methods that utilize physical parameters Ior representing the real world system. Some parameters are obtained Irom tables, some oI them are optimized and others may be calculated using environmental variables. Although the domain soItware provides a wide range oI models, there is not a conceptual architecture that allows the maintenance oI the vast knowledge about simulation strategies and parameters collected in environmental management organizations, Iacilitating the Ilexible simulation scenarios conIiguration. The present work shows how to Iace this problem by means oI conceptual analysis models organized in the scope oI a general architecture. It`s also possible Ior the given architecture, to analyze and deIine microarchitectures Ior soItware components related to particular problems. In the present work, conceptual microarchitectures are deIined to construct a knowledge level Ior hydrologic models systems starting Irom a general conceptual Environmental InIormation Systems architecture. To get the required Ilexibility Ior the conceptual and design models, high-level components are identiIied and diIIerent kinds oI patterns are applied. Keywords: Architecture, analysis patterns, simulation models, parameter. 1. INTRODUCTION In the last years, great advances have been made in techniques Ior exploring the hydrologic environment, such as remote sensing, radar and others. Due to limitations oI these techniques, there is only a limited range oI measurements in space and time, which is normally stored in environmental organizations. ThereIore, models oI diIIerent types provide a means oI quantitative extrapolation or prediction Irom the available measurements in space and time |6|. Models generally make assumptions about real world CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 2 processes in order to predict the behavior oI systems under certain conditions to assess the likely impact oI Iuture hydrological change. The ultimate aim oI predicting using models is to improve decision-making about some hydrological problems in Water Resource Management, such as water resource planning, Ilood prediction, determination oI risk areas, mitigation oI contamination and so on. Modeling has existed Ior at least one hundred and IiIty (150) years. It is based on the idea oI conservation oI mass, momentum and energy. The governing equations Ior environmental models resulted Irom experimentation. A hydrological model is a simpliIied representation oI the real world system which aim is to study the system operation and predicting its outIlow. Model inputs and outputs are hydrologic and climatic variables such as water Ilow, precipitation, temperature, evaporation and others. The model structure is a set oI mathematical equations connecting inputs with outputs |11|. F(t) I(t) svstem transformation equation As it was said, hydrological models serve a range oI purposes but they are used primarily to estimate runoII Irom sequences oI rainIall and the meteorological inIormation needed to estimate potential evaporation. They can be used to estimate river Ilows at ungauged sites, Iill gaps in broken records or extend Ilow records with respect to longer records oI rainIall. Generally, the relationship between rainIall and runoII is a central problem in hydrology. According to this criteria, models can be classiIied in empirical, conceptual or physically-based. Mathematical modeling oI this relationship is oIten based on a black box type oI model with less regard to the physics oI the process. This is partly due to the complexity oI the process and data availability. However there is a continuing interest among hydrologists to develop rainIall-runoII models with a theoretical structure based on physical laws. PowerIul areally-distributed models are based on physical principles governing the movement oI water within a catchment area, but they need detailed high-quality data to be used eIIectively. More commonly, simpler conceptual models are used to represent the basin as a whole. The main controls on water movement are represented by quasi-physical model elements whose action is governed by a set oI model parameters. In some circumstances, these parameters can be adjusted to represent changes to land-use in the catchment area. Computational models present a clear evolution process, due to the computational advances to which they were adapting. It`s common, when tracing the development oI models to distinguish Iive generations |1|, but hydrologic simulation models as soItware products Ior decision-making arose in the Iourth- generation, with some new requirements such as Iriendly job environments, use oI models by non domain experts, etc., giving place to the creation oI a new paradigm called hydroinIormatics |1| Despite its evolution, there are some critic questions to Iace in the soItware domain, related with the lack oI a conceptual Iramework Ior Modeling in Water Resource Management. There are many diIIerent types oI hydrologic models, considering the simulation strategies and methods used Ior Ilow computing, but they are oIten isolated Irom the Environmental systems, which provide basic services and inIormation to them. The complex models used Ior hydrologic studies require extensive parameter input which decreases model accuracy. Sometimes it`s a serious restriction Ior their use. On the other hand, modeling soItware usually is based over a static design model, which doesn`t allow dynamically changing methods or parameters iI they are not available or iI they are not the appropriate Ior the real system simulation. In summary, there is not a domain soItware architecture that Iacilitates the maintenance oI the hydrological Operator I(t) F(t) CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 3 processes simulation methods and parameters knowledge Ior the Ilexible conIiguration oI simulations scenarios and the integration oI models to Environmental InIormation Systems. High-level domain speciIic soItware analysis appears as a possible solution Ior such topics. The problem may be characterized as Iollows: There is a great diversity oI methods Ior each hydrological process simulation by means oI diIIerent strategies (black box, conceptual and physically based models). There are diIIerent parameters Ior each type oI hydrological structural component (lake, river, soil, etc.), each simulated process and selected method used by models. Some parameters can be obtained Irom tables, some oI them can be calculated Irom environmental variables and others are obtained using optimization methods. Environmental management organizations collect important knowledge through the years about parameters that better Iit the real systems conditions Ior a given region. Simulation methods and parameters may use the data Irom existing Environmental InIormation Systems Ior Ilow computing, but models are oIten acquired and used isolated Irom other systems. The domain has been traditionally characterized by the study oI eIIicient Ilow computing algorithms, but not oI high-level solutions Ior the exposed questions. In the present work, it is proposed to introduce Ilexible soItware developing mechanisms, such as architecture, patterns and components in the construction oI speciIic domain soItware. SoItware architecture deals with the design and implementation oI the high-level structure oI the soItware |5|. Architectural descriptions are being recognized as an appropriate vehicle Ior codiIication and reuse oI design knowledge. SoItware domain speciIic architectures provide an organizational structure Ior a Iamily oI applications, that allow to organize their development and sustain their evolution and reuse. By other hand, Ior a given architecture style, it`s possible to deIine a set oI conceptual, design and architectural patterns, which act as 'microarchitectures |21|. They constitute appropriate techniques to solve particular problems, such as those exposed above. Patterns are used in soItware engineering to allow the reuse oI solutions that have been prove to be successIul in the diIIerent soItware process stages. There are diIIerent types oI patterns, which may be classiIied by many points oI view, such as: abstraction level, scale ranges, dependency on a speciIic particular domain and soItware process stage |22|. This article provides conceptual microarchitectures Ior Ilexible hydrologic modeling soItware on the basis oI a general conceptual architecture that Iacilitates simulation models integration to Environmental InIormation Systems. The remainder oI this paper is organized as Iollows. Section 2 reviews soItware techniques Ior Ilexible soItware development. Section 3 presents the conceptual analysis process. Section 4 includes the proposed design models Ior Ilexible simulation scenarios conIiguration. Section 5 shows an example use case oI the models. Section 6 is related with acknowledgements and section 7 presents conclusions and Iuture works. 2. FLEXIBLE SOFTWARE: PATTERNS, ARCHITECTURE AND COMPONENTS. Architecture has emerged as a crucial part oI the design process. Larry Bass |5| deIines soItware architecture as: 'The soItware architecture oI a program or computing system is the structure or structures oI the system, which comprise soItware components, the externally visible properties oI those components, and the relationships among them. From the above deIinition, it is inIerred that when proposing speciIic domain soItware architectures, some inIormation is abstracted to concentrate in relations and high-level structures, providing enough inIormation to constitute the basis Ior analysis. CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 4 It`s possible to use diIIerent architectural views to enhance the understandability oI the architecture and to Iocus on particular concerns separately. Some studies |20| propose the Iollowing three views: conceptual, logical and execution view. The Conceptual Architecture identiIies the high-level components oI the system, and the relationships among them |4|. Its purpose is to direct attention at an appropriate decomposition oI the system without delving into details. It consists oI the Architecture Diagram (without interIace detail) and an inIormal component speciIication Ior each one. In Logical Architecture, the externally visible properties oI the components are made precise and unambiguous through well-deIined interIaces and component speciIications, and key architectural mechanisms are detailed. Execution Architecture is created Ior distributed or concurrent systems. The process view shows the mapping oI components onto the processes oI the physical system. In the present work the emphasis is put on the conceptual architecture analysis. DeIining this basic initial structure, then it`s possible to develop microarchitectures Ior soItware components related with speciIic domain problems. This architecture may be reIined in successive iterations oI the soItware process. As it was said, Iundamental to conceptual soItware architecture is the structure oI the system in terms oI the primary structural elements or components of the svstem, and their interrelationships. The use oI components allows identiIying independent units |23| Ior new appropriate solutions, as well as the reuse oI existing solutions. Patterns have been used in diIIerent domains to deIine microarchitectures Ior particular problems. An architectural pattern |10| expresses a Iundamental structural organization or schema Ior soItware systems. It provides a set oI predeIined subsystems, speciIies their responsibilities, and includes rules and guidelines Ior organizing the relationships between them |3|. A conceptual (or analvsis) pattern is a pattern whose Iorm is described by means oI terms and concepts Irom an application domain. Analysis patterns were proposed by Fowler |13| to make possible the reuse oI conceptual modeling solutions. This term is utilized Ior patterns used to describe solutions Ior problems that appear during the requirement and conceptual modeling stage. These patterns Iacilitate the transIormation Irom analysis to design model. A design pattern describes commonly recurring structure oI communicating components that solves a general design problem within a particular context. A design pattern can be deIined as a common solution to recurring problems in soItware design |15|. Provides a scheme Ior reIining the subsystems or components oI a soItware system, or the relationships between them. Although there are Iew antecedents oI patterns application in hydroinIormatics systems |2| |24| |25|, they are important Ior the study oI speciIic environmental domain architectures, as it can be seen in recent researches related with Geographic InIormation Systems |19| |16|. 3. CONCEPTUAL ANALYSIS 3.1 Methodology The methodology Ior the early stages oI soItware development is based on the RUP (Rational UniIied Process) Process Development |8|, considering its basic Ieatures: case use driven, architecture centric, iterative and incremental. First it is deIined the general conceptual architecture to be used as a Iramework Ior hydrologic models soItware development. It is used an existing conceptual architecture Ior Hydrological Modeling integrated to Environmental InIormation Systems. It was developed on the basis oI a Physical Water Resource Domain Model, which was used Ior the domain objects and analysis classes identiIication |7| |24|. CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 5 This architecture primarily supports the Iunctional requirements stated Ior Environmental InIormation Systems. UML |9| is used Ior the architectural representation, by means oI packages and class diagrams. Packages are used as layers, subsystems and high-level components. Conceptual microarchitectures are used as a vehicle Irom analysis to design. This way it`s possible to bring solutions Ior speciIic design problems beginning Irom the study oI high-level structures. They are developed on the Iollowing basis: The existing domain model and analysis classes deIined Ior Water Resources Information Svstems (WIRS) |24| |25|. A Ieature list and an example use case, which are used as drivers Ior the diagrams construction. The identiIication oI the main hydrological processes corresponding to each hydrologic object. The study oI the common simulation methods and parameters used by hydrologic models. Conceptual analysis is made applying analysis patterns |13| |14|. 3.2 Conceptual General Architecture The general architecture shown in Figure 1 is used as a scheme Ior the integration oI Hydrologic simulation models to Environmental InIormation Systems. The architecture is primarily based on the architectural pattern Layers. The application general laver is called: 'Environmental InIormation Layer |17|. In this layer environmental subsystems like: Water Resource, Soil, Climate, Vegetation are interconnected via interIaces. The application specific laver: 'Simulation Layer includes subsystems reIerred to diIIerent simulation models that use the data and services Irom the Environmental Layer subsystems. In the middleware laver: 'Geographic Representation Layer, there is a conceptual Iramework Ior SIG which is called GeoFrame|18|. Subsystems in the application layers can specialize classes and relationships in the Iramework Ior the hydrological components geographic representation. The system- soItware layer is not shown in the diagram. FIGURE 1. Conceptual Architecture Ior Environmental InIormation Systems layer~~ Simulation layer~~ Geographic Representation layer~~ Environmental InIormation Models simulating real world Interconected Environmental Subsystems Conceptual Framework GeoFrame CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 6 Lower Layers (middleware and system-soItware level) are general to several applications. As it was said, the Environmental InIormation Layer contains diIIerent environmental systems: Soil, Water Resources, Climate, Terrain Ecology, Land Use, etc. The general architecture Ior this layer is based on the architectural pattern 'System oI interconnected systems |12|. These types oI systems are divided into several separate parts, each developed independently as a separate system, as it can be seen in Figure 2. A super system is implemented by a set oI interconnected systems, communicating each other through interIaces owned by the super system. One oI these systems represents the overall capabilities, and it is called the superordinate system. The other systems represent a part oI the whole, and they are called subordinate systems. The Geographic Representation layer contains a conceptual Framework GeoFrame |18|, which is specialized in the EI Layer Ior the environmental objects representation in some convenient system. 3.3 Simulation Layer Conceptual modeling Requirements It`s possible now, to identiIy the main components oI the Simulation layer analyzing their interactions and deIining the required conceptual models. When using an iterative process, it is recommended to keep the initial ideas about the system in a Ieature list, which is used as a starting point Ior the candidate requirements identiIication |4| and the initial system architecture deIinition. Following this approach, the conceptual model requirements Ior the Simulation Layer are the Iollowing: It must bring Iacilities Ior diIIerent hydrological phenomena simulation, maintaining the knowledge about simulation strategies (methods Ior hydrological processes calculation). It must allow the parametric inIormation maintenance either Ior those parameters obtained Irom existing tables or generated through calculations. It must be possible to use environmental data and services Irom the EIS layer. Simulation scenarios conIiguration must be Ilexible. Considering the candidate requirements derived Irom the Ieature list as system use cases, in the present work it is used the system use-case: 'Calculating the runoII process in a catchment using a desired Ilow computing method as an example oI a speciIic requirement Ior the conceptual architecture development. subsystem~~ Terrain Ecology subsystem~~ Water Resources subsystem~~ Climate EIS Layer TEI WRI CI FIGURE 2. Interconected subsystems Ior Environmental Layer CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 7 3.4 Hydrologic Models Knowledge Analysis Hydrologic models represent the nature oI the system through mathematical equations which are solved in computational way |11|. Mathematical models represent the physical hydrological processes in diIIerent ways. Process models can be classiIied as empirical, conceptual or phvsicallv based. A model that is based on analysis oI input and output with the system considered as a black box is termed empirical. A conceptual model uses a combination oI physical representations and empirical equations to Iormulate the model oI the real-world system. Usually the parameters must be calibrated using observed input and output data. A completely physically based model is based upon mathematical process descriptions oI the real world processes. The parameters should in principle be possible to estimate Irom measurements |2|. System models can Iurther be classiIied as lumped or distributed. A lumped model considers the real- world system as one unit, averaging parameters and states over the system. On the other hand, a distributed model allows parameters and variables to spatially vary over the system it represents. Usually the catchment is subdivided in subcatchments or grid cells Ior a better representation oI the real world phenomena. 4.3.1. Obfects Environmental objects can be grouped into a number oI classes that structures the environment into three media: ground, water and air. This simpliIied taxonomy is commonly used by government agencies. For the purpose oI the present work, and because oI the domain Ieatures, it is used the Taxonomy Ior WIRS Domain Objects |24|. This classiIication identiIies Iive types oI objects: hydroecological objects, human activity objects, measuremnt objects, atmospheric variables and hydrologic variables. 4.3.2. Processes Basic hydrological objects processes to be simulated by models are shown in Figure 3. They are identiIied Irom an existing Physical Domain Model |24| Ior WIRS. Usually RainIall-RunoII models include two computing components: runoII and routing. The runoII component represents hydrological processes within a subcatchment or grid cell (depending on the model type), which computes discharge to the channel network within this element. The routing process consists in tracking the water through the river-network. This computing component gets discharge Iorm the runoII component and river inIlow Irom the upper reaches in the adjacent model elements and it calculates river outIlows to lower reaches within the adjacent elements. 4.3.3. Methods There are diIIerent methods Ior each type oI process simulation, which can be Iound in the speciIic bibliography |6|. Methods related with the runoII component computing include the calculation oI processes such as: evapotranspiration, inIiltration, snow melting, overland Ilow, interIlow, base Ilow, etc. By the other hand, there are some methods related with the routing component computing, which take into account the selected calculus strategies like cinematic wave, dynamic wave, etc. 4.3.4. Parameters Model parameters describe the entities that are constant in the model representation. Minimal parameters |6| required Ior a catchment-scale process-based model are: SubsurIace Ilow parameters Ior each soil type, like hydraulic conductivity, porosity, etc. CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 8 Vegetation parameters Ior each vegetation type, like interception storage capacity, canopy resistance, etc. Overland Ilow parameters Ior each slope element in the basin Channel Ilow parameters Snow parameters, like degree-day Iactor. Other parameters speciIic to methods. FIGURE 3. Hydrologic process simulated by models RAINFALL POTENCIAL EVAPOTRANSPIRATION TOTAL RUNOFF MODEL Hydrological Objects Basin, Subasin Catchment Water Course River Reach Channel Lake Reservoir AquiIer Flood Plain Depression Storage Soil Glacier Snow pack Canopy ---------------------- Other Processes Sediment Transport Contamination Biodegradation Dilution. ------------------- Basic Hydrological Processes Precipitation Interception Evapotranspiration Evaporation InIiltration Snow Melting RunoII Overland Flow Storage Discharge Recharge InterIlow Base Flow Flow Routing Methods DiIIerent methods Ior each type oI hydrological object and process and model strategy (empirical, conceptual, physically based). Parameters DiIIerent parameters Ior each hydrological process and method. CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 9 3.5 Conceptual Microarchitectures for the Simulation layer In the Iollowing sections there are deIined conceptual microarchitectures that Iacilitate the Ilexible models scenarios conIiguration 3.5.1 Hvdrologic Models Knowledge Maintenance Each model may present diIIerent conIigurations depending on the hydrologic process involved in the simulation session and on the type oI model, methods and parameters selected Ior the speciIic scenario. Then, the system must 'know all legal simulation conIigurations Ior each type oI hydrological component (Lake, river, snow pack, etc.). For that, it is applied the Knowledge Level analysis pattern |13| as it is shown in Figure 4. There are two levels deIined inside the Simulation Layer: knowledge level and operational level. The knowledge level includes a group oI objects that describe how another group oI objects should behave. In the knowledge level there are all possible legal modeling conIigurations: simulation strategies and parameters associated with diIIerent hydrological processes. Then, its possible to identiIy two components in the knowledge level, deIining independent units with the purpose oI increasing Ilexibility: Simulation Strategies Component and Parametric Component, as it`s shown in the Figure 5. In the Operational level, it is deIined a Structural Component, which maintains the simulation scenarios speciIic behavior to be added to the WRIS hydrologic objects, such as Lake, RiverReach, Catchment, etc. (EI Layer). Convenient structures and conceptual models Ior WRIS have been studied in previous works |2| |25| |26|. Data containers are generic classes that allow the eIIicient incorporation oI state variables to the Structural Component at execution time. The Components that have been identiIied Ior each level and their dependency relationships are shown in Figure 5, using the UML stereotype subsystem~~ Ior high-level components, which internal behavior will be analyzed in the next section. Simulation Layer FIGURE 4. Levels Ior the Simulation Layer layer~~ Operational Level layer~~ Knowledge Level CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 10 3.5.2 Simulation Strategies. The basic conceptual model Ior this component is shown in Figure 6. It allows models scenarios conIiguration using diIIerent processes and computing methods Ior each one. The HvdroProcess class maintains inIormation about the process being modeled (RunoII, Routing, inIiltration, evapotranspiration, etc). The Method class contains the diIIerent computing deIinition Ior each process. HvdroProcess may be an aggregation oI processes. Structural component objects may be conIigured with a Type indicating the selected modeling strategy, Ior example, iI ModelObject is a Lake, then a possible type is Routing (process), Level Pool (method). This conceptual relation (between structural components and strategies) is shown as a dependency in Figure 5. FIGURE 5. Components oI Simulation Layer levels layer~~ Operational layer~~ Knowledge subsystem~~ DataContainer subsystem~~ Structural subsystem~~ Simulation Strategies subsystem~~ Parametric Simulation Layer CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 11 3.5.3 Parametric Information. Some physical parameters are obtained as Iunction oI environmental variables such as soil type, land cover, land use, etc. They can be got Irom existing tables or sometimes it`s possible to calculate them using speciIic methods. It`s convenient to deIine a parametric component where legal parameters Ior each method are maintained as well as their just known corresponding values. For instance, hydraulic conductivity may be calculated Irom soil type; instead oI realizing computations each time this parameter is needed, the parameter value is stored as knowledge in a table related with the right environmental variable. The same thing is done with parameters that are obtained through optimization or through expert experience. Figure 7 shows how each parameter type is associated with a table where legal values and corresponding variables are recorded. Applying the analysis pattern Unit |13|, Units can be represented explicitly in the model allowing this way to convert quantities Irom one unit to another. FIGURE 6. Class Diagram Ior Simulation Strategies Component FIGURE 7. Class Diagram Ior Parametric Component Simulation Strategies Component (Irom Knowledge Level) Model Method MethodA MethodB HydroProcess 1...* 1...* 1 1...* 1 Parametric Component (Irom Knowledge Level) Unit ParMethod ParMethodA ParMethodB Parameter 1...* 0...* 1 1 Table 1 CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 12 The class ParMethod is used to maintain the diIIerent methods Ior parameters calculus as it is shown in the next section. This component must be connected to the components oI the Environmental InIormation Layer, relating parameters with their associated environmental variables Ior the Table construction. The Method class belonging to the Simulation Strategies Component is conceptually related with the Parameter class, allowing this way to deIine all possible legal relationships between methods and parameters and its associated values. This relation is included in the dependency relation between components shown in Figure 5. This way, it was deIined a knowledge level Ior models simulation strategies and parameters, which will be used by the Structural component Ior scenarios conIiguration. 3.5.4 Structural Component. The Structural Component maintains Model objects, which will be conIigured with some speciIic simulation method and parameters. These objects add speciIic behavior related with Ilow computing simulation, to objects Irom Environmental layer, such as river, lake, catchment, etc. which maintains its physical Ieatures and real world measurements. They may be simple (lake) or composed objects (cathcment with river, lake, subcatchment, etc.), depending on the selected scenario conIiguration. The class ParList allows to maintain the legal parameters list associated with the conIigured model object during a Simulation session, as it is shown in Fig. 8. They are obtained Irom the Knowledge level, considering the selected processes and methods Ior the speciIic scenario. 4. DESIGN MODELS Considering the exposed conceptual microarchitectures, in the present section design microarchitectures based on design patterns are deIined, to show the way simulation scenarios are conIigured and how parameter values are obtained either by calculation or optimization Ior their associated tables construction. 4.1. Parameter Acquisition As it was said, there are diIIerent ways to obtain parameter values. Once parameters are obtained, either by calculation or by optimization, they can be stored in tables, related with the corresponding environmental variable value. Tables can also be Ied with values obtained by organizational experiences. FIGURE 8. Class Diagram Ior Structural Component Structural Component (Irom Operational level) ModelObject Hydro Composite ParList CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 13 4.1.1. Parameter calculus. For parameters which can be calculated as Iunction oI environmental variables such as soil type, vegetation type, land use, etc., it is deIined a design microarchitecture that brings Ilexibility to the strategy selection, decoupling computing methods Irom Parameter class. This microarchitecture is shown in Figure 9 and it`s made applying the Strategy design pattern |15|. This pattern deIines a Iamily oI algorithms, encapsulate each one, and make them interchangeable. The Method class declares an interIace to all supported calculating algorithms. Facade design pattern |15| is applied Ior accessing environmental inIormation subsystems appropriately. This pattern provides a uniIied interIace to a set oI interIaces in a subsystem. It deIines a higher-level interIace that makes the subsystem easier to use. The FacadeEIL class delegates Parameter class request to appropriate subsystems. The class named Parameter must know which environmental variable is conceptually associated with the parameter`s value to give this inIormation as an argument to Iacade. 4.1.2. Parameter Optimization. Applying the Strategy pattern it`s also possible to utilize diIIerent strategies Ior parameter optimization by decoupling that responsibility Irom the Parameter class. The corresponding design microarchitecture is shown in Figure 10. FIGURE 9. Obtaining Environmental InIormation Ior Parameters calculus method Parameter store() calculateValue() ..... ParMethod compute() PTransIerFunction compute() XMethod compute() subsystem~~ Soil (EIS) SoilType type() density() ..... Iacade.obtainVar () method.compute() FacadeEIL obtainVar() Iacade Parametric Component (Irom Knowledge Level) Environmetal Layer Simulation Layer CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 14 4.2. Simulation Scenarios configuration. To conIigure some speciIic scenario, ModelObject is conIigured Ior simulation purposes, adding behavior to an appropriate Environmental object, such as lake, river, etc. Decorator pattern |15| is used to dynamically add responsibilities to objects Irom Environmental layer, as it can be seen in Figure 11. FIGURE 10. Class Diagram Ior Parameter Optimization Simulation Layer Environmental Layer Curso outIlow() Almacenamiento outIlow() AreaAporte outIlow() hydrObj hydrObj.outIlow() Decorator ModelObject outIlow() inIlow() simIlow() HvdroObfect ouIlow() inIlow() Structural Component FIGURE 11. Environmental Objects Decoration Ior Simulation purposes method Optimi:ationMethod optimize() HillClimbing optimize() GeneticAlgorithm optimize() Parameter optimizeValue() calculateValue() SimAleaning optimize() method.optimize() Parametric Component (Irom Knowledge Level) CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 15 Strategy pattern is applied Ior updating the state oI hydrological objects with added simulation behavior by some speciIic Computing Method. This pattern allows to decouple Irom the structural object the hydrological proccess to be calculated and the corresponding computing method, making them dinamically interchangeable and giving this way more Ilexibility to the design model. This is shown in Figure 12. ComputingMethod Class is responsible oI knowing which parameters are neccesary Ior the model object type proccess simulation and oI obtaining the list oI legal parameters Irom the Parametric Component. Once legal parameters are obtained, ModelObject must know the values oI Environmental variables related with each parameter in the list, ie., iI a legal parameter in the list is hydraulic conductivity, the object must know the soil type Ior its geographic location. For that, it`s possible to apply the Facade pattern allowing this way Model Object to access the appropriate environmental subsystem, sending object location as an argument and obtaining the desired variable value. This is possible because all environmental objects are represented in the same geographic reIerence system by means oI GeoFrame specialization. Now, parameters values can be obtained Irom tables. At execution time, parameters should be stored in a generic class, giving this way more eIIicience to methods execution in each time step. FIGURE 12. Strategy pattern Ior process Ilow deIinition ComputingMethod computeFlow() SaintVenant computeFlow () CinematicWave computeFlow() HydroProccess setMethod() proccessFlow() Routing proccessFlow() RunoII Ilow() compMethod proccess ModelObject outIlow() inIlow() simIlow() Structural Component (Irom Operational Level) Simulation Strategies Component CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 16 5. HOW TO CONFIGURE A SIMULATION SCENARIO USING THE KNOWLEDGE LEVEL To show the way the exposed models would be used Ior modeling scenarios conIiguration, in the present section there is an example oI objects collaboration in the Iollowing use case realization: 'Calculating the runoII process in a catchment using the Clark Method. The scenario may be conIigured as: Environmental Obfect: Catchment ModelObfect: Decorated Catchment with Tvpe: Process: RunoII, Method: Clark The speciIic ModelObject (Irom the Structural Component, Operational layer) would be asked Irom a Client to return its output Ilow generated by RunoII process, using Clark Method (Figure 14). The existing association with the corresponding environmental object allows knowing the Catchment`s physical and geographic properties. ModelCatchment will Iorward the request to the HydroProcess class (Simulation Strategies Component, Knowledge level) to veriIy that Clark is an appropriate method Ior RunoII calculus, and then it will delegate this responsibility on the speciIic Method class, as it can be seen in Figure 15. BeIore that, it was necessary to conIigure ModelCatchment with its associated object ParList, obtaining the legal parameters Ior the corresponding TvpeObfect (Knowledge level), and its related environmental variables obtained Irom subsystems in the Environmental Layer. This is made applying the Facade pattern, using location as argument. As it was shown in Figure 5, there is a dependency between the Simulation Strategies Component and the Parametric Component. When calculating, Clark Method will ask the Parameter class Ior the CN parameter value (which depends on soil type oI land use) Irom the appropriated table, sending the depending variables values Ior the catchment location as arguments. Environmental Layer Simulation Layer Model Catchment Catchment Client simFlow(RunoII, Clark) location() Model Catchment RunoII ClarkMethod processFlow(Clark) computeFlow() ClarkMethod Parameter Table CNvalue(stype, luse) get() FIGURE 14. Objects collaboration showing the Client request FIGURE 15. Objects collaboration showing the computing process FIGURE 16. Objects collaboration showing parameter values acquisition CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 17 The same process is made Ior the Iollowing legal parameters used by the Clark Method in the object ParList. As it was said, the Parameter class maintains attributes such as the parameter name and its related environmental variables. To construct its associated table, it delegates to FacadeEIL class the responsibility oI Iinding all possible variable values Irom the Environmental Layer, by means oI the statement Iacade.obtainVar() sending the variable name as an argument. Then, the message calculateValue() is sent to the ParMethod class (Figure 8) using the variable value as an argument, to calculate the appropriate parameter value. For a given simulation session, at execution time parameter values are added to a generic class Ior eIIicient methods execution (Figure 17). It can be seen that classes which represent environmental objects (such as catchment, land use, etc.) may be related by their location, because they present geographic behavior by means oI the specialization oI GeoFrame services (Geographic Representation Layer - Figure 1) in the general application layer. 6. AKNOWLEDGEMENTS The present work was developed in the scope oI the 'Design Model Ior Hydrologic models application domain in the EIS context Project Iinanced by the Facultad de Ingenieria (UNPSJB) and availed by CIUNPAT. Research results will be applied in the Water Resource Department oI Tierra del Fuego Government. 7. CONCLUSIONS This article explores the potential oI Ilexible soItware development mechanisms like architecture, patterns and components in the hydrologic modeling domain. It is shown how a layered architecture helps to integrate models and inIormation systems in diIIerent abstraction levels. Conceptual microarchitectures Ior strategies and parametric inIormation Iacilitate the Ilexible simulation scenarios conIiguration. Using components in a simulation layer allows either deIining new design models or reusing existing strategic and parametric components. Analysis and design patterns give Ilexible solutions to the critical question related with parametric inIormation management. The results oI the research will be extended in a Iurther step Iormally speciIying components and interIaces. 7. REFERENCES |1| Abbot M. Hvdroinformatics. Information Technologv and the acuatic environment Avebury Technical, Adlershot, UK, 1991. |2| AlIredsen J. An obfect oriented framework for application development and integration in hvdroinformatics. Dr. Eng. Thesis, Norwegian University oI Science and Technology, 1998. Model Catchment ContainerPar get() Parameter addValue() FIGURE 17. Creating a Parameter Container CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004 18 |3| Appleton B., Patterns and Software. Essential Concepts and Terminologv .Web Page www.enteract.com/~bradapp/, 2000. |4| Bass L. and Kazman R. Architecture Based Development. Technical Report CMU/SEI 99-TR-007, Carnegie Mellon University, 1999. |5| Bass L., Clements and Kazman R. Software Architecture in Practice, Addison-Wesley, 1997. |6| Beven, K. Rainfall-Runoff Modelling. Wiley, 2000. |7| Blind M. Adrichem B. Generic Framework Water. An open modelling svstem for efficient model linking in integrated water management - current status Paper presented at the 4th International Eurosim 2001 congress 'Shaping Future with Simulation, 2001. |8| Booch G. Jacobson I., Rumbaugh J. The Unified Process Software Development. Addison-Wesley Publications, 1999. |9| Booch G. Jacobson I., Rumbaugh J. The Unified Modeling Language Addison-Wesley Publications, 1998. |10| Buschmann, F. Meunier, R.; Rohnert, H.; Sommerlad, P. and Stal, M., Pattern-Oriented Software Architecture. A svstem of patterns. New York: John Wiley & Sons, 1996. |11| Chow Ven Te. Hidrologia Superficial Addison Wesley, 1997. |12| Ericsson M. Developing Large-scale Svstems with the Rational Unified Process. Rational SoItware White paper, Rational SoItware Corporation, 2000. |13| Fowler, M. Analvsis patterns. reusable obfect models. Menlo Park: Addison Wesley Longman, 1997. |14| Fowler, M. Patterns for things that change with time. Fowler Web Page, 2001. |15| Gamma, E. H Design Patterns. Elements of Reusable OO Software Addison-Wesley, 1997. |16| Gordillo, S. Tesis de Magister en Ingenieria de SoItware, Modeli:acion de campos continuos en Sistemas de Informacion Geografica, UNLP, 1998. |17| Gnther, O. Environmental Information Svstems. Springer-Verlag, Berlin, Germany, 1998. |18| Lisboa J., Iochpe C. Specifving Analvsis Patterns for Geographic Databases on the basis of a conceptual framework., ACM-GIS '99, Proceedings oI the 7th International Symposium on Advances in Geographic InIormation Systems, November 2-6, 1999, Kansas City, USA, 1999. |19| Lisboa J., Iochpe C., Beard K. Applving Analvsis Patterns in the GIS Domain Presented at the 10th Colloquium oI the Spatial InIormation Research Centre, University oI Otago, New Zealand, 16-19 November, 1998. |20| Malan R., Bredemeyer D. Software Architecture. Central Concerns, Kev Decisions. Architecture Resources Pubs., Bredemeyer Consulting, 2002. |21| Monroe R., Kompanek D. Melton R. and Garlan D. Stvli:ed Architecture, Design Patterns, and Obfects, 1996. |22| Riehle D., Zllighoven H. Understanding and Using Patterns in Software Development. Theory and Practice oI Object Systems Wiley & Sons, 1996. |23| Szyperski C., Component SoItware. Beyond Object-Oriented Programming. Addison-Wesley, 1998. |24| Urciuolo A., Iturraspe R. Conceptual Patterns for Water Information Svstems. Journal oI Computer Science & Technology, 2003. |25| Urciuolo A., Iturraspe R., Parson Ariel, Sandoval Sandra Patrones conceptuales para Sistemas de Informacion Hidrica. Proceedings CACIC 2002, Buenos Aires, Octubre de 2002. |26| Urciuolo A., Iturraspe R. Microarquitecturas de Diseo OO para Modelos hidrologicos. Jornadas Universitarias de InIormatica, Proceedings Congreso del Nuevo Cuyo, San Juan, Octubre de 2001. CLEI ELECTRONIC JOURNAL, VOLUME 7, NUMBER 1, PAPER 6, JUNE 2004