22c:181 Formal Methods in Software Engineering

Mini Projects

Students can work on a project in a team of up to 2 people. Each student is responsible for contacting other students and form a team. It is okay to form different teams for the two projects.
Teams of 1 are accepted but not encouraged. In particular, no reduction of work will be granted to them.

Even for teams of 2, the grade for the project will be given on an individual basis. All students will be asked to submit an evaluations (on a form provided by the instructor) of how well they and their teammate performed as team members. Each evaluation is confidential and will be be incorporated into the calculation of the project grade.

• Project 1
• Project 2

---

Project 1

Due date: Friday, March 7, 2008 by 11:59pm

Summary

In this project, you will use Lustre and Luke to implement the control system of a simple door lock, and verify some of its properties. You will then formally specify requirements for it, and verify that these requirements hold.

The Door Lock

Consider a simple electronic door lock, as used in several appartment buildings. On the outside of the door there is a panel, on which one is supposed to type a three-digit code. If one types the right code, the door is unlocked for some amount of time, and one can go in. A picture of such a panel is shown on the right.

Every once in a while, the building superintendent changes the door lock code. To do that he types a new three-digit code and then inserts a master key into the lock. This changes the access code into the new code from that moment on.

Control

The door lock checks the integer signal What and the Boolean signals Press and MasterKey, and produces one Boolean signal Unlocking. The keypad manufacturer has built a keypad that will set the signal Press to true every time a button is pressed. Depending on what button is pressed, the signal What will get a value between 0 and 9. The signal MasterKey is true precisely when the master key is in the key lock.
When the signal Unlocking has value true the door will be unlocked and the door can be pushed open.

Implementation

You are to implement the the lock controller as a Lustre node called Lock. The implementation is divided into three parts as shown below.

The auxiliary node Keypad maps the last 3 digits that were entered on the keypad to an integer number representing the entered code uniquely, and outputs that in the stream Last3.

The node Control keeps track of the current code, also as an integer value, and decides if the door should be unlocked or not. Once the right code has been entered, the node Timer holds the door unlocked for 5 clock cycles.

As stated, the system above is somewhat underspecified. To implement the system make additional, reasonable assumptions as needed and clearly state them in your submitted solution.

Problem 1

(a) Implement the node Keypad with the following interface:

  node Keypad( What : int; Press : bool )
  returns ( Last3 : int );

The node turns the last three digits entered on the keypad into the corresponding integer value.

(b) Using a synchronous observer called ReqKeypad, verify that the following requirements hold for your Keypad node:

R1	The value of Last3 lies between 0 and 999.
R2	If I press a button, the last digit of (the decimal representation of) Last3 is equal to the value of the button.

Hints: (1) Do not forget to state the properties of the environment you assume. (2) Do not use 3 variables to keep track of the last 3 buttons pressed. Instead, use only one variable, and use "mod 100" and "* 10" in your calculations.

Problem 2

(a) Implement a Lustre node Control with the following interface:

  node Control( Press : bool; Last3 : int; MasterKey : bool )
  returns ( Unlock : bool );

The node keeps track of what the current access code is, updates it, and unlocks the door when the correct code has been typed.

(b) Using a synchronous observer called ReqControl, verify that the following requirements hold for your Control node:

R1	Until the access code is first set, the door cannot be unlocked.
R2	If the most recently set access code is typed in, the door will be unlocked.
R3	The door will not be unlocked if something other than the current code is entered.

Hint: You may find the the temporal combinators Since and First useful here.

Problem 3

(a) Put together the nodes Keypad and Control in a node called Lock, with the following interface:

  node Lock( What : int; Press : bool; MasterKey : bool )
  returns ( Unlocking : bool );

This node will hold the door unlocked for 5 clock cycles when the correct code has been typed in.

(b) Using a synchronous observer called ReqLock, try to verify that the following requirement holds for your node Lock:

R1	The door will never be held open for longer than 5 clock cycles at a time.

This requirement will probably not hold for your node Lock. If so, explain why.

(c) Amend the English description of the requirement as needed so that it does hold for your node, and report the new description. Then change the formal definition of R1 to reflect the amended requirement, and verify it with Luke.

Hint: You will probably make use of some kind of counter in the observer. If the verification of your observer takes too long, you may want to add to the requirement above a suitable additional constraint on the values of your counter, to help reduce the induction depth needed for the proof.

Submission

Your submission will consist of the following.

1. One file doorlock.lus containing at least the 3 implementation nodes Keypad, Control, and Lock, described above, plus the 3 synchronous observers ReqKeypad, ReqControl, and ReqLock. Since we will use automatic testing procedures, it is imperative that you respect the interfaces of your Keypad, Control, and Lock nodes be as given in the assignments.

2. One text file report.txt, a short text report containing:
   • The decisions that you had to make to implement the informal system description of this project.
   • The bugs you found when verifying the requirements.
   • Any problems you had during verification and what you did to solve them.
   • For each requirement, an argument for why your formalization corresponds to the informal statement of that requirement above.

You will be reviewed for:

The quality of your implementation. You have to keep the code short and simple. Submissions with complicated, lengthy, redundant, or unused code will be rejected.

Correctness of the formalization of the properties.

The motivations for your decisions in your report.

Send your submission by email to the following address projects181@cs.uiowa.edu.
Your submission should be a single message per team, listing at the top the names of the team members and containing the files above as attachments.

For team solutions, each team member must also individually submit to the same address above a completed team evaluation form, which will be emailed to each student. Failure to submit the evaluation form may result in a 0 for the project.

---

Project 2

Due date: Friday, May 2, 2008 by 11:59pm

In this project you will model an air traffic information system in UML/OCL using the Together tool, and you will check some of their properties using KeY. The system processes information about flights, departures, arrivals and passengers.

Part 1

Specifications

The main entities in this domain are flights, passengers, locations, airports, routes, and seats.

This system models flights, not planes. In particular, it maintains no information on whether a plane is at a gate, etc. A flight is characterized by a flight number and a date, the latter given by three integers: day, month, and year. These date and flight number together serve to identify the flight, so that we may have a flight numbered 123 on May 9, 2008, and another numbered 123 on May 10, 2008.

Passengers are characterized by their name, a string; airports by their code, a string; seats by a row number, an integer, and a position, a string.

The are two types of locations: airports and routes. A route is simply an abstract notion that represents that the plane is in the air somewhere between its source airport and destination airport. This kind of route represents only the simple situation where a flight consists of a single hop, with no intermediate stops (we do not consider more complicated flights).

Each airport is the destination of any number of flights, but each flight flies to exacly one airport. Also, each airport is the origin of any number of routes, but each route originates at exactly one airport. Similarly, each airport is the destination any number of routes, but each route ends in exactly one airport. The origin and the destination airport of a route are distinct.

Each flight has any number of passengers on board, and each passenger is on board of at most one flight. Also, each flight has any number of seats, but each seat belongs to exactly one flight. Finally, each passenger is occupies at most one seat, and each seat is assigned to at most one passenger.

Each location, be it an airport or a route, holds zero or more flights, but each flight is exactly at one location at any given time. If a flight is on a particular route, the destination airport of the flight matches the destination of the route.

A flight is initially at some airport. After it departs, it is on a route from that airport to another airport: its destination. After it arrives, it remains at its destination forever. This makes sense since a flight is uniquely identified by not only its number, but also its date -- thus, a flight instance will only ``fly'' one time.

Problem 1

Create a Together UML2.0 project containing a class diagram modeling the flight system according to the specs above. Create a class for each of the main entities involved, and add all needed associations between the various classes, with proper cardinality constraints. Make sure you assign a name, of your choice, to the client and the supplier roles of every association.

Problem 2

Add each of the following OCL invariants to the model, linking it to the proper class context.

1. The airport code is unique.
2. The number and date attributes of a flight uniquely identify a flight.
3. If a flight is on a route, then the flight's destination matches the route's destination.
4. The source and destination of a route must be different.
5. A seat is assigned to at most one passenger.
6. A passenger occupies at most one seat.
7. Every passenger on a flight must occupy a seat on that flight.
8. Every passenger occupying a seat on a flight must be on board of that flight.

Problem 3

Add the following (incomplete list of) operations to the model. Add OCL preconditions and postconditions to each operation as appropriate to specify the described behavior.

• Flight operations:
  
  
  1. A query operation hasDeparted():Boolean that returns true if and only if the flight has departed (from its origin airport).
  2. A query operation hasArrived():Boolean that returns true if and only if the flight has arrived at its destination airport.
  3. A query operation getAvailableSeats():Set(Seat) that returns the set of unoccupied seats on the flight.
  4. An operation depart() that makes a flight depart, provided that the flight has not departed yet.
  5. An operation arrive() that makes a flight arrive, provided that the flight has departed but has not arrived yet.
  
  
• Seat operations:
  
  
  1. A query operation getflight():Flight returning the flight this seat belongs to.
  2. A query operation getOccupant():Passenger that returns the passenger occupying the seat, if the seat is occupied.
  3. An operation assignTo(p:Passenger) that takes a passenger p and assigns this seat to her, provided that no seat on this flight is already assigned to p.
  
  
• Passenger operations:
  
  
  1. An operation board(f: Flight) that takes a flight, puts the passenger on that flight and makes her occupy an unoccupied seat on that flight, provided that the passenger is not already on board on a flight.
  2. An operation deBoard() that puts the person out of the flight she was in and removes her seat from her set of occupied seats, provided that the flight has arrived at its destination.

Submission

Your submission will consist of the following.

1. One file flights.zip a zip file of the UML project created with Borland Together. (See instructions in the Tools sections on how to produce the zipped file.)

2. One text file report.txt, a short text report containing:
   • The decisions that you had to make to implement the informal system description of this project.
   • For each requirement, a brief argument for why your formalization corresponds to the informal statement of that requirement.

You will be reviewed for:

Correctness and completeness of the formalization of the properties.

The motivations for your decisions in your report.

Send your submission by email to the following address projects181@cs.uiowa.edu.
Your submission should be a single message per team, listing at the top the names of the team members and containing the files above as attachments.