COSC A SU Assignment 1 (Abstract Data Types) Due: May 17 th, 2002

Transcription

1 COSC A SU Assignment 1 (Abstract Data Types) Due: May 17 th, 2002 This assignment is all about understanding the use of ADT s. You will work with several different ADT s, including one which will ultimately play a role in your project work. 1. Consider the ADT below, an attempt to reverse-engineer the Java class java.util.enumeration. One problem with this effort is that nextelement is a function with a side-effect. Rewrite the declaration to correct this problem. You may add or remove anything you see fit, but you must justify any and all changes. ENUMERATION -- series of elements, returned one at a time OBJECT, BOOLEAN hasmoreelements : ENUMERATION BOOLEAN -- True if this enumeration contains more elements nextelement : ENUMERATION / OBJECT -- returns the next element of this enumeration, error if no more nextelement(e:enumeration) require hasmoreelements(e) -- exception if no more elements exist none (can you add something here?) Solution: The basic solution is simple: we split a function with side-effects into a procedure with side-effects and a function to return the current value. nextelement will now be the procedure with a side-effect: moving a cursor forward. The new function to return the current value will be item. Now, item has to return the current item right from the start, even before nextelement is called for the first time, but it cannot work if the ENUMERATION is empty. Consequently, we need a new tool, empty, to determine if the ENUMERATION is in fact empty. NB: This does not make hasmoreelements redundant, since it only tells us that the ENUMERATION is or is not empty nextelement doesn t remove elements, after all, it just moves the cursor. As for axioms, there s little we can do, except to note that an ENUMERATION with more elements is clearly not empty. Since we re not given a way to control what is in the ENUMERATION (e.g., by adding things), we can t say anything about successive items, for example. ENUMERATION XQFKDQJHG -- series of elements, returned one at a time OBJECT, BOOLEAN XQFKDQJHG hasmoreelements : ENUMERATION BOOLEAN XQFKDQJHG -- True if this enumeration contains more elements nextelement : ENUMERATION / ENUMERATION VLGHHIIHFWVHFWV QRW DOORZHG LQ IXQFWLRQt FRQYHUW WR SURFHGXUH -- move cursor to the next element of this enumeration, error if no more item : ENUMERATION / OBJECT QHZ -- returns the current element of this enumeration, error if empty empty : ENUMERATION BOOLEAN QHZ -- True if this enumeration contains no elements at all nextelement(e:enumeration) require hasmoreelements(e) XQFKDQJHG -- exception if no more elements exist item(e:enumeration) require empty(e) QHZ -- exception if we look for the current element when none exist at all e : ENUMERATION hasmoreelements(e) empty(e) 2. Reverse-engineer an ADT from the Java class java.util.hashtable, i.e., write an ADT for which this class could be the implementation. Ignore the functions clone, entryset, keyset, putall, elements, keys, rehash, values, any inherited functions, and the Hashtable(Map) constructor. Also, consider put and remove to be void, rather 3311 Assignment 1 Sample Solution (long form) Page 1

2 than returning an Object (i.e., consider them to be commands). Write the declaration in the usual form (shown above). Solution: Although there are physical limits on allocating hash tables (e.g., is there enough memory to allocate a hash table of this size, or even any hash table at all?), and many of the functions require non-null (Eiffel: non-void) object references as arguments, ADT s are mathematical constructs, a realm where these issues don t apply. So, we will stay abstract and not worry about them. Of course, the size cannot be negative, the load factor must be positive, as stated in the documentation, and these are things we can and should look at. HASHTABLE -- maps keys to values OBJECT, BOOLEAN, INTEGER, STRING, FLOAT contains : HASHTABLE OBJECT BOOLEAN -- Test if any key maps into the specified value containskey : HASHTABLE OBJECT BOOLEAN -- True if the specified object is a key containsvalue : HASHTABLE OBJECT BOOLEAN -- True if one or more keys map to this value equals : HASHTABLE OBJECT BOOLEAN -- Compare the specified Object with this table for equality get : HASHTABLE OBJECT OBJECT -- Return the value to which the specified key is mapped hashcode : HASHTABLE INTEGER -- Return the hash code value for this table isempty : HASHTABLE BOOLEAN -- Test if this hashtable maps no keys to values size : HASHTABLE INTEGER -- Return the number of keys in this hashtable tostring : HASHTABLE STRING -- Return a string representation of this Hashtable object remove : HASHTABLE OBJECT HASHTABLE -- Remove the key (and its corresponding value) from this hashtable put : HASHTABLE OBJECT OBJECT HASHTABLE -- Map specified key to specified value (i.e., add them to this hashtable) clear : HASHTABLE HASHTABLE -- Clear this hashtable so that it contains no keys make : HASHTABLE (also: make : HASHTABLE) -- Construct empty hashtable with default capacity and load factor (0.75) make_sized : INTEGER HASHTABLE -- Construct empty hashtable with given capacity and default load factor make_sized_load : INTEGER FLOAT HASHTABLE -- Construct empty hashtable with given capacity and load factor As explained above, we ignore the need to check for Void arguments in get, put (both arguments), contains, containskey, containsvalue, equals, and remove, but the real code needs to include the test. Other than these, there are only two things to verify, being that the initial size and load factor are correct. put and remove are tolerant, so we don t need to verify that the key is or is not already present in the hashtable. make_sized(s:integer) require s 0 -- initial size cannot be negative make_sized_load(s:integer,f:float) require f > 0.0 s 0 -- initial size cannot be negative, load factor must be positive The thing to remember in the work with axioms is that even command functions (e.g., remove and put) don't actually change the hashtable but return a brand new object based on the old one, so if k is in h, remove(h,k) h. Not much can be said about hashcode. hashcode computes a number about which we know little, and which is used largely internally. We can t even guarantee that two hashtables will have different codes, although it is likely. As for tostring, the documentation states that the string returned reflects the entries, so changes are reflected in the value of tostring. An axiom below expresses that; it would be tempting to also say that putting the same entry in the second time does not change the string, but we have no information on the order in which entries appear, and if this would then change Assignment 1 Sample Solution (long form) Page 2

3 equals is not problematic as long as we remember that = here does not mean is coreferent ( i.e., refers to the same object ). h1,h2 : HASHTABLE equals(h1,h2) h1 = h2 -- mathematical interpretation (warning: not just a pointer comparison!) h: HASHTABLE, k,v: OBJECT get(put(h,k,v),k) = v -- after you put something in the table, get returns the same value again h : HASHTABLE isempty(h) size(h) -- empty tables have 0 size h : HASHTABLE, k, v: OBJECT get(h,k) v tostring(h) tostring(put(h,k,v)) -- the string displayed depends on values and keys h : HASHTABLE, k: OBJECT containskey(h,k) tostring(h) tostring(remove(h,k)) -- the string displayed depends on values and keys h : HASHTABLE, k: OBJECT containskey(h,k) containsvalue(h,get(h,k)) -- if a key is contained in the table, so is the corresponding value h : HASHTABLE, k: OBJECT containskey(h,k) contains(h,get(h,k)) -- if a key is contained in the table, so is the corresponding value h : HASHTABLE, k: OBJECT containskey(remove(h,k),k) -- a key is no longer in the hashtable after it is removed h : HASHTABLE, k,v: OBJECT containskey(h,k) (remove(put(h,k,v),k) h) -- putting and removing an old key (+ value) changes the table h : HASHTABLE, k,v: OBJECT containskey(h,k) (remove(put(h,k,v),k) = h) -- putting and removing a new key (+ value) leaves the table unchanged overall h : HASHTABLE, k,v: OBJECT containskey(h,k) size(put(h,k,v)) = size(h) the size increases by one if an item with a new key is added h : HASHTABLE, k,v: OBJECT containskey(h,k) size(put(h,k,v)) = size(h) -- the size is unchanged but putting in a value if the key already existed h : HASHTABLE, k: OBJECT containskey(h,k) size(remove(h,k)) = size(h) the size decreases by one if an existing item is removed h : HASHTABLE, k: OBJECT containskey(h,k) size(remove(h,k)) = size(h) -- the size is unchanged if we try to remove a non-existent item h : HASHTABLE size(clear(h)) = 0 -- clearing a table zeroes the size h : HASHTABLE, k,v: OBJECT containskey(put(h,k,v),k) -- a table contains a key after we put it in h : HASHTABLE, k,v: OBJECT containsvalue(put(h,k,v),v) -- a table contains a value after we put it in h : HASHTABLE, k,v: OBJECT contains(put(h,k,v),v) -- a table contains a value after we put it in h : HASHTABLE, k: OBJECT containskey(clear(h),k) -- a table contains no keys after we clear it h : HASHTABLE, v: OBJECT containsvalue(clear(h),v) -- a table contains no values after we clear it h : HASHTABLE, v: OBJECT contains(clear(h),v) -- a table contains no values after we clear it h : HASHTABLE isempty(clear(h)) -- a table is empty after we clear it h : HASHTABLE, k,v: OBJECT isempty(put(h,k,v)) -- a table is not empty if an item is added to it k: OBJECT containskey(make,k) -- no keys are contained in a fresh table i: INTEGER, k: OBJECT containskey(make_sized(i),k) -- no keys are contained in a fresh table i: INTEGER, f: FLOAT, k: OBJECT containskey(make_sized_load(i,f),k) -- no keys are contained in a fresh table v: OBJECT containsvalue(make,v) v: OBJECT contains(make,v) i: INTEGER, v: OBJECT containsvalue(make_sized(i),v) 3311 Assignment 1 Sample Solution (long form) Page 3

4 i: INTEGER, v: OBJECT contains(make_sized(i),v) i: INTEGER, f: FLOAT, v: OBJECT containsvalue(make_sized_load(i,f),v) i: INTEGER, f: FLOAT, v: OBJECT contains(make_sized_load(i,f),v) h : HASHTABLE, k: OBJECT containskey(h,k) (remove(h,k) = h) -- removing a nonexistent key/value pair does not change the table h : HASHTABLE, k: OBJECT containskey(h,k) (remove(h,k) h) -- removing an existing key/value pair changes the table isempty(make) -- a new table is empty i: INTEGER isempty(make_sized(i)) -- a new table is empty i: INTEGER, f: FLOAT isempty(make_sized_load(i,f)) -- a new table is empty size(make) = 0 -- a new table has 0 entries i: INTEGER size(make_sized(i)) = 0 -- a new table has 0 entries i: INTEGER, f: FLOAT size(make_sized_load(i,f)) = 0 -- a new table has 0 entries We might be tempted to add axioms like the following, but they are not valid for the reasons listed: h : HASHTABLE, k,v: OBJECT containsvalue(remove(h,k),v) -- removing a key means removing its value incorrect, since a value might be -- accessible via more than one key h : HASHTABLE, k,v: OBJECT containsvalue(remove(h,k),v) -- accessible via more than one key 3. The VEHICLE ADT, a work in progress, uses the ADT s POSITION and DIRECTION, and has four operations: make make some vehicle located at a particular position; the position cannot be Void location report on the position of the vehicle drive move the vehicle in some direction, to a new location; the direction cannot be Void fill_up tank up the vehicle with n litres of fuel; the amount must be 1 or more Write a declaration for this ADT in the mathematical format used in class, and above. If the above details are not enough to create the ADT, apply common sense and document your decisions. Solution: This is intended as a simple introduction to creating ADT s: rich enough to require all types of functions (creator, command, and query), one precondition, and one or two axioms. By applying a little imagination, more could be added, e.g., a query function to find out how much fuel is still in the vehicle. You may have been tempted to add other things, such as a fuel consumption rate, maximum fuel level, etc., and if you were, all the more power to you! The simplest ADT would be: VEHICLE -- allows us to simulate a vehicle POSITION, DIRECTION, INTEGER RU 5($/ LQVWHDG RI,17(*(5 KHUH DQG HYHU\ZKHUHHUH EHORZ location : VEHICLE POSITION -- where is the vehicle? drive : VEHICLE DIRECTION VEHICLE -- move the vehicle in a given direction fill_up : VEHICLE INTEGER / VEHICLE -- simulates adding n litres of fuel to the vehicle make : POSITION VEHICLE -- creates a vehicle located at a particular position fill_up(v:vehicle,n:integer) require n 1 -- have to fill up with at least one litre of gas 3311 Assignment 1 Sample Solution (long form) Page 4

5 v : VEHICLE, d:direction location(v) location(drive(v,d)) -- driving a vehicle changes its location v : VEHICLE, n:integer location(v) location(fill_up(v,n)) -- filling up a vehicle does not change its location -- (as long as you don t smoke when filling up ;-) If we add a fuel query function, we need to add the following items: fuel : VEHICLE INTEGER -- how much fuel does the vehicle have v : VEHICLE fuel(v) 0 -- can t have a negative amount of fuel v : VEHICLE, d:direction fuel(v) > fuel(drive(v,d)) -- driving uses up fuel v : VEHICLE, d:direction fuel(fill_up(v,n)) = fuel(v) + n -- filling up with n litres of fuel adds n litres to our amount of fuel If we knew more about DIRECTION and POSITION, we might reasonably add preconditions about them, e.g., the vehicle must be on Earth, but this is all we have, so we can t properly add such preconditions. This is good and bad good if we want to describe the Mars Rover, since even this mild precondition would be too restrictive, but bad if we want to have more complete preconditions. Note that some of the questions have red herings, including this one. References to Void are foreign to mathematics, and should not appear in the ADT. 4. In the project, you will be creating software to administer automated tests to students. Faculty members will use it to create tests like the pre-test you wrote in this course, including multiple-choice questions, true-false questions, and questions with a limited range of typed answers (e.g., numbers, single words, etc.). Students will use it to take tests and query their results. Staff members will also use it, when they need to access test results or update class lists, etc. A key ADT for the software will be a representation for the test itself, which must record the constituent questions and allow different forms of access to different people. Students registered in the course associated with the test may read the questions. Faculty members who are teaching the associated course may read the questions, but also alter them and add to the body of questions. Staff members may not read the questions, nor may they alter them in any way. Consider carefully what you believe should be in the TEST ADT, and write a declaration for it in the same form as used in the other questions. Solution: From the above summary, we can extract the following information, with some obvious musings (in subpoints): faculty create their own tests, can read/alter/add to questions faculty must also be able to take their own tests we can also assume they need to access results, otherwise the tests wouldn t be much use, and here we should consider whether they can just access overall results or responses to individual questions do we let faculty alter a test after anyone other than them has taken it? permitting this means that results before and after the change may not be comparable, so it s best not to allow alterations at that point tests have associated questions of different types students can take tests and query the results do we let students take a test twice? we ll assume no, for the time being when can students see their results? surely only after the test has been taken? what level of detail can students see in their results? if we need an audit trail (probably), then we need to record individual responses, but that doesn t mean students must be able to access the responses because of the simple nature of the answers, allowing later viewing of their own answers (and questions!) allows test takers to show their results (and questions!) to other test takers, introducing a strong risk of cheating; the simplest solution here is to only allow students to view overall scores, but to allow faculty to view everything staff members can access test results, can use the information to update class lists, but cannot read/alter questions implicitly, staff members also cannot add questions; as for updating class lists, this may be a red hering, since we ll see that class lists should probably be maintained separately students may only take tests if they are enrolled in the corresponding course so, students who drop the course cannot take tests any more, but can they still access their results? to simplify things, we ll say no 3311 Assignment 1 Sample Solution (long form) Page 5

6 Other issues may crop up, e.g., what do we do with faculty who take courses and thus are also students, or students who work part time in the department office and thus are staff? (In these cases, it may be simplest to require them to use two or more separate userids, but that s an issue to contemplate later.) The above list leaves us with the following list of candidate features: course identifier (query) take test (command) registered students can do this, and the lecturer of the course (you have to debug tests!), but not staff test taken (query) true if someone has taken the test already create a test (creator) lecturer only get or read questions (query) lecturer only alter questions (command) lecturer only add questions (command) lecturer only delete questions (command) not given above, but obvious counterpart to add lecturer only provide test results (query) students can only see overall result, but faculty can review individual responses test name (query) there will be more than one test per course usually, we can safely assume The following features seem like reasonable possibilities, but are not included for the reasons given: class list (query) this is properly recorded with the course, and thus is accessible via the course identifier lecturer (query) this is properly recorded with the course, and thus is accessible via the course identifier maintain class list (command) as noted, the class list belongs to the course record test results (command) on later reflection, we can see this would be a side-effect of taking the test collection of questions (query) although obviously necessary, we can t allow anyone but faculty to use it, since otherwise it would provide a backdoor to reading the questions; faculty already have get questions, however, so they don t need it, either We might also consider offering the following features, but they re not explicitly stated above: reorder questions (command) again, not given above, but obvious lecturer only Before we can list the functions, we have to consider arguments to the functions, specifically, whether the identity of the user will be passed to functions, in order to check permissions, or whether it should be assumed to be present in some sort of global value, or whether it should be checked at an altogether different level or through still another means. It turns out that we can restrict access to some features to specific classes in Eiffel, our target language, so some of the checking could be done that way, but we don t have access to that in the ADT. Since the only way you have to introduce users into the ADT is to use arguments, we ll assume that route. We also need to assume the existence of some as yet undefined ADT s (USER, QUESTION, SCORE, RESPONSE, COURSE), all but one of which are simply used as arguments or return values, and for which no functionality is assumed. By using these types, we stay general; later, these could be represented with standard types (e.g., USER represented as STRING), but going the other way would not be possible. We need to assume two obvious things about the COURSE ADT that it can provide information about the lecturer and the students registered in the course: TEST -- represents a test, with related questions, answers, and results BOOLEAN, INTEGER, STRING, USER, QUESTION, SCORE, RESPONSE, COURSE course : TEST COURSE -- course identifier take_test : TEST USER / TEST -- allows a user to take a TEST test_taken : TEST USER BOOLEAN -- true if the user has already taken the TEST -- (can be total, since we know unqualified people have not take the test) make : USER COURSE STRING / TEST -- lets user create TEST for a given course with a given name get_question : TEST USER INTEGER / QUESTION -- get a specific question from the TEST alter_question : TEST USER INTEGER QUESTION / TEST -- replace specific question with given one add_question : TEST USER QUESTION / TEST -- add given question delete_question : TEST USER INTEGER / TEST -- delete given question overall_score : TEST USER / SCORE -- lets user access own results individual_response : TEST USER USER INTEGER / RESPONSE -- lets lecturer access response of test taker to specific question 3311 Assignment 1 Sample Solution (long form) Page 6

7 individual_score : TEST USER USER INTEGER / SCORE -- lets lecturer access score of test taker on specific question name : TEST STRING -- TEST name, so we can tell them apart! count : TEST INTEGER -- number of questions on TEST take_test(t:test,u:user) require (registered(course(t),u) test_taken(t,u)) lecturer(course(t)) = u -- only registered students or course lecturer can take a TEST -- only lecturer can retake test (to try different possible scenarios) make(u:user,c:course,n:string) require lecturer(c) = u t : TEST (name(t) n course(t) c) -- only lecturer can create a TEST, and the test name must be unique for a course get_question(t:test,u:user,n:integer) require lecturer(course(t)) = u 1 n count(t) -- only lecturer is allowed, and then the question number must be valid alter_question(t:test,u:user,n:integer,q:question) require lecturer(course(t)) = u 1 n count(t) ( s: USER s u test_taken(t,u)) -- only lecturer can, but must be valid question #, and no one has taken test yet add_question(t:test,u:user,q:question) require lecturer(course(t)) = u ( s: USER s u test_taken(t,u)) -- only lecturer can, but only if no one has taken the test yet delete_question(t:test,u:user,n:integer) require lecturer(course(t)) = u 1 n count(t) ( s: USER s u test_taken(t,u)) -- only lecturer can, but must be valid question #, and no one has taken test yet overall_score(t:test,u:user) require (registered(course(t),u) lecturer(course(t)) = u) test_taken(t,u) -- only registered students or the lecturer of the course can access own results individual_response(t:test,f:user,s:user,n:integer) require lecturer(course(t)) = f registered(course(t),s) test_taken(t,s) 1 n count(t) -- only lecturer can see student response, and then student must be registered, must -- have taken test, and question # must be valid individual_score(t:test,f:user,s:user,n:integer) require lecturer(course(t)) = f registered(course(t),s) test_taken(t,s) 1 n count(t) -- only lecturer can see student response, and then student must be registered, must -- have taken test, and question # must be valid t : TEST, u: USER name(take_test(t,u)) = name(t) -- taking the test doesn t change the name of a TEST t : TEST, u: USER course(take_test(t,u)) = course(t) -- taking the test doesn t change the course t : TEST, u: USER count(take_test(t,u)) = count(t) -- taking the test doesn t change the count t : TEST, u: USER test_taken(take_test(t,u)) -- taking the test marks the test as taken for that user t : TEST, n: INTEGER, u: USER get_question(take_test(t,u),u,n) = get_question(t,u,n) -- taking the test doesn t change the questions t : TEST, q: QUESTION, n: INTEGER, u: USER name(alter_question(t,u,n,q)) = name(t) -- altering a question doesn t change the name of a TEST t : TEST, q: QUESTION, n: INTEGER, u: USER course(alter_question(t,u,n,q)) = course(t) -- altering a question doesn t change the course t : TEST, q: QUESTION, n: INTEGER, u: USER count(alter_question(t,u,n,q)) = count(t) -- altering a question doesn t change the count t : TEST, q: QUESTION, n: INTEGER, u: USER get_question(alter_question(t,u,n,q),u,n) = q -- after alteration, the altered questions is what we see t : TEST, q: QUESTION, u: USER name(add_question(t,u,q)) = name(t) -- adding questions doesn t change the name of a TEST 3311 Assignment 1 Sample Solution (long form) Page 7

8 t : TEST, q: QUESTION, u: USER course(add_question(t,u,q)) = course(t) -- adding questions doesn t change the course t : TEST, q: QUESTION, u: USER count(add_question(t,u,q)) = count(t) adding a question increases the count by one t : TEST, q: QUESTION, n: INTEGER, u: USER get_question(add_question(t,u,q),u,count(t)+1) = q -- questions are added to the end t : TEST, n: INTEGER, u: USER name(delete_question(t,u,n)) = name(t) -- deleting a question doesn t change the name of a TEST t : TEST, n: INTEGER, u: USER course(delete_question(t,u,n)) = course(t) -- deleting a question doesn t change the course t : TEST, n: INTEGER, u: USER count(delete_question(t,u,n)) = count(t) deleting a question decreases the count by one t : TEST, q: QUESTION, i,n: INTEGER, u: USER (i n i < count(t)) (get_question(delete_question(t,u,n),u,i) = get_question(t,u,i+1)) -- after deletion, questions after n are moved up one (i.e., #3 becomes #2, etc.) u: USER, c : COURSE, s: STRING count(make(u,c,s)) = 0 -- no questions are initially defined for a test u: USER, c : COURSE, s: STRING course(make(u,c,s)) = c -- we can retrieve the course used to create the test via course( ) u: USER, c : COURSE, s: STRING lecturer(course(make(u,c,s))) = u -- we can retrieve the lecturer used to create the test via lecturer(course( )) u: USER, c : COURSE, s: STRING name(make(u,c,s)) = s -- we can retrieve the name used for the test via name( ) One more thing we would like to represent with this ADT, but which appears to be impossible for us, is that the instant a student takes the test, no more changes may be made. This is implicit in the preconditions, but we d like to draw it out more obviously. Also, the lecturer has no control over when the test is taken, and theoretically it is possible for a student to take the test before any questions have been added! One way to fix this would be to formalise the permission-granting procedure, and add two features: ready and set_ready. Students would only be permitted to take tests which were ready, and only the lecturer would be allowed to set this value, via set_ready (which could only be used if the test had not yet been taken). There would be interesting changes which would follow from this (exercise left for the reader) Assignment 1 Sample Solution (long form) Page 8