Release date: Wednesday, 01.05.13 - Due date: Sunday, 12.05.13, 23:59

One of your colleagues came back from an interview session with a customer. He has tried to create a preliminary use case diagram A4T01T02_CoffeeMaker based on the notes he had taken during the interview. Unfortunately he got fired before he is able to complete his work. Congratulations to your recent promotion.

During the next interview session, you and the customer end up with a set of scenarios that represent typical uses of the system envisioned by the customer.

Problem Statement

Scenario I: Karl wants to enjoy a coffee during his coffee break.

Scenario II, Variant A: Sharon tries to order coffee while talking to Karl at the same time.

Scenario II, Variant B: Same as A, but the CoffeeMaker is out of change.

Scenario II, Variant C: Same as A, but the CoffeeMaker is out of paper cups.

Scenario III: George is responsible for maintaining the CoffeeMaker.

Your boss asks you to build a use case model from those scenarios. You decide to take your colleagues work as a starting point. As you can see, he failed to write down the flow of events in his early version of the use case model. On the other hand, he seemed to be overly creative in other places. So your first task should be to clean up and validate his work.

• First, you should ease your work as far as possible by removing Use Cases that are clearly not required to cover the scenarios.
• Next, you can try to perform some simplification steps: Try to inline inclusions where possible (i.e. remove included use cases if they represent not more than one step in the flow that isn't even shared between use cases). This should shrink diagram down to a fairly readable size.

These first steps in task 01 did not require any knowledge of the flow of events described by the individual use cases. Think about it: No matter what events are actually attached to the model, the set of scenarios represented by the model should still be the same. Of course, this will change in the following steps:

• Validate that all scenarios are covered.
  • Try to instantiate the “make an order” use case into one of them. While doing so, write down the flow of events.
  • Then continue with the next scenario, adapting (“widening”) your event flow where necessary.
  • It may necessary to add/remove use cases as well as associations to make everything fit in.
• If necessary, iterate the first three steps.

So much for the difficult part. As one last effort, you should try to increase readability of the diagram. Again, this last step does not change the set of scenarios represented by the model.

• Try to beautify your diagram. Check if names are still appropriate, or if factoring out certain things may improve readability.
• Read through the flow of events once more, make sure to eliminate all synonyms or homonyms that might still be there.

Besides coffee (tasks before) and bread (task below) the next most German thing might be beer. So, let us imagine we would be developing a (computers aided / software controlled) beer brewing system.

We mentioned the following classification of requirements:

• [F]unctional Requirements
• Quality Requirements
  • [U]sability
  • [R]eliability (Dependability, Robustness, Safety)
  • [P]erformance (Response time, Throughput, Availability, Accuracy)
  • [S]upportability (Adaptability, Maintainability)
• [+] More Non-Functional Requirements¹⁾
  • Implementation requirements
  • Interface requirements
  • Operations requirements
  • Packaging requirements
  • Legal requirements

a) For a better understand of this list, we suggest that your read through the following section in [BD09] 4.3.2 “Non-functional Requirements”, Table 4-3 in 4.4.7 “Identifying Non-functional Requirements”, 4.6.5. “Identifying Non-functional Requirements” (Table 4-3 applied to an example). You can try online resources as well, but we do recommend the book.

b) Search through the world wide web and see whether you can identify Quality and Pseudo Requirements of such a beer brewing system published by someone. List at least 3 such requirements including the URL where you found them.

c) Before you continue, write a short problem statement describing such a system. You don't need to limit your ideas. We just want to get the context in which you imagine your answers.

d) For each of the 4 quality and 5 pseudo requirements in our list for which you haven't found an example in b) you should suggest a sensible requirement.

Added later: The name of this task confused some of you, as for the cloud BAKERY 2100 only fewer concepts are part of the Domain Object Model, e.g. the bakery itself is no class there. Therefore consider this task (A4T04) as an exercise for applying Abbotts method.

[Task was part of last year's written exam.]

As Germany prides itself on having the largest variety of breads worldwide, you want to develop a simulation of a bakery.

a) As a first step, translate the text next to the following picture into a class-/object-diagram. Use a combination of Abbott’s method and common sense. Don’t worry yet whether the model works for a simulation or not. Besides the class-/object-diagram submit a version of the text where you highlighted the words in different color according to how you represent them in the diagram.

	A bakery is a workplace where baked goods (breads and cakes and pastries) are produced and sold. The bakery consists of a production site and a shop. German bakeries are famous for their special bread, like Pumpernickel. The Haverland Bakery in Soest Germany founded in 1570 is the oldest bakery of Pumpernickel alive.

(The claim of “being the oldest” can just be added as a note.)

b) With which kind of relationship did you connect Bakery and Shop? Why did you choose this relationship and not another one? (1-2 sentences)

More on the topic can be found on Wikipedia: Bakery, Bäckerei, Pumpernickel ( But must not be included into your model )
The picture is public domain and taken from http://commons.wikimedia.org/wiki/File:B%C3%A4ckerladen_19_Jh.jpg.