˘ˇˇ - zalf leibniz-zentrum für...

1

�� !�� "��#$#$%$&�'(��)*� !�� ' �

�

)��)��++&,-.�/(�)�0�� !��"��1��*��"��1��+#�2��3++.�2�� 4.�� *�

SIAT – system architecture and design, Sustainability Impact Assessment Tool

Deliverable number: 4.3.1

Organisation name of lead contractor for this deliverable: Alterra, Wageningen-UR

Partner involved: Alterra, Wageningen-UR

Researchers involved: Peter J.F.M. Verweij, Johnny te Roller, Bas vanMeulebrouk, Rob Knapen, Yke van Randen, Wim de Winter, Jappe Franke.

Acknowledgements: Perez Soba, R. Haines Young, M. Potschin, M. Dibonito, M.L. Paracchini, L. Jones, C. Pacini, T. Jansson, M. van Eupen, T. Kuhlman, H. Haroldsson, D. de Groot. K. Helming, S. Sieber, D. Pohle, K. Fricke, J. Vogt, H. van Meijl, B. Snizek, H. Sten Hansson, J.P. Anders.

Due date of deliverable: Month 54

History: Initial version : April 2007; Sent in for review : April 2008; Review comments received : October 2008; Send in for submittance : December 2008; Coordination comments : January 2009; Pre-Final (added sensor book refs) : January 2009; Updates chapter 10 and 11 : May 2009. Project co-funded by the European Commission within the Sixth Framework Programme (2002-2006) Dissemination level PU Public �PP Restricted to other programme participants (including the Commission Services RE Restricted to a group specified by the consortium (including the Commisssion Services) CO Confidential, only for members of the consortium (including the Commission Services) For dissemination level of the deliverable see DoW chapter 8.4, p. 85

2

Objectives: To describe the architecture and functional, technical and interaction design of the Sustainability Impact Assessment tool SIAT.

Activities: Conceptual, interaction and logical design based on feedback from SIAT prototype I and II by several meetings with project partners and EU officers. Outside-in design starts by looking at the interaction model of a software application in terms of Graphical User Interface sketches and determines logical and technical functionality based on those. The interaction model draft was sketched in Microsoft Powerpoint and presented in a number of iterations. During each iteration feedback was gathered to update the interaction model (and determining its logical and technical requirements from those) for a next iteration. Date Meeting Location Participants September 18/22 2006

Use of spider diagram presentation and what unit to put on the axis (During project meeting)

Saarema, Estonia

Maria Luisa Paracchine, Michiel van Eupen, Peter Verweij

October 25 2006

End user meeting (combined with Seamless, Eforwood and Sensor)

Brussels, Belgium

Daniel Deybe, participants from different DG’s and FP6 project coordination

January 16 2007

Integration of M3, M6 and M7

Amsterdam, The Netherlands

Marta Perez Soba, Roy Haines-Young, Oliver Dilly, Jake Morris and many others.

March 2007

-Echange format of M2 response functions and SIAT -estimation of response functions

The Hague, the Netherlands

Kristina Jansson, Torbjörn Jansson, Tom Kuhlman and Peter Verweij

April 16/20 2007

integrated impact indicator presentation, expressing information reliability and transparent assessments (during cluster meeting)

Vienna, Austria

Roy Haines-Young and Marion Potschin, Peter Verweij

April 16/20 2007

inclusion of present situation and indicator standardisation/normalisation(during cluster meeting)

Vienna, Austria

Maria Luisa Paracchine, Jurgen Vogt, Michiel van Eupen, Peter Verweij

May 28, 2007

Cross module meeting M4/M5. Using the M5 database server for SIAT

Arnhem, Wageningen

Sten Henning Hansen, Johnny te Roller, Peter Verweij

May 24/25 2007

Prototype II planning workshop

Firenze, Italy Cesare Pacini, Hordur Haroldsson, Johnny te Roller, Stefan Sieber, Katharina Fricke, Dirk Pohle, Peter Verweij

June 8 Green week conference Brussels, Patrizia Poggi, Dirk

3

2007 -SIAT interaction model and cluster region schematisation

Belgium Wascher, Peter Verweij

July 8 2007

IALE conference -information reliability and thresholds/limits/standards concept

Wageningen, The Netherlands

Roy Haines-Young, Peter Verweij

Juli 16/20 2007

Model linking workshop Wageningen, The Netherlands

Johnny te Roller, Yke van Randen, Dirk Pohle and Peter Verweij

August 31 2007

Conceptual integration of wp4.4 ‘visualisation’ into SIAT

Amsterdam, The netherlands

Bernhard Snizek, Peter Verweij

September 11 2007

How show what information in SIAT? How integrate stakeholder results?

Alice Holt, UK

Paul Tabbush, Jake Morris, David Edwards, Katharina Helming, Dirk Pohle, Tom Kuhlman, Peter Verweij

September 17 2007

Project meeting - indicator standardisation/normalisation

Cottbus, Germany

Maria Luisa Paracchine, Laurence Jones, Marta Perez Soba, Cesare Pacini, Peter Verweij

September 17 2007

Project meeting - sustainability choice space

Cottbus, Germany

Roy Haines-Young, Marion Potschin, Peter Verweij

Januari 14 15 2008

Integration wp4.4 ‘visualisation’ of 3D landscape perspectives and contextualisation matrix implementations

CopenHagen, Denmark

Bernhard Snizek, Thomas Sick Nielsen, Johnny te Roller, Peter Verweij

Febuary 5 2008

SIAT topic structure (available fact sheets)

Wageningen, Netherlands

Katharina Helming, Marta Perez Soba, Stefan Sieber, Peter Verweij

March 18 2008

SIAT interaction model and Graphical design update


Johnny te Roller, Jos v Roij, Anita Heister, Peter Verweij

April 7/9 2008

Land use functions and standadisation of indicators

Berlin, Germany

Laurence Jones, Maria Luisa Paracchini, Cesare Pacini, Marta Perez Soba and Peter Verweij

April 14 2008

SENSOR scientific review meeting

Brussels, Belgium

Peter de Smedt, Kristian Borch, Erol H. Cakmak, SENSOR module coordinators and Peter Verweij

May 20 2008

End User meeting JRC-IPTS, Seville, Spain

Peter de Smedt, Oliver Wolf, Tomas ratinger, Ignacio Perez, Robert M’Barek, Paul Tabbush, Stefan Sieber, Tobjörn Jansson and Peter

4

Verweij June 10/11

SIAT planning Berlin, Germany

Cesare Pacini, Stefan Sieber, Johnny te Roller, Bernhard Snizek, Dirk Pohle, Katharina Fricke and Peter Verweij

September 22-24 2008

SENSOR project meeting Birmensdorf, Switzerland

Many SENSOR consortium members

November 24-25 2008

Land Use Function expert meeting


Tom Kuhlman, Cesare Pacini, Laurence Jones, Marta Perez Soba, Marcello Dibonito, Johnny te Roller, Dirk Wascher, Peter verweij and many external indicator experts

January 6/7 2009

Sustainability Choice Space meeting

Nottingham, UK

Roy Haines Young, Marion Potschin, Marcello Dibonito, Jake Morris, Johnny te Roller, Dolf de Groot and Peter Verweij

March 23/24 2009

Factsheet inclusion and structuring, terminology consistency check and final prioritisation of tasks


Stefan Sieber and Peter Verweij

5

Executive summary The main objective of WP4.3 is to build the Sustainability Impact Assessment Tool (SIAT) aimed at integrating many of the concepts, methodologies and products of the SENSOR project through a single entry point, the software tool. This deliverable (D 4.3.1) concerns the tool concepts, requirement management, translation of concepts and requirements into an architecture by doing a domain analysis, functional-, technical- and graphical design and provide examples and interfaces to project partners delivering data and model components to fill the system. A second deliverable, D4.3.2 (Sieber et.al., 2009), describes the data and their consistency (e.g. factsheets, model component implementation, or indicator units) based on information from the SENSOR experts outside of WP4.3 to technically fit into the SIAT software system.

Mid 2006, the conceptual SIAT prototype-I system was developed to explore how a SIAT tool could function. The system concepts were based on the SENSOR SIAT demo (after Roos-KleinLankhorst). It uses a wizard like interaction model consisting of the following steps: i) choose reference scenario; ii) define policy; iii) look at land use changes and impact indicators accompanied by a ex-ante quality estimation and iv) see whether the indicators score within given sustainability limits which could be tweaked by the end user. Besides it showed examples on how transparency in the information could be reached: a) fact sheets (based on ATeam (Metzger) and Eururalis1 (Klijn)); b) drill down in calculations (based on Menes (Boogaard) and Osiris (Roos-KleinLankhorst)). Prototype I used dummy data, dummy models and dummy fact sheets.

Following the evaluation of protoype-I functionalities, the objective of Prototype II was to setup a flexible web based operational system which supports impact assessments of land use related policies. System flexibility is defined in terms of system adaptability to new data and models, such as: policy cases, baselines and target years, spatial extent and resolution, indicators, context sensitive fact sheets and models implementing the cause-effect relation between policy and impacts. The system is decoupled from specific model implementations (like response-, or indicator functions) by using model abstraction. The EU open standard OpenMI (Open Modelling Interface) is used to describe models related to specific cause-effect relations. OpenMI facilitates the linking of different models by using a standardised interface between the models. OpenMI (Moore, 2002) was originally developed for linking complex numerical recursive loop models from the water domain. Within SENSOR integrated assessments are carried out by linking numerical model components, but also quantitative knowledge rules. SENSOR triggered the extension of OpenMI to support both nominal and ordinal quantitative data types (Verweij, 2007). Technical flexibility and decentralised system development and maintenance require the use of some logical construct for defining and controlling the interfaces and the integration of a system. This construct is also called architecture (Zachman, 1987, Knapen 2007). The SIAT architecture facilitates to develop the core system separately from pluggable components such as model components, factsheets and 3D landscape perspective visualisations. This allows consortium partners to develop the component for which they are responsible separately.

A constant flow of feedback from stakeholders on available system functionality and system interaction resulted in the final sprint of evolutionary system development from June 2008 to April 2009. As a result the interaction model for defining simulations has been restructured, the Land Use Function model has been included, and many new analysis tools have been added, such as: analysis of sustainability limit sensitivity, comparison of simulations in a league table and drill down the cause-effect chain.

6

1 Introduction...................................................................................................................................8

1.1 Context ..................................................................................................................................8

1.2 SIAT Status ............................................................................................................................8

1.3 Reading guide......................................................................................................................10

2 Business domain model...............................................................................................................11

2.1 Introduction.........................................................................................................................11

2.2 EU concepts of Impact Assessment .....................................................................................11

2.3 Policies in the computational domain .................................................................................15

2.4 Domain model in UML notation..........................................................................................19

3 System requirements...................................................................................................................21

3.1 Technical requirements .......................................................................................................21

3.2 Qualitative requirements .....................................................................................................21

3.3 Functional requirements .....................................................................................................21

4 System architecture.....................................................................................................................23

4.1 Layered architecture ...........................................................................................................23

4.2 Architectural elements.........................................................................................................24

4.3 Element autonomy ...............................................................................................................26

4.4 Data persistency ..................................................................................................................27

5 SIATGUI......................................................................................................................................28

5.1 Simulations ..........................................................................................................................28

5.2 Data services .......................................................................................................................28

5.3 Visualisation factory............................................................................................................30

5.4 Fact sheets...........................................................................................................................32

5.5 Simulation persistency.........................................................................................................33

6 Simulation services......................................................................................................................34

6.1 Domain logic .......................................................................................................................34

6.2 SIATModel interface............................................................................................................38

6.3 Services................................................................................................................................39

6.4 Data persistence ..................................................................................................................40

7 SIAT linkables.............................................................................................................................41

7.1 Modelling the cause effect relation......................................................................................41

7.2 Model composition ..............................................................................................................44

7.3 Open Modeling Interface (OpenMI)....................................................................................45

7.4 Data persistency ..................................................................................................................49

8 Map and Styled Layer Descriptor services ...............................................................................50

7

8.1 Introduction.........................................................................................................................50

8.2 WMS and SLD specification................................................................................................50

9 Software quality assurance ........................................................................................................52

9.1 Evolutionary delivery ..........................................................................................................52

9.2 Source code .........................................................................................................................53

9.3 Testing .................................................................................................................................54

9.4 Documentation ....................................................................................................................54

10 Interaction and graphical design ...............................................................................................55

10.1 Introduction.........................................................................................................................55

10.2 Prototype I...........................................................................................................................55

10.3 Prototype II..........................................................................................................................56

10.4 SIAT ’final delivery’ ............................................................................................................59

11 State of affairs .............................................................................................................................65

11.1 Introduction.........................................................................................................................65

11.2 Policy cases .........................................................................................................................65

11.3 Converting drivers to impacts .............................................................................................65

11.4 Transparency.......................................................................................................................66

11.5 Landscape perspectives in 3D .............................................................................................67

11.6 Editing of indicator knowledge rules...................................................................................68

8

1 Introduction 1.1 Context The SENSOR project deals with land use related policies on a pan European regional scale. Europe is therefore subdivided into about 570 NutsX regions (D3.2.2). The cause-effect relation between policy and indicators concerns the translation of policies into i) land use changes; ii) relating land use changes to impact indicators of the environmental, social and economical dimensions and iii) assessing regional sustainability limits for the indicators by means of land use functions (D3.2.2)

The Sustainability Impact Assessment Tool (SIAT) is a web based software tool that transparently integrates many of the concepts, methodologies and products developed in the SENSOR project. SIAT’s main objective is to support the discussion on the assessment of the impact an intended land use related policy for sustainable development at regional scale for Europe. SIAT does so by providing several images of the future, or baselines, to which the impact of a user defined policy can be compared by means of maps, graphs, tables, etc. Terminology and methods are explained through fact sheets which are accessible from wherever a term is use. Fact sheets contain references to scientific publications. The SIAT system is specifically flexible with regard to: i) adding of new policies (policy cases); ii) baselines with target times; iii) regionalisations (extent and resolution) and; iv) indicators. Making it adaptable for future SIA applications.

A number of deliverables regarding the SIAT software tool are planned for month 24, 42 and 54 respectively.

1.2 SIAT Status Mid 2006 SIAT Prototype-I was delivered (as described in D 4.3). The main objectives of Prototype-I were to explore how a SIAT tool could function and integrate SENSOR’s key concepts like: impact assessment guidelines, response protocols, spatial regional reference framework, land use function approach, transparency, etc to facilitate discussion and definition. For this prototype, in which development speed was more important than quality, the software development methodology of ‘throw away prototyping’ (McConell, 1996) was used. Prototype I used sample models and data. Visualisations (charts, diagrams) were often static and ‘hand drawn’.

From spring 2007 to spring 2008 Prototype II was developed using the software development methodology ‘evolutionary development’ (McConell, 1996). Within evolutionary development functionality is constantly added to a current application. Previously implemented parts may need to be adapted, or merged with the new functionality. To make sure older parts still function after source code changes, automated testing is included by means of unit tests. Unit testing is a procedure used to validate that individual units of source-code are working properly. A unit is the smallest testable part of an application (Unit test, 2008). Prototype II was developed by two teams of software engineers: a) system architects, designers and developers; b) factsheet and model data redaction. Regularly it was necessary to change previously built source code which was not necessarily built by the person changing it. Documentation (reports and in-source code), version control and automated unit testing were essential during development.

9

During winter 2008 and spring 2009 the SIAT ‘final delivery’ has been developed building on prototype II using the evolutionary development methodology. Major system enhancements include the land use function approach, the sustainability choice space and a limit sensitivity tool.

Major differences between SIAT versions are found in Figure 1. Impression Qualities

Prototype I • Objective: integration of concepts • Throw away prototype • No quality assurance • Stand alone application • Sample data • Sample model • Sample factsheets • Single user database • Graphical User Interface: wizard for

defining simulation

Prototype II• Objective: system operationalisation:

o Web based architecture o Flexible to add: policy cases,

baselines, target years, models, regionalisations and indicators.

• Evolutionary development • Quality assurance started • Web based application • Real data • Connected models using OpenMI:

o Preliminary response function implementation

o Preliminary indicators (amount: 3) • Factsheets: preliminary (amount: 12) • Database server • Graphical User Interface: task based

Final delivery • Objective: operationalisation

o Land Use Function approach o Limit sensitivity o Sustainability choice space o Drill down impacts o Dynamic GUI setup

• Evolutionary development (continued) • Under quality assurance • Web based application • Real data • Connected models using OpenMI:

o Indicator data (amount: 18) o Full Land Use Function model

• Factsheets: over 100. • Database server • Graphical User Interface: task based

Figure 1 – characteristics overview of SIAT prototype I, prototype II and version 1.0

10

1.3 Reading guide This deliverable report is structured around the process of conceptualizing and designing the SIAT from a application developers perspective. It starts by analysing the SIAT domain yielding common ground for further analysis in chapter 2. Chapter 3 explains general SIAT system requirements and how requirements are gathered, managed, prioritized and planned for implementation. Chapter 4 describes the SIAT logical construct, or architecture and is a means to communicate system setup at a high level of abstraction. An architecture facilitates the development and maintenance of elements separately. E.g. to have different consortium partners develop the software product for which they are responsible. Each of the architectural elements is described in a separate chapter: 5, 6, 7 and 8. Chapter 9 describes the quality parameters on how all the elements are (to be) developed. It describes the software development process and the quality assurance on source code testing and integration of element testing. While the chapters on architecture and architectural elements focus on internal logic of the SIAT, chapter 10 puts the Graphical User Interface in the spotlight: how does the SIAT look like and how is it to be used to support the SENSOR chain of: i) define policy; ii) determine land use changes as result of the policy; iii) find out what these land use changes mean in terms of indicators and; iv) see what indicator changes mean in relation to sustainability. The final chapter 11 sums up the state of affairs at the end of the project.

11

2 Business domain model 2.1 Introduction “The design of a software product starts by analysing the conceptual domain to which the software applies. A conceptual domain analysis yields common grounds for further specific analysis (Champeaux et al., 1993) by identifying, collecting, organizing, and representing the relevant information in a domain, based upon the study of knowledge captured from domain experts by means of a series of small consortium member workshops and interviews; underlying theory in literature; and the study of existing systems within the domain. Domain analysis carefully bounds the domain being considered, organize an understanding of the relationships between the various elements in the domain, consider commonalities and differences of the systems in the domain and represent this understanding in a useful way (Nilsen et al., 1994). Result of the analysis is a domain model: a simplified, abstract image of reality. In the analysis notions from the domain and relations between those notions are described” (Verweij et al, 2009, submitted).

The following paragraphs describe the derivation of the conceptual domain model, the positioning of model based calculations and a global translation to software classes and main helper classes.

2.2 EU concepts of Impact Assessment The Sustainability Impact Assessment Tool is a quick scan tool to determine impacts and sustainability risks of EU land use related policies in the frame of EU Impact Assessments:

An impact assessment (IA) is a EU tool to find out whether why and how the EU should develop policies and what possible options for these policies are. Doing an IA involves answering a number of basic analytical questions: What should be the objectives pursued by the Union? What are the main policy options for reaching these objectives? What are the likely economic, social and environmental impacts of those options? What are the advantages and disadvantages of the main options? [EC, 2005] (Figure 2)

Figure 2 – impact assessment (Verweij, 2007)

The EC provides a roadmap to analyse impacts and side effects of an intended policy: 1) identify the problem; 2) define the objectives; 3) develop main policy options; 4) analyse their impacts; 5) compare the options and; 6) outline policy monitoring and

Policy Objective Policy options

Impacts HaveHas an

Impact assessment

Concerns a Compares

Can be reached by different

12

evaluation [EC, 2005]. The SENSOR Sustainability Impact Assessment Tool supports stage 4 and 5: the analysis of the impacts and the comparison of options (Tabbush et al. 2008 and Verweij et al., 2006).

Policy option A policy option concerns a set of quantified/qualified policy instruments, one of several ways to achieve the objective(s) of a policy [EC, 2005]. A policy instrument is a specific power which policymakers possess in order to achieve certain goals (Figure 3).

Figure 3 – relation policy option and policy instrument

Policy case A policy case represents a policy theme or problem area within which policies can be formulated. To do this the policy case contains policy instruments (Kuhlman, 2008). The instruments can be divided into direct actions of the policymaker and instruments aimed at influencing behaviour of the public [EC, 2005] (Figure 4).

Figure 4 – relation of concept policy case to concepts: policy themes, -objectives and -instruments

Indicators Progress towards a policy objective is measured by indicators [EC, 2005] (Figure 5), where indicators are quantitative tools that synthesise or simplify relevant data relative to the state or evolution of certain phenomena. They are tools for communication, evaluation and decision making that can take quantitative as well as qualitative form depending on the purpose of the indicator [Gallopin, 1997]. E.g. When the objective is to promote economic development in rural areas the progress is measured by the indicator rate of economic growth in rural areas.

Policy option

Set of Policy instrument

Policy case Policy instruments

Impacts Have measurable

Represents a

Policy theme/ problem area

Contains

Policy objectives

Can support multiple Turns knobs

of

13

Figure 5 – relation between concept indicators and concepts policy objective, impacts and indicator values An indicator framework is a way to organize and systemize indicators for making them consistent. What indicator framework was used for SENSOR can be read in ‘An indicator framework for sustainability impacts of land use changes’ by Frederiksen and Kristensen (Frederiksen et al. 2008). Baseline scenario The impact of a policy may very much depend on the actual situation in the future (Kuhlman, 2008). Future development depends on exogenous drivers such as population growth and climate change. The impacts of policies can therefore be compared with different exogenous related developments. A baseline scenario describes a future situation to which the impacts of policy options can be compared (Figure 6).

Figure 6 – impacts are a result of a policy within a possible future described by a baseline scenario

Exogenous drivers

Policy options

Impacts Modify Baseline scenario

Affect

Possible future

Described by

Policy objective

Can be achieved using different

Policy drivers

Policy objective

Indicators Progress measured by

Impacts Are expressed by

Indicator value

Are quantified /qualified by

14

SIAT impact assessment The Sustainability Impact Assessment Tool (SIAT) concerns the quantifiable part of the domain in which land use changes and regional differences play a central role (Figure 7).

Figure 7 – Total SIAT domain model Determining impact indicator values is the objective of an impact assessment. SENSOR does so by: i) linking policy options with land use changes; ii) link land use changes with environmental, social and economical impacts and; iii) provide a valuation framework of these impacts in the light of sustainable development (Helming et al., 2008) by means of the land use function approach and the sustainability choice space. A land use function (LUF) summarises the most relevant economic, environmental and societal aspects of a region. By doing so it simplifies the classic complex impact assessment based on a large number of indicators and allows to make explicit analytical links between multifunctional land use and sustainable development (Pérez-soba et al., 2008). The sustainability choice space is a way of helping policy advisors visualise and explore what ‘room of manoeuvre’ they might have in the design of a specific policy (Potschin et al. 2008). Please read any of the above references for more information or D 4.3.2 for data details (Sieber et al., 2009) and Hansen for data management (Hansen et al., 2008). This deliverable focuses on the design and architecture of the SIAT software system and builds upon the concepts developed in SIAT prototype1 (Haraldsson et al., 2005, Verweij et al., 2006).

Exogenous drivers

Policy instruments

Impact indicator

valuesModify Baseline

scenario Affect

Possible future

Described by

Policy case (implicit objective)

Can be achieved using different

Policy drivers

Impacts assessment

Concerns

Compares

15

2.3 Policies in the computational domain In the previous part the domain has been modelled based on the notions from the EU impact assessment guidelines [EU, 2005]. This paragraph deals with the application of the introduced notions to the SIAT software system calculation methodology.

Drivers, either policy or exogenous like population growth, steer the models which relate the drivers to indicators by calculating indicator values. Indicators can be quantitative, or qualitative (Figure 8).

Figure 8 – calculating indicators from drivers (Verweij, 2007)

As can be seen in Figure 7 the policy case references a set of policy instruments through which the tool user can shift policies. The baseline scenario defines a possible future. Within the baseline assumptions are made on the possible policies within that possible future. The baseline therefore restricts the tuning of policy instruments and even specifies the probable value of each of the policy instruments. These probable policy instrument values are used as default value (Kuhlman et al., 2008). The baseline scenario defines the room of manoeuvre / solution space for each of the instruments (Figure 9).

Figure 9 – the policy case determines available policy instruments while the baseline scenario determines probable policy instruments’ values and the room of manoeuvre.

By setting the policy and changing the default values of policy instruments a SIAT user defines his/her own policy (Figure 9). The SIAT models take in policy settings and determines impacts by calculating indicator values by the use of these models (Figure 10). Each specific policy determines impacts for a preset, global list, of indicators. The models have implicit knowledge on the regionalisation for which the indicator values are determined. Within SIAT this regionalisation is currently always the pan European 570 regions of NutsX and spatial aggregates of NutsX. Such as member states, cluster regions) and the EU as a whole (D3.2.2).

Policy case Determines available

Baseline scenario

Policy instruments

Policy settings (user defined)

Refer to

Models Indicators

(quantitative and qualitative)

Drivers

(e.g. policy, technological

innovation, climate change, population

growth)

Determine default value

and range

16

Figure 10 – models are steered by policy settings and produce values for indicators

A policy case concerns a policy theme (see Figure 4). Different policy cases might have different methods to determine policy impacts. Additionally policies might behave dissimilar under different baseline scenarios which may also result in dissimilar methods to determine policy impacts. Thus, cause-effect relations between policy and impacts may depend on the policy case and may differ per baseline scenario (exogenous factors). See Figure 11. However, methods to determine policy impacts with different baselines and/or policy cases might be implemented by the same model(s). The option to have different models per Baseline and policy case is flexible to both solutions by this design and is necessary when implementing the Brazilian and Chinese policy cases (SENSOR module 8).

Figure 11 – model choice (or model parameterisation) depends on policy case and baseline scenario

Policy case

Determines

Baseline scenario

models (e.g. indicator-, or land use function model)

Determines

quantify


input values

output values

policy settings (user defined)

Indicators Indicator values

regionalisation Determine available

Determine available

17

A simulation contains all information required to run the models as defined/selected by the user: i) policy case; ii) policy settings and iii) baseline (see Figure 12).

Figure 12 – a simulation publishes all information required to do a model run

The SIAT facilitates to determine impacts of a user defined policy. Besides the ability to do a policy driven impact assessment, SIAT is also able to handle pre-determined impacts, such as the ‘present situation’, or baseline scenarios to which no policies can be defined (such as low- and high growth, see SENSOR module2). For simplicity sake this is not taken into account in this chapter, but further explained in paragraph 5.1 ‘Simulations’.

Policy case Determines available

Baseline scenario

Policy instruments

Policy settings (user defined)

Refer to


and range

simulation (user defined)

Contain

Refer toRefer to

18

The total SIAT calculation domain can be seen in Figure 13.

Figure 13 – total domain model for SIAT calculations

Simulation (user defined)

policy settings (user defined)

Refer to

policy instruments

Policy case Baseline scenario


and range

Determine available


output values

quantify Indicators Indicator values

determinesdeterminesinput values

regionalisation Determine available

Determine available

19

2.4 Domain model in UML notation The basis for the SIAT application design is based upon the domain model as described in previous paragraphs. In Figure 14 the domain model has been translated into the Unified Modeling Language (Booch 2005, Appendix A for short UML overview). UML is a standard for describing object’s relations which will be used throughout this deliverable.

In addition to a direct translation of central concepts like policy case, baseline scenario and indicator a number of classes have been added:

• composition – a model, or chain of models that behave as a composite model to calculate impacts based on policy settings;

• Factory – a helper class to build a composition based on a policy case and baseline scenario. A factory (Gamma, 1995) is a design pattern: a general reusable solution to a common design problem.

Both composition and factory are placeholder abstractions for the models. The objective of the abstractions is to have a more flexible design for SIAT facilitating future adaptations of the modelling, c.q. translation of policy settings into indicator values.

Figure 14 – class diagram of SIAT in UML notation

Figure 14 shows the static relations between the classes while Figure 15 explains the dynamic relations between some of the classes to explain how they work together to perform the task of defining a simulation and preparing a composition to start the calculation of impacts. Dynamic relations within this document are described using the UML sequence diagram notation.

20

Figure 15 – define a simulation and prepare to calculate

21

3 System requirements Requirements are documented needs of what a particular product or service should be or do (requirement, 2006). Requirements in general can be functional (what and how do you want to interact with the system), technical (e.g. Operating System, communication protocol, modelling framework) or qualitative (e.g. system response time). Requirements change as the project evolves. New requirements come up, existing ones change, some disappear and priorities shuffle on the way.

3.1 Technical requirements SIAT is a web application. The SIAT client application runs in any web browser with the Adobe Flash player installed while the server(s) provide necessary data and perform model calculations. Communication between web application and server takes place by means of an internet connection. The amount of data transferred over the internet connection can go up to 1Mb for a single call. SENSOR module5 provides a Microsoft SQL relational database which is to store all (geo)data.

3.2 Qualitative requirements Response time The response time of the SIAT web application must be such as is common in internet application. SIAT is to be used in interactive stakeholder sessions as a Decision Support System making a short response time a high priority. Scalability Currently the amount of expected simultaneous users lies within the range of tens. The server capacity guarantees short response time for this amount of simultaneous users. However, if the amount of simultaneous users rise, or model calculations become more complex taking up more processor time, the server side soft- and hardware need to be up scaled. Flexibility Flexibility is the ability to easily adapt to different circumstances. Within SIAT flexibility is defined in terms to easily add, remove, or change:

• Policy cases (policy case determines available regionalisations); • Policy case specific policy instruments; • Baselines containing exogenous parameters such as: climate change,

population growth, or technological innovations. ; • Target years; • Regionalisation (spatial resolution and extent). E.g. Member states, or Chinese

provinces; • Indicators (in terms of land use classes, impact indicators and land use

functions); • Factsheets (can be associated with any policy case, baseline, regionalisations,

region, indicator, etc.); • Models translating policy to land use changes, impact indicators, land use

functions and spatial aggregates of any of these; • Application menu structure.

3.3 Functional requirements Functional requirements describe what and how you can do what with a system. A first inventory of functional requirements was done and described in D4.2.1

22

(Haraldson et al., 2005) and D4.3 targeting questions like: i) what type of assessment would you like to do; ii) how do you want to present assessment results; iii) how to make assessments transparent; iv) is the calculation method scientifically sound; v) what is the quality of the results; and vi) what (meta) information should be included. Each of the questions above concern several functional requirements. Each of these requirements is written down as a feature request on a ticket in the form of some lines of text, sometimes with a figure for illustration. See Figure 16 for an example.

Figure 16 – sample feature ticket

Implementation time required for each ticket is bound to a maximum. If the workload of a ticket becomes big it is split into multiple tickets. The list of tickets is used to manage and document the work to be done. Tickets are worked at from the top of the list. By shuffling the tickets priorities change. The summed workload of all tickets is likely to be larger than the available capacity within the project. Tickets with a low priority might not get implemented (Beck, 2004).

23

4 System architecture In order to develop a software system the use of some logical construct (or architecture) for defining and controlling the interfaces and the integration of all of the elements of the system is needed (Zachman, 1987). Elements (e.g. database, or internet protocol) are of a certain form (e.g. relational database, or HTTP respectively) and it should be clear why these elements, of the specified form are used (rationale). Developing a system under architecture facilitates the development and maintenance of elements separately. Within the SENSOR project different consortium partners are responsible for different elements, both for development and maintenance. Elements are loosely coupled increasing reusability. The following paragraphs describe the architectural style, the general design principles, and the division into elements and their relations.

4.1 Layered architecture The architecture of a system determines early decisions about high-level system design. It describes what part(s) of the system are easy to adapt and what changes are more time consuming. The flexibility focus points of the SIAT system are:

• Data driven (in terms of policy cases, policy settings, regionalisations, indicators together with their fact sheet meta-info, and geo-related state data);

• ‘Plug and play’ of models (be it a simulation model, a meta model, knowledge rules, chain of models, static data, or a mixture of the above);

• Loose coupling of the (web based) user interface.

SIAT uses the enterprise application layered architectural style as shown in Figure 17. In this architecture the user interface, functional process logic, data storage and data access are developed and maintained as independent modules or layers, possibly on separate platforms at separate locations. As a general rule each layer has dependencies on those below it, limiting the effect of changes and increasing maintainability (Knapen et al, 2007).

Figure 17 – layered architecture

24

4.2 Architectural elements While the previous paragraph describes the use of the layered architectural style, this paragraph explains the elements in which the system is divided. Each of the elements within this paragraph can (and most likely do) concern multiple layers.

The SIAT system is divided into several elements to be able to reuse isolated functionality and to support the organizational structure of the Sensor project in which different engineering groups are responsible for development and/or maintenance of different software parts. Each element has its own functional responsibilities. Figure 18 shows the elements which make up the total SIAT system and their relation to each other. The arrows in the figure represent connecting elements between the figure rectangles which are:

• SIATGUI – Graphical User Interface; • Simulation services – access to the domain model as described in chapter ‘

25

Policies in the computational domain’ like policy cases and indicators and definition of SIAT model interface (e.g. what information should a model publish, how should the model do that?);

• SIATLinkables – specific model implementations (e.g. response functions); • Map services – policy impacts can be displayed on a map to clarify spatial

variation of impacts. This element gives access to geo-referenced images representing maps using the open standard of Web Mapping Service (WMS) (OGC, 2004);

• SLD service –generates a style (=symbolisation) per spatial entity to be used by a WMS based on calculated policy impacts. A Styled Layer Descriptor (SLD) is an open standard to formalise the styling (OGC, 2004);

• 3D landscape visualization services – impacts of an EU wide policy can differ per region. This sub system provides 3D landscape images showing how the landscape might look like as a result of the policy.

Some of the more technical terms within Figure 18 (such as ‘servlet’) are explained later in the text and are of little importance at this stage.

Figure 18 – logical division of system elements

Theoretically each element can be located at a different physical location. For practical reasons like maintenance, performance, or security this would not be optimal. SIATGUI is on a location A as it runs at the client’s machine in a web browser (Figure 19). The biggest part of the systems’ elements (simulationServices, SIATLinkables, mapServices and sldService) are on a web server on location B (hosted by consortium partner NERI of module5). With exception for the database which does not run on a web server, but on B’ for security reasons. B’ is another server within the same domain as B. The web server element 3D visualization services runs on location C for organisational reasons: it is realized by the consortium partners of wp4.4 ‘visualisations’ (LIFE, University of Copenhagen, TUM, Munchen and Lenne3D).

26

Figure 19 – physical location of system elements and organizations implementing them

4.3 Element autonomy The SIAT user interacts with the SIAT system through the SIATGUI element which uses other elements to get access to resources, like available policy cases, or use services, like the calculation of impacts for a user defined policy (Figure 20).

Figure 20 – example element interaction

Separate elements are autonomous and can be developed, maintained and tested as such. To do so, each element must have a well defined interface and behaviour.

27

For independent testing of elements’ behaviour mock elements mimic the behaviour of the elements it depends on. As example the activity diagram in Figure 21 shows how connecting to data for both the SIATGui subsystem and simulationServersubsystem are mimicked for testing purposes. An activity diagram illustrates a network of activities. The path to follow depends upon the decisions to take at path nodes.

Figure 21 – fall back options to connect to data

The SIATGUI can use a live connection to the simulationServer. It can also mimic the behaviour of the server through the same interface (more details in chapter SIATGUI) allowing isolated development (and testing). The same mechanism is implemented in the simulationServer. It can use the database for resources, or use hardcoded resources making it independent of specific data entries.

4.4 Data persistency The SIAT system uses many different types of data like policy cases, fact sheets with texts and pictures, model parameters, parameter units, maps, 3D images, etc. This information can be persisted in many ways, e.g.:

• File based (e.g. XML); • Object database; • Image based (binary memory dump); • Relational database (requires no Object Relational Mapping (ORM)); • Etc.

The SIAT application is being developed in a distributed environment (see Figure 19). Each of the elements is free to store data using its own optimal solution. E.g. the geo-data services use shape files (shapefile, 2008) to store geographical data. The following chapters describe the elements and, if applicable, the method to persist data.

28

5 SIATGUI The SIATGUI element concerns the presentation and application layer of the SIAT system and part of the services layer (Figure 17). The services layer facilitates communication with other elements, like the simulation services and mapServices.

5.1 Simulations

An important task of SIAT is to support comparison of different simulations as stated in the chapter 2 Business domain model. SIAT distinguishes between simulations that were defined outside of the tool and simulations that are defined by a SIAT user in terms of a policy case and policy settings (Figure 22).

Figure 22 – simulation

A simulation contains all information required to perform calculations determining impacts.

5.2 Data services The ServiceCentre is used to get access to data services that are used to retrieve information. Access is through an interface implemented by concrete implementations of local and remote storage (Figure 23).

29

Figure 23 – data services,

When using RemoteDataServices calculation results are requested from the simulation services element. Potentially this involves a large amount of data and might take some time to download. Figure 24 desribes how requests to the server are handled asynchronously, using the Asynchronous Completion Token (ACT) pattern (based on Knapen, 2007). The ACT pattern is implemented in the ResultDataProcessor class.

Figure 24 – ResultDataProcessor for asynchronous data retrieval

30

5.3 Visualisation factory Core for doing an impact assessment is analysing impacts of simulations expressed by indicators. These indicator outputs can be visualised in various ways. A factory design pattern (Gamma et al, 1995) is used for the creation of different types of visualisations (e.g. table, chart, or map, Figure 25). The use of a factory ensures flexibility and extensibility (based on Knapen, 2007).

Figure 25 – visualisation factory

Data provider factory Each of the visualisation outputs use the same generic data provider to access data. The DataFactory creates and formats the data from the data services into the data provider based on the VisualisationModel’s definition (Figure 26).

Figure 26 – data factory

31

Map visualisation Maps have a natural ability to instantly communicate spatial differences over a large number of regions and are therefore a crucial visualization for SIAT. As any visualization it uses a dataProvider as information carrier (Figure 25). Map display is implemented using the Model View Control (MVC) design pattern (Gamma, 1995) as illustrated in Figure 27. The controller determines how the modelis displayed in the view.

Figure 27 – MVC pattern for map visualization component (Vanmeulebrouk, 2008) A map can display several layers at the same time. E.g. an impact indicator layer, and a topography layer for orientation. Different layers can have different spatial extents (e.g. Europe, Spain, or a French department). See Figure 28.

Figure 28 – map (Vanmeulebrouk, 2008)

32

A layer can have several forms such as an imageLayer and a DataProviderLayer. An imageLayer is a geo-referenced image, while a DataProviderLayer contains true geometry like points, lines, or polygons. Each layer has an associated rendererimplementing screen rendering functionality for a specific layer class type (Figure 29).

Figure 29 – layer (Vanmeulebrouk, 2008)

5.4 Fact sheets Factsheets are short textual definitions, or explanations of concepts and assumptions supported by graphical illustrations and possible hyperlinks to more elaborated (scientific) references. They are extensively used throughout the SIAT system as found helpful in EURURALIS (Klijn et al., 2005; Rienks et al., 2008) and ATEAM (Metzger et al., 2006). Factsheets are given on a great variety of topics, like baseline scenario and it’s drivers and assumptions, indicator definitions, policy instruments, etc. A factsheet in SIAT is generally setup by a number of graphical elements such as a header, a footer, an intro and plain text, images and tables. A factsheet can be laid out in a number of columns. Factsheets are stored in an xml file based syntax and contain only the data (e.g. texts) of the factsheets. The styling (font size, font colours, etc) is directed by the SiatGUI application to centralise and make sure factsheets styling is consistent with the SiatGUI in which the factsheets appear. Figure 30 shows the xml schema file (XSD) which applies to all factsheets. An XML schema is a description of a type of XML document, typically expressed in terms of constraints on the structure and content of documents of that type, above and beyond the basic syntactical constraints imposed by XML itself. An XML schema provides a view of the document type at a relatively high level of abstraction (xml schema, 2008).

33

Figure 30 – XSD defining xml language for factsheets

5.5 Simulation persistency The SIATGUI element is implemented using Adobe Flex technology and runs in the Adobe Flash player in a client’s web browser. With Adobe Flex data can be persisted at the client’s machine using a shared object. User defined simulations (see Figure 22) are stored in a shared object to make them available across sessions.

34

6 Simulation services The main task of the simulationServices element is to offer resources and services for policy definitions and determining policy impacts. Resources and services are made available by means of servlets implementing Remote Procedure Calls (RPC) using XML to transfer data between the caller and callee (Figure 18). A Servlet is an object that receives a request and generates a response based on that request (Servlet, 2008). The simulation services give access to:

• Policy cases with policy instruments; • Baselines; • Target years; • regionalisations (e.g. NutsX, Nuts0, or cluster regions); • indicators for a given regionalisation (e.g. land use classes at NutsX); • impact indicator values for a certain regionalisation given a simulation; • symbolisation (e.g. colours) defined per indicator to be used in map display

(e.g. land use class, or a social indicator, or a land use function).

6.1 Domain logic The domain layer contains all domain logic for semantic validation (see chapter System architecture) captured in a domain model. A domain model can be thought of as a conceptual model of a system which describes the various entities involved in that system and their relationships. The domain model is created to document the key concepts and the vocabulary of the system. The model identifies the relationships among all major entities within the system and usually identifies their important methods and data fields. The domain model is especially helpful as a communication tool and a focusing point between technical and business teams (DomainModel, 2008).

All domain classes inherit from DomainObject (Figure 31) with members: • id – unique identification; • caption – screen name as shown to system user • factsheet – a Universal Resource Locator (URL) to where a elaborative

description can be found.

Figure 31 – domainObject class

Topics The SIATGUI contains a hierarchical menu structure which is dynamically built from resources (information) available published by the simulationServices (Figure 32).

35

Figure 32 – topic (after Verweij and Hoek, 2006)

Policy case A policy case contains a list of policy instruments / settings (see chapter Business domain model). The resource made available contains information on the available policy cases and instruments together with information for associated user interface controls (such as radio buttons, or slider controls). See Figure 33.

Figure 33 – policy case

Regionalisation Delineating the area of interest into several regions results in a regionalisation. In general, a region is a medium scale piece of land/water earth surface smaller than the total area of interest (after Region, 2008). The simulationServices publishes a resource containing a list of regionalisations (Figure 34).

36

Figure 34 – regions (after Verweij and Hoek, 2006)

Within SENSOR the area of interest is Europe which is divided into a number of regionalisations:

• NutsX (about 570 regions, see D3.2.2); • Nuts0, or Member state (27 administrative regions);• Cluster regions (27 regions of homogenous regions which are delineated based

on bio-physical and socio-economic attributes, see D3.2.2); • Europe (1 region for all of Europe).

Indicator The term indicator is here used as a tool measuring impacts of policies. Within SENSOR impacts are measured in terms of land use change, intermediate variables, impact indicators (economic, social and environmental) and land use functions (see chapter SIAT linkables). Indicators can be categorised and have a unit attached (Figure 35).

Figure 35 – indicator class

Symbolisation When impacts are displayed in a map they require symbolisation following the cartographic grammar as defined by Bertin (Bertin, 1973). Bertin bases his

37

cartographical grammar on different units of measurement, or data types (Stevens, 1946):

• Nominal – a set defining a mode which can be tested on equity (e.g. land use {forestry, urban});

• Ordinal – a totally ordered set defining a mean which can be tested on order (e.g. fire risk {low, moderate, high});

• Interval – a mean with standard deviation defining an affine line and has a subtraction and weighted average relation (e.g. temperature in degrees Celsius);

• Ratio – a geometric mean, or coefficient of variation for a field which can be added or multiplied (e.g. temperature in Kelvin).

Figure 36 shows how the data type differentiation relates to symbolisation (vanMeuleBrouk and Verweij, 2006).

Figure 36 – symbolisation (vanMeuleBrouk and Verweij, 2006)

38

6.2 SIATModel interface The SIATModel is the interface between the elements simulationServices and SIATLinkables (Figure 18). It defines what information the SIAT needs and can actually provide: i) regionalisations; ii) indicators and iii) request indicator values for a given policy. The SIATModel is based on the OpenMI standard for models (see chapter SIAT linkables). Figure 37 shows the SIATModel interface in UML notation. See chapter 7 for implementation design and actual implementation of this interface.

Figure 37 – SIAT model interface

39

6.3 Services The simulationServices element offers services for policy definitions and determining policy impacts. Services are made available by means of servlets. A Servlet is an object that receives a request and generates a response based on that request (Servlet, 2008). It is implemented using XML-Remote Procedure Calls (RPC), a remote procedure call protocol which uses XML to encode its calls and the Hyper Text Transfer Protocol (HTTP) as a transport mechanism. Multiple user can make use of the simulationServices element simultaneously by sending requests for resources or services. Session management is essential to be sure every response is sent to the correct request (Figure 38).

Figure 38 – session management and component dependencies

A webserver hosts the simulationServices and creates a new session for each client. Within this session each servlet runs in a new thread. The SIATApplication is the entry point for the simulationServices. This class is called by the servlets to generate a response based on the request. In some cases this class uses the SIATModel (the interface between the elements simulationServices and SIATLinkables, Figure 37). Both SIATApplication and SIATModel access the SIAT database. One connection to the database for all clients is used. Only read actions are done. No conflict can occur. However each servlet needs its own instance of the SIATApplication and SIATModel.

40

6.4 Data persistence The simulation server uses a RDBMS (Relational database management system) to store data. Relational means that the data is stored in the form of tables and the relationship among the data is also stored in the form of tables. Currently it is implemented on a Microsoft SQL server (Figure 18).

Figure 39 – Entity Relation Diagram of simulationServices element

Figure 39 shows the RDBMS tables and their relations. Several parts can be recognized and are identified:

• Variables/Indicators – Contains data of the variables (indicators, landuse functions and landuse classes). At which scale they are available and the symbolization used for that scale;

• Symbolisation – Data on how results are presented for each variable and scale. • Regionalisation – Regionalisation (table scale) and the regions belonging to

that scale (table ScalexRegion) • OpenMI: Datatypes – OpenMI part containing data of the datatypes of the

variables • Policycase – Definition of the policycase and policysettings.

41

7 SIAT linkables The SENSOR project deals with land use related policies on a pan European regional scale. Europe is therefore subdivided into about 570 NutsX regions (D3.2.2). The cause-effect relation between policy – and exogenous drivers and indicators concerns the conversion of drivers into i) land use changes; ii) relating land use changes to impact indicators of the environmental, social and economical dimensions and iii) assessing regional sustainability limits for the indicators by means of land use functions (D3.2.2). Each of the above conversions is done by a separate software component. The components are linked up together (see Figure 40).

Figure 40 – composition of modeling components The following paragraphs explain how the meta-model has been derived, how the knowledge rules are conceptualised, the land use function model has been setup, the open source OpenMI model linking framework standard and the use the OpenMI for the SIAT models.

7.1 Modelling the cause effect relation Land use changes and intermediate variables The translation of policies into land use changes is based on a modelling framework containing a macro-economical model NEMISIS (at member state level), a land use allocation model CLUE (at 1x1 km2) and sector models CAPRI and EFISCEN (forestry, agriculture, energy and transport, tourism and urban). See Figure 41.

Figure 41 – modeling framework for land use changes and intermediate variables (D2.2)

42

The macro-economical model translates exogenous drivers such as population growth and energy prices into macro-economical variables as Gross Domestic Product and land use claims per member state. The land use allocation model determines where (at 1x1 km2) what land use claims are actually effected (SENSOR, module2). The models themselves, however, are not part of the SIAT software tool. SIAT is a quick scan tool, which requires little training to use and has a short response time. The modelling framework consists of complex models which require experts (both in domain and technical knowledge) to work with. Instead the models within the framework have been run several times to determine responses to policy settings for a number of intermediate variables (such as land use classes). An interpolation between the response points results in a so-called response function. A response function defines the relation between a single policy instrument and a single intermediate variable (such as a land use change). See Figure 42.

Figure 42 – determining response function from model runs (after Kuhlman and Jansson, 2007)

The line fitting interpolation will not fit 100% the modeled responses. To get an even looking policy impact value, the response function is also used for baseline result value calculation instead of using the modeled baseline result value.

The available baselines (paragraph Baseline scenario) can be seen in Figure 42. Only for the ‘business as usual’ a policy can be defined as for this baseline a response curve is made available. All baselines (and the policy in those baselines) are defined for the single target year of 2025. The baselines low- and high growth are taken up in the modeling to take in the uncertainty of (exogenous) future developments such as world population, or oil price (see SENSOR module2). A response function defines the relation between a single policy instrument and a single intermediate variable. Each region responds differently to a policy so that every regions’ response function differs per policy instrument per intermediate variable. Besides, response functions can only be defined for policy instruments of a

43

continuous data type (e.g. the percentage of direct support for the CAP). Enumerated data types within the same policy case need a new set of response functions relating the continuous policy instrument with each intermediate variable (such as market support, or re-invest in R&D). From a modeling perspective the amount of functions is large (Figure 43). From a software engineering perspective, the amount of functions to store in a database, or execute is small (about 570*100*4 = 228000) compared to administrative, financial, or GIS systems.

Figure 43 – unique response function per region, variable and policy case

Indicator rule While response functions are specific to a region and a policy case, an indicator rule is more generic. It describes the relation between a number of intermediate and state variables and the indicator. It can take both a quantitative or qualitative form. Figure 44 illustrates how intermediate variables from the previous paragraph are used within the indicator rule (e.g. forest coverage and traffic intensity). The rule also uses so-called state variables, variables that are expected to be static throughout the modeling exercise (e.g. present spatial cohesion and present forest coverage). Indicator rules have been derived by experts based on currently available data and within SENSOR modeled results (SENSOR module2) and are valid within that frame.

44

Figure 44 – example indicator rule

7.2 Model composition SIAT is designed to hold a number of modelling components for the conversion of policy- and exogenous drivers into indicators. Within the SENSOR project 3 modelling components are designed for implementation:

• ResponseFunctions – the main responsibility of this component is to translate policies into intermediate variables by making use of mini model versions of Capri, Nemisis, Clue and sector models for the ‘business as usual (2025)’ baseline. For the other baselines (Figure 42) only static responses (no policy changes possible) are determined;

• IndicatorFunctions – translating responses into indicator values; • landuseFunctions – translating indicators into land use function values.

Each of the models is designed as a separate piece of software (Figure 45) accessible via a standardised interface (see next paragraph). Response and indicator functions can make use of state data, i.e. data that is expected not to change within the scope of the modelled time interval. e.g. soil, or average precipitation.

Figure 45 – linkable component dependencies

Policies can be defined for the ‘business as usual’ in the near future of 2025 (see Figure 42). The present situation and other baselines have pre-calculated responses which are put into the database and can be loaded to continue with indicator and land use function calculations as usual (see Figure 46). See D4.3.2 (Sieber et.al., 2009) for details on the implementation of response and indicator functions. By putting them in the database they can be updated without recompiling the models’ implementation.

45

Figure 46 – activity diagram for determining response values

7.3 Open Modeling Interface (OpenMI) Introduction The standardisation of the model interface make it technically possibly to exchange a model with another. The open standard used is the European Open Modelling Interface (OpenMI). OpenMI is the main product of the 5th framework programme project HarmonIT (www.harmonit.eu). OpenMI defines software interfaces and comes with documentation on how to use them. Furthermore it contains a reference implementation, both in the Microsoft .Net framework and the open source language Java. OpenMI is used by a large international community (within and outside of Europe) and is under constant development supervised by the OpenMI association (www.openmi.org). Each model (e.g. response function model, or indicator rule model) is wrapped within a standardised interface called a LinkableComponent. LinkableComponents can be linked to each other building a chain of models. In OpenMI terminology a model chain is called a composition of LinkableComponents. Figure 47 shows how a LinkableComponent (e.g. A, the land use function model) can request calculated values from another linkableComponent (e.g. B, the indicator rule model). OpenMI is a pull-based system. Only calculations are performed that are needed to reply to the trigger request. If the trigger from Figure 47 were connected to linkableComponent B, then linkableComponent A would never be calculated.

46

Figure 47 – composition of linkableComponents

Linkable Components are autonomous. The LinkableComponent wrapper manages dependencies to other Linkable Components. That is, the wrapped model can perform its calculations by itself, but has no knowledge at all of where its input data comes from and where its output data goes to. To be able to do this the data needs to be well defined in terms of:

• data description o what (e.g. indicator fire risk {low, moderate, high}, or forest area

[hectares]) o where (e.g. member state boundaries); o when (not relevant for sensor as its response functions are derived for

2025 only) • data linking (link models to each other semantically); • data transfer (pull another models calculation results).

Qualitative data extension An OpenMI LinkableComponent is a standard wrapper interface around a model. Each LinkableComponent publishes required input and available output by a standard interface called ExchangeItem. An exchangeItem describes what data is available where (Figure 48). E.g. bio energy crops per hectare per Nuts3 region.

Figure 48 – Exchange items and links

Figure 49 shows how OpenMI version 1.2 describes data by means of an exhangeItem in terms of:

• what (quantity). E.g. bio diesel crop in hectares; • where (elementset). E.g. Nuts3 regions.

47

Figure 49 – exchangeItem definition in OpenMI version 1.2

Sensor concerns indicators in terms of quantities (e.g. Gross Domestic Product in Euro) which is supported by OpenMI, but also in terms of qualities. Both for nominal and ordinal data types (Stevens, 1946). E.g. land use {urban, agriculture, forest, etc.}, or fire risk {low, medium, high} respectively. By putting a generic dataType interface for the ‘what’ part of the data description in the exchangeItem interface it is possible to include qualitative data description (Figure 50). Furthermore the generic dataType interface makes it possible to describe data as fuzzy sets, stochastics, include reliability information, etc (Verweij, 2007).

Figure 50 – exchangeItem definition in OpenMI version 1.4 support quantities necessary for SENSOR

Specifying regionalisations OpenMI specifies ‘what’ information can be exchanged ‘where’ through the exchangeItem interface (Figure 50). The SIAT linkableComponents (Figure 45) publish information on inputs (e.g. intermediate variables at NutsX level) and outputs (e.g. indicators on Nuts0 level) through these exchangeItem interfaces. The amount of exchangeItems’ ‘what’ part required per LinkableComponent can be derived from Figure 43 and is summed up in Figure 51 together with the ‘where’ part.

Input Output Linkable Component What [amount] Where What [amount] Where

Response - - 100 NutsX, Nuts0 Indicator 150 (from state

and response) NutsX, Nuts0 (from state and response)

40 NutsX, Nuts0

Land use function

40 (from indicator)

NutsX, Nuts0 (from indicator)

9 NutsX, Nuts0, Cluster region and EU

State - - 50 NutsX Figure 51 – estimated number of exchange items

The administration of exchangeItems per linkableComponent varies from tens to hundreds. To reduce the amount of exchangeItems and the amount of links required

48

between linkableComponents (Figure 48) several elementSets are grouped as can be seen in Figure 52.

Figure 52 – compound elementset (after de Winter, 2006)

SENSOR Linkable components Linkable components are autonomous. Each LinkableComponent manages its own calculation, data persistency and (if necessary for optimization purposes) caching of results. Interlinkage and consistency checks between components are the sole responsibility of OpenMI. Although data persistency for separate components can be realized through the same database (be it relational, file based, etc) no relations may exists between those other than via OpenMI to maintain the flexibility of the system. Within the Sensor project specializations of LinkableComponent’s are being developed (Figure 53) which relate to each other as described in Figure 45:

• Response function; • Indicator function; • Land use function; • State data.

49

Figure 53 – specialisations of linkable components

See Appendix B for a sample business logic - and database design and implementation for evaluating mathematical functions such as response functions for land use functions and indicator functions. Appendix D gives a short overview of the implementation of the Land Use Function model. A complete description of the implementation of the LinkableComponents can be found in D4.3.2 (Sieber et.al., 2009).

7.4 Data persistency The SIATLinkables element uses the same physical relational database as the simulationServices element (see chapter Simulation services) in order to have the database implement data consistency checks by means of foreign keys. See D4.3.2 (Sieber et.al., 2009) for implementation details on table structure specific for responseand indicator LinkableComponent data.

50

8 Map and Styled Layer Descriptor services 8.1 Introduction The map services element publishes a Web Map Service (WMS) for impact maps at different scales (e.g. NutsX, Member state). The MapService element publishes the geometry of different regionalisations and works together with the Styled Layer Descriptor (SLD) Service element for symbolization information of each region (Figure 54).

Figure 54 – retrieve a map image

8.2 WMS and SLD specification A Web Map Service (WMS) produces maps of spatially referenced data dynamically from geographic information. A "map" is a portrayal of geographic information as a digital image file suitable for display on a computer screen. The WMS specification standardizes the way in which maps are requested by clients and the way that servers describe their data holdings (Open Geospatial Consortium 2004). Clients request maps from a WMS instance in terms of named layers and provide parameters such as the size in pixels of the returned map as well as the spatial reference system to be used in rendering the map. WMS defines a number of operations. Some of these operations are obligatory for any WMS to implement while others are optional:

• GetCapabilities (obligatory) – obtain service-level meta-data which is a machine (and human) readable description of the WMS’s information and acceptable request parameters;

• GetMap (obligatory) – Obtain a map image whose geospatial and dimensional parameters are well-defined;

• GetFeatureInfo (optional) – Ask for information about particular features shown on a map;

51

A basic WMS has limited styling capabilities. Styles are defined server-side. The administrator of the WMS may define multiple named styles for each layer in the WMS. Clients can request maps in the default or in one of these named styles.

A SLD enabled WMS has more styling capabilities. Styles can be defined client-side. A Style Layer Descriptor (SLD) is a XML encoded document for the definition of the styles of geographic features. If a WMS supports Style Layer Descriptors it should also implement the following optional operations:

• DescribeLayer (optional) – obtain feature/coverage type information of a named layer;

• GetLegendGraphic (optional) – ask for a generated legend.

Clients may define custom styles using SLD and pass these to the WMS to have the map styled using the custom style. Custom SLD’s can either be passed in the WMS GetMap request directly or as a URL referring to the SLD.

52

9 Software quality assurance Quality assurance provides critical support for maximum development speed. Quality assurance is a planned and systematic pattern of all actions necessary to provide adequate confidence that an icon or product conforms to established technical requirements (ISO, 2008) When a software product has too many defects, developers spend more time fixing the software than they spend writing it. The key to not installing defects, is to pay attention to quality assurance from the beginning (McConnell, 1996). Software quality assurance (SQA) consists of a means of monitoring the software engineering processes and methods used to ensure quality. It does this applying a quality management system under which the software system is created. The processes controlled are: software design, coding, source code control, code reviews, change management, configuration management, and release management (software quality assurance, 2008).

The following paragraphs explain what software development methodology was chosen in order to monitor and steer the development process (paragraph 9.1) and what quality control instruments are used to make sure everything works as designed to (paragraph 9.2 to 9.4).

9.1 Evolutionary delivery Evolutionary delivery is a lifecycle model that facilitates rapid development (Figure 55). It is chosen as it provides the ability to change the product direction mid-course in response to changed requirements. It leads to improved product quality, reduced code size and more even distribution of development and testing resources.

53

Figure 55 – evolutionary delivery (after McConnell, 1996)

To communicate the software concept and the preliminary analyses of the requirements, prototype I was produced. After which the architecture and system could be designed (chapter System architecture). From now on deliveries of the SIAT product can be delivered iteratively. After each delivery, feedback is gathered and translated into new requirements. Usability is ensured through the use of interaction design (chapter 10). The Software Quality Control consists of a means of controlling the quality of software engineering products by formally proofing individual pieces of code (unit- and integration tests), and the review of documents and code (software quality control, 2008).

9.2 Source code Version and configuration control All produced code under the flag of SIAT is maintained in a code version and configuration control system. During development source code is changed continuously. New functionality is added, existing functionality is redesigned to work with new code, or needs to be optimised. Changes can have unforeseen effects in which it is crucial to be able to go back to the latest stable situation, find differences and solve the introduced artefact. A version control system facilitates the process to go back to previous states of the code. Naming conventions Names of packages, units, modules, components etc. must adhere to the standard on naming conventions, such as: i) packages names in lower case; ii) class names in

Prototype I (throwaway version)

Design of architecture and system

core

Preliminary requirements

analyses

Software concept

Elicit feedback

Develop a version

Deliver the version

Incorporate feedback

Deliver final version

54

camel case; iii) constants in upper case with underscore and iv) private fields in lower case. Code review Each piece of code should be reviewed by a peer. Review takes place continuously and during programming, as can be the case in a Paired Programming approach (Heiberg et al., 2003). Otherwise, peers must be able to review code in an asynchronous way.. Code documentation All software should be self-documented, containing a list of meta-information following the java doc standard (sun, 2002):

- Version etc.; - names of author and reviewer, - date of development; - purpose of component / unit; - status of development; - base documents leading to this development (requirements, design etc.); - dependency on other units.

9.3 Testing Testing takes place constantly. Unit- and integration- and database are tested continuously during each iteration. The system- and the system integration test is done once at the end of each iteration. Unit test All code units must pass the accompanying unit test. unit testing is a procedure used to validate that individual units of source code are working properly. A unit is the smallest testable part of an application (unit test, 2008). Integration test Integration testing takes as its input units that have been unit tested, groups them in larger aggregates (modules), and applies automated tests. Database test Database tests include performance tests for authentication, authorisation and execution of database queries. The data integrity checks whether the data within the database complies with the specified requirements, such as ‘an indicator must have a name’, or ‘a regionalisation contains at least one region’, etc. System test System testing of software is testing conducted on a complete system to evaluate the system's compliance with its specified requirements. A system is one of the architectural elements as defined in paragraph Architectural elements. There is no interaction with other systems in this test phase. System integration test This is a test process that exercises a software system's coexistence with others. System integration testing takes multiple systems (paragraph Architectural elements) that have passed system testing as input and tests their required interactions.

9.4 Documentation Software documentation is done by means of deliverable reports as stated in the SENSOR Implementation Plan.

55

10 Interaction and graphical design 10.1 Introduction Interaction Design is the discipline of defining the behavior of products and systems that a user can interact with. Basic principles of cognitive psychology provide grounding for interaction design. These include mental models, mapping, interface metaphors, and affordances. Academic research in Human Computer Interaction (HCI) includes methods for describing and testing the usability of interacting with an interface, such as cognitive dimensions and the cognitive walkthrough. Interaction design is typically done through iterative cycles of user research (interaction design, 2008). Graphic design is the process of communicating visually using text and images to present information. Graphic design practice embraces a range of cognitive skills, aesthetics and crafts, including typography, visual arts and page layout. Like other forms of design, graphic design often refers to both the process (designing) by which the communication is created and the products (designs) which are generated (graphic design, 2008)

The objective of Prototype I was to show how the different SENSOR concepts could be integrated, prototype II focuses at (technical) operationalisation and the final SIAT builds on prototype II and operationalises more of the (reviewed) prototype I and additional concepts.

10.2 Prototype I Prototype I has a navigation menu on the left and a strong wizard like interface for guiding a user through the process of defining a policy and analyzing it’s impacts . Related fact sheets are directly visible in the same screen as can be seen in Figure 56.

56

Figure 56 – screenshot of prototype I

Within prototype I a user defines his simulations by: 1. choosing a reference scenario (called baseline in prototype II) and view a fact

sheet in the same screen describing the main drivers of the scenario (e.g. population growth, or energy price). There are three choices: i) business as usual; ii) low growth and iii) high growth;

2. defining a policy by choosing a policy case and setting the policy case’s specific instrument values (e.g. policy case ‘renewable energy’, instrument ‘subsidy on renewable’ at 80 euro per hectare). A fact sheet for the chosen policy case is shown at the same screen (Figure 56);

3. viewing impact indicators and land use changes by a map for the NutsX regionalization. Each indicator links to an associated fact sheet and is accompanied by a quality estimation (in terms of weak, moderate and good);

4. viewing a pan European NutsX map in which sustainability limits are applied to each of the indicators. An indicator scores either within or outside of the pan European limit for a NutsX region.

10.3 Prototype II Prototype II has two main entry points to the tool (Figure 57):

• Impact assessment – to define your policies, to view and compare impacts; • Background – methodologies, available policies, project context, etc..

Figure 57 – prototype II, introduction screen

Within Prototype II the navigational menu is put on top and the wizard like interface, although illustrative during presentations, is abandoned. The location to define a simulation is on the left column which is always visible when defining a policy and

57

viewing it’s impacts. The right of the screen is used to view impacts. During definition of a new policy the right side of the screen is used to assist the user in how to define a simulation as can be seen in Figure 58.

Figure 58 – define a simulation

By pressing the ‘Go’ button the impacts are determined for the defined policy. By default this results in a spider graph showing the sustainability valuation in terms of land use functions at EU level: an overview of the impacts of the defined policy. Both the ‘business as usual’ and user defined policy are shown within the same graph to visualize differences between both (Figure 59).

Figure 59 – default impact visualization

SIAT methodological process

Navigational menu

Main screen

58

The SENSOR methodological chain of 1) defining a policy; 2) looking at land use changes as result of policy; 3) translating land use changes to impact indicators and 4) doing a sustainability valuation in terms of land use functions is visible through the arrow formed buttons just above the impact valuation. The choice between several baselines as basis for an impact assessment as available in prototype I has become obsolete; policies can only be defined for the ‘business as usual’ baseline. The arrow formed buttons give access to a menu to define a corresponding visualization (Figure 60).

Figure 60 – define land use change visualization

When browsing the ‘Background’ the left menu for defining a policy is replaced for a third level navigation while the main screen is used to display fact sheets. The use of Fact sheets is taken from the Ateam (Metzger 2004) and the Eururalis tool (Klijn 2005). The screen structure is kept similar for tranquility (Figure 61).

59

Figure 61 – background fact sheet

10.4 SIAT ’final delivery’ Application startup The final SIAT is built on prototype II and uses the same two main entry points to the tool (Figure 62):

• Impact assessment – to define your policies, to view and compare impacts; • Background – methodologies, available policies, project context, etc..

Figure 62 – screenshot SIAT: introduction screen showing main application entry points

Impact assessment – simulations The definition of a simulation and analysis of the impacts are split up in separate tasks within the user interface (Figure 63). A simulation is defined by:

1. choosing a policy case; 2. choosing (or creating a new) simulation for that policy case; 3. specification the baseline scenario and target year and; 4. the setting of policy instruments. Policy instruments are specific to a policy

case (see chapter 2, Business domain model). Factsheets can be accessed to view a short description of the policy case and it’s policy instruments, or the baseline.

60

Figure 63 – SIAT screenshot indicating the location for ‘defining a simulation’ and ‘analysing it’s impacts’

Initially all sustainability impacts are shown by means of Land Use Functions spatially aggregated over the EU to give a broad overview of the impacts. The Land Use Functions’ score is presented in a spider diagram from which the policy impact in relation to the sustainability limit can be analysed (Figure 64).

Figure 64 – SIAT screenshot: aggregated impact overview

Define simulation

Fill in details and press ‘determine impacts’

Press ‘i’ to view factsheet

Analyse impacts

Guide explains what to do

61

More in depth impact analysis functionality is available under ‘Analyse impacts’. Impacts can be presented through several visualizations:

1. bar chart; 2. map; 3. table; 4. spider chart.

For each of the visualizations the user can select the: i) regionalisation (spatial extent and resolution such as: EU, member state, cluster region, or NutsX) and; ii) the indicator(s) of interest. Figure 65 is a sample screenshot. It displays a number of Land Use Function impacts for a number of member states. The red lines represent the member state specific limits, while the coloured bars represent the Land Use Function score for that specific member state. Note that limits vary per member state.

Figure 65 – SIAT screenshot: impact display example

Impacts can also be viewed in a map. In case of Land Use Function display the limit sensitivity can be analysed by tweaking the limit by a slider control (see Figure 66). If the limit sensitivity is high a small change of the slider will cause direct change in sustainability and vice versa.

Choose display type

Choose resolution

Choose indicators

Press ‘update visualisation’ to update the impact

Access to factsheets

62

Figure 66 – SIAT screenshot: analysing limit sensitivity

You can click any region within the map to see how the sustainability indication was determined (see Figure 67), read on the calculation method in a fact sheet, or find even more details by drilling further down.

Figure 67 – SIAT screenshot: drill down Land Use Function calculation

Impact values can also be exported to the clipboard for further analysis in tools like Microsoft Excel. Impact assessment – Compare simulations Impacts of different simulations can be compared in a league table (see Figure 68). The league table show all Land Use Functions’ scores for all simulations defined for a policy case and a single region (be it a cluster region, a member state, or the EU).

Drill down further into the cause-impact chain and access fact sheets

63

As with Land Use Function maps (see Figure 67) the Land Use Function display in the league table can be used to drill down into Land Use Function calculation by clicking a cell within the table. The table can also be sorted by clicking the columns.

Figure 68 – SIAT screenshot: league table for comparing simulations

64

Background The background section of the SIAT is reserved to give information on methods and concepts used within the tool as developed within the SENSOR project, such as: the indicator framework, the modeling framework and the spatial regional reference framework. The factsheets in here contain links to: i) other factsheets; ii) websites and; iii) references to scientific publications. Figure 69 shows a part of the available factsheets (listed on the left of the screenshot) and an example of the factsheet ‘SIAT’. For details on available factsheets and factsheet contents see project report D4.3.2 (Sieber et.al., 2009).

Figure 69 – SIAT screenshot: Background factsheet example

65

11 State of affairs 11.1 Introduction This deliverable report is called ‘SIAT - system design and architecture’. As such, the previous chapters describe overall requirements, -architecture, -system design and core system implementations of the SIAT system. Main flexibility characteristics of the SIAT system are the freedom to add:

a) policy cases with several baselines and target years; b) indicators (land use classes, indicators of the environmental, economic and

social dimension and land use functions); c) area of interest and resolution (like different NUTS for EU, Brazilian regions,

or Chinese provinces at 10 km2); d) models / data implementing the policy-impact ‘cause-effect’ chain; e) context sensitive explanatory fact sheets (e.g. for linking to indicators, policy

cases and regions) and; f) dynamic menu structure linking fact sheets together.

The previous chapters within this Deliverable report describe how the system is setup to decouple data and models from the system core (see flexibility points above).This chapter describes what data and software components are available and have been implemented into the SIAT system and thereby provide the test for the architectural setup and functional and technical system design.

11.2 Policy cases The SIAT web application offers the user a list of policy cases as available within the database (flexibility point a in 11.1.). Currently this database contains the policy case ‘CAP financial reform’ for the baseline ‘business as usual’ and target year ‘2025’. Please see D4.3.2 (Sieber et.al., 2009) on data status details.

11.3 Converting drivers to impacts General setup The SIAT system converts drivers (like policy, technological innovations, climate change, or population growth) into spatial explicit indicators of a quantitative, or qualitative form (see Figure 8). This conversion can take place by applying several strategies:

• Look up indicator values in a database • Modeling

o (meta) model o Knowledge rule o Chain of models

• Mixture of the above A generic interface for doing these conversions has been designed to be able to achieve flexibility points b, c and d from the list in 11.1. This interface is discussed in paragraph 6.2. SENSOR planned to have 4 modeling components implemented (see appendix C for planning and Figure 40 for model composition):

1. meta model of response functions for translating drivers into land use change classes;

2. database with thematic data which is presumed to be static throughout the SENSOR modeling process;

66

3. knowledge rule model for determining impact indicators (environmental, economic and social) based on drivers, land use changes and static data;

4. model of Land Use Functions. Implementation details 1, 2 and 3 is part of project report D4.3.2 (Sieber et.al., 2009). Land Use Function model setup (4) can be read at appendix D. Model availability One of the model implementations has been completed and is integrated into the SIAT system: the Land Use Function model. However, the Land Use Function model requires impact indicators as input to be executed. To be able to test the SIAT system setup and run the Land Use Function model a Impact Indicator database component has been developed replacing the 3 missing modeling components (Figure 70).

Figure 70 – model availability for converting drivers into impacts

11.4 Transparency The need to perform transparent assessments focuses on the explanation of terminology, (modelling) assumptions and drilling down the cause-effect chain (Verweij et al, 2006). Factsheets Factsheets give access to short explanations and facts and can contain references (hyperlinks) to more elaborate background documents. The SIAT application enables buttons to access context sensitive fact sheet based on factsheet data availability within the database. These factsheets include information on: policy cases, baselines, land use classes, indicators, land use functions and spatial entities. Please see D4.3.2 (Sieber et.al., 2009) on status details. The SIAT application builds it’s menu structure based on the data found within the database. For example: all ‘background’ topics and their structure, like spatial regional reference framework and indicator framework is dynamically build from the database. See paragraph 6.1 on menu Topics for technical design and D4.3.2 (Sieber et.al., 2009) on content status details. Drill down Understanding the factors that drive the effects of a policy and knowing the assumptions is key in improving the policy. Meta-models and knowledge rules can be

67

setup in such a way that they facilitate the drill down of models to increase understanding of the cause-effect relationship. Drill down is to be enabled from the effect visualisation, i.e. from the modelled result backwards. Drill-down functionality can also (give a start to) clarify regional differences. For example each (regional specific) response function, or the decision path used for the quantification of a (region specific) indicator value can be visualised. Additionally, causal diagrams illustrate relations between modelled variables (see Figure 71).

Figure 71 – concept screen design: drill down the calculation chain (concept only!)

Drill down is available for all integrated models: the Land Use Function model (see Figure 67). See paragraph 11.3 on Model availability.

11.5 Landscape perspectives in 3D Landscape perspectives give a visual birds eye impression of how a landscape may look in the future with and without applying a policy (see D4.4). The future images can be accessed from different contextual locations within the SIAT as illustrated in Figure 72.

68

Figure 72 – concept screen design: accessing 3D landscape perspectives (concept only!) The 3D landscape perspective images are presented in pairs: i) the future baseline and ii) the future baseline with applied policy. The perspectives are accompanied by: a) what indicators were used to produce the image and b) what additional information was used (e.g. detailed soils and elevation map). The 3D landscape perspective is not integrated into the SIAT.

11.6 Editing of indicator knowledge rules Editing of indicator knowledge rules is done through the indicator knowledge rule model. Since this model is not integrated within the system no effort has been put on the development of the editor (See paragraph 11.3 on Model availability).

69

References • Beck, K., 2004. Extreme programming explained, second edition. Addison-

Wesley. • Bertin, J. 1967 La Semiologie Graphique (Cartographic grammar) • Champeaux, D., Lea, D. and Faure, P., 1993. Object oriented system design.

Addison Wesley • Domain model (2008, May 5). In Wikipedia, the free encyclopedia. Retrieved

May 5, 2008 from http://en.wikipedia.org/wiki/Domain_model • European Commission, Impact assessment guidelines. SEC791, 2005 • Gallopín G.C. (1997), “Indicators and their use: information for decision

making”, in Moldan B. and Billharz S. (Eds), Sustainability Indicators. Report on the project on Indicators of Sustainable Development, John Wiley and Sons, Chichester

• Gamma E., Helm, R., Johnson R. and Vlissides J.(1994), Design Patterns: elements of reusable object-oriented software. Addison Wesley, ISBN: 0201633612.

• Gijsbers, P.J.A., R.V. Moore, C.I. Tindall (2002) Towards OMI, an Open Modeling Interface and Environment to harmonise European developments in water related simulation software, Hydro-informatics, 2002.

• Grady Booch, James Rumbaugh, Ivar Jacobson, 2005, The unified modeling language user guide,

• Graphic design (2008, May 6). In Wikipedia, the free encyclopedia. Retrieved May 6, 2008 from http://en.wikipedia.org/wiki/Graphic_design

• Hansen, H.S., Viuf, P., Loibl, W., Peters-Anders, J., Zudin, S., Vogt, J., 2008. Requirement for data managent and maintenance to support regional land use research. In: K. Helming, P. Tabbush and M. Perez-Soba (Editors), Sustainability impact assessment of land use changes. Springer, pp. 425-450.

• Haraldsson, H., Sverdup, H., Lankhorst, J.R.-K., Verweij, P.J.F.M., Wascher, D., Sieber, S., Helming, K. and Müller, K., 2005. Report on the conceptual approach, SENSOR project deliverable.

• Heiberg S., Puus, U., Salumaa, P., Seeba, A., 2003, “Pair-Programming Effect on Developers Productivity” in “Extreme Programming and Agile Processes in Software Engineering” , DOI - 10.1007/3-540-44870-5_27

• Helming K., Tscherning, K., Koning, B., Sieber, S.,Wigering, H., Kuhlman, T., Wascher, D., Perez-Soba, M., Smeets, P., Tabbush, P., Dilly, O., Huttl, R., Bach, H., 2008. Ex ante impact assessment of land use changes in European regions – the SENSOR approach. In: K. Helming, P. Tabbush and M. Perez-Soba (Editors), Sustainability impact assessment of land use changes. Springer, pp. 425-450.

• Interaction design (2008, May 6). In Wikipedia, the free encyclopedia. Retrieved May 6, 2008 from http://en.wikipedia.org/wiki/Interaction_design

• Java servlet (2008, May 6). In Wikipedia, the free encyclopedia. Retrieved May 6, 2008 from http://en.wikipedia.org/wiki/Servlet

• Klijn, J.A., Vullings, L.A.E., van de Berg, M., van Meijl, H., van Lammeren, R., van Rheenen, T., Veldkamp, A., Verburg, P.H., Westhoek, H., Eickhout, B., 2005. The EURURALIS study: technical document. Alterra-rapport 1196. Alterra, Wageningen

• Knapen, M.J.R. SEAMLESS, Deliverable D5.3.9

70

• Knapen,M.J.R., Verweij, P.J.F.M., Wien, J.J.F., 2007, Applying enterprise application architectures in integrated modeling, Modsim2007, Christchurch, New Zealand

• M.J. Metzger, M.D.A. Rounsevell, L. Acosta-Michlik, R. Leemans and D. Schröter, The vulnerability of ecosystem services to land use change, Agric. Ecosyst. Environ. 114 (2006), pp. 69–85.

• McConnell,S., 1996, Rapid development, taming wild software schedules, Microsoft press, Redmond, Washington

• Nilsen, R., Kogut, P. and Jackelen, G., 1994. Component Provider's and Tool Developer's Handbook Central Archive for Reusable Defense Software (CARDS) STARS Informal Technical Report Unisys corporation

• Open Geospatial Consortium Inc. (2004), Web Map Service. WWW document http://www.opengeospatial.org

• Pérez-soba, M., Petit, S., Jones, L., Bertrand, N., Briquel, V., Omodei-Zorini, L., Contini, C., Helming, K., Farrington, J., Mossello, M.T., Wascher, D., Kienast, F. and Groot, R.d., 2008. Land use functions — a multifunctionality approach to assess the impact of land use changes on land use sustainability In: K. Helming, P. Tabbush and M. Perez-Soba (Editors), Sustainability impact assessment of land use changes. Springer, pp. 375-404.

• Potschin, M. and Haines-Young, R., 2008. Making Sustainability Impact Assessments: Limits, Thresholds and the Sustainability Choice Space. In: K. Helming, P. Tabbush and M. Perez-Soba (Editors), Sustainability impact assessment of land use changes. Springer, pp. 425-450.

• Quality assurance, 2008, software and systems engineering vocabulary, fcd24765 , iso geneve 2008

• Region (2008, May 6). In Wikipedia, the free encyclopedia. Retrieved May 6, 2008 from http://en.wikipedia.org/wiki/Region

• Requirement. (2006, June 22). In Wikipedia, The free encyclopedia. Retrieved June 22, 2006, from http://en.wikipedia.org/wiki/Requirement

• Roos-Klein Lankhorst, Janneke, Sjerp de Vries, Peter verweij, Hans Farjon, 2004. KELK gunt bestuurders een blik op toekomstige kwaliteit landschap. ViMatrix juni 2004, jaargang 12, nr. 4, Pp 38-39.

• Sieber, S., Fricke, K., Pohle, D., Muller, K., 2009, Report on knowledge base: implementation of response- and indicator functions and factsheets for Sustainability Impact Assessment Tool SIAT, Project deliverable report D4.3.2.

• Shapefile, 2008, retrieved from http://www.esri.com/library/whitepapers/pdfs/shapefile.pdf on December 9 2008.

• Software quality assurance (2008, May 6). In Wikipedia, the free encyclopedia. Retrieved May 6, 2008 from http://en.wikipedia.org/wiki/Software_Quality_Assurance

• Software quality control (2008, May 6). In Wikipedia, the free encyclopedia. Retrieved May 6, 2008 from http://en.wikipedia.org/wiki/Software_quality_control

• Stevens, S.S.,1946, On the Theory of Scales of Measurement, Science, sciencemag.org, http://www.sciencemag.org/cgi/content/citation/103/2684/677

• Sun MicroSystems Incorporated, 2002, javadoc, retrieved at may 13, 2008, http://java.sun.com/j2se/1.4.2/docs/tooldocs/windows/javadoc.html

71

• Unit Test (2008, May 6). In Wikipedia, the free encyclopedia. Retrieved May 6, 2008 from http://en.wikipedia.org/wiki/Unit_test

• Vanmeulebrouk, B., Groot, h. de, Hoogerwerf, M., Kuyper, M. (2008), Integration of Geo-Spatial Web Services Using Adobe Flex, ESRI conference, in prep.

• Verweij, P.J.F.M., Knapen, M.J.R., Wien, J.J.F., Jansen, J.M.L., Roller te, J.A., Sieber, S., 2009, Sustainability Impact Assessment – the quick scan tool SIAT, Ecological modeling (submitted)

• Verweij, P.J.F.M., Knapen,M.J.R., Wien,J.J.F., 2007, The use of OpenMI in model based integrated assessments, Modsim2007, Christchurch, New Zealand

• Verweij,P.J.F.M., Hoek, S., 2006, Eururalis 2 technical design, unpubl. www.eururalis.eu

• Verweij, P., Sieber, S., Wien, J. and Müller, K., 2006. SIAT, a sustainable impact assessment tool for understanding the drivers in integrated impact assessment, International Congress on Environmental Modelling and Software iEMSs 2006, Burlington (Vermont), USA.

• Xml schema (2008, December 5). In wikipedia, the free encyclopedia. Retrieved December 5, 2008 from http://en.wikipedia.org/wiki/XML_schema

• Zachman, (1987), A Framework for Information Systems Architecture. IBM Systems Journal, vol. 26, no. 3, 1987. IBM Publication G321-5298.

72

Appendix A, Unified Modelling Language (UML) notation

Class with 2 attributes and 1 operation;

An instance of class 1 has a relationwith zero or multiple instances of class 2 (association);

An instance of class 3 contains a set of instances of class 4 (aggregation). E.g. a soccer team (class 3) contains players (class 4). When team disappears the players still exist;

An instance of class 5 contains a set of instances of class 6 (composition). E.g. A house (class 5) contains walls (class 6). When the house is torn down, the walls don’t longer exist either;

Class 8 is a specialisation of class 7. e.g. a dog (class 8) is a mammal (class 7);

Interface with 2 operations;

Class 9 realizes interface1.

73

Appendix B, Mathematical function linkable Component The MathematicalFunction class is a generic LinkableComponent which serves as an example for the implementation of the SENSOR response, indicator and land use function linkableComponents. It can evaluate mathematical expressions by making use of the Java Expression Parser (JEP, http://www.singularsys.com/jep ). Mathematical expressions are used to describe relations between:

• Policy variable value � indicator value; • Policy variable value � change in land use (hectares); • Change in land use (hectares) � indicator value; • Indicator value � indicator value; • Constant � indicator.

For example a relation ‘Policy variable value � indicator value’ might relate the transformation of subsidy on renewable energy in euros/ha change of rapeseed area per region in ha.

The initialization arguments of the MathematicalFunction determine what specific functions are loaded and their associated regions. These are the regions which can be output. The initialization arguments are:

• PolicyCaseId (e.g. ‘RenewableEnergy’) • ReferenceScenarioId (e.g. ‘BusinessAsUsual’) • FunctionSetId (e.g. ‘RapeseedChange’).

Input and output are described by the OpenMI Input- and OutputExchangeIteminterfaces. The mathematicalFunction only uses outputExchangeItem (Figure 1). inputExchangeItems can be handled equally in specific implementations. Following the above example the input and output would be respectively ‘subsidy on renewable energy’ and ‘change of rapeseed area’. OutputExchangeItems are dynamically added to the ResponseFunction based on the data loaded.

Figure 1 – MathematicalFunction LinkableComponent

Component and model design The mathematicalFunction is a LinkableComponent which encapsulates a simple model capable of evaluating mathematical expressions. The model is a list of region objects in which a region is a data object with an associated mathematical expression, an unique identifier (id) and a member to store a calculated value (Figure 2). The Regions class implements the actual evaluation of each of the Region members’ functions by making use of the JEP library and holds information on what input- and output Variables are available.

74

Figure 2 – Class diagram of MathFunctionLinkable which is capable of handling region specific mathematical functions, elementary to the response function approach of SIAT

Data persistence Data for mathematical functions is stored in a HSQL relational database. A mathematical function is location-, policy case-, reference scenario-, and time specific. The vector of functions describing a unique transformation for a specific policy case, reference scenario and time is called FunctionSet. In order to get an overview for all the regions in the EU the FunctionSet for a specific transformation must be retrieved and calculated. The distinction between policy variable, indicatorand land use change has been generalized to Variables (in table variables) (Figure 3).

75

Figure 3 – entity relation model for storing mathematical functions and selection criteria such as policy case

Discussion on flexibility and performance By decoupling the mathematical functions from the functional Java classes the functions can be changed without the need for recompilation of source code and redeployment of the Java logic. Mathematical functions can be changed by putting in different data records in the database. JEP contains a large library of mathematical functions. This flexibility comes at a price. Every mathematical function needs to be parsed individually by the JEP parser. Tests with 2 million records read in from the HSQL database were parsed and executed within 1 second using an average laptop computer running Microsoft Windows XP with Java 6. However, the larger the mathematical expressions, the more time is required to syntax check and execute them. Additionally, large expressions are stored as String in the database making them ‘expensive’ (=time consuming) to transfer to the Java Virtual Machine. Size and structure of the mathematical expressions will have a huge effect on parsing speed.

76

Appendix C, SIAT milestone planning

Milestones are time boxed major SIAT software releases, both from content and functional perspective. Each milestone is typically used to show progress and gather feedback in order to adjust the planning if necessary. The milestone planning as shown in figure 1 listing major content and functionality updates only. Not mentioned within this figure is the long list of relative small functional updates, like: alphabetically sorting of a presented list of indicators and exporting calculated indicator values to Microsoft Excel.

Figure 1 – planning and realization from mid 2008 till end of project

77

Appendix D, Technical design of the Land Use Function model

Each Land-use Function (LUF) consists of a number of indicators, of which the values produced by the models are combined into a single impact value. Below follows a description of the process of combining the indicator values into the LUF-value, the scaling of the LUF-values before presentaion (in the map) and of the maniplation of the limits in the sensitivity function.

Combining the indicator values to LUF-values The LUF-value is calculated by combining the values of its constituent Indicator values. To compare the values of different indicators, that may express uncomparable quantities and scales, or even may not be numerical at all, each indicator comes with a normalizer function to scale its values between zero and ten. Numerical indicators are normalized by a linear normalization function. This function transforms each value in the range of the indicator value to a normalized value between 0 and 10. The function may be either descending (as shown below in Figure 1) or ascending. Non-numerical (qualitative) indicators are transformed using a conversion table.

Figure 1 – example of a linear normalisation function

After normalization, three succesive weights are applied to the new value: 1. the intrinsic weight is specific to an indicator. It balances partial indicators that

constitute a compound indicator. This weight factor therefore is bound by 0 and 1.

2. the impact strength represents the significance of each indicator to the LUF, which can be 1 or 2 (medium or strong significance respectively).

3. the regional importance expresses the significance of the indicator to the region for which the LUF is calculated. This weight has a value of 1, 2, or 3.

Then the weights are multiplied to an unscaled weight of the indicator in the present region:

unscaledweight=intrinsicweight�impactstrength�regionalimportance

These unscaled weights are scaled by dividing them by their sum over all indicators:

78

Finally, the impact value of the LUF is calculated by summing the indicator values multiplied by their weight fractions:

LUF-values that are greater than their corresponding limit are indicative for a sustainable policy. The sustainability limits are derived in an exactly analogous manner starting from indicator limits rather than indicator values.

Missing values A number of conditions can preclude the calculation of the indicator value for a specific region. In such cases, the indicator value returned is NaN, meaning “not a number”, and the value cannot be used in the calculation of the LUF-value. This indicator then will be ignored and the calculation proceeds with the remaining indicators. However, when the number of indicators that succesfully produced a value is less than two , the basis for the calculation of the LUF-value becomes too unsound (it would be a copy of the single remaining indicator) and will result in a NaN too.

Figure 2 shows the class diagram of the Land Use Function model implementation.

Figure 2 – class diagram of the Land Use Function model

˘ˇˇ - zalf leibniz-zentrum für...

Documents