Release date: Wednesday, 18.06.14 - Due date: Sunday, 22.06.14, 23:59

This task refers to the Domain Object Model presented above.

Define the following invariants in OCL:

1. The pickup date has to be after the order date.
2. An order may not be empty.
3. The count in an order item has to be at least 1 and not more than 100.
4. An order may only contain baked good types offered at its production station.
5. No two order items in an order may refer to the same baked good type.

Define the following precondition and postcondition for Order.add in OCL:

1. precondition: The baked good type is not already in the order.
2. postcondition: The order contains an order item for count pieces of the baked good.

This task refers to the Domain Object Model presented above.

We are considering the associations

• between the class Maintainer and the class Station and
• between the class Customer and the class Order.

a) Present the Java code for the creation of these two associations strictly following the idea presented in the lecture (slide 18 f.).

b) The idea presented in the lecture has the benefit that it supports the following two invariants:

• For all orders of a customer the orderer of it is that customer.
• The orderer of an order has that order as one of his orders.

Define these two constraints in OCL. Discuss how the idea supports the invariants and when the invariant is fulfilled (3 - 5 sentences).

c) How would you represent this associations in a relational database? Give us the required tables.

Earlier in the lecture we introduced the notion of checked and unchecked exceptions. On slide 29 you find a suggestion how to map a precondition, a postcondition and an invariant to Java code. Given that the code compiles (and TournamentException is not a subclass of KnownPlayerException), what does this tell us about these two exceptions.

In Task 26 we discussed, when to use checked and when to use unchecked exceptions. Discuss from this perspective, whether it was a good choice to have these two exceptions checked or unchecked respectively. (3 to 6 sentences)

This task refers to the Domain Object Model presented above.

We presented three alternatives to map a class hierarchy to a relational database. Describe the three alternatives and how the tables would look like for the classes User, Customer, Maintainer. Discuss the benefits or drawbacks with respect to performance of queries (runtime), changes to the attributes (evolution), storage consumption.

The following task guides you to explore the impact of the Liskov Substitution Principle on method signatures. We are using the concrete types herbivore (animals eating plant) and frugivore (animals eating fruits). If you prefer to think in types S, T, A, B, C consult last years's version. The mapping is Herbivore = S, Frugivore = T, Food = A, PlantPart = B, Fruit = C.

Herbivore, Frugivore and some Food

• Fruit is a subtype of PlantPart and PlantPart is a subtype of Food.

a) Compare the strength of the conditions “x is of type Food”, “x is of type PlanPart”, “x is of type Fruit”!

• Frugivore is a subtype of Herbivore. We expect Frugivore to fulfill all contracts of Herbivore, especially the methods in Frugivore should “demand no more” and “promise no less”.
• In the occult OO language that we are discussing this is the only restriction on the types of parameters and return types.
• Herbivore has a method PlantPart substitudeForFood(PlantPart food) and substituteForFood is overridden in Herbivore.

b) Which of the six signatures that we listed in Herbivore would be allowed for this overriding method. Explain!

For some example code that uses the method "PlantPart substituteForFood(PlantPart food)" click here

List<Herbivore> animals;
	
List<PlantPart> substituteFoodsForAnimals(PlantPart unavailable){
    List<PlantPart> substitutes = new ArrayList<PlantPart>();
    for (Herbivore animal : animals) {
        PlantPart substitute = animal.substituteForFood(unavailable);
        substitutes.add(substitute);
    }
    return substitutes;
}

c) Abstract from the example and explain, which conditions the LSP imposes on parameter types and return types of overriding methods.

d) Explain how this could improve the Builder Pattern (slide 50 in the pattern lecture) a bit.

Historical side note: The implications of substitutability on parameter and return types was already discussed before Barbara H. Liskov and Jeanette M. Wing suggested their criterion for substitutability. Nevertheless, it is interesting that behavioral subtyping implies the older criteria for subtyping of functions.