B15 Informatik 3 (Info3)

Website of Prof. Dr. Barne Kleinen, Professor for Media Informatics (Bachelor/Master) at HTW Berlin

Assignment 02 - Use Cases and Class Diagrams

     <prev next>

Diagram The Art and Science of Diagramming. Foto by Gary Barber

In this exercise you will develop a detailed Scenario for a Use Case, and draw a Class Diagram for an application called “HTW” - Halloween Treats Worldwide.

First, have a look at the description of the system:


Halloween Treats Worldwide

Pumpkins Foto by Pedro J. Ferreira

Halloween Treats Worldwide (HTW) is planned to be an online-shop where people can buy original Halloween Treats. The product manager has asked you to design and develop the platform for their business.

Users of the site need to be able to search the treats offers - mostly pumpkins, but also all other kinds of Halloween treats. For Pumpkins, they need to find information on the type of Pumpkin, it’s size and weight, and of course it’s price and whether it has been carved already.

Users should be able to buy a pumpkin online and have it delivered to an address of their choice. They can pay via various payment methods, at least money transfer, credit card and a popular online payment service called MoneyPal.

As this is an international service, treat/product descriptions should be available in various languages, for the first phase English and German should be made available.

Users should also be able to rate the treats and post reviews and fotos. Administrators can edit and delete those reviews as needed.

Administrators are also responsible for maintaining the information about available products/treats.

The system should also support the back end, that is, the shipment and invoice processes. For the first phase, it will be sufficient if packers can print out order information with a list of items to pack for each order, and invoices can be printed from the system to be mailed out by administrative staff.


Assignment

Use Cases & Scenarios

Identify the use cases in this description and draw a use case diagram.

Then, pick the most important (or interesting) use case. Write down a detailed scenario for that use case (see below). If you work on this in a group, choose a different use case for each person such that you get a couple covered (that is, everyone has to write a different use case scenario!)

See the section “About Use Cases” below for a detailed instruction on how to write the Use Case Scenarios. In addition to the use case scenarios, it might help if you draw a quick sketch (low fidelity, black and white) of the screen layout, as it is not as straightforward as with the ATM in the example.

ATM https://www.flickr.com/photos/smemon/12698012964/

Class Diagram

Then, draw a Class Diagram for your Application. It should contain associations (aggregations and compositions, association classes as needed), generalizations, as well as the most important fields and method names of the classes. As a good introduction to Class Diagrams, I recommend the one on Scott Ambler’s site.

What to turn in

Include the Lab report in your submitted PDF. You can draw all diagrams by hand and include scans or photos in your PDF. I don’t really recommend using an UML tool, because it will probably slow you down considerably if you are using it for the first time. Using CRC Cards on the other hand may be an advantage.


About Use Cases

Use-cases are a szenario-based technique for requirements elicitation. They were first proposed by Ivar Jacobsen as part of his Objectory methodology. There are many different variations on use cases, but the basic idea is to record the situation in which something happens, explain what should happen, and describe any exceptional circumstances which might arise.

In a scenario you describe a concrete use of the proposed system, using the names of a proposed user. In the use case we abstract away from the concrete situations in the scenarios and try and describe the general case. We have user roles and system functionality , which are depicted in diagrams as little stick figures and circles, respectively:

Example use case diagram

An actor is something or someone that interacts with the target system to produce an observable result. There are active and passive actors. They are usually drawn with a stick figure.

A use case is an instance of how an actor would use a software system or a service offered by the system. More than one actor can participate in a use case. We draw use case diagrams to visualize the use cases and write out the use cases using templates. Use case diagrams are decorated with the name given to the use case. A scenario will typically describe the sequence of concrete activities that happen when a user is interacting with the proposed system. It is a detailed, step-by-step description of observable behaviors - that is, it does not describe the internal workings of the machine, but what a user can observe from the outside. We are not worried about how it will be done on the inside, but instead just want to see if the use of the system makes sense. We can branch inside a scenario using an if statement and can repeat steps using a while statement. A scenario will not have exceptional conditions. If it is describing one such exceptional interaction, then it explains each step of what happens. A scenario also does not extend another scenario - it just describes what happens in this concrete instance. We give names to scenarios, so that we can talk about them. The name should somehow be connected to the use case it is describing. Then we describe any precondition that must hold before the scenario can commence. For example: The user has a valid EC card. Then the sequence of steps is listed, followed by a postcondition describing what must hold at the end of the scenario. For example, the account linked to the EC card has been debited by 100 Euros and the user now has 100 Euros cash in her hands and the card is now marked as having been used on the current day.

NameATM Cash Withdrawal
PreconditionEmmy has an EC card with a readable magnetic stripe & the EC card is valid & the EC card is linked to an account with this bank
Sequence of steps1. Emmy puts her card in the magnetic card reader.2. A screen appears asking the user what she wants to do.3. She points to “display balance” on the screen.4. The machine displays the balance and a continuing menu.5. Emmy selects “other actions”.6. Emmy selects “withdrawal”.7. The machine asks for the PIN number.8. Emmy enters her PIN and presses the green button.9. The machine asks how much money she wants.10. Emmy selects the button labelled 150 Euros.11. If (Emmy has enough money in her account) then Money is prepared for dispensing12. Else (Error screen is displayed)13. The machine returns her EC card.14. If (Money ready for dispensing) then Money is dispensed.
PostconditionEmmy is in possession of her card and 150 Euros & the bank account linked to this card has had 150 Euros deducted & the card is now marked as having been used today.

There are also scenarios sometimes referred to as “secondary scenarios” which describe alternate paths. They have their own name, the name of the scenario to which they are referring, and a description of the problem or alternative faced.

NameInvalid PIN
Scenario based onATM Cash Withdrawal
ExceptionRepeat steps 7 and 8 twice if the user enters in an invalid PIN. If the third time still does not give the correct PIN, then retain the card.

A number of scenarios are usually collected and abstracted into a Use Case and expressed graphically by a Use Case Diagram. The elements of a Use Case often include:

  1. Name of the use case
  2. Summary
  3. Actors involved
  4. Basic sequence of steps
  5. Alternate sequence
  6. Exceptions that can occur
  7. Extension points
  8. Trigger
  9. Assumptions
  10. Preconditions
  11. Postconditions
  12. Author and Date

You should realize that every author and every company have their own ways of describing Use Cases, but usually each of these aspects are addressed. We will be using the structure given here.


And remember, there are two parts to this exercise - Use Cases and a Class Diagram!


Based on Exercise01 by Prof. Dr. Debora Weber-Wulff