1 / 32

Thoughts on Requirements and Design of User Interfaces for Proof Assistants

Thoughts on Requirements and Design of User Interfaces for Proof Assistants. Norbert V ölker University of Essex, England. Background. Personal dissatisfaction Happy Isabelle/HOL hacker Isabelle/Isar requires a user interface

ira-pollard
Download Presentation

Thoughts on Requirements and Design of User Interfaces for Proof Assistants

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Thoughts on Requirements and Design of User Interfaces for Proof Assistants Norbert Völker University of Essex, England

  2. Background • Personal dissatisfaction • Happy Isabelle/HOL hacker • Isabelle/Isar requires a user interface • ProofGeneral is a fantastic achievement but still far from ideal • Toyed with idea of own UI project • Observations • Interested in collaborations • Thanks to the anonymous referee

  3. Overview • Towards Generic UIs • A case for requirements elicitation • Human-computer interface issues • Architectural and system design issues

  4. Generic UIs • Community needs to use its sparse resources more efficiently • more reuse • Generic UIs • separation of UI and proof assistant • find requirements by identifying common features of proof assistant interaction • Generic components

  5. Proof Assistant Interaction:Common Features • Projects • Hierarchical sections (“theories”, …) • Logical context: constants, axioms, types, sorts; proven theorems • Extra-logical context: configuration of parsers, proof tools, display options, … • Persistence mechanism • saving and loading of projects/sections

  6. Generic Proof Interaction • Pose a formula (“main goal”) • Proof steps: user issues proof commands that change the proof state • Proof commands refer to proof tools, theorems, subgoals, subterms, … • Proof state contains open goals and local declarations and assumptions • Proof ends when no open goals left or abort • Proof attempts can possibly be nested

  7. Towards Generic UIs • Generic user interfaces for families of proof assistants are feasible • ProofGeneral • Even if you are building a UI for a specific proof assistant, try and stay as generic as possible in order to aid reuse • build to well documented interfaces!

  8. Overview • Towards Generic UIs • A case for requirements elicitation • Human-computer interface issues • Architectural and system design issues

  9. A Case for Requirements Elicitation • Academic projects do seem to lack in requirements elicitation • Suggestion • use case analysis • object identification • Again, try to stay generic

  10. Use Case Analysis • Each use case abstracts over a set of user-system interactions (“scenarios”) that are performed in pursuit of a certain aim. • Examples • Adding a constant to a theory • Backward proof • (Re)Load a theory • …

  11. A Use Case Template [Larman] • Title of Use Case: … • Actors: … • Preconditions: … • Postconditions (Successful Outcome): … • Main Success Scenario: … • Alternative flows: • Special Requirements: … • Open Issues: …

  12. Title of Use Case: Add a constant to a theory Actors: Specifier Preconditions: System in top-level or theory mode Postconditions (Successful Outcome):constant has been added to the theory Main Success Scenario: • Specifier requests “Add constant” • System responds with a list of theories for current project • Specifier selects a theory • System responds with a list of constants already declared in theory and a form for entering the new constants

  13. Specifier enters the constant details and submits the form • System adds constant to theory • The success of the operation is indicated by a status message in the UI Alternative flows: 1-3a. In theory mode, the specifier can also request “Add constant to current theory”. In this case steps 2 and 3 are omitted. 3b/5a. The specifier can cancel the process by selecting a “cancel” option. 4 b. If the specifier denotes the theory by string input, then the system checks …

  14. Special Requirements: All text input forms should allow copy-and-paste and support auto-completion Open Issues: Should there be a syntax-directed editor for input of the constant definition?

  15. Domain Object Identification • Starting point: nouns in documentation such as use cases, manuals, etc • project, theory, theory hierarchy, child theory, parent theory • logical context, logical basis, extra-logical context • axiom, theorem • formula, term, constant, type, sort • proof, goal, main goal, proof step, proof command, proof state, open goal, …

  16. A Structured Approach to Finding Use Cases • Generic operations • creation of objects • modification of objects • inspection of the state of objects • making objects persistent • deletion of objects • Example “theorem” object: • create, rename, edit a proof, modify goal and rerun proof, inspect, save, delete, …

  17. The Role of Use Case Analysis • Identify interactions that the system needs to support (efficiently, unit) • Describe key use cases in detail • Good starting point for UI design, testing and user documentation • Valuable in practice despite criticism • Stress user-point of view • balance prover-functionality driven development

  18. Overview • Towards Generic UIs • A case for requirements elicitation • Human-computer interface issues • Architectural and system design issues

  19. Principle of Least Effort • Context-sensitive auto-completion • Menus • only possible choices • recent used/frequently used/rarely used sections • Suitable default values whenever a choice has to be made • Reuse of previous inputs

  20. Graphical Interaction • Hypertext can link information and actions • theorems to proofs or to similar theorems • linking a constant in a goal to its definition • clicking unknown opens instantiation dialogue • Drag-and drop for container operations • move a theorem between theories • build a theorem query from constants • assemble theorem sets for proof tools

  21. Proof by Pointing • Generation of proof scripts from a “clicked proof” • Forward reasoning from goal premises via a theorem (“destruct”/ “elim”) • Backward reasoning by resolution from goal via a theorem • Apply assumption rule • Possible brittleness of proofs • positional versus pattern identification

  22. Textual Interaction • Typing a short name versus selection from long lists or via several submenus • Large proof trees can be difficult to use • Tougher interface might lead to better planning of proofs/ proof procedures • UI should support both graphical and textual interaction

  23. Customisation by Users • Adaptation of menus, menu items, tool bars, keyboard short cuts, etc • Adaptation of formatting • proof assistant outputs and UI elements • fonts, font sizes, window sizes, colouring, pretty printer settings, … • mode dependent • Project level/ theory level/ proof level • Recognized as a regular use case

  24. Overview • Towards Generic UIs • A case for requirements elicitation • Human-computer interface issues • Architectural and system design issues

  25. Basic Architecture • Paradigm: control centre with pluggable components similar to IDEs • Assume separate UI • possibly distributed, heterogeneous • UI subsystems corresponding to roles • theory specification • interactive proof • context (extra/logical) inspection • proof tool development

  26. UI Subsystem Ideas • Inspection: use standard web browser?! • attractive: XML/XSLT, MathML, hyperlinks • requires updating of XML documents • Theory specification • enhanced editor similar to ProofGeneral?! • Interactive proof • proof by pointing component?! • Proof tool development • IDE?

  27. Paradigm Change • Goodbye monolithic proof assistant • Welcome platform • prover provides a logical deduction service • Support concurrency? • concurrent access theorem databases? • dependency: theory modifications? • security? • fault-tolerance: orphaned processes, …

  28. Allocation of Responsibility between UI and Prover • Clear for most tasks • Basic validation of user inputs in UI • Parsing of user commands? • generate RPCs? XML encoding? • Output formatting? • XML/XSLT transformation in UI? • What does the UI need to know? • Proof assistant state replication? • Simplicity versus performance gain

  29. Component Frameworks? • Do we need facilities offered by frameworks such as .NET or CORBA? • registries and dynamic binding? • transaction support? • persistence support? • Suggestion: keep it simple • Java UI: encapsulate processes • Loose coupling: (XML) messaging

  30. XML Protocol Thoughts • Message vocabulary and sequencing • Semantic rather than presentation oriented • Support for coarse-grained concurrency • process a theory • If possible, orthogonal to standards like MathML • Extensible • Common core independent of proof assistant and of user interfaces!

  31. Components and Adaptability • Components only work with well-documented interfaces! • Integration of complex components will always require custom adaptation • Simpler components such as XSLT input/output filters could be pluggable • User interface should be extensively adaptable using configuration files • Example: Mozilla XUL

  32. Conclusions • Encourage generic UIs • User oriented requirements elicitation • Scope for HCI improvement • least effort, hyperlinks, drag-and-drop, proof by pointing, text interaction • Separate UI raises architectural issues • platform architecture, components, web browsers, concurrency, XML protocols • Proof assistants need effective UIs

More Related