iblt00-sp

[tibl0m]

proTrezervace

Jedná se o rezervační systém, který je určen pro protetické pracoviště. Návštěvník této stránky si může zobrazit kalendář s aktuálně dostupnými termíny. Pokud je přihlášen, tak si může termín zarezervovat. Rezervace mu musí být následně potvrzena pověřenou osobou. Uživatelé s oprávněním vidí v kalendáři jednotlivé záznamy ostatních uživatelů.

Popis funkcionalit

Návštěvníkovi sránky je zobrazen kalendář s volnými termíny protetického pracoviště. Pokud si chce termín rezervovat, tak se musí zaregistrovat do systému a přihlásit. Přihlášený uživatet navíc může nahlížet do svých rezervací a rušit je dokud nejsou potvrzeny. Uživatel s oprávněním (recepce pracoviště) potvrzuje rezervace a přiřazuje k nim pracovníky, případně je zamítá. Tento uživatel zároveň specifikuje, jaké typy termínů protetické pracoviště rozlišuje. V neposlední řadě může nahlížet do kalendáře s aktuálně obsazenými termíny včetně jejich detailu a případně je zrušit. Administrátor systému zakládá uživatele s oprávněním a vytváří tabulku kódů zdravotnických prostředků, jež dané pracoviště vyrábí.

useCase diagram

Wireframe

Registration Form

Login Form

Calendar - regular user

Reservation Form

Reservations' Overview - user

User details

Daily view - privileged user

Calendar - privileged user

Admin Pane

Architektura

• webový server (Apache)
• back-end (PHP)
• databáze (MySQL)
• front-end (JS)

  Návrh databáze

  

  Procesní diagram, sekvenční diagram

  Bude doplněno

  Checklist

  Kategorie	Požadavek	Splnění	Spolehlivost	Komentář
  Databáze	M:N vztahy	X
  	1:N vztahy	X
  	SQL joins	X
  	Integritní omezení	X
  	Testovací data	?
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Validace a sanitace vstupů	Formuláře	X
  Datové typy	X
  Regulární výrazy	X
  Serverová validace vstupů	X
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Psaní kódu	Potlačení warningů	X
  	Formátování kódu	X
  	DRY princip - minimalizace opakování kódu	X
  	SRP princip - single responsibility
  	Pojmenování proměnných	X
  	Konzistence stylu psaní kódu	X
  	Verzování kódu (Git)	X
  	HTML5 validní + sémantické značky	X
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Objektové programování	Zapouzdření	X
  	Dědičnost	X
  	Abstrakce	X
  	Rozhraní	X
  	Polymorfismus	X
  	Magické metody
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Připojení k databázy	PDO	X
  	Prepared statement	X
  	SQL injection	X
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Performance	Stránkování
  	Indexace databázových tabulek	X
  	Filtrace a organizování zdrojů	X
  	Cache (mezipaměť)
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Autentifikace	Cookies	X
  	Session	X
  	Lokální strategie pro registraci a přihlášení
  	OAuth, access token, login	X
  	Ukládánní hesel	X
  	Uživatelská oprávnění	X
  	Uživatelské role	?
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Datum a čas	Časové pásmo	X
  	Formátování časových hodnot	X
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Návrhové vzory	Model
  	View
  	Controller
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Bezpečnost	XSS
  	CSRF
  	SQL injection	X
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  API	CRUD operace
  	HTTP metody
  	Sémantické pojmenování zdrojů
  	Verzování
  	Idempotence
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Provoz a údržba	Sledovatelnost a logování
  	SEO URL
  	Víceuživatelský přístup k datům	X
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Funkcionality	Generování souborů PDF
  	Posílání e-mailů	X
  	Oddělení ddministrační a uživatelské části	X
  ----------------------------	-------------------------------------------------	---------	--------------	----------
  Testování	Testovací scénáře pro manuální testování
  	Dostupnost aplikace na internetu	X

[nvbach91]

• reservations/for je co? kdyz to ma datovy typ datetime tak asi prejmenovat na reservations/date?
• rezervace by mely mit i dobu trvani, tj. pocet minut od casu, na kdy je pacient objednan
• v tabulce reservations je atribut created_by, to je zrejme reference ja recepcni, ale kde je informace o tom pro ktereho pacienta je rezervace vytvorena?

[tibl0m]

• reservations/for je co? kdyz to ma datovy typ datetime tak asi prejmenovat na reservations/date?

Jedná se o čas a datum, kdy nastává rezervační termín (např. 20/04/2024 18:00)

• bude přejmenováno na date

  • rezervace by mely mit i dobu trvani, tj. pocet minut od casu, na kdy je pacient objednan

Rezervace jsou na celou hodinu. V reálném světě pacient neví, jak dlouho je potřeba pro jeho termín a neví to ani recepční. Délku dokáží určit s malou přesností zaměstnanci na základě lékařského předpisu, případně telefonátu lékaři. Pokud to stihnou rychleji, tak se vrací k výrobě a pokud se to protáhne, tak další pacient čeká a celý den se zpozdí.

• mohu přidat délku trvání rezervace
  • potom by čas trvání určila recepce (uživatel s oprávněním přijmat/zamítat rezervace) při potvrzení
  • funkcionalita pro pacienta zůstane objednání pouze na celé hodiny
  • mohu přidat funkcionalitu pro recepci v podobě zadání termínu komukoli (i neuživateli) na jakkoukoli dobu trvání a společně s tím řešit, zda takový termín má blokovat objednání pacientů po dobu trvání či nikoli

    • v tabulce reservations je atribut created_by, to je zrejme reference ja recepcni, ale kde je informace o tom pro ktereho pacienta je rezervace vytvorena?

Jedná se o informaci jaký pacient rezervaci vytvořil, v systému je pouze jedna recepční a i kdyby jich bylo více, tak není třeba uchovávat, kdo rezervaci potvrdil

[nvbach91]

Takze recepcni nikdy nebude zadavat rezervace, ale pouze je potvrzovat a prirazovat pracovnika