Syllabus for

The class webpage is a Movabletype blog. A blog format allows me to post announcements and pointers as they come up. The blog allows you to comment on those announcements and pointers. If you use an RSS aggregator, you can subscribe to http://vv.cs.byu.edu/cs586/index.rdf to get the class feed.

valgrind is a program that detects memory leaks. The course webpage includes a link to valgrind. I’ve installed valgrind on the CS lab machines in ~jones/bin/valgrind.

You’ll have to implement functions that generate input for graphviz. Graphviz is a program for drawing graphs from a textual description of a graph. The graphviz homepage is http://www.research.att.com/sw/tools/graphviz/. The dot program, along with related programs, is installed at ~jones/bin/dot [mdj3]

The textbook can be a little obtuse sometimes. I have a set of lecture notes I used last semester to teach 586. These are also online at the class webpage. ~~(MIKE: Blackboard or class webpage. I did not see them on the Blog).~~

Purpose of the Course

CS 586 is many things to many people.

For seniors, and graduate students, about to graduate and enter the job market, 586 is exposure to a significant piece of useful theory and its application to important design problems, a final chance to hone your coding skills and a time to learn cutting edge verification technology. After you finish this class and leave the University, you be in a position to decide if this technology will be useful in your new job.

For seniors contemplating research in verification and validation, CS 586 is where you learn the foundational topics in verification and validation. After completing 586, you will be ready to take CS 686 ~~that~~which will take you to the frontier of verification research.

Core Concepts

Realistically, you aren’t going to remember everything you learned in 586. Its hard for me to believe, but I’m told its true ;) . With that in mind, here are four things I hope you’ll remember from 586. These ideas can be learned from a course on model checking but apply more generally to computer science problems.

On-the-fly simplification is better than construction followed by simplification. ~~Classical~~Both model checking algorithms rely on on-the-fly reductions. On-the-fly reduction allows you to solve problems that would otherwise be intractable.
Theory is a power tool for doing useful things. Quantified Boolean formulae and Buchi automata over infinite words are seemingly esoteric concepts, yet they are the foundation of verification algorithms that can find errors in protocols and circuits. Similarly, LR(1) grammars are seemingly useless language classes the form the foundation of compilers. If you get the theory right, elegant and useful algorithms can often be derived.
“Correct” has no meaning without a definition. We’ll spend a lot of time in the first part of the class learning logics for specification. The point of that is to allow precise definitions of correctness. In other settings, we often hear people say that such-and-such algorithm or program is “correct.” After 586, you should always ask, “but what do you mean by ‘correct’?”
Trust recursion. The algorithms for CTL and LTL model checking recurse over the structure of a formula. While difficult to learn the first time, such structural recursion results in simple algorithms for solving arbitrarily complex problem instances.

Projects

The course contains 6 projects. At the end of the class, you will have implemented rudimentary symbolic and explicit model checkers. The purpose of the projects is to help you correlate model checking problems and model checker performance by understanding how model checking tools work from the inside. Using this knowledge, you can evaluate the usefulness of model checking for specific verification problems.

The figure below shows the relationships between the projects

MIKE: How does this show the group rotation?
Project 1: Kripke Structure Parser

In which you implement a parser to read a Kripke structure from a text file and store it in a data structure. The format of the text file and the data structure are both defined below.

A Kripke structure will be given in a text file. The text file will have the following structure:

States <integer>

Start states <state>⁺

<Transitions (<state>,<state>)⁺>⁺

<Label <state> <label>⁺>⁺

The first line gives, n, the number of states. The states are then identified by numbers between 1 and n There may be one or more lines beginning with “Transitions” that identify transitions. Similarly, there may be one or more lines beginning with “Label.” Each “Label” line contains one state and a list of labels for that state. No white space in label names, no commas between transition pairs an white space is ok everywhere else. [Clarification added 9/16]

The Kripke structure class definition is:

class kripke

{

// your may include all the private members and

// method you wish.

public:

kripke (~~int~~ stateCount: int);

// the second constructor reads a Kripke structure

// out of the file. After reading the file, all

// other public methods work correctly. [9/22]

kripke (char *filename);

~kripke ();

// mark a state as a start state. [9/24]

void mark_start_state (int state);

~~void add_state (int state);~~

void add_transition (int src, int dst);

void add_label (int state, char *label);

int state_count ();

// you may assume that I will not modify objects referred to

// by these pointers.

int* next_states (int state);

char** propositions (int state);

int* start_state ();

~~void read_kripke (file *filename);~~ [deleted 9/22]

}

The first entry in the array of next_states, and the array of start_state s, is the number of next states. The last entry in the array of propositions, ie labels, is the null-string (0x0). [Added 9/22]

Project 2: BDD Package

In which you implement the BDD data type and operations. BDDs are the core data structure in symbolic model checkers. The BDD class is defined below.

//syntax corrected [9/25]

enum bool_op {b_or, b_and, b_not, ~~b_var, b_const~~};

class BDD

{

// all the private methods and members you like.

// ideally, the privates will be just a pointer to an

// entry in the global unique table. [9/25]

public:

// the constructors build & reduce the bdd using

// the hash table.

BDD (bool_op rator, BDD* left, BDD* right);

BDD (bool_op rator, BDD* right);

BDD (char* variable_name);

BDD (int true_or_false);

// build a bdd from a string representing a boolean

// formula. This is where you use your parser [9/29]

// This constructor is redundant. The BDD (char* variable)

// constructor above has the same type. Fortunately, the

// behavior of both constructors is the same since a

// variable is a special kind of boolexpression. [10/08]

BDD (char *boolexpression);

~BDD ();

// the bdd created by restricting the variable to

// the given value. Restrict will only be called on the

// root, or top_variable, of a bdd. [10/08]

// restrict just takes the value to which the root variable

// should be restricted [10/08]

BDD* restrict (~~char* variable~~, int true_or_false);

// a pointer to my entry in the unique table.

// modified [9/29]

int unique_table_index ();

// Graphviz (documentation) is program for drawing graphs from // textual descriptions of a graph

int toGraphviz (char* filename);

char* top_variable();

};

Your BDD package must include a computed table and a unique table. The computed table stores a pointer to the BDD that contains the result of building a BDD to represent a boolean expression. The computed table supports top-down dynamic programming. The unique table stores a pointer to the BDD representing a given boolean expression. The unique table supports sharing duplicate nodes. Use alphabetical order for variable ordering. [9/29]

My code will call init_memory () and clean_memory () functions before constructing any BDDs. You may use these functions to initialize your global data structures. I will not access your global data structures (except through your class methods defined above). [10/1]

~~MIKE: Does this interface support the hash table implementation? Do you need to add an APPLY function to the interface?~~

The syntax for boolean expressions is…

bool_const: True, False

bool_var: <variable_name>

bool_expr: <bool_const>, <bool_var>,

<bool_expr> & <bool_expr>,

<bool_expr> | <bool_expr>,

~ <bool_expr>,

(<bool_expr>)

the order of operations is the C order of operations.

You may assume that I’ll pass postfix expressions to your BDD (char *boolexp) constructor. If you do decide to use postfix expressions, which are easier to parse, then be sure to #define POSTFIX somewhere in your header file so I’ll know which kind of expression to pass to your constructor. [Added 10/8]

Project 3: Kripke to BDD Translator

In which you translate your Kripke structure data type to your BDD data type. At the end of project three, you will have a single method that reads a Kripke structure from a data file and returns a pointer to a BDD object that represents the Kripke structure. This requires adding the following method to the Kripke class. [9/29]

In which you implement a class “kripkeBDD” that is a BDD interface to a Kripke structure for use in a symbolic CTL model checker. The class has one constructor for buiding a KripkeBDD from a Kripke structure object. Each interface to the class returns a pointer to a BDD object.

class kripkeBDD {

kripkeBDD (kripke* ks);

~kripkeBDD ();

// note: it’s a good idea to make sure your primed variables

// come first in your variable ordering. An easy way to do

// this is to prepend AA to the front of your primed variables

// rather than appending a prime to the end.

BDD* transitionRelation ();

BDD* labeledBy (char *label);

BDD* startStates ();

// we do not require the Kripke structure to have

// 2^n states, so the BDD for allStates may not be just “T”

BDD* allStates ();

}

You should turn in all of the .C and .h files needed to build your kripkeBDD class. This is likely to include your Kripke files and your BDD files. As before, My code will call init_memory () before building and BDDs and clean_memory ()before exiting.

Project 4: Symbolic Model Checker

In which you implement your own BDD-based symbolic model checker for CTL. The new class is quite simple:

class CTLproblem {

// all the private methods and members you care to define.

public:

CTLproblem (kripkeBDD* kripke; char* property);

~CTLproblem ();

// returns 1 is kripke is a model of property

// returns 0 otherwise

int isAModelOf ();

// returns a BDD that characterizes the states that model

// the property.

BDD* statesThatModel ();

};
The CTL property will be given in postfix notation with no parenthesis and a space separating each atomic proposition or operator. Temporal operators will be written using the text’s notation:

AF, EF, AG, EG, AU, EU, AR, ER, AX and EX [added 10/28. My bad]

Boolean operators will be written as before:

&, |, ~

For example, the CTL expression

A (blue U ~ (red | green))

would be written

green red | ~ blue AU

Project 5: Kripke to Buchi Automata Translator

In which you translate your Kripke data structure into Buchi automata for use in your LTL model checker. The Buchi automata class has the following interface:

This is the correct version, as of November 12 at 7:14 pm.

class Buchi {

// private methods and members

public:

// construct a Buchi automata with the given # of states.

Buchi (int states);

Buchi (kripke *k);

~Buchi ();

// return the index for the vertex just added.

int add_vertex (~~int v~~);

void add_edge (int src, int dst, char** label);

void mark_accept (int v);

void mark_start (int v);

int* successors(int v, char** label);

// this one returns all sucessors.

int* successors(int v);

char** labelings_of (int src, int dst);

bool is_accept (int v);

int start_state (); MIKE: Should this return an int*

~~int readKripkeFromFile (char *filename);~~

int toGraphviz(char *filename);

}

As before, the toGraphviz function writes a text file containing the structure of the current Buchi automata. The graphviz file will be used to check that the resulting automata has the correct structure.

Project 6: Explicit Model Checker

In which you implement the on-the-fly double depth-first search algorithm for LTL model checking. You’ll use the Buchi class from Project 5. The class you’ll be implementing is a lot like the class for the CTL model checker.

class LTLproblem {

// all the private methods and members you care to define.

public:

LTLproblem (Buchi* system; Buchi* negated_property);

~LTLproblem ();

// returns 1 if the system is a model of the negation of the

// negated property. Returns 0 otherwise.

int isAModelOf ();

};

Grades

Projects will be graded for functional correctness on a set of challenge problems. No project with a memory leak will receive full credit. Use valgrind to find memory leaks.

Homework assignments will be made throughout the semester. The grading and importance of each assignment will be given with the assignment.

Policies

Homework is not accepted late. Late projects are accepted at a discount. The discount grows exponentially with the number of days late. Sundays do not count as late days. The formula for computing late grades is

for an assignment that is i days late.

No code sharing. Code sharing means using someone else's code that you either don't understand or didn't type yourself. You may use standard libraries.

Your overall grade will consist of the following components:

Project 1 5% Project 4 15%

Project 2 15% Project 5 5%

Project 3 5% Project 6 15%

Midterm 15% Final 15%

Homework 10%

Grades will be assigned according to the following scale:

100-93A 80-77 C+ 63-60 D-

93-90 A- 77-73 C 60- E

90-87 B+ 73-70 C-

87-83 B 70-67 D+

83-80 B- 67-63 D

We reserve the right to curve grades in your favor. The University policies on UW and I grades will be strictly followed. If you can't afford to get a UW due to visa issues, then come to class and take the final.

Special circumstances arise for students during the semester. In this class, special circumstances can be accommodated by prior arrangement . If you anticipate you need some kind of accommodation to handle a special circumstance, talk to your instructor as soon as possible. In all but the most dire circumstances, special circumstances will not be accommodated after the fact. For example, if you are planning to get married during the semester, arrange with your instructor to make up missed work, extend deadlines etc. If you got married the third week of classes and missed a project, but did not make prior arrangements, then no accommodations will be made. If you were in a car accident and at the Emergency Room and could not make prior arrangements, then of course we can make accommodations.

The Honor Code includes a statement of standards regarding academic honesty. Academic honesty includes writing your own programs, properly citing sources in reports and doing your own work on tests. Examples of academic dishonesty include sharing code for projects with other students, turning in someone else's writing as your own report and cheating on an exam. The first violation of academic honesty standards will result in your course grade being lowered 1 grade level and you will be required to either redo the work or receive a 0 on the assignment. The second violation will result in failing the class. All violations of academic honesty are documented and reported to the Honor Code office.

In this class, we support the University policy regarding discrimination. If you feel you have been discriminated against or require assistance, you may discuss your concerns with an instructor or call the number listed below.

Title IX of the Education Ammendments of 1972 prohibits sex discrimination against any participant in an educational program or activity receiving federal funds. The act is intended to eliminate sex discrimination in education. Title IX covers discrimination in programs, admissions, activities, and student-to-student sexual harassment. BYU's policy against sexual harassment extends not only to employess of the university but to students as well. If you encounter unlawful sexual harassment or gender based discrimination, pleast talk to your professor; contact the Equal Employment Office at 378-5895 or 367-5689 (24 hours); or contact the Honor Code Office at 378-2847.

Brigham Young University is committed to providing a working and learning atmosphere that reasonable accomodates qualified persons with disabilities. If you have any disability, which may impair your ability to complete this course successfully, please contact the Services for Students with Disabilities Office (378-2767). Reasonable academic accomodations are reviewed for all students who have qualified documented disabilities. Services are coordinated with the student and instructor by the SSD Office. If you need assistance or if you feel you have been unlawfully discriminated against on the basis of disability, you may seek resolution throught established grievance policy and procedures. You should contact the Equal Employment Office at 378-5895, D-282 ASB.

Approximate Schedule

Week.	Date	topic	reading	Homework (due dates as announced).	Projects (due on Fridays)
1 (2)	3-Sep	Mutual exclusion	handout
2	8-Sep	Mutual exclusion and Kripke Structures	handout, MC 1, MC 2,2.1	position page about the mutex protocols.
3	15-Sep	Temporal Logics: CTL*	MC 3,3.1	write a kripke structure for a mutex protocol. write a specification for a mutual exclusion protocol. due Friday 9/19
4	22-Sep	Temporal Logics: LTL and CTL, the model checking problem	MC 3.1,3.2, 4-4.1	translate a scripture to CTL*	Kripke parser
5	29-Sep	BDDs, ~~Kripke to BDD translation~~	MC 5.1, 5.2	build a BDD
6	6-Oct	BDDs, Kripke to BDD translation	MC 5.1 5.2	none	nothing
7	13-Oct	Fixpoints and the symbolic CTL algorithm	MC 6.1-6.2		BDD package (due Wed)
8	20-Oct	Counter examples, fairness, etc.		tba	Kripke to BDD translator (due Wed)
9	27-Oct	Buchi Automata and Kripke translation	MC 9.1-9.2	tba	Symbolic MC (due Fri)
10	3-Nov	Checking emptiness using DDFS	MC 9.3	tba	midterm
11	10-Nov	on-the-fly LTL model checking	MC 9.5	tba	Kripke to Buchi translator
12	17-Nov	class interest	?	tba
13 (2)	24-Nov	class interest	?	tba
14	1-Dec				Explicit MC
15 (2)	8-Dec

MIKE: How does this show the group rotation? Project 1: Kripke Structure Parser

Project 4: Symbolic Model Checker

Project 5: Kripke to Buchi Automata Translator

MIKE: How does this show the group rotation?
Project 1: Kripke Structure Parser