Estratto del documento

Ingegneria del software introduzione

L’ingegneria del software è, per definizione, l’applicazione di un approccio sistematico, disciplinato e quantificabile dello sviluppo, funzionamento e manutenzione del software. Il software è l’insieme delle procedure, della documentazione associata e dei dati relativi all’operatività del sistema. L’ingegneria del software è invece la disciplina che riguarda lo sviluppo e la manutenzione di un prodotto software entro un certo tempo e un certo costo limitati. Più sinteticamente ancora, possiamo dire che l’ingegneria del software tratta il ciclo di vita del software. Il ciclo di vita del software è l’insieme delle attività utili a realizzare, rilasciare e mantenere il software. L’ingegneria del software, essendo tale, fa uso anch’essa di un approccio ingegneristico.

Approccio ingegneristico

  • Analisi e specifica dei requisiti: L’analisi identifica l’obiettivo da raggiungere e produce una specifica dei requisiti.
  • Progettazione: Si occupa di realizzare un metodo di risoluzione del problema.
  • Sviluppo: È la realizzazione dell’algoritmo prodotto dalla progettazione.
  • Testing: È la verifica del sistema realizzato.

Sviluppo ed evoluzione

Inizialmente, la procedura dello sviluppo del software veniva presa senza considerare la parte della progettazione. Prendeva infatti il nome di “code and fix”. Successivamente, come per la produzione di un qualsiasi prodotto, è nata la necessità di creare un processo produttivo. Questo processo è basato sul ciclo di vita del software. Il ciclo di vita infatti, è formato da vari artefatti, ossia delle versioni del software che conducono a risultati parziali.

  • Definizione: Stabilisce il cosa deve essere fatto dal software. Indica quindi a grandi linee i requisiti, i risultati attesi, il comportamento del sistema, le interfacce ecc., senza però considerare come questi fattori verranno poi realizzati.
  • Sviluppo: Stabilisce come deve essere realizzato il software. Si occupa quindi della definizione del progetto, dell’architettura software, della realizzazione del software a partire dal progetto (programmazione) e del collaudo.
  • Manutenzione: Si occupa delle modifiche a cui il software viene sottoposto dopo il rilascio.

I fattori di qualità del software

Il software, come la maggior parte dei prodotti, è sottoposto a delle valutazioni che ne indicano la qualità complessiva. Queste valutazioni, vengono fatte prendendo in considerazione dei fattori di qualità. I fattori di qualità del software sono suddivisibili in due grandi categorie:

  • Black box: Visibili dall’utente finale
  • White box: Visibili dagli sviluppatori

I fattori di qualità WB sono un metodo per realizzare le qualità BB. Molto spesso i vari fattori di qualità si influenzano tra loro. Un’altra classificazione dei fattori di qualità del software è:

  • Del processo: Metodo con il quale ricavo il prodotto
  • Del prodotto

Correttezza

Un software si dice corretto se soddisfa tutti i requisiti funzionali. Un requisito funzionale è un requisito che corrisponde ad una funzionalità che il software deve realizzare. Ad esempio, un requisito non funzionale potrebbe essere quello di far riportare al software un risultato in un determinato intervallo di tempo.

Affidabilità

Rappresenta la probabilità che il software operi come atteso in un determinato intervallo di tempo. A differenza della correttezza, l’affidabilità è una qualità relativa perché ammette degli scostamenti dal servizio atteso. La correttezza invece, è una qualità assoluta, in quanto non ammette scostamenti dal servizio atteso (O funziona o no, non ci sono vie di mezzo). Considerando l’ipotesi che la specifica dei requisiti contenga tutte le proprietà richieste dall’utente, si potrebbe affermare che l’affidabilità contiene la correttezza. Questo non è vero in ogni caso, perché il software potrebbe soddisfare tutti i requisiti funzionali, ma non soddisfare i bisogni dell’utilizzatore, ad esempio operando in un intervallo di tempo maggiore a quello prestabilito.

Robustezza

Un software è robusto se si comporta in maniera accettabile anche di fronte a situazioni non specificate nei requisiti, come ad esempio di fronte ad input non corretti. Non è da equivocare con la correttezza. Infatti, se si potesse dire specificamente cosa fare per rendere un software robusto, la robustezza e la correttezza sarebbero lo stesso fattore di qualità. La linea di demarcazione tra correttezza e robustezza sono i requisiti.

Prestazioni

Sono una qualità esterna (recepita dall’utente). Queste sono basate sull’utilizzo dell’utente e sull’utilizzo efficiente delle risorse (tempo di esecuzione, memoria occupata). Sono diverse dall’efficienza, che vedremo dopo.

Efficienza

È una qualità interna, che verifica il corretto utilizzo delle risorse da parte del software. Spesso l’efficienza influenza le prestazioni. Efficienza e prestazioni possono essere valutate tramite tre approcci differenti:

  • Misuristico: Basato su un sistema reale
  • Analitico: Basato su un sistema astratto, utile in fase di progettazione quando non è ancora stato implementato il sistema.
  • Simulativo: Basato su un sistema simulativo costruito ed eseguito appositamente.

Usabilità

È una qualità soggettiva in quanto indica la facilità di utilizzo del software da parte degli utilizzatori. Gran parte di questa qualità è influenzata dalla presenza e dalla realizzazione delle interfacce.

Verificabilità

Un software è verificabile se è semplice verificare la sua correttezza, ossia se i suoi requisiti funzionali sono implementati.

Manutenibilità

Indica la facilità e l’economicità dei processi di manutenzione del software. Non bisogna mai dimenticare che i costi di manutenzione occupano circa il 60% del costo totale del software. Ci sono vari tipi di manutenzione:

  • Correttiva: Consiste nell’eliminazione di eventuali errori residui.
  • Adattiva: Consiste nella modifica dell’applicazione per adattarla ad eventuali cambiamenti dell’ambiente (Ad esempio uscita di un nuovo sistema operativo).
  • Perfettiva: Consiste nell’aggiunta, modifica o eliminazione di caratteristiche o funzionalità del software (È la manutenzione che costa più di tutte).

La manutenibilità può essere vista come l’unione di altri due fattori di qualità.

Riparabilità

Indica la semplicità relativa alla riparazione o alla rimozione di difetti dal software.

Evolvibilità

Indica la semplicità relativa all’inserimento di nuove funzionalità all’interno del software. Questo fattore di qualità richiede una grande attenzione in fase di progettazione, in cui bisogna prevedere già eventuali evoluzioni del software, e costruirlo in modo da non renderle proibitive quando, in futuro, si vorranno applicare.

Riusabilità

Indica la capacità dei singoli moduli costituenti il software di essere riutilizzati per la realizzazione di nuovi prodotti.

Portabilità

Indica la possibilità del software di essere eseguito in diversi ambienti.

Comprensibilità

Indica la capacità del software di essere compreso al fine di verificarne la correttezza, di apportare modifiche e di riusarlo.

Visibilità

Si riferisce ai processi software. Questi devono essere accessibili (disponibili e verificabili). Ciò richiede una documentazione chiara.

Interoperabilità

È la capacità di coesistere e cooperare con altri sistemi. Un concetto correlato è quello di sistema aperto, che a differenza di quello chiuso, non è di tipo proprietario. I sistemi aperti hanno alta interoperabilità.

Produttività

Indica prestazioni ed efficienza del software.

Tempestività

Indica la capacità di rendere il prodotto finale disponibile in un tempo fissato. Richiede una attenta pianificazione del processo. È ottenibile tramite la consegna incrementale del prodotto, ossia una consegna continua di diverse versioni del prodotto, ovviamente sempre più avanzate e complete nel tempo.

I principi dell'ingegneria del software

Sono dei principi generali e astratti, che ispirano il processo software o metodi e tecniche utilizzati in alcune fasi. L’individuazione di metodi e tecniche affidabili per un certo procedimento adeguato alla soluzione del problema è lo scopo della metodologia. Metodologie, metodi e tecniche fanno uso di strumenti che ne facilitano l’applicazione.

Rigore

È necessario a realizzare il processo in maniera corretta, fornendo precisione e accuratezza. Il livello più alto del rigore è il formale.

Formalità

La formalità è il livello più alto del rigore, ossia si basa su procedimenti matematici. Non è sempre necessario basare lo sviluppo del processo sulla formalità, in quanto vi sono alcuni casi in cui è meglio utilizzare un rigore più basso. La formalità è utile a garantire l’automazione. Infatti, dei requisiti formali, possono portare alla generazione automatica del codice. Anche il codice stesso è formale, in quanto si basa su sintassi e semantica ben definite.

Separazione degli interessi

Permette di risolvere il problema concentrandosi su tanti piccoli problemi separatamente. Aiuta a ridurre drasticamente la complessità. Vi sono vari tipi di separazione di interessi:

  • Separazione temporale: È alla base del modello del ciclo di vita del software.
  • Separazione dei fattori di qualità: Considerandone e valutandone uno alla volta, verificando se sono rispettati o meno.
  • Separazione di viste diverse: Ad esempio considerare separatamente il flusso dei dati e quello di controllo.
  • Separazione di parti del sistema: Capacità di affrontare diverse parti del sistema separatamente.
  • Separazione di domini: Separare gli aspetti del dominio del problema, dominio della soluzione e dominio dell’implementazione.

La separazione degli interessi può essere utile alla suddivisione dei ruoli di un’azienda.

Differimento delle decisioni

Ogni decisione deve essere presa a tempo debito, in modo da non andare a influenzare quelle successive. Ad esempio, la scelta del linguaggio di programmazione da utilizzare per la realizzazione di un sistema software, non deve essere antecedente all’analisi dei requisiti, a meno che non rappresenti un vincolo dettato dal committente.

Astrazione

L’astrazione è il processo che porta ad astrarre alcune proprietà di un’entità, nascondendone i dettagli inessenziali, tenendo conto sempre dei diversi punti di vista, cioè quale dettaglio è inessenziale, ma soprattutto per chi lo è. Ogni astrazione dà luogo ad una vista. Ad esempio, considerando un’automobile, un’astrazione utile al venditore deve includere il prezzo, la durata della garanzia, il colore ecc., mentre un’altra astrazione utile ad un meccanico deve includere caratteristiche del motore, olio ecc. L’astrazione può essere vista come un particolare tipo di separazione degli interessi.

Modularità

È la separazione di un modello o di un sistema in varie parti più piccole dette moduli, in modo che siano più semplici da gestire. Praticamente tutti i sistemi complessi sono modulari. La modularità viene applicata ad ogni modulo finché non si arriva ad un problema risolvibile.

Modulo

Un modulo di un sistema software è un componente che realizza un’astrazione ed è dotato di una netta separazione tra:

  • Interfaccia: Ciò che è reso visibile dall’astrazione
  • Corpo: Come è realizzata l’astrazione

Una classe con parte privata (Corpo), e parte pubblica (Interfaccia) è un esempio di modulo.

Incapsulamento e information hiding

L’incapsulamento è un metodo per nascondere e proteggere alcuni aspetti di un sistema. L’accesso alle informazioni nascoste è dettato dall’interfaccia. Se questa non cambia, possono essere modificate le informazioni nascoste senza che vengano influenzate le altre caratteristiche del sistema. Prendiamo ad esempio un telecomando. I tasti che noi vediamo su di esso rappresentano l’interfaccia di esso, infatti ogni tasto corrisponde ad una determinata azione interna che noi utilizzatore non conosciamo, e soprattutto non abbiamo bisogno di conoscere per avviare o utilizzare lo strumento in questione.

Tipologie di astrazione

L’incapsulamento è un particolare tipo di astrazione, e come tale può essere classificata in vari modi:

  • Astrazione sui dati: Astrae le entità (oggetti) del sistema. Questa può essere applicata tramite metodi di programmazione modulare e soprattutto è supportata da varie funzionalità della programmazione a oggetti.
  • Astrazione sul controllo: Astrae una funzionalità dai dettagli della sua implementazione. È supportata dalla maggior parte dei linguaggi di programmazione tradizionali tramite il concetto di sottoprogramma.

Tipologie di modulo

Le tipologie di astrazione danno luogo a diversi tipi di modulo.

  • Procedura o funzione: Applicano l’astrazione sul controllo (Astrazione procedurale). Implementa delle operazioni ed incapsula un algoritmo.
  • Libreria: Applicano un’astrazione procedurale. Rappresentano un insieme di funzioni.
  • Oggetti: Applicano un’astrazione sui dati. È formato da struttura dati e operazioni. Hanno una struttura dati permanente visibile solo tramite funzioni interne, quindi il dato è nascosto.
  • Tipo di dato astratto: Esporta un tipo oltre che le operazioni possibili (Classe).

Esistono anche altre tipologie di modulo, meno usate e importanti di quelle elencate precedentemente.

  • Pool di dati: Un insieme di dati relativi ad una certa funzione, che verranno utilizzati nel momento in cui è in azione la funzione relativa. Ad esempio, un pool di dati di configurazione, viene chiamato in causa durante la fase della configurazione, che accede ai dati e li utilizza. Ha un livello di astrazione molto basso, in quanto non nasconde nulla.
  • Moduli generici: Sono dei veri e propri template di moduli. Sono caratterizzati ognuno dal tipo di dato a cui appartengono, infatti per essere utilizzati devono necessariamente essere prima istanziati.

I benefici della modularità

  • Utile per domare la complessità
  • Utile per eventuale suddivisione del lavoro
  • Utile per la manutenzione
  • Utile per il riuso dei moduli creati
  • Utile per l’analisi di un sistema in relazione alle sue parti

Coesione e accoppiamento

Ovviamente la suddivisione in moduli non presenta solo vantaggi. La scomposizione del sistema in diversi moduli deve essere fatta in maniera appropriata, cercando di evitare che questi siano troppo dipendenti l’uno dall’altro, ma allo stesso tempo non devono essere completamente separati. Quindi bisogna raggiungere una soddisfacente: Alta coesione e basso accoppiamento per massimizzarne i benefici.

Alta coesione

Se tutti gli elementi del modulo (Funzioni, istruzioni, dichiarazioni) sono logicamente ben coesi. Ciò significa che gli elementi sono raggruppati in un modulo per un motivo logico e cooperano per la realizzazione della funzionalità richiesta.

Basso accoppiamento

L’accoppiamento misura la relazione tra moduli diversi. Il basso accoppiamento indica che due o più moduli hanno un buon livello di separazione. In questo modo è più semplice analizzare, modificare, estendere, riparare o testare singoli moduli, senza che il nostro intervento vada ad influenzare gli altri moduli.

Metodologie di progetto

Top down

È una decomposizione funzionale del sistema software, da iterare continuamente finché non si raggiunge un livello di complessità più facilmente gestibile. Si passa quindi dal problema più grande a quello più piccolo, per questo top down, cioè dall’alto al basso.

Bottom up

Consiste nell’identificazione delle entità del sistema, delle loro operazioni e delle loro interrelazioni. Il sistema viene creato assemblando i suoi componenti dal basso verso l’alto.

Le relazioni tra moduli

Uses

Il modulo M1 uses il modulo M2 se richiede la presenza di M2 per portare a termine il suo compito. Valutando il fan-in (archi entranti nel modulo) ed il fan-out (archi uscenti dal modulo) si hanno indicazioni sulla buona modularizzazione. Bisogna infatti avere un basso fan-out e alto fan-in.

Is component of

Il modulo M2 is component of il modulo M1 se il modulo M1 è composto da uno o più moduli, incluso il modulo M2.

Comprises

M1 comprises M2 se M2 is component of M1. È la relazione inversa di “is component of”.

Anticipazione del cambiamento

La possibilità che in futuro il software possa essere modificato deve essere sempre prevista, per questo vi è bisogno di una corretta progettazione del software. Per facilitare il cambiamento, come abbiamo visto, si può ricorrere alla modularizzazione, che deve essere eseguita correttamente, per far sì che il sistema sia flessibile e facilmente adattabile.

Anteprima
Vedrai una selezione di 14 pagine su 62
Lezioni, Ingegneria del software Pag. 1 Lezioni, Ingegneria del software Pag. 2
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 6
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 11
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 16
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 21
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 26
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 31
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 36
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 41
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 46
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 51
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 56
Anteprima di 14 pagg. su 62.
Scarica il documento per vederlo tutto.
Lezioni, Ingegneria del software Pag. 61
1 su 62
D/illustrazione/soddisfatti o rimborsati
Acquista con carta o PayPal
Scarica i documenti tutte le volte che vuoi
Dettagli
SSD
Ingegneria industriale e dell'informazione ING-INF/05 Sistemi di elaborazione delle informazioni

I contenuti di questa pagina costituiscono rielaborazioni personali del Publisher KekkoV94 di informazioni apprese con la frequenza delle lezioni di Ingegneria del Software e studio autonomo di eventuali libri di riferimento in preparazione dell'esame finale o della tesi. Non devono intendersi come materiale ufficiale dell'università Università degli studi di Napoli Federico II o del prof Russo Stefano.
Appunti correlati Invia appunti e guadagna

Domande e risposte

Hai bisogno di aiuto?
Chiedi alla community