1. Integration-on-Demand Framework Marco G.A. Huigen University of Hohenheim

2. In our project team we have several (potential) projects in which we work on integrated modeling, hence deal with integrated research questions. We need a sound (generic) approach in these projects, so that the ‘wheel’ is not invented over and over again.

3. Integration-on-Demand Framework (IoDF) Integration is a process, in which - Technical integration, - Scientific knowledge integration, And Stakeholder integration are well-balanced.

4. Integration-on-Demand Framework (IoDF) Components: -Common Sampling Frame -statistical approach for data-collecting methodology -Integration protocol, use-case analysis and workflow -from conceptual ideas to technical solution based on research question -Model coupling framework (with simulation-scheduler) -Environment in which models are coupled according to standard (using XML and component based architecture) -Potential candidate = OpenMI -Data Management System -Suite of tools for Data-transformation

5. “Bad Approach of technical integration” Model A Model B Model C ModelA2ModelB ModelB2ModelA ModelA2ModelB ModelC2ModelA ModelB2ModelC ModelC2ModelB

6. Approach is what in computer-science would be called “bad practice”. –Every integrating step itself will probably be done “quick and dirty”. –It is inflexible, –It has an unclear structure –It is difficult to adapt to future wishes –It is difficult/impossible to maintain.

7. The better way!!

8. With regards to “scenario” development, this approach allows most flexibility. –The component based approach allows model configuration or even model re-defining while the adaptation to the interpreter is a minimal additional programming task. –Once the generic component is constructed, every multi- disciplinary scenario set up may communicate via the structure of the component. Base data and scenario data is stored in the DMS and labeled as such. This prevents loss and confusion. In case other scientists or users will have to work with these models, this structure will make it easier to adjust.

9. Demo OpenMI

10. But as said, technology is only 1 part of integration out of three!!!! To deal with scientific knowledge integration and with stakeholder (participation/integration) we developed an integration protocol.

11. Structure of integration protocol 1. Define Use-cases –What are the research questions that require integration (scientific and stakeholder perspective) –What are the conceptual models from each involved party. –How do you define the scenarios related to a specific RQ within the conceptual structures 2. Define workflow for implementation

12. Research Theme Research Question Scenario Use-Case Use cases

13. Term ‘Use cases’ is derived from Computer science Main structure of Use-case template (1): –General Information Overall goals and scope Document and Use case identification Project team –Use case Definition Description of research theme, Research Question –Objectives and expected outcomes –related RQ’s –Scenario descriptions

14. Main structure of Use-case template (2): –Stakeholder interface Description Interaction with Integrated components Conceptual frameworks of stakeholders involved (unlinked) –Scientific interface Description: Scientific conceptualization Interaction with Integrated components Conceptual frameworks of scientists involved (unlinked) –Technical interface Description: The models involved Conceptualization of model interactions –Sequence of actions of individual components and actors –Required data per model action »Data format Input »Data format output –The integrative solution: Bringing the three interfaces together Data definitions (Input, temporary, output and conditions) –Data syntax, format, transformation Normal process flow (sequence diagrams) Alternative flows and exceptions –Workflow

15. Conclusions This integration methodology delivers a well structured, documented and well defined way that helps us talk to each other (scientists) and with stakeholders on content and technology It requires a lot of input at the beginning, but it pays back! It requires input from all parties, at all times...

16. Conclusions Use case approach systematically works towards technical solution(s) and avoids pitfall of talking technical without having defined content. It prevents misunderstanding among involved parties if steps are followed.