Z Documents-Software Engineering-Lecture 13 Slides-Computer Science, Slides of Software Engineering

Download Z Documents-Software Engineering-Lecture 13 Slides-Computer Science and more Slides Software Engineering in PDF only on Docsity!

LECTURE 13: A SHORT CASE STUDY

Software Engineering

1 Z Documents

• A Z specification document for a system contains the following: - a set of schemas, which define: ∗ the state space of the system; ∗ the operations, or events, which can occur to the system and possibly cause state changes; - explanatory text, to help the reader to understand the system.

2.1 The Types

• We require three types for our specification: 1. USERS the set of all possible system users; 2. FILES the set of all possible file names; 3. BLOCKS the set of all possible disk block numbers.
• To be able to use these types we must parachute them into our specification. We do this by including the following horizontal schema: [USERS, FILES, BLOCKS]
• Once declared in this way, we can use them as required.

2.2 System Invariants

• What are the invariants on our file system?
  1. there is an upper limit to the number of users;
  2. files must be owned by someone;
  3. the blocks used to store files are not free for subsequent use;
  4. the blocks not used to store files are free;
  5. only system users are allowed to own files;
  6. no file can be owned by more than one user;
  7. no two files can share the same block; 8....

2.4 The Remove Operation

• Inputs: - file name; - user name.
• Pre-conditions: - the user is known to the system; - the file is owned by the user.
• Post-conditions: - number of users does not change; - ditto system users; - blocks formerly occupied by file are now free; - file is no longer owned by anyone.

Remove ∆FileSystem uname? : USERS fname? : FILES

uname? ∈ system users

fname? ∈ owns(uname?)

system users′^ = system users

no users′^ no users

free blocks′^ = free blocks ∪ occupies(fname?)

occupies′^ = occupies
{fname? 7 → occupies(fname?)}

owns′^ = (owns \ {uname? 7 → owns(uname?)}) ∪ {uname? 7 → owns(uname?) \ {fname?}}

Add ∆FileSystem uname? : USERS fname? : FILES

fname? 6 ∈ owns(uname?)

uname? ∈ system users

system users′^ = system users

free blocks′^ = free blocks

no users′^ = no users

∀u : dom owns • (u 6 = uname?) ⇒ owns′(u) = owns(u)

owns′(uname?) = owns(uname?) ∪ {fname?}

occupies′^ = occupies ∪ {fname? 7 → ∅}

3 Closing Remarks

• There are many ways we could extend the basic system; for example, let’s think about access rights, in the UNIX sense.
• In UNIX, each file has access rights associated with three types of user: - user (the file owner); - group (the user category, e.g., staff or student); - other (everyone else).
• For each type of user, there are three possible access rights: - read (is able to read file); - write (is able to alter file); - execute (is able to execute file).
• For example, you might have all your files set so that you can read, write and execute them, your group can read and execute them, and others cannot read, write or execute them.

• The new variable access rights associates files and user types with access rights; for example, if access rights(myfile, g) = {r, w} then people in the same group as the owner of file myfile have read (r) and write (w) access rights to myfile.
• The new invariant means that the function access rights is defined for all combinations of files known to the system, and user types.
• In other words, if myfile is a file known to the system, then access rights is defined for: access rights(myfile, u) access rights(myfile, g) access rights(myfile, o)

• EXERCISES.

Extend the simple specification given here to the full UNIX system. (See the article Specification of the UNIX filing System by Morgan & Sufrin, in IEEE Transactions on Software Engineering, Vol. SE-10 No. 2, 1984.)