6.4 Worked Example: dateFashion

Theory: Worked Example, dateFashion

This worksheet takes a short specification written in words all the way to test cases: causes and effects, the logic, the cause-effect graph, the decision table, and one test per rule. The professor came back to it in the review class (Lecture 9), with one tip that makes the whole method much easier.

From the slides: the specification. int dateFashion(int you, int date). You and your date want a table at a restaurant.

• you and date = how stylish your clothes are, from 0 to 10.
• Return 2 (yes) if either of you is very stylish (8 or more).
• Exception: if either of you has style 2 or less, return 0 (no).
• Otherwise return 1 (maybe).

The Professor’s Tip: Turn the Words into Simple Code First

The professor said that finding the cause-effect graph directly from the words of a specification is hard. It is much easier to first turn the words into a small, simple program (pseudocode). Once you have the code:

• the conditions in the if statements become the causes,
• the return values become the effects.

It is like translating a long recipe paragraph into a numbered checklist before you cook: the steps were always there, but now you can see them. The professor also said to keep the code as simple as possible, because a decision table cannot handle complex statements well.

int dateFashion(int you, int date) {
    if (you <= 2 || date <= 2)       // causes 1, 3
        return 0;                    // effect 70: no (the exception wins)
    else if (you >= 8 || date >= 8)  // causes 2, 4
        return 2;                    // effect 72: yes
    else
        return 1;                    // effect 71: maybe
}

Why the “2 or less” check comes first

The specification says “exception”: that rule beats everything, even a very stylish partner. In the professor’s words, it “trumps everything”. So in the code it must be tested first. If you checked “8 or more” first, a stylish person with a scruffy date, say (9, 2), would wrongly get a table.

Common mistake: forgetting precedence. The first low-style condition wins. U = 9 and D = 2 must return No, not Yes, even though someone is very stylish. A table or code that checks ”≥ 8” first gets this wrong.

Step 1: Causes and Effects

The professor numbered the causes 1 to 4 and took the effect numbers 70, 71, 72 from the slides.

Step 2: The Logic, Remembering What “else” Means

Each branch of an if / else if / else chain is reached only when every earlier condition was false. So “else” means NOT of everything before it.

• 70 (no) comes from the first if: $\;70 = 1 \lor 3$.
• 72 (yes) comes from an else if, so the first if must have been false: $\;72 = (1 \lor 3)' \land (2 \lor 4)$.
• 71 (maybe) comes from the else, so the if and the else if must both have been false: $\;71 = (1 \lor 3)' \land (2 \lor 4)'$.

To reach MAYBE you must answer “no” twice, and each “no” is a NOT.

Exam radar: the professor stressed this rule and posted it again for the class:

$$\text{maybe} = (1 \lor 3)' \land (2 \lor 4)'$$

with both NOTs. Expanding with De Morgan, maybe = $1' \land 3' \land 2' \land 4'$: all four causes are false. Forgetting the second NOT turns “maybe” into the formula for “yes”.

Step 3: The Cause-Effect Graph

Two OR nodes group the causes (“someone is ≤ 2”, “someone is ≥ 8”). The “no” rule wins, so it is NOT-ed on its way to both YES and MAYBE; MAYBE also needs the NOT of “someone is ≥ 8”.

Step 4: The Decision Table

The professor reminded the class: in a decision table, all the entries in one rule (one column) are joined by AND. An OR cannot fit in one column, so every OR must be split into separate rules:

• 70 = 1 ∨ 3 becomes two rules: T1 (1 is true) and T2 (3 is true).
• 72 also becomes two rules: T3 (2 is true) and T4 (4 is true), both with 1 and 3 false.
• 71 is one rule: all four false.

Conditions that do not matter in a rule get an X.

Some inputs match two rules, for example (1, 1) matches T1 and T2, but those rules give the same effect, so the table stays consistent. Every one of the $11 \times 11 = 121$ possible inputs matches at least one rule, and the rules it matches give the same answer as the code: the table is complete.

Step 5: One Test Case per Rule

How to write the answer: extra marks. Notice that c1 and c2 can never both be 1 (nobody is ≤ 2 and ≥ 8 at once); the same holds for c3 and c4. So add an E constraint between c1 and c2, and between c3 and c4. And a good tester adds BVA: (3, 5) → 1 and (7, 7) → 1 sit just inside the “maybe” zone, and (9, 2) → 0 checks that the exception really wins.

Worked Examples

String shipping(int items, boolean remote) {
    if (remote)            // cause 1
        return "charged";  // effect A
    else if (items >= 10)  // cause 2
        return "free";     // effect B
    else
        return "charged";  // effect C
}