CLup System DD

Design Document
for
CLup Project
Version 1.0
Prepared by Matteo Merz and Pavel Popov
Politecnico di Milano
07.10.2020

Page ii
Table of Contents
1. Introduction .......................................................................................................................................... 1
1.1 Purpose ........................................................................................................................................ 1
1.2 Scope ........................................................................................................................................... 1
1.3 Definitions, Acronyms, Abbreviations........................................................................................ 2
1.4 Revision History.......................................................................................................................... 2
1.5 Reference Documents.................................................................................................................. 2
1.6 Document Structure..................................................................................................................... 2
2. Architectural Design ............................................................................................................................ 4
2.1 Overview ..................................................................................................................................... 4
2.2 Component View......................................................................................................................... 6
2.3 Deployment View........................................................................................................................ 9
2.4 Runtime View............................................................................................................................ 10
2.5 Component Interfaces................................................................................................................ 20
2.6 Selected architectural styles and patterns .................................................................................. 21
3. User Interface Design......................................................................................................................... 22
4. Requirements Traceability ................................................................................................................ 29
5. Implementation, Integration and Test Plan..................................................................................... 32
5.1 Overview ................................................................................................................................... 32
5.2 Implementation plan.................................................................................................................. 32
5.3 Integration strategy.................................................................................................................... 34
5.4 Testing....................................................................................................................................... 34
6. Effort Spent......................................................................................................................................... 37
6.1 Matteo Merz .............................................................................................................................. 37
6.2 Pavel Popov............................................................................................................................... 37

1. Introduction
1.1 Purpose
This document represents the Design Document and show the results of the second effort on the cLup system
project and implementation, after the requirement analysis one.
The very first purpose is to clarify the architecture of the system, and so the main components and interfaces.
Then, the document aims to describe the interaction between those components, through the analysis of some
use cases. To maximize the comprehension of those concepts, some diagrams are provided. They have been
drawn according to the UML standard and each one is accompanied by a proper description. To persuade the
reader that the architecture is able to satisfy the system requirements, a dedicated chapter points out the
linking between components and requirements.
Another relevant argument is the implementation, integration and test plan, which is made to help
programmers in the next step of the system development.
Finally, the document specifies how the user interfaces of the various applications should look like. This has
the dual purpose of showing stakeholders the “external side” of the system and leading developers during the
implementation.
As already stated, the document is addressed to both stakeholders and developers of the system; it will be
proposed to the professor of Software Engineering 2 course for its approval.
1.2 Scope
The cLup system takes place in the context of the world COVID-19 pandemic. Many countries are imposing
lockdowns that allow people to exit their homes only for essentials needs, and are enforcing strict rules even
when people are justified in going out. In particular, grocery shopping can become a challenge in the
presence of such strict rules: supermarket need to restrict access to their stores to avoid crowds inside, which
typically results in long lines forming outside, which are themselves a source of hazards.
The system sims to be a solution to this problem, allowing customers to line up from their home, and then
wait until their number is called (or is close to being called) to approach the store. In addition, the application
should also allow customers to “book” a visit to the supermarket. Obviously, fallback options should be
available for people who do not have access to the required technologies.
The system is addressed to grocery chains, or in general to any grocery association. The reason of that is the
system administrator can manage all groceries.
As has just been said, the solution from which cLup is born is a very simple one, where customers can
immediately enter the stores as long as they are not full, and then they wait in a physical line for customers
exiting. For this reason, the cLup system will be developed from scratch.

1.3 Definitions, Acronyms, Abbreviations
In Table 1 are listed the main terms that are used in the document, with the relative definitions.
Customer A person who wants to visit a grocery.
Visitor A customer who is not registered into the system.
User A customer who is registered into the system.
Administrator A person in charge to administrate the system.
Ticket An item, physical or virtual, that contains the position of a customer in the queue.
Booking A virtual item that contains all details about a scheduled visit of user.
Aisle A grocery area where customers can find a certain category of products.
Table 1: Definitions
In are listed the acronyms that are used in the document, with the relative meaning.
RASD Requirement Analysis and Specification Document
Table 2: Acronyms
1.4 Revision History
Version Date Description
1 10/01/2021 First version
Table 3: Revision History
1.5 Reference Documents
Specification Document: R&DD Assignment A.Y. 2020-2021
Requirement Analysis and Specification Document: RASD cLup Merz-Popov
Slides of the lectures.
1.6 Document Structure
This is a rapid overview on how the document is structured. There is a brief description of the main topics
covered by each chapter.

Chapter 1 – Introduction
This chapter gives and introduction about the purpose of the document and explains the principal terms and
abbreviations, so the reader can better understand the other sections. Moreover, it clarifies the position of the
document in the system development process.
Chapter 2 - Architectural Design
This chapter is about the architecture of the system, with particular attention to components and interfaces.
The discussion is enriched by several UML diagrams, each one accompanied with a proper explanation. An
accent is put on the interaction between components, especially in the runtime view paragraph, and on the
most relevant algorithm to be implemented.
Chapter 3 - User Interface Design
This chapter contains the user interface guidelines for the various system applications. It is divided in a sub-
chapter for each system human actor, and so customers, entrance managers and administrators, and explains
in a detailed way how the interaction with the system should work.
Chapter 4 - Requirement Traceability
This chapter is dedicated to the traceability of the requirements, that means this is the place where it’s
explained the way in which the components satisfies the various requirements.
Chapter 5 - Implementation, Integration and Test Plan
The chapter contains a list and a short description of the system’s subcomponents, primary order of their
implementation and testing methodology proposal.
Chapter 6 - Effort Spent
This chapter is accessory and shows the effort spent by each member of the group.

2. Architectural Design
2.1 Overview
The architecture of the system can be streamlined into three logic layers.
• Presentation layer, that is the user interface. Its main purpose is to display information to and collect
information from the various users. It is implemented through the mobile and web applications the
reader can find on Figure 1.
• Application layer, that is the business logic. This is the heart of the system: here, information
collected in the presentation tier is processed. It can also add, delete or modify data in the data tier.
• Data layer, where the information processed is stored and managed.
The reasons behind this choice are explained on paragraph 2.6.
The architecture has to be made in a client-server style, where the components are not allocated in the same
physical machine and the communication takes place mainly through Internet.
2.1.1 High-level components
Customers can interact with the system in different ways, depending on the functionality they want to use.
• The virtual line-up and the book-a-visit functionalities should be activated trough a mobile
application to be installed on a smartphone. In this way, customers can use the system from
whenever they want, without physically approaching a grocery.
• The physical line-up functionality should be activated in front of the groceries through a dedicated
application running on a PC and which is connected to a printer. Customers can use it through a
touchscreen device. This is the fallback option to guarantee the line-up functionality for those
customers who have not a smartphone.
These devices communicate with the application server through the Internet.
In a very similar way, entry managers can use their dedicated functionalities through a mobile application to
be installed on a smartphone (equipped with a camera, it can scan bookings QR codes), which communicates
with the application server through the Internet. The same means of communications is used by the people
counter.
In order to monitor the network traffic and to guarantee its security, all these devices can’t interact with the
application server directly, but with the supervision of a firewall.
On the other hand, administrators are asked to use a PC and the interface is a web application. To manage the
http traffic, and so the dispatching of web pages, the application server communicates with the web
application trough a web server, protected by a firewall.

The information produced during the system execution is stored in a database, which is managed by a
database server. The communication with the application server takes place in a LAN.
Finally, the application server is responsible for the interaction with the Mail Server, that’s supposed to be
external. Thanks to that, the system can send emails to users, and in particular the one-time code necessary
during the authentication.
The high-level system components and their interaction are showed in Figure 1.
Figure 1: High-level system components
In this initial scheme, so many details of the architectural choice have been omitted: they are better explained
in next paragraphs.

2.2 Component View
In this section, the main components of the system are listed. For a better comprehension, in Error!
Reference source not found. the reader can see the component diagram, drawn according to the UML 2.5
specification. The diagram gives a specific view of the system focusing on the representation of the internal
structure of the application server and on the interaction between components.
Figure 2: Component Diagram

UserApp
The UserApp is the component from which users can interact with the system. As seen in paragraph 2.1.1, it
should be installed on a smartphone (the supported OSs are analyzed in paragraph 0) and is connected to the
application server through Internet. It requires three interfaces, LineUpUserInt, UserAccessInt and
BookAVisitInt, that allow the activation of the virtual customer-related functionalities of the system.
The UserApp is not only a presentation software: it has a logic part and, moreover, a data part (they will be
better explained in paragraph 2.6).
UserAccessManager
The UserAccessManager is the component that controls the user authentication and login. It requires an
interface with the DatabaseManager, DatabaseManagerInt, to manage users, and an interface with the
MailManager, MailMangerInt, to send the one-time code.
From the RASD, the reader should remember that a user profile is tied just to the user email address, and
there is no need of a password (the access security is left to the one-time code).
MailManager
This component should manage the interaction with the MailServer. It is important because the MailServer is
an external component and can change over time, but the interface with the rest of the system should not be
modified.
EntryManagerApp
The EntryManagerApp is the component from which entry managers can interact with the system. As seen in
paragraph 2.1.1, it should be installed on a smartphone (the supported OSs are analyzed in paragraph 0) and
is connected to the application server through Internet. It requires three interfaces, EMAccessInt,
CheckTicketInt and CheckBookingInt, that allow entry managers to manage the influx of customers
groceries; and should provide the EMAppInt, from which it can update the counter of the customers inside
the groceries.
Likewise the UserApp, it’s evident that also the EntryManagerApp has a logic part (it will be better
explained in paragraph 2.6).
EntryManagerAccessManager
The EntryManagerAccessManager is the component that controls the entry manager authentication and
login. It requires an interface with the DatabaseManager, DatabaseManagerInt, to manage entry managers.
From the RASD, the reader should remember that the credentials, and so username and password, are
provided and managed by administrators.
LineManager
The LineManager, together with the BookingManager, is one of the main components of the application
server: it manages the line-up functionality, both from the user and the entry manager perspective. It is
divided in two sup-components, that reflect this division.

• The LineUpUtils is the component that controls the functionality from the customer perspective. It
provides two interfaces, one for the UserApp and one for the PrinterApp, and can create, update and
delete physical and virtual tickets, with the consequent updating of the lines.
• The CheckTicketUtils is the component that controls the functionality from the other perspective,
that is the entry manager one. It tells if a ticket, physical or virtual, is valid or not.
Both the sub-components require an interface with the DatabaseManager, the DatabaseManagerInt.
PrinterApp
The PrinterApp is the component from which customers can activate the physical line-up functionality of the
system. As seen in paragraph 2.1.1, it should be installed on a PC and is connected to the application server
through Internet.
It requires the LineUpPrinterInt interface from the LineManager component, with which it can update the
line, and the PrinterInt interface from the Printer component, with which it can control the device for printing
physical tickets.
MonitorManager
The MonitorManager is the component that manages the monitor from which customers in the line can see
the currently called ticket. It should provide the MonitorManagerInt interface to the LineManager, from
which it can get the updated line state every time a ticket is successfully checked.
BookingManager
The BookingManager, together with the LineManager, is one of the main components of the application
server: it manages the book-a-visit functionality, both from the user and the entry manager perspective. As
the LineManager, it is divided in two sub-components, that reflect this division.
• The BookAVisitUtils is the component that controls the functionality from the customer perspective.
It can create, update and delete bookings.
• The CheckBookingUtils is the component that controls the functionality from the other perspective,
that is the entry manager one. It tells if a booking is valid or not.
Both the sub-components require an interface with the DatabaseManager, the DatabaseManagerInt.
AdministratorApp
The AdministratorApp is the component from which administrator can use the administrator-related
functionalities of the system. As seen in paragraph 2.1.1, it is a web application and should be executed on a
generic PC browser. It is as such connected to web server trough Internet.
It obviously requires an interface with the WebServer, that is the WebServerInt.

WebServer
The WebServer is the component that satisfies the HTTP requests of the AdministratorApp: it can store,
process and deliver web pages. To fully fulfill this task it requires two interfaces, the AdminAccessInt from
the AdministratorAccessManager and the AdminWebInt from the AdministratorManager.
AdminAccessManager
The AdminAccessManager is the component that manages the administrator authentication and login. It
requires an interface with the DatabaseManager, DatabaseManagerInt, to manage administrators.
From the RASD, the reader should remember that the credentials required to login are a username and a
password.
AdministratorManager
The AdministratorManager is the component that manages the operations made by administrator and provide
information useful to them. For this reason, it requires an interface with the DatabaseManager,
DatabaseManagerInt, and provides an interface with the CustomerManager, the AdminCustInt, in addition to
the one already described with the WebServer.
It can create, update and delete groceries and manage entry managers. Moreover, it lets administrator knows
the current number of customers inside the groceries.
CustomerManager
The CustomerManager is the component that monitors the number of customers into the groceries. By the
interface provided by the PeopleCounter, that is PeopleCounterInt, it gains the information about people
entering and exiting the groceries. Then, it provides two interfaces to update the local counters, one for the
EntryManagerApp and another for the AdministratorManager.
DatabaseManager
The DatabaseManager is the component that manages the accesses to the database. It provides a big
interface, the DatabaseManagerInt, that’s used by most of the components of the system. It can create, update
and delete objects; all these operations are then written in the database through the interface DatabaseInt.
Moreover, this interface allows it to get any needed data.
2.3 Deployment View
After having listed the components of the system, the discussion moves to the description of the physical
devices where the various components are installed. To help the reader in the comprehension of that, in
Figure 3 there is the deployment diagram, drawn according to the UML 2.5 specification.
The client applications UserApp and EntryManagerApp, as previously said, can be installed on a
smartphone. On the other hand, the AdministratorApp can be installed on a PC and used through a web
browser. Each registered grocery should have a PC connected to the people counter, the monitor, the printer
and the touch screen. From it, all these devices are controlled: for this reason, the relative component should
be installed on it.

Moving to the application layer, the reader can see that the interaction between client and server is
supervised by two firewalls, one to protect the application server and the other to protect the web server.
After the first firewall, a load balancer has been inserted because the application server should be replicated
for performance and reliability reasons.
Finally, the data layer is managed by a database server.
Figure 3: Deployment Diagram
2.4 Runtime View
So far, the discussion has been concerned about the static behavior of the system; in this chapter it moves to
the description of the dynamic behavior. Here the point is to analyze the interaction between components
during the execution of the most representative tasks. To facilitate the reader comprehension, some sequence
diagrams are provided, drawn according to the UML 2.5 specification.
Beware that this is still a high-level description of the actual interactions that are going to take place, so
functions may be added and names modified during the implementation process.

2.4.1 Visitor Registration / User Login
In Figure 4, the visitor registration and user login processes are described in a sequence diagram.
Figure 4: Visitor Registration / User Login Sequence Diagram

As soon as it is started, the UserApp checks if the user ID has been previously stored in the local memory. If
so, the user can access without any other interactions. In the other case, the application returns the login
screen, where the user can insert an email address. After having received the address, the
UserAccessManager generates a one-time code and sends it to the user using the interface with the
MailManager. Once the email is dispatched, the user can insert the code into the application, which, in turn,
sends it to the UserAccessManager. If it is correct, this component queries the database for a user with this
email address; if the user exists the DatabaseManager returns it, else a new user is generated and then saved
on the database.
2.4.2 Virtual Line Up
In Figure 5, the virtual line up process is described in a sequence diagram.
When the user presses the LineUp button on the UserApp, the first thing to do is to check if he currently is in
other lines (this operation is made at the LineManager level). If so, an error dialog is shown and the user is
invited to delete the previous ticket. In the other case, the user is asked choose between a list of groceries: for
each one considered, the LineManager should provide the current line detail, so that the user can decide
according to the estimated waiting time. Once the grocery has been chosen, he has to specify the time he
needs to reach the grocery (the LineManager will notify the UserApp when the estimated waiting time is
equal to this time). Now, if the line is not empty, the ticket can be generated and stored in the database, the
line updated and the UserApp equipped with the new ticket, ready to be shown to the entrance manager.

Figure 5: Virtual Line Up Sequence Diagram

2.4.3 Physical Line Up
In Figure 6, the physical line up process is described in a sequence diagram.
Figure 6: Physical Line Up Sequence Diagram
The customer is in front of a grocery and wants to line up to enter the store, so he starts interacting with the
printer app. As soon as he presses the LineUp button, the application asks to the LineManager details about
the current line. If it is empty, a dialog appears on the screen saying that the user can enter the grocery
immediately; in the other case the physical line-up process starts: the LineManager generates a new ticket,
saves it into the database and updates the current line. At this point, the PrinterApp asks the Printer to print
the ticket, so that the customer can show it to the entry manager when his turn to enter comes.

2.4.4 Check a Ticket
In Figure 7, the check a ticket process is described in a sequence diagram.
Figure 7: Check a Ticket Sequence Diagram
First of all, the customer shows to the entry manager his ticket, physical or virtual (in the second case it’s
enough if he shows the home page of the UserApp). The entry manager checks the ticket number with the
one currently called. If the number is different, the user cannot enter: if it’s smaller he has lost his turn and
has to line up another time, if it’s bigger he has to wait until the number is called. In the other case, the entry
manager presses the Confirm button on the EntryManagerApp and the LineManager updates the ticket and
the line state. At this point the user can enter the grocery.

Add a Grocery
In Figure 8, the add a grocery process is described in a sequence diagram.
Figure 8: Add a Grocery Sequence Diagram
As a prerequisite, the administrator should be successfully passed through the authentication process and
should be in the AdministratorApp Home Page. Here he can press the AddGrocery button, that makes the
WebServer load the AddGrocery page, which is a form where he can specify all the details about the grocery
he wants to add. Once the administrator has finished editing the grocery details, by pressing the Confirm
button, the information inserted are sent to the WebServer and then to the AdministratorManager: here they
are processed to create a new grocery instance, that is later saved through the DatabaseManager.
Now the administrator can see the new grocery in the Home Page of the AdministratorApp.

2.4.5 Customer Entrance
In Figure 9, the customer entrance process is described in a sequence diagram.
Figure 9: Customer Entrance Sequence Diagram
When a customer enters a grocery, the PeopleCounter dispatches the event to the CustomerManager. Here
the counter of the people inside the grocery is increased. The described process is pretty identical to the
customer exit one (in that case the counter is decreased).
The second part of the diagram shows how the EntryManagerApp updates the local counter: every few
seconds it asked to the CustomerManager the new count.
2.4.6 Book a Visit
In Figure 10, the book a visit process is described in a sequence diagram.
When the user presses the BookAVisit button on the UserApp, the first thing to do is to check if he currently
has more than two other bookings open (this operation is made at the BookingManager level). If so, an error
dialog is shown and the user is invited to delete one of them before taking a new one. In the other case, the
user is asked to choose between a list of groceries: for each one considered, the BookingManager should
provide the grocery aisles. Once the grocery has been chosen, the user specifies when he want to enter the
store, how long he is approximately going to stay in and which aisles he plans to visit. Now, if the chosen
time slot has not been booked by too many other customers (in paragraph Error! Reference source not
found. the relative algorithm is better explained), the booking can be generated and stored in the database,
and the UserApp equipped with the new booking together with the QR code, ready to be shown to the
entrance manager.

Figure 10: Book a Visit Sequence Diagram

2.4.7 Check a Booking
In Figure 11, the check a booking process is described in a sequence diagram.
When a customer with a booking approaches the grocery to enter, the first thing to do is to open, in the
UserApp, the QR code that represents the booking. Then the customer has to show it to the entry manager, so
that he can read it using the EntryManagerApp. Now the checking operation can start: the BookingManager
controls that the booking is valid and eventually save it into the database, through the DatabaseManager. In
this case the customer can enter the grocery. In the other case, if the booking is refused, the customer cannot
enter: if he is too late he has to line up, if he is too early he has to wait until the scheduled time comes.
Figure 11: Check a Booking Sequence Diagram

2.5 Component Interfaces
The diagram in Figure 12 lists the main methods of the system components declared in the interfaces. The
arrows that link the various components represent the interactions; the direction of each arrow indicates
which component uses the other.
In general, methods written in the Component Interfaces diagram are not to be intended exactly as the
methods that the developers will implement: they are logical representation of what component interfaces
should offer, then they will be adapted in a way that depends on the implementation choices.
Figure 12: Component Interfaces Diagram

2.6 Selected architectural styles and patterns
As partially described in paragraph 2.1, a three-layer architecture has been chosen for the system
implementation. Behind this choice there are lots of reasons, mainly dealing with the satisfaction of the non-
functional requirements of the system: it provides relevant benefits in the system reliability (an outage in one
layer is less likely to impact the availability or performance of the other tiers) and security (because the
presentation layer and the data layer can’t communicate directly, the application tier can function as a sort of
internal firewall, preventing SQL injections and other malicious exploits). In general, this architecture has a
positive impact also on:
• the development, that can be speeded up by the simultaneous effort on the different layers (the
implementation plan will be better addressed in Chapter 5);
• the scalability, in the sense that any layer can be scaled independently of the others as needed.
Anyway, the layers are not fully separated, at least in the physical infrastructure. The most relevant example
is the UserApp component: it should be entirely enclosed in the presentation layer, because it is the end point
with which customers can interact with the system, but it has a logic part and even a data storage
functionality (it can store the user ID to speed up the authentication). By the way, these exceptions are not so
relevant, so the discussion about the benefits is still valid.
In paragraph 2.1, the system is said to be built in accordance with the client-server model; by the way, the
behaviors described in the following paragraphs point out some differences with it. This regards in particular
the role of the clients: for example, the entry manager app is triggered every few seconds to update the local
customer counter, which is a server-specific behavior. By the way, it’s important to say that those examples
are exceptions, and that the client-server is the model that has conditioned the most all the design choices.
The discussion can now be moved to the communication protocols. The interaction between clients and the
server has to be done through HTTP, because of the nature of the exchanged messages and of the network,
that is Internet. To satisfy the security requirements of the system, the messages should be encrypted and so
the HTTP should be over TLS or SSL. This choice also improves the reliability of the connection.
Finally, the software architecture to be used for the web services should follow the REST style. The reason
of this choice is that, as well as simplifying and uniformizing the interfaces, it provides great benefits on
scalability and portability.

3. User Interface Design
Here the UI guidelines for the client applications are described (the discussion is divided in paragraphs, one
for each actor considered). The aim is not to cover every details of the applications.
3.1.1 Customer
The customer mobile application must be available for both iOS and Android OS.
The following images shows how to render the login UI. The first screen (Figure 13) has a form that asks
User to insert a valid email address; the other (Figure 14), that appears on the Confirm button tap, asks the
User to insert the one-time code received by email.
Figure 13: User Login UI (pt. 1) Figure 14: User Login UI (pt. 2)

After the user is successfully authenticated, the application pushes the Home Page. In Figure 15 it is shown
in the case there are not tickets and bookings active. On the far right there is a button with the plus symbol: if
the user taps on it, the dialog in Figure 16 appears. This is the starting point to activate the line-up or the
book-a-visit functionalities.
Figure 15: UserApp Home Page Figure 16: UserApp functionalities
If the user presses the Line Up button, he is prompted to the screen in Figure 17; if he presses the Book a
Visit button, the screen in Figure 19 is loaded.

In Figure 17 the user is asked to select the grocery he wants to visit, from a list containing all the available
ones. Every time he selects one, the grocery item is expanded to show some information in real time about
the line. Once the desired grocery is found, the user has to insert how much time he needs to reach it: only
after this operation he can press the Confirm button.
Now the user is in the grocery line and the Home Page of the application shows the ticket with the
correspondent line position (Figure 18). Here the user can also monitor in real time the line updates, both in
terms of number people waiting before him and in terms of the estimated remaining waiting time.
Figure 17: Select a grocery UI (Line Up) Figure 18: Virtual Ticket UI

In Figure 19 the user is asked to select the grocery he wants to visit, from a list containing all the available
ones. Every time he selects one, the grocery item is expanded to show a form the user has to fill to
successfully book a visit. In particular, he has to specify the time when he wants to enter the grocery, how
much time he wants to stay in and the aisles he wants to visit. Once the desired grocery is found and the form
filled, he can press the Confirm button.
Now the booking is registered into the system and the Home Page of the application show the booking with
the correspondent selected time (Figure 20). If the user taps on the center of the booking item, a dialog with a
QR code will be opened: this is a required functionality to facilitate the checking operation.
Figure 19: Select a Grocery UI (Book a Visit) Figure 20: Booking UI

3.1.2 Entry Manager
The entry manager mobile application must be available for both iOS and Android OS.
In Figure 21 there are the guidelines about how to render the login operation. Once the entry manager has
been authenticated, the Home Page of the application is pushed. In Figure 22 there is represented the case in
which the grocery has reached the maximum number of allowed customers: there are 15 people in the line
and one person can enter for each one that exits the store. Now, a customer is just gone out and the one with
the ticket number 13 can enter (if the ticket checking is successful, the entry manager taps on the green
button on the ticket right side, if the customer doesn’t come, he taps on the red button on the other ticket
side).
In the case there is a user with a booking for that time, the entry manager taps on the bottom side of the
screen, so that the smartphone camera is opened and he can check the user booking QR code.
Figure 21: Entry Manager Login UI Figure 22: EntryManagerApp Home Page

3.1.3 Administrator
The administrator application should be a web application.
In Figure 23 there are some guidelines about how to render the application Home Page, that’s pushed as soon
as the administrator successfully passes through the authentication. On the left side there is a bar where all
the groceries registered to the system are listed. When the administrator clicks on one item, the detail is
shown on the rest of the page. From here he can manage the entrance managers linked with that grocery, and
so add, delete and update them. The information he can specify is showed in Figure 24 (all the fields are
mandatory).
At the top of the grocery list, there is a plus button from which the administrator can add a grocery. When the
button is pressed, the page in Figure 25 is shown; to successfully add a grocery, he has to fill all the
mandatory fields of the form and the press the Confirm button.
The last element to be described can be found in all templates, on the lower left corner. It shows the
username of the currently logged administrator and gives him the possibility to log out.
Figure 23: Grocery Detail UI

Figure 24: Entry Manager addition UI
Figure 25: Grocery Addition UI

4. Requirements Traceability
As already said, the design choices made in the previous chapters aim to fulfill in a complete and correct way
the requirements of the cLup system. To prove that, the Table 4 provides a mapping between requirements
defined in the RASD and system components illustrated in this document.
# Requirement Component
R1
The system should provide an interface from which a user can use the
virtual customer-related functionalities of the system.
UserApp
R2
The system should allow any customer who can access the required
technologies to sign up.
UserApp
R3
The system should dispatch a virtual ticket when a user uses the virtual-
line-up functionality without currently being in another virtual queue.
UserApp
LineManager
DatabaseManager
R4
The system should disable the virtual-line-up functionality for a grocery if
the current time is outside the store opening hours.
LineManager
R5 The system should allow user to cancel a virtual ticket.
UserApp
LineManager
DatabaseManager
R6
The system should ask the user who wants to virtually line up how much
time it will take to reach the grocery from the place he/she currently is.
UserApp
R7
The system should notify users who have a virtual ticket when the
estimated time before the ticket will be called is equal to the time needed
to reach the grocery.
UserApp
LineManager
R8
The system should allow users who wants to line up to check the line state
before.
UserApp
LineManager
DatabaseManager
R9
The system should allow users who have a virtual ticket to check in real
time how many people are waiting before them and an estimation of the
remaining waiting time.
UserApp
LineManager
R10
The system should provide an interface from which a customer can user
the physical customer-related functionalities of the system.
PrinterApp
R11
The system should dispatch a physical ticket when a customer uses the
physical-line-up functionality.
PrinterApp
LineManager
DatabaseManager
R12 The system should allow entry managers to check if a customer with a EntryManagerApp

ticket (physical or virtual) can enter the grocery or not. LineManager
R13 The system should skip a called ticket if the customer doesn’t come.
EntryManagerApp
LineManager
R14 The system should refuse tickets already and to-be called.
EntryManagerApp
LineManager
R15
The system should provide an interface from which administrators can use
the administrator-related functionalities of the system.
AdministratorApp
R16 The system should allow administrators to login.
AdministratorApp
WebServer
AdminAccesManager
DatabaseManager
R17 The system should allow administrators to add a new grocery.
AdministratorApp
WebServer
R18
The system should allow administrators to specify and modify the opening
hours of a grocery.
AdministratorApp
WebServer
R19
The system should allow administrators to specify the aisles of a certain
grocery.
AdministratorApp
WebServer
R20
The system should allow administrators to specify, for each aisle of a
grocery, the maximum number of customers allowed at the same time.
AdministratorApp
WebServer
R21
The system should allow users who want to use the book-a-visit
functionality to schedule their visits (the system should avoid schedules
outside the opening hours and less than half an hour from the current
time).
UserApp
BookingManager
DatabaseManager
R22
The system should ask to users who want to use the book-a-visit
functionality to specify how much time they are going to stay in the
grocery (the maximum possible lapse of time should be one hour).
UserApp
R23
The system should allow users who want to use the book-a-visit
functionality to specify the aisles they intend to visit, choosing among the
ones specified by the administrators.
UserApp
BookingManager
DatabaseManager
R24
The system should dispatch a booking when a user correctly activates the
book-a-visit functionality. The system should not dispatch the booking in
those cases: the selected schedule is already booked by the 10% of the
maximum number of customers allowed; the user has already booked a
visit for the same time; the user has already booked two visits, for any
UserApp
BookingManager
DatabaseManager

time.
R25 The system should allow users to cancel a booking.
UserApp
BookingManager
DatabaseManager
R26
The system should allow entry managers to check if a user with a booking
can enter the grocery or not.
EntryManagerApp
BookingManager
R27
The system should refuse bookings more than 5 minutes late or early than
the specified time.
EntryManagerApp
BookingManager
R28
The system should notify users who has a booking when there is half an
hour to the scheduled time.
UserApp
BookingManager
R29
The system should allow entry manager to know in real time the
maximum number of customers that can be inside the store.
EntryManagerApp
CustomerManager
R30
The system should allow entry managers to know in real time the number
of customers inside the groceries.
EntryManagerApp
CustomerManager
R31
The system should communicate with the people counters to register
whether a customer enters or exits the groceries.
CustomerManager
R32
The system should allow customers to enter the grocery without lining up
if the maximum number of customers in the store has not been already
reached.
LineManager
UserApp
PrinterApp
CustomerManager
R33
The system should allow customers waiting in a line to know when their
turn to enter the grocery comes.
LineManager
MonitorManager
Table 4: Requirements Traceability
The most observant readers can argue that two components have not been mentioned: the MailManager and
the EntryManagerAccessManager. Nevertheless, they are still required:
• the MailManager component tries to satisfy the non-functional requirement that say that the
application should be easy to use (with it the user can be authenticated without a password);
• the EntryManagerAccessManager component is needed for a security reason (without it anyone with
a smartphone could use the entry manager-related functionalities of the system).

5. Implementation, Integration and Test Plan
5.1 Overview
After planning, requirement and analysis part the next step is to provide a step-by-step definition of how the
software can be built, validated and verified. This chapter provides possible implementation details and
shows testing methodologies applicable to a project.
5.2 Implementation plan
As was mentioned before, the final system is a mobile application available for both iOS and Android OS
used by different groups of users including customers and entry managers. For this sake, one of the possible
solutions of software development compatible for both platforms could be a Flutter framework. The
framework allows to implement front-end part of the application and client side of the three tier architecture
supposed in the document. Here are following macro-components to be implemented for succesful
operations of a software:
1. Client part
1.1.Mobile application iOS
1.2.Mobile application Android
1.3.Web service design for administrator
2. Application server part for mobile applications processing.
3. Web server for communicating with administrator of the system.
4. Database server, ORM model on application server for controlling a database itself.
5. Physical devices connection (Ticket printer, counter)
Overall representation can be seen on a Figure 1 of a document. For the implementation technique the team
of 2 people can use sprints of 1 week. At the end of each sprint some defined deliverables are presented in
the repository. The concept is taken from Agile methodologies.
Following figure represents an order in which all components of the system are supposed to be implemented
on a development phase. On the left, the set of activities are represented, the timeline of sprints of about 5
days is used as an assumption. It is supposed to start a development from a most crucial part of the
application – users and customers mobile applications. We suppose to use Flutter framework for designing
applications itself. The framework allows to create a portable product for both iOS and Android operation
systems. Following the UX/UI part which will define the way the user interacts with the system; it is
supposed to develop the main functionalities as separated components. The development of the logic as
separate components will allow to have unit tests for each block and integration testing for testing the system
as a whole.

5.3 Integration strategy
For the integration part, bottom-up approach can be chosen as a best suited for this type of software.
5.4 Testing
After the system is completely developed and integrated, it must be covered by various types of tests to
ensure functionality and completeness. For the system that is described in the document, we can use several
options of testing conducted in the needed order or combined. Based on the fact that the system itself consists
the number of components developed step by step, we can propose following tests to be covered to ensure y
that functional and non-functional requirements are satisfied.
• Unit tests – they will be conducted for each component separately to ensure a stable functionality of
them.
• Integration tests – this type of tests will check the functionality of the system as a whole. It will also
cover an intercommunication between different components.
• Functional testing - verifies if the application satisfies the functional requirements described in the
RASD.
• Performance testing - identifies bottlenecks affecting response time, utilization, throughput and
establishes a performance baseline and possibly compares it with different versions of the same
product.
• Load testing - is able to highlight different problems with security such as memory leaks,
mismanagement of memory, buffer overflows and identifies limits of components.
Unit tests are crucial for verification of functionality of components. However, it is not enough to make sure
the system is operable as a complete one. For this sake, integration tests can be provided on completely
assembled application. In a following table you will find several test cases, useful for checking crucial
functionality of the system.
For some testing cases one or several testing user accounts can be created. Some of test cases require checks
of concurrency and the

Test
Case ID
Test Case Objective Test Case Description Expected Result
1
To check User Registration
functionality
Clicking on Registration
button in user’s mobile
application. Following
instructions displayed by
the application, proceed
with the registration.
The message showing
the successful
registration is shown.
The functionality of the
registered user is
available.
2
To check Physical Line Up
functionality.
Select a random grocery
from a given list using
one testing account.
Obtain a virtual number
n. Select the same
grocery using second
testing account. Obtain a
virtual number. It is
supposed that only two
testing accounts are
operable for a chosen
grocery.
The Virtual number of
the second account is
equal to n+1 while first
account has number n.
3 To check Virtual Line Up functionality
The case is conducted
similarly to the Case 2,
but
Current line details
provided after choosing a
grocery. Estimated
waiting time.
4 To check Virtual Line Up concurrency
Get a ticket for a grocery
for a certain time. Get
another ticket.
Error message is shown.
User is invited to delete
the previous ticket.
5 To check Book a Visit functionality
The case is quite like
Case 3 but selection of
aisles and desired time
slot.
The QR code for the
entrance is generated and
can be read by the
Entrance Manager part.
6
To check Book a Visit concurrency
The case is quite like
Case 4 but there are 3
bookings supposed to be
generated for a same
account.
The error message is
shown, and the user is
invited to leave at least 2
bookings for his account.

7
To check Add a Grocery functionality
Access Administrator’s
account, press “Add
grocery” button, specify
details, press “Confirm”
button.
The new grocery is seen
on the Home page of the
administrator
application.
Table 5: Integrations test case examples
Together with the unit-testing and the integration testing, also an automated static analysis should be
conducted. The metrics for the testing of the applications can be defined by programmers but, in any case,
full coverage (or at least 85%) of unit testing conduct by developers itself helps to find problems early.

6. Effort Spent
In this chapter there is the effort for the drafting of the document.
6.1 Matteo Merz
Hours Date Argument
1 24/12/2020 System Architecture
2 28/12/2020 System Architecture, Component Diagram
3 29/12/2020
System Architecture, Component Diagram, Deployment Diagram, Sequence
Diagram
1 30/12/2020 Sequence Diagram
4 04/01/2021 Sequence Diagram, Component Diagram
4 05/01/2021 Sequence Diagram, Component Diagram, User Interface
3 06/01/2021 Sequence Diagram, Component Diagram, User Interface
4 07/01/2021 Component Interfaces Diagram, DD Introduction
6 08/01/2021 DD Architectural Design: Overview, Component View, Runtime View
4 09/01/2021 DD User Interface Design; DD Requirements Traceability
5 10/01/2021
DD Architectural Design: Runtime View; Deployment View, Selected
architectural styles and patterns, Other design decisions
Table 6: Matteo Merz effort
6.2 Pavel Popov
Hours Date Argument
1 27/12/20 System Architecture
2 31/12/20 User Interface
1 03/01/21 Implementation Plan

5 07/01/21 Implementation Plan
1 08/01/21 Integration Plan
5 09/01/21 Test Planning
3 10/01/21 Fixing Document Issues
Table 7: Pavel Popov effort

CLup System DD

Recommended

Recommended

More Related Content

Similar to CLup System DD

Similar to CLup System DD (20)

Recently uploaded

Recently uploaded (20)

CLup System DD