small tools and interoperability arend rensink formal methods and tools university of twente

Small Toolsand Interoperability

Arend RensinkFormal Methods and Tools

University of Twente

IPA Spring Days, 7 May 2008 Small tools and interoperability 2

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


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


Questionnaire 1

• What tools do you have?– What do they do?– What language(s) and platform?

• Which of them are small tools?


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


Typical small tools lifecycle

1. A new research project is started2. 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


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


Questionnaire 2

• What solutions do you have– Documentation– Building/testing– Availability– Versioning/maintenance– Licensing


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


Questionnaire 3

• What ambition level are you on?


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”


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


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?


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


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


Questionnaire 4

• What interoperability solutions do you use?


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


Conclusion

• Building tools is a lot of fun!• But: think it through!– What is your ambition level?– What are desired interoperability modes?


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

small tools and interoperability arend rensink formal methods and tools university of twente

Documents

research small tools

research ideas small

end of project tools

big ideas small

ipa spring days

documentation slide

academic context small

prototype tool