\documentclass{article}
\usepackage[utf8]{inputenc}
\usepackage{graphicx}
\usepackage{float}


\title{Problem Analysis and Software Design}
\author{Cristian Rosiu - Paul Veldhuyzen - Gerrit Sijberen Luimstra}
\date{November 2019}


%%%%%
%%%%% To find a list of the current todo list
%%%%% https://trello.com/b/1sxVgzW2/problem-analysis-and-software-design
%%%%%

\begin{document}

\maketitle

\tableofcontents
\newpage

\section{Introduction}
This document aims to provide a thorough problem analysis and software design of the Ferry service in question. Shipping company KOENDES maintains a ferry service between Harlingen and the Frisian Islands Vlieland and Terschelling. This project is initiated due to the demand for a completely new system in which paying, reservation and booking a passage all need to be included.

\newpage

\section{Actors and other stakeholders}
\textit{The aim of this chapter is to list the relevant actors and stakeholders associated with the system to be built. Actors are external entities that interact with a system in some way, in other words, an entity with some behavior that acts on the system. Stakeholders are entities that care of the project in some way.}\\

The following parties will be able to interact with the system and can be considered \textbf{actors}:
\begin{itemize}
    \item Rob Frisia (Manager)
    \item Regular customers
    \item Customers with vehicle (truck drivers / residents)
    \item Secretary / Cashier (at the office)
    \item System administrator
    \item Ticket collector
    \item Customer support\\
\end{itemize}

Other relevant \textbf{stakeholders} not immediately interacting with the system:
\begin{itemize}
    \item Government handing out the permits (car permits)
    \item The banks of both the company and its customers
    \item Traffic crew responsible for directing the vehicles to the boats
    \item Boat crew
    \item Boat captain
    \item Island residents
    \item Financial advisors
    \item Travel sites
    \item Insurance companies
    \item Police
\end{itemize}

Note that this is not an exhaustive list and many more users may be added later. Different types of users interact with the system in different ways and might therefore have different rights with respect to the system.

\section{User wishes}
\textit{The aim of this chapter is to provide the user wishes for the roles that partake in the system to be built. The purpose of a user wish is to articulate a certain need for a functionality; a minimal functional requirement.}\\

Note that we have subdivided the user wishes into broad categories. This, however, does not mean that they are distinct parts of the system as usually they are not independent.\\

\textbf{User accounts}
\begin{itemize}
    \item Create user account
    \item Update a user account
    \item Remove a user account (GDPR)
    \item Read customer information
\end{itemize}

\textbf{Booking}
\begin{itemize}
    \item Make a booking (includes payment)
    \item Update a booking
    \item Request booking information (associated with the code, if done online)
    \item Retrieve specific booking by the ‘code’
    \item Retrieve e-ticket for a booking
\end{itemize}

\textbf{Reservation}
\begin{itemize}
    \item Register a reservation
    \item Pay for a reservation online
    \item Request a reservation bill
    \item Pay a reservation bill
    \item Update a reservation
    \item Cancel an overdue reservation
    \item Notify customer of overdue payment and thus cancelled reservation
    \item Cancel a reservation
    \item Retrieve a specific reservation (associated with the code, if done online)
    \item Retrieve e-ticket for a reservation
    \item Retrieve specific reservation by the ‘code’
\end{itemize}

\textbf{General}
\begin{itemize}
    \item Produce a timetable for each respective boat [or individually]
    \item Produce a list of all current reservations
    \item Retrieve all unpaid reservations
    \item Retrieve all overdue and thus unpaid reservations
    \item Produce a list of all current bookings
    \item Retrieve the amount of remaining seats for a ship
    %Were these bold for a reason?
    \item Retrieve boat information
    \item Produce a list of valid permits
    \item Retrieve future departments

    \item Update cancellation possibility
\end{itemize}

\textbf{Statistics}
\begin{itemize}
    \item Produce statistics on:
    \begin{itemize}
        \item average capacity per ship per [month/year/quarter]
        \item monthly income
        \item average car length
        \item average trailer length
        \item cancellation of tickets (to investigate what the main cause is)
    \end{itemize}
\end{itemize}

\newpage

\section{User stories}
\textit{The aim of this chapter is to provide the user stories for the roles that partake in the system
to be built. The purpose of a user story is articulate how a piece of work will deliver a
particular value back to the customer.}\\

\textbf{User account}
\begin{itemize}
    \item As a \textbf{(Regular/Vehicle) customer}
    \begin{itemize}
        \item I want to \textbf{create a user account} to access my bookings/reservations easily
        \item I want to \textbf{update my user account}
        \item I want to \textbf{remove my user account} (right to be forgotten, GDPR)
        \item I want to \textbf{read my account information}
        \item I want to \textbf{pay a reservation bill}
    \end{itemize}
\end{itemize}

\textbf{Booking}
\begin{itemize}
    \item As a \textbf{Regular customer}
    \begin{itemize}
        \item I want to \textbf{make a booking} (includes payment)
        \item I want to \textbf{update a booking}
        \item I want to \textbf{request specific booking information}
        \item I want to \textbf{retrieve specific booking by the ‘code’}
        \item I want to \textbf{retrieve an e-ticket for a booking}
    \end{itemize}

    \item As a \textbf{Secretary}
    \begin{itemize}
        \item I want to \textbf{make a booking for a customer} (includes payment)
        \item I want to \textbf{update a booking}
        \item I want to \textbf{request specific booking information}
        \item I want to \textbf{retrieve an e-ticket for a booking}
    \end{itemize}

    \item As a \textbf{Customer Support}
    \begin{itemize}
        \item I want to \textbf{request specific booking information}
    \end{itemize}

    \item As a \textbf{Ticket inspector}
    \begin{itemize}
        \item I want to \textbf{request specific booking information by the 'code'}
        % Should this be a feature?
        \item I want to \textbf{retrieve an e-ticket for a booking}
    \end{itemize}
\end{itemize}

\textbf {Reservation}
\begin{itemize}
    \item As a \textbf{Customer with a vehicle}
    \begin{itemize}
        \item I want to \textbf{register a reservation}
        \item I want to \textbf{pay for a reservation online}
        \item I want to \textbf{request a reservation bill}
        \item I want to \textbf{update a reservation}
        \item I want to \textbf{cancel a reservation}
        \item I want to \textbf{retrieve a specific reservation by its ‘code’}
        \item I want to \textbf{retrieve an e-ticket for a reservation}
    \end{itemize}

    \item As a \textbf{Customer Support}
    \begin{itemize}
        \item I want to \textbf{request specific reservation information}
        \item I want to \textbf{update specific reservation information}
    \end{itemize}

    \item As a \textbf{System administrator} % this is more of a system thing..
    \begin{itemize}
        \item I want to \textbf{manually cancel and overdue reservation}
        \item I want to \textbf{manually notify a customer of overdue payment} (cancelled reservation)
        \item I want to \textbf{manually notify all customers of the boarding time in advance}
        \item I want to \textbf{manually notify all customers of the arrival time in advance}
        \item I want to \textbf{manually notify all customers of cancellation (in the case of an issue)}
    \end{itemize}

    \item As a \textbf{Ticket inspector}
    \begin{itemize}
        \item I want to \textbf{request specific reservation information by the 'code'}
        % Should this be a feature?
        \item I want to \textbf{retrieve an e-ticket for a booking}
    \end{itemize}
\end{itemize}

\textbf{General}
\begin{itemize}
    \item As a \textbf{System administrator}
    \begin{itemize}
        \item I want to \textbf{produce a timetable for each respective boat} [or individually]
        \item I want to \textbf{produce a list of all current reservations}
        \item I want to \textbf{retrieve all unpaid reservations}
        \item I want to \textbf{retrieve all overdue and thus unpaid reservations}
        \item I want to \textbf{produce a list of all current bookings}
    \end{itemize}

    \item As a \textbf{Manager}
    \begin{itemize}
        \item I want to \textbf{produce a timetable for each respective boat} [or individually]
        \item I want to \textbf{produce a list of all current reservations}
        \item I want to \textbf{retrieve all unpaid reservations}
        \item I want to \textbf{retrieve all overdue and thus unpaid reservations}
        \item I want to \textbf{produce a list of all current bookings}
        \item I want to \textbf{retrieve the amount of remaining seats for a ship}
        \item I want to \textbf{Retrieve a list of regular customers}
        \item I want to \textbf{Retrieve a list of customers with vehicle}
    \end{itemize}
\end{itemize}

\textbf{Statistics}
\begin{itemize}
    \item As a \textbf{Manager}
    \begin{itemize}
        \item I want to \textbf{produce statistics on average capacity per ship per
[month/year/quarter]}
        \item I want to \textbf{produce statistics on monthly income}
        \item I want to \textbf{produce statistics on average car length}
        \item I want to \textbf{produce statistics on average trailer length}
        \item I want to \textbf{produce statistics on cancellation of tickets} (to investigate what the main cause is)
    \end{itemize}
\end{itemize}

\section{Use cases}

\subsection{Make a booking}
\textit{Created by Paul Veldhuyzen}\\
\textit{Updated by Cristian Mihai Rosiu}\\

\subsubsection{Rationale/context}
Crucial to the business of ferrying passengers is customers being able to book their ferry ticket. To make a booking the customer needs to supply the system with the right set of specifications e.g. name, departure slot, do they need a bike ticket or not, payment preferences etc. This is essential for the ticket to be valid. Booking a ticket can be done by multiple actors, primarily a customer (online) and the ticket salesperson (at the office). Included in the ticket booking process is also payment of the ticket.\\

\subsubsection{User story}
As a regular customer I want to make a booking (includes payment).\\

\subsubsection{Use case}
\textbf{Title}: Make a booking\\
\textbf{Level}: User goal\\
\textbf{Special Requirements}: Payment\\ %Is this a non-functional requirement?\\
\textbf{Technology and Data Variations List}: None\\
\textbf{Frequency Of Occurrence}:
Daily, equal to the number of passengers\\
\textbf{Primary Actor}: Customer\\
\textbf{Stakeholders and Interests}:
\begin{itemize}
    \item Customer: wants to make a booking so they have a valid ticket to use the ferry and get to their destination.
    \item KOENDES: wants customers to easily be able to book a ticket. Wants to ensure payment of	said tickets.
\end{itemize}
\textbf{Precondition}: None\\
\textbf{Post condition}:
\begin{itemize}
    \item The new booking was created and saved in the system.
    \item The customer was informed that the booking was successful.
    \item The ticket was successfully payed for.
    \item The customer received their ticket.
\end{itemize}
\vspace{1em}
\textbf{Main Success Scenario}
\begin{enumerate}
    \item The customer sends a request to the system to make a booking
    \item The system sends the user an empty 'Booking Form' to be filled in
    \item User fills in the form (fills in all required$^{(1)}$ entries and maybe some optional$^{(1)}$ entries)
    \item User sends back the filled-in booking form (Using 'submit form').
    \item The system confirms the specifications of the booking are correct.
    \item If the specifications constraints $^{(1)}$ are not met, the system asks the customer to send new specifications and repeats 2-5
    \item The system creates a booking with a new unique bookingID and adds it to the database.
    \item The system sends a payment request in the manner that is wished.
    \item The customer makes the payment.
    \item The system confirms the payment when it is made.
    \item If the payment constraints (2) are not met, the system cancels the booking process.
    \item The system confirms to the customer that the booking was completed successfully and the sends a ticket to the customer.
\end{enumerate}

\textbf{Extensions (to MSS)}
\begin{itemize}
    \item (1) Required entries, optional entries and default values as indicated in the Data Model.
    \item (2) Payment method should be valid , i.e. the method used for payment should be in the company list of accepted methods. Moreover, the required entries can be seen in the Data Model
\end{itemize}

\vspace{1em}

\subsubsection{SSD}
\textit{Created by Paul Veldhuyzen}
\textit{Updatd by Cristian Mihai Rosiu}
\begin{enumerate}
    \item  USER $\rightarrow$ SYSTEM : requestBooking()
    \item Repeat ::
        \begin{itemize}
            \item SYSTEM $\rightarrow$ USER   : sendForm(bookingFrom)
            \item USER $\rightarrow$ USER: fill(bookingForm)
            \item USER $\rightarrow$ SYSTEM: sendForm(bookingForm)
            \item  SYSTEM $\rightarrow$ SYSTEM : validity = checkBooking(bookingForm)
            \item  SYSTEM $\rightarrow$ USER : bookingValidityReply(validity)
        \end{itemize}
    Until the user has entered valid booking specifications.
    \item SYSTEM $\rightarrow$ SYSTEM : booking = createBooking(bookingForm)
    \item SYSTEM $\rightarrow$ SYSTEM : payment = createPaymentRequest(booking)
    \item SYSTEM $\rightarrow$ USER :
    sendPaymentRequest(payment)
    \item Repeat ::
        \begin{itemize}
            \item  SYSTEM $\rightarrow$ SYSTEM : paymentExpirationCheck(payment)
            \item  USER $\rightarrow$ SYSTEM : makePayment(payment)
        \end{itemize}
    Until the user pays.
    \item SYSTEM $\rightarrow$ USER :
    paymentConfirmation(payment)
    \item SYSTEM $\rightarrow$ SYSTEM :
    ticket = createTicket(booking)
    \item SYSTEM $\rightarrow$ USER :
    bookingConfirmation(ticket, booking)

\end{enumerate}
If we convert the SSD into a diagram, we obtain the diagram in figure \ref{fig:diagramMakeBooking}.

\begin{figure}[H]
    \centering
     \includegraphics[scale=0.8]{bookingSSD.png}
    \caption{Diagram of 'make a booking' user case and corresponding SSD.}
    \label{fig:diagramMakeBooking}
\end{figure}

\subsection{Remove a user account}
\textit{Created by Gerrit Sijberen Luimstra}\\

\subsubsection{Rationale/context}
According to the General Data Protection Regulation (GDPR) it is mandatory for the system to have an ability to remove a user account, if a user so wishes. In this case the user account should be removed, along with all the associated bookings/reservations. Due to the statistics on said tickets being fairly useful, we choose to anonymize the bookings/reservations instead of removing it from the system completely. The bookings/reservations will however be cancelled.\\

\subsubsection{User story}
As a (Regular/Vehicle) customer, I want to remove my user account(right to be forgotten, GDPR)\\

\subsubsection{Use case}
\textbf{Title}: Remove a user account (GDPR)\\
\textbf{Level}: User goal\\
\textbf{Special Requirements}: No\\
\textbf{Technology and Data Variations List}: None\\
\textbf{Frequency Of Occurrence}:
Hopefully not very frequent, but does not adhere to any planning. This can happen continuously.\\
\textbf{Primary Actor}: A (Regular/Vehicle) customer\\
\textbf{Stakeholders and Interests}:
\begin{itemize}
    \item Customer: wants to be sure that his information is forgotten, or at least eliminate the possibility of linking the data back to the user in any way.
    \item Manager: wants to maintain the ability of having statistics on bookings/reservations
\end{itemize}
\textbf{Precondition}:
\begin{itemize}
    \item The customer is authorized into the system and has access to the associated account
\end{itemize}
\textbf{Post condition}:
\begin{itemize}
    \item The customers account is removed and there are no identifiable traces of the customer left.
    \item The bookings/reservations of the account are anonymized but remain in the system.
    \item The customer is informed about the removal of his/her/its account and his/her/its authorities are revoked.
\end{itemize}
\vspace{1em}
\textbf{Main Success Scenario}
\begin{enumerate}
    \item Customer sends a request for account removal to the system along with the associated account ID
    \item The system sends back a confirmation dialog that prompts the user to enter his/her/its password to prevent accidental deletion.
    \item Customers confirms by typing the password
    \item The system responds with the confirmation status ("OK" or "Password does not match.")
    \item If the constraints are not met (1), the system repeats step 2 - 4.
    \item The system cancels all the (running) bookings and reservation of said customer
    \item The system anonymizes all the associated bookings and reservation of said customer
    \item The system removed the customer accounts completely
    \item The system redirects the user outside of the authorized part of the system and responds to the customer (now without an account) that the account removal has been completed.
\end{enumerate}

\textbf{Extensions (to MSS)}
\begin{itemize}
    \item (1) The entered password matches the password of the account
\end{itemize}

\vspace{1em}

\newpage

\subsubsection{SSD}
\textit{Created by Gerrit Sijberen Luimstra}
\begin{enumerate}
    \item USER $\rightarrow$ SYSTEM   : requestAccountDeletion(accountID)
    \item Repeat ::
        \begin{itemize}
            \item  SYSTEM $\rightarrow$ USER : sendConfirmationDialog()
            \item  USER $\rightarrow$ SYSTEM : confirmAccountDeletion(password, accountID)
            \item  SYSTEM $\rightarrow$ USER : "OK" or "Password does not match."
        \end{itemize}
    until the user has entered the right password;
    \item SYSTEM $\rightarrow$ SYSTEM : cancelRunningTickets(accountID)
    \item SYSTEM $\rightarrow$ SYSTEM : anonymizeAccountData(accountID)
    \item SYSTEM $\rightarrow$ SYSTEM : removeAccount(accountID)
    \item SYSTEM $\rightarrow$ USER   : "Succesfully removed account" + redirect to login page
\end{enumerate}
If we convert the SSD into a diagram, we obtain the diagram in figure \ref{fig:diagramRemoveAccount}.
\begin{figure}[H]
    \centering
    \includegraphics[scale=0.8]{assignment1.png}
    \caption{Diagram of 'remove a user account' user case and corresponding SSD.}
    \label{fig:diagramRemoveAccount}
\end{figure}


\subsection{Update a booking}
\textit{Created by Cristian Mihai Rosiu}\\

\subsubsection{Rationale/context}
Depending on the situation, sometimes a booking needs to get updated , e.g. a problem occurred in the system or the customer has entered the wrong information. With the exception of booking ID, which is unique,  all the other properties of a booking are update-able.(Note that the updating of a booking can be done by special instances that have the permission to do it: e.g. Customer Support or by the customer itself).\\

\subsubsection{User story}
As a user, I want to update a booking with a given booking ID.\\

\subsubsection{Use case}
\textbf{Title}: Update of a booking\\
\textbf{Level}: User goal\\
\textbf{Special Requirements}: None\\
\textbf{Technology and Data Variations List}: None\\
\textbf{Frequency Of Occurrence}:
Hopefully not very frequent, but does not adhere to any planning. This can happen continuously.\\
\textbf{Primary Actor}: A (Regular/Vehicle) customer\\
\textbf{Stakeholders and Interests}:
\begin{itemize}
    \item Customer: wants to be sure his booking information is updated correctly
    \item Employee: wants to easily find the booking and update the specified fields
\end{itemize}
\textbf{Precondition}:
\begin{itemize}
    \item User is identified and given the privilege by the system to use this respective Use Case
\end{itemize}
\textbf{Post condition}:
\begin{itemize}
    \item Booking state changed: The old values of the given booking were successfully replaced by the new entered values.
    \item Show to user that the action was finished without any problems by outputting: “Successful Update”
\end{itemize}
\vspace{1em}
\textbf{Main Success Scenario}
\begin{enumerate}
    \item User sends request to the system to update a booking with a given booking ID.
    \item System sends back a form that has all the data available to the user if no constraints are violated (1).
    \item The user updates the form accordingly.
    \item User sends back to the System the updated form.
    \item If the constraints are not met (2), the system repeats step 2-6.
    \item System updates the booking with the data from the form.
    \item The System informs the user that the update was successful.\\
\end{enumerate}

\textbf{Extensions (to MSS)}
\begin{itemize}
    \item (1) In this case the constraint is: If the given booking with the given ID is found in the system.\\
    \item (2) By correct values we specifically refer to the domain of each variable in the booking instance e.g. : Date can’t contain only strings.
\end{itemize}

\vspace{1em}

\newpage

\subsubsection{SSD}
\textit{Created by Cristian Mihai Rosiu}
\begin{enumerate}
    \item USER $\rightarrow$ SYSTEM   : updateBooking(bookingID)
    \item SYSTEM $\rightarrow$ USER   : sendForm(form)
    \item Repeat ::
        \begin{itemize}
            \item  SYSTEM $\rightarrow$ USER : Update the values of the form.
            \item  USER $\rightarrow$ SYSTEM :  sendUpdate(form)
            \item  SYSTEM $\rightarrow$ USER : "OK" or "Invalid Data."
        \end{itemize}
    until the user has entered the right details;
    \item SYSTEM $\rightarrow$ SYSTEM : Update booking accordingly
\end{enumerate}
If we convert the SSD into a diagram, we obtain the diagram found in figure \ref{fig:updateDiagram}.
\begin{figure}[H]
    \centering
    \includegraphics[scale=0.8]{update_usecase_diagram.png}
    \caption{Diagram of 'update a booking' user case and corresponding SSD.}
    \label{fig:updateDiagram}
\end{figure}


\section{Domain Model}
\subsection{Introduction}
This section contains all the information about the current Domain Model. Here we introduce the concepts together with their attributes that we think were most suitable for this analyses. Moreover, the graph representation is shown in subsection \ref{subsectionGraph}.\\
\\
For a better understanding, we have chosen to offer additional explanation regarding the data model:
\begin{enumerate}
    \item Attribute(s) preceded by an exclamation mark are unique
    \item Attribute(s) between the brackets '[' and ']' are optional
    \item Attribute(s) starting with 'hat' is/are foreign keys
\end{enumerate}
\subsection{Concepts and their attributes}
An User is a customer that can partially interact with the system: e.g.: creating account, buying a ticket, updating a booking, updating personal details.\\
\\
\includegraphics[scale=0.6]{user_concept.png}\\
\\
The employee is a person that can directly access a parts of the system: e.g. Customer Support, managers.\\
\\
\includegraphics[scale=0.6]{employee_concept.png}\\
\\
A booking (i.e. reservation) instance holds all information about date, time and details regarding the passenger. As soon as the user requires it, it its created. A booking can exist without a payment. Therefore a ticket is required in advance.\\
\includegraphics[scale=0.6]{booking_concept.png}\\
\\
A ticket is the instance that show whether the customer made a payment or not. It has information about the price, and if the passenger has chosen to take a bike or a dog\\
\\
\includegraphics[scale=0.6]{ticket_cocnept.png}\\
\\
\\
A VehicleTicket is the instance that shows whether the customer made a payment or not to bring a vehicle on board. It has information about the length of the vehicle and the corresponding (regular) Ticket of the customer.\\
\\
\includegraphics[scale=0.6]{v_ticket_concept.png}\\
\\
\\
Ship concept contains ferry information such as name, type, both passenger and vehicle capacities and the location of departure\\
\\
\includegraphics[scale=0.6]{ship_concept.png}\\
\\
\\
The payment reference which states the method used for buying a ticket.\\
\\
\includegraphics[scale=0.6]{payment_concept.png}\\
\subsection{Associations and the graph representing them}
\label{subsectionGraph}

User \underline{1 BUY 0..*} Ticket\\
User \underline{ 1 HAS 0..*} Booking\\
Booking \underline{1 HAS 0..*} Ticket\\
Booking  \underline{1 HAS 1} PaymentReference\\
Employee \underline{0..* ASSES 0..*} Booking\\
Ticket  \underline{1 CAN BE 1} VehicleTicket\\
Ticket  \underline{0..* HAS 1} Ship\\

The model is visualized in the graph shown in figure \ref{fig:domainModel}.
\begin{figure}
\centering
\hspace*{-1.5cm}
\includegraphics[scale=0.4]{graph.png}\\
\caption{Domain model of different concepts their attributes and relations}
\label{fig:domainModel}
\end{figure}

% QUESTIONS: TO BE REMOVED LATER
% - Do ‘normal’ passengers (no car etc.) need to reserve a week in advance?
% - What about the ferry from Terschelling to Vlieland? Is their ‘Harlingen – Terschelling’ ticket enough and they just need a surcharge. Do people pay two surcharges if they get on in Harlingen and need to get off in Vlieland.
% - Should you be able to rebook the return trip once you made the first part of a trip? In which case I would need to add the booking in the user wishes too.
% Ticket checking should be done with the same system, is that correct? Or may this part be omitted?
% Do we need the template?
\end{document}