Domenico Giacomo Campanile - UNIVERSITÀ DEGLI STUDI ......Il crollo dei costi dell'hardware, la...

UNIVERSITÀ DEGLI STUDI DI MESSINA

DIPARTIMENTO DI MATEMATICA E INFORMATICA

Corso di Laurea Triennale in Informatica

Tesina di Ingegneria del Software

Anno Accademico 2015/2016

Docente: Prof. Antonio Puliafito Studente: Campanile Domenico Giacomo Matricola: 445794

TESINA INGEGNERIA DEL SOFTWARE !1

CAPITOLO 1

Indice Capitolo 1 Ingegneria del Software: Visione d’insieme pag. 3

1.1 Cenni di Storia “ 5

1.1.1 Gli anni pionieristici: 1950 – 1965 “ 5 1.1.2 Due anni importanti: 1968 – 1969 “ 6 1.1.3 Gli anni della maturità: 1970 – 1990 “ 6 1.1.4 Dal 1990 – Oggi “ 7

Capitolo 2 Sviluppo del Software pag. 8

2.1 Ciclo di vita “ 8

2.1.1 Modello a cascata “ 8 2.1.2 Modello a Spirale “ 9 2.1.3 Rational Unified Process (RUP) “ 11 2.1.4 Modello Incrementale o Interattivo “ 12 2.1.5 Modello Evolutivo “ 13 2.1.6 Modello Trasformazionale “ 13 2.1.7 Modello a Fontana “ 13 2.1.8 Metodologia Agile “ 13

2.2 Le Qualità del Software pag. 14

2.2.1 Correttezza “ 15 2.2.2 Affidabilità “ 15 2.2.3 Robustezza “ 15 2.2.4 Altre qualità del software “ 16

Capitolo 3 L’Autocad del Software: UML pag. 17

3.1 Utilità dell’UML “ 17 3.2 Diagrammi UML “ 19

3.2.1 Diagramma delle classi (Class Diagram) “ 19 3.2.2 Diagramma degli oggetti (Object Diagram) “ 19 3.2.3 Diagramma dei casi d'uso (Use case Diagram) “ 20 3.2.4 Diagramma di stato (State Diagram) “ 21 3.2.5 Diagramma di attività (Activity Diagram) “ 22 3.2.6 Diagramma di sequenza (Sequence Diagram) “ 22


CAPITOLO 1

Ingegneria del Software: Visione d’insieme “La creazione di software multiversione da parte di più operatori”

(D. Parnas, 1978)

La locuzione “Ingegneria del Software”, fu coniata verso la fine degli anni Settanta quando ci si rese conto che tutto ciò che si era appreso riguardo alle corrette tecniche di programmazione non aiutava a costruire sistemi software migliori. Dagli anni Settanta, l'ingegneria del software, è il settore dell'informatica che si occupa della creazione di sistemi software talmente grandi e complessi da dover essere realizzati da uno o più gruppi di ingegneri.

Parnas [1978] ha definito l'ingegneria del software come la “creazione di software multiversione da parte di più operatori”.

Questa definizione mette in risalto l'essenza dell'ingegneria del software e sottolinea le differenze tra programmazione e ingegneria del software. Un programmatore scrive un programma completo, mentre un ingegnere del software scrive un componente software che sarà poi combinato con altri componenti per creare un sistema.

Di seguito, vengono illustrate le caratteristiche tra uno sviluppo ingegneristico del software e quella che è la programmazione di un singolo programmatore:

Software Engineering Solo programmingsoftware grandi dimensioni software piccole dimensioni

team / teams singola persona

requisiti definiti dal cliente all’atto del contratto

requisiti definiti dal programmatore

molti componenti pochi componenti

molti cambiamenti, vita lunga costi elevati pochi cambiamenti, vita corta costi ridotti


CAPITOLO 1

Sviluppare un software non vuol dire, quindi, sviluppare un programma ma un sistema complesso costituito da tanti programmi e componenti hardware che collaborano tra di loro. Ad esempio, un sistema telefonico è composto da computer, telefoni, linee telefoniche e cavi, altri componenti hardware come i satelliti e infine da software che controlla i vari componenti. Il software diviene sempre di più la parte interna intelligente di vari sistemi, dalle televisioni agli aeroplani, in tal caso si parla di software embedded.

Tipologie di SoftwareTipologia Descrizione Esempi

Embedded

Sistemi elettronici di elaborazione a microprocessore progettati appositamente per una determinata applicazione ovvero non riprogrammabili dall'utente per altri scopi

Lettori di Musica Elettrodomestici

Smartphone

Stand alone

Oggetto o un software capace di funzionare da solo o in maniera indipendente da altri oggetti o software, con cui potrebbe altrimenti interagire.

Videoscrittura Navigazione Web

Process support Un'attività o una funzione che supporta le operazioni giorno per giorno di un'organizzazione

Contabilità Comunicazione Manutenzione

Vendite

Safety critical

Un computer , sistema elettronico o elettromeccanico il cui fallimento può provocare lesioni o morte per gli esseri umani . Strumenti comuni utilizzati nella progettazione di sistemi safety-critical sono ridondanza e metodi formali

Aerospaziale Militare Medico

Mission critical

Sono sistemi relativi a informazioni, attrezzature o altre risorse di un’impresa o di un progetto essenziali per la corretta operatività dell’organizzazione. I requisiti principali di questi sistemi sono la sicurezza dei dati, la massima disponibilità e la scalabilità delle prestazioni.

Banche Logistica


esempio di sistema telefonico

CAPITOLO 1

1.1 Cenni di Storia

La nascita e l'evoluzione dell'ingegneria del software come disciplina nel campo dell'informatica risale alla maturazione dell'attività di programmazione.

Agli albori dell'informatica, il problema principale della programmazione era come mettere insieme una sequenza di istruzioni per far in modo che il computer producesse qualcosa di utile.

Con la diminuzione dei prezzi dei computer e la loro diffusione, un numero sempre maggiore di persone iniziarono ad utilizzarlo. In questo periodo “programmare” divenne una professione: una persona poteva chiedere al programmatore di scrivere un programma, invece di realizzarlo per conto proprio.

Questo accordo introdusse una separazione tra utente e computer: l'utente specificava cosa voleva ottenere da una data applicazione utilizzando un linguaggio diverso dalla notazione di programmazione, il programmatore leggeva tale specifica e la traduceva in un insieme ben preciso di istruzioni macchina.

Nei primi anni Sessanta i progetti di software complessi furono veramente pochi e quei pochi furono intrapresi da pionieri del campo dell'ingegneria, che erano molto esperti. Un esempio è stato il sistema operativo CTSS sviluppato al MIT.

Nella seconda parte degli anni Sessanta, vi furono tentativi di creare grandi sistemi di software commerciali. Di questi progetti, quello meglio documentato fu il sistema operativo OS 360 per la famiglia di computer IBM 360.

1.1.1 Gli anni pionieristici: 1950 - 1965

In questi anni il software è sviluppato principalmente per singoli clienti; è di tipo batch e deve risolvere problemi spesso molto complessi. Gli informatici sono pochi e provenienti da altre discipline ingegneristiche o scientifiche. Le competenze informatiche si riducono alla conoscenza dei linguaggi di programmazione (linguaggio macchina). I progetti vedono il coinvolgimento di pochi programmatori (spesso uno solo) che sviluppano il codice senza produrre alcuna documentazione. Lo sviluppo del software si riduce dunque alla mera programmazione. Le uniche discipline applicate sono quelle degli algoritmi, delle strutture dati e dei linguaggi di programmazione.


un IBM 360/20

CAPITOLO 1

1.1.2 Due anni importanti: 1968 - 1969

La nascita ufficiale dell'Ingegneria del software avvia importanti studi e attività di ricerca nel campo delle metodologie, dei metodi e delle tecniche per il software. Si definisce una nuova disciplina su base teorica e scientifica portando l'Ingegneria del software alla stregua degli altri rami ingegneristici. La ricerca si sviluppa fondamentalmente su tre direttrici: una linea di ricerca approfondisce i temi legati agli aspetti organizzativi del software definendo ruoli, responsabilità e competenze della professione; un'altra linea si concentra sulle metodologie software (cicli di vita, processi, metodi, tecniche, metriche ecc.); la terza linea si concentra sulle tecnologie (sistemi operativi, sistemi gestionali, linguaggi di programmazione ecc.). Gli articoli e i libri pubblicati in questi anni costituiscono le basi della disciplina e sono ancora attuali.

1.1.3 Gli anni della maturità: 1970 - 1990

In questo periodo si assiste allo sviluppo di software per più utenti/clienti. Nascono i "pacchetti software" che offrono soluzioni preconfezionate rivolte a più utenti con la stessa necessità. I problemi non mancano nemmeno adesso: quello della "manutenzione del software" è il problema più importante! La diffusione del software aumenta in tutti i settori. Le esigenze degli utenti crescono con il crescere dell'utilizzo del software. Le metodologie definite dall'Ingegneria del software non si diffondono con la giusta attenzione. I metodi e le tecniche sono spesso ignorate. Le competenze si limitano alle tecnologie e il software prodotto necessita sempre più di manutenzione: spesso un affare per molti produttori di software. Il test e collaudo richiede grandi energie, materiali ed economiche, e la qualità del software non sempre risulta adeguata alle necessità. L'introduzione di nuove tecnologie (sistemi distribuiti, nuovi sistemi per la gestione dei dati, linguaggi di programmazione evoluti ecc.) e la riduzione dei costi dell'hardware spingono verso una diffusione sempre maggiore del software applicativo. Si effettuano analisi sulla difettosità del software e si definisce una "teoria della propagazione degli errori nel software". Con la programmazione ad oggetti (Object-Oriented) nasce l'innovazione che porterà, forse, ai maggiori cambiamenti nel modo di produrre software. Importanti sviluppi si hanno anche nella progettazione grafica delle interfacce utente (Graphical User Interface, GUI). L'usabilità del software si evolve anche grazie ai risultati delle ricerche di una disciplina collaterale all'Informatica, l'interazione uomo-macchina (Human-Computer Interaction, HCI).


CAPITOLO 1

1.1.4 Dal 1990 - Oggi

L'impulso maggiore all'evoluzione dell'Ingegneria del software è fornito, senza dubbio, dallo sviluppo delle tecnologie della Rete. Internet è, a tutti gli effetti, una delle maggiori rivoluzioni tecnologiche e culturali del nuovo millennio. Il crollo dei costi dell'hardware, la grande competitività tra le aziende software e l'uso del Web inducono l'Ingegneria del software a ridefinire i suoi principi: tecnologie, metodologie e culture. Internet e Open source rappresentano due pilastri imprescindibili che costringono tutti i produttori a ridefinire le proprie strategie. E lo sviluppo del software non può esimersi dall'adeguarsi a tali nuovi paradigmi.

In un articolo del 1987, Brooks, parafrasando Aristotele, sostenne che vi erano solo due tipi di sfide nello sviluppo del software: l'Essenziale e l'Accidentale.

Le difficoltà accidentali sono quelle che riguardano gli strumenti e le tecnologie correnti: ad esempio, i problemi sintattici che sorgono dal linguaggio di programmazione utilizzato. Si possono superare tali difficoltà con strumenti e tecnologie migliori.

Le difficoltà essenziali, invece, non sono generalmente superate con l'uso di nuovi strumenti. Problemi di progettazione complessa – ad esempio, la creazione di un modello utile per le previsioni atmosferiche e per l'economia – richiedono sforzo intellettuale, creatività e tempo.

[ Le spese mondiali per il software sono passate da 140 miliardi di dollari nel 1985 a 800 miliardi di dollari nel 2000. Solo questo basterebbe a dimostrare quanto l'ingegneria del software crescerà come disciplina ]


0

200

400

600

800

0

200

400

600

800

1950 - 1965 1968 - 1969 1970 - 1990 1990 - oggi

$

CAPITOLO 2

Sviluppo del Software “Vi sono solo due sfide nello sviluppo del software: l’essenziale e l’accidentale”

(F. P. Brooks, 1987)

2.1 Ciclo di vita

Il Software ha un ciclo di vita composto da varie fasi. A ciascuna di queste è associato lo sviluppo di una parte del sistema o di qualche elemento a questo legato come, ad esempio, un manuale per l'utente o un piano di test.

Nel modello tradizionale del ciclo di vita, chiamato “modello a cascata”, ogni fase ha un inizio e una fine ben definiti, con dei risultati parziali che vengono trasferiti a una ben identificata fase successiva.

2.1.1 Modello a cascata

Un modello a cascata è composto dalle seguenti fasi: 1. Analisi e specifica dei requisiti: Viene intrapresa dopo aver compiuto uno studio di

fattibilità per definire in modo preciso i costi e i benefici di un sistema software. Questo studio può essere compiuto dal cliente, dallo sviluppatore o da specialisti nell'analisi di mercato. Nei casi in cui i requisiti non siano chiari, è necessario che vi sia ampia interazione tra il cliente e lo sviluppatore. In questa fase i requisiti dovrebbero essere scritti impiegando terminologia comprensibile dall'utente finale, ma molte volte non è così.


CAPITOLO 2

2. Progettazione di sistema e sua specifica: Gli ingegneri del software progettano un sistema software che li soddisfi. Questa fase è divisa in due sotto fasi: il progetto architetturale e il progetto dettagliato.Il progetto architetturale affronta l'organizzazione globale del sistema in termini di componenti ad alto livello e delle loro interazioni. Man mano che ci si addentra in livelli di progettazione sempre più dettagliati, i vari componenti vengono scomposti in moduli a basso livello, con interfacce definite in modo accurato. Tutti i livelli di progettazione vengono indicati in un documento di specifica che fornisce informazioni sulle decisioni di progettazione prese. Scopo finale della fase di progettazione, è quella di giungere alla specifica di un particolare sistema software che soddisfi i requisiti dichiarati.

3. Codifica e test di modulo: L'ingegnere produce il codice che sarà consegnato al cliente sotto forma di un sistema funzionante. Bisogna notare che i singoli moduli creati nella fase di codifica vengono testati prima di passare alla fase successiva.

4. Integrazione e test di sistema: Tutti i moduli creati e testati singolarmente nella fase precedente vengono in questa assemblati, integrati, e testati come un unico sistema.

5. Consegna e manutenzione: Una volta che il sistema supera tutti i test, viene consegnato al cliente ed entra nella fase di manutenzione.

2.1.2 Modello a Spirale

Il Modello a spirale è un modello del ciclo di vita del software che consente di rappresentare i diversi cicli di vita per cui può essere visto come un metamodello. Per ovviare ai problemi dei modelli precedentemente sviluppati, è nata la metodologia a spirale (o iterativa) ancora oggi ampiamente utilizzata. Proposta da Barry Boehm nel 1988, scompone il processo di sviluppo in quattro fasi multiple, ciascuna ripetuta più volte. I capisaldi sono:

1. Pianificazione: Si determinano degli obiettivi, delle alternative e i vincoli associati al progetto. Il committente e il fornitore del sistema interagiscono allo scopo di definire in maniera sufficientemente univoca cosa deve essere realizzato e come. In questa fase è buona norma redigere dei documenti, in principio non eccessivamente dettagliati, che fissino i punti fondamentali della pianificazione del lavoro futuro.


CAPITOLO 2

2. Analisi dei rischi: Si identificano e si analizzano i problemi e i rischi associati al progetto, al fine di determinare delle strategie per controllarli. Tra i rischi che devono essere presi in considerazione si annoverano i fattori di costo, di tempo e di variazione delle specifiche.

3. Sviluppo: Si procede alla vera e propria realizzazione: i tempi di realizzazione di questa attività, che comprende sia la codifica sia la verifica, sono tra i più lunghi tra tutti quelli previsti all'interno del ciclo di vita del prodotto software.

4. Valutazione: Il committente valuta se il sistema realizzato risponde alle sue esigenze. Attraverso questa fase il committente verifica che il prodotto soddisfi effettivamente i requisiti richiesti.


CAPITOLO 2

2.1.3 Rational Unified Process (RUP)

Il Rational Unified Process è un modello di processo software iterativo sviluppato da Rational Software (oggi parte di IBM). Il RUP non definisce un singolo, specifico processo, bensì un framework adattabile che può dar luogo a diversi processi in diversi contesti. È pensato soprattutto per progetti di grandi dimensioni. Ogni fase ha un certo insieme di obiettivi e si conclude con la realizzazione di un deliverable (prodotto) di qualche genere. Le fasi sono ulteriormente scomposte in iterazioni, che sono associate a periodi temporali e hanno scadenze precise.

1. Fase iniziale: Si può considerare come una particolare elaborazione e precisazione del concetto generale di analisi di fattibilità. Lo scopo principale è quello di delineare nel modo più accurato possibile il business case, ovvero comprendere il tipo di mercato al quale il progetto afferisce e identificare gli elementi importanti affinché esso conduca a un successo commerciale.

2. Fase di elaborazione: Definisce la struttura complessiva del sistema. Questa fase comprende l'analisi di dominio e una prima fase di progettazione dell'architettura. Questa fase deve concludersi con il superamento dei seguenti criteri:

deve essere stato sviluppato un modello dei casi d'uso completo all’80%; deve essere fornita la descrizione dell'architettura del sistema; deve essere stata sviluppata un'"architettura eseguibile" che dimostri il completamento degli use case significativi; deve essere eseguita una revisione del business case e dei rischi; deve essere completata una pianificazione del progetto complessivo.


CAPITOLO 2

3. Fase di costruzione: Viene portato a termine il grosso degli sviluppi. Viene prodotta la prima release del sistema.

4. Fase di transizione: Il sistema passa dall'ambiente dello sviluppo a quello del cliente finale. Vengono condotte le attività di training degli utenti e il beta testing del sistema a scopo di verifica e validazione. Si deve in particolare verificare che il prodotto sia conforme alle aspettative descritte nella fase di Inception. Se questo non è vero si procede a ripetere l'intero ciclo;

5. Iterazioni: Tipicamente, un progetto gestito usando il RUP viene suddiviso in iterazioni. Questa scomposizione presenta numerosi vantaggi ma implica un overhead specifico. Il RUP definisce una "Project Management Discipline" (disciplina di gestione dei progetti) a cui il project manager può affidarsi per amministrare le iterazioni.

2.1.4 Modello Incrementale o Interattivo

Con Modello incrementale o modello iterativo, si intende, nell'ambito dell'ingegneria informatica, un modello di sviluppo di un progetto software basato sulla successione dei seguenti passi principali:

1. pianificazione 2. analisi dei requisiti 3. progetto 4. implementazione 5. prove 6. valutazione

Questo ciclo può essere ripetuto diverse volte, denominate "iterazioni", fino a che la valutazione del prodotto diviene soddisfacente rispetto ai requisiti richiesti. L'utilizzo del modello incrementale è consigliabile quando si ha, fin dall'inizio della progettazione, una visione abbastanza chiara dell'intero progetto, perché occorre fare in modo che la realizzazione della generica versione k risulti utile per la realizzazione della versione k+1. Un approccio incrementale è particolarmente indicato in tutti quei casi in cui la specifica dei requisiti risulti particolarmente difficoltosa e di difficile stesura (semi)formale. L'uso di questo modello di sviluppo favorisce la creazione di prototipi, ovvero parti di applicazione funzionanti, che a loro volta favoriscono il dialogo con il cliente e la validazione dei requisiti.


CAPITOLO 2

2.1.5 Modello Evolutivo

Il Modello evolutivo è uno dei modelli del ciclo di vita del software che cerca di superare i limiti principali del modello a cascata. Si basa sulla prototipizzazione che consiste nell'uso di specifici strumenti software per la realizzazione rapida di una versione semplificata del sistema informativo, con la quale sperimentare le sue funzionalità. La verifica del prototipo può portare a una modifica dei requisiti e una eventuale revisione del progetto. È un modello costituito da poche fasi che si ripetono

A. Costruisci qualcosa B. Consegnalo all’utente C. Ottieni delle valutazioni D. Modifica il progetto

2.1.6 Modello Trasformazionale

Il processo di sviluppo viene visto come una trasformazione graduale di una specifica in un’implementazione. Attraverso maggiori approfondimenti le specifiche si chiariscono e migliorano per diventare esse stesse prototipo evolutivo. Le fasi, quindi, sono due:

A. Analisi e specifica dei requisiti B. Ottimizzazione.

2.1.7 Modello a Fontana

Il Modello a fontana è un modello di sviluppo altamente iterativo, che ben si sposa con lo sviluppo del software con metodologie orientate agli oggetti, è particolarmente adatto a grandi progetti sviluppati da un gran numero di persone, specialmente se questi progetti riguardano prodotti “mission critical” che non possono fallire (programmi per il controllo del traffico aereo).

2.1.8 Metodologia Agile

I metodi agili si contrappongono al modello a cascata e altri processi software tradizionali, proponendo un approccio meno strutturato e focalizzato sull'obiettivo di consegnare al cliente, in tempi brevi e frequentemente, software funzionante e di qualità. Fra le pratiche promosse dai metodi agili ci sono la formazione di team di sviluppo piccoli, cross-funzionali e auto-organizzati, lo sviluppo iterativo e incrementale, la pianificazione adattiva, e il coinvolgimento diretto e continuo del cliente nel processo di sviluppo.


CAPITOLO 2

2.2 Le Qualità del Software

Esistono molte qualità desiderabili per il software, alcune si applicano sia al prodotto che al processo utilizzato per il suo sviluppo. L'utente richiede che il prodotto software sia affidabile, efficiente e facile da usare. Il produttore del software desidera che sia verificabile, manutenibile, portatile ed estendibile. Il manager di un progetto software desidera che il processo di sviluppo sia produttivo, prevedibile e facile da controllare.

Possiamo dividere le qualità del software in due categorie: interne ed esterne. Le qualità esterne sono visibili agli utenti del sistema mentre le qualità interne riguardano gli sviluppatori. In molti casi le qualità sono strettamente correlate e la distinzione tra qualità interne ed esterne non è così marcata.

Tra le principali qualità del software, troviamo la Correttezza, l'Affidabilità e la Robustezza.


CAPITOLO 2

2.2.1 Correttezza

Un programma è funzionalmente corretto se si comporta secondo quanto stabilito nelle specifiche funzionali. La definizione correttezza assume che le specifiche del sistema siano disponibili e che sia possibile determinare in maniera non ambigua se un programma soddisfi le specifiche. La correttezza è una proprietà matematica che stabilisce l'equivalenza tra il software e la sua specifica. Ovviamente, possiamo essere tanto più sistematici e precisi nel valutare la correttezza quanto più rigorosi siamo stati nello specificare i requisiti funzionali. La correttezza di un programma si può valutare mediante vari metodi, alcuni basati su un approccio sperimentale, altri basati su un approccio analitico, come le ispezioni del codice.

2.2.2 Affidabilità

Il software è considerato affidabile nella misura in cui l'utente può farne affidamento sulle sue funzionalità. La letteratura specializzata definisce l'affidabilità in termini statici, ovvero come la probabilità che un software operi come atteso in un intervallo di tempo determinato. La correttezza è una qualità assoluta: una qualunque deviazione rispetto a quanto stabilito rende un sistema non corretto. La notazione di affidabilità è invece relativa. Se la conseguenza di un errore software non è grave, un software non corretto può continuare a essere considerato affidabile.

2.2.3 Robustezza

Un programma è robusto se si comporta in modo accettabile anche in circostanze non previste nella specifica dei requisiti, per esempio quando vengono inseriti dati di input non corretti o in presenza di malfunzionamenti hardware. Un programma non è robusto se assume dati di ingresso perfetti e genera un errore non recuperabile durante l'esecuzione, qualora l'utente prema inavvertitamente un tasto sbagliato.


CAPITOLO 2

2.2.4 Altre qualità del software

Usabilità: Gli utente reputano il software facile da utilizzare (user friendly);

Verificabilità: Procedere facilmente alla verifica della correttezza e delle prestazioni;

Manutenibilità: Indica le modifiche effettuate su un software dopo il suo rilascio iniziale;

Riparabilità: Un sistema software è riparabile se i suoi difetti possono essere corretti con una quantità ragionevole di lavoro;

Portabilità: Il software è portabile se può essere eseguito in ambienti diversi;

Interoperabilità: Si riferisce alla capacità di un sistema di coesistere e cooperare con altri sistemi;

Produttività: Qualità del processo di produzione del software, ne indica l'efficienza e le prestazioni;

Tempestività: Qualità del processo che indica la capacità di rendere disponibile un prodotto al momento giusto;

Visibilità: Un processo di sviluppo del software è visibile se tutti i passi successivi e lo stato attuale sono documentati in modo chiaro;


CAPITOLO 3

L’Autocad del Software: UML

Nel mondo costantemente in fermento ed in evoluzione come quello dello sviluppo di applicazioni Object Oriented, diviene sempre più difficile costruire e gestire applicazioni di alta qualità in tempi brevi. Come risultato di tale difficoltà e dalla esigenza di avere un linguaggio universale per modellare gli oggetti che potesse essere utilizzato da ogni industria produttrice di software, fu inventato il linguaggio UML, la cui sigla sta per Unified Modeling Language. In termini pratici, potremmo dire che il linguaggio UML rappresenta, in qualche modo un progetto di ingegneria edile riportato nel mondo dell’Information Technology. L’UML è, dunque, un metodo per descrivere l’architettura di un sistema in dettaglio. Come è facile intuire, utilizzando un progetto iniziale, sarà molto più facile costruire un sistema e assicurarsi che il sistema stesso si presterà senza troppe difficoltà a futuri cambiamenti dei requisiti. La forza dell’Unified Modeling Language consiste nel fatto che il processo di disegno del sistema può essere effettuata in modo tale che i clienti, gli analisti, i programmatori e chiunque altro sia coinvolto nel sistema di sviluppo possa capire ed esaminare in modo efficiente il sistema e prendere parte alla sua costruzione in modo attivo.

3.1 Utilità dell'UML L'UML non è altro che il progetto che un costruttore segue per costruire per esempio un'abitazione. E' impensabile costruire un palazzo senza un solido progetto iniziale da seguire fedelmente. Capito quindi, nella pratica cosa è l'UML, vediamo i principali punti di forza del linguaggio:

- L'UML è un linguaggio molto semplice da imparare e molto intuitivo e ciò consente un rapido apprendimento di tutte le metodologie più importanti. Inoltre è estremamente più semplice leggere uno schema di un'applicazione fatto in UML piuttosto che leggere il codice sorgente dell'applicazione stessa. Infatti la lettura dello schema UML permette una rapida comprensione delle varie funzionalità e tutte le relazioni tra i vari oggetti che la compongono, tutto ciò anche senza una conoscenza approfondita dell'UML. Situazione opposta è la lettura di codice sorgente di un'applicazione con un gran numero di classi: ciò richiede sicuramente molto più tempo rispetto alla lettura di uno schema UML e richiede un elevatissima conoscenza del linguaggio in cui l'applicazione è stata scritta.


CAPITOLO 3

- La modifica di uno schema UML è più semplice rispetto ad una modifica da apportare ad un codice sorgente già scritto. Infatti molti dei bug che i software presentano sono dovuti ad un'errata fase di progettazione, che ha portato i programmatori a modificare la struttura del programma in fase di scrittura del codice.

UML consente di descrivere un sistema secondo tre aspetti principali. Ciascuno ha un insieme di tipi di diagrammi specifici.

1. Il modello funzionale rappresenta il sistema dal punto di vista dell’utente, ovvero ne descrive il suo comportamento così come esso è percepito all’esterno, prescindendo dal suo funzionamento interno. Questo tipo di modellazione serve nell’analisi dei requisiti. La modellazione funzionale utilizza gli Use Case Diagram.

2. Il modello a oggetti rappresenta la struttura e sotto struttura del sistema utilizzando i concetti object-oriented di classe, oggetto, le relazioni fra classi e fra oggetti. Questo tipo di modellazione può essere utilizzata sia nella fase di analisi del dominio che nelle varie fasi di progetto a diversi livelli di dettaglio. Utilizza class diagram, object diagram, e deployment diagram.

3. Il modello dinamico rappresenta il comportamento degli oggetti del sistema, cioè le dinamiche delle loro interazioni. È strettamente legato al modello a oggetti e viene impiegato negli stessi casi. Utilizza i sequence diagram, gli activity diagram e gli statechart diagram.


CAPITOLO 3

3.2 Diagrammi UML

3.2.1 Diagramma delle classi (Class Diagram)

E' il diagramma più importante nella modellazione UML e rappresenta la struttura intera del nostro progetto. Come dice la parola stessa, il diagramma delle classi, rappresenta le varie classi presenti collegate tra di loro dalle rispettive relazioni. Proprio grazie al diagramma delle classi è possibile tradurre il progetto modellato in progetto concreto con la stesura del codice. Ma che cosa rappresenta una classe? Una classe identifica un insieme di oggetti che hanno simili proprietà e compiono simili azioni.

3.2.2 Diagramma degli oggetti (Object Diagram)

Molto simile al diagramma delle classi; in questo diagramma vengono rappresentati gli oggetti, ovvero le istanze concrete di una classe, e le varie relazione presenti. E' un diagramma di tipo statico, ovvero è un diagramma che rappresenta il sistema in un certo istante di tempo ed è una sorta di fotografia della struttura del sistema nel momento dello scatto. Per questo motivo diagrammi degli oggetti ad istanti differenti potranno differire sia


CAPITOLO 3

per numero di oggetti presenti sia per i valori relativi agli attributi di un oggetto. Ipotizziamo infatti di voler modellare una chat internet: avremo presumibilmente una classe server e una utente. Il diagramma degli oggetti all'inizio del processo vedrà presente solo un unico oggetto, l'oggetto Server, mentre se eseguissimo una modellazione ad istanti successivi avremo sicuramente, oltre all'oggetto Server anche vari oggetti Utente che sono connessi . Data la sua dipendenza dal tempo non è un diagramma troppo utilizzato.

3.2.3 Diagramma dei casi d'uso (Use case Diagram)

Questo tipo di diagramma è molto utile per modellare il funzionamento dinamico di una certa funzionalità del sistema. Uno dei vantaggi di questi diagrammi è il fatto di essere estremamente semplici da leggere anche da chi non ha esperienze di UML in quanto sono molto intuitivi. Per fare un esempio pratico di diagramma di un caso d'uso potrebbe essere quello di modellare l'azione di prelievo di soldi da uno sportello di una banca: l'utente inserisce la carta, selezione la funzionalità "prelievo", inserisci il pin relativo alla carta, digita l'importo, prende i soldi e ritira la carta.


CAPITOLO 3

3.2.4 Diagramma di stato (State Diagram)

E' il diagramma utilizzato per mostrare il comportamento di un determinato sistema. E' molto utile per mostrare come un sistema si comporta in relazione ad input ricevuto da un utente. Per riallacciarsi all'esempio del prelievo di soldi potremo fare un digramma di stato dello sportello bancomat: inizialmente lo sportello si trova nello stato di "wait", poi appena l'utente inserisce la carta si passa nello stato "ready", a seconda dell'input si passa ad un altro stato e così via. In questi diagrammi è buona norma rappresentare anche le situazioni di errore come per esempio la situazione in cui l'utente sbagli per tre volte il pin in quel caso si entrerà, per esempio, nello stato "trattieni carta" per poi passare nuovamente allo stato di "wait" in attesa di un'altra operazione.


CAPITOLO 3

3.2.5 Diagramma di attività (Activity Diagram)

Il diagramma viene utilizzato per mostrare le varie attività che vengono eseguite per espletare una determinata funzione prevista dal sistema. Questo diagramma è utilizzato, principalmente, per mostrare i vari passi che un algoritmo, di qualsiasi genere, compie prima di produrre il risultato atteso. Se il sistema da progettare implementa algoritmi abbastanza complessi, conviene sempre creare un diagramma delle attività per non compiere errori di progettazione.

3.2.6 Diagramma di sequenza (Sequence Diagram)

E' un diagramma che per certi versi è legato al diagramma dei casi d'uso. Il diagramma di sequenza mostra le varie azioni compiute dall'utente e dal sistema quando viene richiesto un determinato servizio, mostrando tutte le interazioni tra i due e tra eventuali sotto-sistemi.


Domenico Giacomo Campanile - UNIVERSITÀ DEGLI STUDI ......Il crollo dei costi dell'hardware, la...

Documents

Transcript of Domenico Giacomo Campanile - UNIVERSITÀ DEGLI STUDI ......Il crollo dei costi dell'hardware, la...