Progettazione del software

Appunti di progettazione software

A cura di Christian Di Pietro

Matricola 557

Anno 2020/21

Lezione 1 - Introduzione all'analisi e progettazione del software

Il software oggi

Il software è presente ovunque con un ruolo rilevante ed è sempre più complesso. C'è in banca, sul volo dell'aereo. Tutte le comunicazioni sono controllate dal software. La realizzazione pone delle sfide formidabili agli sviluppatori. Gli obiettivi per un sistema software sono: fornire funzionalità e gestire alcuni tipi di informazioni, con opportune caratteristiche di qualità come la sicurezza, correttezza, affidabilità e prestazioni.

L'attività di progettazione è fondamentale. Questa scompone (a livelli diversi di granularità) il software da realizzare in sottoinsiemi software indipendenti che però interagiscono tra di loro attraverso le relazioni.

Analisi e progettazione

Analisi e progettazione sono attività correlate tra di loro ma distinte. Analisi è interessata all'investigazione di un problema e dei requisiti dello stesso. Risponde alla domanda: CHE COSA? L'analisi dei requisiti ad esempio è interessata a capire quali sono i modi di utilizzo che dovrà gestire il sistema.

La progettazione è interessata a trovare una buona soluzione che risolva i problemi e soddisfi i requisiti. Risponde alla domanda COME è fatto?

Analisi orientata agli oggetti (OOA)

L'analisi orientata agli oggetti (OOA) si basa sull'identificazione dei concetti del dominio del problema. La classe rappresenta un insieme di oggetti del mondo reale. In UML è rappresentata da un rettangolo diviso in più parti. La parte superiore contiene il nome della classe, la parte inferiore gli attributi e i metodi.

Progettazione orientata agli oggetti (OOD)

Nella progettazione orientata agli oggetti (OOD) si basa sull'identificazione di oggetti software che collaborano per soddisfare i requisiti. Non ci interessano quali sono gli oggetti del mondo reale ma gli elementi software che parteciperanno alla soluzione. Le istanze sono oggetti software usati per rappresentare gli oggetti del mondo reale. Vanno assegnate delle responsabilità (operazioni).

Programmazione orientata agli oggetti (OOP)

Nella programmazione orientata agli oggetti (OOP) riguarda l'implementazione delle classi software scelte durante la fase della progettazione (ad esempio con una classe java).

UML: Unified Modeling Language

La modellazione è un'attività fondamentale nell'analisi e progettazione software. UML è un linguaggio visuale standard per la descrizione di sistema software. Questo facilita il lavoro dello sviluppatore. Un modello è una semplificazione della realtà che descrive un sistema da un particolare punto di vista. Contiene delle astrazioni e contiene gli aspetti considerati fondamentali durante un'attività. È usato sia per la modellazione di sistemi software ma può essere usato per modellazione di processi.

In UML ci sono 14 diagrammi che si dividono in strutturali e comportamentali.

Diagrammi strutturali

Diagrammi che mostrano un insieme di oggetti, classi in un istante di tempo. Ci dà un punto di visto statico. Es. Diagramma delle classi o diagrammi degli oggetti.

Diagrammi comportamentali

Enfatizzano un punto di vista dinamico ovvero mostrano l'interazione tra gli oggetti invocando le operazioni. Esempi sono i diagrammi di sequenza o di comunicazioni.

Prospettive per utilizzare UML

• Concettuale: non rappresenta oggetti software ma dei concetti della realtà di interesse (ad esempio una macchina). È rilevante nell'analisi del software.
• Specifica software: utilizzati per rappresentare elementi software e le loro relazioni. È rilevante nella progettazione OOD e OOP (ad esempio per rappresentare una classe java).
• Implementazione software: utilizzati per descrivere le classi software con una determinata tecnologia (java).

Tipi di approcci nell'uso di UML

• UML come abbozzo: Diagrammi informali abbozzati spesso su una lavagna, usati per esplorare parti complesse del problema o della soluzione. È quello consigliato nella modellazione agile.
• UML come progetto: Diagrammi dettagliati utilizzati per il reverse-engineering o per la generazione di codice. In entrambi i casi esistono dei software che generano automaticamente il sorgente (ad esempio in java) da un UML e viceversa. Lo sviluppatore può eventualmente aggiungere codice aggiuntivo successivamente.
• UML come linguaggio di programmazione: è un approccio ancora in via di sviluppo. Il codice viene generato in automatico dal diagramma e non viene né modificato né visto dagli sviluppatori.

Esempio di progettazione

Analisi requisiti: capire quali sono i requisiti del sistema. Sia quelli funzionali (il modo di utilizzo) e quelli non funzionali (le qualità desiderate). Per rappresentare i requisiti funzionali usiamo i casi d'uso. Sono storie scritte.

Analisi orientata agli oggetti: quali sono le tipologie di informazioni da gestire, le operazioni da consentire agli utenti ed il comportamento associato a quelle operazioni. La modellazione viene fatta tramite il modello delle informazioni del dominio.

Qui ci sono le classi rappresentate da rettangoli, le associazioni rappresentate da linee e gli attributi che sono i dati delle classi.

Progettazione orientata agli oggetti: ha lo scopo di identificare le classi software e le relazioni tra queste. Quali sono le classi da scrivere? Le variabili? I metodi? I diagrammi di interazione ci aiutano in questa fase. Ci sono anche i diagrammi delle classi di progetto (statico). È utilizzato dal punto di vista software.

L'ultima fase è la programmazione del software scrivendo le classi java.

Lezione 2 - Sviluppo iterativo

Processo software

Il processo utilizzato per lo sviluppo del software, essendo un'attività molto complessa, richiede un approccio sistematico, metodico ed ingegneristico per la costruzione il rilascio e la manutenzione dello stesso. Il processo definisce chi fa che cosa, come e quando, per raggiungere un certo obiettivo. Il “che cosa” sono le singole attività, il “chi” riguarda i ruoli associati alle persone, il come riguarda le metodologie (esempio progettazione concettuale DB), il quando riguarda l'organizzazione temporale delle attività (processo a cascata, a spirale, evolutivo).

Attività fondamentali

• Analisi dei requisiti: le caratteristiche funzionali e non funzionali
• Progettazione: Capire quali saranno le parti che costituiranno il prodotto software
• Implementazione: Scrittura del software
• Validazione e verifica: riguarda la correttezza rispetto agli obiettivi (comprende tutti i vari test automatizzati)
• Rilascio: l'installazione e messa in opera del sistema
• Manutenzione ed evoluzione: correttiva ed evolutiva
• Gestione del progetto: attività trasversale che si occupa del coordinamento di queste attività

Differenze nei processi software

Si differenziano nel “quando”, ovvero nel determinare l'ordine delle attività e nei criteri di transizione tra un'attività e l'altra.

Processo a cascata

Processo di sviluppo classico nato tra gli anni 60 e 70. Si basa sul voler definire nel dettaglio tutti i requisiti prima di iniziare la programmazione e di definire un piano “affidabile” del progetto più o meno all'inizio dello stesso. Ma spesso all'inizio queste informazioni nemmeno si conoscono con esattezza. Le operazioni vengono svolte in sequenza una dopo l'altra. Quando viene raggiunta la fine di un'attività (ed approvata) si può passare alla fase successiva.

Le attività sono: Pianificazione, analisi, progettazione, codifica, collaudo, rilascio.

Questo approccio deriva dagli approcci classici dell'ingegneria (costruzione del ponte). Ha una percentuale elevata di fallimento, una bassa produttività, percentuali errori alti. La causa principale del fallimento sta nel fatto che si dà per scontato che i requisiti non cambino durante la durata del progetto. Si è potuto vedere con il tempo invece che, nei progetti software, il cambiamento medio dei requisiti è del 25% con punte del 50% nei progetti più grandi. Per questo è poco efficace ed è difficile gestire errori fatti nella parte iniziale (analisi dei requisiti), il costo per sistemare questi errori in una fase avanzata è alto. Inoltre, i rischi sono gestiti tardi. Si è visto che tempi e costi riscontrati alla fine del progetto possono variare fino al 400% rispetto alle stime iniziali.

Sviluppo evolutivo

È un approccio in cui l'idea di base è quella di realizzare un'implementazione iniziale del sistema, presentarla agli utenti (che ci forniscono il loro feedback) e poi raffinarla con le modifiche che faranno parte delle varie versioni successive (con funzionalità via via crescenti). Questo finché non si arriva al sistema desiderato.

Sviluppo iterativo o incrementale

È una forma particolare di sviluppo evolutivo, lo sviluppo del software è organizzato in mini progetti di 2-4 settimane chiamate iterazioni. Il MIP dice che lo sviluppo iterativo è un fattore critico di successo. Le singole iterazioni comprendono parte dell'analisi dei requisiti, parte della progettazione, molta implementazione e test, si fa una dimostrazione, si ottiene il feedback e si procede. Il risultato della singola iterazione deve essere un software eseguibile, testato ed integrato (anche se parziale) che possa essere presentato agli utenti. È importante sottolineare che il risultato di una singola iterazione non è un prototipo sperimentale ma un sottoinsieme del sistema finale, in cui la qualità del codice è a livello produzione. Le idee alla base di questo metodo sono quella di anticipare nel tempo alcune attività (almeno in parte). Rimandare nel tempo altre attività (quelle con valore minore), in tutto ciò bisogna massimizzare i benefici e minimizzare i rischi.

I vantaggi sono la minor probabilità di fallimento del progetto, riduzione precoce dei rischi maggiori, miglior produttività, percentuale di difetti bassa, visibilità del progresso, assenza della “paralisi da Analisi”, apprendimento riutilizzabile iterazione per iterazione.

Pratiche dello sviluppo iterativo

• Time boxing: Ogni iterazione ha una durata prefissata. Questi devono essere né troppo brevi né troppo lunghi. Quelli brevi non danno il tempo di avere evolutive significative, quelli lunghi fanno passare troppo tempo per il feedback. Se ci si rendesse conto che il carico di lavoro è troppo per il tempo stimato occorre spostare funzioni nell'iterazione successiva piuttosto che far ritardare la scadenza.
• Pianificazione iterativa: ovvero l'organizzazione del lavoro nella prossima iterazione. Bisogna capire quali delle cose che rimangono da fare inserire nella successiva iterazione. Questa scelta può essere guidata dal rischio (affrontare prima quelli maggiori) o guidata dal cliente (sulla base di quella con valore maggiore). Lo sviluppo guidato dal rischio comprende quello centrato sullo sviluppo dell'architettura (questa infatti è definita come un fattore ad alto rischio).

Il backlog è uno strumento importante nella pianificazione iterativa. Questo contiene tutte le operazioni arretrate da fare. In ciascuna iterazione faccio il grooming del backlog, assegno una priorità alle attività rimanenti, le ordino per priorità e affronto prima quelle a maggiore priorità. In un'iterazione solitamente il tempo dedicato all'analisi e progettazione è il 10%/15%, l'80% invece è dedicato allo sviluppo software ed al test, la restante parte si verifica che tutti i requisiti siano stati rispettati (retrospective) e si fa la dimostrazione. Solitamente anche a metà iterazione si fa una piccola verifica sullo stato del lavoro.

Una forma particolare è lo sviluppo agile. Questo incoraggia pratiche per una reazione rapida e fluida al cambiamento.

Unified Process

È uno specifico processo per lo sviluppo del software di tipo iterativo. È basato su un certo numero di pratiche tra cui:

• Sviluppo evolutivo ed incrementale
• Sviluppo guidato dal rischio
• Sviluppo dell'architettura nelle prime fasi
• Gestire i requisiti ed il loro cambiamento
• Coinvolgimento continuo degli utenti
• Applicare i casi d'uso
• Modellare in modo visuale (UML)
• Tecnologia ad oggetti
• Verifica continua delle qualità del sistema.

Fasi del processo unificato

Nel processo unificato le singole iterazioni sono raggruppate per fasi. Queste sono:

• Ideazione: è solitamente costituita da una singola iterazione. Ha lo scopo di trovare un accordo tra le parti del sistema. Si fa qui lo studio economico e si decide se vale la pena iniziare lo sviluppo. Si inizia l'analisi dei requisiti.
• Elaborazione: si applicano tutte le tecniche di analisi e progettazione. Ha lo scopo da un lato di realizzare lo scheletro dell'architettura, ovvero capire quali sono tutte le parti e come interagiscono tra di loro e implementare ciò. Si iniziano a sviluppare le funzionalità principali e si affrontano i rischi principali. Comprendere la maggior parte dei requisiti e stimare in modo accurato i tempi di realizzazione ed i costi.
• Costruzione: è la fase più lunga. Il suo scopo è quello di implementare tutte le altre funzionalità del sistema. I rischi più importanti sono già stati affrontati e risolti. Bisogna finire di comprendere i requisiti rimasti o quelli cambiati.
• Transizione: comprende poche iterazioni. Il suo scopo è quello di testare il sistema per rilasciarlo al cliente e metterlo in funzione.

Disciplina e elaborato

La Disciplina è l'insieme delle attività e dei relativi elaborati relative ad una determinata area (es. Disciplina dei requisiti che comprende attività come analisi dei requisiti e definizione di modelli come quello dei casi d'uso). Altre discipline importanti sono la progettazione e l'implementazione. L'elaborato invece è un prodotto di lavoro che interessa una disciplina. L'elaborato dell'implementazione è il software finale.

Il lavoro dedicato nelle varie fasi varia in funzione del tempo. Questo è descritto dalle curve. L'analisi dei requisiti ad esempio ha un impatto maggiore nell'elaborazione e va poi via via scemando.

Lezione 3 - Requisiti e casi d'uso

Requisiti

Un requisito è una capacità o condizione a cui il sistema software deve essere conforme. L'attività di analisi ci dice le caratteristiche che deve avere il sistema per soddisfare le aspettative delle parti interessate. Deve fornire quindi un valore aggiunto. Questo viene fatto in una forma che parli chiaramente al cliente ed ai membri del team di sviluppo. La gestione è un approccio alla ricerca, analisi, organizzazione, documentazione, validazione e verifica. I requisiti possono cambiare. Le percentuali sono dal 20% al 35%. Questo perché o sono stati espressi male, percepiti male o perché cambiano gli interessi.

Modello FURPS+

I Requisiti sono divisi in categorie in base al modello FURPS+. L'acronimo sta per:

• Functional: Caratteristiche funzionali, capacità che il sistema deve avere.
• Usability: Fattori umani e documentazione
• Reliability: Affidabilità in termini di ripristinabilità e frequenza al fallimento
• Performance: Tempo di risposta, precisione, disponibilità
• Supportability: Adattabilità, manutenzionabilità, configurabilità.
• +: Implementazione, interfacce, vincoli fisici, vincoli legali, contesto operativo.

Più in generale, tutti i requisiti si dividono in funzionali e non funzionali (o di qualità). Quelli funzionali riguardano il modo in cui il sistema è utilizzato e rappresentano la F del modello FURPS+. Quelli non funzionali riguardano le qualità che il sistema fornisce, come sicurezza, flessibilità, prestazioni, scalabilità e sono tutte le altre lettere del modello FURPS+.

Elaborati dei requisiti in UP

Gli elaborati (opzionali) che riguardano i requisiti in UP sono essenzialmente 5:

• Modello dei casi d'uso: scenari tipici dell'utilizzo del sistema (usato per i requisiti funzionali);
• Specifiche supplementari: Raccoglie tutti i requisiti non funzionali e le caratteristiche funzionali non espresse.
• Glossario: Definisce i termini e significati come un vero e proprio dizionario dei dati
• Visione: Riassume i requisiti ad alto livello e uno studio economico.
• Regole di Business: Sono le caratteristiche legate al contesto dell'azienda, come le leggi fiscali.

Casi d'uso

Sono storie scritte, testuali, che raccontano come gli utenti possono raggiungere i loro obiettivi usando il sistema. Sono utili per individuare e descrivere i requisiti funzionali. Sono facilmente comprensibili sia dagli utenti finali che dagli esperti software. Possono essere espressi a diversi livelli di dettaglio.

Attori nei casi d'uso

Un attore è qualcosa (un sistema) o qualcuno (una persona) dotato di comportamento che interagisce con il sistema in discussione. Esistono 3 tipi di attori:

• Attore Primario: Raggiunge gli obiettivi utente sfruttando i servizi del sistema (cassiere)
• Attore di supporto: Offre un servizio al sistema ed è utile per identificare interfacce esterne (sistema carte credito).
• Attore fuori scena: Ha interesse sul comportamento (ente governativo per le tasse)

Lo scenario (o istanza) è una sequenza specifica di azioni e interazioni tra sistema e attori. Possono essere di successo (se raggiunge l'obiettivo) e no. I casi d'uso sono l'insieme di molti scenari. Due scenari fanno parte dello stesso caso d'uso se si tratta dello stesso attore che vuole raggiungere lo stesso obiettivo.

Il procedimento corretto per la definizione dei casi d'uso è quello di scrivere uno scenario principale (solitamente di successo), gli altri scenari sono detti scenari alternativi. Questi non sono completi ma descrivono una diramazione temporanea dallo scenario principale.

Possiamo avere diversi livelli di dettaglio dei...