Things may turn out more complicated than they seem at first glance. Consider the following three propositions
Wow, that was difficult. Let's move on. Draw a class diagram that reflects the above propositions.
Still feeling good? Tell us about your experience. Did you encounter any problems? If you like, go ahead and implement it.
One of your colleagues came back from an interview session with a customer. He has tried to create a preliminary use case diagram (Same file, imported in Jude Community 5.2.1) 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. 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.
These first two steps 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:
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.
You got an e-mail from your customer with a description of his wishes regarding the text editor which you are going to program:
Your task: Draw a complete UML UseCase diagram for these requirements. Use the appropriate stereotypes.
Note: Ignore unspecified features and special cases that were not required by the customer.
Let's go back to the coffeemaker you dealt with for task 6. You had a look at the scenarios? Analyze the first scenario (Karl getting his coffee) with regard to data and control flow. Map the scenario onto a sequence diagram.
Mark the involved objects as either boundary, control, or entity objects.
Here is the description of a (very simple) game:
The player navigates an avatar in search for food through an island. The possible avatars are rabbits and tigers. Each scene in this game contains food in form of cabbage and cows as well as obstacles in form of toppled down tree trunks and rivers. While searching for food these obstacles are to be overcome.
Your Task: Draw a class diagram that depicts the described concepts and relations between them.
Hint: By drawing this diagram, we want to establish a Domain Object Model (or DOM). You should not care about implementation issues yet. Instead concentrate on capturing the described domain as closely as possible. Don't “invent” anything that is not mentioned in the description. Use named associations rather than methods.
The management of contacts e.g. on a mobile phone is the matter of this task. Describe the most important scenarios for dealing with contact management on a mobile phone. Keep you description short and avoid technical details. Take only the position of a user - don't care about implementation. Restrict yourself to the really important situations.
This task should be done by each participant on its own. You can easily just take your phone and protocol what you're doing (or even better describe how you would like your phone to do it).
Now exchange your scenarios among your teammates and create use cases from them. Draw a UML use case diagram. (You might use the case tool JUDE for that and store the resulting file in the svn.)
Assume one of your use cases is “adding a new contact”. This typically involves to enter name parts, phone numbers etc. You might want to have different key settings (or different virtual keys on a touch screen) to ease entering the different data. Modify your UML Use Case diagram accordingly and define special small use cases as you need them.
What happens if you enter a name that already exists in your contact list? We suppose that the name is a unique key, so there should not be multiple entries with the same name. Reflect this situation also in the Use Case diagram and description.