Servizio noleggio biciclette città

Di seguito viene proposto un progetto complessivo (in forma discorsiva, ma strutturato), che affronta le varie richieste. Per maggiore chiarezza, l’elaborato è suddiviso nei punti indicati.

---

PARTE I

1. Progetto dell’infrastruttura tecnologica e informatica necessaria a gestire il servizio

1.a Infrastruttura di comunicazione

Scenario generale
Abbiamo diverse stazioni di noleggio/riconsegna dislocate sul territorio cittadino, ciascuna dotata di:

• Un lettore contactless (per la smartcard dell’utente).
• Circa 50 slot, ognuno con un lettore RFID integrato per leggere il tag della bicicletta.
• Un piccolo dispositivo “controller locale” (in genere un mini-PC/embedded board) che:
  • Gestisce i dati provenienti dai lettori RFID degli slot.
  • Comunica con il lettore contactless.
  • Invia e riceve dati dal sistema centrale.

Rete di comunicazione

• Collegamento dalla stazione al centro: le stazioni possono connettersi alla rete centrale tramite:
  1. Rete cablata (fibra/ADSL), dove possibile.
  2. Rete cellulare (4G/5G), nel caso in cui la connessione cablata non sia disponibile o economica; in molte città si opta per SIM dati su router industriali.
• Protocolli: a livello applicativo, potrebbe essere usato un protocollo sicuro come HTTPS o MQTT over TLS.
  • HTTPS per invocare API REST del sistema centrale (soluzione semplice e largamente diffusa).
  • MQTT (con TLS) per una comunicazione continua e leggera (utile se si vogliono ricevere notifiche in tempo reale sui cambi di stato).

In ogni stazione, quindi, il controller locale si occupa di:

1. Leggere i dati di noleggio/riconsegna (ID utente, ID bicicletta, timestamp).
2. Gestire i blocchi meccanici (apertura/chiusura).
3. Trasmettere in tempo reale le informazioni al server centrale.

Sicurezza e affidabilità

• Utilizzo di VPN o connessioni cifrate end-to-end (TLS) per garantire integrità e riservatezza dei dati.
• Backup di rete su più canali (ad esempio una doppia SIM su router industriale) per garantire continuità.

---

1.b Caratteristiche generali dei componenti hardware e software

1. Componenti a livello centrale

   • Server dell’applicazione (o cluster di server) che gestisce:
     • Il database principale (con i dati degli utenti, delle biciclette, degli slot, delle operazioni di noleggio/riconsegna, ecc.).
     • Il motore di tariffazione (calcolo costi, fatturazione).
     • Servizi web (API REST o pagina web + WebApp/portale).
   • Server di monitoraggio (potrebbe essere lo stesso o un modulo distinto) per mostrare in tempo reale:
     • Quante bici sono disponibili in ogni stazione.
     • Quanti slot liberi ci sono.
   • Server di autenticazione (potrebbe essere un modulo integrato o stand-alone) per la gestione delle credenziali degli utenti, l’autenticazione, l’autorizzazione a noleggiare.

2. Componenti a livello delle stazioni

   • Controller locale (hardware tipo mini-PC o embedded con sistema Linux o Windows Embedded).
   • Lettore contactless (supporto smartcard contactless standard, ad es. MIFARE).
   • Lettori RFID (uno per ciascuno slot, integrato nel blocco).
   • Unità di blocco meccanico (lucchetto controllato via segnale digitale).
   • Modulo di comunicazione (router cellulare industriale o gateway ethernet/fibra).

3. Software

   • A livello di stazione: un’applicazione/servizio che:
     1. Gestisce i dispositivi (lettori contactless, RFID, lucchetti).
     2. Comunica in tempo reale con il server centrale (via REST/MQTT).
   • A livello centrale:
     • Applicazione web-based (front-end + back-end).
     • Database relazionale (es. PostgreSQL o MySQL).
     • Modulo tariffazione e reportistica.

---

1.c Misure e apparati per assicurare la continuità del servizio

• Gruppi di continuità (UPS) presso ogni stazione per evitare interruzioni dell’alimentazione agli slot e al controller.
• Alimentazione ridondata (se possibile) nei data center centrali, con generatori di emergenza.
• Ridondanza dell’infrastruttura server:
  • Virtualizzazione o containerizzazione (es. Docker + Kubernetes) per distribuire i carichi e minimizzare i tempi di down.
  • Replica dei database (master-slave o master-master) per garantire resilienza.
• Piano di Disaster Recovery con backup periodici dei dati su sito remoto.

---

2. Progetto della base di dati

Si propone un modello concettuale (E/R) e poi il modello logico (relazionale).

2.a Modello concettuale (E/R semplificato)

• ENTITÀ
  1. Utente
     • Attributi: ID_Utente, Nome, Cognome, Indirizzo, Email, NumCartaCredito, ProfiloTariffa, …
  2. Bicicletta
     • Attributi: ID_Bicicletta, Modello, Stato (es. “disponibile”, “in manutenzione”, “noleggiata”), …
  3. Stazione
     • Attributi: ID_Stazione, Nome, Indirizzo, CoordinateGPS, NumSlotTotale, NumSlotLiberi (questo può anche essere ricavato dalle relazioni con gli slot), …
  4. Slot
     • Attributi: ID_Slot, StatoSlot (es. “occupato”, “libero”), …
     • Relazione: ogni Slot appartiene a una Stazione.
  5. Noleggio (o Operazione di Noleggio/Riconsegna)
     • Attributi: ID_Noleggio, DataOraInizio, DataOraFine, Costo, …
     • Relazioni:
       • Noleggio associato a un Utente (chi ha noleggiato).
       • Noleggio associato a una Bicicletta.
       • Noleggio si avvia in una certa Stazione (stazione_prelievo) e termina in un’altra Stazione (stazione_restituzione).

Nota: A volte si può separare “Noleggio” e “Riconsegna” in due tabelle, ma spesso è più comodo un’unica tabella con DataOraInizio e DataOraFine.

2.b Modello logico (relazionale)

Di seguito uno schema possibile (campi semplificati):

text
TABELLA Utente (
  ID_Utente            INT PRIMARY KEY,
  Nome                 VARCHAR(50) NOT NULL,
  Cognome              VARCHAR(50) NOT NULL,
  Indirizzo            VARCHAR(100),
  Email                VARCHAR(100) UNIQUE,
  NumCartaCredito      VARCHAR(20),
  ProfiloTariffa       VARCHAR(20) -- es. standard, premium, etc.
  -- altri campi a piacere
);

TABELLA Stazione (
  ID_Stazione          INT PRIMARY KEY,
  Nome                 VARCHAR(50),
  Indirizzo            VARCHAR(100),
  Latitudine           DECIMAL(9,6),
  Longitudine          DECIMAL(9,6)
  -- si possono aggiungere altri campi (es: zone, quartiere, etc.)
);

TABELLA Slot (
  ID_Slot              INT PRIMARY KEY,
  ID_Stazione          INT NOT NULL,
  StatoSlot            VARCHAR(20)  -- "libero", "occupato", "guasto", ...
  -- vincolo di FK
  FOREIGN KEY (ID_Stazione) REFERENCES Stazione(ID_Stazione)
);

TABELLA Bicicletta (
  ID_Bicicletta        INT PRIMARY KEY,
  Modello              VARCHAR(50),
  Stato                VARCHAR(20)  -- "disponibile", "noleggiata", "manutenzione", ...
);

TABELLA Noleggio (
  ID_Noleggio          INT PRIMARY KEY,
  ID_Utente            INT NOT NULL,
  ID_Bicicletta        INT NOT NULL,
  StazionePrelievo     INT NOT NULL,
  StazioneRiconsegna   INT,           -- potrebbe essere NULL finché non riconsegnata
  DataOraInizio        DATETIME NOT NULL,
  DataOraFine          DATETIME,      -- potrebbe essere NULL finché non riconsegnata
  Costo                DECIMAL(6,2),
  -- vincoli di FK
  FOREIGN KEY (ID_Utente) REFERENCES Utente(ID_Utente),
  FOREIGN KEY (ID_Bicicletta) REFERENCES Bicicletta(ID_Bicicletta),
  FOREIGN KEY (StazionePrelievo) REFERENCES Stazione(ID_Stazione),
  FOREIGN KEY (StazioneRiconsegna) REFERENCES Stazione(ID_Stazione)
);

Gestione dello stato degli Slot e delle Biciclette:

• Quando la bicicletta è parcheggiata in uno slot, quell’Slot risulta “occupato” e la Bicicletta risulta “disponibile” (ma fisicamente in quell’Slot). Talvolta si crea una tabella di associazione “SlotBiciclettaCorrente” oppure si aggiunge in “Slot” un riferimento alla Bicicletta (ID_Bicicletta) se è occupato.
• In fase di noleggio, la Bicicletta passa a stato “noleggiata”, e lo Slot si libera.

---

3. Progetto delle pagine web

Per semplicità, supponiamo di avere un portale con diverse sezioni. Le funzionalità richieste sono:

1. Mappa delle stazioni: all’accesso, si visualizza una mappa interattiva (Google Maps o altra libreria).

   • Cliccando su una stazione, appare un pop-up con:
     • Nome stazione
     • Numero di biciclette disponibili
     • Numero di slot liberi
   • Funzionalità: se la stazione ha biciclette disponibili, compare un’indicazione (“Biciclette disponibili: N”).

2. Visualizzare le biciclette attualmente in uso

   • Sezione riservata al gestore del sistema.
   • Una tabella che elenca:
     • ID_Bicicletta
     • ID_Utente attuale (o Nome e Cognome utente)
     • Stazione di prelievo
     • Ora di inizio noleggio

Esempio di codice (HTML + pseudo-PHP/SQL)

(a) Verifica disponibilità bici in una data stazione

html
<!-- pagina stazioni.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Bike Sharing - Stazioni</title>
  <!-- include librerie JS per la mappa, CSS, etc. -->
</head>
<body>
  <h1>Elenco Stazioni</h1>
  <!-- Mappa interattiva, omessa per brevità -->
  <div id="mappa"></div>

  <!-- Elenco stazioni testuale, da generare dinamicamente -->
  <table>
    <tr>
      <th>Stazione</th>
      <th>Indirizzo</th>
      <th>Biciclette Disponibili</th>
      <th>Slot Liberi</th>
    </tr>
    <!-- Ciclo sulle stazioni -->
    <?php
    // Esempio di query per ottenere la disponibilità
    // SELECT s.ID_Stazione, s.Nome, s.Indirizzo,
    //   (SELECT COUNT(*) FROM Slot sl 
    //       WHERE sl.ID_Stazione = s.ID_Stazione 
    //         AND sl.ID_Bicicletta IS NOT NULL) AS bikeAvailable,
    //   (SELECT COUNT(*) FROM Slot sl 
    //       WHERE sl.ID_Stazione = s.ID_Stazione 
    //         AND sl.ID_Bicicletta IS NULL) AS slotFree
    // FROM Stazione s

    // Esempio di rendering
    while($row = fetch($result)) {
      echo "<tr>";
      echo "<td>{$row['Nome']}</td>";
      echo "<td>{$row['Indirizzo']}</td>";
      echo "<td>{$row['bikeAvailable']}</td>";
      echo "<td>{$row['slotFree']}</td>";
      echo "</tr>";
    }
    ?>
  </table>
</body>
</html>

(b) Biciclette in uso

html
<!-- pagina gestione.html -->
<!DOCTYPE html>
<html>
<head>
  <title>Gestione - Biciclette in uso</title>
</head>
<body>
  <h1>Biciclette Attualmente Noleggiate</h1>
  <table>
    <tr>
      <th>ID Bicicletta</th>
      <th>Utente</th>
      <th>Stazione Prelievo</th>
      <th>Data/Ora Inizio</th>
    </tr>
    <?php
    // Query esemplificativa:
    // SELECT b.ID_Bicicletta, u.Nome, u.Cognome, st.Nome AS NomeStazione, n.DataOraInizio
    // FROM Noleggio n
    // JOIN Bicicletta b ON n.ID_Bicicletta = b.ID_Bicicletta
    // JOIN Utente u ON n.ID_Utente = u.ID_Utente
    // JOIN Stazione st ON n.StazionePrelievo = st.ID_Stazione
    // WHERE n.DataOraFine IS NULL  (--> significa che il noleggio è in corso)

    while($row = fetch($result)) {
      echo "<tr>";
      echo "<td>{$row['ID_Bicicletta']}</td>";
      echo "<td>{$row['Nome']} {$row['Cognome']}</td>";
      echo "<td>{$row['NomeStazione']}</td>";
      echo "<td>{$row['DataOraInizio']}</td>";
      echo "</tr>";
    }
    ?>
  </table>
</body>
</html>

---

PARTE II

1. Report contenente le biciclette noleggiate da un utente, stazioni, durata e costi

Specifica: L’utente deve poter richiedere (o ricevere periodicamente) un report con:

• Elenco dei noleggi effettuati (ID bicicletta, stazione di prelievo, stazione di riconsegna).
• Durata di ogni noleggio (differenza DataOraFine - DataOraInizio).
• Costo sostenuto per ogni noleggio.
• Totale.

Struttura del report

Ad esempio, un file PDF/HTML inviato via mail:

text
Report noleggi - Utente Mario Rossi (ID_Utente=123)
---------------------------------------------------
1) Bicicletta: 25
   Stazione prelievo: StazioneCentro
   Stazione riconsegna: StazioneStadio
   Inizio: 2025-01-10 08:15  Fine: 2025-01-10 09:05
   Durata: 00:50
   Costo: 2,50 €

2) Bicicletta: 14
   ...
   Costo: ...
---------------------------------------------------
TOTALE speso: ...

Invio periodico automatico

• L’utente nel proprio profilo può impostare una frequenza di invio (es. settimanale, mensile).
• Soluzione: configurare un job/scheduler sul server (es. cron job) che:
  • Ogni X giorni/settimane esegue uno script.
  • Lo script legge gli utenti che hanno la periodicità impostata in quella data (es. “ogni lunedì”).
  • Genera il report (query e formattazione).
  • Invia una mail con il PDF allegato o un link per scaricarlo.

Motivazione: è una soluzione standard e robusta, perché:

• Centralizziamo la logica di invio su un server affidabile.
• Possiamo gestire facilmente il carico (gli invii avvengono in batch).
• L’utente non deve ricordarsi di richiedere manualmente il report.

---

2. Sviluppo in linguaggio SQL delle query

Sono richieste due query:

(a) Dato il codice di una bicicletta, elencare gli utenti che l’hanno utilizzata nel mese corrente

Supponiamo di voler estrarre: ID_Utente, Nome, Cognome. Usando la convenzione che MONTH(DataOraInizio) = MONTH(CURDATE()) indica il mese corrente e YEAR(DataOraInizio) = YEAR(CURDATE()) indica l’anno corrente.

sql
SELECT DISTINCT u.ID_Utente, u.Nome, u.Cognome
FROM Noleggio n
JOIN Utente u ON n.ID_Utente = u.ID_Utente
WHERE n.ID_Bicicletta = :idBici
  AND MONTH(n.DataOraInizio) = MONTH(CURDATE())
  AND YEAR(n.DataOraInizio) = YEAR(CURDATE());

(Al posto di :idBici mettiamo il codice della bicicletta.)

(b) Mostrare la stazione presso la quale è stato effettuato il maggior numero di noleggi in un dato periodo

Definiamo il periodo con due parametri: :dataInizio, :dataFine. Vogliamo ID_Stazione o Nome, e il conteggio.

sql
SELECT s.ID_Stazione, s.Nome, COUNT(*) as numeroNoleggi
FROM Noleggio n
JOIN Stazione s ON n.StazionePrelievo = s.ID_Stazione
WHERE n.DataOraInizio BETWEEN :dataInizio AND :dataFine
GROUP BY s.ID_Stazione, s.Nome
ORDER BY numeroNoleggi DESC
LIMIT 1;

In questo modo otteniamo la stazione con più noleggi nel periodo desiderato (tramite LIMIT 1).

---

PARTE III

Normalizzazione della tabella QUADRO

Abbiamo la relazione:

text
QUADRO(
  Cod_Quadro,
  Cod_Museo,
  Titolo_Quadro,
  Nome_Museo,
  Citta_Museo,
  Prezzo,
  DataInizioEsposizione,
  DataFineEsposizione
)

Verifica delle forme normali

1. 1FN (Prima forma normale)

   • Presumibilmente tutti i campi sono atomici (Cod_Quadro, Cod_Museo, Titolo_Quadro, …) → OK.

2. 2FN (Seconda forma normale)

   • Serve una PK. Si suppone che la PK sia (Cod_Quadro). A meno che si consideri la coppia (Cod_Quadro, Cod_Museo) come chiave, ma di solito il codice del quadro (univoco) basta.
   • Se la PK è “Cod_Quadro” da solo, non abbiamo dipendenze parziali (gli altri attributi dipendono tutti dal quadro). Quindi sembra a posto per la 2FN.

3. 3FN (Terza forma normale)

   • Verificare se ci sono dipendenze transitive. Per esempio, Nome_Museo e Citta_Museo dipendono da Cod_Museo, non da Cod_Quadro.
   • Quindi abbiamo una dipendenza: Cod_Museo → Nome_Museo, Citta_Museo.
   • Inoltre, Cod_Quadro → Prezzo, DataInizioEsposizione, DataFineEsposizione, (Cod_Museo?).
   • Questo vuol dire che “Nome_Museo, Citta_Museo” non dovrebbero stare nella tabella QUADRO, bensì in una tabella MUSEO.

Schema normalizzato

• Tabella QUADRO:

  text
  QUADRO (
    Cod_Quadro PK,
    Cod_Museo FK,
    Titolo_Quadro,
    Prezzo,
    DataInizioEsposizione,
    DataFineEsposizione
  )

• Tabella MUSEO:

  text
  MUSEO (
    Cod_Museo PK,
    Nome_Museo,
    Citta_Museo
  )

Motivazione

• Si evita la ridondanza di Nome_Museo e Citta_Museo in QUADRO.
• Se uno stesso museo ospita più quadri, Nome_Museo e Citta_Museo non vengono duplicati.
• Con questa divisione, siamo in 3FN: ogni attributo non chiave (Nome_Museo, Citta_Museo) dipende solo dalla chiave della rispettiva entità (Cod_Museo).

---

PARTE IV

Sicurezza, integrità e riservatezza dei sistemi informatici di rete

Nella gestione di un sistema informatico di rete, è fondamentale autenticare gli utenti in modo sicuro. Principali tecniche/protocolli:

1. Autenticazione basata su password

   • Vantaggi: semplice da implementare, ampiamente supportata.
   • Svantaggi: se le password sono deboli o non protette (in chiaro o con hashing debole), c’è rischio di compromissione.
   • Miglioramenti: salvataggio con hashing robusto (es. bcrypt, Argon2), password policy, ecc.

2. Autenticazione a due fattori (2FA)

   • Vantaggi: aggiunge un livello di sicurezza (token monouso, app OTP, SMS, ecc.).
   • Svantaggi: maggiore complessità per l’utente, necessità di un servizio per generare/verificare i token.

3. Certificati digitali (autenticazione basata su certificato)

   • Vantaggi: molto sicura (chiave privata localmente e certificato firmato da una CA).
   • Svantaggi: più complessa da distribuire/gestire per l’utente (smartcard, software di gestione certificati).

4. Single Sign-On (SSO) con protocolli quali OAuth2 / OpenID Connect / SAML

   • Vantaggi: l’utente si autentica una volta presso un Identity Provider e poi può accedere a più servizi. Migliore user experience.
   • Svantaggi: maggiore complessità architetturale, dipendenza dall’Identity Provider.

5. Sicurezza di trasporto (TLS/SSL)

   • Indispensabile per garantire la riservatezza dei dati scambiati (come credenziali, dati sensibili).

Considerazioni finali

• In un sistema di bike sharing con dati sensibili (numero di carta di credito, dati anagrafici), è auspicabile utilizzare almeno password sicure + TLS.
• Eventualmente, per gli operatori amministrativi, si può imporre 2FA.
• Per la parte di contatto con i device fisici (lettori contactless, RFID), è bene prevedere protocolli di crittografia e sistemi di sicurezza fisica (ad es. protezioni anti-manomissione dei lettori).

---

CONCLUSIONE

La soluzione proposta:

1. Descrive un’architettura distribuita con stazioni intelligenti e un server centrale.
2. Definisce un database relazionale che traccia utenti, biciclette, slot e noleggi.
3. Prevede pagine web (o app) per monitorare in tempo reale la disponibilità di biciclette e slot, e per la gestione del servizio da parte degli operatori.
4. Include meccanismi di reportistica automatica per gli utenti.
5. Garantisce sicurezza e continuità grazie a tecnologie standard di rete, protocolli sicuri e metodologie di backup e ridondanza.

È un progetto che può essere facilmente implementato con tecnologie moderne (REST API, database SQL, front-end JavaScript/HTML5, app mobile). L’importante è assicurare la scalabilità (in caso la città cresca e si aggiungano più stazioni) e la manutenibilità del sistema (aggiornamenti, nuove funzionalità, gestione guasti).