slide1 l.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
PowerPoint Presentation
Download Presentation

Loading in 2 Seconds...

play fullscreen
1 / 13

- PowerPoint PPT Presentation


  • 309 Views
  • Uploaded on

software analysis: a roadmap Daniel Jackson & Martin Rinard MIT Laboratory for Computer Science ICSE · Limerick, Ireland · June 7, 2000 analysis zoo every analysis involves an artifact language model or code? a property language operational or declarative? a mechanism

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 '' - Anita


Download Now 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

software analysis: a roadmapDaniel Jackson & Martin RinardMIT Laboratory for Computer ScienceICSE · Limerick, Ireland · June 7, 2000

analysis zoo
analysis zoo
  • every analysis involves
    • an artifact language
      • model or code?
    • a property language
      • operational or declarative?
    • a mechanism
      • sound, scalable, accurate?
  • Promela LTL SPINassigns CTL SMVStatechart ad hoc StatemateCSP CSP FDRLTSA FSP LTL
  • VDM ad hoc IFAD Z Z+ Z/EVESAlloy Alloy Alloy
  • Java Java types javacC++ FO logic PSAC ad hoc lint any RMT graphsC SQL CIA

PSA: Parametric Shape AnalysisSagiv, Reps, Wilhelm

RMT: Reflexion Model ToolMurphy, Notkin, Sullivan

© Daniel Jackson, 2000

topics
topics
  • analyzing models
    • why analysis?
    • incrementality
    • do errors matter?
  • analyzing code
    • compositionality
    • unsoundness
    • evaluation
  • analyzing code vs. models
    • rhinos and tick birds
  • some myths
    • about analysis generally

© Daniel Jackson, 2000

disclaimers
disclaimers
  • this roadmap
    • will leave you at forks without directions
    • doesn’t stick to main roads
    • doesn’t take you to your destination

© Daniel Jackson, 2000

why analysis
why analysis?

This is not a good gameSaid our fish as he lit“No, I do not like it,Not one little bit!”

  • clashing cultures?
    • Z: language matters
    • SMV: analysis matters
  • two kinds of result
    • checking an adder
      • want errors
    • modelling a railway
      • want a model
  • morals
    • in software, both matter
    • design language with analysis
    • no formal basis, no analysis

A4D

analysis

description

D4A

© Daniel Jackson, 2000

the apple doesn t fall far from the tree
the apple doesn’t fall far from the tree

Oxford, home of Z

elegant expression

Pittsburgh, home of SMV

mechanization

Oxford photo from Jonathan Bowen’s collection; Pittsburgh photo by Norm Schumm, with permission

© Daniel Jackson, 2000

incrementality
incrementality

model expressed asabstract programeasy for programmersno frame problem

  • want
    • gentle slope: say a bit, analyze a bit
    • few environmental assumptions
    • maximal implementation freedom
  • language effects
    • conjunction: refine by extension
    • if property language is artifact language
      • can use property as model
      • can continue analysis without fixing bug
  • morals
    • need interactive tools
    • language can help

model expressed aslogical formula

can start with lessinconsistency

underconstraint

© Daniel Jackson, 2000

do errors matter
do errors matter?
  • standard justification
    • catching errors early saves costly fix later
  • in software
    • few showstopper bugs
    • subtle bugs are cheap to fix
    • real cost is flawed design
  • morals
    • analysis can help simplify design
    • “a difficulty deferred is a difficulty doubled”*
    • find a new way to sell software model checking …
  • *Michael Jackson

© Daniel Jackson, 2000

compositionality
compositionality
  • analysis in the face of
    • missing source code
    • libraries, frameworks
    • multiple languages
  • compositional analyses
    • process unit once
    • use spec for clients
  • morals
    • can’t escape specs
    • user’s help may be inevitable
  • where do specs come from?
    • the tool (eg, Rinard’s PEG)
      • handle all contexts
      • but need just a few
      • huge or imprecise spec
    • the user (eg, ESC)
      • laborious
    • a wizard (eg, Houdini)
      • expensive but effective?

© Daniel Jackson, 2000

unsoundness
unsoundness

semantics-preserving

  • conservative analysis
    • sound: results can be trusted
  • why be unsound?
    • often good enough (PreFIX, Murphy’s LSME)
    • easier to implement (Womble)
    • soundness compromises accuracy (ESC)
  • morals
    • soundness & accuracy conflict
    • engineer can do for a dime …
    • depends on task at hand
    • no guarantees, ever?

optimizations enabled

all bugs

bugs found

© Daniel Jackson, 2000

evaluation
evaluation
  • is it good enough?
    • how detailed alias analysis?
    • flow sensitive? context sensitive?
    • higher-order functions?
  • morals
    • need both approaches
    • can’t predict anyway
  • the short view
    • only end-to-end results count
    • show value for a given task
  • the long view
    • the internet took 30 years
      • maybe slicing will too?
    • surprises (eg, ML types for C)
    • judge ideas, not applications

© Daniel Jackson, 2000

symbiosis models code
symbiosis: models & code
  • check conformance of code to models
    • Bandera, RMT, Pathfinder, etc
  • how analysis helps models
    • if not conforming, what predictive use?
  • how models help analysis
    • focus on properties of interest
    • no fumbling in the dark (eg, k-limiting)
    • models as induction hypotheses
  • morals
    • look for good matches
      • object models & shape analysis?

© Daniel Jackson, 2000

some myths
some myths
  • complex implementation ok
    • easy to implement, more implementors (eg, JVM)
    • tool writers pick easy languages (eg, Java vs. C++)
  • can run for a week
    • occasionally true
    • but interactive tools far better
  • can evaluate analyses by reading papers
    • not your examples, numbers suspect
    • you have more/less expertise
    • publication culture rewards hiding failures
  • must be linear time, etc
    • better: how will Moore help?
    • 1980–2000: 3 hours to 1 second

© Daniel Jackson, 2000