Assessment OO analysis case study COS 2015-2016

Fill in (0, 1 or 2) de yellow zones in the table below

0= dit not cooperate in that assignment
1= passive cooperation (no active cooperation in discussions, modelling). Only read solutions of
other members.
2= active cooperation in discussions, modelling, use of Visual Paradigm
Student names (family name + first name)

ST1:
ST2:
ST3:
ST4:
ST5:

name
name
name
name
name

student
student
student
student
student

1:
2:
3:
4:
5:

Jeremy De Wit
Ronald Michiels
Geert Van De Abbeele
Glenn Lorenzet
/
Max Score ST1 ST2 ST3 ST4 ST5
scor
e
2
1
1
0
/
Assignme Scope/Probl
5
nt 1
em/busines
s analysis
1
2
1
1
/
Assignme Requireme
5
nt 2
nt analysis/
context
2
2
2
0
/
Assignme Requireme
5
nt 3
nt
analysis/Us
e case
description
1
2
1
0
/
Assignme
Usecase
5
nt 4
realisation
Datamodelli
ng
Total group score
20
% time allocation per
student
Student score

30%

40%

30%

0%

20

Space for lector!!!

Remarks

Assignment1
Finishing date assignment: 26/11/2015
Tasks performed
ST1
Problem Statement Matrix
Problem Description (PIECES): one
Business Use Case Diagram
Activity Diagram
ST2
Problem Statement Matrix
Problem Description (PIECES): two
Business Use Case Diagram
Activity Diagram
Business Class Diagram
ST3
The Product Vision
Problem Description (PIECES): one
Business Use Case Diagram
Activity Diagram
ST4

ST5

Remarks (which parts of the assignment are not finished

or partly finished)
We finished all the parts of Assignment 1.

Assignment2
Finishing date assignment: 3/12/2015
2

Tasks performed
ST1
List Of Stakeholders and Actors
List of Business Rules
List of Quality Attributes (non-funcitonal requirements)
Main Use Case Diagram
ST2
Event Response List
Context Diagram
List of Stakeholders and Actors
List of business Rules
List of Quality Attributes (non-funcitonal requirements)
Main Package Diagram
Main Use Case Diagram
ST3
Event Response List
List of Business Rules
List of Quality Attributes (non-funcitonal requirements)
Use Case List with Ranking
Main Package Diagram
ST4

ST5
Remarks (which parts of the assignment are not finished
or partly finished)
We finished all parts of assignment 2.

Assignment3
Finishing date assignment: 10/12/2015
Tasks performed
ST1
3

Flow of Events for order meal from cafeteria

User stories in UeXceler
Activity Diagram for order meal from cafeteria
State-Chart Diagram for order meal from cafeteria
ST2
Flow of Events for order meal from cafeteria
Flow of Events for order meal from cafeteria in Visual
Paradigm
User stories in UeXceler
Mock-ups (wireframes) in UeXceler
Activity Diagram for order meal from cafeteria
CRUD-Matrix
State-Chart Diagram for order meal from cafeteria
ST3
CRUD-Matrix
State-Chart Diagram for order meal from cafeteria
ST4

ST5

Remarks (which parts of the assignment are not finished

or partly finished)
We finished all parts of assignment 3.

Assignment4
Finishing date assignment: 17/12/2015
Tasks performed
ST1
Operation Contacts
4

Model View Controller Sequence Diagram for order meal

from cafeteria
Communication Diagram for order meal from cafeteria
ST2
Sequence Diagram for order meal from cafeteria
Operation Contacts
Model View Controller Sequence Diagram for order meal
from cafeteria
Communication Diagram for order meal from cafeteria
Design Class Diagram
Normalized Data Diagram
ST3
Operation Contacts
Model View Controller Sequence Diagram for order meal
from cafeteria
Design Class Diagram
ST4

ST5

Remarks (which parts of the assignment are not finished

or partly finished)
We finished all parts of assignment 3.

Table of Contents
1. Assessment Sheets
............................................... 1
5

2. Table of Contents
6
3. Product Vision Document (Assignment 1)
. 7
4. Problem Statement Table (Assignment 1)
. 8
5. Problem Description PIECES (Assignment 1)
9
6. Business Use Case Diagram (Assignment 1)
. 11
1. Activity Diagram Business Use Case (Assignment 1)
.. 12
7. Business Class Diagram (Assignment 2)
.. 13
1. Event response list (use case list) (Assignment 2)
14
8. Context Diagram (Assignment 2)
.. 17
9. Description data flows (Assignment 2)
. 18
10. List stakeholders/actors (Assignment 2)
. 19
11. List business rules (Assignment 2)
20
12. List quality attributes (non-functional requirements) (Assignment 2) ..
21
13. Use case list with ranking (Assignment 2)
.. 22
14. Main use case diagram (package diagram) (Assignment 2)
23
15. System use case diagram for one package (Assignment 2)
. 24
16. Flow of Events for Order meal from Cafeteria (word) (Assignment 3)
25
17. Flow of Events for Order meal from Cafeteria (Vis. Par.) (Assignment 3).
27
18. User stories (4 phases) + mock ups UeXceler screen shots (Assignment 3)
30
19. Activity diagram for use case order meal from cafeteria (Assignment 3)
40
20. Domain class diagrams for order meal from cafeteria (Assignment 3)
..41
21. CRUD-Matrix (Assignment 3)
41
22. State chart diagram for domain class Order (Assignment 3)
. 43
23. System sequence diagram for order meal from cafeteria (Assignment 3)
.. 44
6

24. Operation contracts (Assignment 4)

44
25. MVC Sequence diagram for order meal from cafeteria (Assignment 4)
48
26. Communication diagram for order meal from cafeteria (Assignment 4)
.. 48
27. Design class diagram for order meal from cafeteria (Assignment 4)
49
28. Normalised data model (Assignment 4)
. 49

Product Vision Board

Target Group
Needs

Product

Customers: employees who want to order meals from the

company cafeteria or from local restaurants on-line.
Time issues, the current system costs too much
time, and is too expensive.
Employees will save a lot of time and it will increase food
choices.
A Cafeteria Ordering System is an Internet-based and
smartphone-enabled application that will accept
individual or group meal orders, process payments, and
trigger delivery of the prepared meals to a designated
location on the Process Impart campus.
What makes it desirable and
special
More food choices, no more queues in
cafeteria, local restaurants,

Value

Is it feasible to develop the product?

Yes
How is the product going to benefit the company?
Less money loss, due to much efficient food distribution.
7

What are the business goals?

Reduce the cost of cafeteria food wastage by 40% within
6 months following initial release.
Reduce cafeteria operating costs by 15% within 12
months following initial release.
Increase average effective work time by 15 minutes per
cafeteria-using employee per day within 6 months
following initial release.

Problem Statement Table

Brief Statements of Problem,
Opportunity, or Directive

Urgen
cy

Visibilit
y

Priorit
y or
Rank

Proposed
Solution

ASAP

High

New Development

Employees dont always get the selections they

want because the cafeteria runs out of certain
items.

2
month
s

Medium

After New
Development
provide tracking
abilities to the
program so that
we know what the
employees want
most.

The cafeteria wastes a significant quantity of

food that is not purchased and must be thrown
away.

2
month
s

Medium

After New
Development
provide tracking
abilities to the
program so that
we know how

Employees at the company Process Impact

presently spend an average of 65 minutes per
day going to the cafeteria to select, purchase,
and eat lunch.

many mployees
buy what product.
Future ability for employees to order meals for
delivery from local restaurants would make a
wide range of choices available to employees.

8
month
s

Low

New Development

Future ability to order meals for

delivery from local restaurants could
be more expensive

8
month
s

Low

Cost savings through

volume discount
agreements with the
restaurants.

Problem Description PIECES

Problem 1 (Geert

Van De Abbeele)

Employees at the company Process Impact presently spend an average of 65 minutes per
day going to the cafeteria to select, purchase and eat lunch.
Cause: A lot of choice, too busy, has to be "prepared" immediately after order.
Effect: Bad time-efficiency, could go faster. Ordering and purchasing

takes too long.

Opportunity: Order (and pay) in advance.

Benefit: Just pick up the meal at certain time and start eating at once.
Constraint: Order (and pay) methods. Time margin after order.
Possible Improvements: Less time is wasted in cafeteria.

Problem 2 (Ronald Michiels)

Employees dont always get the selections they want because the cafeteria runs out of certain
items.
9

Cause: Combination of too much orders for certain food-items and the cafeteria staff not
knowing how much ingredients to order beforehand .
Effect: Certain employees are unable to order their desired food.
Opportunity: Better regulating the ordering of meals.
Benefit: Employees being able to order their desired food.
Constraint: Ordering time-gap will have to be implemented.
Possible Improvements: Better served customers and the cafeteria not running out of food.

Problem 3 (Jeremy De Wit)

The cafeteria wastes a significant quantity of food that is not purchased and must be
thrown away.
Cause: There is nothing to track what the customers want most so they make too
much of and too less of some of the products
Effect: Customers are not satisfied with the cafeteria
Opportunity: Implement some tracking abilities in the new system
Benefit: Less food will be wasted, and less food will be out of stock
Constraint: Lots of data has to be saved
Possible Improvements: Money is well spend when this is implemented
Problem 4 (Ronald Michiels)
Future ability to order meals for delivery from local restaurants could be more
expensive
Cause: Local restaurants are not a member of the company's cafeteria chain. They view the
cafeteria as competition. As so, they would like to profit as well.
Effect: Employees have to pay more for their meals when delivered by restaurants.
Opportunity: Make a deal with the local restaurants that meet both wishes. the local
restaurants will provide food and services for the company's employees in return for publicity
and a cut of the revenue.
Benefit: Better relationship between the company and local restaurants as well as their
services and expertise.
Constraint: The Company has to sacrifice a cut of the revenue
Possible Improvements: Company's image, Services for employees.

10

Business Use Case Diagram

11

Activity Diagram of Business Use Case

12

Business Class Diagram

13

Event Response List

Event

Trigger

Source

1.Employee
wants to log in

COS Login
Request

Employee

2.Employee
wants to view
past
transactions

COS View
transactions
request

Employee

3. Employee
wants to place
order

COS Order
request

Use Case

Response

Destinatio
n

Order food

Account details

Employee

View
transactions

Transaction

Employee

Employee
Order food

details

Order
confirmation

Employee

Order details

Payrolldepartment

Transaction

Stock

Order details
4. Employee
wants to
change placed
order

Cos Change
order request

Employee

Employee
Change/Cancel
order

Change
confirmation

Payroll
14

Event

Trigger

Source

Use Case

Response

Destinatio
n
department

Updated order
details

Stock

Order details
5. Employee
wants to cancel
placed order

Cos Cancel
order request

Employee

Employee
Change/Cancel
order

Cancel
confirmation

Updated
transactions list

6. Staff selects
meal(s)

Cos Select
Top Priority
meals request

Cafeteria Staff
Select Priority
meals

List of most
urgent meals

Payroll
department

Stock

Cafeteria
Staff

Stock

7. Staff cooks
meal(s)

Priority meals

Cafeteria Staff

Cook time

Cafeteria

Prepared meal

Delivery
Staff

Prepare meals

Stock changes

8. Staff delivers
meal(s)

Prepared Meals

Address

Cafeteria

Distance

Employee

Cafeteria
Deliver meals

Delivery-time

Delivery

15

Event

9. Management
assigns staff

Trigger

COS Assign
Staff

Source

Management

Use Case

Assign Cafeteria
Staff

Response

Destinatio
n

Staff member

Cafeteria

Role

Cafeteria
Staff

Place

Workhours
Season
10.
Management
changes menu

Ingredient
prices

Day / Week

Cafeteria

New menu

Cafeteria
staff

Management
Change menu

Employee
complaints

Changes
Online
menu
Season
11.
Management
adjusts prices

Ingredient
prices

Menu

Cafeteria

Old price

Cafeteria
staff

Management
Adjust Prices

Employee
complaints
Sales

New price

Corporate
policies

Online
menu
Reason

12. Corporate
Management
changes
policies

Sales
Employee
happiness
Social pressure

Corporate
Management

Change policies

Old policies

Employees

New policies

Cafeteria
Staff

Changes

16

Context Diagram

17

Description of Data Flows

Account = EmployeeID + FirstName + LastName + Password
Order = EmployeeID + Date + Amount of (Meal(s)) + Amount of (Drink(s))
+ Total price + OrderID + Delivery choice {a. At local Cafeteria
/ b. At following address: address}
Cart = List of orders
Address = Town/City + Postal code + Street + Number
Meal = List of ingredients + recipe + price
Menu = List of meals / every day of the week
Employee = Some-one who works at the company + ability to create
Account + Making orders
Cafeteria Staff = People assigned to the cafeteria. + Cook meals +
Deliver meals
Policy = Rules in the Company / Way of working in the company +
Dictate what is allowed and what not.
Payment = Deduction of total price of an order from the employees salary.

18

List of Stakeholders/Actors

Stakeholder/Actor

Role

Intrests

Major Values

Employee

Customer

Ordering food

Easy, quick access to

ordering food

Cafeteria Staff

Supplier

Preserving jobs

More efficient time and

food distribution

Cafeteria Management

Planner

Increasing sales

Reducing wasted food,

increased sales

Corporate Management

Decision maker

Reducing wasted
time

Improving employee
satisfactory

Payroll Departement

Payment dealer

No real intrests

No benefits

19

List of Business Rules

ID

Rule Definition

Type

Static/Dynamic

Source

BR-1

Delivery time windows are 15 minutes,

beginning on each quarter hour.

Fact

Dynamic

Cafeteria
Manager

BR-2

Deliveries must be completed between

10:00 A.M. and 2:00 P.M. local time,
inclusive.

Constraint

Dynamic

Cafeteria
Manager

BR-3

All meals in a single order must be

delivered to the same location.

Constraint

Static

Cafeteria
Manager

BR-4

All meals in a single order must be paid

for by using the same payment
method.

Constraint

Static

Cafeteria
Manager

BR11

If an order is to be delivered, the

patron must pay by payroll deduction.

Constraint

Dynamic

Cafeteria
Manager

BR12

Order price is calculated as the sum of

each food item price times the quantity
of that food item ordered, plus
applicable sales tax, plus a delivery
charge if a meal is delivered outside the
free delivery zone.

Computation

Dynamic

cafeteria
policy; sta
tax code

BR24

Only cafeteria employees who are

designated as Menu Managers by the
Cafeteria Manager can create, modify,
or delete cafeteria menus.

Constraint

Static

cafeteria
policy

BR33

Network transmissions that involve

financial information or personally
identifiable information require 256-bit
encryption.

Constraint

Static

corporate
security
policy

BR86

Only regular employees can register for

payroll deduction for any company
purchase.

Constraint

Static

Corporate
Accounting
Manager

BR88

An employee can register for payroll

deduction payment of cafeteria meals if
no more than 40 percent of his gross
pay is currently being deducted for
other reasons.

Constraint

Dynamic

Corporate
Accounting
Manager

20

List of Non-Functional Requirements

Reliability
1. The COS website and system cant be un-operational for more than 3 hours per 3
months during the workweek.
2. The COS-system cant lose data in case of a power outage.
3. The COS-system has to be able to correctly deal with incorrect input and
operations
Useability
1. The COS website (and system) have to be intuitive to use for both customers and
staff.
2. The COS website has to be disabled-friendly (e.g. Being able to use the website
with just a keyboard, the website being recognized by speech-software, )
3. The COS-app (mobile application similar to the website) has to be available for
both Android and iOS.
Efficiency
1. The COS-system has to react within 3 seconds of a customer/staff request and
deliver results when completed or feedback when an error occurred
2. The COS-system can use a maximum of 2Mb/s of the networks capacity. The
systems size can be maximum 150 GB
3. The COS-system has to be able to handle at least 800 simultaneous users, with a
peak in traffic of 1400 users.
Functionality
1. The COS-website has to be able to predict the arrival/availability of the
customers order with a 5 minute accuracy.
2. The user-accounts of the customers have to be secured, and their data safely and
confidentially stored on our servers.
3. The COS-system can only make 1 error a year when calculating and making
payments of an order.
Maintainability
1. The COS-website and COS-system must have a clear and logical structure, so
adding new functionality is easy and obvious in which subsystem to implement.
2. The COS-system cannot show unexpected/unwanted behavior when
implementing a new feature.
21

3. A new release of the POS-system has to be reviewed within 48 hours of its

release.
Transferability
1. The COS-system has to be easily transferrable between machines (e.g. servers).
2. The COS-system can run on an existing system (business intranet).
3. The COS-system is easy to install on a new machine.

Use Case list with Ranking

Use case

Priority
(M,S,C,
W)

Releas
e (1,2
or 3)

Create account

Place order

Update/change
order

Motivation priority

Is a must have because

without an account, the
employee can't order food.

Is a must have because if the

employee can't place an
order, he will not receive his
food.

Is a should have because it is

not necessary to order a meal,
but is a feature that will be
handy to prevent wrong
orders.

View
transactions

Is a won't have because the

employee does not
necessarily has to be able to
check the transaction history,
might a new feature later on.

View orders

Is a must have because the

staff has to check the orders
in order to prepare them, the
management to analyse them
and the payroll dept. to
process the payments.

22

Moscow priorities

M - must haves: these use cases must be implemented in the end product;

S - should haves: these use cases should be implemented but the product
should work without them;

C - could haves: these use cases could be implemented, but are not necessary;

W - Wont haves: these use cases won't be implemented, but maybe at a later
stage in the process (update for example.).

Main Package Diagram

23

System User Case Diagram for (Order Meal)

24

Flow of Events for order meal from cafeteria

(Word)
Use case ID + Use case name: 2: Order Food
Primary actors: Patron, COS-system
Secondary actors: Cafeteria Staff, Payroll department
Short description: In this use case, the patron (= client/employee) orders food
from the COS-system using the web-interface.

Preconditions: The user must have an account on the COS-website.

Post conditions: The user confirms he/she received his/her order.

Basic flow:
1. The use case begins when the user surfs to the COS-website.

E1: The COS-website is down.

2. The user logs in with his/her username and password.

A1: The user entered an incorrect username or password.

3. The user is logged in and can now make a new order, view a list of past
transactions or edit a placed order.
4. The user chooses to place a new order.
5. The system displays the menu for that day.
6. The user selects one or more meals and their quantities as a order, and
the location where the order should be brought to.

A2: The stock has run out of ingredients to prepare one or more
meals

A3: The user chooses to save the order

A4: The user tries to place an order on an invalid day or past

11:00 PM.

25

7. The system shows the total amount to pay.

8. The user clicks "confirm" to confirm his/her order. The order is labeled
"pending"

A5: The user chooses to cancel the order.

9. The COS-system sends the fee to the Payroll-Department who will

deduct the fee from the user's salary.

A6: The user's (remaining) salary is too low to accommodate for

the purchase.

10. When the COS-system receives a response from the Payroll-Department,

the order is labeled "accepted"

E2: The COS-system does not receive a response

11. The order is added to the batch of orders for that day.
12. The cafeteria staff selects the order.
13. The cafeteria staff starts preparing and cooking the meal(s).
14. Once the order is ready, The delivery staff takes over. The order is
labeled "cooked"
15. The delivery staff delivers the order to the delivery-address.

A7: The Patron is not present at the delivery - address

16. The user receives their meal and signs the reception confirmation.
17. The order is now labeled "done"
18. The use case ends.

Alternative flows:

1. The user entered an incorrect username or password.

Show error "incorrect username/password" and redirect to basic 2

2. The stock has run out of ingredients to prepare one or more meals

3.

Grey out meals for which there are insufficient ingredients

Display alternatives to the user

Redirect to basic 6

The user chooses to save the order

The system saves the order for the user.

The system redirects to basic 6

26

4. The user tries to place an order on an invalid day or past 11:00 PM

5.

Display error message "unable to order: Invalid date/time."

The system proposes to save the order

The system redirects to basic 3

The user chooses to cancel the order

The system asks to confirm the cancellation

The system redirects to basic 3

6. The user's (remaining) salary is too low to accommodate for the

purchase

The system notifies the user that his/her salary is insufficient

The system saves the order

The system cancels the order

The system redirects to basic 3

7. The Patron is not present at the delivery address.

The delivery staff notifies the user

The staff returns the order to the cafeteria for the user to pick up

Error flows:

1. The COS-website is down.

The system displays an Error-message and recommends to retry

within an hour.

2. The COS-system does not receive a response.

The system resends the request after X amount of time

If the system does get response, resume at Basic 11

If not, reject order and display error message (payroll

departement not available).

redirect to order page

27

Flow of Events for order meal from cafeteria

(Visual Paradigm)

Primary Flow
1. The user surfs to the COS-website.
1.1. E1: The COS-website is down.
2. The user logs in with his/her username and password.
2.1. A1: The user entered an incorrect username or password.
3. The user is logged in and can now make a new order, view a list of past transactions or ed
4. The user chooses to place a new order.
5. The system displays the menu for that day.
6. The user selects one or more meals and their quantities as an order, and the location whe
6.1. A2: The stock has run out of ingredients to prepare one or more meals
6.2. A3: the user chooses to save the order.
6.3. A4: The user tries to place an order on an invalid day or past 11:00 PM.
7. The system shows the total amount to pay.
8. The user clicks on "confirm" to confirm the order. The order is labeled "pending"
8.1. A5: The user chooses to cancel the order.
9. The COS-system sends the fee to the Payroll-Department, who will deduct the fee from the
9.1. A6: The user's remaining salary is too low to accommodate for the purchase.
10. When the COS-system receives a response from the Payroll - Department, the order is la
10.1. E2: The COS-system does not receive a response.
11. The order is added to the batch of orders for that day.
12. The cafeteria staff selects the order.
13. The cafeteria staff starts preparing and cooking the meal(s).
14. Once the order is ready, the delivery staff takes over. The order is labeled "cooked".
15. The delivery staff delivers the order to the delivery-address.
15.1. A7: The patron is not present at the delivery-address.
16. The user receives their meal and signs the reception confirmation.
17. The order is now labeled "done".
18. The use case ends.

28

Alternative Flow
1. A1: The user entered an incorrect username or password.
1.1. Show error message "Incorrect username/password".
1.2. Redirect to Primary Flow step 2.
2. A2: The stock has run out of ingredients to prepare one or more meals
2.1. Gray out the meals for which there are insufficient ingredients.
2.2. Display alternatives to the user.
2.3. Redirect to Primary Flow step 6.
3. A3: The user chooses to save the order.
3.1. The system saves the order for the user.
3.2. Redirect to Primary Flow step 6.
4. A4: The user tries to place an order on an invalid day or past 11:00 PM.
4.1. Display error message "unable to order: Invalid date/time".
4.2. The system proposes to save the order.
4.3. Redirect to Primary Flow step 3.
5. A5: The user chooses to cancel the order.
5.1. The system asks to confirm the cancellation
5.2. Redirect to Primary Flow step 3.
6. A6: The user's remaining salary is too low to accommodate for the purchase
6.1. The system notifies the user that his/her salary is insufficient
6.2. The system saves the order
6.3. The system cancels the order
6.4. Redirect to Primary Flow step 3.
7. A7: The Patron is not present at the delivery - address
7.1. The delivery staff notifies the user.
7.2. The staff returns the order to the cafeteria for the user to pick up.

Error Flow
1. E1: The COS-website is down.
1.1. The system displays an Error-message and recommends the retry within an hour.
2. E2: The COS-system does not receive a response
2.1. Redirect to Primary Flow step 11.

29

User Stories UeXceler (Order food)

Patron can login on COS-website using username and password.
1. Allow a Patron to log in to the COS-system
2. Support mobile devices as well (iPhone/iPad, android devices)
3. Allow a new Patron (someone without account) to register
4. Required fields for logging in:
4.1. Username
4.2. Password
5. Required fields for registering:
5.1. Employee ID
5.2. Office Block
5.3. First Name
5.4. Last Name
5.5. Birth Date
5.6. Username
5.7. Password
5.8. Confirm Password
Patron can create a new order with chosen items.
1. Allow a Patron to create a new order.
2. Precondition: The user is already logged in.
3. Required fields:
3.1. Food item (at least one)
3.2. Delivery-Address
3.3. Delivery Date and Hour.
Patron can view a history of transactions.
1. Allow a Patron to view a history of transactions
2. Accessible via homepage.
Patron can cancel a pending order
1. The patron is able to cancel an order.
2. Preconditions: The patron has to be logged in.
Patron can alter a pending order by adding new items or removing existing ones.
1. Patron is allowed to update pending orders.
2. Preconditions: The user is logged in
3. Preconditions: The user has already placed a pending order.

Wire-Frames UeXceler (Order food)

30

Login

31

32

Register

33

Create new Order

34

35

View Transactions

36

Cancel Order

37

Update Order

38

39

Activity diagram for use case order meal from

cafeteria

40

Domain Class Diagram for use case order meal

from cafeteria
41

CRUD Matrix
Activities

Entities
Employe COS
e

Cafeteria
staff

Place new Order

CR

CU

RUD

Update existing
order
Delete existing
order
View transactions

RU

RU

RU

RD

RUD

RD

Change menu
Adjust price
Get orders
Prepare meal

RUD

CRUD

RU

RUD

RUD

RUD

RU

Deliver meal

UD
CRU
D

Corp.
Manag.

Payroll
Department
RU

CRU
D
RUD

Assign staff
Change policy

Caf.
Manag.

RU
UD
CRUD

C = Create new Data | R = Read data| U = Update existing data| D = Delete data

State Chart Diagram for domain class Order

42

43

System sequence diagram for order meal from

cafeteria

Operation Contracts
Subject: COS-System
Name
Ask for login
Responsibilities
Responding to the users request with the login-page. On this page, the user can
identify by logging in.
References
The create new order use case.
Pre conditions
44

The user must have sent a request for the login-page

The user is not logged in yet
Post conditions
The user receives the login-page
The user can now login
Name
Redirect to homepage
Responsibilities
Redirecting the user to his/her custom home-page
References
The create new order use case.
Pre conditions
The user must be logged in
The users account is still valid
Post conditions
The user receives the homepage
The user can make a decision
Name
Redirect to new order page
Responsibilities
Redirecting the user to the create new order page
References
The create new order use case.
Pre conditions
The user must be logged in
The user has clicked the link to create new order
Post conditions
The user receives the create new order screen
The user can now select items to create an order
Name
Ask for Destination Address, Date and Time
Responsibilities
Color the Destination Address, Date and Time fields red while not filled in.
References
The create new order use case.
Pre conditions
The user must be logged in
The user selected his/her food items
Post conditions
The user specified his/her delivery address and date/time.
The user is able to proceed the order
Name
Show total price and ask for confirmation
Responsibilities
Show the total price of the order and ask if the user wants to confirm or cancel
References
The create new order use case.
45

Pre conditions
The user must be logged in
The user selected his/her food items
The user specified his/her delivery address and date/time.
Post conditions
The user can make a decision based on this information
Name
Response from Payroll-Department
Responsibilities
Process the payment of the order and report to COS-system
References
The create new order use case.
Pre conditions
The user must be logged in.
The user selected his/her food items.
The user specified his/her delivery address and date/time.
The user must have confirmed the order.
The COS-system must have sent the order details to the Payroll-Department
Post conditions
The COS-system received an answer and can proceed with the order.
The COS-system can now notify the user.
Name
Feedback: Order successfully placed
Responsibilities
Alert the user that his/her order was successfully processed.
References
The create new order use case.
Pre conditions
The user must be logged in.
The user selected his/her food items.
The user specified his/her delivery address and date/time.
The user must have confirmed the order.
Post conditions
The user received the information that his/her order is completed
The user can now return to the home-page.
Name
Respond with list of orders.
Responsibilities
Show the list of placed orders for that day.
References
The create new order use case.
Pre conditions
The Cafeteria staff must request the list
There have to be placed orders.
Post conditions
The Cafeteria staff can now select orders to prepare
Name
Change status of selected order to pending
46

Responsibilities
Update the state of the selected orders
References
The create new order use case.
Pre conditions
The orders must to be selected by the cafeteria staff
The orders must be prepared
Post conditions
The order is prepared and the state is changed to ready.
Name
Notify delivery staff
Responsibilities
Notify the delivery staff when orders are ready to transport
References
The create new order use case.
Pre conditions
The orders must be prepared
The orders must be ready for transport
The orders date has to match todays date
Post conditions
The Delivery Staff picked up the orders
Name
Confirm (successful) delivery
Responsibilities
Change the state of the delivered orders to done or revoked
References
The create new order use case.
Pre conditions
The orders must be delivered
The orders must be either accepted or declined
Post conditions
The delivered orders are marked done in case of successful delivery
The delivered orders are marked revoked in case of unsuccessful delivery

MVC Sequence Diagram for order meal from

cafeteria

47

Communication Diagram for order meal from

cafeteria

Design class diagram for order meal from

cafeteria

48

Normalized Data Model

49