1. Small Tools and Interoperability Arend Rensink Formal Methods and Tools University of Twente

2. IPA Spring Days, 7 May 2008 Small tools and interoperability2 Outline What are small tools? – Characteristics – Lifecycle How to support small tools? – Aspects of tool support – Tool ambition levels Tool interoperability – Classification – Problems Long-term vision: LIST

3. IPA Spring Days, 7 May 2008 Small tools and interoperability3 What are small tools? Tools developed in an academic context – Small basis for support Time: all that is not spent on “real” research Money: none (university infrastructure) Manpower: 1 person – Tend to die at the end of project Tools YOU write – Origin: PhD research topic (throwaway prototype) MSc final project Identified as problem at 3TU mid-term visitation

4. IPA Spring Days, 7 May 2008 Small tools and interoperability4 Questionnaire 1 What tools do you have? – What do they do? – What language(s) and platform? Which of them are small tools?

5. IPA Spring Days, 7 May 2008 Small tools and interoperability5 Characteristics of small tools Small tools may embody big ideas – “Small” does not refer to the research ideas Small tools are numerous – Virtually all PhD students create one or more Small tools are not integrated – PhD students are not software engineers – No ambition to make tools part of larger framework – Innovation does not extend beyond own research Small tools are prototypes – PhD students are not software engineers – No time devoted to user interface, documentation

6. IPA Spring Days, 7 May 2008 Small tools and interoperability6 Typical small tools lifecycle 1.A new research project is started 2.Research yields (preliminary) results – Tool needed to experiment, validate ideas 3.Small, throwaway prototype created – Validate results on dedicated examples – Experiment with real data 4.Research results published – Including experimental data 5.Project ends – Tool not maintained, no users Steps 2-4 may be iterated Latest point to intervene, raise ambition, find funding

7. IPA Spring Days, 7 May 2008 Small tools and interoperability7 Aspects of tool support Documentation – Programmer and user level Building and testing – Manual or automatic; regression tests Availability – Downloading, installing on multiple platforms Versioning/maintenance – Continuous development, releases Interoperability – Interchange formats, protocols Licensing Code doc On-line help Build farm (Delft) Sourceforge Build farm Svn (or cvs) Sourceforge (L)GPL, Apache, FreeBSD

8. IPA Spring Days, 7 May 2008 Small tools and interoperability8 Questionnaire 2 What solutions do you have – Documentation – Building/testing – Availability – Versioning/maintenance – Licensing

9. IPA Spring Days, 7 May 2008 Small tools and interoperability9 Ambition levels for small tools 1.(Low): Prototype tool – One developer = user – Lifespan: one paper 2.(Medium): Project tool – One or more developers = users – Lifespan: one project (4 years) 3.(High): Strategic tool – Multiple developers, external users – Lifespan: indefinite Building Versioning Documentation Availability Interoperability Licensing

10. IPA Spring Days, 7 May 2008 Small tools and interoperability10 Questionnaire 3 What ambition level are you on?

11. IPA Spring Days, 7 May 2008 Small tools and interoperability11 Interoperability Various definitions in existence Key elements: – Diversity of components – Cooperation to achieve common task – Here: components are individual tools Related concepts: – Integration: stronger than interoperability Global, unified view or presentation Imposes requirements upon individual tools – Interaction: weaker than interoperability Any kind of mutual influence, no “common goal”

12. IPA Spring Days, 7 May 2008 Small tools and interoperability12 Classifications Conceptual level classification – Syntactic interoperation: tools exchange data – Semantic interoperation: data mean the same – We concentrate on syntactic Better achievable (semantics hard to formalise) Necessary precondition for semantic Solution level classification – Run-time communication – File interchange – Programming-level integration

13. IPA Spring Days, 7 May 2008 Small tools and interoperability13 Run-time communication Based on pipes, channels… – Special case: mutual invocation Examples – Web services – TorX (test generation toolset) Advantages – Multi-paradigm solution Problems: – Precise definition of protocol – Setup phase: scripting?

14. IPA Spring Days, 7 May 2008 Small tools and interoperability14 File interchange Based on agreed-upon “standard” format – Most frequently chosen solution Examples: – UML, programming languages, XML, tool specific Advantages: – Multi-paradigm solution – Reduces work (from quadratic to linear in #tools) Problems: – Agreeing upon format (exponential in #tools?) – Precise definition of format, versions – Poor performance

15. IPA Spring Days, 7 May 2008 Small tools and interoperability15 Programming-level integration Based on public program interface Examples – Language libraries, plugins – CADP Advantages – Best performance Problems – Single-paradigm solution – Learning curve – Contract & interface changes

16. IPA Spring Days, 7 May 2008 Small tools and interoperability16 Questionnaire 4 What interoperability solutions do you use?

17. IPA Spring Days, 7 May 2008 Small tools and interoperability17 LIST Laboratory for Interoperability of Small Tools Initiative at FMT, University of Twente – Funding: CeDICT/LaQuSo – 1 technical assistant, 3 years Set up framework for tool support – Especially solutions for interoperability – Cooperation Eindhoven (Groote), Delft (Van Deursen) Improve interoperability of existing (FMT) tools – Especially strategic tools Set up & run responsible experiments – Documentation, reproducibility

18. IPA Spring Days, 7 May 2008 Small tools and interoperability18 Conclusion Building tools is a lot of fun! But: think it through! – What is your ambition level? – What are desired interoperability modes?

19. IPA Spring Days, 7 May 2008 Small tools and interoperability19 Provocations We should not invest in tool integration – in contrast to interoperability We should not invest in semantic interoperability – as long as we haven’t solved syntactic interoperability We should not invest in strategic tools – academia is wrong environment for serious tool development – small tools are a solution, not a problem