SDA SE Wiki

Software Engineering for Smart Data Analytics & Smart Data Analytics for Software Engineering

User Tools

Site Tools


Assignment 2

  • Each team should upload its final solution to the team's SVN directory.
  • The solution should contain:
    • One (Word or PDF) document containing the solution of all tasks.
    • One or more .jude files containing the Tasks' UML diagrams. The naming schema for these files should depend on task numbers. For example, you can create the class diagram for task 5 in this assignment 2 in a file called “A2T05_ClassDiagram.jude”

.

Task 5: Liskov's Substitution Principle

Things may turn out more complicated than they seem at first glance. Consider the following three propositions

  1. All Animals eat Food.
  2. Herbivores only eat Grass.
  3. Carnivores only eat Meat.

Wow, that was difficult. Let's move on. Draw a class diagram that reflects the above propositions.

  • It seems natural to represent the concepts Animal, Herbivore, Carnivore, Food, Grass and Meat as classes.
  • Let's see some specialization relationships between those classes.
  • We would also like to see a method eat somewhere in your diagram. Maybe even in several places. Make sure you specify argument and return types correctly.

Still feeling good? Tell us about your experience. Did you encounter any problems? If you like, go ahead and implement it.


Task 6:(Usage Scenarios und UML Use Cases)

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.

  • 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. This should shrink diagram down to a fairly readable size.

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:

  • 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 aswell 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.

Task 7: UML UseCase Diagrams

You got an e-mail from your customer with a description of his wishes regarding the text editor which you are going to program:

  1. The users may do: close the text editor, save a file (without dialog window), save a file with a specific name (with dialog window), copy text, select text and focus the editor window (by clicking on it).
  2. Selecting text can happen in two ways: by keyboard and by mouse.
  3. Copying text includes selecting text.
  4. Selecting text includes focussing the editor window.
  5. In the special case that a file is unsaved at the time of closing the editor, the file has to be saved.
  6. In the special case that a file is still unnamed at the time of saving, the “Save as…” dialog window opens and lets the user select a name to save it.

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.

Task 8: UML Sequence Diagrams

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.


Optional Tasks

Task O1: (Exam-Style Task)

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.


Task O2: Contacts on your Mobile Phone (Usage Scenarios und UML Use Cases)

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.)


Task O3: More on UML Use Cases

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.

teaching/lectures/oosc/2008/exercises/assignment2.txt · Last modified: 2018/05/09 01:59 (external edit)

SEWiki, © 2020