HTW Berlin Fachbereich 4 Internationaler Bachelor Studiengang Internationale Medieninformatik (Bachelor) Informatik 3 Winter Term 2023/24
	Info 3: Informatik III Modern Software Engineering

Your job

Your job over the course of the semester will be to design a system for selling custom sandwiches online. We will be implementing a rough draft in Rails at the end of the semester, but until then we have to understand what the system needs to do and give it a good design before we implement. You should form a team of two to three people. You can change during the semester if need be, but it would be good to work together all semester. Choose a name for your team! This exercise spans two weeks. The first week you need to form your team and start reading up about use cases. Begin thinking about the project, but don't start your diagrams until the second week. Lab reports are due before the lab in two weeks at 22.00. Each team will submit a core report that should be the same for all members of the team, each team member needs to include a personal reflection on what they learned in this exercises and state the amount of time (in and out of class) spent on the exercise.

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:

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, although I sometimes enjoy using a stick-woman figure just to be ornery.

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, such as the one given in Wikipedia. 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.

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.

A number of scenarios are usually collected and abstrated 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.

Our case study

The Hoagie To-Go Webshop (HTW) is planned to be an online-shop where people can customize their own hoagies for pick-up or delivery. The product manager has asked you to design and develop the platform for their business. Your site will need to be extensible, we want to get a basic shop set up first.

Users of the site need to be able to select from three kinds of bread (white, whole-meal, rye), two main ingredients, and a selection of vegetables and condiments. You decide which main ingredients, vegetables, and condiments your store will be offering. There are two sizes, regular and large to pick from. A user can order more than one hoagie in one order and have them delivered to an address of their choice, or reserved for pick-up. The delivery address can be different from the billing address.

The product manager also wants an area on the web shop for people to upload a selfie of themselves while eating their custom hoagie, and a short comment on the eating experience. The comment should be about Twitter-sized, as they may want people to tweet this, and they capture it in a database. But that's for a future version...

They can pay via various payment methods, at least by money tranfer (we are in Germany only), or credit card, or using a popular online payment service called MoneyPal. If they use a credit card, a processing fee will apply.

As this service will start in Berlin, you will need to plan for various languages. For the first phase, at least English and German should be possible. Note that there will be different shipping charges leveled depending on where the delivery address is located.

Food preparers will need to be given information about the orders, and the management will want statistics on which ingredients are used the most and on which days of the week. An invoice will need to be printed to accompany each order.

Administrators are responsible for maintaining the information about available products.

Exercises

1. Your first job is to identify the actors in such an application system. Give them names and a one sentence description of their jobs. There may be actors missing.
2. Now each member of the team develops at least three scenarios. That means at least 9 scenarios for a 3-person-group, at least 6 for a two-person group.
3. From the scenarios now develop the use cases. Which actors are involved with which use case? Give the use cases names and describe them using the format above.
4. Draw appropriate use case diagrams with a tool to show how your actors communicate in the use cases. Try to generalize from some concrete situations, what is the common part? Can you perhaps even define an inheritance hierarchy, that is, there is a general, a sort of "super" use case that has specialist use cases? Fix the use case diagram to reflect this! We use arrows between the use case ovals to denote this. Look up the syntax on the web and include the URL of where you found it in your report.

There is a forum for submitting exercises in Moodle - please have your exercises online here by 22.00 the day before the next exercise as indicated on the schedule. Please include all materials (scenarios, use cases and use case diagrams) in one PDF and don't forget to put the names of each person involved on the report. Alternate formats such as ZIP files will be considered not submitted.

A report should include information on the class, the lab, the date, and all explanations should be in complete sentences, either in German or in English. Always include a short (4-5 sentence) reflection on how difficult each of you found this exercise and how long you spent in and out of class. All material in this exercise should reflect your own work. Submitting work of other groups (especially those from years past) or from the Internet is not acceptable. If your materials are not in on time, the exercise will be marked failed, 0 points.