[OTHER] Segnalazioni RP

[lorenzodeinegri]

• [x] Registro delle modifiche: modificare le regole di versionamento, per evitare che l'approvazione per il rilascio determini uno scatto di indice maggiore, senza che ci siano modifiche.

  Si potrebbe rimuovere la x da x.y.z, però bisogna pensare come tenere aggiornata l'ultima baseline in caso di approvazioni distanti dalla consegna.

• [x] Metiche banali: bisogna aggiungere le nuove metriche per la codifica, oltre che amplicare la sezione di codifica stessa e degli strumenti di supporto.

  Bisogna anche ricordarsi dei test. Valutare se ci sono altre cose da aggiungere alle norme.

• [x] Aggiungere visione d'insieme alla pianificazione: bisogna capire bene cosa intenda Tullio e quindi come modificare il tutto.

  Potrebbe essere utile inviare una mail e/o fissare un incontro.

• [x] Casi d'uso: specificare meglio i casi d'uso per la gestione dei gaterway per renderli simili, per profondità di analisi, a quellli per la gestione dei dispositivi.

  Ricordarsi poi di aggioranare i requisiti, le fonti, il tracciamento e i test di sistema.

• [x] UC1: spostare la gerarchia da UC1.1 a UC1 stesso, rimuovendo il diagramma e portando ad un livello superiore tutti i sotto casi d'uso. Inoltre è necessario spostare le estensioni di UC1.1 in UC1.

• [x] UC1.3.3: rimuovere l'attore secondario Telegram, in quanto non aiuta in alcun modo all'inserimento del codice di autenticazione, ma serve solo ad inviarlo all'utente; infatti il caso d'uso riguarda solamento l'inserimento del codice, quindi Telegram non è coinvolto. Di conseguenza deve essere rimosso a casacata nei casi d'uso superiori.

• [x] UC14: modificare il caso d'uso lasciando il solo sotto caso UC14.1 e relative estensioni.

• [x] UC14.2: rimuovere il caso d'uso in quanto è un dettaglio implementativo e non una funzionalità offerta all'utente, come per l'autenticazione sulla web app.

• [x] RA-P-2: specificare meglio il requisito, definendo la struttura hardware dell'architettura, in termini di numero di nodi e di specifiche tecniche, e come i diversi componenti vengono messi in produzione sugli stessi (TODO dopo la progettazione).

Ricordarsi poi di aggioranare le fonti, il tracciamento e i test di sistema.

[lorenzodeinegri]

Registro delle modifiche

L'idea sarebbe la seguente:

• z: rimane invariata, quindi modifiche/aggiunte a/di singole sezioni, con contestuale verifica;
• y: utilizzata per l'approvazione del documento, in seguito ad una o più modifiche/aggiornamenti di sezioni "minori", quindi retrocompatibili;
• x: utilizzata per l'approvazione del documento, in seguito ad una o più modifiche/aggiornamenti profondi di sezioni o della struttura del documento stesso, quindi non più retrocompatibili con le versioni precedenti.

Gli scatti di versione di x e y devono essere in allineamento con le baseline di progetto.

Bisogna riportare nei registri delle modifiche gli incrementi di baseline anche se non è stata apportata alcuna modifica al documento?

[lorenzodeinegri]

Pianificazione

L'idea per dare una visione d'insieme alla pianificazione, e tenerne sotto controllo le risorse necessarie, è quella di individuare delle macro-fasi che vadano a comprende più incrementi temporalmente contigui. Gli incrementi raggruppati dal queste macro-fasi devono essere scelti in base a degli obiettivi di alto livello in relazione al prodotto e al capitolato, che possono essere quindi complementari e/o sovrapposti tra loro. Inoltre, ognuna di queste macro-fasi deve avere una propria pianificazione (diagrammi di Gantt), un proprio preventivo (tempi e costi) e un proprio consuntivo (tempi e cosi) con relative considerazioni e preventivo a finire.

[Maxelweb]

Domande ulteriori

• Cosa faremo per lo stage? Vedi mail di Tullio
• Come sarà l'esame? Medesimi contenuti ma in modalità telematica su un'apposita piattaforma.

Data la natura della RQ potrebbe essere spostato al 21 aprile

[Maxelweb]

Domande per Cradin 🍺 👶

• RA-P-2 , anche sentendo l'ultima lezione sulla architettura a microservizi, volevamo capire meglio come andare a definire il "deployment".

  Il sistema deve poter gestire un carico di almeno 30 utenti connessi contemporaneamente nella web app

Design pattern che abbiamo adottato

• A partire dalla nostra architettura, noi abbiamo 5 componenti, tra cui gateway con un device simulator, adapter per i database, servizio API e due applicazioni che comunicano con l'utente, ossia webapp e telegram bot.
• Rispetto quanto riportato a lezione, non abbiamo trovato particolari attinenze con le architetture a microservizi, pur usando di Kafka.
• Al massimo, ci è parso di avere una somiglianza con il centralized message topology, che fa uso del broker, ma in ogni caso noi facciamo anche uso delle API per le richieste di webapp e bot telegram, quindi ci pare più una architettura mista.
• E' corretto mantenersi su questa linea o rischia di essere un antipattern?

Design pattern per ogni componente

• Gateway: fa uso di un observer per le aggiornare le configurazioni
• API: usiamo lo Spring framework, che permette di sfruttare il dependency injection (es: istanze di classe per interfacciarsi coi database --> autowired)
• Webapp: usando Laravel, facciamo uso di MVC
• Per quanto riguarda telegram, il database adapter e il simulatore di dispositivi siamo un po' affranti perché non riusciamo a trovare dei design pattern sensati, dal momento che le loro funzionalità sono molto specifiche e limitate, in termini di dimensione.
• In molte parti delle componenti che comunicano con Kafka, facciamo uso del Object adapter per poter riadattare la comunicazione con Kafka in base alle nostre necessità (costruttore)
• Può bastare o conviene cercare meglio più design pattern?

Diagrammi da presentare per la PB

• Quali diagrammi dobbiamo presentare e di quali componenti?
• Dobbiamo poi riportarli tutti in modo ordinato nel manuale del manutentore, alla eventuale consegna del RQ?
• Per quanto riguarda le API, dobbiamo includere anche quelle col formato Swagger? Idem per il database con lo scherma ER?

Esame

• Come sarà l'esame?

[lorenzodeinegri]

RA-P-2

• Ogni requisito deve essere verificabile, quindi se non vengono messi dei vincoli minimi per il soddisfacimento ci si espone al rischio di ricevere rischieste insoddisfacibili da parte del proponente/committente
• Si può togliere il requisito, altrimenti vanno specificate per bene tutte le caratteristiche hardware che prevediamo di utilizzare

Architettura

• Microservizi che operano sulla base di eventi
• L'architettura ad eventi e quella a microservizi si differenziano per l'organizzazione aziendale
• In realtà ogni microservizio è un applicazione a sè stante che funziona da sola, poi componendo i vari microservizi si ottengono le funzionalità del sistema

  TODO: guardare event driven microservices architecture

Design Pattern

• Generale

  • Non bisogna cercare i design pattern, ma si intruducono solo quando vanno a risolvere dei problemi che vengono riscontrati nel far interagire le classi previste
  • Se le classi sono già coese e con basso accoppiamento, o comunque svolgono poche funzionalità limitate, non serve mettere dei design pattern che vanno solo ad aumentare la complessità generale

• Gateway

  • Al posto di Vanilla Kafka si poteva usare Spring Kafka
  • Il consumer deve scatenare un'azione, perché essendoci delle attività concorrenti c'è il rischi di creare inconsistenza
  • Il consumer legge i dati e quando gli arriva la configurazione fa partire un task su un thread, oppure in modo sincrono, per far aggiornare la configurazione

• API

  • Bisogna usare bene Spring

Manuale del manutentore

• Bisogna mettere tutte le informazioni per chi deve modificare o far evolvere il software
• Se le informazioni sono utili per chi deve mettere mano sul software, allora queste vanno messe nel manuale tramite un'opportuna contestualizzazione

PB

• 15 minuti in cui bisogna spiegare architetturalmente il software, quindi come è stato pensato e come viene sviluppato dal punto di vista architetturale
• C'è libertà assoluta per quanto riguarda i materiali da utilizzare per la presentazione, però non bisogna andare nè troppo nel dettaglio nè rimanere ad un livello troppo generale
• Non servono a nulla diagrammi delle classi con tutte le classi e moltissime associazioni
• Meglio avere dei diagrammi ristretti, che vadano a focalizzarsi sulle parti più salienti
• Architettura logica: quali sono le varie parti del sistema e come interagiscono

[lorenzodeinegri]

Ulteriori appunti riguardo le segnalazioni di Cardin

• I diagrammi dei package vanno fatti uno per componente per vedere bene le dipendenze tra classi
• Gli observer non sono da esplicitare, perché integrati nei framework, ma vanno saputi spiegare e motivare
• Bisogna usare una strategia bottom-up, partendo dalle classi, si fanno interagire tra loro e, se sorgono problemi, probabilmente c'è un design pattern che può aiutare a risolverli
• Il principio da utilizzare per i diagrammi dei package non importa, basta fare vedere bene le classi e le dipendenze
• I diagrammi delle attività vanno fatti solo per processi principali, quindi per cose che hanno bisogno di più spiegazione e se sono molto significative, altrimenti non servono
  • Per ogni diagramma non ci devono essere più di 8-10 azioni
• I diagrammi di sequenza vanno fatti solo per classi e metodi implementati in esse, quindi quando bisogna descrivere determinate operazioni mostrando bene tutti i passaggi temporali tra le varie classi
  • Vanno usati solo per cose importanti e rilevanti
  • Sono più importanti di quelli di attività