Ingegneria del Software

Principi di progettazione REST

URI;

Utilizza soltanto i metodi HTTP: le operazioni CRUD che si possono fare su una risorsa, si basano sull'utilizzo esplicito dei metodi GET, PUT, POST e DELETE del protocollo HTTP;

Risorse autodescrittive: le risorse di per sé sono concettualmente separate dalle rappresentazioni restituite al client. I principi REST non pongono nessun vincolo sulle modalità di rappresentazione di una risorsa. Virtualmente possiamo utilizzare il formato che preferiamo senza essere obbligati a seguire uno standard;

Collegamenti tra risorse: le risorse devono essere messe in relazione tramite link ipertestuali. Questo principio è anche noto come HATEOAS, dall'acronimo di Hypermedia As The Engine Of Application State;

Comunicazione Stateless: questa è infatti una delle caratteristiche principali del protocollo HTTP, cioè ciascuna richiesta non ha alcuna relazione con le richieste precedenti e successive. La principale ragione di questa scelta è

Semplificare e standardizzare i processi di documentazione di API per servizi web RESTful. Swagger prevede 2 componenti: uno Swagger Editor ed uno Swagger UI:

Esempio di interfaccia grafica di Swagger.

Il cuore di Swagger consiste in un file testuale (in formato sia YAML che JSON) dove sono descritte tutte le funzionalità di un'applicazione web, i parametri di ingresso e le risposte in output, in un formato studiato per essere interpretabile correttamente sia dagli umani che dalle macchine. Lo Swagger Editor offre una serie di vantaggi, fra cui:

• Una migliore e più condivisibile esplorazione delle funzionalità di un'applicazione.
• Possibilità di generare codice client/server in diversi linguaggi di programmazione sfruttando la descrizione inserita nell'editor.
• Funzionalità di supporto nella stesura del documento, come ad esempio il completamento automatico e la validazione automatica del testo scritto in tempo reale.

1.7. Design

Patterns

Un Design Pattern è uno schema di progettazione, può essere definito come una "soluzione generale ad un problema ricorrente", esso rappresenta un modello logico da applicare alla soluzione di un problema che appunto può manifestarsi in diverse situazioni durante le fasi di modellazione e sviluppo del software. Dato che i problemi che si possono incontrare nello sviluppare grossi progetti software sono ricorrenti e prevedibili, si fa uso dei design pattern che sono degli schemi utilizzabili nel progetto di un sistema e permettono di non inventare da capo soluzioni a problemi già risolti, ma di usare questa sorta di "mattoni", che già sono stati testati e usati. L'introduzione dell'uso dei pattern in informatica si deve al celebre libro "design patterns: Elements of reusable object-oriented software" di Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides. Gli autori vennero identificati col tag grassetto.

Il termine "Gang of Four GoF" è un soprannome introdotto in architettura da Christopher Alexander e poi è stato applicato all'ingegneria del software.

I vantaggi dell'uso dei pattern sono:

• Aumento di riutilizzabilità del software;
• Aumento della velocità di sviluppo;
• Aumento della flessibilità del software;
• I patterns forniscono un vocabolario comune che facilita la comunicazione fra più progettisti, per questo sono facili da riconoscere per il progettista ed aiutano a comprendere con maggiore immediatezza i programmi scritti da altri;
• Aiutano a documentare l'architettura software;
• Descrivono astrazioni software, cioè sono astratti così da poter essere compresi da progettisti con punti di vista differenti;
• Non si applicano solo alla progettazione Object Oriented ma anche ad altri domini.

Lo svantaggio è che a volte il loro utilizzo può rendere la struttura del codice più complessa.

• Pattern Name and Classification: Un nome unico e descrittivo che permette di identificare e riferirsi ai patterns.
• Intent (scopo): Una breve descrizione dell'obiettivo che ha spinto alla creazione del pattern e le ragioni per utilizzarlo. Specifica cosa fa il pattern e a cosa serve.
• Also Known As (sinonimi): Altri nomi per il pattern.
• Motivation (Forces) motivazione: Un problema e un contesto in cui il pattern può essere usato.
• Applicability (applicabilità): Situazioni in cui il pattern può essere usato (contesto).
• Structure: Una rappresentazione grafica della struttura generica del pattern. Spesso sono usati i diagrammi.

Analysis Patterns:

Questi pattern sono specifici per il dominio dell'analisi dei requisiti e aiutano a modellare concetti comuni e ricorrenti in un determinato dominio.

Design Patterns:

Questi pattern sono generali e possono essere applicati a diversi domini. Aiutano a risolvere problemi di progettazione comuni e forniscono soluzioni testate e comprovate.

Architectural Patterns:

Questi pattern riguardano l'organizzazione e la struttura di un sistema software a livello architetturale. Forniscono linee guida per la progettazione di sistemi complessi e scalabili.

Behavioral Patterns:

Questi pattern si concentrano sul comportamento degli oggetti e sulle interazioni tra di loro. Aiutano a definire come gli oggetti comunicano e collaborano per raggiungere determinati obiettivi.

Creational Patterns:

Questi pattern si occupano della creazione di oggetti in modo flessibile e riutilizzabile. Forniscono un'alternativa alla creazione diretta di oggetti e consentono di delegare la creazione a classi specializzate.

Structural Patterns:

Questi pattern si concentrano sulla composizione di classi e oggetti per formare strutture complesse. Aiutano a definire le relazioni tra gli oggetti e a organizzare il codice in modo modulare e riutilizzabile.

Esprimono schemi riguardanti la descrizione del dominio e non si interessano del linguaggio di programmazione e dell'implementazione.

Architectural Patterns: I pattern architetturali operano ad un livello diverso (e più ampio) rispetto ai design pattern, ed esprimono schemi di base per impostare l'organizzazione strutturale di un sistema software. In questi schemi si descrivono sottosistemi predefiniti insieme con i ruoli che essi assumono e le relazioni reciproche.

Design Patterns: I design pattern possono essere classificati con diversi criteri, i più comuni dei quali sono quelli che evidenziano il tipo di problema che si cerca di risolvere.

Process Patterns: definiscono i processi di sviluppo software.

Noi ci concentreremo sui design pattern. I design pattern possono essere classificati con diversi criteri, i più comuni dei quali sono quelli che evidenziano il tipo di problema che si cerca di risolvere. Distinguiamo le seguenti

macrocategorie:

• Creational Pattern: Risolvono problemi inerenti l'istanziazione degli oggetti, astraendo il più possibile il come vengono creati questi ultimi, cioè nascondendo i costruttori delle classi usando delle interfacce al loro posto.
• Structural Pattern: Gestiscono la separazione tra interfaccia e implementazione e le modalità di composizione tra oggetti utilizzando il concetto di ereditarietà.
• Behavioral Pattern: Questi schemi di progettazione riguardano specificamente la comunicazione tra oggetti, essi consentono la modifica del comportamento degli oggetti minimizzando le necessità di cambiare il codice.
• Concurrency Pattern: usati nel caso di processi che operano contemporaneamente su dati condivisi, indicando metodi di sincronizzazione.

Nella figura seguente è mostrata una classificazione dei principali design pattern:

Vengono descritti adesso qualcuno dei più famosi Design Patterns.

301.7.1. Composite

È uno Structural Design

Pattern basato su oggetti che viene utilizzato quando si ha la necessità di realizzare una gerarchia di oggetti in cui l'oggetto contenitore può detenere oggetti elementari e/o oggetti contenitori. L'obiettivo è di permettere al Client che deve navigare la gerarchia, di comportarsi sempre nello stesso modo sia verso gli oggetti elementari e sia verso gli oggetti contenitori, in tal modo:

• Definisce la gerarchia: Gli oggetti della gerarchia possono essere composti da oggetti semplici e/o da oggetti contenitori che a loro volta sono composti ricorsivamente da altri oggetti semplici e/o da oggetti contenitori.
• Semplifico il client: il Client tratta gli oggetti semplici e gli oggetti contenitori nello stesso modo. Questo semplifica il suo lavoro il quale astrae dalla specifica implementazione.
• Semplifica la modifica dell'albero gerarchico: l'alberatura è facilmente modificabile aggiungendo/rimuovendo foglie e contenitori senza dover

modificare tutto il resto. Questo pattern è composto dai seguenti