Release date: Monday, 27.04.15 - Due date: Sunday, 03.05.15, 23:59

dsp: I stumbled upon a blog post & podcast about
The Devilish Origins of "Pumpernickel". Enjoy !

You colleague created a textual description of the domain of the “cloud BAKERY 2100”. Use Abbott's method to translate it into a class and object diagram.

Besides the customers, maintainers are users of the system and have as well a username 
and password. Customers place orders for a date to be produced at a station. The order 
contains items having the count of the ordered types of baked goods. The ordered baked 
good type has to be offered at the station where the order is produced. Baked good types 
have - besides a name - a price and a production recipe. Customers own credit cards by 
which orders are payed. Credit cards have a holder, a number and a verification value.

Customer Bart (username = "bart the bartender", password = "i can afford it") placed an 
order for the "01.05.15" to be produced at the station named "4 Your Convenience". The 
order contains 12 bread rolls each at 0,25 ct and 4 croissant each at 1,05 ct.

Although we will only evaluate the final diagram, we suggest to follow the following steps:

1. Mechanical translation
   • Identify the different parts of speech in the text. E.g. with different text markers.
   • Mechanically translate them into a class and object diagram.
2. Adding common sense
   • Review your model and clarify it.
   • You may add some multiplicities, where you are sure about them.
   • You must not invent additional elements.

As a starting point you find the A04T11_CloudBakeryDomainObjectModel file in your repository.

The UI designer used in the UI prototype already the notion of the status of the order. This is a natural idea. Nevertheless the for states “Scheduled”, “In Production”, “Ready”, “Retrieved” are not enough to represent all possibilities.

Do some brainstorming to answer the following questions:

1. What are the triggers that change the state of the order? List them.
2. Are there additional states that are relevant for the customer or the system? List them.

In addition we have the following requests:

• It should be possible to cancel the order (at least in some states).
• Integrate the possibility that the system might be temporary out of ingredients.
• What happens, if the customer does not pick up his baked goods?
• We like composite states so much, that we would love to see a meaningful one in the diagram.

Start with A04T12_CloudBakeryOrderStatemachine from your repository and complete it according to your ideas and our requests.

When you are done, check for each state whether it “responds” to every trigger¹⁾, that could be relevant.

There is a sample solution for the use case diagram of the cloud BAKERY 2100 from Task 09. Use this Use Case Model and your Domain Object Model (Task 11) to create an Analysis Object Model. Make sure that all use cases are covered and all actors can interact with the system.

Tip: We described a straightforward strategy for creating an Analysis Object Model in the Requirements Analysis slides. See slide 52-60.

Start with A04T13_CloudBakeryAnalysisModel.

To verify that your model is complete do some walkthroughs in your mind.²⁾

a) Analysis Object Interaction

In A04T14_CloudBakerySequenceDiagram you find a fragment of the Use Case Model (The use cases “Order baked goods”, “Authenticate”, “Pay”) and a fragment of the Analysis Object Model that realizes these three use cases. In addition you find the interaction of the actors with the system for these use cases modeled as a sequence diagram in Blackbox sequence. In this diagram you find only one lifeline for each actor and a lifeline for the system.

In Whitebox sequence we started already a more detailed diagram that shows how the analysis objects need to interact to realize the three use case. Complete the diagram. Tip1: You need all the analysis objects that we added to the fragment of the Analysis Object Model. Tip2: Make sure that only objects sends messages only to objects that it knows.

b) Instance Form vs Descriptor Form

The sequence diagram you completed in a) is in instance form. Describe in your own words the semantical differences between the instance form and the descriptor form of a sequence diagram.

Describe a short interaction of an actor with the the cloud BAKERY 2100 in a simple sequence diagram in descriptor form that uses one alt(nerative) or one loop. Instead of using the descriptor form one might use two separate sequence diagrams in instance form to convey the same information (although not in a formal way). Try to do this for your example. In total we want to have three different sequence diagrams. One in descriptor form and two in instance form. Please choose an example that is as concrete as possible.