slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic An PowerPoint Presentation
Download Presentation
From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic An

Loading in 2 Seconds...

play fullscreen
1 / 20

From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic An - PowerPoint PPT Presentation


  • 221 Views
  • Uploaded on

From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis. Elsa L Gunter NJIT. Objective of Formal Methods. Goal: Prove system satisfies requirements when deployed in intended environment Reality:

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'From Natural Language to LTL: Difficulties Capturing Natural Language Specification in Formal Languages for Automatic An' - cassara


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

From Natural Language to LTL:Difficulties Capturing Natural Language Specification in Formal Languages for Automatic Analysis

Elsa L Gunter

NJIT

objective of formal methods
Objective of Formal Methods
  • Goal: Prove system satisfies requirements when deployed in intended environment
  • Reality:
    • System exists in physical world,
    • Requirements exists in minds of designer / user
      • Collection of thoughts in natural language
  • Proof requires mathematical formalism
  • Keep gap on each end as small as possible
common approach for embedded systems
Common Approach for Embedded Systems
  • Model system (and environment) as concurrent processes
  • Each process modeled as finite automaton
  • Requirements stated in temporal logic
    • e.g. LTL, CTL*, μ-calculus
  • Apply model checking
narrowing the gap system side
Narrowing the Gap – System Side
  • Generate code for system automatically from formal model
  • What is best kind of automata
    • For modeling processes
    • For use in formal proofs
    • For automatically generating code
  • Usually some variant of finite state machine used
  • Generate model from code?
narrowing the gap requirements side
Narrowing the Gap – Requirements Side?
  • Generate logical formula from natural language requirements?
  • What is the best kind of language / logic
    • For capturing natural language requirements
    • For use in formal proofs
    • For capturing the necessary details of requirements of complex systems
    • Usually some variant of temporal logic used
  • Generate natural language requirements from logical formulae?
requirements in natural language
Requirements in Natural Language
  • Requirements begin as natural language expressions (thoughts)
  • Natural language is highly expressive
    • Problem for languages designed for use in automatic proofs
  • Requirements is natural language often quite ambiguous
    • Problem for any attempt to translate into formal language
ambiguity example
Ambiguity – Example
  • “Once pump has been turned on, pressure display will be updated every 2 seconds”
  • What does “updated” mean?
    • Display made equal to actual value?
    • When?
    • Display made equal actual previous value?
    • How long ago?
  • What exactly does “every 2 seconds” mean?
  • (Did we really mean something else?)
resolving ambiguities
Resolving Ambiguities
  • Fundamentally a human task
  • First ambiguities must be found
  • Formalizing requiremetns is a good way to find ambiguities
  • Automatic tools for translation can help
    • Must not build in a fixed interpretation when many are possible
slide9
LTL
  • Linear Temporal Logic is gives properties over sequences of states
  • Advantages
    • Simple syntax
    • Well-defined semantics
    • Admits model checking
slide10
LTL
  • Disadvantages:
    • No explicit time
    • No direct ability to compare values from different states
    • Operators assume closed-world assumption
      • Next is too strong
example
Example

Always

(seconds(cur_time – last_reading)  2) 

Next (display = previous_pressure))

  • May be true for monitor of pressure
  • Becomes false for pressure monitor run in parallel with other monitors
dealing with problems
Dealing With Problems
  • No Explicit Time
    • Add time variable to formulae
    • Cannot state in logic basic properties of time, such as always increasing
dealing with problems13
Dealing With Problems
  • No comparison between states
    • Add history variables
    • Example: Always x  previous_x
    • Cannot state that history variable actually holds variable’s previous value
dealing with problems14
Dealing With Problems
  • Closed-world assumption
    • Replace Next P with Eventually P
    • Much weaker
    • Possibly can use

Not Too_late Until P

for some notion of Too_late

automaton support
Automaton Support
  • No Explicit Time
    • Update time variable at every transition

Or

    • Time variable controlled by environment, modeled by separate automaton
  • No comparison between states
    • Update at history variable at each transition (or at each assignment)
automaton support16
Automaton Support
  • Problem: these clutter automaton, distance it from implementation
  • Partial solution:
    • Express extensions to model in separate automata designed only for them
    • Product with original automaton for checking
    • Requires appropriate notion of automaton and product (mix of synchronous and asynchronous)
future
Future
  • Automated assistance for translating natural language
    • Design to highlight ambiguities, not hide them
  • Design better language / logic for expressing requirements
    • Stay within the realm of automated checking
    • Possibly incorporate constructs for heuristics given above
  • Tools for generating auxiliary automata and product
product definition
Product Definition
  • (S,T, ,A)
    • S states
    • T transitions (labeled pairs of states)
    •  alphabet of transition labels
    • A mapping from  to actions
product definition20
Product Definition
  • (S1,T1,1,A1) * (S2,T2,2,A2) =

(S1 S2,T*, 1  2 ,A*) where

    • T* = {((s1 ,s2),(s’ 1,s 2), l1)

| (s1,s’ 1,l1)  T1 & l1  12 } 

{((s1 ,s2),(s1,s’ 2), l2)

| (s2,s’ 2, l2)  T2 & l2  2 1} 

{((s1 ,s2),(s’ 1,s’ 2),l)

| (s1 ,s’ 1 ,l)  T1 & (s2,s’ 2,l)  T2 }

    • A* merges actions on synchronization