1.0 Introduction
1.1 Terminology
1.2 Modeling Background
1.3 Framework Background
1.1 Modeling and Framework Terminology
The overall design of the CCEF consists of developing framework requirements, architecture design, and data exchange protocols using a modular approach that allows users the flexibility to construct, combine, and couple attributes that meet their specific modeling needs. This allows a variety of models and databases to work within a single construct. There are various terms that need to be defined to help the reader understand the overall design of the CCEF documented in this report.Framework
A framework typically consists of a set of modules that have been specified by the client, an associated framework user interface, and data exchange protocols. The purpose of a the framework is to:- Minimize data-exchange requirements between modules in the framework
- Allow relatively easy inclusion of additional modules and models into the framework
- Allow for unlimited access to data
- Address linkage concerns for a variety of models.
Object
An object, in the context of this study, is a module, model, database, or algorithm that is associated with the CCEF. The Framework treats all these the same, as objects. An object reads data from other objects, processes that data, and writes out that data to other objects. In the case of a database, the data may not necessarily be processed. From the Framework's point of view, these objects are all the same and must follow the data exchange protocols associated with them.Module
A module potentially contains three components: the user interface, the scientific model, and, for those frameworks that incorporate legacy models, pre-and/or post-processors. Examples of modules include source term releases, vadose zone transport, saturated zone transport, surface water transport, air transport, exposure pathway analysis, dose estimates, health impacts, and sensitivity/uncertainty support tools.
Model
A model is the set of scientific algorithms, calculations, and databases that define a particular module. Several models have been developed over the past 10 years by researchers focusing on developing fully integrated, multi-media, multi-pathway, multi-route modules that allow a more transparent connection between individual medium-specific models. The grouping of these models takes a holistic approach to environmental assessment of potential contaminant impacts as they simulate:
1. Release of contaminants into the environment
2. Transport and fate through various environmental media (i.e., groundwater, surface water, air, and overland surfaces)
3. Resultant exposures and impacts to an organism
4. Support tools such as sensitivity, uncertainty, graphical interface systems, and displaying results.
Module User Interface
The purpose of the module user interface is to make it easy for the user to collect the data necessary to run the model. Besides gathering the necessary data, the module user interface often provides online help to the user, reference storage options for collected data, flexible unit inputs, and other user support functions.
Module Pre/Post-Processors
As mentioned earlier, time and cost are saved if models can be integrated into a framework intact. Legacy models that have been tested and reviewed can be preserved and integrated by the addition of pre- and/or post-processors to the module. These processors transfer reorganized data into the specified format of the overall framework, thus allowing the inclusion of models that were initially created for a media-specific analysis to be used in this more holistic approach to multiple media assessments. Whether a pre/post-processor is used depends on the needs of the scientific model and the data exchange protocols of the framework. Models that have been created or modified with the data exchange protocols predefined will likely not need pre/post-processors before integration.
Overall Design of Comprehensive Chemical Exposure Framework (CCEF)
Framework attributes for micro-environmental exposure modeling vary depending on the needs of the research area. The problem set and client needs will define the requirements, design, and data exchange protocols for a framework. This section will provide a brief definition and purpose of the framework requirements, design, and data exchange protocols.
Framework Requirements
A project starts with the definition of the research needs. What problem or problems must be solved? What kinds of information are needed? Who are the ultimate users and how can the framework best meet their needs? This definition begins with the analysis of the needs, a definition of the functional components of hardware and software, and packaging of the information. The requirements analysis is based on communication with the client and needs of the research area of interest and produces a set of requirements for the framework that describe what the software should do.
The information in the requirements package should, at a minimum, answer the following questions:
- Which capabilities have been discussed with the client and research area of interest?
- What additional capabilities are necessary to produce a quality product?
- What specific restrictions have been noted?
- What potential difficulties have been identified?
- What compatibilities are necessary for usability?
Specific requirements for a framework include:
- Data exchange protocol needs
- Mathematical algorithms and formulations
- Necessary help information
- Identification of ways to ensure a consistent look and feel with related interfaces
- Expected deliverables for the task.
Framework Design
If the requirements of a framework describe what the software should do, the framework design describes how the software will implement the stated requirements. Design of a framework cannot start until a set of requirements has been developed. Usually an initial set of requirements is developed and then a design is implemented based on those requirements. In almost all cases, issues will arise during the design process that will require changes to the requirements. In this way the definition of requirements and design is an iterative process. In many cases, design will include prototyping of software to provide an early look at the software and its functionality.
Data Exchange Protocols
Before a framework is designed, the appropriate databases and the file structures of the input and output for the framework and modules must be defined. Module file structure should be consistent with the framework’s data exchange protocols. Pre/post-processors may be used to aid in the conversion of legacy code file formats not already meeting those data exchange protocols. All file formats should be designed to ensure readability and compatibility with most spreadsheet programs, and to incorporate necessary information to communicate the use and purpose of each file.
