- Tips and Tricks
Release date: Monday, 02.12.13 - Due date: Sunday, 08.12.13, 23:59
[Taken with slight modifications from the exam 2011]
a) Alistair Cockburn described an Agile approach to Use Cases. As we did not introduce the approach this year yet, we give you the four steps here: (In the exam we just gave the first):
(1) Identify the actors and their goals.
(2) Describe the main success scenario.
(3) Name the extension/exceptional conditions.
(4) Elaborate how to handle the exceptional conditions.
b) In the use case description below1) add in the empty brackets the number of the step in which the information was written. As an example we added “1” for the actors and the goal.
Use Case: “Withdraw Money” (and “Contact personal bank assistant”)
Goal (Bank Customer): Withdraw money from own account
|Valid Card||Invalid Card|
|Bank customer enters PIN||…|
|Bank customer enters amount||…|
|Invalid Amount||Amount > Daily Limit||Amount > Account Balance||Amount valid and in Range|
The use case diagram below shows the use cases “Transfer Between Accounts”, “Deposit Money”, “Withdraw Money”, and “Contact personal bank assistant”.
c) Explain the «extend» relation in general and why we use it here (1-2 sentences).
d) Which relation do you expect between use case slices that realize the extended and the extending use case? Why? (1-2 sentences).
e) Explain the terms “scattering” and “tangling”. (1-2 sentences)
f) Have a look at the responsibilities of the «boundary» class
ATM Interface. Can you see “scattering” or “tangling” here? Explain! (1-2 sentences)
Below you see an analysis object model for the use cases that we created for you.
g) Which analysis objects realize the “Withdraw Money” Use Case?
h) Which analysis objects realize the “Contact personal bank assistant” Use Case?
i) Complete the corresponding use case slices for these two use cases (see g) and h)) in the model below.
j) Add the appropriate stereotypes to the dependencies between the usecase slices and non-usecase-specific slices.
k) Add a note to each of the three analysis objects that are extended by an aspect that explains, which responsibility is added by the aspect to the analysis object.
[Taken from an older exam]
SimpleMobilePhonebook is a small application running on mobile devices. A user can edit the details of his contacts. A contact has a name, a phone number and an address. For every contact there can be a voice file recorded as an alternative mean to identify the contact. A user can make a call by entering the name of a contact or by voice lookup. To call a contact identified by voice file, he presses a special button on the screen; the device records his voice and compares it to the voice files for the contacts. If none of the voice files matches with a high enough score a list with the best matches will be presented from which the user can select the contact. After successful selection of a contact the call is initiated.
a) Study the Use Case Diagram thoroughly.
b) Draw a class diagram showing the Domain Object Model (= the entities). It’s quite simple.2)
c) Based on your Domain Object Model and the Use Case Diagram create an Analysis Object Model using the «boundary», «controller», «entity» stereotypes.
d) Which of the elements (including all three stereotypes) in your Analysis Object Model realize the following use cases?
e) In which sense it there “scattering” or “tangling” in your model?
f) Draw a version of the Analysis Object Model separated into Use Case Specific Slices. Either use a graphic program and edit the picture below or bring a print out to the presentation.
Develop our Hotel Management System following the aspect-oriented approach presented in today's lecture. You are free to reuse any model that was present in the lecture or that you (not by other groups) created during any of the previous assignments. We want to see models as well as code. Your solution doesn't need to be a complete Hotel Management System, but the model you are suggesting should be sound and your code should be doing his job.
Your solution has to contain:
Hint: The important thing for us here is that model and code match. Neither of them has to include all the different features we talked about. It is completely sufficient to have a small core functionality included. The code does not have to be perfect. You can get full points even if something is not working.