The development of the WadBOS Decision Support …publicaties.minienm.nl/download-bijlage/30033/dss-wadbos.pdfThe development of the WadBOS Decision Support System 4 (DSS), representing

The development of the WadBOS Decision Support System

1

TTTTHE HE HE HE DDDDEVELOPMENTEVELOPMENTEVELOPMENTEVELOPMENT OF THEOF THEOF THEOF THE

WWWWADADADADBOS DBOS DBOS DBOS DECISION ECISION ECISION ECISION SSSSUPPORT UPPORT UPPORT UPPORT SSSSYSTEMYSTEMYSTEMYSTEM....

A A A A BRIDGE BETWEENBRIDGE BETWEENBRIDGE BETWEENBRIDGE BETWEEN KNOWLEDGE AND POLICYKNOWLEDGE AND POLICYKNOWLEDGE AND POLICYKNOWLEDGE AND POLICY IN THE IN THE IN THE IN THE WWWWADDEN ADDEN ADDEN ADDEN SSSSEAEAEAEA

Guy Engelen

Research Institute for Knowledge Systems bv P.O. Box 463

6200 AL Maastricht The Netherlands

Tel. 31-43-388.33.22 Fax. 31-43-325.31.55

guy@ riks.nl www.riks.nl

Technical paper prepared for:

National Institute for Coastal and Marine Management / RIKZ Directorate-General of Public Works and Water Management Ministry of Transport, Public Works and Water Management

P.O. Box 20907 2500 EX The Hague

The Netherlands

Contract: 42002555 November 30th, 2000


2

0. C0. C0. C0. CONTENTSONTENTSONTENTSONTENTS

0. CONTENTS.................................................................................................................................... 2 1. ABSTRACT.................................................................................................................................... 3 2. THE FUNCTIONS OF WADBOS..................................................................................................... 3 3. DEFINITION OF A DSS.................................................................................................................. 5 4. A TOOL FOR PEOPLE DEVELOPED BY PEOPLE.............................................................................. 6

4.1 A partnership involving end-users, DSS developers and Domain specialists ...................... 6 4.2 Iterative design and development.......................................................................................... 9

5. DEVELOPING THE MODELBASE.................................................................................................. 10 5.1 Knowledge acquisition ........................................................................................................ 10 5.2 Integration of Models .......................................................................................................... 12

5.2.1 End-use integration ...................................................................................................... 12 5.2.2 Scientific integration .................................................................................................... 14 5.2.3 Straightforward integration, adaptation, rebuilding, or developing............................. 14

6. TECHNICAL INTEGRATION......................................................................................................... 15 6.1 One of four possible architectures ...................................................................................... 16 6.2 The Geonamica® DSS Generator....................................................................................... 20

6.2.1 An application framework to implement WadBOS .................................................... 20 6.2.2 Model building Blocks in GEONAMICA................................................................... 21

7. THE INTEGRATED WADBOS MODEL ........................................................................................ 24 8. TOOL INTEGRATION................................................................................................................... 28 9. DATA INTEGRATION .................................................................................................................. 30 10. USER INTERFACE ..................................................................................................................... 31 11. DISCUSSION AND CONCLUSIONS............................................................................................. 34 12. REFERENCES ............................................................................................................................ 37


3

1. A1. A1. A1. ABSTRACTBSTRACTBSTRACTBSTRACT The Wadden Sea is an important coastal system in the north of the Netherlands. It is part of a larger system extending into Northern Germany and Western Denmark. In the Netherlands, the sea has the status of a protected natural site because of the important ecological functions that it fulfils. At the same time, the sea has an important economic function. Fishing, recreation, transportation, and mining are among the main economic activities. It generates employment, income and food for many a household. The management of the different activities and functions of the sea is distributed over a great number of institutions, ranging from the local to the European. When new decisions are required or policies need to be developed relative to the exploitation or protection of the area, incompatible views tend to slow down the decision-making process. In order to streamline this process, CUBWAD, the governmental organizations responsible for the management of the Dutch Wadden Sea, decided in 1996 to initiate the development of an Information System. The aim of the latter was to gather the knowledge available about the sea and to link it with a view to make it available in an operational form usable for policy and decision making. Today, 4 years later, WadBOS exists in its second version. It is a Decision Support System featuring an integrated model representing the ecological and the economic functions of the sea. The constituting sub-models represent processes operating at different time scales, ranging from daily to yearly. They also represent spatial processes operating at three different spatial scales: the whole sea, 12 relatively homogeneous compartments within the sea, and small cellular units of 25 ha each. The WadBOS system relies heavily on GIS information for its inputs, but its models need economic, demographic and ecological data from other sources equally well. WadBOS has been developed to be useful for and usable by the decision makers in the region working in isolation or in a group setting. A lot of effort has gone into its user-friendly character, its interactive capabilities, the (geo)graphical representation of its dynamic output, and its transparency. The system has been instrumental in analytical exercises, but its communication and learning capabilities have proven to be at the least as important. WadBOS is not finished. Probably it will never be finished, as new scientific insight and knowledge will become available in the course of time, new policy problems will surface, and views on the role of policy making will change. But, WadBOS is equipped with a number of appealing features, which make it fairly unique in its kind. In this paper, we will discuss the technical choices that have been made during the development process. From this discussion it will become clear that WadBOS-like systems are very demanding on state of the art information and computer technologies, but that their successful implementation and use in a decision making organization is even more dependent on the intricate interplay of different actors: end–user, domain specialists and developers.

2. T2. T2. T2. THE FUNCTIONS OF HE FUNCTIONS OF HE FUNCTIONS OF HE FUNCTIONS OF WWWWADADADADBOSBOSBOSBOS The development of WadBOS started in 1996 when CUBWAD concluded that policy-making in the Wadden Sea could be enhanced if the abundant existing knowledge about the Wadden Sea, which is generally spread among the many policy making, management, and research bodies active in the region, would be gathered, ordered, linked and made available in an operational form to those involved in the policy-making process. The general thinking was that an information system of some sort, a Knowledge Based System (KBS), Expert System (ES) or Decision Support System


4

(DSS), representing the Wadden Sea in an holistic manner, integrating ecological functions and human activities at the appropriate temporal and spatial scales would be a very useful instrument for this purpose. Such system was expected to enable the exploration of the autonomous dynamics of the Wadden system as well as the analysis of effects of policy measures thereon. Thus it would boost the analytic capabilities of the policy-makers, the communication between the policy-makers and stakeholders, and the awareness development in the region. To enable learning and knowledge acquisition about the system the knowledge base of this system should be transparent: a glass box, rather than a black box representation. Once the available knowledge would be integrated the system would equally demonstrate the white spots in the knowledge base and thus give impetus to future research activities. Thus, the scope and function of WadBOS is broadly defined a system providing information and knowledge in support of the preparation of, and possibly the implementation of, integrated policies for the Wadden Sea. It is not to wonder that tasks are named covering all phases in a typical decision making process (see for example: Mintzberg et al., 1976). After all, policy-making is essentially decision making. Hence, we can easily recognise a learning function, when it comes to deepening the understanding about particular topics and linkages, a library function, when it comes to acquiring knowledge and information about issues or problems, an analytic function when it comes to searching for solutions and alternatives to solve policy problems, and finally, a communication function, when the steps taken during the policy making process, or the results obtained from it are to be shared with others involved: stakeholders, fellow policy makers, or the recipients of the policies: the public. •= Analysis is certainly the most important task of the envisaged system as WadBOS is to provide

its end-user with a good insight into the autonomous dynamics of the Wadden system. It should enable judging the effects of policy intervention onto the system and should finally assist in coming to a decision relative to precise policy measures to be implemented. This kind of support is only possible if WadBOS is equipped with a formal representation of the Wadden system capable of performing sophisticated calculations and evaluation of potential effects.

•= Learning is an inherent result of analysis, as a good insight into a problem holds in part the solution to it. A WadBOS system featuring a holistic representation of the Wadden system becomes a very valuable learning instrument in that it provides insights, not only in the individual domains but also in the linkages between the domains represented. Users that are experts in the dependencies in their own field of interest may want to use WadBOS to learn about the linkages to the fields of others and the processes unknown to them.

•= Communication or the lack thereof is what renders integrated policy making as difficult as it often is. A facility that visualises the anticipated effects of policies in a very tangible manner will not always or necessarily lead to consensus, but at the least, it makes things much more tangible and thus facilitates greatly discussions among policy makers, stakeholders and the public at large.

•= Library. A WadBOS that gathers, orders and links knowledge can serve nicely as a knowledge management infrastructure and can fulfil the function of a dynamic library. It may reveal knowledge gaps, and thereby give impetus to further research and data collection. The more this knowledge is available in a formal manner, the more it will be operational and thus immediately useful to a large group of users.

The above is an ambitious set of functions, which is not easily attained by traditional information systems such as databases or GIS systems. Rather, an information system is envisaged with a high level of intelligence (Catanese, 1979): a system with the ability to manipulate and aggregate data as the result of statistical, mathematical, heuristic or algorithmic operations and to catch from this complex information and data the essential factors explaining the functioning and the dynamics of the Wadden system. To achieve this, this information system is to be equipped with formal models and methods.


5

3. D3. D3. D3. DEFINITION OF A EFINITION OF A EFINITION OF A EFINITION OF A DSSDSSDSSDSS Few analysts or policy makers will contradict the statement that nearly all problems in the field of integrated coastal zone management are complicated, complex, ill-defined or unstructured in nature. Models, mathematical models in particular, are instruments to solve structured and strictly defined problems: given a strict formal solution method or algorithm, and given that all the inputs required by this algorithm are provided; the model will produce a fully specified output. Thus, there seems to exist an incompatibility between the needs and the tools: ill-defined problems, but tools for solving strictly defined problems. The question at hand then is: are models useful instruments for decision makers and how can they be made more useful to them? The short answer to this question is a confirmation of the incompatibility: many problems in coastal zone management still await more appropriate analytical tools. However, many problems can be sufficiently solved by approximating their solution as closely as possible. This is where Decision Support Systems become useful instruments. Decision Support Systems (DSS) are computer-based information systems developed to assist decision makers to address semi-structured (or ill-defined) tasks in a specific decision domain. They provide support of a formal type by allowing decision makers to ‘access’ and use ‘data’ and appropriate ‘analytic models’ (El-Najdawi and Stylianou, 1993). The terms ‘semi-structured’ and ‘appropriate’ in this definition refer to the fact that Decision Support Systems are typically applied to find answers for problems that, due to their specific nature and complexity lack an unambiguous solution method. Rather, usage of the most appropriate analytical solution methods available approximates the unique answer. Thus, the DSS provides the decision maker with a suit of ‘analytic models’, which are considered appropriate for the decision domain. Typically decision models, statistical and operations research methods are available from the modelbase of the DSS. Even more essential in the modelbase are the domain specific models capable of grasping the complexities of the system and the problems studied. Integrated models play a key role in the modelbase of a DSS in the sense that their constituting models are covering, at the least in part, the (sub-)domains related to the decision problem, but more so because a good integrated model features the many essential linkages between the constituting models and the related domains. Thus, the user of the DSS gets immediate access to very rich and operational knowledge of the decision domain. But a DSS is more than an integrated model or (1) a modelbase alone. Typically three more components can be distinguished (Engelen et al., 1993): (2) a user interface enabling easy interaction between the user and the system, (3) a modelbase containing the raw and processed data of the domain and the area at study; and (4) a modelbase with the methods, analytical techniques, and software instruments required to work in an effective manner with the domain models and the data.

User interface

Model-base

Data- base

Tool-base

Figure 1: Basic functional components of the WadBOS DSS


6

Each of the four components fulfils specific tasks within the DSS and has a complex internal structure. In this paper we will discuss these briefly in later sections. Most of our attention will go to the modelbase of the DSS and that of WadBOS in particular. The development of a tool for a technical and complex subject like ‘Integrated Coastal Zone Management’ requires a very rich modelbase with models from very different domains operating at different spatial and temporal scales. Moreover, in line with the stated objectives, the approach taken in WadBOS is clearly bottom-up: based on a reasonable understanding of the characteristic processes and problems typifying the Wadden Sea and based on a fair amount of complementary knowledge and modelling material available from a large number of organizations, an integrated model was designed and constructed. This integrated model, consisting of linked sub-models, represents the Wadden system as completely as possible with a view to facilitate the design and evaluation of integrated policies. The development of WadBOS involves three major aspects. •= Foremost like any other DSS, WadBOS is intended for people and should contain information

and knowledge useful for problem solving. This can only be achieved as a result of very close collaboration between people.

•= Second, there is the aspect of knowledge acquisition and development of the modelbase in a manner that leads to an integrated model, which is appropriate for policy making. This also involves people, but major scientific issues need to be dealt with too.

•= Finally there is the technical implementation of the DSS, which requires technological means and methods, software designs, and adequate and careful lifecycle planning.

4. A 4. A 4. A 4. A TOOL FOR PEOPLE DEVETOOL FOR PEOPLE DEVETOOL FOR PEOPLE DEVETOOL FOR PEOPLE DEVELOPED BY PEOPLELOPED BY PEOPLELOPED BY PEOPLELOPED BY PEOPLE Decision Support Systems can only be successful if they are developed as part of an effort involving both the intended end-users and the DSS developers. This is mostly so because they are still highly technical, novel products with a high degree of sophistication, typically build by those not using them and used by those not building them. They require experienced professional analysts, specialized in the development of DSS applications, and formally trained in computer science, as well as knowledge engineers, system analysts and model developers knowledgeable about the details surrounding the problem under study. But, the DSS is to incorporate knowledge and expertise of the decision domain known to the end-user and, he or she is best placed to clarify the functionality expected from the system, hence can bring in this information in the project and thus participate actively in the development of the product. In WadBOS the intended end-users are coastal zone managers and policy makers. Their profile is best described as: high-level technicians actively involved in the design and evaluation of coastal zone management policies. They perform policy work of a formal/analytic nature in support of the administrator or politically appointed person responsible for taking the actual decision and starting the actual policy implementation process. Thus, this policy maker is not a politician; rather, he is a technician. He is not setting the agenda; rather, the latter is set by his superior, the public, and more and more the media. Most often, the policy maker will work under a lot of stress due to time constraints and rapid changes in the emphasis and relevance of the policy work itself.

4.1 A partnership involving end4.1 A partnership involving end4.1 A partnership involving end4.1 A partnership involving end----users, DSS developers users, DSS developers users, DSS developers users, DSS developers and Domain specialistsand Domain specialistsand Domain specialistsand Domain specialists WadBOS involved different kind of organisations and people, each with a specific role in the project and in the creation of the DSS:


7

First, there is CUBWAD (Commissie uitvoering Beheersplan Waddenzee). As an organisation of governmental bodies responsible for the implementation of the management plan of the Wadden Sea they initiated in 1996 the feasibility project, which eventually resulted in the actual version of WadBOS. CUBWAD assembles institutional partners from provincial and national governing bodies. It took the initiative, because it came to the conclusion that the ever-increasing complexity of its management task could possibly be made more transparent through the introduction of some kind of information system enabling the analysis of the cumulative effects of human activities in the Wadden Sea on the natural system. Thus, the first condition for the effective introduction of an information system in the organisation was met, as the organisation decided that change was needed in its way of working, and that this change could possibly be facilitated by some kind of information system. CUBWAD, as an organisation, is the near to optimal end-user of the WadBOS DSS, in the sense that it reflects within its structure and tasks the very different geographical, temporal and contextual dimensions of policy making in the Wadden Sea. At the same time the same diversity is a major problem for the development of the product, as a diverse group of users is very likely to have a diverse set of expectations relative to the end-product and thus will produce a diverse set of user requirements. This of course is a burden for the development of any kind of software product. Moreover, a large, diverse group of end-users is very difficult to involve in the typical development cycle of a DSS involving a lot of interactions between the developers and the end-users. To a degree, the problem of end user involvement was solved in WadBOS in so far that one of the partners in CUBWAD, the Ministry of Public Works, Water management and Transport, took the initiative to carry out the feasibility study. This eased greatly the development of the first prototype of WadBOS, but, it hampered and keeps on hampering the introduction of the system in the CUBWAD organisation. Second, the Ministry of Public Works, Water management and Transport, represented by its regional directorates North Netherlands, North Holland and its research division RIKZ in Haren initiated the WadBOS project proper. They represented the end-user community and gave direction to the context, desired policy content, and the functionality of the end-product. At the same time they took active part in the development of the product: they translated as much as possible the management objectives written out in the Management plan for the Wadden Sea into workable and measurable variables, indicators and criteria to be incorporated into the system and to be used for the analysis and the comparison of alternative policies. They took responsibility for the provision and the adaptation of GIS material required for the system, and finally, they used their network of domain specialists actively involved in the area to facilitate the acquisition of data, information and knowledge to be captured into the WadBOS system. More than in the typical DSS project, WadBOS was blessed with a group of visionary end-users that had been involved in a previous, smaller project, in which they tried to do the same, but choose to address the problem by means of a static rather than a dynamic approach (RWS Noord-Nederland et al., 1995). An approach also which was partly qualitative rather than fully quantitative. From this exercise, they learned how to avoid the same pitfalls. They understood the importance of integrated models and discovered the difference between high-resolution dynamic spatial models and static overlay analysis offered in GIS the hard way. With this in mind they screened the market for products and developers, which they considered useful and competent to produce the product envisaged. Third, a relatively small group (+/-10) of DSS developers experienced in the development of the kind of product participated in the project. The members of the developers group were in fact spread out over the entire country. But, Internet and e-mail facilitated greatly an intense collaboration within the group as well as with the domain experts, and, at very regular intervals, meetings with the end-users were organised. Although the developers were all experts in their own and different fields, they had not more than an average knowledge about the Wadden Sea and the processes that typify it. This however, had the positive effect that all the others involved in the project: the end-users, stakeholders and domain specialists, took a very open-minded, informal attitude relative to these ‘new-comers’. Moreover, the new-comers themselves did not have definite views on the region, the domains, the processes or the problems to be represented. All aspects, processes and problems as well as all the advice, expertise, data, information and


8

knowledge gathered got an equal and objective treatment. Although there is no proof of this, we believe that it might have been much more difficult to obtain the same result with people knowledgeable about the region, but associated with one or the other organisation having a stake in the region or its management. The DSS developers group consisted of the following specialists: •= Trans-discipline’ and ‘trans-role’ domain specialists / scientists / model developers

Coastal Zone Management issues and most other problems related to socio-environmental systems are set in very complex systems. Thus, what is needed most in order to develop effective instruments are scientists and model developers interested in interdisciplinary work, and interested in looking into the domain of the other with a view of building knowledge-bridges between the domains. Scientists also having the flexibility to imagine the position of others involved in the exercise. In most cases, to take the role of the end-user and thus understand much better his exact problems and needs.

•= An architect of the modelbase and integrated model of the DSS It is not enough to bring together a bulk of ‘good’ sub-models in order to construct an integrated model nor is it enough to bring together a group of ‘good’ model builders to do so. Individual model developers are often proficient in their domain and the models that they develop, but may not be interested in going much beyond this to build bridges with others. This is why a project team needs an architect of the modelbase. He is more of a generalist and has a very good understanding of the pitfalls of modelling in general. He gives guidance to the model developers in reformulating and adapting their material and keeps an eye on the role performed by each sub-model, on the integration, and on the overall functionality covered.

•= Flexible and skilful software system designers and developers Decision Support Systems are complex information systems requiring knowledge of state of the art software technologies, high-level programming skills, and a lot of programming effort and patience to be built (see Section 6.2). A well-designed system and an appropriate development strategy will minimise the amount of ‘lost’ implementation effort (see Section 4.2). However, re-implementation cannot be avoided. Hence, the software developers should be aware of, and accept the fact that some of their hard work might be ‘thrown away’ in the next version of the system.

•= A professional ‘communication’ specialist (a mediator, or facilitator) The expertise and working methods of policy-makers and scientists can be worlds apart. Hence, when they are to work together on a complex product like a DSS, it is not uncommon that communication and the exchange of information are very difficult or non-existing. Especially when the group of end-users and/or developers is large, the participation of a communication professional, a mediator or facilitator, in a project team can be very effective. In WadBOS this role was not filled in during the building phases of the instrument, because the relationship among those involved in the project was near to perfect. However, the need for professionals of the kind was felt much more strongly when a new version of the product was to be communicated, demonstrated and evaluated with the large group of intended or potential end-users within the CUBWAD community.

•= Project manager. The development of a DSS is hard work. Very many little details matter and must be dealt with in order to deliver a foolproof and bug-free product. A strict management of the project is essential. This is not only so because more than a few people are involved in it, but also because the work is organised in clearly sequenced tasks: a model needs to be past the conceptual phase before it can be implemented and before it can be tested, validated and run. Once many small models become integral parts of much more encompassing DSS systems, the synchronisation and sequencing of the tasks becomes paramount. An agreed work schedule, clearly defined tasks and stated milestones need to keep the project on track. If not the delivery of the system will be endangered and the costs may rise in a disproportionate manner.

The group of WadBOS-developers was sufficiently small and the competences of the people involved were complementary. Hence, the division of tasks was straightforward and very little


9

time was lost in conflicts and misunderstandings of all sorts. The end-users were given a lot of leeway in defining the user requirements and functions of the system. With them the themes to be incorporated into the WadBOS system were prioritised and a realistic implementation plan was worked out that could be adhered to during the execution of the project. Finally, there is the large group of some 20 to 30 domain experts. These are technicians and researchers of one of the many organisations active in the region: Ministries, Provinces, Municipalities, NGO’s, Universities and other research organisations, and Consultants. Many of them have worked in the region for decades and have an excellent knowledge of the working of parts of or the whole Wadden system. They do not necessarily possess of this knowledge in a formal manner. Actually only few of them work with formal mathematical or rule based models. Most have acquired the knowledge because they have been involved in a number of different exercises including policy preparation and evaluation, environmental impact analysis, data analysis, monitoring, scientific cruises, report writing, advisory work, etc. This too, we believe eased to a great extent the development of WadBOS, in that it was important to talk to both modellers responsible for the development, maintenance and upgrading of models that have proven their reliability and usefulness and to people with a general, almost encyclopaedian knowledge about the system, without a particular commitment to his or her mathematical model or method.

4.2 Iterative design and development4.2 Iterative design and development4.2 Iterative design and development4.2 Iterative design and development In WadBOS, we applied the life cycle model known as Evolutionary Delivery (McConnell, 1996). This model was preferred to the Waterfall model and Evolutionary prototyping (see Figure 2).

SoftwareConcept

RequirementsAnalysis

ArchitecturalDesign

DetailedDesign

Coding andDebugging

SystemTesting

SoftwareConcept

PreliminaryRequirements

Analysis

Design ofArchitecture

and System Core

Develop aVersion

Deliver theVersion

ElicitEnd-userFeedback

IncorporateEnd-userFeedback

DeliverFinal

Version

SoftwareConcept


ArchitecturalDesign

DetailedDesign

Coding andDebugging

SystemTesting

SoftwareConcept


ArchitecturalDesign

DetailedDesign

Coding andDebugging

SystemTesting

SoftwareConcept


Analysis


and System Core

Develop aVersion

Deliver theVersion



DeliverFinal

Version

SoftwareConcept


Analysis


and System Core

Develop aVersion

Deliver theVersion



DeliverFinal

Version

Figure 2: Left. It is difficult to back-up to previous phases in the Waterfall lifecycle model. Right. The iterative nature of the Evolutionary Delivery lifecycle model provides some ability to accommodate end-user requests mid-course. (McConnell, 1996).

The development of a WadBOS-like system cannot be easily reduced to the typical Waterfall lifecycle model in which clearly defined stages are gone through strictly sequentially and in which in a late stage the technical work is carried out. This model fails for the simple reason that, at the beginning of a project, insufficient information is available both with the developers and the end-users on how and for what tasks the system will be used in practice by its end-users. Hence, the precise functional requirements of the envisaged system are not clear. Further, it is not entirely


10

clear what kind of knowledge and models are available to represent the domain and are useful to integrate in the system. Hence, the exact contents of the system remain slightly vague, making it difficult to select a precise architecture for the system and to produce a detailed design. And, finally, it is not entirely clear what kind of technical solutions will be required to represent the domain and provide the user with the functionality required. Hence, the technical design and the software techniques required to implement the system, are not entirely fixed. In such circumstances, an iterative design and development method is much more appropriate as it provides some ability to change the product mid-course in response to changes in the desired functionality or the availability of material for incorporation. In WadBOS Evolutionary prototyping could be avoided, because the technical implementation of WadBOS was carried out by means of a DSS Generator specifically designed for the development of this kind of systems (see Section 6.2). Examples were available to illustrate and discuss options relative to the functionality, interface concepts, and performance criteria of the intended system. Thus, tasks in the development cycle, which typically take a lot of effort, such as the definition of the software concepts, the requirements analysis and the design and architecture of the system, could be performed with success and much faster than what is normally the case. This also enabled to avoid the main drawback of prototyping, which is the inherent uncertainty relative to the final product: its content, look and feel, performance and the quality of its implementation. Rather we could emphasise early in the development on the core of the system and on the lower level system functions that are not easily changed by the feedback of the end-users.

5. D5. D5. D5. DEVELOPING THE MODELBEVELOPING THE MODELBEVELOPING THE MODELBEVELOPING THE MODELBASEASEASEASE The Wadden Sea is an extensively studied coastal system and an amazing amount of data, information and knowledge is available. However, this material is very diverse in nature and spread out among the very many organisations and people that are or have been involved in producing it. Developing an information system able of holding this information and making it available in a usable format is a major endeavour in need of a structured approach in phases. With the end-users the decision was taken to develop WadBOS as a series of iterative prototypes. Different from ‘throwaway’ prototypes, these evolve with the project towards the intended final product (see Section 4.2). They are fully blown products developed according to a predefined set of specifications and with particular objectives in mind. The first prototype, WadBOS-1, was mostly developed with a view to proof the feasibility of the approach and the usefulness of the system before engaging in a stepwise completion of the instrument. To that effect, the Wadden system was represented by and large, and a few human activities and ecological functions were represented in detail. In particular, recreational activities and shell mining as well as the nutrient, algae and filter feeder dynamics got a more detailed representation. The second prototype, WadBOS-2, completed the systems representation. Fishing and recreational boating got a more encompassing representation and assessment indicators at the landscape level were introduced. At the same time the toolbase was extended with additional analytic instruments. Finally, the third prototype, WadBOS-ES2, which development will start shortly, intends to improve the system with a view of its application in an environmental impact assessment and practical policy making context.

5.1 Knowledge acquis5.1 Knowledge acquis5.1 Knowledge acquis5.1 Knowledge acquisitionitionitionition In order to gather and structure the available data, the information and knowledge, techniques from both the fields of Systems Analysis and Knowledge Engineering were used. In fact these are not entirely different. Knowledge Engineering differs from Systems Analysis in that it is less research but more purpose driven ‘the development of a knowledge based system for a domain’, and that it


11

gathers primarily information from ‘experts’ (see for example: Kok et al., 1997; Firley and Hellens, 1991; Gonzalez and Dankel, 1993). For the remainder, they both envision bringing about the details of the coupled processes that structure and change systems. In fact, the developers of WadBOS organised three consecutive knowledge-acquisition sessions. During these they carried out a gradual systems analysis of the Wadden system with a view to obtain a systems model at the end of the exercise. Prior to the first sessions, a preliminary requirements analysis had been carried out focussing strongly on the use and user of the system. Next, this analysis was extended to include the contents of the knowledge base. An extensive group of potential end-users, all actively involved in policy-making, were interviewed. From these sessions answers were obtained relative to the following questions:

•= What and where are the (system) boundaries of the Wadden system? •= What knowledge should be included in WadBOS? •= What is a desirable level of detail for the system and its models? •= What is a desired level of accuracy? •= What knowledge is available, what is its relevance, and from whom or where can it be

obtained? Clearly the expectations relative to the system were diverse, but consensus grew over a representation covering the entire Wadden Sea, not the land, and including all the major human activities that take place on the water. The level of detail and accuracy expected was that of a policy model (see Section 5.2.1). Very fundamental was the appropriate representation of the processes in their complexly coupled multi-spatial and multi-temporal context. With this information, complemented with material obtained from literature research and the analysis of policy documents, an initial systems analysis was initiated: the main processes were identified and their definition in terms of measurable characteristics and state variables was carried out and an initial set of system diagrams and conceptual models were drafted. Further, and for each process considered, experts were identified. In a second knowledge acquisition round, the developers set up structured interviews with a large group of selected domain experts. Most of the work with the experts was carried out in sessions involving 2 to 4 people only. Sometimes a member of the end-user group would participate. During the interviews, visual modelling was applied and the initial system diagrams and conceptual models were discussed, corrected and completed according to the experts’ knowledge about the system as well as the interpretation of the relative importance of system components. At the end of these sessions a rather complete description of the Wadden system was available in the form of visual, qualitative models. There was a very reasonable consensus relative to this representation. Ambiguity and difference of opinion had been resolved to the degree possible in a number of consecutive visits and discussions in which conflicting views were clarified and cleared. Parallel to the qualitative representation, a number of existing and potentially usable mathematical models had been detected and evaluated for incorporation. With this material the developers began the translation of the qualitative models into a mathematical representation. To the extent possible, existing models were incorporated, adapted or rebuild for this purpose (see Section 5.2.3). However, a lot of knowledge was not available in the form of readily usable mathematical models. Thus, a considerable (mathematical) modelling effort began. The latter could fall back on large amounts of data available from many data sources. Partway this modelling phase, a third knowledge acquisition round was organised, in which the developers confronted the end-users, the domain experts, scientists, and model developers with the resulting mathematical representation of the system. These were very intense exercises in which consensus was sought relative to the representations chosen, the level of integration accomplished and the simplifications introduced. With a view to meet the general objectives of the WadBOS system, much effort went into separating the detail from the essence in the domain representations.


12

Very often this meant developing a policy model out of a research model, which is by no means a simple task (see Section 5.2.1). With the information thus obtained, the modelling phase was completed, the technical integration of models was started (see Section 5.2), and so was the technical implementation of the system (see Section 6). For the development of successive prototypes, WadBOS-2 and WadBOS-ES2, similar knowledge acquisition sessions have been and will be organised with the appropriate specialists. With the basic structure of WadBOS in operation, these become more focussed and effective to the extent that improved representations of processes can now be introduced in a time span of a few days.

5.2 Integration of Models5.2 Integration of Models5.2 Integration of Models5.2 Integration of Models Component (sub-)models are integrated in the WadBOS modelbase with a view to complete the system diagram of the integrated Wadden model and to make it operational. This is clearly a multi-criteria and multi-objective problem as issues need to be solved that deal with the end-use, scientific, and technical aspects of the integration. Although we treat these aspects separately here, it is clearly understood that this sub-division is rather artificial. •= End-use integration deals with the end-use and the end-user of the model. It seeks an answer

to the questions: what is useful to be integrated with a particular end-use in mind and what are the needs, expectations and constraints of the end-user. Coastal Zone Management problems are usually ‘complex problems’ rather than ‘complicated problems’. Although these problems touch the near complete system, they could be given an adequate answer if a limited formal description of the whole system would be available to support the search for solutions. The development of the integral WadBOS model involved foremost a simplification and aggregation effort with minimal loss of content and accuracy in order to enable policy use of models that were originally developed for research purposes.

•= Scientific integration is about what can and what cannot be integrated from a scientific point of view. It involves constraints on the type of models (for example: qualitative vs. quantitative, dynamic vs. static, equilibrium vs. non-equilibrium, etc.) on the temporal dynamics and time scales, on the spatial dynamics and spatial resolutions, on the details that matter, and on rigorous methods for aggregation and simplification. Once sub-models have been selected and integrated, a thorough analysis of the resulting product is required in order to find out whether the component models are correctly and sufficiently coupled, whether their synchronization and information passing is correctly handled, and whether the integrated model is an appropriately complete and correct representation of the real world system. Such analysis should bring about the missing elements and processes in the representation.

•= Technical integration deals with the ways in which existing models, their software representation, databases, user-interfaces, input and output devices can be coupled into a single system, running on the end-user’s computer platform. In the computer sciences, technical integration has been given a lot of attention in the last decade. It has become much easier with the venue of object-oriented frameworks and component based development methods.

5.2.1 End5.2.1 End5.2.1 End5.2.1 End----use integrationuse integrationuse integrationuse integration Models selected for integration in WadBOS are in most cases simplified versions of ‘the ultimate’ or ‘the best available’ models. In order to fit the integration scheme, and to work at the right level of abstraction, models need to be simplified and stripped of details that are not directly relevant in the process represented, the Wadden system, and/or the typical problems studied. The value of the integral model is as good as the weakest element in the web of linked sub-models. Hence, it is better to improve this weakest element rather than to add details to the other sub-models. What is needed in WadBOS are Policy models rather than Research models (Engelen et al., 2000)


13

•= Research models are strongly process oriented. Their temporal scales, their spatial scales, but also their level of complexity is determined by the characteristics of the process that is the subject of the modelling exercise. The model is mostly mono-sectorial. The model developer aims at a representation that is as accurate as possible. He uses the model to test hypotheses and push the level of understanding with an eventual aim to enable ‘prediction’. In his endeavour, he is encouraged to make use of scientifically innovative techniques and he will develop a model that is as complex as required. Often this will pose difficulties in validating the resulting model. But, in a quest for new knowledge, the development of the model is a purpose of its own right as it raises new questions that help in furthering and deepening the level of knowledge. In the process, new data needed for the model will be gathered as required from field sites or other sources. The processing speed and the interactivity of the model are not considered a criterion. Nor are the transparency of the model and its user-friendliness, as the model developer is usually the only user of the model.

•= Policy models are foremost problem oriented. The policy problems that are in need of solutions determine the time horizon of the calculations performed as well as the temporal and the spatial resolution at which processes are represented. The levels of detail, complexity and spatial resolution are most often determined by the availability of data. Policy models are only interesting because they deliver usable output. In order to achieve this, robust, extensively tested, and proven methodologies will preferentially be applied to perform the mathematical operations. The policy model might be complex, but it is kept as simple as possible. Quite often it is superficial, but addresses the problem in an integrated manner. The processing speed and the interactivity of the model are determining factors for its success, mostly so if the model is used in participatory and exploratory exercises involving policy makers and/or stakeholders. Also the transparency and the user-friendliness of the system are crucial factors. And, as the model is very much problem oriented, the involvement of the problem owner during its development is very dear.

In the selection of component sub-models for the integrated WadBOS model, the following list of key end-user requirements was taken as a guideline: (a) All processes. The WadBOS model should adequately represent all the important processes

necessary to provide the required policy outputs. (b) Scale. The WadBOS model should be spatial and operate at multiple spatial scales. It should

provide information at a sufficient level of spatial resolution to reflect the scale of variation in the most important physical, ecological and socio-economic variables. A spatial resolution also at which policy-problems occur and can be addressed in coastal zone policies.

(c) Time horizon. The WadBOS model should be dynamic and operate at time scales and temporal resolutions representing realistically the autonomous dynamics of the system modelled. A time horizon also which is relevant for policy design, implementation and assessment.

(d) Routine data. The WadBOS model should be sufficiently simple to run from routinely measured and available data. In principle, no new data are collected to run WadBOS.

(e) Output centred. The WadBOS model should be output centred. It will be judged mostly upon the quality of its output and less upon the scientific or technical innovative character of its models.

(f) Policy centred. The WadBOS model should support easy to run policy exercises that the user can be taken through. These may focus on environmental changes, anthropic impacts, and management options. WadBOS should provide appropriate results using indicators or variables that directly interface with the policy implementation process rather than more abstract scientific or technical variables;

(g) Interactive. The WadBOS model should be fast, responsive and interactive and should cater for a very short attention span. A response time of 15 minutes per simulation-run covering a period of 10 years should be aimed for. Clever models, fast algorithms, and efficient software code are required to achieve this.


14

5.2.2 Scientific integration5.2.2 Scientific integration5.2.2 Scientific integration5.2.2 Scientific integration The appropriateness of models was evaluated on the basis of the end-user requirements mentioned, but also on an informal evaluation of their conceptual, paradigmatic, spatial, dynamic, and technical characteristics. Further, a more profound scientific evaluation was carried out considering the performance of the models in terms of their capacity of generating validatable output. In the case of existing models, the DSS development team did not carry out the latter tests, rather it engaged in discussions with the developers and/or specialized users of these models to obtain the desired information (see Section 5.1). Further to this, discussions focused on the potential for simplification, aggregation, and spatialisation of the existing models. The following scientific criteria were taken into consideration for the incorporation of models: •= Models fitting the integration scheme. Only models are integrated that fulfil a specific task

within the WadBOS integration scheme not dealt with by any other (sub-)model. They compute a subset of the total state-variable set and exchange the necessary information among one another at the right temporal and spatial scales during the calculations;

•= Time scales and temporal dynamics. Only dynamic models are integrated. Models need to span a strategic time horizon (10 years) and operate at appropriate (simulation) time steps reflecting the inherent characteristics of the processes and decision-making time frame (tidal cycle, 1 month, 1 year). With a view of simplifying or aggregating the model, the effect of increasing or decreasing the time step on the performance of the model is a criterion;

•= Spatial resolution and spatial dynamics. Only spatial models or models that can be spatialised are integrated. Models are applied on the entire Wadden Sea and operate at an appropriate spatial resolution to reflect realistically the real world processes, the spatial variability across the region, and its constituent geographical entities, subject to decision and policy making (25 ha - 3000 km2). With a view of simplifying or aggregating the model, the effect of increasing or decreasing the spatial resolution on the performance of the model is a criterion;

•= Compatibility of scientific paradigms. Only models are integrated that from a scientific/opera-tional point of view can be integrated. Thus, the basic assumptions and constraints underlying the models are assessed. Most of the models selected in, or developed for, WadBOS are spatial, dynamic, non-equilibrium or quasi-equilibrium models that are solved by means of simulation. Models using both rule based and algebraic solution methods are retained;

•= Scientifically proven. The process descriptions within the WadBOS model should be well understood and scientifically proven. A well understood, proven but crude process description is preferred above an innovative but poorly documented and less proven one. The model results should be as robust, reliable and accurate as possible.

5.2.3 Straightforward integration, adaptation, rebuilding, or developing5.2.3 Straightforward integration, adaptation, rebuilding, or developing5.2.3 Straightforward integration, adaptation, rebuilding, or developing5.2.3 Straightforward integration, adaptation, rebuilding, or developing

The key trade-offs in the selection process were very much between accuracy (of outputs and of process representations) and simplicity (of models and of input data). The resulting model needed to have sufficient spatial and temporal detail and sufficient model complexity to accurately represent the processes but needed to achieve this over large areas in a fast and responsive manner with a minimum of data. From the above it will be clear that this is not automatically achieved; rather that important adaptations to the research models were required before they were effectively integrated. In this respect, WadBOS developed solutions at three levels: •= straightforward integration when the model represents the process adequately and efficiently,

and when the interactions with other component models is possible; •= existing models are adapted if only minor repairs or reformulations of the model, its algorithms

or code are required to have it perform its tasks more appropriately;


15

•= rebuilding is necessary when an existing model needs major repairs and adaptation in order for it to fit in the integration scheme.

•= finally, development of new models is considered when there are processes in the integration scheme for which models are missing.

The WadBOS model resulting from the exercise consists of sub-models running at one of three embedded spatial scales: the Wadden Sea as a whole (+/- 3000 km2), the 12 compartments within the sea (mostly delimited on the basis of the hydrodynamic characteristics of the Sea), or a regular grid consisting of +/- 11000 cells of 25 ha each (see Figure 3). As for the temporal resolution WadBOS integrates sub-models running a yearly and a monthly time step, or a time step equal to the tidal cycle. This model is sufficient to generate the output required for most relevant policy questions. It meets the performance criteria specified and performs a simulation run of 10 years in less than 10 minutes on a state of the art PC with Windows installed. And, sufficient existing GIS data are available at the 500 m grid resolution as are the statistical data required for the economic and ecological models.

Figure 3: WadBOS integrates sub-models running at one of three spatial scales

6. T6. T6. T6. TECHNICAL ECHNICAL ECHNICAL ECHNICAL IIIINTEGRATIONNTEGRATIONNTEGRATIONNTEGRATION As all of the models discussed so far are also software models, the problem of technical integration is very much a hard- and software problem: how can we efficiently link pieces of executable code so that they together perform the operations specified in the integrated model at the right time and so that data is exchanged in a way that is consistent with the temporal and spatial logic of the model? Is it possible to do this in a manner that enables reconfiguration of the model in a straightforward manner? And, can the material developed be re-used for DSS systems implemented elsewhere to address similar aspects? Two aspects are decisive to answer these questions positively: the architecture chosen for representing the modelbase and the integrated model and secondly, the software technology used to implement the DSS and its modelbase.

The whole Wadden sea

12 Compartments

11000 cells of 25 ha each


16

6.1 One of four possible architectures6.1 One of four possible architectures6.1 One of four possible architectures6.1 One of four possible architectures

As discussed extensively in this paper, one of the key factors for the success of a Decision Support System is the way in which it makes the knowledge, captured in its modelbase, available to its intended users. The choice of an appropriate architecture is decisive in this. To meet the objectives formulated by CUBWAD, four possible types of architecture could have been implemented. The four solutions differ from one another mostly in terms of:

•= Policy relevance, policy support, and technical performance; •= Development and maintenance costs; •= Technical and organizational difficulties involved with the development and use.

These characteristics are captured in 15 technical criteria used for selection and evaluation. Table 1 presents a score table showing the weak and strong points of the four solutions relative to these criteria. In Figure 4 a graphical representation of the 4 architectures is presented. For each solution, the user is represented at the left. He interacts with WadBOS via a user-interface and has access to an integrated model. The integrated model consists of different more or less strongly coupled component sub-models available from the modelbase of the DSS. On the right of each solution is shown how the sub-models are accessed and integrated more precisely.

inte

gral

polic

y-m

odel

com

plet

e

dom

ain-

spec

ific

rese

arch

-mod

elde

taile

d Access to loose & distributed models

Existing models linked in a single system

Systems model consisting in part of rebuilt models

Systems model with access to detailed models

InternetInternetInternetInternet

inte

gral

polic

y-m

odel

com

plet

e

dom

ain-

spec

ific

rese

arch

-mod

elde

taile

d Access to loose & distributed models

Existing models linked in a single system

Systems model consisting in part of rebuilt models

Systems model with access to detailed models

InternetInternetInternetInternet

Figure 4: Approaches to model integration in 4 possible DSS architectures

From an evaluation of the 4 architectures it was decided that the most suitable for WadBOS was solution 3: ‘Reformulation of the existing models into 1 systems model’, or 4: ‘Systems model with access to detailed sub-models’. As a matter of facts, the former was selected to implement WadBOS-1, while more recent versions of WadBOS have evolved towards the latter.


17

Table 1: Four architectures evaluated against 15 criteria on a 4-point scale (-- worst to ++ best)

Criterion Distributed models

Models (weakly

integrated)

Systems model

Systems model with

Detail

Abstraction level -- - + ++ Accurateness ++ + - + Collaboration + ++ - + Completeness ++ + - + Development cost ++ + - -- Explorative learning -- - ++ + Flexibility ++ + - + Implementation effort ++ + - -- Integration - + ++ ++ Interactivity -- - ++ + Maintenance cost ++ + - -- Performance -- + ++ ++ Policy relevance -- - ++ + Transparency -- - ++ + User friendliness -- + ++ ++ Short definitions: Abstraction level The level of detail with which the system represents the decision domain. Accurateness The quality of the output generated by the system. The loss of information relative to

the original process modelled. Collaboration The potential for the distributed development, maintenance, and use of the system. Completeness The share of relevant domain processes represented by the system at a sufficient level

of detail. Development cost The costs involved with building the final version of the system. Explorative learning The ease with which the user can explore and learn about a subject by means of the

system. Flexibility The ease with which the system can be adapted or changed for tackling new

problems. Implementation effort The level of technical difficulty involved with building the system. Integration The level of model and tool integration attained in the system. Interactivity The share of functions that can be accessed in an interactive session with the system. Maintenance cost The costs involved with maintaining and upgrading the system. Performance The speed with which the system, its models and tools generate output immediately

relevant to the end-user. Policy relevance The level of immediate support for the policy end-user provided by the system. Transparency The tractability of the results generated and the tasks carried out by the system User friendliness The ease with which the system can be used by its intended end-user.

Access to loose and distributed models or models coupled into Access to loose and distributed models or models coupled into Access to loose and distributed models or models coupled into Access to loose and distributed models or models coupled into a single system.a single system.a single system.a single system.

In solution 1: ‘Access to loose and distributed models’ the integration of the models is kept weak. Most are made available to the end-user in their near to original form. Only the most essential adaptations are carried out for making them more useful in the context of the DSS. The models generally reside on the computer of the model owner together with the data to run them. Thus their maintenance and management remains with the owners and original developers. The DSS will access the sub-model either via a direct network connection, or via the owner as an intermediary. In the latter case, the usage will always be asynchronous: rather than running the model directly, the owner is requested to run his model on his machine and return the results to the DSS to enable a continuation of the analysis.


18

Solution 2: ‘Access to models linked into a single system’ is user-friendlier than the previous one. The integrated model consists of more tightly coupled sub-models residing on the machine of the end-user. Thus, the resulting DSS is much better equipped for explorative use and learning purposes. At the same time it supports rather technical usage too, because the constituent models will usually be moderately changed versions of the originals. The performance of this system is overall better, but it is more expensive to develop and maintain than solution 1. Both solutions lack user-friendliness. In the worst case (solution 1), they require complicated procedures to do even the simplest things. Their performance is not good, in that it might take a long time to obtain model output (solution 1). And, the level of complexity attained depends very much on the technical implementation of the original models. Consequently, these solutions are more suitable for chain-like linked models and much less for simultaneously solved models. They have some advantages too. Providing that a sufficient set of procedures and protocols is adhered to, distributed development is possible. Thus, the development and maintenance costs are kept low, and the models are updated by their owners, hence by those knowledgeable about the domain and its model representation. These solutions are to be selected if access to very complicated models is required, e.g. models that would not run easily on the platform of the end-user. Models too, requiring special or large data sets or used for technical tasks and not so much for policy exploration or learning purposes. For WadBOS the solution was rejected because the modelbase available for the Wadden system was too fragmented and the available models were mostly incompatible for this kind of coupling (solution 2). And above all, the DSS that would result from either of these solutions would be too cumbersome for the intended use and users. The latter is more so for solution 1 than solution 2. In summary:

•= Medium development and maintenance costs •= User-friendliness low to medium •= Distributed architecture supports distributed development and maintenance •= Weak level of integration, possibly even asynchronous (solution 1) •= Internet based client-server implementation is possible

Systems model consisting in part of rebuilt modelsSystems model consisting in part of rebuilt modelsSystems model consisting in part of rebuilt modelsSystems model consisting in part of rebuilt models

The core element in this third architecture is an integrated model fully tailored to the precise role of the DSS and the needs of the end-user. Hence, a clear problem definition, an in depth user requirements analysis and a precise user profile are essential elements to decide on the exact depth and the extent of the integrated model and its constituent sub-models. More than in the solutions 1 and 2, this integrated model is very strongly coupled. It is a truly complex model. It is so by design, and, as each of the sub-models is adapted and (re-)implemented for this purpose it is also materialized technically. Once realized, this system is user-friendly and, it usually will have a good performance. More than in the previous two cases, the system will represent all relevant processes at the same level of abstraction and detail, which will not necessarily produce the most detailed or most accurate output possible. Because of the effort spent in the design and (re-)implementation it is a medium to high cost solution. With a view to keep the maintenance costs low, it is advisable to choose an object-oriented or component-based technology to implement the solution. If not, maintenance costs can be very high, certainly if the end-user requirements change and/or if the model representation needs major repair and upgrading. The development and maintenance of this system can best be kept in the hands of a relatively small group of modellers and system developers. As the near complete model is implemented anew there is no essential need for, or advantage from, using distributed development.


19

This solution was chosen for WadBOS-1, mostly because it enables the development of a well-balanced, transparent system with the best computational performance. Thus, it is the best solution for high-level policy makers involved in explorative integrated assessment exercises. For the same reasons this solution supports explorative learning very well. WadBOS is implemented with an object oriented application framework, enabling re-use and flexible upgrading (see Section 6.2). In summary:

•= Medium to high development and maintenance costs •= User-friendliness is high •= High end-user participation and involvement during development phase •= Highly interactive and transparent system •= Highly integrated DSS for policy support •= Policy-model developed from adapted or rebuilt research models •= Knowledge acquisition phase to fill gaps (missing links) with newly developed models •= Standalone application with high computational performance

Single systems model with access to original modelsSingle systems model with access to original modelsSingle systems model with access to original modelsSingle systems model with access to original models

One of the disadvantages of the previous solution is the fact that the integrated model lacks the accuracy to perform detailed calculations on what are considered to be less important components of the real world system represented. It would for example be very difficult to include the detailed dynamics of a minor bird species, inhabiting a small area, in an integrated model covering the complete Wadden Sea. This level of detail would be difficult to attain because in the context of the integrated model it is considered irrelevant and/or for most of the Sea the data required would not be available. The policy maker might not find this a problem, but an analyst using the system might rightfully have a different view on this. As a solution to this problem, the architecture of solution 4 represents the Wadden system by means of an integrated model as explained in solution 3, but permits in addition to this access to the more precise, original models for a reduced set of processes. The latter models can be run on particular relevant spots for which the data are available. Moreover, the output of the detailed models could be exchanged with the integrated model, and visa versa, thus permitting a more complete analysis of a problem. This architecture combines the advantages of the second and the third solution. It is not to wonder that it is also the most expensive of all, both in terms of development and maintenance costs. But it has major advantages also. It is a user-friendly solution, as it provides maximum accuracy, completeness, interactivity, and flexibility. Its policy relevance is high, without hampering the analytical user to exploit the system effectively. Gradually, this solution has been adopted for WadBOS, starting with the version 2. This is mostly so because some of the policy questions addressed by the system need a more detailed representation in space and time but do not cover the entire Wadden Sea. In particular the environmental impact assessment of a brackish water ecosystem near the Afsluitdijk, the 30 kilometre long dike separating the Wadden Sea from the IJsselmeer, requires the kind of extensions discussed and so does the analysis of the detailed impacts caused by individual recreational boaters touring the sea. In summary:

•= High development and maintenance costs •= User-friendliness is maximal •= End-user involvement in development is maximalVarious spatial and temporal scales and

levels of detail can be accommodated more easily •= Standalone or distributed system •= Policy-model developed from adapted research models supplemented with full-size

research models •= Knowledge acquisition phase to fill gaps (missing links) with newly developed models


20

6.2 The Geonamica® DSS Generator6.2 The Geonamica® DSS Generator6.2 The Geonamica® DSS Generator6.2 The Geonamica® DSS Generator For the technical implementation, or software coding, of a Decision Support Systems the developer has essentially three types of products to choose from: a standard programming language, a DSS Generator or a DSS specific application. Standard software languages do not need further elaboration. They are any of the state of the art general-purpose software programming languages such as: C++, Java, Delphi, or Basic. They provide maximum flexibility, but are very low-level and difficult to master. To apply them for the development of a fair size, state of the art DSS will take a very substantial investment in time and human resources. More attuned to the specific purpose are the so-called DSS-Generators. A DSS Generator is not ‘somebody generating a DSS’, rather it is a term defined by Sprague and Carlson (1982) as ‘a package of hardware/software which provides a set of capabilities to build specific DSS[s] quickly and easily’. Hence, this refers mostly to a special purpose software environment for the creation of new DSS applications in a more or less narrowly defined domain. In the business context, Microsoft Excel is often referred to as a DSS-Generator, because it is equipped with a standard set of functions and tools that are typically wanted in business oriented DSS applications. Finally, a DSS can also be developed on the basis of a DSS specific application. The latter are off-the shelf applications that are instrumental for the implementation of narrowly defined, standard problems. They come in a ready to use form, ready to be completed, possibly by the end-user proper, with the data and the specifics of a problem and the problem owner. Today, Decision Support Systems like WadBOS are still far too unique and too sophisticated to be built by means of DSS specific applications. There are simply none available as yet. What is left are DSS-Generators and general purpose programming languages. For the technical implementation of WadBOS, the DSS-Generators GEONAMICA® has been used. GEONAMICA® is an object-oriented application framework, developed by RIKS bv for use by DSS developers. It is specially tailored for developing Spatial Decision Support Systems featuring models that run at multiple spatial and temporal resolutions. Typically it will combine system dynamics models and cellular models for this purpose. In particular use is made of spatial interaction based models, different kinds of cellular automata models, multi agent or other kinds of rule-based models. It is equipped with highly efficient computational techniques and algorithms for addressing spatial problems, but also with additional analytical tools, visualization tools, and input, import, export and output tools. It is equipped with a number of tools for interactive map manipulations, in particular: map editors and display tools for 1-D network and 2-D map objects, map comparison, and overlay-analysis.

6.2.1 An 6.2.1 An 6.2.1 An 6.2.1 An application framework to implement WadBOSapplication framework to implement WadBOSapplication framework to implement WadBOSapplication framework to implement WadBOS The development of a Decision Support System with the level of sophistication attained in WadBOS is a long-term project and a relatively expensive endeavour. However, providing that the right technical choices have been made from the beginning, the development, the maintenance and upgrading of the DSS, and its transfer to a similar coastal zone can be kept within very reasonable limits. To our knowledge the best state of the art software engineering method to achieve this goal is component-based development (CBD). The basic idea of Component Based Development is old, simple and powerful: to build a complex whole, try to assemble it from less complex parts, which you might already have available. CBD enables software engineers to build complex systems in a way that is very similar to how their hardware colleagues design new cars or computer motherboards: by assembling compatible parts. To be able to assemble something useful from parts, the parts need to fit together. This is where interfaces come into play. Interfaces are everything to components, because it is their only way to communicate among one another (Rogerson, 1997). They can be seen as a specification or contract to which parts must adhere to be compatible with each other. In the past decade standards for


21

components and interfaces have come about that enable assembling components written in different programming languages and on different hardware platforms into a single software system that are totally transparent to the end-user (for more on CBD see for example: D’Souza and Cameron-Wills, 1999). Application frameworks are built upon object / component technology and go even further in achieving reusability. While component libraries could be described as providing ‘bottom-up’ reuse, object-oriented application frameworks provide ‘top-down’ reuse. For example an object-oriented application framework for the development of Integrated Coastal Zone Management- DSS[s] would provide a generic application template for this type of DSS. It provides interfaces and extension points for the developer to ‘fill-in’ the application specific models, tools and data. It therefore allows saving substantial development costs to extend an existing application or develop a similar application for another coastal area. Object-Oriented application frameworks can be classified by their scope and by the techniques they offer for extension (Fayad et al., 1999). As far as scope is concerned, GEONAMICA® is an example of an enterprise application framework for DSS[s] in the broad domain of ‘Complex Spatial Planning and Policy Problems’. GEONAMICA® also has some features of a middleware integration framework in the sense that it supports the integration of external models with component technology, more in particular COM/ActiveX. Relative to the extension technique, GEONAMICA® is a White-box framework as it relies heavily on Object-Oriented language features like inheritance, dynamic binding, and templates (C++) in order to achieve extensibility (Gamma et al., 1995). Existing functionality is reused and extended by (1) inheriting from framework base classes and (2) overriding pre-defined hook methods and using patterns like the Template Method. White-box frameworks are much more widely used than black-box frameworks. This is partly because they are conceptually easier to develop and partly because (programming language independent) interface description languages have only recently become available to the software engineering community. White-box frameworks require the application developer to have deep knowledge about their internal structure, especially the inheritance relationships. In contrast, reuse in black-box frameworks is more flexible as it is realized by composing new objects from predefined framework components and by implementing framework defined interfaces in application objects.

6.2.2 Model building Blocks in GEONAMICA6.2.2 Model building Blocks in GEONAMICA6.2.2 Model building Blocks in GEONAMICA6.2.2 Model building Blocks in GEONAMICA The cornerstone of the GEONAMICA® application framework is the way in which it enables the DSS-developer to set up a new modelbase consisting of a set of exchangeable and interchangeable Model Building Blocks (MBB) that can be entered, exchanged, re-arranged and re-used in the modelbase of the DSS nearly as easily as Lego building blocks. The concept of MBB is not new or unique to GEONAMICA®; rather it has been implemented in different forms as part of many simulation and modelling frameworks. A Model Building Block represents a part of a model: an action or process. Hence, it is a more or less complete model varying from a simple mathematical operator to complete model consisting of coupled mathematical equations performing large numbers of sophisticated calculations. MBB[s] may simply represent sources of information (i.e. entered from file), while others will transform information as it passes through them, and still others will simply communicate, in a synthetic manner, the outputs of the model to the user. Despite the fact that all these MBB[s] play different roles in the model, in Object-oriented jargon, they are all ‘specializations’ of the same ‘abstraction’, which is essentially a MBB capable of exchanging and transforming information. Each MBB has two graphical representations:

(1) A rectangle (or box). A unique graphical object in the interface of the integrated model that shows how the MBB relates and is connected to other MBB[s] in the integrated model


22

(see Figure 5). A user can know from this connection scheme where the MBB gets its input(s) from, and where it sends its output(s);

Figure 5: A Model Building Block is represented in the connection scheme of the integrated model by means of a rectangle. Arrows connecting the boxes show the flow of data

(2) Its user interface (UI), which presents itself as a dialog window. The user interface gives the user read/write access to all the MBB specific parameters as well as the initial (input) values of its state variables. While a simulation is running, it enables read-only access to all the updated values of output variables. Entering data in dialogs is done in a manner which will support and protect the user to some extent, because each edit box in a dialog window knows what type of data it should get from the user: a single number, a vector of numbers, a matrix, or a table (i.e. time series). For each type the appropriate editor is opened when the user clicks in the edit box.

Each MBB has its Documentation page in the Documentation system. It is accessible when the dialog window of the MBB is opened (by pressing the F1-key or clicking in the dialog window by means of the Context Sensitive Help cursor). This Documentation page gives technical information about the MBB and may include the mathematical expression, scientific references, the specification of the input and outputs, etc. The MBB manages the memory for its parameters and its outputs. An advantage of this design is that it makes the MBB[s] self-contained and independent. The inputs of a MBB are pointers to the memory location where the required output is residing. As an output X is always managed by the MBB producing that output X, the input is pointing to a memory location managed by the MBB producing the output X. A MBB does not know what MBB it receives input from. It is the responsibility of the simulation engine to connect the inputs of the receiving MBB to the outputs of the producing MBB while executing an integrated model. The Step function of the MBB contains the software code that implements the mathematical model of the MBB. It specifies how each of the outputs of the MBB changes depending on the time, the current input values, and the current parameter values. Each MBB runs at its own pace. In WadBOS this is once per tidal cycle, monthly or yearly. The Step function of the MBB is called by the simulation engine, it is executed, and the MBB tells the simulation engine when it should be called again. The MBB does not know about other MBB[s] as they are kept as independent of one another as possible. It is the responsibility of the simulation engine to keep all the MBB[s] synchronized in time. Libraries are repositories of MBB[s]. The entire definition of the MBB (its code, its graphical representation, its dialog, its connectors) is stored in the MBB Library. When a MBB is included in a model, the block itself is not copied to the model; rather a reference to the block in the library is made. MBB[s] can be reused in the same model more than once. For example the MBB calculating turnover in the mussel fishery is also used for calculating turnover in the cockle fishery. But, MBB[s] and Libraries can be re-used in other applications equally well. The factual re-

Model Building Block

In-Connector

Out-Connector

Connection


23

usability will depend largely on the process modelled and the level of generic applicability attained in the implementation.

Cellular automataIntensityStressImpactLandscapeSuitabilityEtc …

ExitOpen/CloseSaveStep/RunPauseAnimateLogLinkEtc …

GEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exe

UI Engine

Simulation engine

Cellular spatial models

UI Spatial models

WadBOS WadBOS WadBOS WadBOS WadBOS WadBOS WadBOS WadBOS model.model.model.model.model.model.model.model.dlldlldlldlldlldlldlldll

Controller

Model UI

Integrated model

Adaptor MBB

MBB

MBB

Adaptor UI

UI

UI

Legacy software model

ActiveXComponent

+ UI

ActiveXModel WrapperComponent + UI

View gridShading3D viewRoadsCompartmentsFeaturesEtc …

GEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development Kit

WadBOSWadBOSWadBOSWadBOSWadBOSWadBOSWadBOSWadBOS LibraryLibraryLibraryLibraryLibraryLibraryLibraryLibrary

Cellular automataIntensityStressImpactLandscapeSuitabilityEtc …

ExitOpen/CloseSaveStep/RunPauseAnimateLogLinkEtc …

GEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exeGEONAMICA.exe

UI Engine

Simulation engine

Cellular spatial models

UI Spatial models

WadBOS WadBOS WadBOS WadBOS WadBOS WadBOS WadBOS WadBOS model.model.model.model.model.model.model.model.dlldlldlldlldlldlldlldll

Controller

Model UI

Integrated model

Adaptor MBB

MBB

MBB

Adaptor UI

UI

UI

Legacy software model

ActiveXComponent

+ UI

ActiveXModel WrapperComponent + UI

View gridShading3D viewRoadsCompartmentsFeaturesEtc …

GEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development KitGEONAMICA Software Development Kit

WadBOSWadBOSWadBOSWadBOSWadBOSWadBOSWadBOSWadBOS LibraryLibraryLibraryLibraryLibraryLibraryLibraryLibrary

Figure 6: Inside GEONAMICA

The GEONAMICA SDK (Software Development Kit) provides all the templates required to start a new application and a new library (see Figure 6). Building an application, or to put it in other word, creating a modelbase and connecting the MBB[s] into an integrated model, is enabled by means of a piece of application specific software specifying which MBB[s] are part of the application, and how they are interconnected (which inputs are connected to which outputs). This application is the so-called model.dll. The model.dll for WadBOS is called WadbosModel.dll. Not all models have to be available as MBB[s] within the library in order to be integrated into an application. An external (existing) software model can become part of a GEONAMICA application via an adaptor MBB. This is done by means of an ActiveX�Model Wrapper Component, which wraps the external model into a piece of software so that it looks from the outside like a GEONAMICA MBB, and thus can function within a model like all the other MBB[s]. The ActiveX�Model Wrapper Component delegates most of the work to the actual external model, but performs some missing functionality, such as displaying and effecting the user interface or the conversion of data between the GEONAMICA framework and the external model. If the external model is developed according to the specifications of the COM/ActiveX component technology, hence is an ActiveX Model Component equipped with all the necessary interfaces, then, a specific Adaptor MBB can integrate it directly into the application. For example the Policy Wizard application, discussed in Section 10, is integrated into GEONAMICA as an ActiveX Component. The user interface of an application consists of a number of system diagrams with sensitive areas (see figures in sections 7 and 10). The diagrams are graphical representations of the application. The MBB[s], represented by rectangles are the sensitive areas. They are connected to either more specific diagrams, representing the MBB at a deeper level of detail (when the sensitive area is connected to a SuperMBB), or to the user interface (the dialog) of the MBB (when the sensitive area is directly connected to a single MBB). The user can navigate through the system diagram hierarchy by clicking the sensitive areas.


24

GEONAMICA.exe is the piece of software capable of loading a specific application and thus launching the Decision Support System. GEONAMICA.exe is a generic executable, and the integrated model is a project-specific model.dll. GEONAMICA.exe features also a set of cellular spatial models. They perform operations on a grid representation of the region modelled. The most powerful of these are Cellular Automata models of the kind developed by White, Engelen and Uljee (see for example: White and Engelen, 1994, 1997; White et al. 1997; Engelen et al. 1993, 1995, 1996, 1999a), but all kind of other spatial modelling algorithms are included as well. In WadBOS for example they are invoked to calculate among others: Intensity of activities, Stress caused by activities, Disturbance of species, Wadden-Landscape calculations, Appreciation of the Wadden sea, potential distribution of Species, etc. GEONAMICA.exe will also launch the toolbase and the databases of the application. While an application is running, the tools are automatically invoked as the result of user actions, or they can be purposely selected from the menu system of the DSS. Pre-processing and post-processing tools such as OVERLAY.exe and ANALYSE.exe are available as separate applications that are launched independently of GEONAMICA.exe.

7. T7. T7. T7. THE HE HE HE IIIINTEGRATED NTEGRATED NTEGRATED NTEGRATED WWWWADADADADBOS BOS BOS BOS MODELMODELMODELMODEL In its version 2, the Integrated WadBOS model has the following main characteristics:

1. It represents strongly coupled social, economic, ecological, biological, physical and chemical processes (see Figure 7). They are grouped into three main sub-models: the Economy (Economie), the Ecology (Ecologie) and Landscape.

2. It integrates models that run at 3 spatial scales: a. the Wadden Sea as a whole, b. 12 compartments of the Sea, and c. a cellular representation of the Sea: some 11.000 cells of 25 ha each.

3. It integrates models that run at one of three possible time steps: a. one tidal cycle; b. one month; c. one year.

4. It typically performs a run of 10 years and shows its outputs every month. The tidal cycle outputs are integrated over the month.

As a general rule all combinations of the above are present in the model. However, most economic processes run on a monthly or yearly time step, while most of the ecological processes are represented at the compartment level and run on a tidal cycle time step. Figure 7 shows the system diagram of the integrated model at the highest level of abstraction. As explained in sections 6.2.2 and 10, this diagram is also the user interface of the model. The boxes (the MBB[s]) represent sub-models and the arrows between the boxes show the main data flows in the model. When a box is clicked, the details of the underlying model are shown, which is either a new system diagram of the sub-model, or a dialog window relative to that sub-model.


25

Figure 7: System diagram of the Integrated WadBOS model at the highest hierarchical level of the user interface. The little red circles and squares shown at the in- and out connectors of the MBB[s] are linkages with MBB[s] shown in the other views of the model: Scenario’s, Policy Options and Impacts (see Section 10).

Economic subEconomic subEconomic subEconomic sub----modelmodelmodelmodel

In the economic sub-model (see Figure 7), all the major economic activities present in the Wadden Sea are represented at some level of detail. Shell mining (Schelpenwinning), Fishing (Visserij), and Recreation (Recreatie) have been worked out in more detail. Most activities carried out at sea are an input into the local Industry (Industrie) and cause directly or indirectly the need for Transportation of Good and People (Goederen & personenvaart). Shell mining, and Fishing directly extract biological resources from the Wadden Sea, while Recreation, Electricity generation (Electriciteit) and Military activities (Defensie) use the open space as their prime resource. Finally, Gas extraction (Gaswinning) taps underground resources and may thus have an impact on the Morphology (Morfologie) of the seafloor. The presence and the noise generated by nearly all activities has its effects on the Landscape (Landschap): the ecological state, the species present and the attractivity to humans. And, each kind of activity causes some form of Emission (Emissie) of pollutants into the waters. Each of the economic sub-models is developed according to the same general modelling scheme, represented in Figure 8. This increases greatly the consistency, the learnability, and the transparency of WadBOS. The scheme is derived from the existing Platvis economic fishery model (Salz, 1994). It calculates through a series of interlinked relations on a monthly basis. The following is one way of reasoning through these loops. The Effort (Inspanning) of an economic activity is determined by the available Infrastructure (Infrastuctuur). Infrastructure for fishery, for example, is the amount of fishing equipment available on board of vessels expressed in horsepower. Infrastructure for hotels and other recreational facilities is the number of beds available. In order to operate the Infrastructure, a workforce is required. This determines the Employment (Werkgelegenheid) in the sector. The deployment of Effort and the availability of clients (in the recreation sector), or biomass as calculated in the Ecology sub-system (in the fishery sector), determine the extent of the Extraction: Catch (Vangst) for the fishery sector and number of Recreants present in the area for the recreation sector. At a fixed price, the Catch generates a particular Turnover (Omzet). In WadBOS prices are externally determined constants. They are


26

part of economic scenarios that can be tried out with the system. On the basis of the infrastructure, debits are calculated, from employment labour costs and from turnover technical costs. These are deducted from the Turnover and thus Value added (Toegevoegde waarde) is calculated. If the latter is positive, Investments may be made to increase the Infrastructure. Policies can intervene directly and set a Maximum limit on infrastructure (Beleid infrastructuur) allowed, or indirectly through Taxes and Subsidies (Heffingen & Subsidies). Another way of intervening into an economic sector is by setting Quota (Quotum). These will possibly reduce the Catch and will prevent the exhaustion of the species or other resources (i.e. shells). In the above discussion, the example is given of the Mussel fishery, but the scheme of relations can be applied to all sectors with minor adaptations in the concepts and their definitions.

Figure 8: The model of an economic sector in WadBOS. The Mussel fishery is used as an example. The boxes in grey are MBB[s] that are part of sub-models different from the one represented.

The above relations are calculated for the entire Wadden Sea or per compartment (i.e. Quota can be set per compartment). Next to these there are calculations relative to the precise location of the activity at the level of the 25 ha cells. This is because the Effort is not equally distributed over the entire Sea. It is particularly the cell’s Suitability (Geschiktheid) for an activity that determines where the Intensity (Intensiteit) of an activity is high or low. So does the availability of the resource --Mussels (Mosselen) in the above example-- fished or mined. However, the distribution of activities can be controlled through Zoning-policies by closing areas (Sluiten gebied) permanently or for particular periods during the year. The latter is an important policy lever, because a high intensity may cause Disturbance of particular species of bird or sea animals in locally and add to specific forms of Pressure (Belasting). Each activity contributes to one or more of the 3 types of Pressure: presence and noise, mechanical influence, and extraction. Presence and intensity of the activity will also have an effect on the assessment of the natural state (Natuurwaardering) of the Sea. All variables calculated at the cellular level are available as dynamic maps, updated on a monthly basis. Thus maps can be consulted for: Intensity for each activity, the 3 types of Pressure, and 11 forms of Disturbance (a combination of an activity causing the disturbance, a species being affected, and a particular kind of disturbance, such as noise or presence). For each activity the Suitability map is a composite measure calculated on the basis of physical, environmental and infrastructure elements characterising each cell. Similarly, for each activity there is a Zoning map calculated from different factors characterising the institutional and legal status of each cell in the Sea. The Suitability will express the extent to which a cell is appropriate for carrying out the activity, while the zoning map will indicate whether or when the activity can be


27

carried out in the cell. Both maps can be edited in the system thus enabling the user to define different kinds of spatial policy measures.

LandscapeLandscapeLandscapeLandscape

The economic activities will have their effects on the pristine character and landscape of the Sea. These too are localised effects that are calculated in WadBOS at the cellular level and on a monthly basis. An assessment in ecological terms is calculated, based on the Ecotope (Ecotopen) present in each cell and on the potential biodiversity of that ecotope. This assessment is done with and without the effect of economic Activities (Activiteiten) and Cultural elements (Cultuurelementen) that are present in the landscape (partly land based), which enables a straightforward visualisation of the human impact. On the basis of the same information, patches of contiguous Landscape types (Landschap) are calculated, varying from ‘nearly natural’ to ‘entirely human’. The size and ecological characteristics of the patch will determine what kind of Species (Soorten) potentially could populate a patch in a sustained manner. Finally the Wadden Sea is assessed relative to the way it is perceived (Belevingswaarde) by humans as ‘typical’. This too is done with and without human elements. The different characteristics mentioned: Ecological assessment, Perception, Landscape types, and potential Species is presented as dynamic maps on a monthly basis. For most of the assessment calculations there are no ‘hard scientific facts’ to build into the model, rather expert judgements and best estimates are used. Even then, the sequence of monthly maps demonstrate in a very interesting manner how the Sea looses a lot of its ecological value and its attractivity for humans during the summer when human activity booms. During winter however, the Sea returns to a much more natural state.

Figure 9: The Landscape sub-model

Ecological subEcological subEcological subEcological sub----systemsystemsystemsystem

Where activities are carried out some form of pollution will be generated and particular Emissions (Emissie) (copper, TBT, PAK, and Oil) will end up in the water (see Figure 7). River borne pollutants will enter the Sea mainly from the IJsselmeer and the Eems river. A simple hydrodynamic model (Morfologie & Waterbeweging) calculates how the water moves from one compartment to the next to eventually end up in the North Sea. Not only pollutants will move with the water, but so will other dissolved matter Detritus and Nutrients (Detritus & Nutrienten) including phosphates, silicon and nitrogen. In a food chain model derived from the EcoWasp model (Brinkman, 1993) the Nutrients serve as an input to the Algae (Algen) dynamics. Simply stated, the growth of the latter is determined by the availability of nutrients, the right climatic conditions, light, or influx from the North Sea and sweet water systems. They are grazed by Filter feeders, including the commercial species Cockles and Mussels (Kokkels & Mosselen). The latter are prey for Birds (Vogels) and the Fishery (Visserij). More precisely, the policy makers will decide every year on how much are needed as food for birds and for the survival of the species. The rest can be fished commercially. Cockles are fished and cooked at sea and their shells are returned into the Sea. Thus they become a resource for the Shell mining industry (Schelpenwinning). The food chain dynamics are calculated on a tidal cycle time step and mostly on the spatial level of the compartments. Some information, such as the mussel and cockle biomass


28

and the consumption rates of birds is calculated on the cellular level. The latter serves as a cellular input into the fishing activity. This description is kept very superficial. The interested reader can get more ample and more exact descriptions of the models used in the on-line documentation of the WadBOS DSS itself, or in the technical reports written (Huizing et al., 1998 and Engelen et al., 1999b). From this description however it should be clear how the different sub-models are linked to each other in a network of mutual, reciprocal influence. It should be clear too, that the outputs are visualised by means of a large number of dynamic maps, each of which is updated at every time step during the simulation. Outputs are also presented in the form of text, MS Excel tables and time graphs. Dynamic maps generated during a simulation can be stored on file for interactive comparison and further analysis by means of the ANALYSE-Tool. The input maps can be prepared in a commercial GIS package and imported into WadBOS. Once imported, each input map can be edited by means of an appropriate editor. Thus, spatial policy measures can be localised and tried out. The interactive generation of the Zoning and Suitability maps is supported by means of the OVERLAY-Tool. OVERLAY and ANALYSE, and many other similar instruments are part of the Toolbase of WadBOS. This is the subject of the next section.

8. T8. T8. T8. TOOL INTEGRATIONOOL INTEGRATIONOOL INTEGRATIONOOL INTEGRATION Modelbases featuring integrated models are very essential in any DSS, however models only are not sufficient. Rather the DSS should stimulate and facilitate the explorative learning behaviour of the decision maker, because better informed policy makers are better equipped to make better policies which bring the systems that they are to manage on a better path towards sustainability. Thus, the prime role of the models and the Decision Support Systems is awareness raising, understanding and education, rather than the decision-making act itself. In the DSS, it is the role of the models to present an adequate and truthful representation of the real world system, and it is the role of the tools to enable the decision maker to work with the models. They enable to invoke the appropriate models, to prepare the input of the analysis, to generate decision alternatives, and to compare and evaluate the outcomes of the different alternatives generated. However, the toolbase is the component that usually gets the least attention in the DSS. Many authors will either consider it to be an integral part of the user interface, while others will consider it to be part of the modelbase. Both views in our opinion are wrong and tools should be treated with particular attention because they decide to a large extent on the usability, effectiveness, and the user-friendliness of the DSS. In a well-designed DSS the tools are the gnomes that carry out the many technical tasks, small or large, in the background of the system. The user will hardly be aware of the fact that he is using a tool when he is editing a parameter and a map or view a variable graphed against time. Without tools, the most sophisticated model is nothing but a number-cruncher, running out of control and drowning its user in a lake of figures. Tools are among the most robust elements in a DSS and can be re-used easily in new applications combined with vastly different modelbases and accessed by different types of user interfaces. We will not dwell extensively on the specifications of the many tools built into WadBOS. The interested user is referred to the User Manual (Uljee et al., 2000) and reports (Huizing et al., 1998 and Engelen et al., 1999b). Most of the tools are standard in the GEONAMICA® DSS Generator, hence were readily available for integration into WadBOS. Some have been developed purposely, and because of their generic nature have since enriched GEONAMICA®. In this overview the tools are ordered relative to the type of task they carry out in WadBOS, and distinguished between Input tools, Output tools, Exploration tools, and Evaluation Tools.


29

Table 2: Tools available in WadBOS and their usefulness in relation to the functions of WadBOS (on a scale from + to ++++)

Tools Analysis Communication Learning Library

Input tools text editor ++ + +++ +++ value editor +++ + +++ +++ series editor +++ + +++ +++ table editor +++ ++ +++ +++ function editor ++ + + +++ network (points and lines) editor (*) ++++ ++ ++++ +++ 2D map editor ++++ ++ ++++ +++ Open / close files ++++ ++ ++++ ++ Import / export files ++++ ++ +++ + Output tools on-line documentation ++++ +++ ++++ ++++ on-line help ++ ++ ++++ ++++ time graphs ++++ + ++++ + dynamic maps (2D) ++++ ++ ++++ + dynamic maps (network) (*) ++++ ++ ++++ + 3D representation ++ +++ +++ + Animation tool (*) ++ ++++ +++ + tracing tool +++ ++ +++ + Link to Excel ++++ + +++ + Log to file ++++ ++ +++ + Exploration tools POLICY-wizard + ++++ +++ + OVERLAY-Tool ++++ +++ +++ + ANALYSE-Tool ++++ +++ +++ + SCENARIO-Tool(*) ++ ++++ ++ + MONTE CARLO-Tool(*) +++ ++ +++ + Evaluation tools SCORE-Table-Tool ++++ ++++ ++++ + EVALUATE-Tool (MCA)(**) +++ ++++ ++++ + Optimization (**) ++ + + + Goal seeking +++ + + + (*) available in GEONAMICA, to be implemented in the next version of WadBOS (**) not as yet available in GEONAMICA, but very much wanted in WadBOS •= Among the Input tools there are the typical editors for changing single numbers, or series of

numbers in a textual or graphical manner. As part of the latter, the table editor, which enables entering 2-D relations as a curve, and the map editors are very essential and powerful instruments in WadBOS. But so are the tools to open, close, import, and export files, scenarios and policy exercises.

•= The Output tools fulfil the difficult task of presenting the massive amounts of data generated interactively and in as concise and precise a manner as possible. For presenting dynamic spatial data interactively, fast dynamic mapping facilities are available. For storing simulation results and enabling in depth analysis of simulation results at a later stage, WadBOS features map recorders and players of (map)animations, as well as tools for storing dynamic map output in so-called .LOG files, and tools to write results in a linked MS Excel spreadsheet.


30

•= Exploration tools enable the user to interactively search the solution space. The capacity to generate scenarios, produce map overlays interactively, compare maps interactively, and carry out sensitivity analysis puts great analytical power in the hands of the end-user.

•= Evaluation tools help the user to decide on a ‘best’ solution. Techniques such as Multi Criteria Analysis, Score Tables and the like are needed. WadBOS features the latter, and will be equipped with a Multi Criteria Analysis instrument in its next version. A built-in Goal Seeking feature presents, on the basis of a sensitivity analysis, the dependency of state variables on policy relevant parameters in the integrated model. Thus, the risk can be avoided that the ‘best’ solution is never attained when series of ‘what-if’ analyses are carried out.

Not all the tools in the WadBOS have the same importance for all its users. According to the function the system is to carry out (see Section 2) they play a more or less pronounced role. In Table 2 we value the importance of the tools relative to the potential uses or functions of the Decision Support System. From this table it is clear that the analyst uses the near complete set extensively. He needs both the very down to earth instruments for entering data, and reading input files as well as the sophisticated instruments for analysing output. When the main purpose of the DSS is communication, pertinent output instruments are very essential. The learner needs a bit of everything, his usage of the system is not fundamentally different from that of the analyst, but he will be foremost interested in transparent input and output tools and the documentation systems. Finally for the library function of the system, a good documentation system is paramount, as are facilities to quickly enter, update and retrieve the information stored in the library.

9. D9. D9. D9. DATA INTEGRATIONATA INTEGRATIONATA INTEGRATIONATA INTEGRATION The integration of the data required to run and validate each of the models in the DSS is essential. Moreover, data need to be kept up to date. Depending on the amount of data involved and their refreshment rate three types of solutions are possible: Stand-alone database. This is the most common and technically the simplest way of making data available in the DSS. The database is either an internal part of the DSS system or it is external but resides on the same host machine. Data updates are realized by exchanging old against new files or simply by editing the data in the database file(s). For WadBOS, this is the solution chosen as it is a logical solution in line with the general objectives and usage of the system. The solution was possible, because none of the models momentarily incorporated in WadBOS requires vast amounts of data. Moreover, most of the data are obtained from a wide variety of sources, some of which are not in digital format. This is certainly the case for the economic and ecological data in the system. WadBOS takes entirely care of the storage and retrieval of its data: new or additional information is entered via the dialogs of the system and WadBOS will store it in a hierarchically organised directory structure. All the files are in a readable format, hence can be viewed and edited directly by the end-user if he wishes to do so. The map information is stored in an internal GIS format, but can be exported in either ArcInfo ascii .ASC or Idrisi Image .IMG format. Online-connection to external database. This alternative is technically the most cumbersome. It is a solution much more typical for Management Information Systems, rather than Decision Support Systems for policy-making like WadBOS. It requires a direct and permanent connection between the DSS and (an) external database management system(s). In practice this restricts the usage of the DSS to places where (a good) Internet connection is available. It is only useful if the DSS contains models needing on-line updated data (i.e. water-levels and meteorological data for navigation). In WadBOS this is not the case until now. Offline-connection to external database. In this case, the DSS offers the tools for establishing a connection, typically via Internet, to external databases in order to upload the data used in the DSS.


31

Thus, a copy of the data is stored in the DSS or in a database on the host machine, and the DSS can be used stand-alone until an upgrade of the data is required. This solution is very interesting when large amounts of data are used that are upgraded very regularly (i.e. meteorological data) and that can be obtained from one or a few data providers. For future versions of WadBOS this solution will be implemented. It certainly is a better alternative for the maintenance and distribution of the substantial amount of geographical data used in the system. Practice has learned that the GIS files are replaced by better quality versions on a very regular basis. Until now, these data are generated and stored in the GIS system of the National Institute for Coastal and Marine Management / RIKZ in Haren. They are distributed with new versions of the WadBOS. However, and once WadBOS will be installed on the machines of the many end-users of the member organisations of CUBWAD, there will be an absolute need for a central site from where the management and distribution of the databases is organised. This is not only the case for the data, but equally so for the rest of WadBOS: the models, the tools and the application proper. At this moment, options are evaluated to set-up a management organisation that would distribute the WadBOS DSS from a page in the Interwad Internet application.

10. U10. U10. U10. USER INTERFACESER INTERFACESER INTERFACESER INTERFACE The user interface is the vehicle of interaction between the user and the computer. It enables the user to address the different components of the DSS (tools, data, models, etc.), translates the user input into appropriate computer instructions, and reports back the results of the computations. To provide maximal user-friendliness, state-of-the art interactive graphical techniques are applied extensively. A well-designed, intuitive, and user-friendly interface will support the execution of the policy exercises to the degree considered necessary by the decision maker. The same interface will increase the transparency of the DSS, its models and methods as much as possible: at any point in time, the user should have access to the background information needed to understand the models he is working with, the processes represented, and the numbers generated. Without this information, models remain black boxes and learning is impossible. Another important role of the user-interface is to hide the complexities of the internal computer system without hampering its flexibility. It organises the handling of the DSS in line with the context of the decision maker rather than that of the software developers, the model builders, and the other toolsmiths. Thus, it enables the users to make decisions on the basis of a consistent line of reasoning and suggests solutions in ways that make intuitive sense to them. The latter is a prerequisite for a successful DSS (Holtzman, 1989). The user interface of WadBOS has been designed in accordance with the scheme shown in Figure 10. The Wadden system (box: System) is represented by means of the integrated dynamic model. Because of its autonomous dynamics and the policies in force, the Wadden system evolves into new states as time goes by (box: Resulting state). The policy relevant aspects of new states is captured and synthesised in a number of indicators. The policy maker should begin any policy exercise, aimed at selecting ways of altering the autonomous dynamics or future state of the Wadden system, with a clearly defined set of criteria defining the desired state at a particular point in time (box: Preferred state). In order to bring the actual state of the Wadden system closer to the preferred state, he can intervene in the system by means of policy measures (box: Policy measures). In an iterative process, he can tune his policy measures in an attempt to approach the preferred state with a minimum amount of effort and costs. The robustness of the chosen policy measures can be tested by imposing effects on the system that in the real world are beyond his control. These effects are called scenarios (box: Scenarios).


32

Figure 10: WadBOS enables the policy maker to work with the models in a structured manner. Thus, he can get a better understanding of the system he is to manage.

The user-interface of WadBOS features for each of the boxes in the above scheme a specific window and view on the underlying models. Each view shows in a graphical manner how policy relevant features relate to the processes modelled. 1. The System diagram View contains an overview of the structure of the integrated model at the

most synthetic level (see Figure 7). It represents the linkages between the ecological, landscape, and economic processes typifying the dynamics of the Wadden Sea by means of boxes connected by arrows. When a box is clicked with the mouse, the details of the particular model are shown, and the user can access the related input and output dialogs.

2. The Scenarios View shows the parts of the model

that are most subject to external influences. These are elements not under the control of the policy-maker. The user can enter hypothesis for the following external influences: Atmospheric and Climatologic variability (Atmosfeer & klimaat); Economic growth and decline (Economische ontwikkeling) in the sectors; development of the level of Prosperity (Welvaart) in the Netherlands; and exchanges of water and dissolved matter between the Wadden Sea, the North Sea and the IJsselmeer (Noordzee-IJsselmeer).

3. The Policy options View shows the parts of the

model that are subject to policy interventions. These are elements that are under the control of the policy-maker. The user can experiment with different combinations of policy measures and set values for: Zoning policies (Sluiten gebieden), including closure of parts of the Sea; limitations on Infrastructure (Infrastructuur); Taxes and Subsidies (Heffingen & Subsidies); and Quota set on fishing and mining. The costs and benefits of these Government (Overheid) policies can be assessed.


33

4. The Impacts View shows the parts of the model containing the summarised information and policy indicators required to evaluate the success of scenario and policy options tried out on the system. In general the indicators are taken from the management plan of the Wadden Sea. For most indicators norms and criteria are available which can be entered as a reference value in the score-tables of the dialogs associated with the boxes in this view. Indicators expressing the economic, social, ecological, biological, chemical and physical state of the system can be viewed.

Figure 11: The WadBOS Policy-Wizard with part of a concept network for a policy exercise related to recreational boating in the Wadden Sea

While working with the system, the user has in principle access to all the variables and all the parameters of all the models. Moreover, he can decide which combination of dialogs and maps he wants to view while he is working with the system. All opened maps and dialogs will be updated instantaneously and for each relevant time step. However, flexibility rarely comes without some form of complexity. Experience has shown that policy makers, willing and able to invest the time required, learn to work with WadBOS rather quickly, hence, that the logic behind the approach makes sense to them. For them, WadBOS offers many possibilities to learn how the Wadden system is critically bounded and how they can intervene and influence the dynamics. For the new or the occasional user of the system, a so-called Policy-Wizard is available in WadBOS (see Figure 11). The Policy-Wizard is a facility enabling the interactive creation and adaptation of a case specific user interface. It is most effective in a situation where an experienced WadBOS user prepares a case for a novice. To that effect a concept diagram can be drafted in a graphical


34

window. The concepts are meaningful elements or steps in a policy exercise (i.e. the steps in an environmental impact assessment) and can be linked to MBB[s] from the integrated model. Very similar to the other diagrams in the user interface, the concepts are represented as boxes. But, the arrows connecting the boxes are not flows of data, rather are indicating the stepwise direction of the analysis. When a concept is clicked, direct access to the linked MBB is enabled. The Policy Wizard can reduce the complexity of WadBOS in a substantial manner, because the user is only confronted with system elements that are immediately relevant to a policy exercise. At the same time the full functionality of WadBOS remains available.

11. D11. D11. D11. DISCUSSION AND ISCUSSION AND ISCUSSION AND ISCUSSION AND CCCCONCLUSIONSONCLUSIONSONCLUSIONSONCLUSIONS When the intention was originally formulated to develop a system ‘to gather, order and link the knowledge available about the Wadden Sea in order to facilitate the policy-making process’, a lot of different views coexisted relative to its function: (1) a tool for analysis and evaluation of autonomous dynamics and the effect of policy intervention thereon, (2) a storage tank of data, information, and knowledge, (3) a tool for communication (of results), or (4) a tool for the management of information and knowledge about the Wadden system. The very existence of WadBOS proofs that the tools and the technology exists to build the kind of instrument envisaged, but it took a very close collaboration between the end-users and the DSS developers to make the many technical decisions explained in this paper. The specifications of the end-users were clear in stating that WadBOS was primarily an instrument for analysis. However, the role of WadBOS as an instrument for communication has been at the least as important in practice. The fact that this instrument integrates in a formal manner the many processes that make and change the Wadden Sea gives direction to a lot of the discussions. It does not necessarily make stakeholders agree on issues more easily, but it helps certainly in clarifying what it is that they do not agree about. The capacity to visualise conflicting views and reduce these conflicts in an interactive session is of paramount importance. A core element in WadBOS is its integrated model of the Wadden Sea. The use and need of such instruments is strongly advocated in disciplines such as Integrated Assessment (see for example: Gough et al., 1998). Yet, and despite the fact that the term ‘integrated model’ is used all over to mean a wide variety of things, there are very few operational definitions and recipes or procedures for model integration available from the scientific literature. Thus, model integration seems more an art than a science at this moment. It is a deep scientific problem but also a pragmatic multi-criteria multi-objective problem as it requires dealing with end-use aspects: what is appropriate to be integrated in view of the intended use, the scientific aspect: what can and cannot be integrated on scientific grounds, and the technical aspects: how will the integrated model be assembled and run. Integrated models used to support the policy making process, called policy models in this paper, come with a set of requirements of their own distinguishing them rather clearly from research models. Policy makers are most served by models in which the time horizon, the spatial and the temporal resolution are policy problem oriented and not so much process oriented as in research models. They need adequate rather than accurate representations of the processes modelled and sketchy but integral rather than in depth and sectorial models. While research models are as complicated as necessary and scientifically innovative, the policy maker is better served with an instrument that is as simple as possible and scientifically proven. If these differences are ignored in the integration process, the result will be a large-scale sluggish model not tailored to the needs and expectations of its end-user. Clearly, a fast, interactive model equipped with a graphical interface will do much better for policy exploration. Four different types of architecture for integrating models are possible, but they all differ strongly relative to their implementation and maintenance


35

costs, their user-friendliness and overall performance. The modelbase of WadBOS is very much organised to facilitate a ‘single integrated dynamic model with access to the original, in depth models’. This solution is most user-friendly and offers the best performance and accuracy. But, it is not cheap to build. In order to limit the development maintenance costs, to enable distributed development, and to promote flexibility and re-use of models and tools state of the art component based development has been applied to implement WadBOS. In particular it has been implemented technically by means of GEONAMICA®, an object-oriented application framework and DSS-Generator. The choice has been to keep the system sufficiently self-contained, stand alone, easy to install and run. So far, and during the prototyping and evaluation phases, this has been to the benefit of the system. In the future, when the system will have been given a better defined role within the policy organisations for which it is intended, a distribution and management organisation servicing a large group of end-users from a central point, most likely via the Internet, will be more appropriate. A model will only serve the policy end-user if it is handed to him in a format that enables him to work with it. In Decision Support Systems, models are supplemented with sets of tools to structure and carry out the analysis in a manner that makes intuitive sense to the policy maker. One of the crucial elements in the DSS is the user-interface. It is a very essential element in bridging the gap between the world of the policy maker and that of the model developers and computer specialists. It should hide the technical complexity of the information system without reducing its flexibility and transparency. Attaining the level of user-friendliness and flexibility that policy-makers seem to desire remains a very big challenge for computer scientists, model developers and domain specialists alike. Indeed it is very difficult to package in a single application a system with the level of interactivity, flexibility and the fast response times wanted, the user-friendliness, simplicity and the transparency desired, and, the level of accuracy and certainty expected. A lot more innovative research, design and implementation work will need to be carried out to get to this point if ever we do. For certain, the demand for the kind of instruments is real. Policy questions have reached a level of complexity that can no longer be dealt with by politicians alone. High-level technicians are playing an ever-increasing role, and, the revolution in hardware and software technologies has equipped them with very powerful multi-media calculators. What general lessons can be learned from this project? From the WadBOS project it can be concluded that a policy support tool can be developed within very reasonable constraints relative to budget, human resources and development time. This is much more easy when good base material and expertise is available and when a stimulating collaboration between visionary end-users and competent DSS developers is propelling the development. However, the development phase described is only the first one in the life of a Decision Support System. It needs to be followed by an in depth evaluation of the technical contents of the system: its constituent models, its coverage of the decision domain(s), its way of dealing with the spatial and temporal dynamics of the processes and the policies. Also an evaluation on behalf of the end-users is pertinent. How do they believe their decision domain has been represented? Does the system speak their language? Does it work in the way that they find useful and pleasant? With the answers to all these questions a more or less major redesign of the DSS might be possible or necessary. In this paper we have not dealt with the quality of integrated models in terms of their calibration and predictive capabilities, because it is all together a subject worth another paper of a similar size. The technology presented in this paper is not an alternative for calibration and good modelling practices. As long as a model is not calibrated, it should stay in the hands of the model developer and should certainly not be used for policy-making purposes. Calibration remains a very difficult and time-consuming task. It is more so for a complex integrated model than for a simple and small one. However, linking individual models into an integrated model is not necessarily increasing the level of uncertainty and error. Rather, the strong linkages and loops between the individual models and the fact that variables are passed from sub-model to sub-model, bring to the surface mistakes in


36

the model formulations and calculations much more easily than when the same models are applied in isolation. Nevertheless, it should be emphasized that even extensively calibrated WadBOS-like models will only generate potential developments rather than predictions of future states or changes. This is not only due to the problem of calibration, but because of the inherent uncertainty in the processes represented too. Consequently, the model and the encompassing DSS should be used for explorative rather than predictive purposes at all times. Introducing and institutionalising the DSS in the end-user organisation is the ultimate factor determining its success (see for example: Alter, 1980; Klein and Methie, 1995). Even the best DSS will go unnoticed or will fail if the wrong implementation and introduction strategy is chosen. Generally speaking, the development and acceptance of the DSS will be much easier if the development is initiated by its end-users right from the beginning. The more they feel the need for a change, the more they are involved in defining the precise role of the instrument in the organisation, the more likely it is that the DSS will be accepted and used. The more the product itself fulfils tasks that are perceived as real, in ways that are transparent to the end user, and in ways that solve the problem in an obviously better way than before its introduction, the more the product will make a chance to survive. It is therefore very crucial to determine the right moment during the development of the DSS to have it change state from a prototype into an operational version. This is when a gradual introduction, a good technical documentation, hands-on training, and prolonged technical assistance during the usage, becomes of paramount importance. A hasty, unprepared introduction should be avoided under all circumstances. From this paper, it will be clear that the WadBOS methodology and the technical components that constitute WadBOS can be easily transferred to other coastal zones in the Netherlands, Europe and the world beyond. There are many examples to proof this point: RamCO1, SimLucia2, Murbandy3, MODULUS4, Environment Explorer5, etc. Such transfer could take place on a site-by-site and application-by-application basis. However, a more systematic approach in which databases and model bases are developed and maintained covering more than a single region or application holds much more potential. In the Netherlands, an initiative has started as part of the GEOMOD6 project to transfer the WadBOS concepts and tools to the Scheldt estuary. One of the aims of this initiative is to find out precisely what the contents would be of the national database, modelbase and toolbase enabling the implementation of a WadBOS like system in other coastal zones of the Netherlands. At the European level similar initiatives would be required. They should be combined with ongoing activities to develop tools for the effective access to and integration of data relevant to coastal zone management and planning, such as: COASTBASE, DESIMA, EIONET and ESPON. The development of such instruments should anyway result from a joint effort between those involved in model development, thus able to define the kind of data required, and those involved in data providing or monitoring, thus knowledgeable about systematic data gathering and monitoring programmes. One or the other in isolation will not bring about the material required for effective policy making.

1 RamCO is a Coastal Zone Management application in Sulawesi, Indonesia developed for the National Institute for Marine and Coastal Management. 2 SimLucia is a Coastal Zone Management and Land Use Planning application in St. Lucia, West Indies, developed for the United Nations Environment Programme. 3 Murbandy is an Urban Land Use Planning application generically applicable for European urbanised regions developed for the Joint Research Centre of the European Commission. 4 MODULUS is an Integrated Watershed Management and Land Use Planning application applied in Mediterranean Coastal Watersheds subject to Land Degradation and Desertification in Greece and Spain developed for DG12 of the European Commission. 5 Environment Explorer is an Integrated Land Use Planning application in the Netherlands, developed for Ministry of the Environment and the Ministry of Transport, Public Works and Water Management. 6 GEOMOD is a project initiated and financed by the Ministry of Transport, Public Works and Water Management.


37

12. R12. R12. R12. REFERENCESEFERENCESEFERENCESEFERENCES Alter S.L., 1980; ‘Decision Support Systems: Current Practices and Continuing Challenges’,

Addison-Wesley, Reading, MA. Brinkman A., 1993; ‘Biological processes in the EcoWasp ecosystem model’, IBN-DLO report

93/6, Texel. Catanese A.J., 1979; ‘Information for planning’. The Practice of Local Government Planning,

International City Management Association, Washington D.C. D’Souza D.F., Cameron Wills D., 1999; ‘Objects, Components, and Frameworks with UML. The

Catalysis Approach’, Addison-Wesley, Reading, Massachusetts, USA, 785 pp. El-Najdawi M.K. and Stylianou A.C., 1993; ‘Expert Support Systems: Integrating AI

technologies’, Communications of the ACM, 36, (2), pp.55-65. Engelen G., White R. and Uljee I., 1993; ‘Exploratory Modelling of Socio-Economic Impacts of

Climatic Change’. In: Climate Change in the Intra-America’s Sea, G. Maul, (ed.), Edward Arnold, London, pp.306-324.

Engelen G., White R., Uljee I. and Drazan P., 1995; ‘Using Cellular Automata for Integrated Modelling of Socio-Environmental Systems’, Environmental Monitoring and Assessment, 34, pp.203-214.

Engelen G., White R., Uljee I., and Wargnies S., 1996; ‘Numerical Modeling of Small Island Socio-Economics to Achieve Sustainable Development’. In: Maul G.A. (ed.) ‘Small Islands. Marine Science and Sustainable Development’, American Geophysical Union, Washington DC, Coastal and Estuarine Studies, 51, pp.437-463.

Engelen G., Geertman S., Smits P., and Wessels C., 1999a; ‘Dynamic GIS and Strategic Physical Planning: A Practical Application’. In: Stillwell J., Geertman S., and Openshaw S. (eds.) Geographical Information and Planning. Advances in Spatial Science. Springer, Berlin, pp.87-111.

Engelen G. (ed.), 1999b; ‘BOS Integraal beheer van Estuariene en Waddensystemen. Deelproject: Case Waddenzee’, Stichting LWI, Gouda

Engelen G. (ed.), 2000; ‘MODULUS: A Spatial Modelling Tool for Integrated Environmental Decision-making’, Final report, EU-DG12 (Contract ENV4-CT97-0685), Brussels.

Fayad M.E., Schmidt D.C., Johnson R.E., 1999; ‘Building Application Frameworks: Object-Oriented Foundations of Framework Design’, Wiley Computer Publishing.

Firley M. and Hellens D., 1991; ‘Knowledge Elicitation. A Practical Handbook’ Prentice Hall, New York.

Gamma E., Helm R., Johnson R., and Vlissides J., 1995; ‘Design Patterns: Elements of Reusable Object-Oriented Software’, Addison-Wesley, Massachusetts.

Gonzalez A.J. and Dankel D.D., 1993, ‘The Engineering of Knowledge-based Systems. Theory and Practice’, Prentice Hall, Englewood Cliffs, NJ.

Gough C., Castells N., and Funtowics S., 1998; ‘Integrated Assessment; an emerging methodology for complex issues’, Environmental Modelling and Assessment, 3, pp.19-29.

Huizing J.J., Engelen G., van de Ven K., Pothof I., and Uljee I., 1998; ‘WadBOS. Een prototype van een kennissysteem voor beleidsanalyse van de Waddenzee’, Eindrapport, Directie Noord Nederland, Rijkswaterstaat, Leeuwarden.

Holtzman S., 1989; ‘Intelligent Decision Systems’, Addison-Wesley, Reading Klein M.R. and Methie L.B., 1995; ‘Knowledge-Based Decision Support Systems’, Wiley, New

York.


38

Kok, J.L. de, Arifin T., Noor A., Wind H.G., and Augustinus P.G.E.F, 1997; ‘Systems analysis as a methodology for sustainable coastal-zone management in Tropical Countries’. Torani, Marine Science and technology bulletin, 8, pp.31-41.

Marakas G.M., 1998; ‘Decision Support Systems in the 21st Century’, Prentice Hall, Upper Saddle River, NJ.

RWS Noord-Nederland, RWS Noord-Holland, and RWS-RIKZ, 1995; ‘Nota Marsdiep. Verkennende studie naar een methode voor integral beleid en beheer’, Nota NN-ANW 95-02, Leeuwarden.

McConnell S., 1996, ‘Rapid Development. Taming Wild Software Schedules’. Microsoft Press, Redmond, Washington.

Meyer B. 1997; ‘Object-Oriented Software Construction’. Prentice-Hall, ISBN 0-13-629155-4. Mintzberg H., Raisinghani D., and Théorêt A., 1976; ‘The Structure of Unstructured Decision

Processes’, Administrative Science Quaterly, 21, pp.246-275. Orfali R., Harkey D., and Edwards J., 1996; ‘The Essential Distributed Objects Survival Guide’,

John Wiley & Sons, New York, USA, 604 pp. Rizzoli A.E., Davis R.J., and Abel D.J., 1998; ‘Model and data integration and re-use in

environmental decision support systems.’ Decision Support Systems, 24, pp.127-144. Rogerson D.E., 1997. ‘Inside COM’. ISBN 1-57231-349-8, Microsoft Press, Redmond,

Washington, USA, 376 pp, 1997. Salz P., Dol W., and Smit W., 1994; ‘Schol case; economisch model’, LEI-DLO, Den Haag. Sprague R.H.,Jr., and Carlson E.D. 1982; ‘Building Effective Decision Support Systems’, Prentice

Hall, Englewood Cliffs, NJ Uljee I., Hahn, B., van der Meulen M., and Engelen G., 2000; ‘WadBOS Gebruikershandleiding’,

National Institute for Coastal and Marine Management / RIKZ, Haren White R. and Engelen G., 1994; ‘Cellular Dynamics and GIS: Modelling Spatial Complexity’,

Geographical Systems, 1, pp.237-253. White R. and Engelen G., 1997; ‘Cellular Automata as the Basis of Integrated Dynamic Regional

Modelling’, Environment and Planning B, 24, pp.235-246. White R., Engelen G. and Uljee I., 1997; ‘The use of Constrained Cellular Automata for high-

resolution modelling of urban land use dynamics’, Environment and Planning B, 24, pp.323-343.

Documents

The development of the WadBOS Decision Support …publicaties.minienm.nl/download-bijlage/30033/dss-wadbos.pdfThe development of the WadBOS Decision Support System 4 (DSS), representing