UFMFJA-30-2 Date:14/04/2016

Kenshow Large: 13016784, Will Mandil: 14017874, Paul Morgan: 14001296

Robotic Systems Report

Robot Waiter

Contents
1 Introduction

2 Unified Modeling Language (UML)

2.1 Use Case Diagrams . . . . . . . . .
2.2 Use Cases . . . . . . . . . . . . . .
2.3 Class Diagrams . . . . . . . . . . .
2.4 Sequence Diagrams . . . . . . . . .
2.5 Activity Diagrams . . . . . . . . .

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

.
.
.
.
.

3 Project Aims

1
1
2
4
5
6
8

4 Requirements Documentation
4.1 Environment Elaboration . . . .
4.1.1 The Bar (establishment)
4.1.2 Item(s) . . . . . . . . . .
4.1.3 Database/HQ . . . . . .
4.1.4 Robot Waiter . . . . . .
4.1.5 The Bar (physical) . . .
4.1.6 Customer Interaction . .
4.1.7 Bartender . . . . . . . .
4.1.8 Doorman . . . . . . . .
4.2 Assumptions . . . . . . . . . . .
4.3 Functional Requirements . . . .

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.
.
.

9
9
9
9
9
9
10
10
10
10
11
11

5 Use Case
12
5.1 Use Case Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
5.2 Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
6 Class Diagram
18
6.1 Class and Attribute Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
6.2 Class scenario justification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
7 Increasing Efficiency and Robot Coordination
21
7.1 Scheduling with Wasps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
7.2 Task Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
8 Individual Diagrams
8.1 Willow Mandil Diagrams .
8.1.1 Sequence diagram .
8.1.2 Activity diagram .
8.2 Kenshow Large Diagrams
8.2.1 Sequence Diagram
8.2.2 Activity diagram .
8.3 Paul Morgan Diagrams . .
8.3.1 Sequence Diagram
8.3.2 Activity diagram .

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

.
.
.
.
.
.
.
.
.

23
23
23
24
25
25
26
27
27
28

9 Conclusion

29

10 Group Member Contribution

29

11 References

29

Introduction

For this project report, we hope to adequately capture the requirements of a project to
present to a company that has asked us to design a system by their specification. Through the
use of different requirement capture methods, we hope to exercise and develop our understanding of appropriate requirement capture, as well as industry level standards of presentation.
With designing a system with an external partner such as an employer or an investor,
capturing the appropriate depth of requirements for the wanted system is of primary importance
at many levels throughout the development process. For customers that are less accustomed
to complex development language that designers may often be use to is an important factor to
consider when reporting back to an investor for development feedback. If it is too complex for
their standard comprehension, their feedback may be minimal or their understanding mistaken,
causing errors in any changes made. By keeping the language and methods simple in the early
stages, the possibility of error at the fundamental beginning levels of the design process are less
likely, as well as it being much easier to implement new ideas or features.

Unified Modeling Language (UML)

Throughout this project, we plan to use Unified Modeling Language (UML) in order to
show the design process of our system at different depths of complexity. In the subsections to
follow, we will go into further detail about why we use specific UML methods, and what each
method helps us to achieve.
The exact definition of UML is somewhat disputed, as it is used for a wide variety of purposes
by many different people. It is also argued that there is no strict syntax or method of including
particular snippets of information. However, in its simplest form, UML as stated by Fowler;
a family of graphical notations - backed by a single meta-model - that help in describing and
designing software systems.
UML is versatile and has various levels of depth. This allows us to decide a level of complexity we feel is appropriate for both the task, and the customer. For example, Use Case
Diagrams allow us to clearly capture the interaction requirements in an image format that is
easy to dissect, understand and explain, even to someone that has no previous experience or
knowledge in system structure diagrams. In comparison, Sequence Diagrams are more complex
and is catered more towards designers to show a specific sequence in which objects may interact with each other, including data sent between them. While this allows the design team to
outline the architecture of their system in more detail, it may be inappropriate for a customer
who is outside of this industry due to their limited understanding.
For the purpose of this project, we have decided that using UML to design and visualise our
software system would be most appropriate due to its varying levels of complexity, allowing
our report to be legible to many different comprehensions of customer knowledge.

2.1

Use Case Diagrams

Use Case diagrams show actors, Use Cases and their relationships. An actor is an external
entity that interacts with our system. An actors Use Case shows the interaction they have
with the system in order to achieve their own desired goals. It is important to note that other
systems (such as an electronic device) that is also external to the system could also be classed
as an actor as they can also have a purpose or goal.
As mentioned previously, Use Case Diagrams are a great way for the development team to
outline their understanding of the customers requirements of the system in a diagrammatic
method that is simple to interpret for those outside of their domain.
1

The list below shows all of the rules and symbols we used when creating our own Use Case
diagram for our Robot Waiter, they are are follows:
Outer Box: The box surrounding the Use Cases is used to represent the systems boundary, it should be labeled to define the systems name and include all the Actors Use Cases
inside them.
Stick-man: We use a stick-man to symbolise the actors that interact with the system,
and want the system to perform particular actions on their behalf
Text-filled ovals: Ovals represent the actions the actors are wanting the system to perform.
These ovals are also labeled with a number that is used to reference the Use Case to its
respective Use Case documentation
Lines from the Actor to Use Cases: These lines are used to display the actor that each
Use Case belongs to, as well as how the Use Cases either extend or include another Use
Case action
<<include>>: The use of an include means that the flow of that use case is always
included when that action is done by an actor
<<extend>>: The use of an extend means that the flow of the extending use case is only
included under specific conditions, which will be specified in the documentation of that
Use Case
An example of a Use Case diagram of a system is shown below:

Figure 1: Use Case Diagram Example

2.2

Use Cases

As stated above, Use Cases are used to describe the typical interactions between users of a
system and the system itself, providing a narrative of how the system is used - Fowler (2015).
According to Gorman (2006) we can use Use Cases to describe key scenarios that the system
may go through - they form the basis of interaction design. Though Use Cases are a part of
UML, there is no clear or strict Use Case Template and so our group decided to use the Derak
Colemans standard Use Case template. Colman (1998)
Below is the template we followed, which Colman provided:

Use Case

Description

Actors

Assumptions

Steps

Variations (optional)

Non-Functional

Use Case identifier and reference number and modification

history.
Each Use Case should have a unique name suggesting its
purpose. The name should express what happens when the
use case is performed. It is recommended that the name
be an active phrase, e.g. Place Order. It is convenient to
include a reference number to indicate how it relates to other
use cases. The name field should also contain the creation
and modification history of the use case preceded by the
keyword history.
Goal to be achieved by use case and sources for requirement.
Each use case should have a description that describes the
main business goals of the use case. The description should
list the sources for the requirement, preceded by the keyword
sources.
List of actors involved in use case.
Lists the actors involved in the use case. Optionally, an
actor may be indicated as primary or secondary.
Conditions that must be true for use case to terminate successfully.
Lists all the assumptions necessary for the goal of the use
case to be achieved successfully. Each assumption should
be stated as in a declarative manner, as a statement that
evaluates to true or false. If an assumption is false then
it is unspecified what the use case will do. The fewer assumptions that a use case has then the more robust it is.
Use case extensions can be used to specify behavior when
an assumption is false.
Interactions between actors and system that are necessary to
achieve goal.
The sequence of interactions necessary to successfully meet
the goal. The interactions between the system and actors
are structured into one or more steps which are expressed in
natural language. A step has the form:
<sequence number> <interaction>
Conditional statements can be used to express alternate
paths through the use case. Repetition and concurrency
can also be expressed (see Coleman, 1997, for a proposed
approach to do doing so).
Any variations in the steps of a use case.
Further detail about a step may be given by listing any variations on the man- ner or mode in which it may happen.
<step reference> <list of variations separated by or>
List any non-functional requirements that the use case must
meet. The nonfunctional requirements are listed in the form:
<keyword>: <requirement>
Non-functional keywords include, but are not limited to Performance, Reliability, Fault Tolerance, Frequency and Priority. Each requirement is expressed in natural language or
an appropriate formalism.

Table 1: Use Case Template

2.3

Class Diagrams

A class diagram describes the types of objects in the system and the various kinds of static
relationships among them. Class diagrams also show the properties and operations of a class
and the constraints that apply to the way objects are connected. The UML uses the term
feature as a general term that covers properties and operations of a class. (Fowler, M. 2015).
The Class diagram provides another graphical method of representing an object oriented
system at a much deeper level of abstraction when compared to Use Case Diagrams, thus
allowing developers to go into further detail when understanding the design and going into the
planning and implementation stage of the system.
Class Diagrams are made up of boxes, lines, and arrows. Lines usually represent the give and
take between the objects of a system. Lines that are ended with an empty arrowhead show that
they belong to an Abstract Class, thus inheriting the attributes and operations listed within
that Abstract Class. As well as having an arrowhead pointing towards Abstract Classes, you
can differentiate Abstract Classes from ordinary Classes due to their header text being in italics.
By linking classes to an Abstract Class, the classes inherit the data and methods stated within
the Abstract Class, creating a cleaner and clearer diagram.
The following is a more defined list of the things used when designing a Class Diagram:
Three Part box: Every class in the class diagram will be put into a three part box. Inside
this box will have all the information specific to the class. From top to bottom the box
will include: The Class Name, the Class attributes, the Class operations.
Empty arrowhead line: An empty arrow head points towards an abstract class. This
means that on the opposite end of the arrowhead line is the the classes that belong to
that abstract class.
Abstract Class: Signified by an italics header. All attributes and operations within
Abstract classes are inherited to the children classes.
Numbers at the end of a connector line: These numbers tell us the amount of classes that
can be related to each class. These numbers can be any number that is appropriate for
your system. However, a general syntax of having any amount is 0...*, meaning Zero
to many.

Figure 2: Class Diagram Example

2.4

Sequence Diagrams

A sequence diagram is used most commonly to capture the behavior of a single scenario
within the system. The diagram shows the interaction between object examples and the messages passed between them within the specific use case. (Fowler 2015) As is often the case,
although sequence diagrams are one of the most complex UML diagrams, they are also very
powerful as they allow developers to convey exactly how their Use Cases will work at a lower
level of abstraction. They accommodate time into their system which allows a more in depth
approach than Class Diagrams (of which the sequence diagram is an extension). The list of
specific rules and symbols for sequence diagrams is extensive and so we will only discuss ones
we have used when creating our own individual diagrams. Beneath these rules I have placed an
example diagram to aid the description and to show the flow of time (the ordering of messages
is shown with the order of messages by reading down the page (Fowler 2015)):
Participants: Positioned across the top of the diagram, they represent the objects that
participate in the sequence being described. Participants are shown as a box which
contains the name of the Participant.
Lifelines: These are dashed lines that protrude from the participants vertically down.
They have an activation bar that shows when the participant is active withing the interaction. They are optional within UML however they really help clarify to the reader the
systems behavior.
Messages: Participants can send messages to other participants, this is shown by using a
horizontal line that flows from the sender to the receiver, the message or method name
is written above the line. It is worth noting that it is good form to name the messages
appropriately, thus improving the readability of both the sequence diagram, but also the
code you would be writing. Participants can also send messages to themselves.
Return Messages: These are a spin off of a regular message, but are shown with a dotted
line. They are used to show correspondence of a message. For example, if the message to
a participants lifeline was getProduct, then the return value may be aProduct. (Fowler
2015) They are often used to show the return of a call, and in our sequence diagrams later
on we often do this as it helps to add more description. However, Fowler suggests in UML
distilled that doing this can clutter the diagrams making it harder to read. He comments
I prefer to use them only where they add information, however for the purpose of clarity,
we will treat that as the former.

Figure 3: Example sequence diagram showing message with and without a return (Fowler 2015)

 Interaction Frames: Interaction Frames are what we call loops, conditionals, alternatives,
etc. It is worth mentioning that these sequence diagrams are not particularly good at
showing these at work. They would be better described with an activity diagram. However
for this project, it is required that we use them. Frames divide up the sequence diagram
into one or more fragments. Each frame has an operator, and each fragment can have a
guard as shown below. Guards are used to state that the segment within the frame may
only be carried out if the guards statement (shown with square brackets which contain
the condition) is true.

Figure 4: Example sequence diagram showing Interaction Frames (Fowler 2015)

Operator
ALT
OPT
LOOP

Meaning
(Alternative multiple fragments): Where you can have 2+ alternate frames,
only the frame whose condition is true will execute.
(Operational): the fragment will execute only if the guard condition is true
The fragment can execute multiple times, the guard within the LOOP
frame indicates the basis of iteration
Table 2: All operators used for Interaction Frames

2.5

Activity Diagrams

Activity diagrams are a technique to describe procedural logic, business process, and work
flow. In many ways, they play a similar role to flowcharts, but the principal difference between
them (Activity diagrams) and flowchart notation is that they support parallel behavior. (Fowler
2015)
As Activity Diagrams support parallel behaviour, it is possible to show split flows through
the use of a fork. This allows whoever is using the Activity Diagram to choose the order
activities are completed in as the diagram only shows the essential sequencing, giving no ties
across parallel flows. However, it still needs to be kept in mind that you can only progress from
the join point once all activities are completed inside that forks parallel flows. As there is a
relatively extensive list of specific symbols to be used in Activity Diagrams, only ones that have
been used in the creation of our Activity Diagrams will be discussed. To demonstrate these
symbols, there will also be an example diagram below the symbol explanations.
Initial Node: This is the starting point of the diagram and is shown as a filled circle. It
provides a clear point of entry into the system that the diagram is showing.
6

 End Node: This is the end point of the diagram, shown by a filled circle with a ring
around it. It is possible to have multiple end nodes as different decisions may lead to
varying outcomes
Activity: A rounded rectangle is used to show activities that can occur in the systems
flow. This could be something such as Add Item to Order or Stock Check
Flow: The flow is the representation of logic through the diagram and as such has direction. The flow is shown by arrows, and links activities, decisions, and merges.
Decision: A decision is marked by a diamond. It will only have one flow entering, but
multiple exiting. These output flows typically have conditions attached to them.
Merge: A merge is again marked by a diamond, however it will have multiple flows entering
and only one flow exiting. All flows leading into a merge point must be completed before
the output flow can proceed.
Condition: A condition is text along a flow, typically coming out of a decision point. This
often states a scenario that needs to be fulfilled to progress along that flow.
Use Case: A use case is a box surrounding an activity diagram to give clarity about what
the diagram contains. These can be useful, however are not necessary.

Figure 5: Example activity diagram

Project Aims

The aim of this project is to, using the UML design process, develop a software system for a
Robot Waiter that is to be situated inside an establishment that serves food and drink. We will
undertake this project in a group of three. In the design process for this project, the following
sections will need to be covered:
Section
Requirements
Documentation
Use Cases
Class Diagram
Individual
Diagrams

Sub-sections
Environment Elaboration
Assumptions
Functional Requirements
Use Case Diagram
Use Case Description
Class and Attribute Description
Class Diagram Justification
Activity Diagrams
Sequence Diagrams

In our project, we are trying to achieve a robot that interacts as much as possible with the
public as this is what we believe to be the main attraction of the establishment. We aim to
design a Robot Waiter that is able to successfully perform all of the tasks of a regular waiter,
thus replacing the need for one.

4
4.1

Requirements Documentation
Environment Elaboration

In this section of the report, we will briefly define the environment that we imagine our
robot waiter to be implemented in, as well as defining specific parts of the system that may be
a current grey area in order to avoid conflicts and confusion as our designed system goes on.
4.1.1

The Bar (establishment)

We have designed our Robot Waiter to be situated in a bar where most - if not all - of an
ordinary Waiters tasks will be taken by a mobile Robot Waiter. The Bar will be made up of
many tables, which cannot be moved or combined, all with a specific number of seats that will
not change. We decided this to ensure that our system can keep track of the customer locations
and tables free.
Items ( 4.1.7 ) will all be created at the Bar ( 4.1.5 ), with our Robot Waiters ( 4.1.4 )
delivering prepared items from the Bar to Customers.
4.1.2

Item(s)

Items in our system are simply items that are on the menu. In an attempt to keep our
explanations clean and clear we have combined everything that a customer may want to order
into a single description of item. Items can be any food or drink, alcoholic or not.
4.1.3

Database/HQ

Within our system we have a main server that has its own processing capabilities, acting as
the brain of our system. We have decided to call this processing server HQ. Built into the
HQ we have a storage database that has storage capabilities for all the data and data types that
is required for the system to keep track of the processes going on within the Bar system. The
data stored in this database includes, but is not limited to: Number of Customers, Location of
Tables, State of Tables, Order list, Menu list, Number of Tables, stock of items, button press
boolean values, Robot location, etc.
As the Database handles all the data, the HQ also has the capacity to hold and give out
orders for the Robot Waiters to perform in order to queue processes. In this way, the HQ could
be regarded as the brain of the Bar system.
4.1.4

Robot Waiter

We decided that we would design a mobile robot to be implemented into an already existing
modern-time Bar, with little impact to the system that may already be place. Since we enjoyed
the appeal of having interactions with a mobile robot, we wanted our mobile robot to also be
our delivery system.
Our Robot waiter will be able to understand spoken word and interpret it effectively, as
well as having a system installed physically onto the robot to allow for the delivery of items
from the bar ( 4.1.5 ) to the customers table.
Since we wanted our Waiter to perform the majority of human waiter tasks, we designed
our system with a payment system in mind where the robot could provide being the method
of payment. This means that if the customer has either cash or card, the robot can provide
change, as well as process bank card payments, printing a receipt with both options.

4.1.5

The Bar (physical)

Throughout the requirements document of this report, we will be referring to the bar
many times in relation to going to the bar to pick up items. When we state this, we mean to
refer to physical work surface counter-top that items will be placed on to allow for our waiter
to pick items up for delivery, as well as the general area that items are made, or where the
bartender works.
4.1.6

Customer Interaction

The initial customers interaction will be with the human Doorman, who will have the
ability to interact with our HQ and Database. After being allowed to enter the bar, unless
the customer wishes to visit the bars other facilities or provide feedback, the rest of their
interaction will be with the Robot Waiter.
We have designed our system that, unless the customer wishes to provide feedback, the
robot waiter will be the only part of the system that customers will see and interact with.
Customers will order call a waiter through the use of a push button at their table, and will
order items verbally once the called robot has arrived.
We have also included a possibility that customers may interrupt robots mid-task verbally
if they wish to request information about the bar facilities such as toilets or where the bar is
in order to provide feedback to the bartender.
4.1.7

Bartender

The Bartender in our system is the human in charge of creating all the items that customers
may order, both food and drink. Similar to the Robot Waiter, We have not specified an
amount of Bartenders in our system design to allow for the establishment where our system
will be implemented to expand or condense their workforce appropriate to the size of their
establishment, as well as other factors such as how much staff they can afford, or the efficiency
of their own workers. Therefore, the number of bartenders will be decided by the owner of the
Bar.
The Bartender will know the orders necessary through looking at an interface, inspired by
fast food restaurants that have a similar method of storing orders made by their customers.
The interface will also have a series of buttons accessible by the Bartender that will allow
the Bartender to signal whether the item that has been ordered has been started (to avoid
other bartenders starting the same order), as well as a button to signal that an order has been
completed. Upon completion, the physical item will be placed on the bar and a Robot waiter
called to take it to the appropriate table.
The only other interaction with the system the Bartender has is if a customer wishes to
provide feedback on the bar, to allow for the establishment to improve with customer improvements, suggestions or complaints. We feel that this interaction should be done verbally to
ensure the appropriate message is put across, as well as allowing the bar establishment to have
their own way of dealing with these suggestions, and so we did not think it was necessary to
include the processing of feedback in our system.
4.1.8

Doorman

The Doorman will be the first entity that is in our system that the customer will have any
form of interaction with. The Doorman will have an interactive interface that will allow them
to access the database to call up values of the tables free. As well as being able to efficiently
turn away customers before they enter the bar, this also allows the system to call a robot in
time to take a customer to a table as they enter the bar. This can also help linearise human
10

actions by guiding them to an appropriate table as soon as they enter, which would hopefully
help avoid any customers wondering off or becoming unaccounted for.
Due to the fact that our bar serves many types of item, both alcoholic and non alcoholic,
the age confirmation to allow for legal drinking will not be carried out by the Doorman but by
the Waiter. The system is designed to hopefully increase the customers allowed in the bar, to
achieve maximum profit. Otherwise, customers that may not be of legal drinking age may be
turned away from the bar before entering, even if they had no intention of buying an alcoholic
item.

4.2

Assumptions

Assumptions are a necessity when writing a document of this nature, as in order for our
designed solution to perform in an expected environment, assumptions must be made to provide
information to both the customer and the design team. Assumptions make it unnecessary for
the designers to be forced to discuss every possible eventuality that could occur under the
described environment, no matter what the chances are of it actually occurring.
Listing assumptions is important early on in the design process to allow both the design
team and the customer to be on the same page, with the design team understanding the full
environment that the designed solution is expected to perform.
Our list of assumptions are listed below:
Robot Waiter will be used in an environment where the mechanics of the Robot allow it
to travel smoothly and without fault across the floors of the bar.
Accurate facial recognition.
Customers can all speak English.
Employees have the capacity to govern themselves to an extent with minimal error, under
the governance of the HQ.
No two Robots will vote on a task at exactly the same time.

4.3

Functional Requirements

Functional Requirements capture the intended behavior of the system. This behavior may
be expressed as services, tasks or functions the system is required to perform. (Malan and
Bredemeyer, 2001). Simply put, they are a list of requirements that the system must perform
in order to achieve its goal.
Below are the listed functional requirements for our robot waiter:
...has on-board processing.
...has instant and reliable wireless access for data transmission to and from HQ.
...can successfully navigate around moving and stationary objects and people.
...can successfully avoid unexpected stationary objects not plotted on internal bar map.
...can pick up and manipulate item trays without error.
...has a stable build design and cannot be accidentally toppled or tripped over.
...location and orientation is always known to both Robot and HQ.
11

 ...is able to understand and interpret human speech, independent of accent, effectively
and respond appropriately.
...is able to scan ID cards for age verification, and is able to link scanned ID to respective
customer face.
...is able to be distracted mid-goal by human actors - whom are unrelated to the goal and is able to provide answers to questions before returning back to original task.
...can clear and clean floor and tables.
When running low on battery, returns to charging station and is replaced by another
Robot Waiter.
Functional Requirements for our system:
Read and Write speed to and from the HQ/Database is a high enough speed and reliable
enough to perform tasks and processing of data without flaw or delay.

Use Case

In this section we will display our Use Case diagram and Use Case table documentation
that we created based on our understanding, and the rules that we listed previously in Section
2.1.

5.1

Use Case Diagram

Figure 6: Use Case Diagram

12

5.2

Use Cases
Identifier: Order Item(s)

Use Case
Reference Number: 1
Goal: For a customer to order an item from the menu

Description
Actors
Assumptions

Steps

Non-Functional

Sources: HQ
<Primary > Customer
<1> Robot Waiter is already present in front of the
customer
<1> Customer orders item(s)
<2> Check ID Database for Customer
if (Item = Alcoholic & New Customer)
<3>
Scan Customer ID and add to Database
<4>
Approve or Deny item appropriate to ID results
<5> Add order details to Database
<Reliability>: <ID Scan has no errors>

Table 3: Use Case 1

Identifier: Cancel Order

Use Case
Reference Number: 2
Goal: For a customer to cancel an order

Description
Actors
Assumptions

Steps
Non-Functional

Sources: HQ
<Primary > Customer
<1> Robot Waiter is already present in front of the
customer
<2> Customer has previously ordered an Item
<3> Item(s) have not yet been delivered
<1> Customer cancels order
if (Customer wishes to make a new order)
<2>
goto <Use Case 1 >
<Reliability > : <Accurate voice recognition>

Table 4: Use Case 2

Identifier: Provide Feedback

Use Case
Reference Number: 3
Goal: For a customer to provide feedback about the Bar

Description
Actors
Assumptions
Steps
Non-Functional

Sources: HQ
<Primary> Customer
<Secondary> Bartender
<1> Bartender has a method of recording and storing the
given feedback
<2> Customer has the capability to get to the Bar
<1> Customer goes to Bartender
<2> Customer tells Bartender their feedback
N/A

Table 5: Use Case 3

13

Identifier: Pay Bill

Use Case
Description
Actors

Assumptions

Steps

Non-Functional

Reference Number: 4
Allow the Customer to Pay their bill owed
<Primary> Customer
<Secondary> HQ
<1> Customers card balance is sufficient to pay required
amount
<2 > Multiple Customers pay in one transaction and do not
need the bill to be split
<1> Customer pays required bill amount
if (Customer pays by card)
<2 >
Robot scans Customers card
<3 > Payment is processed and receipt printed
else if (Customer pays by Cash)
<4 >
Cash is processed and appropriate change is
given
<Accuracy>: <Calculation of change owed is accurate>

Table 6: Use Case 4

Identifier: Request Item Info

Use Case
Description
Actors
Assumptions

Steps

Non-Functional

Reference Number: 5
To allow the Customer to request information about specific
items on the menu
<Primary > Customer
<Secondary > HQ
<1> Robot Waiter is present in front of Customer
<2> Customer has the ability for verbal communication
<1> Customer verbally asks Robot Waiter about specific
item on the menu
<2> Robot Waiter sends respective information request to
Database
<3> Robot Waiter relays information to Customer
<Accuracy> : Robots understanding of spoken language
has no errors

Table 7: Use Case 5

14

Identifier: Request info about facilities

Use Case
Description
Actors
Assumptions
Steps

Non-Functional

Reference Number: 6
Allows the Customer to inquire information about the Bars
facilities
<Primary > Customer
<Secondary > HQ
<1> Robot Waiter is present in front of the Customer
<2> Customer has the ability for verbal communication
<1> Customer asks Robot about Bars facilities
<2> Robot sends information request to Database
<3> Robot relays information to Customer
<Reliability >: <Information retrieval speed is sufficiently
fast to create minimal delay between question processing
and answer >

Table 8: Use Case 6

Identifier: Request Customer Info

Use Case
Description
Actors
Assumptions
Steps
Non-Functional

Reference Number: 7
Allow the customer to request information about already
seated customers
<Primary >Customer
<Secondary >HQ
<1> Customer has no malicious intent
<2> Customer is present in front of a Robot Waiter
<1> Customer inquires information to Robot
<2> Robot Waiter sends information request to Database
<3> Robot relays appropriate information to Customer
N/A

Table 9: Use Case 7

Identifier: Deliver Items

Use Case
Description
Actors
Assumptions
Steps
Non-Functional

Reference Number: 8
For the Robot Waiter to deliver items from Bartender to
Customers
<Primary> Bartender
<1> Items are ready to be delivered
<1> Bartender signals that item is ready for delivery
<2> Robot picks up item tray and delivers it to appropriate
Customer table
N/A

Table 10: Use Case 8

15

Identifier: Take Customers to Table

Use Case
Description
Actors
Assumptions

Steps

Non-Functional

Reference Number: 9
For the Robot Waiter to seat new Customers
<Primary> Doorman
<1>
<1> Doorman checks the HQ to ensure that there is room
for the new customer(s)
if (No space in the bar)
<2>
Refuse Customer Entry
else ()
<3>
Accept Customer entry and update Database
accordingly
N/A

Table 11: Use Case 9

Identifier: Add to Database

Use case
Description
Actors
Assumptions
Steps
Non-Functional

Reference Number: 10
To allow for entries to be added to the database
<Primary> Bartender
<Secondary> HQ
<1> HQ storage space is large enough to store what is necessary
<1> Add to Database
<Reliability>: <Read/Write speed is fast>
<Accuracy>: <Send/Receive data is error-less>

Table 12: Use Case 10

Identifier: Delete from Database

Use case
Description
Actors
Assumptions
Steps
Non-Functional

Reference Number: 11
To allow for and an entry in the database to be deleted
<Primary> Bartender
<Secondary> HQ
<1> There is at least one entry in the database
<1> Delete database entry
<Reliability>: <Read/Write speed is fast>

Table 13: Use Case 11

Identifier: Edit Database

Use Case
Description
Actors
Assumptions
Steps
Non-Functional

Reference Number: 12
To allow for an entry in the database to be edited
<Primary> HQ
<1> HQ storage space is large enough to store what is necessary
<1> Edit Database
<Reliability>: <Read/Write speed is fast>
<Accuracy>: <Send/Receive data is error-less>

16

Table 14: Use Case 12

17

Class Diagram

Figure 7: Class Diagram

18

6.1

Class and Attribute Description

In order to represent the system we have created with our Use Cases at a deeper level of
abstraction, we have created a Class Diagram. By splitting what could be a large diagram
into three parts, we can make it simpler to design. The three parts are: Robot navigation,
Customer, and HQ (including the internal systems interactions). As we slowly develop each
part, we can start interconnecting the three main blocks with the relevant relationships.
We found that the diagram we initially started with changed a lot during the design process, especially after each member had created their own sequence diagrams. This highlighted
operations that we had not realised we would need, and helped remove irrelevant ones we had
included. Above is the diagram we created. In the next section, we will discuss relevant attributes and operations with their respective classes to give further information/justification
on why and how our system works.

6.2

Class scenario justification

As stated above, we will explain and justify how key classes (and their respective attributes
and operations) work and why we need them. For clarity, we will refer to the Classes and their
relevant attributes and operations as, CLASS.attribute and CLASS.operations() (Fowler 2015).
The best way to do this will be to run through some scenarios:
Entering the bar (Use Case 9): Upon arriving at the bar the customer will wish to enter
the bar. As the bar is a sit down only bar, they are essentially asking for a table hence
CUSTOMER:requestTable() as some tables can tsee more than others it is necessary to
know how many people the customer is with, hence the customer passes into this function.
This links to the DOORMAN who responds to the request, as the doorman does not
have access directly to the date base he uses an interface DOORMAN INTERFACE
through this he can request seating and table availability with the operation DOORMAN.requestTableAvailability()o send the seating and table availability to the DOORMAN the uses operation DOORMAN INTERFACE.requestTableAvailability()hich gathers this information from the HQ, it then displays to the DOORMAN the values received
along with the table sizes from the TABLE class which holds the sizes (number of seats)
as an integer so that doorman can give the right sized table (number of seats) to the
group. DOORMAN then either accepts or declines entry based on the table availability
displayed on the interface with DOORMAN.declineEntry() or DOORMAN.allowEntry().
In our system we use the robot to take the group to their tables, hence the DOORMAN
INTERFACE.addTaskStimulus() which would then using the HQ and our task allocation
technique send a robot to collect and take the group to their seats.
Ordering an Item (Use Case 1): After CUSTOMER(s) has been assigned a TABLE,
the Customer can call a Robot Waiter when they are ready to order using the Button
at the TABLE INTERFACE. Upon a CUSTOMER.pressButton, a boolean is produced
from the TABLE INTERFACE. When this boolean is high (1), a robot request is added
onto the task stack using TABLE INTERFACE.addTaskToStack(). For the HQ to know
what Button has been pressed, each button has a TABLE INTERFACE.ButtonLocation.
The HQ holds the task stack, and by using the information given when when CUSTOMER.pressButton is called, HQ can send this new task to the Waiter using
HQ.sendTaskStimulus.
Using the location given of the TABLE INTERFACE.ButtonLocation which tells us
which TABLE the Button belongs to, we can make this our new GOAL.Location in
our Waiter using CARTOGRAPHER.updateGoal(). At this stage, we can assume that
19

the map of our bar and the locations have already all been mapped out in a previous process, so it is not needed for our Waiter to CARTOGRAPHER.buildMap()
or CARTOGRAPHER.updateMap(). Now that the Robot has successfully navigated
to the table where the button was pressed by a customer, the customer calls CUSTOMER.startOrder() by choosing items from MENU. This triggers the ROBOT to create a new order using ROBOT.newOrder(). While the CUSTOMER orders ITEMs, the
ROBOT will check if the item is available to order through ROBOT.itemAvailability(),
then ROBOT.addItemToOrder(), followed by ROBOT.requestNextItem() until the CUSTOMER.finishOrder() function is called. For verification, the Waiter can relay the order
back to the CUSTOMER, where they will have the option to CUSTOMER.denyOrder()
if the ROBOT has made a mistake, or the CUSTOMER has changed their mind.
If the ROBOT.itemAvailablilty() returns a negative, the ROBOT will inform the CUSTOMER by calling ROBOT.denyOrder() to let them know that the item ordered is
unavailable.
Deliver Items (Use Case 8): Once the CUSTOMER has called the operation CUSTOMER.selectOrder(), and the BAR STAFF has completed the operations
BAR STAFF.receiveOrder(), BAR STAFF.startOrder() and BAR STAFF.createItem(),
the BAR STAFF proceeds with the BAR STAFF.orderComplete() operation. This in
turn triggers the BAR INTERFACE to call BAR INTERFACE.addTaskToStack(). As
the HQ send the stack of tasks to every ROBOT after a looped predefined time interval,
the newly added task will soon be sent to all ROBOTs for task allocation as described in
Chapter 7.
When the stimulus of the task is high enough for a particular ROBOT, that robot
then calls the operation ROBOT.removeTaskFromStack(). This stops the HQ from
re-sending the delegated task. The ROBOT then calls the operation CARTOGRAPHER.updateGoal(). This will update the operation CARTOGRAPHER.currentGoal()
so the ROBOT is able to view what it now has to do. The CARTOGRAPHER.currentGoal
for this scenario will entail going to the MAP.Collection Point to pick up Items and proceeding to deliver them to the previously known TABLE.Location.
Once the ROBOT has called the operation CARTOGRAPHER.currentGoal(), and is
aware of where it needs to travel (in this first instance, to the MAP.Collection Point which
becomes the NAVIGATOR.GoalLocation), the ROBOT can call the operation NAVIGATOR.planRoute(). Once this is all completed the ROBOT will call PILOT.goToGoal().
When the ROBOT has reached CARTOGRAPHER.currentGoal, it will call the function ROBOT.collectItem(). The ROBOT will now go through this process again after calling CARTOGRAPHER.updateGoal to make TABLE.Location the CARTOGRAPHER.currentGoal.

20

Increasing Efficiency and Robot Coordination

In this section I will discuss how the robot waiter system could adopt the methods proposed
in a paper called Wasp-like Agents for Distributed Factory Coordination by Vincent A.
Cicirell and Stephen F. Smith (2004), and a method for task allocation with mailmen in a book
called Swarm Intelligence from Natural to Artificial Systems.

7.1

Scheduling with Wasps

In the paper they show how to improve the efficiency of the scheduling system by proposing
a system that can dynamically schedule parallel multi-purpose machines based on the natural
multi-agent system of a wasp colony. The process described could be extended to our robot
bar. If we assume there are many different types of robot waiters, their differences being that
the some can carry more drinks than other, some move faster, some are better at carrying food
over drinks, some have unique properties that make them a better waiter for certain groups
such as a smaller robot thats preferred by kids and familys and they have a changing distance
from the drinks collection point.
In order to coordinate a schedule we would use a voting system, the robot who will complete
the task best is then chosen to carry out the next task. However this does not take into account
the anticipation of future jobs that that robot may be better suited to. Hence, by allowing the
robots the option of not taking part in the biding system and having a No-bid option.
The biding system would work by: each multi-purpose robot waiter has a routing wasp
which is in charge of choosing which jobs the specific robot waiter bids on for the chance to be
assigned to that job. Each robot waiter has a set of response thresholds:
= {w,o . . . ,j }

(1)

Where ,j is the response threshold of the wasp (robot waiter) to the jobs of type j
Jobs in the system will be broadcast via the HQ to all routing wasps with a stimulus Sj
which is proportional to the length of time the jobs has been waiting for. The stimulus contains
type of job j (food, drinks, requested for ordering etc.). A routing wasp will then bid or
not-bid for the job with probability:
P (bid|,j,Sj ) =

Sj2
2
Sj2 + ,j

(2)

This is just an assumption that the exponent 2 will be adequate for the task however this
value has not been tested or simulated and so could change.
The threshold of ,j will change in the domain [min , max ]. This is just the process of which
machine will bid on a current job. However it does not take into account that two smaller but
faster robots could carry half the order each and complete it faster... hence wasps are not an
ideal ecological system to represent the robot waiter system. However the routing wasp concept
is a great idea, I shall use this for the basis of my task allocation system however excluding
bidding system that would be commanded by the HQ, for the perpose of simplicity we will just
have the routing wasp if stimulated to bid, it will automatically have that task allocated to it
(taking a first come first served basis).

7.2

Task Allocation

Approaching this from a delivery coordination example described in Swarm Intelligence

from Natural to Artificial Systems. (Bonabeau, Dorigo, and Theraulaz, 1999)
21

In this system they describe a scenario of a group of mailmen who belong to a company,
they have to pick up letters in a large city, the customers should not have to wait a given time,
the aim is to allocate the mailmen to various demands that appear over the course of the day,
keeping the global demand as low as possible. (Bonabeau, Dorigo, and Theraulaz, 1999)
This is a very similar case to the robot bar as the tasks are, ignoring the actual processs
the robot has to go through once at a location where it has a job (for example pick up tray
of drinks, or for the mailman collect letter) locations that the mailman must go to, which is
exactly the same as our robot waiters, the impetus for a good job is keeping the waiting time
down, exactly the same in a bar.
Bonabeau et.all stated that the probability that an individual i, located in zone z(i) will
respond to a demand, Sj (or stimulus if we are to carry on with the routing wasps) located in
zone j is given by:
Sj2
(3)
Pi,j = 2
2
Sj + i,j
+ d( z(i), j)2
where
i,j ([min , max ]) is the response threshold of the mailman i to the demand from zone j
dz(i),j is the distance between z(i) and j (distance could be euclidean or include factors
such as one way streets, lights, expected traffic jams etc.)
, are two positive coefficients that effect the influence of and d.
Using this as a stimulus held by the routing wasps and keeping the overall design of the
wasp scheduling system we now have a changeable but easily implemented technique that allows
for a more efficient work schedule. In the class diagram we have implemented this, by using
operations such as DOORMAN INTERFACE.addTaskStimulus() we are able to change the
stack of stimuluss sent out by the HQ (with HQ.sendTaskStimulus) to the routing wasps
which are contained within the robot for simplicity.
There is so much more I would love to do here however as time is an issue I was not able
to get a fully working simulation developed to test out different values of and . There is so
much more that could be done in this aspect like for example having different types of robots,
all with unique aspects that make them better at a specific job than others, for example having
different speeds, number of drinks it can carry, cup collection, table cleaning efficiency etc, this
would allow the system to come into its own, by having individual responses to job types we
could further home the system. I also havent had the chance to look into a prediction option
within the HQ, when the robots bid for a job, for example, a group of ten people have just
entered the bar, we could assume a large order of drinks will be ordered and ready for delivery
soon, if we have different types of robots then it may be foreseeable that despite a larger robot
be stimulated for a smaller task it may be better to keep it free ready for the predictable large
order. This HQ over site would add further efficiency to the system.

22

Individual Diagrams

8.1

Willow Mandil Diagrams

I will be doing my diagrams on Use case 1 (order Items)

8.1.1

Sequence diagram

Figure 8: Sequence Diagram : Order Items : Willow Mandil : 14017874

23

8.1.2

Activity diagram

Figure 9: Activity Diagram : Order Items : Willow Mandil : 14017874

24

8.2

Kenshow Large Diagrams

Use Case 4 : Pay Bill

8.2.1

Sequence Diagram

Figure 10: Sequence Diagram : Pay Bill : Kenshow Large : 13016784

25

8.2.2

Activity diagram

Figure 11: Activity Diagram : Pay Bill : Kenshow Large : 13016784

26

8.3

Paul Morgan Diagrams

Use Case 9 : Take Customer to Table

8.3.1

Sequence Diagram

Figure 12: Sequence Diagram : Take Customer to Table : Paul Morgan : 14001296

27

8.3.2

Activity diagram

Figure 13: Activity Diagram : Take Customer to Table : Paul Morgan : 14001296

28

Conclusion

Beyond the bare understanding of the UML approach to describing systems and the various
diagrammatic processes within UML, by far the most important thing we have learned as a
group is the importance of fully describing a system before implementation. In doing so it forced
us to properly consider every aspect of our system which in turn pointed out inconsistencies in
our logic and helped us to design a better system for the task at hand, not just one that would
work.
The robot system changed allot throughout the process of this assignment, often we would
take one approach to a problem only to find out it would be better to implement it differently,
UML had a big role in this, by creating class and sequence diagrams almost in tandem it slowly
changed the system from the bottom up, creating and removing use cases, assumptions and
functional requirements.
This was an excellent assignment that gave us a chance do delve into more complex systems
that we hadnt come across before in the course. As for teamwork, we found that although one
group member had no input into the project until the last few days we were still able to deal
with the assignment requirements. This was because of our approach to the task, we finished
everything as early as possible, having meetings weekly. This allowed us to give more time to
the natural evolution of the system as suggested earlier.

10

Group Member Contribution

Group Member
Willow Mandil
Kenshow Large
Paul Morgan

11

Contribution (%)
45
45
10

References

Fowler, M (2015). UML Distilled. 3rd ed. Massachusetts: Pearson Education Limited. 1. 99.
Coleman, D, A Use Case Template: Draft for discussion, Fusion Newsletter, April 1998. Available at http :
//www.bredemeyer.com/pdff iles/usec ase.pdf.
https : //www.bhf.org.uk/get involved/events/training zone/walking training zone/walking f aqs
Malan, R. and Bredemeyer, D. (2001). Functional Requirements and Use Cases. Bloomington: BREDEMEYER
CONSULTING, pp.2, 9. Available at: http : //www.bredemeyer.com/pdff iles/f unctreq.pdf
Cicirello, Vincent A., and Stephen F. Smith. Wasp-Like Agents For Distributed Factory Coordination.
Autonomous Agents and Multi-Agent Systems 8.3 (2004): 237-266. Web.
Bonabeau, E., Dorigo, M. and Theraulaz, G. (1999) Swarm intelligence: From natural to artificial systems.
New York, NY: Oxford University Press.

29