EECS3311 Fall 2020 Software Design
Instructor: Chen-Wei Wang Practice Questions 2020-12-11
Name (Print):
Prism Login Signature
This question set contains 9 pages (including this cover page) and 4 problems.
Check to see if any pages are missing.
Enter all requested information on the top of this page before you start the questions, and put
your initials on the top of every page, in case the pages become separated. This is a closed book test, and no data sheets are permitted.
Attempt all questions. Answer each question in the boxed space provided. The following rules apply:
• NO QUESTIONS DURING THE TEST.
• If a question is ambiguous or unclear, then please write your assumptions and proceed to answer the question.
• Write in valid Eiffel syntax wherever required.
• Where descriptive answers are requested, use com- plete sentences and paragraphs. Be precise and concise.
• Organize your work, in a reasonably neat and coherent way, in the space provided. Work scat- tered all over the page without a clear ordering will receive very little credit.
• Mysterious or unsupported answers will not receive credit. A correct answer, unsupported by calculations or explanation will receive no credit; an incorrect answer supported by substantially cor- rect calculations and explanations might still re- ceive partial credit.
• All answers must appear in the boxed areas in this booklet. In the worst case, if you feel you need more space, use the back of the pages; clearly in- dicate when you have done this.
Do not write in this table which contains your raw mark scores.
Problem
Points
Score
1
10
2
15
3
15
4
40
Total:
80
EECS3311 Fall 2020 Practice Questions – Page 2 of 9 2020-12-11
Writing Unit Tests for Contracts
1. Consider the following Eiffel code for: 1) the contract view of the ACCOUNT class; and 2) its (client) test class:
class ACCOUNT create make feature
balance: INTEGER
credit: INTEGER
make (new credit: INTEGER)
ensure
balance = 0 and credit = new credit
withdraw (a: INTEGER)
— Withdraw amount ‘a’.
require
positive amount: a > 0
enough balance: balance + credit − a >= 0 ensure
balance = old balance − a and credit = old credit invariant
positive credit: credit > 0
balance not too low: balance + credit >= 0 end
class
TEST ACCOUNT
inherit
ES TEST
create
make
feature
make
do
— Add tests here. end
feature
— Define test features here. end
You can assume that the two invariant constraints are correct: the credit is always positive, and the balance may go negative, provided that it is not smaller than −credit (i.e., 0 − credit).
(a) You are required to write a test case which verifies that the current precondition for the withdraw feature in class ACCOUNT is not too weak. Consider the following use case: say an account object acc is created with an initial credit value of 10, and a subsequent call of acc.withdraw(11) should cause a precondition violation with the corresponding tag. Your have two tasks (both written in valid Eiffel syntax): 1) Convert this use case to a feature test withdraw precondition not too weak; and 2) Write the line of code, appearing in the make feature of class TEST ACCOUNT, that adds this feature as a test case. Hint: You should first decide whether to implement this feature as a command or a query.
[ of 5 points]
EECS3311 Fall 2020 Practice Questions – Page 3 of 9 2020-12-11
(b) You are required to write a test case which verifies that the current precondition for the withdraw feature in class ACCOUNT is not too strong. Consider the following use case: say an account object acc is created with an initial credit value of 10, and a subsequent call of acc.withdraw(10) should not cause any precondition violations.
Your have two tasks (both written in valid Eiffel syntax): 1) Convert this use case to a feature test withdraw precondition not too strong; and 2) Write the line of code, appearing in the make feature of class TEST ACCOUNT, that adds this feature as a test case. Hint: You should first decide whether to implement this feature as a command or a query.
Information Hiding and the Iterator Pattern
2. Consider the following three classes:
[ of 5 points]
class
SHOP
feature
cart: CART
checkout: INTEGER
do from
orders.start until
orders.after do
Result := Result + cart.orders.item.price ∗
cart.orders.item.quantity orders.forth
end end
end
class
CART
feature
orders: LINKED LIST [ORDER]
end
class
ORDER
feature
product name: STRING price: INTEGER quantity: INTEGER
end
Each shop object contains a cart of orders. The checkout feature calculates the total amount that is due for the current cart of orders.
EECS3311 Fall 2020 Practice Questions – Page 4 of 9 2020-12-11 (a) The above design violates the principle of information hiding. How?
Your answer should clearly explain all of the following: • who the supplier is and who the client is;
• the problem on the supplier side; and • the problem on the client side.
(b) One way to resolve the above problem is to apply the iterator pattern to it. Your task is to draw a BON diagram detailing the new design after the iterator pattern is implemented. Your diagram must include all of the following:
• all necessary deferred and effective classes and features;
• all necessary client-supplier and inheritance relations;
• an expanded view of the SHOP class showing how the checkout feature is changed.
[ of 5 points]
[ of 10 points]
EECS3311 Fall 2020 Practice Questions – Page 5 of 9 2020-12-11
Genericity: Design
3. Figure 1 shows the design (omitting contracts) of a book that stores people’s records of any types, implemented using two arrays. It is assumed that the stored records are indexed by the set of names (i.e., an existing name maps to a single record, whereas an existing record might be associated with multiple names).
class BOOK create make feature
make
— Initialize an empty book.
add (r: ANY; n: STRING) — Add an entry to the book.
get (n: STRING): ANY
— The associated record of person with name ‘n’.
find (r: ANY): ARRAY[STRING]
— Names of people whose associated records are equal to ‘r’.
feature {NONE} — Implementation names: ARRAY[STRING] records: ARRAY[ANY]
end
Figure 1: Design of A Book of Any Records
Consider the following Eiffel test case for the above design of book (Figure 1). The feature day of the week is a query defined in the DATE class, which returns an integer value, ranging from 1 to 7, representing the current date’s day of the week (1 for Sunday, 7 for Saturday, and so on).
test book: BOOLEAN local
b: BOOK
birthday: DATE
phone number: STRING
do
create b.make
create phone number.make from string (‘‘416−967−1010’’) b.add (phone number, ‘‘Jared’’)
create birthday.make (1975, 4, 10)
b.add (birthday, ‘‘David’’)
Result := b.get (‘‘David’’).day of the week = 4
end
1 2 3 4 5 6 7 8 9
10 11 12 13
Figure 2: A test case for the book
EECS3311 Fall 2020 Practice Questions – Page 6 of 9 2020-12-11 (a) The above Eiffel code (Figure 2) does not compile, which line? Why?
[ of (b) Write, in valid Eiffel syntax, the fix for making the identified line in part (a) compile.
Hint: Consider an explicit cast via the attached expression in Eiffel.
[ of
(c) Improve the design shown in Figure 1 (page5) by creating a new class GENERIC BOOK. This new class declares a generic parameter for the type of stored records. In your answer, show both the class declaration and feature signatures (do not worry about implementa- tions or contracts).
3 points]
3 points]
[ of
(d) Consider the above test case in Figure 2 (page5). Say the client decides to have the local variable b as a book that stores dates only. How should the declaration in Line 3 be changed using a generic book?
[ of
(e) After the fix from part (d) on Figure 2 (page5), the code does not compile, which line? Why?
[ of
3 points]
3 points]
3 points]
EECS3311 Fall 2020 Practice Questions – Page 7 of 9 2020-12-11
Genericity: Contracts and Implementations
4. All parts of this question are related to your new design of a generic book from Question 3 (c).
Contracts
(a) An invariant for the GENERIC BOOK class is formally specified as:
∀i, j : INTEGER |
names.valid index(i) ∧ names.valid index(j) •
names[i] ∼ names[j] ⇒ i = j
That is, there are no duplicates of strings stored in the names array (since book records are indexed by string names). Convert this mathematical expression to valid Eiffel using the across syntax. Hints: Consider nesting two across expressions, and using the |..| operator to create iterable integer interval expressions.
[ of 10 points]
(b) The precondition of feature add(r, n) is formally specified as:
∀name : STRING | name ∈ names • ¬ (name ∼ n)
That is, each string in the names array is not equal to the argument name n to be added. Convert this mathematical expression to valid Eiffel using the across syntax.
[ of 3 points]
(c) The postcondition of feature add(r, n) asserts that: 1) sizes of the names and records arrays are both incremented by one; and 2) the argument name n and record r are inserted to the end of the names array and records array, respectively. Write this postcondition in valid Eiffel syntax.
Hint: Consider using the count, lower, and/or upper features from the ARRAY class.
[ of 4 points]
EECS3311 Fall 2020 Practice Questions – Page 8 of 9 2020-12-11
(d) The precondition of feature get(n) is formally specified as:
∃name : STRING | name ∈ names • name ∼ n
That is, there exists a string in the names array that is equal to the argument name n. Convert this mathematical expression to valid Eiffel using the across syntax.
[ of 3 points]
(e) The postcondition of feature find(r) asserts that if the argument record r exists in the book, then the returned array is non-empty. Convert this into valid Eiffel syntax.
Hints: Do not use the if . . . then . . . else . . . end instruction to write this contract; in- stead, consider using a combination of the logical negation and implication, and the is empty and has features from the ARRAY class.
[ of 3 points]
(f) Since both features get(n) and find(r) are queries, they should not modify the state of the current account. So they have the same postcondition which asserts that the pre-state values of the two implementation arrays names and records are equal to their post-state values. Write these two constraints in valid Eiffel syntax.
[ of 6 points]
Implementations
(g) Write in valid Eiffel syntax the implementation for the add feature. Start your answer with the signature of add. Hints: Write your implementation in terms of the two array attributes names and dates. You may declare local variables if necessary. Consider using the force(v: G; i: INTEGER) or put(v: G; i: INTEGER) feature from the ARRAY class.
[ of 4 points]
EECS3311 Fall 2020 Practice Questions – Page 9 of 9 2020-12-11
(h) Write in valid Eiffel syntax the implementation for the find feature. Start your answer with the signature of find. Hints: Write your implementation in terms of the two array attributes names and dates. You may declare local variables if necessary. Consider using the force(v: G; i: INTEGER) or put(v: G; i: INTEGER) feature from the ARRAY class.
[ of 7 points]