frekkanzer2 / eat-reorder Goto Github PK

Lavorando ai dati del database, ho notato un'incongruenza nel DD.
Una era già nota e riguardava i caratteri delle due città che non combaciavano (ne è stato aperto il compito sul test plan): città azienda e fattorino - formato dati non corretto (dimensioni diverse, modificare con 20).
Altra incongruenza riguarda la sezione DD_Ord: nel form vengono inseriti indirizzo, carta di credito e note, mentre nel dizionario sono presenti dati non conformi. Lascio a voi la refactorizzazione siccome so che dovrete modificare anche i documenti riguardanti il testing. Bisogna, appunto, modificare il DD e i documenti di testing, adattandoli ai seguenti dati:
indirizzo -> valori alfanumerici con dimensione massima 30
carta di credito -> va bene l'attuale campo
note ordine -> va bene l'attuale campo
Il cliente, al momento dell'ordine, inserisce solo questi tre campi. La città non viene controllata siccome viene mantenuta in sessione già quando si effettua la ricerca dell'azienda.
In caso di dubbi, discutete nei commenti qui sotto.

Andando a lavorare con la matrice di accesso, mi sono resoconto della necessità dell'avere un oggetto su cui effettuare operazioni, cosa che fondamentalmente nei SD RFR non accadeva. Inoltre, dando un'occhiata, ho notato il fatto che nella gestione dei prodotti delle aziende si andasse ad aggiornare sempre l'azienda come oggetto in sessione ma mai nel database. Di conseguenza, quindi, è stato introdotto in manager utente nei SDs. Ovviamente i metodi cambiati sono stati apportati nell'elenco dei metodi di GitHub. Di conseguenza, se c'è qualcos'altro da cambiare, sapete che è stata effettuata tale modifica.

I gestori devono essere rivisti siccome sono errati, essendo assegnati alle categorie coperte dal sistema. Il carrello, invece, bisogna renderlo come classe persistente, con metodi statici per effettuare il retrieve del carrello. Inoltre, eventuali operazioni come aggiunta di un prodotto, ecc, devono esser effettuati in tale classe.

Questo issue verrà aggiornato nei commenti, in modo che possiate sempre ricevere notifiche

nella classe UtenteDao il metodo per aggiornare il fattorino non funziona correttamente,o meglio funziona ma non effettua il cambiamento dei dati del fattorino.

Mancano i controlli riguardanti chi sta utilizzando la servlet/jsp.
Tali controlli dovranno essere implementati alla fine dell'implementazione "di base", in modo da avere un sistema completo e in modo da dover aggiornare tutto senza dimenticarsi qualcosa.

Si devono completare tutti gli accessi alle jsp e alle servlet in base al tipo di utente @frekkanzer2 @Roxar90 @MarcoProduction

Stavo testando la registrazione dell'Azienda, ma mi ha dato la seguente eccezione nel momento in cui ho testato un metodo del gestore utenti:

Sostanzialmente, il problema è qui:

Non è possibile ricavare dei giorni effettuando un controllo sulla mail (?)
Fixate appena possibile per favore, siccome devo testare le pagine riguardanti la gestione dell'azienda

EDIT
Vi chiedo di completare e testare ENTRO DOMANI il backend riguardante la:
Registrazione Azienda
Login Azienda
Inserimento Prodotto Azienda
Richiedo di farlo così in fretta perchè sono bloccato, siccome devo creare pagine che utilizzino i prodotti dell'azienda. Se non mi funziona quel che dovete testare, non posso andare avanti.
Vi chiedo cortesemente di dedicarvi a ciò e di finirlo il prima possibile

A seguito dei cambiamenti di formati le seguenti pagine jsp devono essere cambiate ,
RegistrazioneCliente, RegistrazioneAzienda,RegistrazioneFattorino
ModificaCliente, ModificaAzienda,ModificaFattorino
InserisciProdotto, ModificaProdotto.
Fate sapere quando si possono cambiare che lo faccio ,massimo 15 minuti @frekkanzer2 @Roxar90 @MarcoProduction

Inserire del testo che indichi che non ci sono aziende secondo la ricerca effettuata

Ridefinire il diagramma della scomposizione del sistema in sottosistemi tenendo in considerazione il fatto che probabilmente i sottosistemi da gestire saranno 2 (Gestione Utente e Gestione Ordinazioni)

Creare sequence diagram per vista dinamica utilizzando boundary, control e model dei casi d'uso per Ordinazione e Registrazione Cliente

È necessario creare il database in SQL, pubblicando il file contenente il codice nella cartella "Documents". Una volta creato il database ed una volta testato il funzionamento (è consigliabile effettuare qualche query di prova giusto per assicurarsi il corretto funzionamento), è necessario ricavarsene il modello logico tramite apposito tool di MySQL.
Il modello va pubblicato nel DBD al posto dell'ER.
Le tabelle in SQL devono essere basate sulle tabelle descritte nel DBD.

Ho un problema con il SD di RFR5, siccome deve essere trattato anche lo stato dell'ordine e non ho la benchè minima idea di come gestirlo..
@Roxar90 puoi darci un'occhiata e, magari, vedere se riesci almeno ad abbozzarlo? Non ti preoccupare riguardo i nomi dei boundary, control, metodi, ecc.
Mi basta una bozza, poi provvedo io a riadattarlo.
Scusa per questo piccolo lavoro extra 😢

Come stabilito, man mano che si scriverà codice bisognerà aggiornare diversi documenti.
La creazione di classi o jsp o html implica la modifica della sezione packages nell'ODD.
La creazione di qualsiasi query implica la modifica del DBD.

Da finire entro domenica notte

Revisionare i SD apportando le opportune modifiche circa la gestione degli oggetti quando è necessario passarli al manager.

Creare una tabella con boundary e control e la loro relazione(quale boundary utilizza quale control, quale control inizializza quale boundary) utilizzando come riferimento i sequence diagram del RAD

Durante il laboratorio del 24/10/2019 si è verificato un problema riguardante la documentazione "Gestione Acquisto": secondo il diagramma affiliato, qualsiasi utente registrato e non registrato può visualizzare e cercare aziende e prodotti, quando in realtà solamente clienti ed utenti non registrati possono effettuare tali operazioni.
Il diagramma UCs "Gestione Acquisto" è stato già modificato a dovere, ma bisogna aggiornare i seguenti documenti il prima possibile in modo tale che rispettano la condizione sopra descritta:

• VisualizzaDettagliProdotto
• VisualizzaProdotti
• RicercaAzienda

Alcuni documenti degli UCs tra quelli descritti potrebbero non esistere dati i cambiamenti recenti apportati al diagramma. Siccome sto lavorando io alla creazione dei documenti UCs inesistenti, probabilmente ne troverete alcuni tra quelli elencati già fixati, quindi ignorateli e lavorate solo su quelli che non rispettano la condizione descritta.
Quindi, riassumendo:
È necessario modificare gli attori correlati a quel determinato caso d'uso solamente nel documento affiliato e, se necessario, anche il flusso di eventi siccome gli attori compaiono. Gestitevi la suddivisione dei compiti tra voi.

È necessario avere il commit "Aggiornamento 1910241253" sul proprio computer prima di poter lavorare a ciò che vi è stato assegnato!

PS: Eventuali aggiornamenti verranno riportati nei commenti; gli aggiornamenti più importati sono citati di seguente:

Il flusso di eventi dello UC RFA2 deve essere riadattato siccome non tratta la visualizzazione dei prodotti, bensì la ricerca dei prodotti.
@MarcoProduction quando puoi ricrea il flusso di eventi e modifica anche la condizione descritta nell'issue

Devono essere completati UC RFA5 ed RFA6, i quali sono nuovi.
@kenz097 non appena puoi compilali e committa

Stabiliti oggi i compiti per finire il RAD in questa settimana:
Io lavorerò ai mockup oggi, venerdì 15; sabato revisionerò i sequence diagrams (o almeno i principali) in modo da prepararli per il RAD.
Rosario lavorerà alla creazione del class diagram e alla composizione del RAD, il quale ultimerà domenica 17.
Marco e Vincenzo si prepareranno al testing, studiandolo nel migliore dei modi per poi praticarli martedì, consultandosi con il tutor.
È necessario che ognuno svolga al meglio i propri compiti, onde rientrare ai tempi del programma.

Poichè dobbiamo avere una versione comune per il server penso che la cosa migliore sia di utilizzare tomcat 9.0, in caso contrario scrivete qua sopra altrimenti lo utilizziamo tutti. @frekkanzer2 @Roxar90 @MarcoProduction

Su GitHub leggevo riguardo la creazione di un GestoreMail. Io attualmente sto lavorando alle segnalazioni e ho notato una somiglianza tra GestoreSegnalazione e GestoreMail, siccome il GestoreSegnalazione dovrà poter accettare la segnalazione del cliente ed inviare la mail all'amministratore. Volevo sapere se il GestoreMail è stato creato da qualcuno per le segnalazioni o per altro.
Inoltre, riguardo il GestoreSegnalazione, mi servirebbe un parere riguardo il come gestire il fatto che venga mandata la mail all'amministratore sui SD.

Nella modifica dell'azienda (non ho controllato per il fattorino), ci sono dei problemi con i giorni: non vengono inseriti quelli che l'azienda già possiede. Non so se sia un problema di DB o di visualizzazione, ma sta di fatto che non funziona.
Necessari controlli domani!

Come ben sapete, mi sono incaricato del controllo di tutti i SD.
Osservando la gestione acquisti e la gestione ristorante, ho notato alcune ridondanze e alcune confusioni riguardo il come son stati gestiti i gestori. Ho deciso, quindi, di stabilire ciò, a parer mio decisamente sensato: se un metodo deve intaccare l'Azienda, allora appartiene al GestoreRistorante; se un metodo intacca un elemento della fase di acquisto come il carrello, allora appartiene al GestoreAcquisto.
Quindi, metodi come dammiProdotto(Azienda, codiceProdotto) non apparterranno più alla GestioneAcquisto, bensì alla GestioneRistorante (e direi sia decisamente più sensato).
Inoltre, vi avverto che i metodi refactorizzati sul VPP non sono aggiornati su GitHub: ciò significa che bisognerà rivedere i SDs per riscriverli e farsi un elenco dei metodi su GitHub. Faremo ciò martedì al tutorato.

Non è possibile effettuare l'ordinazione quando l'ora di chiusura supera la mezzanotte del giorno successivo. Ciò è dovuto al fatto che, dalla mezzanotte in poi, tutti gli orari risultano successivi e non precedenti di conseguenza il controllo sulla chiusura dell'azienda fallisce.
Inoltre se l'orario di chiusura supera la mezzanotte bisogna tenere in considerazione il fatto che l'azienda sia aperta anche il giorno successivo quindi il controllo del giorno va effettuato passando il giorno successivo - 1.
Lo stesso controllo dovrà essere aggiunto all'assegnamento del fattorino da parte del database che in caso contrario, non troverebbe i fattorini anche se disponibili

Creare Casi d'uso per Boundary Conditions Amministratore ( start,failure,shutdown)

È necessario completare l'header per fornire un header anche al moderatore.
@kenz097 fallo quando puoi.

Effettuare controlli e risolvere, grazie

Il bug si presenta nel caso ci si registri con una mail già esistente nella REGISTRAZIONE AZIENDA.
Se è un problema di servlet, risolve Vincenzo. Se è un problema di database, risolve Rosario.

Inserire le label nei form

Creare il documento per database con mapping E-R, tabelle e query(almeno le principali)

Dalla discussione di oggi, 03/12/2019, sorge la mancanza di un'importante eccezione nel caso d'uso dell'ordinazione.
Il caso d'uso RFA 3 - Ordinazione permette la compilazione di un form e la creazione di un oggetto Ordine che verrà gestito da Azienda e Fattorino: l'Azienda cucinerà i piatti presenti nell'Ordine, mentre il Fattorino si occuperà della consegna di esso. Nel comportamento di default viene fatto solamente un controllo sulla correttezza dei dati. Sorge, però, un problema.
Il problema consiste nel fatto che, una volta creato l'ordine, per qualsiasi motivo possano mancare i fattorini, quindi non si potrà in alcun modo consegnare l'ordine al Cliente.
È necessario, quindi, introdurre un'eccezione nel caso d'uso RFA 3 - Ordinazione.
L'eccezione si chiamerà RFA 3.b - MancanzaFattorini e consisterà nella visualizzazione di un boundary in cui viene mostrato un messaggio di errore dovuto dalla mancanza di fattorini nella città di consegna.
Prima di proseguire, avverto che è necessario leggere per intero l'issue anzichè iniziare a lavorare senza aver concluso la lettura.
L'aggiunta di tale eccezione prevede le seguenti attività:

1. Refactoring del documento UC RFA 3, siccome deve essere aggiunta l'eccezione nel flusso principale;
2. Refactoring del SD RFA 3, siccome deve essere aggiunto il controllo della presenza dei fattorini (il controllo deve esser fatto dal manager riguardante l'utenza);
3. Aggiunta del SD RFA 3.b, siccome si deve prevedere il sequence diagram dell'eccezione;
4. Aggiornamento delle classi intaccate e dei metodi nella sezione Projects -> RAD di GitHub;

Le modifiche devono essere apportare su un file word posto nella cartella Documents del progetto, chiamato EDIT_ISSUE_RFA3.B.docx
Tale documento includerà lo UC RFA 3 e gli SD modificati.
Evitiamo la modifica dei documenti della repository in modo da poter rivedere e correggere eventuali errori presenti nelle modifiche.
La modifica è assegnata a Vincenzo De Martino. È necessario consegnare il documento con le modifiche entro il 7/12/2019 ed entro le ore 22.00.
Io effettuerò un eventuale refactoring di tale documento nel caso ce ne sia bisogno nel giorno dopo.
Evitiamo modifiche al RAD siccome effettueremo in futuro un controllo ed un refactoring massivo di tutti i documenti. Almeno per ora, il RAD rimane intaccato.
Per qualsiasi chiarimento o spiegazione commentate il topic, in modo da tenerci salvata la discussione.

È necessario controllare con accuratezza gli SD, in modo da trovare eventuali nomi diversi tra un SD e l'altro. Nel caso si debba apportare una modifica, essa dovrà essere registrata anche in tutti gli altri diagrammi (non per forza solamente gli SD).
Alla fine di tale controllo, è necessario esportare tutti gli SD e tutti gli altri diagrammi modificati sul RAD.

La sessione non viene svuotata con il logout.
Il mio ultimo update, purtroppo, non è servito.
Una soluzione sarebbe quella di rimuovere ogni singolo attributo dalla sessione manualmente.
Ne discutiamo poi domani.
[È possibile verificare il bug accedendo con diversi utenti e visualizzando il profilo di uno di essi]

E' stato riscontrato un problema durante il test delle regex, in particolare nei vari formati che comprendono un apostrofo, quest'ultimo risulta essere sbagliato sintatticamente, di conseguenza la regex da esito negativo.

COSA FARE:
Bisogna cambiare le regex che abbiano l'apostrofo sbagliato nella classe checkFormato.java e tutte le classi JSP che utilizzano le regex della classe checkFormato.

Rivedere le classi del sistema e definire i metodi e gli attributi di tutte le classi del sistema così come sono emersi dai SD.
Ridefinizione del class diagram in RAD aggiungendo le tabelle associative per carrello/prodotto e prodotto/ordine

Per ogni SD di inserimento, l'oggetto da memorizzare va creato dal control. Un oggetto per il controllo dei dati verifica i dati dell'oggetto ed eventualmente restituisce un messaggio di errore. Se l'oggetto ha i dati validi. Dopo di che il manager riceve l'oggetto dal control e effettua l'inserimento dell'oggetto nel db.

Se la query restituisce dei dati allora il manager crea l'oggetto
Se la query inserisce dati allora il control crea l'oggetto e il manager lo memorizza
Se la query elimina, il control passa solo la chiave dell'oggetto al manager che elimina.

Le aziende bannate non devono essere visualizzate.
Per ogni azienda visualizzata devono essere mostrati gli orari e i giorni lavorativi.

Definire tutti i servizi forniti dai sottosistemi creando una tabella con servizio/descrizione
Creare tabella tavola degli accessi: per ogni servizio, definire la coppia attore/operazioneconsentita

Svolgere i seguenti compiti entro le date indicate

Rosario
Ridefinire il mapping HW/SW in SDD - 19/12/2019
Specificare l'Adapter nei design pattern (cos'è e perchè si usa) - 19/12/2019
Specificare almeno 5 class interfaces a piacere - 20/12/2019

Abby
Spostare il gestore mail più in basso nella scomposizione in SDD rispetto agli altri gestori - 19/12/2019
Importare il class diagram con firme nell'ODD - 19/12/2019
Trattare tutti i packages - 20/12/2019

Mark
Controllare capitolo 1 in ODD - 19/12/2019
Specificare il DAO nei design pattern (cos'è e perchè si usa) - 19/12/2019
Deployment a runtime (web-uml extension) - 22/12/2019

Per come è stato pensato fin'ora, il sistema terrà parzialmente conto degli ordini:

• Il cliente non potrà gestire e visualizzare gli ordini
• L'azienda visualizzerà gli ordini attivi commissionatele
  Dal fatto che l'azienda può visualizzare gli ordini, comprendiamo che gli ordini verranno, quindi, salvati temporaneamente nel database finchè essi non verranno completati (per completati si intende si sia confermato ritiro dell'ordine presso l'azienda e consegna presso il domicilio indicato dal cliente).
  In RFU4, l'utente inserisce il numero dell'ordine a cui si riferisce la segnalazione: se gli ordini non sono più presenti nel database una volta chiusi, allora il numero dell'ordine nel form della segnalazione diventa futile.
  Si chiedono chiarimenti, quindi, nella giornata di oggi, 07/11/2019.

Inserire i controlli di JS sulle JSP