SHARE
TWEET

Untitled

a guest Dec 7th, 2019 77 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. \documentclass{article}
  2. \usepackage[utf8]{inputenc}
  3. \usepackage{graphicx}
  4. \usepackage{float}
  5.  
  6.  
  7. \title{Problem Analysis and Software Design}
  8. \author{Cristian Rosiu - Paul Veldhuyzen - Gerrit Sijberen Luimstra}
  9. \date{November 2019}
  10.  
  11.  
  12. %%%%%
  13. %%%%% To find a list of the current todo list
  14. %%%%% https://trello.com/b/1sxVgzW2/problem-analysis-and-software-design
  15. %%%%%
  16.  
  17. \begin{document}
  18.  
  19. \maketitle
  20.  
  21. \tableofcontents
  22. \newpage
  23.  
  24. \section{Introduction}
  25. 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.
  26.  
  27. \newpage
  28.  
  29. \section{Actors and other stakeholders}
  30. \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.}\\
  31.  
  32. The following parties will be able to interact with the system and can be considered \textbf{actors}:
  33. \begin{itemize}
  34.     \item Rob Frisia (Manager)
  35.     \item Regular customers
  36.     \item Customers with vehicle (truck drivers / residents)
  37.     \item Secretary / Cashier (at the office)
  38.     \item System administrator
  39.     \item Ticket collector
  40.     \item Customer support\\
  41. \end{itemize}
  42.  
  43. Other relevant \textbf{stakeholders} not immediately interacting with the system:
  44. \begin{itemize}
  45.     \item Government handing out the permits (car permits)
  46.     \item The banks of both the company and its customers
  47.     \item Traffic crew responsible for directing the vehicles to the boats
  48.     \item Boat crew
  49.     \item Boat captain
  50.     \item Island residents
  51.     \item Financial advisors
  52.     \item Travel sites
  53.     \item Insurance companies
  54.     \item Police
  55. \end{itemize}
  56.  
  57. 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.
  58.  
  59. \section{User wishes}
  60. \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.}\\
  61.  
  62. 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.\\
  63.  
  64. \textbf{User accounts}
  65. \begin{itemize}
  66.     \item Create user account
  67.     \item Update a user account
  68.     \item Remove a user account (GDPR)
  69.     \item Read customer information
  70. \end{itemize}
  71.  
  72. \textbf{Booking}
  73. \begin{itemize}
  74.     \item Make a booking (includes payment)
  75.     \item Update a booking
  76.     \item Request booking information (associated with the code, if done online)
  77.     \item Retrieve specific booking by the ‘code’
  78.     \item Retrieve e-ticket for a booking
  79. \end{itemize}
  80.  
  81. \textbf{Reservation}
  82. \begin{itemize}
  83.     \item Register a reservation
  84.     \item Pay for a reservation online
  85.     \item Request a reservation bill
  86.     \item Pay a reservation bill
  87.     \item Update a reservation
  88.     \item Cancel an overdue reservation
  89.     \item Notify customer of overdue payment and thus cancelled reservation
  90.     \item Cancel a reservation
  91.     \item Retrieve a specific reservation (associated with the code, if done online)
  92.     \item Retrieve e-ticket for a reservation
  93.     \item Retrieve specific reservation by the ‘code’
  94. \end{itemize}
  95.  
  96. \textbf{General}
  97. \begin{itemize}
  98.     \item Produce a timetable for each respective boat [or individually]
  99.     \item Produce a list of all current reservations
  100.     \item Retrieve all unpaid reservations
  101.     \item Retrieve all overdue and thus unpaid reservations
  102.     \item Produce a list of all current bookings
  103.     \item Retrieve the amount of remaining seats for a ship
  104.     %Were these bold for a reason?
  105.     \item Retrieve boat information
  106.     \item Produce a list of valid permits
  107.     \item Retrieve future departments
  108.    
  109.     \item Update cancellation possibility
  110. \end{itemize}
  111.  
  112. \textbf{Statistics}
  113. \begin{itemize}
  114.     \item Produce statistics on:
  115.     \begin{itemize}
  116.         \item average capacity per ship per [month/year/quarter]
  117.         \item monthly income
  118.         \item average car length
  119.         \item average trailer length
  120.         \item cancellation of tickets (to investigate what the main cause is)
  121.     \end{itemize}
  122. \end{itemize}
  123.  
  124. \newpage
  125.  
  126. \section{User stories}
  127. \textit{The aim of this chapter is to provide the user stories for the roles that partake in the system
  128. to be built. The purpose of a user story is articulate how a piece of work will deliver a
  129. particular value back to the customer.}\\
  130.  
  131. \textbf{User account}
  132. \begin{itemize}
  133.     \item As a \textbf{(Regular/Vehicle) customer}
  134.     \begin{itemize}
  135.         \item I want to \textbf{create a user account} to access my bookings/reservations easily
  136.         \item I want to \textbf{update my user account}
  137.         \item I want to \textbf{remove my user account} (right to be forgotten, GDPR)
  138.         \item I want to \textbf{read my account information}
  139.         \item I want to \textbf{pay a reservation bill}
  140.     \end{itemize}
  141. \end{itemize}
  142.  
  143. \textbf{Booking}
  144. \begin{itemize}
  145.     \item As a \textbf{Regular customer}
  146.     \begin{itemize}
  147.         \item I want to \textbf{make a booking} (includes payment)
  148.         \item I want to \textbf{update a booking}
  149.         \item I want to \textbf{request specific booking information}
  150.         \item I want to \textbf{retrieve specific booking by the ‘code’}
  151.         \item I want to \textbf{retrieve an e-ticket for a booking}
  152.     \end{itemize}
  153.    
  154.     \item As a \textbf{Secretary}
  155.     \begin{itemize}
  156.         \item I want to \textbf{make a booking for a customer} (includes payment)
  157.         \item I want to \textbf{update a booking}
  158.         \item I want to \textbf{request specific booking information}
  159.         \item I want to \textbf{retrieve an e-ticket for a booking}
  160.     \end{itemize}
  161.    
  162.     \item As a \textbf{Customer Support}
  163.     \begin{itemize}
  164.         \item I want to \textbf{request specific booking information}
  165.     \end{itemize}
  166.    
  167.     \item As a \textbf{Ticket inspector}
  168.     \begin{itemize}
  169.         \item I want to \textbf{request specific booking information by the 'code'}
  170.         % Should this be a feature?
  171.         \item I want to \textbf{retrieve an e-ticket for a booking}
  172.     \end{itemize}
  173. \end{itemize}
  174.  
  175. \textbf {Reservation}
  176. \begin{itemize}
  177.     \item As a \textbf{Customer with a vehicle}
  178.     \begin{itemize}
  179.         \item I want to \textbf{register a reservation}
  180.         \item I want to \textbf{pay for a reservation online}
  181.         \item I want to \textbf{request a reservation bill}
  182.         \item I want to \textbf{update a reservation}
  183.         \item I want to \textbf{cancel a reservation}
  184.         \item I want to \textbf{retrieve a specific reservation by its ‘code’}
  185.         \item I want to \textbf{retrieve an e-ticket for a reservation}
  186.     \end{itemize}
  187.    
  188.     \item As a \textbf{Customer Support}
  189.     \begin{itemize}
  190.         \item I want to \textbf{request specific reservation information}
  191.         \item I want to \textbf{update specific reservation information}
  192.     \end{itemize}
  193.    
  194.     \item As a \textbf{System administrator} % this is more of a system thing..
  195.     \begin{itemize}
  196.         \item I want to \textbf{manually cancel and overdue reservation}
  197.         \item I want to \textbf{manually notify a customer of overdue payment} (cancelled reservation)
  198.         \item I want to \textbf{manually notify all customers of the boarding time in advance}
  199.         \item I want to \textbf{manually notify all customers of the arrival time in advance}
  200.         \item I want to \textbf{manually notify all customers of cancellation (in the case of an issue)}
  201.     \end{itemize}
  202.    
  203.     \item As a \textbf{Ticket inspector}
  204.     \begin{itemize}
  205.         \item I want to \textbf{request specific reservation information by the 'code'}
  206.         % Should this be a feature?
  207.         \item I want to \textbf{retrieve an e-ticket for a booking}
  208.     \end{itemize}
  209. \end{itemize}
  210.  
  211. \textbf{General}
  212. \begin{itemize}
  213.     \item As a \textbf{System administrator}
  214.     \begin{itemize}
  215.         \item I want to \textbf{produce a timetable for each respective boat} [or individually]
  216.         \item I want to \textbf{produce a list of all current reservations}
  217.         \item I want to \textbf{retrieve all unpaid reservations}
  218.         \item I want to \textbf{retrieve all overdue and thus unpaid reservations}
  219.         \item I want to \textbf{produce a list of all current bookings}
  220.     \end{itemize}
  221.    
  222.     \item As a \textbf{Manager}
  223.     \begin{itemize}
  224.         \item I want to \textbf{produce a timetable for each respective boat} [or individually]
  225.         \item I want to \textbf{produce a list of all current reservations}
  226.         \item I want to \textbf{retrieve all unpaid reservations}
  227.         \item I want to \textbf{retrieve all overdue and thus unpaid reservations}
  228.         \item I want to \textbf{produce a list of all current bookings}
  229.         \item I want to \textbf{retrieve the amount of remaining seats for a ship}
  230.         \item I want to \textbf{Retrieve a list of regular customers}
  231.         \item I want to \textbf{Retrieve a list of customers with vehicle}
  232.     \end{itemize}
  233. \end{itemize}
  234.  
  235. \textbf{Statistics}
  236. \begin{itemize}
  237.     \item As a \textbf{Manager}
  238.     \begin{itemize}
  239.         \item I want to \textbf{produce statistics on average capacity per ship per
  240. [month/year/quarter]}
  241.         \item I want to \textbf{produce statistics on monthly income}
  242.         \item I want to \textbf{produce statistics on average car length}
  243.         \item I want to \textbf{produce statistics on average trailer length}
  244.         \item I want to \textbf{produce statistics on cancellation of tickets} (to investigate what the main cause is)
  245.     \end{itemize}
  246. \end{itemize}
  247.  
  248. \section{Use cases}
  249.  
  250. \subsection{Make a booking}
  251. \textit{Created by Paul Veldhuyzen}\\
  252. \textit{Updated by Cristian Mihai Rosiu}\\
  253.  
  254. \subsubsection{Rationale/context}
  255. 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.\\
  256.  
  257. \subsubsection{User story}
  258. As a regular customer I want to make a booking (includes payment).\\
  259.  
  260. \subsubsection{Use case}
  261. \textbf{Title}: Make a booking\\
  262. \textbf{Level}: User goal\\
  263. \textbf{Special Requirements}: Payment\\ %Is this a non-functional requirement?\\
  264. \textbf{Technology and Data Variations List}: None\\
  265. \textbf{Frequency Of Occurrence}:
  266. Daily, equal to the number of passengers\\
  267. \textbf{Primary Actor}: Customer\\
  268. \textbf{Stakeholders and Interests}:
  269. \begin{itemize}
  270.     \item Customer: wants to make a booking so they have a valid ticket to use the ferry and get to their destination.
  271.     \item KOENDES: wants customers to easily be able to book a ticket. Wants to ensure payment of   said tickets.
  272. \end{itemize}
  273. \textbf{Precondition}: None\\
  274. \textbf{Post condition}:
  275. \begin{itemize}
  276.     \item The new booking was created and saved in the system.
  277.     \item The customer was informed that the booking was successful.
  278.     \item The ticket was successfully payed for.
  279.     \item The customer received their ticket.
  280. \end{itemize}
  281. \vspace{1em}
  282. \textbf{Main Success Scenario}
  283. \begin{enumerate}
  284.     \item The customer sends a request to the system to make a booking
  285.     \item The system sends the user an empty 'Booking Form' to be filled in
  286.     \item User fills in the form (fills in all required$^{(1)}$ entries and maybe some optional$^{(1)}$ entries)
  287.     \item User sends back the filled-in booking form (Using 'submit form').
  288.     \item The system confirms the specifications of the booking are correct.
  289.     \item If the specifications constraints $^{(1)}$ are not met, the system asks the customer to send new specifications and repeats 2-5
  290.     \item The system creates a booking with a new unique bookingID and adds it to the database.
  291.     \item The system sends a payment request in the manner that is wished.
  292.     \item The customer makes the payment.
  293.     \item The system confirms the payment when it is made.
  294.     \item If the payment constraints (2) are not met, the system cancels the booking process.
  295.     \item The system confirms to the customer that the booking was completed successfully and the sends a ticket to the customer.
  296. \end{enumerate}
  297.  
  298. \textbf{Extensions (to MSS)}
  299. \begin{itemize}
  300.     \item (1) Required entries, optional entries and default values as indicated in the Data Model.
  301.     \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
  302. \end{itemize}
  303.  
  304. \vspace{1em}
  305.  
  306. \subsubsection{SSD}
  307. \textit{Created by Paul Veldhuyzen}
  308. \textit{Updatd by Cristian Mihai Rosiu}
  309. \begin{enumerate}
  310.     \item  USER $\rightarrow$ SYSTEM : requestBooking()
  311.     \item Repeat ::
  312.         \begin{itemize}
  313.             \item SYSTEM $\rightarrow$ USER   : sendForm(bookingFrom)
  314.             \item USER $\rightarrow$ USER: fill(bookingForm)
  315.             \item USER $\rightarrow$ SYSTEM: sendForm(bookingForm)  
  316.             \item  SYSTEM $\rightarrow$ SYSTEM : validity = checkBooking(bookingForm)
  317.             \item  SYSTEM $\rightarrow$ USER : bookingValidityReply(validity)
  318.         \end{itemize}
  319.     Until the user has entered valid booking specifications.
  320.     \item SYSTEM $\rightarrow$ SYSTEM : booking = createBooking(bookingForm)
  321.     \item SYSTEM $\rightarrow$ SYSTEM : payment = createPaymentRequest(booking)
  322.     \item SYSTEM $\rightarrow$ USER :
  323.     sendPaymentRequest(payment)
  324.     \item Repeat ::
  325.         \begin{itemize}
  326.             \item  SYSTEM $\rightarrow$ SYSTEM : paymentExpirationCheck(payment)
  327.             \item  USER $\rightarrow$ SYSTEM : makePayment(payment)
  328.         \end{itemize}    
  329.     Until the user pays.
  330.     \item SYSTEM $\rightarrow$ USER :
  331.     paymentConfirmation(payment)
  332.     \item SYSTEM $\rightarrow$ SYSTEM :
  333.     ticket = createTicket(booking)
  334.     \item SYSTEM $\rightarrow$ USER :
  335.     bookingConfirmation(ticket, booking)
  336.  
  337. \end{enumerate}
  338. If we convert the SSD into a diagram, we obtain the diagram in figure \ref{fig:diagramMakeBooking}.
  339.  
  340. \begin{figure}[H]
  341.     \centering
  342.      \includegraphics[scale=0.8]{bookingSSD.png}
  343.     \caption{Diagram of 'make a booking' user case and corresponding SSD.}
  344.     \label{fig:diagramMakeBooking}
  345. \end{figure}
  346.  
  347. \subsection{Remove a user account}
  348. \textit{Created by Gerrit Sijberen Luimstra}\\
  349.  
  350. \subsubsection{Rationale/context}
  351. 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.\\
  352.  
  353. \subsubsection{User story}
  354. As a (Regular/Vehicle) customer, I want to remove my user account(right to be forgotten, GDPR)\\
  355.  
  356. \subsubsection{Use case}
  357. \textbf{Title}: Remove a user account (GDPR)\\
  358. \textbf{Level}: User goal\\
  359. \textbf{Special Requirements}: No\\
  360. \textbf{Technology and Data Variations List}: None\\
  361. \textbf{Frequency Of Occurrence}:
  362. Hopefully not very frequent, but does not adhere to any planning. This can happen continuously.\\
  363. \textbf{Primary Actor}: A (Regular/Vehicle) customer\\
  364. \textbf{Stakeholders and Interests}:
  365. \begin{itemize}
  366.     \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.
  367.     \item Manager: wants to maintain the ability of having statistics on bookings/reservations
  368. \end{itemize}
  369. \textbf{Precondition}:
  370. \begin{itemize}
  371.     \item The customer is authorized into the system and has access to the associated account
  372. \end{itemize}
  373. \textbf{Post condition}:
  374. \begin{itemize}
  375.     \item The customers account is removed and there are no identifiable traces of the customer left.
  376.     \item The bookings/reservations of the account are anonymized but remain in the system.
  377.     \item The customer is informed about the removal of his/her/its account and his/her/its authorities are revoked.
  378. \end{itemize}
  379. \vspace{1em}
  380. \textbf{Main Success Scenario}
  381. \begin{enumerate}
  382.     \item Customer sends a request for account removal to the system along with the associated account ID
  383.     \item The system sends back a confirmation dialog that prompts the user to enter his/her/its password to prevent accidental deletion.
  384.     \item Customers confirms by typing the password
  385.     \item The system responds with the confirmation status ("OK" or "Password does not match.")
  386.     \item If the constraints are not met (1), the system repeats step 2 - 4.
  387.     \item The system cancels all the (running) bookings and reservation of said customer
  388.     \item The system anonymizes all the associated bookings and reservation of said customer
  389.     \item The system removed the customer accounts completely
  390.     \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.
  391. \end{enumerate}
  392.  
  393. \textbf{Extensions (to MSS)}
  394. \begin{itemize}
  395.     \item (1) The entered password matches the password of the account
  396. \end{itemize}
  397.  
  398. \vspace{1em}
  399.  
  400. \newpage
  401.  
  402. \subsubsection{SSD}
  403. \textit{Created by Gerrit Sijberen Luimstra}
  404. \begin{enumerate}
  405.     \item USER $\rightarrow$ SYSTEM   : requestAccountDeletion(accountID)
  406.     \item Repeat ::
  407.         \begin{itemize}
  408.             \item  SYSTEM $\rightarrow$ USER : sendConfirmationDialog()
  409.             \item  USER $\rightarrow$ SYSTEM : confirmAccountDeletion(password, accountID)
  410.             \item  SYSTEM $\rightarrow$ USER : "OK" or "Password does not match."
  411.         \end{itemize}
  412.     until the user has entered the right password;
  413.     \item SYSTEM $\rightarrow$ SYSTEM : cancelRunningTickets(accountID)
  414.     \item SYSTEM $\rightarrow$ SYSTEM : anonymizeAccountData(accountID)
  415.     \item SYSTEM $\rightarrow$ SYSTEM : removeAccount(accountID)
  416.     \item SYSTEM $\rightarrow$ USER   : "Succesfully removed account" + redirect to login page
  417. \end{enumerate}
  418. If we convert the SSD into a diagram, we obtain the diagram in figure \ref{fig:diagramRemoveAccount}.
  419. \begin{figure}[H]
  420.     \centering
  421.     \includegraphics[scale=0.8]{assignment1.png}
  422.     \caption{Diagram of 'remove a user account' user case and corresponding SSD.}
  423.     \label{fig:diagramRemoveAccount}
  424. \end{figure}
  425.  
  426.  
  427. \subsection{Update a booking}
  428. \textit{Created by Cristian Mihai Rosiu}\\
  429.  
  430. \subsubsection{Rationale/context}
  431. 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).\\
  432.  
  433. \subsubsection{User story}
  434. As a user, I want to update a booking with a given booking ID.\\
  435.  
  436. \subsubsection{Use case}
  437. \textbf{Title}: Update of a booking\\
  438. \textbf{Level}: User goal\\
  439. \textbf{Special Requirements}: None\\
  440. \textbf{Technology and Data Variations List}: None\\
  441. \textbf{Frequency Of Occurrence}:
  442. Hopefully not very frequent, but does not adhere to any planning. This can happen continuously.\\
  443. \textbf{Primary Actor}: A (Regular/Vehicle) customer\\
  444. \textbf{Stakeholders and Interests}:
  445. \begin{itemize}
  446.     \item Customer: wants to be sure his booking information is updated correctly
  447.     \item Employee: wants to easily find the booking and update the specified fields
  448. \end{itemize}
  449. \textbf{Precondition}:
  450. \begin{itemize}
  451.     \item User is identified and given the privilege by the system to use this respective Use Case
  452. \end{itemize}
  453. \textbf{Post condition}:
  454. \begin{itemize}
  455.     \item Booking state changed: The old values of the given booking were successfully replaced by the new entered values.
  456.     \item Show to user that the action was finished without any problems by outputting: “Successful Update”
  457. \end{itemize}
  458. \vspace{1em}
  459. \textbf{Main Success Scenario}
  460. \begin{enumerate}
  461.     \item User sends request to the system to update a booking with a given booking ID.
  462.     \item System sends back a form that has all the data available to the user if no constraints are violated (1).
  463.     \item The user updates the form accordingly.
  464.     \item User sends back to the System the updated form.
  465.     \item If the constraints are not met (2), the system repeats step 2-6.
  466.     \item System updates the booking with the data from the form.
  467.     \item The System informs the user that the update was successful.\\
  468. \end{enumerate}
  469.  
  470. \textbf{Extensions (to MSS)}
  471. \begin{itemize}
  472.     \item (1) In this case the constraint is: If the given booking with the given ID is found in the system.\\
  473.     \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.
  474. \end{itemize}
  475.  
  476. \vspace{1em}
  477.  
  478. \newpage
  479.  
  480. \subsubsection{SSD}
  481. \textit{Created by Cristian Mihai Rosiu}
  482. \begin{enumerate}
  483.     \item USER $\rightarrow$ SYSTEM   : updateBooking(bookingID)
  484.     \item SYSTEM $\rightarrow$ USER   : sendForm(form)
  485.     \item Repeat ::
  486.         \begin{itemize}
  487.             \item  SYSTEM $\rightarrow$ USER : Update the values of the form.
  488.             \item  USER $\rightarrow$ SYSTEM :  sendUpdate(form)
  489.             \item  SYSTEM $\rightarrow$ USER : "OK" or "Invalid Data."
  490.         \end{itemize}
  491.     until the user has entered the right details;
  492.     \item SYSTEM $\rightarrow$ SYSTEM : Update booking accordingly
  493. \end{enumerate}
  494. If we convert the SSD into a diagram, we obtain the diagram found in figure \ref{fig:updateDiagram}.
  495. \begin{figure}[H]
  496.     \centering
  497.     \includegraphics[scale=0.8]{update_usecase_diagram.png}
  498.     \caption{Diagram of 'update a booking' user case and corresponding SSD.}
  499.     \label{fig:updateDiagram}
  500. \end{figure}
  501.  
  502.  
  503. \section{Domain Model}
  504. \subsection{Introduction}
  505. 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}.\\
  506. \\
  507. For a better understanding, we have chosen to offer additional explanation regarding the data model:
  508. \begin{enumerate}
  509.     \item Attribute(s) preceded by an exclamation mark are unique
  510.     \item Attribute(s) between the brackets '[' and ']' are optional
  511.     \item Attribute(s) starting with 'hat' is/are foreign keys
  512. \end{enumerate}
  513. \subsection{Concepts and their attributes}
  514. 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.\\
  515. \\
  516. \includegraphics[scale=0.6]{user_concept.png}\\
  517. \\
  518. The employee is a person that can directly access a parts of the system: e.g. Customer Support, managers.\\
  519. \\
  520. \includegraphics[scale=0.6]{employee_concept.png}\\
  521. \\
  522. 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.\\
  523. \includegraphics[scale=0.6]{booking_concept.png}\\
  524. \\
  525. 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\\
  526. \\
  527. \includegraphics[scale=0.6]{ticket_cocnept.png}\\
  528. \\
  529. \\
  530. 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.\\
  531. \\
  532. \includegraphics[scale=0.6]{v_ticket_concept.png}\\
  533. \\
  534. \\
  535. Ship concept contains ferry information such as name, type, both passenger and vehicle capacities and the location of departure\\
  536. \\
  537. \includegraphics[scale=0.6]{ship_concept.png}\\
  538. \\
  539. \\
  540. The payment reference which states the method used for buying a ticket.\\
  541. \\
  542. \includegraphics[scale=0.6]{payment_concept.png}\\
  543. \subsection{Associations and the graph representing them}
  544. \label{subsectionGraph}
  545.  
  546. User \underline{1 BUY 0..*} Ticket\\
  547. User \underline{ 1 HAS 0..*} Booking\\
  548. Booking \underline{1 HAS 0..*} Ticket\\
  549. Booking  \underline{1 HAS 1} PaymentReference\\
  550. Employee \underline{0..* ASSES 0..*} Booking\\
  551. Ticket  \underline{1 CAN BE 1} VehicleTicket\\
  552. Ticket  \underline{0..* HAS 1} Ship\\
  553.  
  554. The model is visualized in the graph shown in figure \ref{fig:domainModel}.
  555. \begin{figure}
  556. \centering
  557. \hspace*{-1.5cm}
  558. \includegraphics[scale=0.4]{graph.png}\\
  559. \caption{Domain model of different concepts their attributes and relations}
  560. \label{fig:domainModel}
  561. \end{figure}
  562.  
  563. % QUESTIONS: TO BE REMOVED LATER
  564. % - Do ‘normal’ passengers (no car etc.) need to reserve a week in advance?
  565. % - 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.
  566. % - 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.
  567. % Ticket checking should be done with the same system, is that correct? Or may this part be omitted?
  568. % Do we need the template?
  569. \end{document}
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Top