About validation of Restaurant

Group Phase Specification
1

in the specification is stated:

Screenshot 2026-09-15 102816
Screenshot 2026-09-15 1028162165Ă—681 149 KB

Screenshot 2026-09-15 103001
Screenshot 2026-09-15 1030011613Ă—1131 176 KB

my questions are now:

  1. Has a Resaurant exactly 1 or [0,1] or unlimited basic dishes?

  2. get every Restaurant the same basic dish in the parsing and it only can be adapt through incidents(each Restaurant gets adapted the same way) or how can the basic dish be adapted so that the duration etc. is diffrent for every Restaurant?

  3. We just figured out that at compile time there must be atleast one of waiter,cook and dilivery driver, but there can be 0 Waiters at run time due incidents , is that also the case for deliveryDrivers and cooks?

1 Like
2
  1. A restaurant has every basicDish that has the basicDishFor type of the restaurant
  2. In addition to that, an adaption of a recipe already happens in the Json file: the adapted recipe has the same dishname as the original, but an other Id, and it doesn’t have the basicDishFor property anymore, even tho it practically is one. So you can have multiple recipes with the same name, but there has to be exactly one recipe that contains the basicDishFor property, not less and not more.

For each restaurant type, there exists a fixed set of basic dishes that the restaurant offers. There exists a default recipe for each basic dish, but restaurants are allowed to customize them.

If the restaurant now lists the Id of the adapted recipe in its recipelist, this is the “basicDish” for this restaurant, and it doesn’t offer the original basicDish (which has the same name and the basicDishFor property) anymore, but instead the referenced recipe → So in conclusion, we have a list of basicDishes for each restaurantType, that each restaurant of this type offers by default. However, if the restaurant references an other recipe, that has the same name, but not the basicDishFor property, the original basicDish gets “overwritten” by the referenced. However, you still have to validate the each recipe the restaurant references in its list has a unique Dishname (for example: [1,3] is the recipe list of the restaurant, where 1 has name chickenrice and basicDishFor is set != null and 3 also has name chickenrice and basicDishFor == null or even != null should be rejected)

This post already discussed it: https://forum.se.cs.uni-saarland.de:51443/t/customizable-recipies/78

  1. yeah

All staff numbers remain non-negative, so a reduction beyond 0 results in having 0 members of that staff type.

2 Likes
3

A small correction: The part with the dishNames and exactly 1 required basicDishFor property is wrong, you can have multiple dishes with the same name without one having to have this property.

1 Like
4

Thanks for the answer!
could a tutor validate this answer?

5

@Sascha.Mueller’s answers (with follow-up correction) are almost correct. Clarification:

  1. (Rephrasing of @Sascha.Mueller): Multiple recipe objects may have the same dishName, but each restaurant may own only one of them. Exactly one recipe must contain basicDishFor only when that dish name is a basic dish. Otherwise, none needs it.
  2. Incidents can reduce waitstaff, drivers, or non-EXEC cooks to 0. EXEC cannot be affected by staff incidents (page 26, lines 8-10).
3 Likes