Towards Verified Software: Research and Education
Murali Sitaraman
School of Computing
Clemson University
E-mail: murali@cs.clemson.edu
http://www.cs.clemson.edu/~resolve
This research has been funded in part by grants from the
U. S. National Science Foundation for the past 20 years.
About Clemson
• Clemson University is the land-grant institution of
the state of South Carolina
• Ranked #22 among the public institutions in the US
• 17,000 students: About 13,000 undergraduate and
4000 graduate students
• The university is in the scenic town of Clemson
(population 11,000)
• Capacity of the Clemson Tiger football stadium:
85,000
• School of Computing has 30 faculty members and
about 120 graduate students
Current Students at Clemson
Ph. D. students
• David Frazier (security)
• Svetlana Drachova (educational environment)
• Heather Harton (verification condition generation)
• Hampton Smith (automated proving)
• Nighat Yasmin (performance specification/analysis)
Other students
• Chuck Cook
• Emily Forney
• Grant Giles
Collaborating professors elsewhere
•
•
•
•
•
•
•
Jeremy Avigad (Philosophy, CMU)
Harvey Friedman (Mathematics, Ohio State)
Joe Hollingsworth (CS, Indiana University Southeast)
Joan Krone (Mathematics and CS, Denison)
Greg Kulczycki (CS, Virginia Tech)
Bill Ogden (CS, Ohio State)
Bruce Weide (CS, Ohio State)
More collaborators…
• Steve Edwards (Virginia Tech)
• Gary Leavens (Central Florida)
• …
The RESOLVE vision
• The RESOLVE vision is that of a future in which no
production software is considered properly
engineered unless it has been fully specified and fully
verified as satisfying these specifications.
A different vision (Once upon a time…)
• No production software will be considered properly
developed, unless it is written in a high-level
programming language, and translated into machine
language entirely automatically.
Status of the high-level language translation
vision today
• Vision accomplished (compilers)!
• Vision exceeded: Compilers can themselves be
developed in high-level languages!!
• Vision exceeded even further: Operating systems,
and even more complex systems can be developed in
high-level languages!!!
What is a specification?
• Specification of a Boolean function to determine if a
number is prime simply states under what conditions
the function will return true or false.
• Specification of a Queue Sort operation would say
that the resulting queue is in order and …
What is a specification?
• Specification of a Boolean function to determine if a
number is prime simply states under what conditions
the function will return true or false.
• Specification of a Queue Sort operation would say
that the resulting queue is in order and the resulting
queue is a permutation of the input queue.
• Unlike typical programming languages, in RESOLVE,
you can write formal specifications and code.
The vision
• The RESOLVE vision is that of a future in which no
production software is considered properly
engineered unless it has been fully specified and fully
verified as satisfying these specifications.
The vision
• The RESOLVE vision is that of a future in which no
production software is considered properly
engineered unless it has been fully specified and fully
verified as satisfying these specifications.
• Also see Tony Hoare’s verification grand challenge
for the computing community
What if the specifications are wrong?
• What if the real-world modeling, on which the
specifications are based, is wrong?
• What if the specifications are simply not formulated
right, i.e., do not capture the intent?
• These are important questions, but if the vision is
realized, we’d at least know that the software is
correct!
• Thus the vision isolates the verification problem.
Will testing still be needed?
• Absolutely.
• Verification only checks if code meets specified
behavior.
• To validate software, i.e., code satisfies customer
requirements, you still need testing.
Isn’t the verification problem undecidable?
• Yes.
• But correctness of programs we will ever write in
practice has nothing to do with undecidability!
• Intuition: competent programmers can usually tell
whether their code is right; they don’t solve deep
mathematical theorems to reach conclusions.
What does this code do?
I and J are Integers.
I = I + J;
J = I – J;
I = I – J;
Does this code leave S unchanged?
S is a Stack of entries.
S.Push( S.Pop() );
Back to competent programmers
• Intuition: competent programmers can usually tell
whether their code is right (modulo careless errors);
they don’t solve deep mathematical theorems to
reach conclusions.
Back to competent programmers
• Intuition: competent programmers can usually tell
whether their code is right (modulo careless errors);
they don’t solve deep mathematical theorems to
reach conclusions.
Jason Kirschenbaum, Bruce Adcock, Derek Bronish,
Hampton Smith, Heather Harton, Murali Sitaraman
and Bruce W. Weide, Verifying Component-Based
Software: Deep Mathematics or Simple
Bookkeeping?, Procs. 11th Int. Conf. Software Reuse,
Springer, September 2009.
Automated verification made easy…
• Given proper justifications from programmers (e.g.,
invariants for loops) and adequate mathematical
developments (e.g., theorems), verification is easy;
actually so easy that a minimalist prover can do most
of it!
RESOLVE Compiler/Verifier information flow
Proof
Units
Math
Units
Specifications Realizations
Proof
Checker
Verifier
Compiler
Result
Reports
Result
Reports
Compiled
Code
Verification System
Relevant Publication
• Murali Sitaraman, Bruce Adcock, Jeremy Avigad,
Derek Bronish, Paolo Bucci, David Frazier, Harvey M.
Friedman, Heather Harton, Wayne Heym, Jason
Kirschenbaum, Joan Krone, Hampton Smith, and
Bruce W. Weide, Building a Push-Button RESOLVE
Verifier: Progress and Challenges, Formal Aspects of
Computing, Springer, accepted to appear; available as
a tech. report.
Main points for the verification vision
• Integrated specification and implementation language
with clean semantics.
• Modular verification.
• Soundness.
• Adequate mathematical development.
• Programmers should supply adequate justifications,
but should not be involved in proofs.
• Educational challenges in producing competent
programmers.
Some Recent Publications
•
Greg Kulczycki, Murali Sitaraman, Nighat Yasmin,
and Kim Roche, Formal Specification, Encyclopedia
of Computer Science and Engineering, Wiley, 2008.
•
Heather Harton, Joan Krone, and Murali Sitaraman,
Formal Program Verification, Encyclopedia of
Computer Science and Engineering, Wiley, 2008.
•
Hampton Smith, Heather Harton, David Frazier,
Raghuveer Mohan, and Murali Sitaraman, Generating
Verified Java Components through RESOLVE, Procs.
11th Int. Conf. Software Reuse, Springer,
September 2009.
Education
• Murali Sitaraman, Jason Hallstrom, Jared White,
Svetlana Drachova-Strang, Heather Harton, Dana
Leonard, Joan Krone, and Rich Pak, Engaging
Students in Specification and Reasoning: Hands-on
Experimentation and Evaluation, Procs. ACM-SIGCSE
14th Annual Conference on Innovation and Technology
in Computer Science Education (ITiCSE), 2009.
• Also SIGCSE 2009 paper on teaching specifications.
Courses at Clemson
• CPSC 215: Introduction to Software Foundations.
• Formal specification and reasoning principles are
introduced in a Java context, along with OO
concepts.
• CPSC 372: Introduction to Software Engineering.
• Team development with formal contracts
verification are reinforced.
• Principles taught in incremental, adpatable modules.
Principles for Teaching
• How can specifications scale?
• Abstraction in specification
• How can implementations scale?
• Component-based software development
• How can verification scale?
• Modularity in verification, i.e., ability to verify one
component at a time
• How can automation scale?
• Adequate justifications from programmers
• Adequate mathematical developments
Sample Educational Activity
• Graduate and undergraduate SE classes
• Specifications are given
• Also internal assertions (e.g., representation
invariants and abstraction functions) for some
implementations are given.
• Mixed and used pieces of code from 6 different
students
• The resulting software – composed in class in front
of students - worked the first time after
integration!
Main points for the verification vision
• Integrated specification and implementation language
with clean semantics.
• Modular verification.
• Soundness.
• Adequate mathematical development.
• Programmers should supply adequate justifications,
but should not be involved in proofs.
• Educational challenges in producing competent
programmers.
Towards Verified Software: Research and Education
Murali Sitaraman
School of Computing
Clemson University
E-mail: murali@cs.clemson.edu
http://www.cs.clemson.edu/~resolve
Verified Software Part II: Technical Details
Murali Sitaraman
School of CTecomputing
Clemson University
E-mail: murali@cs.clemson.edu
http://www.cs.clemson.edu/~resolve
What is modular verification?
uses
implements
uses
uses
implements
implements
uses
Abstraction in specification
• Think of a List as a pair of mathematical strings:
• A string of entries that precede the current
position and
• A string of remaining entries
• Initially, both strings are empty.
View of lists with abstraction
Preceding
S1 = ( <
S2 = ( <
,
Remaining
>,<
>,<
>)
>)
Views of List S1 before and after:
Insert (T, S1)
S1 = ( <
,
>,<
>)
,
>,<
,
T=
S1 = ( <
>)
Mathematical Modeling
Concept List_Template (type Entry);
uses String_Theory, …;
Type List is modeled by (
Prec: String(Entry);
Rem: String(Entry)
);
exemplar S;
initialization ensures
S.Prec = empty_string and
S.Rem = empty_string;
...
end List_Template;
List Operations
Concept List_Template (type Entry);
uses …
Type List is modeled by …
Oper Insert(E: Entry; S: List);
Oper Remove(E: Entry; S: List);
Oper Advance(S: List);
Oper Reset(S: List);
Oper Advance_To_End(S: List);
Oper Prec_Length(S: List): Integer;
Oper Rem_Length(S: List): Integer;
Oper Swap_Rems(S1, S2: List);
end List_Template;
Design & Specification of Operations
Operation Insert(clears E: Entry; updates S: List);
Ensures S.Prec = #S.Prec and
S.Rem = <#E> ° #S.Rem;
Operation Remove(replaces E: Entry; updates S: List);
Requires |S.Rem| > 0;
Ensures S.Prec = #S.Prec and
#S.Rem = <E> ° S.Rem;
Design & Specification of Operations
Operation Advance(updates S: List);
Requires |S.Rem| > 0;
Ensures S.Prec ° S.Rem = #S.Prec ° #S.Rem and
|S.Prec| = |S.Rem| + 1;
Operation Reset(updates S: List);
Ensures S.Prec = empty_string and
S.Rem = #S.Prec ° #S.Rem;
Operation Rem_Length(restores S: List);
Ensures Rem_Length = (|S.Rem|);
Specification of a List Sort Operation
Definition Is_Ascending_Order = …
Operation Sort_List( updates P: List );
ensures P.Prec =  and In_Ascending_Order( P.Rem )
and Is_Permutation (P.Rem, #P.Prec o #P.Rem);
Skeleton of insertion sorting
Procedure Sort_List( updates P: List );
Var P_Entry, S_Entry: Entry;
Var Sorted: List;
Reset ( P );
While ( Length_of_Rem (P) > 0 )
maintaining Sorted.Prec = empty_string and
In_Ascending_Order( Sorted.Rem ) and …
Remove (P_Entry, P);
Repeat
…
iterate;
end;
P :=: Sorted;
end Sort_List;
While Length_of_Rem( P )  0 do
Remove( P_Entry, P );
Iterate
When Length_of_Rem( Sorted ) = 0
do exit;
Remove( S_Entry, Sorted );
When Lss_or_Comp( P_Entry, S_Entry )
do Insert( S_Entry, Sorted ) exit;
Insert( S_Entry, Sorted );
Advance( Sorted );
repeat;
Insert( P_Entry, Sorted );
Reset( Sorted );
end;
P :: Sorted;
end Sort_List;
While Length_of_Rem( P )  0 do
Remove( P_Entry, P );
Iterate
When Length_of_Rem( Sorted ) = 0
do exit;
Remove( S_Entry, Sorted );
When Lss_or_Comp( P_Entry, S_Entry )
do Insert( S_Entry, Sorted ) exit;
Insert( S_Entry, Sorted );
Advance( Sorted );
repeat;
Insert( P_Entry, Sorted );
Reset( Sorted );
end;
P :: Sorted;
end Sort_List;
Performance Analysis
Procedure Sort_List( updates P: List );
duration …
manip_displacement …
Var P_Entry, S_Entry: Entry;
Var Sorted: List;
Reset ( P );
While ( Length_of_Rem (P) > 0 )
maintaining …
decreasing …
elapsed time …
manip_disp …
…
end;
end Sort_List;
Performance Analysis
Procedure Sort_List( updates P: List );
duration O( Max( |#P.Prec ◦ #P.Rem|,
P_Rank( #P.Prec◦#P.Rem ) );
…
Main points
• Integrated specification and implementation language
with clean semantics.
• Modular verification.
• Soundness.
• Adequate mathematical development.
• Programmers should supply adequate justifications,
but should not be involved in proofs.
• Educational challenges in producing competent
programmers.
• Visit www.cs.clemson.edu/~resolve for details.