Ingegneria del softwarePrima parte

2018 Andrea Oian

Possiamo assolutamente dire che l’economia di tutte le nazioni è arrivata ad un punto in cui dipende quasi totalmente dai software, infatti sempre più sistemi sono controllati dai suddetti; infatti le spese in software rappresentano una buona parte delle spese sostenute dai paesi più evoluti. Nonostante questa crescita lo sviluppo del software presenta non poche difficoltà: infatti molto spesso il problema legato l’ambito è difficile (ovvero la sua applicazione) e lo è anche la sua soluzione, il processo di sviluppo è difficile da gestire. Oltre a questi lati negativi per ce ne sono in risposta molti positivi, infatti il software ha il vantaggio di essere molto flessibile e di essere un sistema discreto. In particolare quando ci si approccia allo sviluppo del software esistono quattro momenti fondamentali, ovvero: 1. Problem solving: ovvero creare una soluzione di seguito progettare un sistema basato sulla

soluzione che abbiamo creato. 2. Modelling; 3. Acquisizione di conoscenza; 4. Gestione razionale; In particolare nella prima fase ci sarà un momento dedicato all’analisi, ovvero un momento dedicato alla comprensione della natura del problema e della sua scomposizione in problemi più semplici. In seguito ci sarà una sintesi che consisterà nella composizione delle soluzioni dei micro problemi in cui abbiamo suddiviso il nostro problema principale. Per ottimizzare tutte le fasi dello sviluppo occorre che siano date delle regole e definizioni che saranno composte da una serie di tecniche e metodologie che porteranno alla creazione di software di alta qualità attenendosi al budget assegnato, rispettando le scadenze e offrendo la possibilità di modifiche in corso d’opera. Ma quali sono queste tecniche, metodi e strumenti ? • Tecniche: Procedure formali che danno risultati a partire da notazioni ben definite. • Metodologie: Insieme di tecniche applicate attraverso lo sviluppo del software unificate da un

approccio filosofico. • Strumenti: Strumenti o sistemi automatizzati che realizzino una tecnica. COSTI RELATIVI AL SOFTWARE: Molto spesso i costi relativi al software sono quelli più alti quando si sviluppa un sistema informatico, quindi il costo del software è maggiore di quello dell’hardware. In particolare il software risulta essere più costoso nel suo mantenimento piuttosto che nel suo sviluppo, infatti, in sistemi con una lunga vita, la manutenzione arriva a costare molto di pi del suo costo di sviluppo. Una delle prerogative dell’ingegneria del software è di sviluppare software con un costo più basso possibile. Le tecniche di sviluppo del software ci aiutano a costruire sistemi più grandi e più complessi, in particolare vogliamo che i sistemi siano sviluppati e consegnati sempre più velocemente, che siano sempre più ampi e complesse e che i sistemi integrino funzioni sempre più avanzate rispetto alle versioni precedenti. Se il software non viene sviluppando seguendo i criteri dettati dall’ingegneria del software, questo risulterà essere più costoso e meno affidabile dei competitor che sfruttano questi principi. CHE COS’È IL SOFTWARE? Il software è definito come l’associazione di programmi per computer, documentazione e requisiti, modelli di design e manuali d’utente. Il software pu essere sviluppato per un singolo cliente o per un mercato più vasto, da cui si suddivide in software generico: che viene sviluppato per essere venduto a una base composta da vari clienti, ad esempio excel o word. Oppure pu essere custom o personalizzato: ovvero che viene sviluppato per un singolo cliente in base alle richieste specifiche di quest’ultimo. Un software pu essere creato sviluppando nuovi programmi, configurando sistemi basati su software generico o riutilizzando un software esistente.

CHE COS’È UN SISTEMA? E’ una raccolta mirata di componenti interconnessi che lavorano insieme per raggiungere un obiettivo comune. Pu includere software, hardware elettrico o meccanico che pu essere usato

2018 Andrea Oian

da persone. I suoi componenti sono dipendenti dagli altri componenti del sistema. Le sue proprietà e comportamenti dei suoi componenti sono mescolati inestricabilmente. Ci possono essere due tipologie di sistemi: • Techincal computer-based systems: Ovvero sistemi che sono composti da hardware e

software, ma in cui gli operatori e i processi operazionali non sono considerati parte del sistema.

• Socio-technical systems:Sistemi che includono i technical systems ma che includono anche i processi operazionali e le persone che usano e interagiscono con il sistema tecnico.

COSTI DELL’INGEGNERIA DEL SOFTWARE: I costi dello sviluppo in genere si aggirano attorno al 60%, mentre il restante 40% è attribuito ai costi relativi ai testing. Quando ci troviamo di fronte ad un software custom, molto spesso i costi di evoluzione sono addirittura superiori ai costi di sviluppo. Il costo pu variare a seconda del tipo di sistema che si andrà a sviluppare e in base alle specifiche e ai requisiti come ad esempio le performance e l’affidabilità del sistema. Possiamo identificare delle variazioni di costi a seconda del modello di sviluppo che viene adoperato.

Metodi di ingegneria del software: Sono degli approcci strutturati per lo viluppo del software che comprendono la descrizione grafica dei modelli che stiamo producendo, le regole da applicare per i modelli di sistema. GOOD SOFTWARE ATTRIBUTES: • Maintainability: ovvero il software deve essere in grado di evolversi e di andare incontro alle

necessità che si presentano. • Dependability: Ovvero il software deve essere affidabile; • Efficiency: Il software non deve sprecare le risorse che gli vengono fornite dal sistema; • Acceptability: Il software deve essere accettato dagli utenti per cui è stato progettato, questo

significa che deve essere comprensibile, utilizzabile e compatibile con gli altri sistemi con cui verrà usato.

Le sfide chiave nell’ingegneria del software sono: • L’eterogeneità: ovvero lo studio di tecniche per sviluppare software che possa far fronte ad

un insieme eterogeneo di piattaforme e poi ambienti esecutivi. • Consegna: Sviluppo di tecniche che portino ad una consegna più veloce del software al

cliente. • Fiducia: Ovvero sviluppare tecniche che dimostrino agli utenti che possono far affidamento

sul software.

TIPI DI APPLICAZIONI: • Applicazioni Stand-Alone: Sistemi applicativi che vengono eseguiti su computer locali, ad

esempio su un personal computer (PC); Includono al loro interno tutte le funzionalità necessarie e non richiedono la connessione ad un network;

• Applicazioni interattive transaction-based: Sono applicazioni che vengono eseguite su un computer remoto e permettono l’accesso agli utenti tramite il loro PC o attraverso terminali; Questa categoria include le applicazioni web come ad esempio le applicazioni di e-commerce.

• Sistemi di controllo integrato: Sono sistemi di controllo software che controllano e gestiscono dispositivi hardware, numericamente ci sono più sistemi embedded di qualsiasi altro tipo id sistema.

• Sistemi di elaborazione batch: Sistemi nell’ambito business che sono progettati per processare grandi pacchetti di dati, ovvero processano grandi quantità di dati in input per fornire un corrispondente output.

• Sistemi di intrattenimento: Sistemi che sono usati maggiormente per uso personale, che hanno come scopo quello di intrattenere l’utente.

• Sistemi di modelling e di simulazione: Sono sistemi che sono sviluppati da scienziati e ingegneri per modellare processi o situazioni fisiche, che comprendono molti oggetti che interagiscono tra di loro.

2018 Andrea Oian

• Sistemi di acquisizione dati: Sistemi che acquisiscono dati dal loro ambiente circostante, usando un set di sensori che a loro volta mandano i dati raccolti ad altri sistemi per essere elaborati.

• Sistemi di sistemi: Sistemi che sono a loro volta composti da un certo numero di altri sistemi software.

DEFINIZIONE DI PROCESSO SOFTWARE: é un insieme di attività strutturate che vengono richieste per sviluppare un sistema software. Queste attività comprendono: la specificazione, il design, la convalida e l’evoluzione. Un modello di processo software è una rappresentazione astratta di un processo. Contiene una descrizione di un processo da un a prospettiva particolare. I due modelli di modellazione software più usati sono il modello a cascata e il modello incrementale. Il modello a cascata risulta essere un modello rigido, in cui vi è una netta separazione tra la specificazione e lo sviluppo. Mentre nel modello incrementale i processi di specificazione e sviluppo sono tra di loro interfogliati, questo modello pu avere una dinamica più agile rispetto al modello a cascata. Un modello di sviluppo rigido è caratterizzato dalla suddivisione del processo di sviluppo in fasi distinte. I risultati che vengono prodotti ad ogni fase sono pianificati in anticipo, e tra una attività e l’altra pu presentarsi dell’iterazione.

Un modello di sviluppo agile invece è caratterizzato dall’interfogliamento delle fasi di specificazione, design, implementazione e testing. Gli output ottenuti dal processo di sviluppo sono decisi in corso di sviluppo attraverso una negoziazione durante il processo di sviluppo.

Modello a cascata: • Analisi dei requisiti e definizioni : Servizi di

sistema, vincoli e obiettivi sono stabiliti assieme agli utenti del sistema.

• i requisiti sono in seguito definiti in modo che siano comprensibili sia dagli utenti che dal team di sviluppo.

2018 Andrea Oian

• Questa fase può essere suddivisa in sotto fasi: - studio della fattibilità; - analisi dei requisiti; - definizione dei requisiti; - specificazione dei requisiti;

DESIGN DEL SOFTWARE E DEL SISTEMA: vengono definiti uno o più modelli di sistema, in particolare il modello rappresenta il sistema con diversi livelli di dettaglio. Questa fase può essere suddivisa in due attività principali: 1. Design dell’architettura: in cui vengono identificati i componenti hardware e software che

andranno assemblati tra di loro. In più viene definita una architettura generale; 2. Design dettagliato: Rappresentazione delle funzioni software di sistema in modo che

possano essere trasformate in uno p più programmi eseguibili;

PROGRAMMAZIONE DELLE UNITÀ E TESTING: In questa fase i componenti di sistema che sono stati definiti nella fase precedente sono implementati e testati. Questa fase pu essere divisa in due momenti: 1. I componenti sono realizzati come un set di programmi o come unità di programma. Questi

vengono scritti in maniera molto specifica oppure vengono presi altrove o adattati da programmi già esistenti.

2. I componenti software vengono testati separatamente secondo le specifiche.

INTEGRAZIONE E TESTING DEL SISTEMA: Le unità di programma sono integrate e testate in modo da realizzare il sistema completo. Questa fase viene suddivisa in quattro attività: 1. Integrazione dei componenti; 2. Test di integrazione; 3. Test sui requisiti di sistema; 4. Consegna del sistema al cliente;

MANUTENZIONE E INTERVENTI:

In questa fase il sistema è già in funzione e i clienti lo stanno adoperando. Viene garantito il supporto al cliente. Questa fase viene divisa in quattro momenti: 1. intervento; 2. manutenzione; 3. evoluzione; 4. eliminazione graduale; Riassumendo possiamo vedere tutto il processo attraverso questo schema: —>

COMPROMESSI DEL MODELLO A CASCATA: I. Documentazione dettagliata e fasi ben specificate; II. Facile eseguire delle manutenzioni al sistema (assumendo che la documentazione sia

aggiornata); III. Una volta scritta la documentazione questa rimane immutabile nonostante l’evoluzione del

sistema; IV. Il cliente viene coinvolto nel processo di sviluppo solo nella prima fase del processo; V. Il processo di sviluppo è difficile da controllare; VI. Il prodotto diventa utilizzabile molto tardi durante il processo di sviluppo;(questo rischia di

portare alla creazione di un prodotto sbagliato rispetto a quello che ha richiesto il cliente);

Modello a spirale: 2018 Andrea Oian

Combina elementi di design e di prototipazione; in particolare combina la realizzazione di prototipi al modello a cascata. Questo modello rende più semplice far fronte a modifiche che devono essere effettuate in corso d’opera. Questo lo rende ideale per essere adoperato nello sviluppo di progetti molto complessi e costosi. SOFTWARE PROTOTYPING: Un prototipo è una versione iniziale di un sistema, usato per dimostrare i concetti fondamentali di funzionamento del sistema e per testare elementi di design. Tipicamente un prototipo simula solo alcuni aspetti del prodotto finale e molto spesso è molto diverso rispetto al prodotto finale. Un prototipo può essere usato in: - nel processo di ingegneria dei requisiti per aiutare nella definizione e nel provare la validità

dei requisiti. - nel processo di design per esplorare le varie opzioni nello sviluppare il sistema o una sua

parte, ad esempio nella UI. - nel processo di testig per fare test continui.

QUALI SONO I BENEFICI NELL’UTILIZZO DEI PROTOTIPI? Un migliore usabilità del sistema, un prodotto che rispecchia il più possibile le aspettative del cliente e che funziona nel modo desiderato, un design di qualità superiore, una mantenibilità maggiore e un minor sforzo durante lo sviluppo. Di seguito schema sviluppo di un prototipo:

SVILUPPO DI PROTOTIPI: Si pu basare sullo sviluppo attraverso linguaggi e strumenti specifici. Durante lo sviluppo del progetto possiamo tralasciare alcune funzionalità in favore dello sviluppo di aree del prodotto che non sono comprensibili. Inoltre la correzione degli errori può non essere contemplata nello sviluppo del prototipo, e ci sarà un maggiore focus sulla sicurezza e sull’affidabilità. Normalmente i prototipi sono privi di documentazione e inoltre molto spesso sono molto lontani rispetto alla qualità del prodotto finale.

SVILUPPO INCREMENTALE: L’obiettivo che si pone questo approccio di sviluppo è di lavorare a fianco del cliente per creare un sistema finale a partire da alcune specifiche iniziali. Inoltre questo approccio di sviluppo fa si che la consegna del prodotto non avvenga alla fine del processo di sviluppo ma bensì che lo sviluppo e la consegna si suddividano in incrementi graduali. In questo modo ad ogni incremento verranno aggiunte delle funzionalità al prodotto finale.

2018 Andrea Oian

In questo approccio i requisiti dell’utente hanno la massima priorità, infatti vengono implementate a partire dalla prima release. Una volta che lo sviluppo di un incremento è iniziato i requisiti e le proprietà che sono stati introdotti nelle release precedenti vengono congelate, mentre le proprietà e le funzionalità che devono ancora essere implementate si evolvono. PRO E CONTRO DELLO SVILUPPO INCREMENTALE:

I. (pro)Valore aggiunto per il cliente, in quanto ogni richiesta aggiuntiva pu essere esaudita nell’incremento successivo. Quindi questo rende più veloce la disponibilità di nuove funzionalità da sottoporre al cliente.

II. (pro)I primi incrementi sono visti come prototipi che possano suscitare nel cliente la richiesta di nuovi requisiti e funzionalità per incrementi successivi.

III. (pro)Minor rischio che il progetto fallisca. IV. (pro)I servizi del sistema che richiedono una maggiore priorità tendono a ricevere una

maggiore quantità di test e verifiche. V. (contro)Mancanza di schematicità nell’andamento dello sviluppo. VI. (contro)I sistemi sono spesso strutturati in modo grossolano. VII. (contro)Sono richieste abilità nella creazione di prototipi attraverso linguaggi immediati.

Lo sviluppo incrementale è spesso applicabile per sistemi interattivi medio-piccoli o per particolari parti di grandi sistemi (ad esempio nell’interfaccia grafica). O anche per sistemi che avranno una breve ciclo di vita.

Processo unificato: E’ una metodologia che si adatta per lo sviluppo di software orientato ad oggetti. Si basa sulla fusione del modello incrementale e il modello iterativo. E’ basato su UML e ruota attorno all’architettura.

Le sue fasi sono: 1. Inizio: Determinare se vale la pena lo sviluppo del prodotto; cogliere lo scopo e i requisiti

fondamentali per lo sviluppo; identificare i rischi annessi allo sviluppo;

2. Elaborazione: raffinare i requisiti e creare un piano manageriale di sviluppo del software e la definizione di una architettura di base;

3. Costruzione: creazione della prima betarelease e la prima versione del manuale utente;

4. Transizione: Raccogliere e analizzare i feedback dei clienti, correzione errori e creazione dei manuali completi;

Come dice la parola stessa, in questo tipo di processo si

2018 Andrea Oian

itera lo sviluppo a partire da una prima versione, andando via via ad aumentare le prestazioni del prodotto.

Nel modello incrementale si parte fin da subito con uno schema chiaro di quello che sarà il prodotto finale, e ci si concentra nei suoi aspetti senza iterazioni, completandoli singolarmente uno ciascuno.

Sviluppo Agile: E’ una struttura concettuale per l’ingegneria del software che promuove l’iterazione dello sviluppo durante tutto il periodo di sviluppo. Il software sviluppato durante l’unità di tempo è riferito ad una singola iterazione, che in genere può durare da una a due settimane. In più lo sviluppo agile enfatizza il principio secondo cui un codice che funziona sia la misura del progresso del progetto. I concetti chiave dello sviluppo agile sono: • Consegna continua dei risultati durante lo sviluppo; • Modifica dei requisiti; • Consegna frequente di nuove versioni; • Coinvolgimento del cliente, ovvero il cliente viene visto come parte del team di sviluppo; • Motivazione dei partecipanti, in modo da avere una sviluppo a cui tutti diano il proprio

contributo; • Conversazione diretta, face-to-face, sui problemi e sulle modifiche da fare al progetto; •

Focalizzarsi sul software; • Sostenibilità; • Continua attenzione alla qualità sia tecnica che del design del progetto; • Semplicità: ovvero non affrontare il problema nella sua totalità ma scomporlo in sotto

problemi elementari; • Team che si auto organizza;

Extreme ProgrammingRappresenta il metodo di sviluppo in stile agile più utilizzato. I vari scenari sono rappresentati da storie degli utenti chiamati task, per ogni task i programmatori lavorano a coppie e sviluppano test prima ancora che il sw sia sviluppato.Il sw così avanza a piccoli passi, senza rispettare una pianificazione ben precisa.Così nuove versioni del sw vengono rilasciate più volte al giorno e gli icrementi vengono consegnati spesso al cliente.

Integrazione e configurazioneQuesto metodo consiste nel prendere parte di sw gia precedentemente progettato e riadattarlo alle funzionalità e requisiti del nuovo modello da progettare, questo permette di risparmiare un sacco di tempo e denaro però bisogna scendere a compromessi con il cliente per quanto riguarda i requisiti.I sistemi maggiormente implementati in questa maniera sono:

2018 Andrea Oian

-i sistemi di buisness-i servizi web-le collezioni di oggetti-sistemi stand-alone

Modellazione di sistema: E’ il processo di sviluppo di modelli astratti di un sistema, in cui ogni modello rappresenta una visione diversa o una prospettiva diversa dello stesso sistema. Molto spesso il modelling di un sistema comprende molte views, ovvero diversi modelli. Spesso si rappresentano i sistemi sfruttando delle notazioni grafiche.

MODELLAZIONE DEI COMPONENTI:

Un modello è una astrazione che descrive un sottoinsieme di un sistema. Una view rappresenta aspetti specifici di un sistema. Una notazione è un set di regole testuali e grafiche per la rappresentazione delle viste. Più viste e i modelli di un unico sistema possono possono sovrapporsi tra di loro.

COME MAI SI RAPPRESENTANO DEI MODELLI ?

Il primo motivo è che il software è complesso, e in genere la complessità e talmente alta che la maggior parte delle persone non riesce a comprenderlo. Molto spesso risulta di difficile comprensione per sviluppatori che non lo hanno scritto. In più non è necessario conoscere tutti i dettagli subito, questo è il motivo per cui si usano dei modelli! Offrono una visione semplificata, che permette di concentrarsi di più sui problemi di sviluppo del progetto. Aiutano gli analisti a capire le funzionalità del sistema e sono utili anche per comunicare con il cliente.

Regole che deve seguire un buon modello: • predittivo: Costruito prima dell’inizio dell’implementazione, fatto per prevedere

come il software dovrà essere e aiuta a preparare ai requisiti necessari e ai rischi; • estratto: estratto da un sistema esistente dall’analisi delle proprietà del software.

Aiuta a chiarire domande più specifiche sul funzionamento del software; • prospettiva: Definisce una serie di regole e

confini su come costruire e far evolvere il software;

I modelli di sistemi già esistenti possono essere usati durante l’ingegneria dei requisiti di un nuovo sistema. Possono aiutare a chiarire cosa fa il sistema esistente e in che modo questo può essere usato come base per un nuovo sistema. In particolare ci sarà una discussione dei suoi punti di forza e delle sue debolezze.

SVILUPPO BASATO SU MODELLI:

Supporta la generazione di una completa o parziale implementazione di un determinato sistema a partire da un modello. Il tutto parte dallo sviluppo di un modello che sia indipendente dalla piattaforma su cui verrà implementato il sistema, ma in modo che siano descritti i suoi

2018 Andrea Oian

comportamenti e le sue funzionalità. Il modello verrà descritto e rappresentato attraverso un linguaggio di moderazione, questo sarà in grado di convertire il modello in un modello specifico per una determinata piattaforma, e questo porterà alla creazione di un eseguibile specifico per la piattaforma in questione. Il vantaggio di questo approccio è che il codice è in gran parte generato dal modello, questo è utile per la portabilità e per la interoperabilità. MDA è la sigla di questo tipo di approccio, e risulta essere quello più usato.

PROSPETTIVE DI SISTEMA:

Una prima prospettiva può essere quella dell’ambiente in cui si andrà ad implementare il nostro sistema, ovvero il contesto e l’ambiente circostante. Un’altra prospettiva è quella delle interazioni, ovvero come il sistema interagisce con l’ambiente circostante, o anche come i singoli componenti del sistema interagiscono tra di loro. Ci può essere anche una prospettiva strutturale in cui viene modellata l’organizzazione del sistema o anche la struttura dei dati che vengono processati dal sistema. Infine vi pu essere una prospettiva comportamentale, dove vengono modellati i comportamenti in regime dinamico del sistema e come risponde a diversi eventi esterni. Vi sono inoltre dei modelli contestuali usati per illustrare il contesto operazionale del sistema e per mostrare quali sono i limiti del sistema. In più sono usati per definire l’ambito fisico del sistema, ovvero sapere cosa possiamo controllare, ovvero interno al sistema e cosa no, ovvero esterno al sistema.

CONFINI DI SISTEMA: Sono introdotti per definire cosa si trova all’interno e cosa all’esterno del sistema, e vengono adoperati per mostrare i sistemi che dipendono o che vengono usati nel sistema che si sta sviluppando. La definizione dei confini del sistema ha un grande impatto nello stilare i requisiti del sistema. La definizione di confini del sistema è un giudizio politico, in quanto ci possono essere delle pressioni per sviluppare confini di sistema che aumentino o diminuiscano l’influenza o il carico di lavoro di specifiche parti dell’organizzazione.

MODELLI DI INTERAZIONE: Il modelling delle interazioni con l’utente è importante, dato che aiuta ad identificare i requisiti dell’utente. In più risulta importante anche il modelling delle interazioni sistema-sistema, per mettere in evidenza i problemi di comunicazione in cui si può incorrere. Risulta fondamentale anche il modelling dell’interazione tra i componenti, in quanto aiuta a capire quali architetture di sistema riescono a garantire le performance richieste.

MODELLI STRUTTURALI: Mostrano l’organizzazione di un sistema in termini dei componenti che formano il sistema e le relazioni che intercorrono tra di loro. Possono essere modelli statici, che mostrano la struttura del design del sistema, o modelli dinamici che mostrano l’organizzazione del sistema mentre è in esecuzione. Questi modelli vengono creati quando si ha la necessità di discutere riguardo al design e all’architettura del sistema.

MODELLI COMPORTAMENTALI: Sono modelli dinamici che mostrano il comportamento dinamico di un sistema mentre è in esecuzione. Mostrano in particolare cosa accade o cosa ci si aspetta che accada quando il sistema risponde ad uno stimolo proveniente dal suo ambiente circostante. Questi stimoli possono essere di due tipi: 1. Dati che arrivano e che devono essere processati dal sistema;

2018 Andrea Oian

2. Eventi che attivano il processing del sistema, o anche eventi che incorporano al loro interno dei dati;

MODELLI DATA-DRIVEN: Mostrano la sequenza di azioni che sono coinvolte nel processing dei dati in ingresso e alla generazione di un output a loro associato. Molti sistemi in ambito business sono sistemi di data-processing che sono pilotati dai dati con l’aiuto di eventi esterni. Sono molto utili durante l’analisi dei requisiti in quanto possono essere usati per mostrare tutte le fasi di processing che svolge il sistema.

MODELLI EVENT-DRIVEN: Mostrano come un sistema reagisce ad un evento esterno e interno. Un esempio di sistema event-driven sono i sistemi real time, in cui vi è una piccolissima parte di data processing. Sono basati sull’assunzione che il sistema abbia un numero finito di stati e che gli eventi possano causare il passaggio da uno stato all’altro.

Unified Modeling Language (UML): Definito nel gennaio 1997, è il linguaggio standard e il sistema di notazione usato per la specifica, la costruzione, la visualizzazione e la documentazione di modelli di sistemi software. E’ formato da un infrastruttura(costrutti linguistici ben precisi),una sovrastruttura(modelli e diagrammi UML) e il linguaggio OCL.Non è una metodologia di sviluppo.

CARATTERISTICHE DI NOTAZIONE UML: I. Semplice perché richiede un set limitato di concetti e simboli; II. Espressivo perché è applicabile ad un’ampio spettro di sistemi con diversi cicli di vita; III. Utile perché si focalizza solo sugli elementi necessari all’ingegneria del software; IV. Coerente in quanto lo stesso concetto e simbolo devono essere applicati allo stesso modo

in tutti i casi; V. Estendibile in quanto gli utenti e i costruttori di strumenti hanno la libertà di estendere la

notazione;

VISTE DI UML: • Vista use-case; • Vista strutturale; • Vista comportamentale; • Vista di implementazione; • Vista di ambiente; VISTA USE-CASE: Questa vista raccoglie i requisiti del sistema, in più descrive i casi di utilizzo che forniscono valore per l’utente. Gli use case essenziali sono usati come prova del concetto per l’implementazione dell’architettura. Possono essere visualizzati attraverso UML con dei diagrammi use-case. Ogni uso può avere multipli scenari, che possono essere descritti usando descrizioni testuali o grafiche, ad esempio con diagrammi comportamentali di UML.

VISTA STRUTTURALE: Rappresenta gli elementi strutturali necessari per l’implementazione della soluzione secondo i requisiti che sono stati definiti. Definisce un’analisi orientata agli oggetti, in più definisce il

2018 Andrea Oian

dominio e il vocabolario della soluzione. Definisce il sistema attraverso la sua decomposizione in strati (layers) e sottosistemi.

VISTA COMPORTAMENTALE: Rappresenta le interazioni dinamiche tra i componenti del sistema per l’implementazione dei requisiti. In più mostra la distribuzione delle responsabilità e permette di identificare le interazioni e i colli di bottiglia del sistema. Questa vista è anche un mezzo per discutere di requisiti non funzionali.

VISTA DI IMPLEMENTAZIONE: Descrive gli artefatti dell’implementazione si sottosistemi logici definiti nella vista strutturale. Pu includere artefatti intermedi usati nella costruzione del sistema, ad esempio file di codice, librerie e dati. Definisce le dipendenze tra l’implementazione dei componenti e le connessioni necessarie e le loro interfacce.

VISTA D’AMBIENTE: Rappresenta la topologia del sistema hardware. Definisce come i componenti software sono disposti nei vari nodi hardware. Questa vista è utile per l’annidi di requisiti non funzionali come l’affidabilità, la scalabilità la sicurezza ecc.. Fornisce informazioni necessarie alla installazione e alla configurazione del sistema.

Tipi di diagrammi UML: DIAGRAMMA USE-CASE: mostra le funzionalità di un sistema, e rappresenta in unità discrete le interazioni tra l’utente (che pu essere una macchina o una persona) e il sistema. In più fornisce agli sviluppatori, esperti del dominio e agli utenti un modo per comunicare. In più è una base per il testing.

DIAGRAMMI DI CLASSE: Mostra attraverso la costruzione di blocchi il funzionamento di un sistema orientato agli oggetti. In particolare mostra una visione statica di un modello, o una parte di esso, descrivendone gli attributi e i comportamenti. Non spiega in modo dettagliato come queste operazioni possano essere compiute. E’ molto utile per illustrare le relazioni tra classi e interfacce.

DIAGRAMMA DEGLI OGGETTI: Descrive una struttura statica di un sistema, in un preciso istante, e può essere considerato come un particolare tipo di Class Diagram. La differenza tra i due è che mentre un class diagramma descrive tutte le possibili situazioni,

2018 Andrea Oian

un modello ad oggetto descrive solo una particolare situazione. E’ utile per capire e dare valore ai corrispettivi diagrammi di classe.

DIAGRAMMA DI STRUTTURA COMPOSTA: Mostra la struttura interna di una classificatore, compresi i suoi punti di interazione con altre parti del sistema. Un classificatore è un elemento di UML che è descritto da attributi e/o metodi, ad esempio una classe, una interfaccia o un componente. E’ simile ad un class diagram, ma mostra parti singole invece che intere classi.

DIAGRAMMA DI PACCHETTI: Sono usati per decomporre i sistemi in unità logiche di lavoro, descrivendo le dipendenze che hanno l’uno con l’altro. In più forniscono viste di un sistema attraverso multipli livelli di astrazione. Il loro uso più comune è per organizzare i diagrammi use case e i diagrammi di classe, ma possono essere sfruttati anche per altri elementi UML. DIAGRAMMA DI STATO: Modella il comportamento di un singolo oggetto, in particolare specifica la sequenza di stati che un oggetto attraversa durante il suo lifetime, in risposta a diversi stimoli dall’ambiente esterno. Mostra: • La cronologia della vita di una classe

specifica; • Gli eventi che hanno causato la transizione

da uno stato all’altro; • Le azioni che risultano da un cambiamento di

stato; Vengono usati per oggetti che hanno un comportamento molto dinamico nel tempo.

DIAGRAMMA DI ATTIVITÀ: Può essere considerato come un caso particolare di uno state-machine diagramma. In questi diagrammi gli stati sono le attività o funzioni. Sono utili per rappresentare il workflow di un sistema, in particolare vengono usati per rappresentare in dettaglio situazioni in cui vi è la necessità di un processing in parallelo per l’esecuzioni di alcune attività. Molto usato per il modelling nell’ambito business.

DIAGRAMMA DI SEQUENZA: Descrive come un processo viene svolto da un gruppo di oggetti, attraverso un set di interazioni sequenziali. Facilità l’attribuzione di responsabilità alle classi, e aiuta a trovare

2018 Andrea Oian

nuovi metodi e classi necessari per lo svolgimento di azioni. Pu contenere i seguenti elementi: • Ruoli: che rappresentano i ruoli che gli oggetti avranno durante una determinata interazione; • Linee della vita: che rappresentano l’esistenza di un oggetto in un certo lasso di tempo; • Attivazioni: rappresentano il tempo in cui un oggetto sta svolgendo una certa operazione; • Messaggi: rappresentano la comunicazione tra oggetti;

DIAGRAMMA DI COMUNICAZIONE: Precedentemente venivano chiamati diagrammi di collaborazione, ed è un diagramma di interazione che mostra informazioni simili al diagramma di sequenza, ma è focalizzato sulle relazioni di un oggetto. Possono essere composti da: • Oggetti: sono mostrati con connettori di associazione tra di

loro; • Messaggi: sono aggiunti alle associazioni, e mostrano,

attraverso frecce che puntano in direzione del destinatario; • La sequenza di messaggi è mostrata attraverso uno schema

di numerazione; Forniscono una vista alternativa al diagramma di sequenza, in un format che si basa sulla struttura invece che sul tempo. TIMING DIAGRAM: Usato per mostrare il cambiamento di stato o di valore di uno o più elementi durante il tempo. Può anche mostrare le interazioni tra eventi dipendenti dal tempo e la loro durata. Mostra il tempo di esecuzione impiegato da ciascuna istruzione in formato grafico.

DIAGRAMMA DI INTERAZIONE GENERALE: E’ un tipo di diagramma di attività in cui i nodi rappresentano gli inter action diagram (sequence, comunicazione interaction overview e timing diagram). La maggior parte della sua notazione deriva dall’activity diagram. Le uniche peculiarità sono che introduce due nuovi elementi: occorrenza di interazione e elementi di interazione.

COMPONENT DIAGRAM: Mostra le relazioni che intercorrono tra le componenti software , le loro dipendenze, comunicazioni, posizioni e altre condizioni. Danno la possibilità di modellare componenti software di alto livello, e le interfacce di tali componenti. Si riferiscono molto spesso al diagramma di connessione. Un componente è una entità indipendente ed eseguibile che pu essere

2018 Andrea Oian

da uno o più oggetti eseguibili. Un componente ha una interfaccia pubblica usata per comunicare con gli altri componenti.

DIAGRAMMA DI DISTRIBUZIONE: Questo diagramma mostra le relazioni fisiche che ci sono tra hardware e software all’interno di un sistema. Contengono nodi e connessioni. Un nodo molto spesso rappresenta un pezzo dell’hardware presente nel sistema, mentre una connessione rappresenta il percorso di comunicazione usato dall’hardware per comunicare.

Ingegneria dei requisiti: REQUISITI: Possono variare da una dichiarazione astratta ad alto livello di un servizio o di un confine di sistema a dettagliate specificazioni matematiche. I requisiti risultano essere inevitabili, in quanto hanno due funzioni: I. Possono essere la base per una offerta per un contratto: in questo caso possono essere

aperti add una interpretazione; II. Possono essere alla base del contratto stesso: in questo caso devono essere molto

dettagliati. Che caratteristiche devono avere i requisiti del mio sistema? Devono essere: • Validi (corretti): ovvero devono esprimere le reali necessità di tutte le parti interessate. In più

non devono contenere niente che non sia privo di requisiti. • Non ambigui: ogni affermazione deve essere specifica e non fraintendibile. • Completi: Devono contenere tutte le cose che il sistema pu e non pu fare. • Comprensibili (chiari): Che possano essere compresi da chiunque, anche da chi non è un

programmatore. • Coerenti: Non devono contraddirsi da soli e usare termini coerenti. • Classificati: Ovvero indicarli in ordine di importanza. • Verificabili: Ovvero creare un test che permetta di verificare la copertura di ogni requisito. • Modificabili: Possono essere modificati facilmente. • Tracciabili: L’origine di ogni requisito deve essere chiara, necessario etichettare ogni

requisito per riferimenti futuri. L’ingegneria dei requisiti è il processo con cui si stabiliscono i servizi che il cliente richiede dal sistema e i limiti sotto cui il sistema dovrà operare ed essere sviluppato. L’obbiettivo è di raccogliere ed analizzare le descrizioni dei servizi di sistema e i suoi vincoli. I requisiti documentano il comportamento del software che deve soddisfare certe esigenze, mentre il design mostra come quei requisiti verranno implementati, queste due entità per non possono essere scollegate in quanto una architettura di sistema deve essere disegnata seguendo i requisiti richiesti.

REQUISITI E UML: Analisi degli use case: è focalizzata sulla scrittura testuale, gli use case sono solo una parte dei requisiti funzionali, i quali descrivono le interazioni interne ed esterne. Serve anche una analisi strutturale e un modelling del dominio, ovvero la ricerca degli oggetti reali che sono coinvolti nei diagrammi use case e delle classi, in modo da rappresentarli correttamente. Analisi comportamentale: Creazione di diagrammi di attività, comunicazione e sequenza, in modo da carpire i dettagli del diagramma use case.

CLASSIFICAZIONE DEI REQUISITI: Alla base del tipo di funzioni del sistema: • Requisiti funzionali; • Requisiti non funzionali;

2018 Andrea Oian

• Requisiti di dominio; Alla base della loro natura statica o dinamica: • Requisiti duraturi; • Requisiti volatili; Sulla base del pubblico: • Requisiti dell’utente; • Requisiti di sistema;

REQUISITI FUNZIONALI: Catturano il comportamento desiderato di un sistema; questo comportamento può essere espresso come un servizio, un task o delle funzioni che il sistema è necessario che che compia. Descrive come il sistema deve reagire ad un particolare input e come il sistema deve comportarsi in particolari situazioni. Si avrà: • Descrizione dei dati che potranno essere immessi nel sistema; • Descrizione delle operazioni compiute; • Descrizione dei work-flow eseguiti dal sistema; • Descrizione dei report del sistema o di suoi altri output; • Chi può introdurre dati all’interno del sistema; Ad esempio nel caso di un sistema Libreria i requisiti funzionali sono: Il sistema fornisce una singola interfaccia per un certo numero di database di articoli in librerie diverse, in cui gli utenti possono cercare, scaricare e stampare gli articoli per studi personali. Gli utenti dovrebbero essere in grado di cercare sia da tutti i database o anche da sotto classi di uno di essi. Il sistema dovrà fornire visualizzatori appropriati per l’utente, in modo che possa leggere i documenti.

REQUISITI NON FUNZIONALI: Sono vincoli sui servizi o sulle funzioni offerte dal sistema, come vincoli temporali, vincoli nel processo di sviluppo, standard… Specificano un criterio che può essere usato per giudicare le operazioni del sistema, invece che i comportamenti specifici. Vincolano il design e l’implementazione del sistema, ma non descrivono i servizi che il sistema deve fornire. Tipi di requisiti non funzionali: • Requisiti di prodotto: requisiti che specificano

che il prodotto consegnato deve comportarsi in un determinato modo, ad esempio la sua velocità di esecuzione l’affidabilità..

• Requisiti di organizzazione: Requisiti che sono una conseguenza dell’organizzazione delle politiche e delle procedure, ad esempio gli standard di processo usati, i requisiti di implementazione…

• Requisiti esterni: Requisiti che sorgono da fattori che sono esterni al sistema e al processo di sviluppo, ad esempio requisiti di interoperabilità, o requisiti legislativi.

Facendo presente l’esempio della libreria, i requisiti non funzionali di un sistema che gestisce una libreria sono: A. Requisiti di prodotto: Le interfacce utente devono essere implementate con solo HTML,

senza usare applet java; B. Requisiti di organizzazione: Il processo di sviluppo del sistema e la consegna dei

documenti devono essere conformi ad una certa specifica. C. Requisiti esterni: il sistema non deve divulgare alcuna informazione personale dei clienti

all’infuori del loro nome e del loro numero di riferimento per le operazioni di sistema.

2018 Andrea Oian

REQUISITI DI DOMINIO: Derivano dal dominio di applicazione del sistema e riflettono le caratteristiche del dominio in questione. Possono essere sia funzionali che non. E’ difficile capire le implicazioni della loro introduzione, da non specialisti, o capire come interagiscono con gli altri requisiti. Se non vengono soddisfatti il sistema potrebbe essere inutilizzabile. Alcuni requisiti possono essere espressi usando il linguaggio dell’appication domain, e questo molto spesso non viene compreso dagli ingegneri software durante lo sviluppo del sistema. Alcuni requisiti possono essere espressi nel linguaggio degli sviluppatori, che molto spesso non vengono capiti dai clienti.

REQUISITI DURATURI E VOLATILI: Requisiti duraturi: Sono stabili e derivano dalla attività principale dell’organizzazione del cliente. A esempio un ospedale avrà sempre dei dottori e delle infermiere. Requisiti volatili: Possono cambiare durante lo sviluppo o durante l’uso del sistema. Ad esempio in un ospedale vi sono dei requisiti che derivano da delle politiche della salute. TIPI DI REQUISITI VOLATILI: • Requisiti mutabili: Requisiti che cambiano in base all’ambiente in cui l’organizzazione sta

operando. Ade esempio in ospedale i finanziamenti possono cambiare e ad ogni cambiamento ci saranno delle politiche diverse da seguire.

• Requisiti emergenti: Requisiti che possono emergere in corso di sviluppo del sistema, quando il cliente cambia idea su alcune feature durante lo sviluppo. Questi requisiti emergono molto spesso nella fase di design del sistema.

• Requisiti consequenziali: Requisiti che possono essere richiesti in seguito all’introduzione del sistema informatico. Infatti con l’introduzione del sistema informatico pu cambiare il processo di organizzazione e aprire nuovi modi di lavoro, che a loro volta possono generare dei nuovi requisiti.

• Requisiti di compatibilità: Requisiti che dipendono da particolari sistemi o da processi business all’interno dell’azienda. Se uno di questi cambia, i requisiti di compatibilità che sono commissionati assieme al sistema dovranno evolversi a loro volta.

Documentazione dei requisiti: ESIGENZE UTENTI (USER REQUIREMENTS): Descrizione dei servizi di sistema e dei suoi limiti operazionali, in modo che siano comprensibili dagli utenti che non hanno conoscenze tecniche del sistema. Scritto per i clienti, ma usato da: Manager, utenti di sistema, ingegneri del cliente, architetti di sistema.. Questi requisiti vengono definiti con linguaggio naturale, tabelle diagrammi.

REQUISITI DI SISTEMA: Specificazione molto più dettagliata degli user requirements, scritta sia per il cliente che per l’imprenditore, usata da: Utenti di sistema, ingegneri del cliente, architetti di sistema e sviluppatori software. Possono essere usati come contratto tra cliente ed esercente. Possono essere espressi attraverso modelli di sistema.

SPECIFICAZIONE REQUISITI: E’ un documento che spiega chiaramente i requisiti di sistema, e dovrebbe includere sia la definizione che la specifica dei requisiti, inoltre deve descrivere cosa il sistema dovrebbe e cosa non dovrebbe fare. Se il sistema è solo software viene chiamato Software Requirements Specification (SRS) , se invece il sistema è sia hardware che software viene chiamato System Specification.

2018 Andrea Oian

PROBLEMI DELLA DESCRIZIONE ATTRAVERSO LINGUAGGIO NATURALE: • Mancanza di chiarezza: è difficile essere precisi senza rendere il documento difficile da

leggere; • Confusione dei requisiti: I requisiti funzionali e non tendono ad essere mischiati tra di loro; • Amalgamazione dei requisiti: Diversi requisiti potrebbero essere espressi assieme; • Ambiguità: I lettori e gli scrittori devono interpretare le stesse parole con lo stesso significato; • Mancanza di modularità: il linguaggio naturale è inadatto per strutturare i requisiti di sistema;

Vi sono alcune linee guida per l’uso del linguaggio naturale: Partire da un formato standard e applicarlo a tutti i requisiti, usare inoltre il linguaggio in modo coerente, ovvero usare la stessa sintassi per la descrizione dei requisiti e gli stessi termini per lo stesso tipo di requisiti. Usare testo evidenziato per identificare le parti chiave del requisito. Evitare di usare un gergo informatico.

Parole Chiave: Comportamento, limitazione: • Shall: il sistema deve svolgere questo compito il 100% delle volte a meno di specifiche. • Should: è desiderabile che il sistema faccia una certa cosa quando è ragionevole. • Can: il

sistema può fare qualcosa, ma non vi è un particolare incentivi per attuarlo.

User actions: • Must: L’utente deve fare questa cosa, ha lo stesso significato di should, ma questo è riferito

all’utente e non al sistema. • May: l’utente potrebbe avere questo comportamento, ma non è obbligato a farlo. Environment: • Will: Il designer può dare per certo che l’ambiente si comporterà in un certo modo. • Might: il designer si deve adattare alla situazione, ma non è detto che ci possa fare

affidamento.

Change risk: • Expected to: Questa area è molto probabile che sia cambiata; • Could: questa area è possibile che cambi, non è certo per .

Il processo usato per l’ingegneria dei requisiti può variare a seconda di alcuni parametri, in particolare il dominio di applicazione, le persone coinvolte e in base alla casa produttrice che sviluppa i requisiti. Nonostante queste variabili vi sono delle attività che sono comuni a tutti i processi, ovvero:-l’estrapolazione dei requisiti-la loro analisi-la loro convalida -la loro gestione

OCL: I diagrammi UML non sono mai abbastanza rifiniti in modo da fornire tutti gli aspetti di una determinata specifica, infatti spesso sono necessari dei vincoli aggiuntivi sulle relazioni tra le entità dei diagrammi che possono essere descritto attraverso il linguaggio naturale, anche se

2018 Andrea Oian

può portare a delle ambiguità, o attraverso un linguaggio formale, il quale è utilizzabile solo da persone con conoscenze matematiche. Per poter rimediare a questa problematica è stato sviluppato OCL, ovvero un linguaggio formale che rimane semplice da leggere e scrivere sia per i clienti che per i modellatori di sistema. OCL sta per Object Constraint Language, ovvero linguaggio di vincolo ad oggetti. E come dice il nome stesso è un linguaggio che permette la descrizione di espressioni e di vincoli di modelli orientati agli oggetti. In particolare è un linguaggio scritto e formale, ma con una precisa sintassi e semantica. Inizialmente sviluppato da IBM. Non è un linguaggio di programmazione. Viene usato con i seguenti utilizzi: • Linguaggio di interrogazione; • Per specificare vincoli sulle classi e sui tipi; • Per specificare i vincoli sulle operazioni; • Per specificare i target per i messaggi e le azioni; • Per definire espressioni per la navigazione nei modelli UML; TIPI DI DATI IN OCL: I. Tipi base: Reali, interi, stringhe e bool; II. Tipi definiti dall’utente/modelo, tutte le classi, i tipi le interfacce e le enumerazioni in un

modello UML III. Tipi di raccolta: Set, OrderedSet, Bag e sequence;

ESPRESSIONI E VINCOLI: Ogni espressione ha un esito: il valore ottenuto dalla valutazione di tale espressione; Ogni espressione può contenere solo operazioni di interrogazione: le interrogazioni restituiscono un valore, ma non cambiano niente nel sistema. L’attivazione di un processo e di una operazione non-query non sono possibili con OCL. Il tipo di espressione risulterà essere anche il tipo del risultato di tale espressione. Un vincolo è un tipo booleano.

Perché usare vincoli? Forniscono una miglior documentazione, infatti sono un modo per documentare i diagrammi UML, in più aggiungono informazioni riguardo gli elementi del modello e le relazioni che intercorrono tra di loro legate ai modelli visuali di UML. TIPI DI VINCOLI: • Invarianti, pre-condizioni e post condizioni sono vincoli che sono connessi ad un elemento di

modelling, ad esempio ad una classe o ad una interfaccia, e che devono mantenere le loro istanze.

• custodia: sono vincoli che sono per di più associati ad una transizione;

Studio della fattibilità: Nello studio di fattibilità si decide se il sistema può essere utile a qualche impiego e se è realilzzabile, quindi si controlla se il sistema contribuisce coi sistemi organizzativi della ditta, se si riuscirà a terminare nei tempi stabiliti e nel budget stabilito.Inizialmente bisogna stabilire dove andare a ricercare, cioè da quali fonti, questi requisiti e quali sono le informazioni necessarie.Un buon elicitation si ha quando il cliente riesce a comprendere bene i requisiti fin dove il sistema può spingersi, e se lo sviluppatore riesce a capire se è possibile e in quanto tempo riesce a sviluppare il sw.

Sistem stackholders

2018 Andrea Oian

E’ l’insieme di tutte le persone sia interne che esterne che hanno a che fare con il sistema, quindi possono essere sia gli utenti che gli sviluppatori, buisness maneger, esperti di dominio o rappresentanti dei sindacati.

Tecniche di elicitationAnalisi dei documentiE’ una tecnica che comprende la visione di documenti o file ed è svolta in diversi passaggi:-si identificano i documenti necessari per l’analisi-si visionano i documenti annotandosi le informazioni principali-si discute con le persone interessate le informazioni ricavate per poi organizzare i requisitiI vantaggi di questa pratica è che quando molte persone coinvolte nel progetto sono disponibili, questa pratica risulta utile, e sono disponibili cmq un enorme quantitativo di informazioni. Però presenta numerosi svantaggi, dati dalla vastità dei documenti che possono essere presenti, infatti qualche informazione chiave potrebbe scappare, e cmq ce bisogno di un grande investimento in termini di tempo e monetario.

OsservazioneConsiste nell’osservazione sul posto di lavoro di persone che c entrano in qualche modo col sistema.L’obbiettivo è estrapolare il maggior numero di informazioni, stando bene attenti a non farsi notare, infatti le persone sentendosi osservate potrebbero cambiare modo di lavorare. Dopo aver preso appunti su queste persone le si rivaluta e si stabiliscono i requisiti. E’ una tecnica poco costosa e permette di avere molte informazioni, ma bisogna stare attenti ad avere un basso profilo.

Creazione di un questionarioConsiste nella creazione di un questionario che verrà fatto a tutti gli elementi della ditta o a una parte, è un metodo poco costoso di estrapolare informazioni utili ai fini dei requisiti.Le domande possono essere a scelta multipla o a risposta aperta.Questo metodo fornisce molte informazioni a poco costo, ma le informazioni sono limitate alle domande.

IntervistaL’intervista si svolge in questa maniera:-bisogna scegliere l’intervistato o gli intervistati-condurre l’intervista-scrivere un riassunto dell’intervistaBisogna stare accorti in molte cose, bisogna mettere a proprio agio l’intervistato evitando di fargli domande lunghe e complesse o troppo personali o troppo aggressive, si può lasciare in alcuni casi la possibilià di parlare anche di cose che non c’entrano proprio con la domanda.E’ una prassi molto stimolante per l’intervistato, sollecitano idee e opinioni.

ScenariGli scenari sono dei comportamenti, anche particolari del sistema, nella vita reale e contengono:-una descrizione della situazione iniziale-una descrizione del flusso degli eventi-cosa puo andare storto-la conclusione

2018 Andrea Oian

Use caseGli use case sono particolari tipi di scenari che utilizzano per la loro rappresentazione i diagrammi UML. Gli use case sono descritti sia da diagrammi use case, che da descrizioni testuali, che da sequence diagram.Essi descrivono le funzionalità del sistema e quali attori partecipano a queste funzionalità nei vari passaggi e sequenze di eventi. In primo luogo è necessario identificare gli attori del sistema, cioè coloro che interagiscono dall’esterno con il sistema, e per fare ciò bisogna stabilire in primo luogo i confini del sistema, poi si selezionano le entità che verranno etichettate con dei nomi.Gli use case possono essere di 2 tipi:-di dominio, rappresentano le iterazioni fra gli utenti e il dominio applicativo-di sistema, rappresentano le iterazioni fra gli utenti e il sistemaPer sviluppare gli use case è necessario essere il più narrativi possibile, ogni use case avrà un nome che sarà un verbo che identifica un azione, ed essi sono descritti in pochi passi. Inoltre possono essere ordinati in base alla loro importanza. I vantaggi relativi all’utilizzo degli use case è che sono molto semplici e intuitivi, permettono di gestire la complessità di sistemi molto grandi e permettono di identificare i confini del sistema, tuttavia gli use case servono per identificare più che altro requisiti funzionali.

Analisi dei requisitiE’ quella fase del processo dell’ingegneria dei requisiti che ha come scopo quello di definire le funzionalità che il nuovo prodotto deve offrire, cioè quali requisiti devono essere soddisfatti dal sw. Quindi da questa fase nascono i requisiti veri e proprio dopo un attenta fase di analisi fra gli sviluppatori e il cliente. Questa fase può essere molto complessa perchè i clienti possono non essere tutti d’accordo sugli stessi requisiti, oppure possono non sapere cosa vogliono realmente.

Processo dell analisi dei requisiti

Modelli di analisiI modelli di analisi permettono di creare un astrazione della realtà e sono indipenti dal tipo di piattaforma sul quale andremo a lavorare(a differenza di quelli di design).Esistono molti modelli di analisi, uno di questi è quello orientato agli oggetti, che crea astrazioni chiamate classi che rappresentano entità ed incapsula i suoi dati e il loro stato, in questo caso l’entità sono parti di sistema.

2018 Andrea Oian

Classi di analisiQueste classi analisi sono delle astrazioni delle classi di sistema e gestiscono i requisiti funzionali di sistema, mentre per quelli non funzionali ci pensa il design. Sono semplici e comprensibili ma allo stesso tempo estendibili.Sono rappresentate dai class diagram secondo la convenzione di Boundary,Control ed entity:-Boundary, si tratta di un interfaccia che permette la comunicazione fra le entity e il resto del sistema-entity, attori del sistema-Control, sonogli elementi logici che costituiscono il collante fra i primi due elementi

Categorie di classi di analisi-Elementi esterni al sistema, che cmq utilizzano le informazioni prodotto dal computer-elementi riguardanti il dominio applicativo del sistema-Luoghi-Strutture-Occorrenze ed eventi che possono capitare mentre il sistema è in azione-Ruoli

Techinche per la ricerca di classi-Analisi nome-verbo, un approccio euristico in cui vengono trovati nome,metodi e attributi di una classe partendo dai requisiti, a condizione che si abbia un documento dei requisiti ben stilato-Use case driven, metodo simile al precedente solo che le informazioni sulle classi vengono estrapolate gurdando i numerosi casi d’uso del sistema-Class pattern comuni, è un metodo che si avvale di una branca della scienza che studia come gli oggetti possono essere divisi in gruppi. Forniscono un ottima guida ma non un processo affidabile per trovare le informazioni complete sulle classi-CRC,è formato dal tree compardment card(Nome della classe,responsabilità della classe,collaboratori della classe) e dalle sessioni di brainstorming, ma anche questo metodo non è del tutto affidabile-metodo misto, utilizza in primo luogo un class pattern comune, poi si utlizza il nome-verbo per identificare ene i nomi delle classi, successivamente di testa la loro validità con gli use case ed infine si esegue il brainstorming con il CRC.

Validazione dei requisitiIl processo di validazione dei requisiti ha come obbiettivo quello di controllare la correttezza dei requisiti precedentemente individuati, in poche parole bisogna controllare che i requisiti e la loro documentazione corrispondono a quello che realmente vuole dil cliente.I problemi che bisogna maggiormente tenere d’occhio sono i costi e la completezza, inoltre questa fase dovrebbe continuare fino a quando è necessario ma ci si scontra inevitabilmente con problemi legati al budget e alle scadenze.

Domande per la validazione-Completezza, sono include tutte le funzionalità richieste dal cliente?-Estendibili, è possibile in un secondo momento cambiare o modificare essi?-Coerenza, i requisiti sono in conflitto fra di loro?-Realismo, è possibile implementare i requisiti con le risorse hw e sw possedute?

Tecniche di validazioneCi sono diverse tecniche per la validazione dei requisiti:-Revisione,analisi sistematica dei requisiti-Prototipazione,utilizzo di un modello eseguibile per verificare i requisiti di sistema

2018 Andrea Oian

-Generazione di test, si creano test per testare i requisiti

Revisione e domande per la revisioneLa revisione è un processo che dovrebbe essere svolto dagli sviluppatori in collaborazione coi clienti.Le domande principali per questa parte sono:-Verificabilità, i requisiti possono essere verificati facilmente?-Comprensibilità, i requisiti sono comprensi fino in fondo?-Tracciabilità, è possibile identificare l’origine di questi requisiti?-Adattabilità, i requisiti possono essere modificati?

Generazione di testSi sviluppano test per verificare la testabilità dei requisiti. Quando si fa fatica a generare questi test, questo di solito sta a significare che ci sarà un problema a livello implementativo per quel requisito.

Gestione dei requisitiSi tratta dell’ultimo processo di ingegnerizzazione dei requisiti, e consiste nella modifica di questi ultimi. Infatti è molto difficile che i requisiti cosi in prima stesura possano non essere corretti al 100%, allora si utilizza questa fase per avvicinarsi sempre di più a questa percentuale. Inoltre i requisti possono cambiare durante i processo di ingegnerizzazione, perché gli ambienti tecnici e lavorativi cambiano.

Responsabilità e costiDai requisiti è possibile stabilire in termini di costi il valore del sistema, quindi durante questa fase dove i requisiti cambiano, bisogna stare attenti a non fuoriuscire dal budget.Occorre gestire le nuove configurazioni di sistema negoziando col cliente per i nuovi requisiti.

Pianificazione della gestione-Identificazione requisiti-Stabilire un processo di gestione dei requisiti-Policy per la tracciabilità-Utilizz un tool di supporto CASE

.Immagazzinamento dei requisiti

.Gestione dei cambiamenti

.Gestione della tracciabilitàLa tracciabilità è molto importante per i sistemi sw, se noi garantiamo un ottimo livello di tracciabilità questo si ripercuoterà sulla qualità dell’implementazione sw. Essa consiste nei rapporti tipo predecessore-successore oppure master-subordinato.

2018 Andrea Oian

Processo di DesignE’ un processo di risoluzione dei problemi il cui obiettivo è trovare e descrivere un modo per implementare il sistema funzionale dai requisiti, cercando di rispettare i vincoli imposti dalla qualità, dalla piattaforma e aderendo a principi generali di buona qualità.Il suo obiettivo è quello di produrre un modello o una rappresentazione pronta per essere discussa e costruita successivamente.

Le linee generali da seguire sono:♦ Esporre un'organizzazione modulare che rende intelligente l’uso del controllo tra i componenti♦ Logicamente partizionato in componenti che eseguono compiti specifici e attività secondarie♦ Descrivere sia i dati che le procedure♦ Porta a interfacce che riducono la complessità♦ Derivato utilizzando un metodo ripetibile guidato da informazioni raccolte durante i requisiti

Il processo di design per essere fatto correttamente ♦ Deve implementare tutti i requisiti espliciti contenuti nel modello di analisi, e deve ospitare tuttii requisiti impliciti voluti dal cliente.♦ Deve essere una guida comprensibile sia per quelli che generano il codice e per chi prova e successivamente supporta il software♦ Dovrebbe fornire un'immagine completa del software

Fasi di progettazione del processo♦ Comprensione dei problemi: Guardare il problema da diverse angolazioni ♦Identificare una o più soluzioni: valutare le possibili soluzioni e scegliere il più appropriato a seconda dell'esperienza del progettista e risorse disponibili♦ Descrivi le astrazioni della soluzione: Utilizzare notazioni grafiche, formali o di altra natura descrittiva a descrivere i componenti del design♦ Ripeti il processo per ogni astrazione identificata fino a quando il design è espresso in termini primitivi

Design come serie di decisioniI progettisti devono affrontare una serie di problemi di progettazione rappresentando sotto-problemi del problema di progettazione generale. Il designer prende una decisione per risolvere ogni problema scegliendo l'opzione migliore tra le alternative.Per prendere ogni decisione, il designer usa: Conoscenza dei requisiti, tecnologie disponibili, software, principi di progettazione e esperienza precedenti.

Passaggi di tecniche decisionali di base prioritarie1. Elencare e descrivere le alternative per la decisione progettuale e i loro pregi e difetti2. Determina se alcune alternative impediscono al sistema di soddisfare uno o più degli obiettivi

2018 Andrea Oian

3. Scegli l'alternativa che ti aiuta a soddisfare al meglio gli obiettivi4. Modifica le priorità per il successivo processo decisionale

Approccio al design♦ Top-down: In primo luogo progettare la struttura di livello molto alto del sistema, quindi procedere gradualmente verso decisioni dettagliate sul livello inferiore♦ Bottom-up: Prendere decisioni sulle utility di basso livello riutilizzabili, poi decidi come questi verranno messi insieme per creare un livello superiore♦ Misto: Il design top-down è quasi sempre necessario per fornire al sistema unbuona struttura, invece il design bottom-up è utile per essere riutilizzato su vari componenti.

Attività del design♦ Design dell'architettura: Divisione in sottosistemi e componenti e definizione di esse saranno connesse e interagiscono (ad es. le loro interfacce)♦ Progettazione dell'interfaccia utente♦ Design di componenti / classi

Rischi del designIl design è un'abilità che richiede una notevole esperienza, ovvero i singoli ingegneri del software non devono tentare la progettazione di grandi sistemi e gli architetti di software aspiranti dovrebbero studiare attivamente i progetti di altri sistemi.Inoltre disegni scadenti possono portare a costosi interventi di manutenzione.Il design richiede uno sforzo costante per garantire che il design del sistema software rimanga buono per tutta la sua durata, inoltre bisogna cercare di rendere il design il più flessibile possibile per anticipare i cambiamenti ed estensioni ed assicurarsi che la documentazione di progettazione sia utilizzabile e disponibile presso corretto livello di dettaglio.

Principi fondamentali del design

AstrazioniPermettono di concentrarsi sugli aspetti importanti di un problema ad un livello particolare senza l'ostacolo di dettaglio inutile o irrilevante.Inoltre permette la descrizione di un sistema come una struttura a strati ● Più alto è il livello, meno dettagli ● Più basso è il livello, più dettagli

RaffinamentoE’ un processo top-down in cui in ciascuna fase, uno o più istruzioni del programma in questione sono scomposte in istruzioni più dettagliate, l'idea di base è iniziare con una specifica di alto livello su come può essere un problema risolto, successivamente scomporlo in un numero limitato di problemi e per ciascuno di questi problemi fare lo stesso.Ripetere fino a quando i problemi secondari possono essere risolti immediatamente.Non è appropriato per sistemi distribuiti su larga scala ed è principalmente applicabile alla progettazione di metodi.

ModularitàUn modulo può essere definito in molteplici modi, ma di solito si tratta di un componente di un più vasto sistema, che opera in quel sistema indipendentemente dalle operazioni di altri componenti.I moduli forniscono una separazione tra le interfacce e la implementazione. Una interfaccia di un modulo esprime gli elementi che sono forniti e necessari al modulo. Gli elementi definiti in una interfaccia sono visibili agli altri moduli. L'implementazione contiene il codice operativo che corrisponde agli elementi dichiarati nell'interfaccia.Si basa su componenti separati integrati a risolvere i problemi. Permette di ridurre la complessità, facilitare il cambiamento. Un metodo di progettazione può essere chiamato "modulare" solo se esso supporta la scomponibilità modulare, la componibilità, comprensibilità, continuità e

2018 Andrea Oian

protezione. Si basa sull'uso di: unità modulari linguistiche, interfacce piccole ed esplicite e informazioni nascoste.

Requisiti di modularità♦ Scomposizione modulare: un problema software può essere suddiviso in un numero ridotto di meno problemi secondari complessi, collegati da una struttura semplice, e abbastanza indipendente da consentire ulteriori lavori per procedere separatamente su ciascun articolo♦ Componibilità modulare: alcuni elementi software possono essere combinati tra loro per produrre nuovi sistemi, possibilmente in diversi ambienti da quello in cui sono stati inizialmente sviluppati♦ Comprensione modulare: un lettore umano può comprendere ciascun modulo senza averloper conoscere gli altri, o, nel peggiore dei casi, dover esaminare solo alcuni degli altri♦ continuità modulare: un piccolo cambiamento nelle specifiche del problema attiverà amodifica di un solo modulo o di un numero ridotto di moduli♦ Protezione modulare

Principi di progettazione modulare ♦ Unità modulari linguistiche: i moduli devono corrispondere a unità linguistiche nella lingua usata ♦ Poche interfacce: ogni modulo dovrebbe comunicare con pochi altri ♦ Piccole interfacce: Se due moduli qualsiasi comunicano, dovrebbero scambiarsi il minor numero informazioni possibili ♦ Interfacce esplicite: se due moduli qualsiasi comunicano, deve essere ovvio (ad es deve essere descritto nella documentazione di progettazione) ♦ Nascondere informazioni: tutte le informazioni su un modulo devono essere private a meno che non sia specificamente dichiarato diversamente

CoesioneIn informatica, la coesione è una misura di quanto strettamente correlate siano le varie funzionalità messe a disposizione da un singolo modulo.Una forte coesione è desiderabile perché semplifica le operazioni sul codice(correzione, modifica ed estensione), riduce il test, promuove il riutilizzo; mentre la bassa coesione è spesso associata a caratteristiche non desiderabili come il rendere difficoltose la manutenzione, le verifiche, la riusabilità e la comprensibilità.

Tipi di coesione♦ Coesione coincidente: Gli elementi non sono correlati ma semplicemente raggruppati per comodità ♦ Coesione logica: Elementi che hanno risultati simili (ad es. hanno input e gestione degli errori simili)♦ Coesione temporale: Elementi attivati in un tempo comune, avere un comune avvio e arresto♦ coesione procedurale: Gli elementi costituiscono una stessa procedura♦ coesione comunicazionale: Gli elementi funzionano sullo stesso input, o producono la stessa uscita ♦ coesione sequenziale: Gli elementi condividono o operano su dati condivisi ♦ coesione funzionale: Elementi dedicati al raggiungimento di un requisito funzionale singolo ♦ Coesione degli oggetti

AccoppiamentoMisura di dipendenza di un modulo da un altro.♦ Con forte (stretto) accoppiamento, i moduli sono altamente dipendente da l'un l'altro♦ Con debole (libero) accoppiamento, i moduli sono in gran parte indipendente♦ nessun accoppiamento diretto♦ Accoppiamento dati♦ Accoppiamento del timbro♦ Accoppiamento di controllo♦ Giunto esterno♦ Accoppiamento comune

2018 Andrea Oian

♦ Legatura prematura♦ Accoppiamento di contenuti

Livelli di accoppiamento♦ nessun accoppiamento diretto: Nessuna dipendenza ♦ Accoppiamento dati: Solo i dati necessari vengono passati come argomenti ♦ Accoppiamento timbro (struttura dati): Le strutture dati vengono passate dall'elenco degli argomenti e solo da parti di loro sono usati ♦ Accoppiamento di controllo: Interfaccia passando flag e altri parametri ♦ Giunto esterno: Legami con dispositivi o driver di dispositivo ♦ Accoppiamento comune: Uso di variabili globali ♦ Legatura prematura: Uso di numeri e altri valori in tutto il programma ♦ Accoppiamento di contenuti: Modifica le istruzioni / i dati di un altro modulo

Tradeoff♦ Elevato accoppiamento- I componenti sono difficili da capire da soli -Le variazioni dei componenti si riflettono sugli altri -I componenti sono difficili da riutilizzare -Può ridurre i costi di prestazione♦ Basso accoppiamento -Può sostenere costi di prestazione -Generalmente più veloce per costruire e mantenere sistemi

Decomposizione del software Maggiore difficoltà di adattamento e manutenzione, è causato da: modifica dei requisiti, comunicazione e / o interruzione della documentazione. Per prevenire questo fenomeno: principi di progettazione della classe, principi di coesione del pacchetto,principi di accoppiamento della confezione.Segni di design in decomposizione♦ Rigidità:Codice difficile da modificare♦ Fragilità: Anche piccole modifiche possono causare effetti a cascata♦ Immobilità:Il codice è così intricato che è impossibile riutilizzare qualsiasi cosa♦ Viscosità:Molto più facile da hackerare

Principi di progettazione della classe orientata agli oggetti♦ SRP: il principio della responsabilità unica♦ OCP: il principio aperto chiuso♦ LSP: il principio di sostituzione di Liskov♦ ISP: il principio di segregazione dell'interfaccia♦ DIP: il principio di inversione di dipendenza

1)Principio della singola responsabilitàNella programmazione orientata agli oggetti, il principio di singola responsabilità afferma che ogni elemento di un programma (classe, metodo, variabile) deve avere una sola responsabilità, e che tale responsabilità debba essere interamente incapsulata dall'elemento stesso. Tutti i servizi offerti dall'elemento dovrebbero essere strettamente allineati a tale responsabilità.Una classe dovrebbe avere solo un motivo per cambiare quindi.Molte classi piccole con responsabilità distinte risultano con un design molto più flessibile.

2)Principio open-closeNella programmazione orientata agli oggetti il principio aperto/chiuso afferma che le entità (classi, moduli, funzioni, ecc.) software dovrebbero essere aperte all'estensione, ma chiuse alle

2018 Andrea Oian

modifiche; in maniera tale che un'entità possa permettere che il suo comportamento sia modificato senza alterare il suo codice sorgente. In particolare, una volta completata l'implementazione di un'entità, questa non dovrebbe essere più modificata, eccetto che per eliminare errori di programmazione. L'introduzione di nuove caratteristiche o la modifica di quelle esistenti dovrebbe richiedere la creazione di nuove entità.Ciò è particolarmente importante in un ambiente di produzione, in cui i cambiamenti al codice sorgente possono richiedere la revisione del codice, test di unità

3)Il principio di sostituzione di LiskovLe sottoclassi dovrebbero essere sostituibili per le loro classi base.Le classi derivate devono rispettare i contratti della loro base Classi e devono semplicemente estendersi senza sostituire le funzionalità delle classi base.In caso contrario, le classi derivate possono produrre effetti indesiderati.

4)Il principio di segregazione dell'interfaccia Molte interfacce specifiche per il cliente sono meglio di una interfaccia generale.Mantenere le interfacce snelle e focalizzate

5)Il principio di inversione di dipendenzaI moduli di alto livello non dovrebbero dipendere da quelli di basso livello. Entrambi dovrebbero dipendere dalle astrazioni. Le astrazioni non dovrebbero dipendere dai dettagli, sono i dettagli che dovrebbero dipendere dalle astrazioni.

Pacchetto di coesione♦ REP: il principio di equivalenza del riutilizzo del rilascio♦ CCP: il principio di chiusura comune♦ CRP: il principio del riuso comune

Rilasciare il principio di riutilizzo dell'equivalenza♦ Il granello di riutilizzo è il granello di rilascio● Tutte le classi di un pacchetto devono essere riutilizzabili o non riutilizzabili● Classi non correlate allo scopo del pacchettonon dovrebbe essere incluso● Un pacchetto costruito come una famiglia di classi riutilizzabili tende aessere più utile e riusabile

Principio di chiusura comune♦ Le classi che cambiano insieme appartengono insieme● Ridurre al minimo l'impatto delle modifiche per il programmatore♦ Le classi dovrebbero essere confezionate in modo coeso● Devono indirizzare la stessa area funzionale o comportamentale● Sono inseparabili e interdipendenti

Principio di riutilizzo comune♦ Le classi che non sono riutilizzate insieme non dovrebbero essereraggruppati insieme● Le classi raggruppate dovrebbero cambiare per lo stessomotivi● Evitare le dipendenze non necessarie per gli utenti

Principio dell'accoppiamento della confezione♦ ADP: il principio delle dipendenze acicliche: Non consentire cicli nel grafico delle dipendenze♦ SDP: il principio delle dipendenze stabili: Dipende dalla direzione della stabilità ● Le dipendenze tra i componenti di un disegno dovrebbero essere nella direzione della stabilità ● Un componente dovrebbe dipendere solo dai componenti che lo sono più stabile di quello

2018 Andrea Oian

♦ SAP: il principio delle astrazioni stabili: Un pacchetto dovrebbe essere tanto astratto quanto stabile● I pacchetti astratti dovrebbero essere responsabili e indipendenti(stabile)■ Facile da dipendere● I pacchetti di cemento dovrebbero essere irresponsabili e dipendenti(instabile)■ Facile da cambiare♦ Un'architettura ideale ha la seguente struttura● Pacchetti instabili (modificabili) in alto■ Deve essere concreto● Pacchetto stabile (difficile da cambiare) sul fondo■ Difficile da modificare, ma facile da estendere■ Altamente astratto (facilmente esteso)■ Le interfacce hanno una stabilità intrinseca maggiore rispetto al codice eseguibile

Buone attività di progettazione♦ Dividi e conquista● Cercare di occuparsi di qualcosa di grosso in una volta è normalmente moltopiù difficile di una serie di piccole cose♦ Aumentare la coesione ove possibile● Un sottosistema o modulo ha un'elevata coesione se si tiene insiemecose che sono legate l'una all'altra e tengono fuori altre cose♦ Ridurre l'accoppiamento laddove possibile● L'accoppiamento si verifica quando vi sono interdipendenze tra unamodulo e un altro♦ Mantieni il livello di astrazione più alto possibile● Assicurarsi che i disegni consentano di nascondere o differire la considerazione didettagli, riducendo così la complessità

Elenco dei principi di progettazione♦ Aumentare la riusabilità ove possibile: Progettare i vari aspetti del sistema in modo che possano essere usato di nuovo in altri contesti♦ Riutilizzare disegni e codici esistenti laddove possibile: Il design con riutilizzo è complementare al design per la riusabilità♦ Design per flessibilità: Prevedere attivamente le modifiche a cui un progetto potrebbe dover essere sottoposto in futuro ♦ Anticipare l'obsolescenza: Pianificare le modifiche alla tecnologia o all'ambiente in modo cheil software continuerà a funzionare o può essere facilmente modificato♦ Design per la portabilità: Fai girare il software sul maggior numero possibile di piattaforme♦ Design per testabilità: Adottare misure per facilitare i test♦ Progettare in modo difensivo: Non fidarti mai di come gli altri cercheranno di usare un componente come è stato progettato

Design ArchitetturaleSi occupa di comprendere come un sistema software debba essere organizzato e di designare lasua struttura complessiva.Rappresenta il legame critico tra il design e l'ingegneria dei requisiti. Identifica i principalicomponenti strutturali di un sistema e le relazioni che intercorrono tra di essi.Ciò che si ottiene è un modello architetturale che descrive come il sistema è organizzato secondoun insieme di componenti che comunicano tra di loro.Generalmente, i primi passaggi di un processo Agile è di designare una architettura complessiva del sistema.Esso identifica un modello di sistema software cioè i suoi componenti le loro interazioni e le loro interconnessioni.

2018 Andrea Oian

E’ definito da descrizioni informali o formali, scatole e linee o prosa informale o diagrammi UMLBasato su un vocabolario condiviso, semanticamente ricco.Architettura software = {Elementi, modulo, logica}L'architettura del software coinvolge:

-Descrizione degli elementi da cui sono stati costruiti i sistemi-Interazioni tra questi elementi-Modelli che guidano la loro composizione-Vincoli su questi modelli

L'architettura del software si occupa di astrazione, decomposizione, composizione, stile ed estetica di un sistema e del design e implementazione della struttura di alto livello di un sistema.

Concetti architetturali(Cosa sono sistemi e moduli)Un sottosistema è un sistema a sé stante, la cui funzione è (in gran parte) indipendente dai servizi fornito da altri sottosistemiUn modulo è un componente di sistema che fornisce servizi ad altri componenti ma normalmente non sarebbero considerato come un sistema separatoTre blocchi canonici●Componenti● Connettori● Configurazioni

ComponentiSono unità di calcolo o archivi di dati: clienti, server, database, filtri, livelli.Può essere semplice o composito

ConnettoriSono elementi architettonici che modellano: interazioni tra componenti, possono essere:♦ Interazioni semplici: chiamate di procedura,accesso alle variabili condivise♦ Interazioni complesse e semanticamente ricche: Protocolli client-server, Protocolli di accesso al database, Multicast di eventi asincroni, Streaming di dati convogliati

ConfigurazioniSono collegamenti grafici di componenti e connettori che descrivono la struttura architettonica che identifica.

Vantaggi di un'architettura esplicita• Comunicazione con le persone interessate: L'architettura può essere utilizzata come centro di discussione per sistema le parti interessate• Analisi del sistema: Significa analizzare se il sistema è in grado di soddisfare i suoi requisiti non funzionali• Riutilizzo su vasta scala: L'architettura può essere riutilizzabile in una vasta gamma di sistemi

Diagramma box and lineSi tratta di diagrammi semplici ed informali che mostrano i sottosistemi e le relazioni cheintercorrono tra di essi. Non hanno una semantica, in quanto non mostrano le tipologie direlazioni né le proprietà visibili dei sottosistemi.

Modelli architetturali UML♦ Package diagrams ♦ Component diagrams ♦ Deployment diagrams

A cosa è utile un modello architetturale?E’ utile come mezzo per facilitare la discussione sul sistema design

2018 Andrea Oian

È utile una vista architetturale di alto livello di un sistema comunicazione con le parti interessate del sistema.Gli stakeholder possono collegarsi ad esso e comprendere una visione astratta del sistema, possono quindi discutere il sistema nel suo complesso senza essere confusi da dettaglio.L'obiettivo qui è quello di produrre un modello di sistema completo mostra i diversi componenti in un sistema, le loro interfacce e le loro connessioni.

Decisione di design architetturaleSi tratta di un processo creativo che differisce in base al tipo di sistema che deve esseresviluppato.Tuttavia, alcune decisioni sono comuni in tutti i processi di design. Queste decisioni riguardano lecaratteristiche non funzionali del sistema.

Architettura e requisiti non funzionali• Prestazioni◦ Identificare le operazioni critiche e minimizzare le comunicazioni◦ Preferire componenti più grandi• Sicurezza◦ Utilizzare una architettura a strati, in cui le attività più critiche si trovano negli strati piùinterni◦ Localizzare problemi per la sicurezza in un numero ristretto di sottosistemi• Disponibilità◦ Includere componenti ridondanti e meccanismi di tolleranza all'errore• Manutenibilità◦ Utilizzare componenti sostituibili

Viste dell'architettura software• La logical view mostra le astrazioni chiave del sistema come oggetti o classi di oggetti,• La process view mostra come, a runtime, il sistema è composto da processi cheinteragiscono tra di loro,• La development view mostra come il software viene scomposto per lo sviluppo,• La physical view mostra l'hardware del sistema e come le componenti software sianodistribuite lungo i processori o i nodi del sistema

Scelta del sottosistemaI sottosistemi dovrebbero fornire un'elevata coesione, la maggior parte delle interazioni dovrebbe essere all'interno di sottosistemi, rispetto ai confini del sottosistema. I sottosistemi dovrebbero fornire un accoppiamento basso. Una modifica in un sottosistema dovrebbe avere effetti limitati sugli altri sottosistemiAssegna gli oggetti identificati in un caso d'uso nello stesso sottosistema.Tutti gli oggetti nello stesso sottosistema dovrebbero essere funzionalmente relazionati.

Layering and partitioningSono tecniche per ottenere un accoppiamento basso, Un grande sistema è solitamente scomposto in sottosistemi utilizzando entrambi i livelli e le partizioni. Il layering divide un sistema in più ordinati sottosistemi (livelli) in cui ogni livello fornisce servizi al suo strato superiore (livello di astrazione). Un livello può dipendere solo da livelli inferiori e uno strato non ha conoscenza dei livelli superiori. Il partizionamento divide un sistema o uno strato in più sottosistemi indipendenti (debolmente accoppiati).

Riutilizzo dell'architetturaSpesso i sistemi all'interno dello stesso dominio hanno architetture simili che riflettono alcune ideelegate al dominio stesso.Le linee di prodotti applicativi sono costruite attorno ad un'architettura centrale con alcunevarianti atte a soddisfare particolari requisiti degli utenti.

2018 Andrea Oian

L'architettura di un sistema può essere progettata attorno ad uno o più pattern architetturali ostili.

Pattern architetturaliSi tratta di descrizioni stilizzate di pratiche di buon design che sono state provate e testate inambienti differenti. Dovrebbero includere informazioni su quando possono o no tornare utili.Dovrebbero essere rappresentate utilizzando tabelle e descrizioni grafiche.

Principali pattern architetturali• Model-View-Controller (MVC)• Layered architecture• Repository architecture• Client-server architecture• Pipe and filter architecture

Model-View-ControllerSepara la rappresentazione e l'interazione dai dati del sistema.È struttrata in tre componenti logiche che interagiscono tra di loro:• Model: è la componente che gestisce i dati del sistema e le operazioni associate• View: è la componente che definisce e gestisce il modo in cui i dati vengono presentatiall'utente• Controller: è la componente che gestisce le interazioni con l'utente e le passa a View eModelSi utilizza quando ci sono diversi modi per vedere i dati ed interagire con essi.Permette che i dati possano cambiare indipendentemente dalla loro rappresentazione, eviceversa. Tuttavia può comportare la presenza di codice aggiuntivo, e di conseguenza una maggiorecomplessità, quando i modelli dei dati e delle interazioni sono semplici.

Layered ArchitectureOrganizza il sistema in un insieme di livelli (o macchine astratte). Ciascun livello fornisce alcuniservizi a quelli sopra.Normalmente, i livelli più bassi rappresentano servizi principali che potrebbero essere usatiattraverso tutto il sistema.Si utilizza quando si creano nuove funzionalità su sistemi già esistenti, quando lo sviluppo è divisotra diversi team ciascuno dei quali si occupa di un certo livello o di certe funzionalità, oppurequando è richiesta una sicurezza multi-livello.Tuttavia, è difficile fornire una chiara separazione tra i livelli. Livelli alti potrebbero doverinteragire direttamente con quelli più bassi. Possono esserci problemi di prestazioni a causa deidiversi livelli di interpretazioni di una richiesta di servizio poiché viene processata a ciascun livello.

Repository ArchitectureTutti i dati del sistema sono gestiti in un repository centrale, che è accessibile a tutte lecomponenti del sistema. Queste componenti non possono interagire tra di loro direttamente masolo attraverso il repository.Si utilizza quando vengono generati grandi volumi di informazioni che devono essere memorizzateper lungo tempo o quando l'inserimento dei dati in un repository attiva un'azione o uno strumento.Le componenti possono essere indipendenti in quanto non hanno bisogno di conosceredell'esistenza l'uno degli altri. I cambiamenti dei dati possono essere propagate a tutte lecomponenti. Inoltre, tutti i dati possono essere gestiti in maniera consistente poiché si trovanotutti nello stesso luogo.Tuttavia, spesso è inefficiente gestire le comunicazioni attraverso il repository che può ancheessere difficile da distribuire attraverso numerosi computer.

2018 Andrea Oian

Client-Server architectureLe funzionalità del sistema sono organizzate in servizi, ciascuno dei quali può essere consegnatoad un server separato. I client sono gli utenti di questi servizi ed accedono ai server perutilizzarli.Si utilizza quando è necessario accedere ai dati da diversi luoghi. Inoltre, dal momento che iserver possono essere duplicati, può essere utilizzato quando il carico di un sistema è variabile.I server possono essere distribuiti attraverso una rete. Le funzionalità generali possono esseredisponibili a tutti i clienti e non è necessario che siano implementate in tutti i servizi.Tuttavia, ogni servizio rappresenta un punto di errore che può essere soggetto ad attacchi Ddos oaltri errori server. Le prestazioni potrebbero essere imprevedibili poiché dipendono dalla rete oltreche dal sistema. Potrebbero, inoltre, esserci problemi di gestioni se i server sono posseduti daorganizzazioni diverse.

Pipe and Filter architectureIl processing dei dati in un sistema è organizzato in una sequenza di componenti. Ognicomponente, detta filtro, effettua un tipo di trasformazione dei dati. I dati fluiscono da unacomponente ad un'altra per essere processati.Si utilizza nelle applicazioni di processing dei dati quando gli input sono gestiti in passaggi separatiper generare i rispettivi output.È facile da comprendere e supporta il riutilizzo, il workflow corrisponde alla struttura di moltiprocessi lavorativi. L'evoluzione ottenuta aggiungendo trasformazioni è lineare. Può essereimplementato sia come sistema sequenziale che concorrente.Tuttavia, è necessario accordarsi per il formato da utilizzare per il trasferimento dei dati. Ognitrasformazione deve decodificare il proprio input e codificare l'output nel formato che è statoaccordato con un impatto significativo sulle prestazioni.

Application ArchitecturesI sistemi applicativi devono essere progettati in modo da soddisfare le necessità dell'organizzazione.Poiché le attività commerciali hanno molto in comune, i loro sistemi di applicazioni tendono adavere una architettura simile.Un'architettura generica è un'architettura per una tipologia di sistema software che può essereconfigurata e adattata per creare un sistema che soddisfi specifici requisiti.Utilizzi• Come punto di partenza per la progettazione dell'architettura,• come checklist per la progettazione,• come modo per organizzare il lavoro del team di sviluppo,• come mezzo per valutare le componenti per un possibile riutilizzo,• come vocabolario per discutere delle tipologie di applicazioni.Esempi• Applicazioni di data processing,• Applicazioni di transaction processing,• Sistemi di event processing,• Sistemi di language processing.

Tecniche di controllo Software

Design centralizzato vs Design decentralizzato

2018 Andrea Oian

• Centralizzato: vi è un control object o un sottosistema (detto spider) che controlla tutto. Inquesto caso è molto semplice cambiare la struttura di controllo, tuttavia la presenza di unsolo control object può costituire un collo di bottiglia per quanto riguarda le prestazioni.• Decentralizzato: il controllo è distribuito. Ciò si presta molto bene allo sviluppo object oriented.

Come scegliereSi prende il sequence diagram e i control object dal modello di analisi e si guarda come questipartecipano nel sequence diagram:• se il diagramma presenta dei bivi, si usa il centralized design• se sembra una scala, si usa un design decentralizzato.

Progettazione dell'Interfaccia UtenteGli utenti tendono a giudicare un sistema dalla sua interfaccia piuttosto che dalle sue funzionalità.Un'interfaccia grafica povera o mal progettata può portare l'utente a commettere gravi errori ecostituisce il motivo principale per cui molti sistemi software non vengono mai usati.L'interfaccia utente dovrebbe essere progettata in modo da incontrare le capacità, l'esperienza e le aspettative degli utenti.I progettisti dovrebbero essere a conoscenza delle limitazioni fisiche e mentali delle persone edovrebbero riconoscere che le persone possono commettere errori. Quando le persone commettono errori e i sistemi vanno male, allarmi e messaggi inappropriati possono aumentare lo stress e quindi la probabilità di più errori.Le persone sono diverse e hanno una vasta gamma di capacità fisiche e diverse preferenze di iterazione con la macchina, per questo il progettista non deve progettare solo per se stesso ma soprattutto per gli altri.La progettazione dovrebbe basarsi su alcuni principi ben conosciuti:• familiarità dell'utente: l'interfaccia dovrebbe basarsi su termini e concetti rivolti all'utente• consistenza: il sistema dovrebbe mostrare un livello di coerenza appropriato,• sorpresa minima: se un comando opera in un modo conosciuto, l'utente è in grado diprevedere le operazioni di comandi simili,• recuperabilità: il sistema dovrebbe fornire un certo livello di capacità di recupero daglierrori commessi dagli utenti,• guida per l'utente: è bene fornire alcune guide per l'utente, come manuali online o simili,• diversità dell'utenza: occorre fornire funzionalità per l'interazione di diverse tipologie dutenti.

Altri principi di progettazione♦ Mappatura del mondo reale: corrisponde a layout familiari♦ Coerenza: le caratteristiche comuni dovrebbero rimanere nella stesso posto, lavora allo stesso modo♦ Personalizzazione: offre agli utenti esperti funzionalità più efficienti♦ Trasparenza♦ Contiguità♦ Caricamento memoria: ricorda all'utente i dettagli♦ Controllo dell'utente: identificare il soggetto responsabile delle azioni♦ Parla la lingua dell'utente: istruzioni comprensibili,feedback, messaggi di errore ...

Problema di interazione del sistema utente♦ Come devono essere fornite le informazioni dell'utente al sistema informatico?♦ Come dovrebbero essere le informazioni dal sistema informatico presentato all'utente?

Metafore nella progettazione dell'interfaccia utente

2018 Andrea Oian

Una serie di immagini, azioni e procedure dell'interfaccia utente che sfruttano le conoscenze specifiche che gli utenti hanno già di altri domini, può aiutare gli utenti a sviluppare un modello mentale e dovrebbe essere semplice da capire per l’utente.

Elementi dell interfaccia grafica♦ finestre: consentono a diverse informazioni di essere visualizzate contemporaneamentesullo schermo dell'utente♦ icone: rappresentano diversi tipi di informazioni♦ Menu e pulsanti: sono usati per selezionare i comandi♦ Puntamento: sono utilizzati per selezionare le scelte da un menu o per indicare elementidi interesse in una finestra♦ Elementi grafici: possono essere combinati con il testo nella stessa finestra

Tipi di interazione♦ Manipolazione diretta: Videogiochi, sistemi CAD.Gli utenti si sentono in controllo del computer ed è meno probabile che si sentano intimiditi da questo. Il tempo di apprendimento degli utenti è relativamente breve. Gli utenti ottengono un feedback immediato sulle loro azioni così gli errori possono essere rapidamente rilevati e correttiLe interfacce di manipolazione diretta possono essere complesse e il programma fa richiesta di risorse pesanti♦ Selezione del menu: usato dalla maggior parte dei sistemi per uso generico.Gli utenti non devono ricordare i nomi dei comandi, così Evita all'utente errori di digitazione.Gli errori degli utenti sono intrappolati dall'interfaccia. I sistemi di menu sono più adatti per presentare un piccolo numero di scelte. Gli utenti esperti trovano i menu più lenti del comando a linguaggio♦ compilazione modulo: Semplice inserimento dei dati, facile da impar are e controllabile ma Prende molto spazio sullo schermo.♦ Linguaggio di comando: Può essere implementato utilizzando terminali economici.I comandi di complessità arbitraria possono essere creati da combinazione di comandiÈ possibile creare interfacce concise che richiedono una digitazione minimaGli utenti devono imparare e ricordare una lingua di comando, quindi le interfacce di comando non sono adatte a volte agli utenti.♦ linguaggio naturale: Accessibile agli utenti occasionali e può essere esteso facilmente. In generale, il vocabolario è limitato e questi sistemi sono confinati in domini specifici.La tecnologia di elaborazione non è abbastanza buona per fargli interfacce efficaci per utenti occasionali.

Rappresentazione dell'informazioneSi occupa di stabilire come l'informazione debba essere presentata agli utenti. Questa può essererappresentata direttamente o trasformata.L'approccio Model-View-Controller è un modo per supportare una rappresentazione multipla deidati.

Rappresentazione analogica e digitale• Rappresentazione digitale: compatta, poiché richiede poco spazio sullo schermo e precisa.• Rappresentazione analogica: è più semplice avere un'impressione a colpo d'occhio di unvalore, può mostrare i valori relativi ed è più semplice individuare valori di dati eccezionali.

Utilizzo del coloreIl colore può aggiungere una dimensione extra ad un'interfaccia e può aiutare l'utente acomprendere strutture complesse. Può essere utile anche per evidenziare eventi eccezionali.Spesso si commettono errori come utilizzare un colore per comunicare un significato o utilizzarnetroppi.Linee guida• Limitare il numero di colori usati ed essere parsimoniosi nel loro utilizzo,

2018 Andrea Oian

• Utilizzare cambiamenti di colore per mostrare cambiamenti nello stato del sistema,• Utilizzare una codificazione del colore per supportare l'operazione che l'utente sta cercando di effettuare,• La codificazione del colore va utilizzata in maniera coerente,• Prestare attenzione agli accoppiamenti di colore.

Messaggi d'erroreÈ estremamente importante una corretta rappresentazione di un messaggio d'errore. Questimessaggi devono essere gentili, precisi, coerenti e costruttivi.Il background e l'esperienza degli utenti dovrebbe essere un fattore determinante nellaprogettazione di questi messaggi.Linee guida• Contesto: Laddove possibile, il messaggio generato dal sistema dovrebbe riflettere l'attualecontesto utente.• Esperienza: Messaggi di errore molto lunghi possono infastidire l'utente a mano a mano cheguadagna familiarità col sistema. Tuttavia, i principianti potrebbero trovare difficoltà nel comprendere brevi messaggi d'errore,Entrambi i tipi di messaggio, quindi, dovrebbero essere disponibili lasciando che sial'utente a scegliere• Livello di competenza: I messagi dovrebbero essere costruiti sulle capacità dell'utente• Stile: I messaggi dovrebbero essere positivi• Cultura: Laddove possibile, i messaggi dovrebbero tenere conto della cultura del Paese in cui ilsistema viene venduto.

Valutazione dell'interfaccia utenteLa valutazione completa è molto costosa e poco pratica per la maggior parte dei sistemiquindi un'interfaccia dovrebbe essere valutata rispetto a una specifica di usabilità:♦ Apprendibilità: Quanto tempo impiega un nuovo utente a diventare produttivo con sistema?♦ Velocità di funzionamento: Quanto bene la risposta del sistema corrisponde al lavoro dell'utente?♦ robustezza: Quanto è tollerante il sistema agli errori dell'utente?♦ recuperabilità. Quanto è buono il sistema in fase di recupero dagli errori degli utenti?♦ adattabilità: Quanto è strettamente legato il sistema a un singolo modello di lavoro?

Tecniche di valutazione♦Recensioni di esperti♦ Questionari per il feedback degli utenti♦ Registrazione video dell'uso del sistema ♦ La fornitura di un pulsante di presa per il feedback degli utenti in linea♦ Test di usabilità competitivi

Design patternsL'utilizzo di modelli si rivolge principalmente alle nostre limitate capacità mentali (la nostramemoria a breve termine ha una capacità limitata). Un buon modello, quindi, è in grado di farefronte a questa limitazione riducendo la complessità, utilizzando astrazioni e strutture organizzative.

Ridurre la complessità dei modelliPer comunicare informazioni relative ad un modello complesso utilizziamo la navigazione e lariduzione della complessità: non ci limitiamo ad utilizzare un immagine presa dai tool CASE edarla all'utente, la chiave è navigare attraverso il modello in modo che l'utente possa seguirlo.Si parte con un modello molto semplice, basato su delle astrazioni chiave. Successivamente siarricchisce il modello con classi aggiuntive.Per ridurre ulteriormente la complessità del modello, si cercano le eredità (tassonomie),successivamente si identificano o introducono dei pattern.

2018 Andrea Oian

Strutture di Design ricorrentiI sistemi orientati agli oggetti ben definiti mostrano strutture ricorrenti che favorisconoastrazione, flessibilità, modularità ed eleganza.Queste strutture sono un'importante conoscenza di design per lo sviluppo di qualsiasi sistema. Ilproblema sta nel trovare i mezzi corretti per comunicare ed applicare questa conoscenza.

Design patternSi tratta di una soluzione ricorrente ad un problema standard. Descrive un problema che si verificaspesso all'interno dell'ambiente.Descrive il nucleo della soluzione a quel problema in modo che quella soluzione possa essereriutilizzata più volte.I design pattern (o software pattern) sono formati da quattro parti:• nome• problema• soluzione• conseguenze e compromessi della sua applicazioneIl pattern è indipendente dal linguaggio utilizzato e dalla sua implementazione e non offreun'applicazione meccanica.

Obiettivi dei design patternCodificare un buon design, fornire alle strutture di design un nome esplicito(complessità ridotta e maggiore espressività), catturare e preservare le informazioni relative al design(migliora la documentazione) e facilitare la ricostruzione e il refactoring.

Classificazione dei Design pattern• Pattern creazionali: I pattern creazionali risolvono problematiche inerenti l'istanziazione degli oggetti• Pattern strutturali: formano strutture più grandi partendo da singole parti, possono esserediversi dipendentemente dalla struttura e il suo scopo,• Pattern comportamentali: I pattern comportamentali forniscono soluzione alle più comuni tipologie di interazione tra gli oggetti• Object pattern (a runtime): permettono l'interazione di diverse classi che vanno usate nellostesso posto in un pattern• Class pattern (a runtime): utilizza l'ereditarietà per stabilire delle relazioni, che vengonogeneralmente durante la compilazione.

Pattern compositi(Strutturale)Questo pattern permette di trattare un gruppo di oggetti come se fossero l'istanza di un oggetto singolo. Il design pattern Composite organizza gli oggetti in una struttura ad albero, nella quale i nodi sono delle composite e le foglie sono oggetti semplici.

2018 Andrea Oian

Adapter pattern(Strutturale)Converte l'interfaccia di una classe in un'altra interfaccia come voluta dal cliente.È utilizzabile quando una classe già esistente fornisce alcuni (o tutti) dei requisiti richiesti ma nonimplementa l'interfaccia richiesta.

Bridge pattern(Strutturale)Separa un'intefaccia di astrazione dalla sua implementazione fisica.Si applica quando interfaccia e implementazione variano indipendentemente.

Decorator pattern(Strutturale)Ha l’intento di estendere (decorare) la funzionalità di un determinato oggetto staticamente o in fase di esecuzione. Si utilizza quando è utile aggiungere / rimuovere responsabilità individuali in modo trasparente, cioè senza influenzare altri oggetti.

Ravioli design

2018 Andrea Oian

Struttura ideale di un sottosistemaUn sottosistema è formato da:• l'interfaccia oggetto• un insieme di oggetti del dominio dell'applicazione (entity objects) che modellano entità reali o sistemi esistenti• uno o più control object

Façade pattern(Srutturale)Letteralmente façade significa "facciata", ed infatti nella programmazione ad oggetti indica un oggetto che permette, attraverso un'interfaccia più semplice, l'accesso a sottosistemi che espongono interfacce complesse e molto diverse tra loro, nonché a blocchi di codice complessi.Si utilizza per fornire un'interfaccia semplice ad un sottosistema complesso e per disaccoppiarele classi di un sottosistema da altri sottosistemi.

Proxy Pattern(Strutturale)Nella sua forma più generale, un proxy è una classe che funziona come interfaccia per qualcos'altro. L'altro potrebbe essere qualunque cosa: una connessione di rete, un grosso oggetto in memoria, un file e altre risorse che sono costose o impossibili da duplicare.Fornisce un surrogato o un segnaposto per un altro oggetto per controllarne l'accesso.Protegge il componente reale da un'eccessiva complessità aggiungendone una copertura.Si utilizza quando si vuole controllare l'accesso ad un oggetto o quando c'è bisogno di unriferimento sofisticato ad un oggetto.

Tipologie di Proxy Pattern• Virtual proxy• Cache proxy• Remote proxy• Protection proxy• Smart referenceEsecuzione flessibileA volte è necessario indirizzare delle richieste agli oggetti senza sapere nulla riguardo l'operazionerichiesta.Nel toolkit per l'interfaccia utente o nelle librerie dei widget sono inclusi bottoni e menu cheeffettuano una richiesta corrispondente all'input dell'utente.Bottoni e menu non possono implementare esplicitamente l'azione, poiché solo un'applicazioneconosce ciò che dovrebbe essere fatto e con quale oggetto.

Command pattern(Comportamentale)Il Command pattern è uno dei design pattern che permette di isolare la porzione di codice che effettua un'azione (eventualmente molto complessa) dal codice che ne richiede l'esecuzione; l'azione è incapsulata nell'oggetto Command. L'obiettivo è incapsulare la richiesta di un servizio.

Observer pattern(Comportamentale)Sostanzialmente il pattern si basa su uno o più oggetti, chiamati osservatori o observer, che vengono registrati per gestire un evento che potrebbe essere generato dall'oggetto "osservato", che può essere chiamato soggetto.Definisce una dipendenza uno-a-molti tra gli oggetti in modo che quando un oggetto cambia il suo

2018 Andrea Oian

stato, tutte le dipendenze vengono notificate ed aggiornate.

Comportamento flessibileMolte classi correlate differiscono solamente nel loro comportamento piuttosto chenell'implementare le diverse astrazioni.Diverse varianti di un algoritmo possono essere usate per risolvere un problema.Una classe definisce numerosi comportamenti che appaiono come diverse dichiarazionicondizionali.

Strategy Pattern(Comportamentale)Definisce una famiglia di algoritmi e li rende intercambiabili in modo che i client e gli algoritmipossano cambiare indipendentemente.E’ utile in quelle situazioni dove è necessario modificare dinamicamente gli algoritmi utilizzati da un'applicazione

Template method pattern(Comportamentale)Fornisce uno scheletro di un algoritmo in un metodo, lasciando alle sottoclassi il compito di implementare alcuni passi come preferiscono.Si applica per implementare gli aspetti invarianti di un algoritmo un'unica volta e lasciare che sianole sottoclassi a definire gli aspetti che cambiano. Si usa per individuare un comportamento comunein una classe in modo da incrementare il riutilizzo di codice.

Creazione flessibileSpesso è necessario nascondere come gli oggetti sono creati in modo da rendere il sistemaindipendente. La classi da istanziare possono essere conosciute solo a runtime.

Abstract factory pattern(Creazionale)Fornisce un'interfaccia per creare famiglie di oggetti connessi o dipendenti tra loro, in modo che non ci sia necessità da parte degli utilizzatori di specificare i nomi delle classi concrete all'interno del proprio codice.

Singleton Pattern(Creazionale)Ha l’intento di assicurati che una classe abbia solo un'istanza e fornisca un globale punto di accesso ad esso.

Builder pattern(Creazionale)Separa la costruzione di un oggetto complesso dalla sua rappresentazione in modo che lo stessoprocesso di costruzione possa creare rappresentazioni differenti.Si applica quando l'algoritmo per la creazione di un oggetto complesso dovrebbe essereindipendente dalle parti che compongono l'oggetto stesso ed il modo in cui sono assemblati, oquando il processo di costruzione deve consentire diverse rappresentazioni per l'oggetto costruito.

Requisiti non funzionali e design patternI requisiti non funzionali vengono descritti da:• abstract factory pattern: “manufacture/device independent” o “must support a family ofproducts”• Adapter pattern: “must interface with existing objects”• Strategy pattern: “must provide a policy independent from the mechanism”lOMoARcPSD• Façade pattern: “must interface to existing set of objects”• Composite pattern: “complex structure”, “must have variable depth and width”• Proxy pattern: “must be location trasparent”• Bridge pattern: “must interface to several systems”, “some of them to be developed in the

2018 Andrea Oian

future”, “an early prototype must be demonstrated”• Observer pattern: “must be extensible/scalable”

Design anti-patternDescrivono situazioni che è meglio evitare.Definiscono un modo molto conosciuto e per identificare e prevenire errori comuni e problemi neldesign del software.Descrive contromisure conosciute e testate ad una soluzione anti-pattern.Esempi di anti-patternClassi che detengono troppe responsabilità, lava flow, classi con poche responsabilità ed una vitabreve, soluzioni che non risolvono il problema, soluzioni quasi identiche in posti differenti,interfacce di classi troppo complesse.

Progettazione object-orientedL'obiettivo della progettazione orientata agli oggetti è quello di preparare per l'implementazioneIl modello, trasformarlo, ottimizzarlo e ricercare modi alternativi per implementarlo.

Differenze tra analisi dei requisiti e object designNell'analisi dei requisiti, il modello funzionale e quello dinamico forniscono le operazioni perl'object model. L'object design aggiunge dettagli all'analisi dei requisiti, funge da base per l'implementazione e permette di prendere decisioni per l'implementazione stessa.Obiettivi dell'object design sono:• Riutilizzare le conoscenze acquisite con esperienze precedenti,• Riutilizzare le funzionalità già disponibili,• Supportare la definizione di un implementazione del sistema che garantisca robustezza edadattabilità.

Activities dell'object design• Identificazione delle soluzioni esistenti e utilizza ereditarietà e design pattern• Specifiche dell'interfaccia, descrivere precisamente tutte le interfacce delle classi• Ristrutturazione e ottimizzazione dell'object model

Tecniche di riutilizzo• Eredità• Delegazione• Classi astratte e method overriding• Intefacce

RefactoringIn ingegneria del software, il refactoring (o code refactoring) è una "tecnica strutturata per modificare la struttura interna di porzioni di codice senza modificarne il comportamento esterno", applicata per migliorare alcune caratteristiche non funzionali del software. I vantaggi che il refactoring persegue riguardano in genere un miglioramento della leggibilità della manutenibilità, della riusabilità e dell'estendibilità del codice e la riduzione della sua complessità, eventualmente attraverso l'introduzione a posteriori di design pattern. Il refactoring è un elemento importante delle principali metodologie emergenti di sviluppo del software (soprattutto object-oriented): per esempio delle metodologie agili, dell'extreme programming, e del test driven development.

EreditarietàNuove funzionalità sono ottenute per ereditarietà. Si può riutilizzare l'implementazione o le interfacce.Implementazione dell’ereditarietà(inheritance)Anche detta class inheritance, il suo obiettivo è estendere le funzionalità di un'applicazione riusando le funzionalità della superclasse. Eredita, quindi, da una classe esistente di cui sono stateimplementate alcune (o tutte) le operazioni.

2018 Andrea Oian

Specification inheritanceDetta anche subtyping, l'obiettivo è quello di ereditare da una specificazione, che costituisce unaclasse astratta le cui operazioni sono state tutte specificate ma non ancora implementate.

Usi dell'ereditarietà• Organizzazione (durante l'analisi)• Riutilizzo (durante la progettazione degli oggetti):ci aiuta a riutilizzare il modelli ed il codice

L'ereditarietà può essere identificata con:• Generalizzazione: la relazione di ereditarietà tra due classi viene trovata a partire dallasottoclasse• Specializzazione: la relazione viene trovata partendo dalla superclasse

GeneralizzazioniPrima troviamo le sottoclassi, quindi la superclasse. Questo tipo di scoperta si verifica spesso nella scienza e ingegneria, ad esempio, prima troviamo singoli animali (elefante, leone, tigre, ...), poi scopriamo che questi animali hanno qualcosa in comune proprietà (mammiferi). Ad es., Quali sono le proprietà comuni delle automobili e aeroplani?

SpecializzazioniPrima troviamo la superclasse, quindi la sottoclasse. Questo tipo di scoperta si verifica quando troviamo la sottoclasse che è molto simile a una classe esistente. Ad esempio, uno sviluppatore aggiunge un nuovo stereotipo grafico a un UML sistema di modellazione.

ComposizioneNuove funzionalità sono ottenute per aggregazione. Un nuovo oggetto con più funzionalità vienecreato come aggregazione di oggetti esistenti.

DelegazioneSi tratta di un modo per rendere la composizione tanto potente per il riutilizzo quanto l'ereditarietà.Due oggetti si ritrovano a gestire una richiesta da un client:• l'oggetto ricevente delega le operazioni all'oggetto delegato• l'oggetto ricevente si assicura che il client non utilizzi l'oggetto delegato in maniera scorretta

Delegazione vs ereditarietàDelegazione: ha più flessibilità, cioè un qualsiasi oggetto può essere sostituito in fase di esecuzione da un altro (purché abbia lo stesso tipo), ma è più inefficiente.Ereditarietà: è semplice da usare ed è supportato da molti linguaggi di programmazione, ma espone una sottoclasse ai dettagli della sua classe genitore e un qualsiasi cambiamento nell'implementazione della classe genitore costringe la sottoclasse a cambiare.

Metodi e classi astrattiNella programmazione orientata agli oggetti una classe astratta è una classe che definisce una interfaccia senza implementarla completamente. Questo serve come base di partenza per generare una o più classi specializzate aventi tutte la stessa interfaccia di base.Un metodo astratto è un metodo privo di implementazione. Una classe astratta è una classe che contiene almeno un metodo astratto.Un'interfaccia è una classe astratta costituita solamente da metodi astratti.

Metodi riscrivibili e ereditarietà strettaUn metodo riscrivibile è un metodo che permette una sua reimplementazione.L'eredità stretta impone che le sottoclassi possano solamente aggiungere nuovi metodi allesuperclassi.

Contrazione (contraction)

2018 Andrea Oian

L'obiettivo è quello di rendere invisibili le operazioni della superclasse. Andrebbe evitata ad ogni costo, ma viene spesso utilizzata.Una classe contratta porta le funzionalità desiderate dal cliente ma la superclasse contiene delleoperazioni che non hanno senso in quella classe e la sottoclasse non rientra nella tassonomia della superclasse. Inoltre viola i pincipi della sostituzione di Liskov.

FrameworksUn framework è una applicazione parzialmente riutilizzabile che può essere specializzata per produrre applicazioni personalizzate. I benefici principali dell'utilizzo dei framework sono la riusabilità e l'estendibilità.Classificazione• Sulla base della loro posizione nel processo di sviluppo del software:

◦ infrastructure frameworks: puntano a semplificare il processo di sviluppo del software,di solito vengono usati internamente e non consegnati ai clienti,◦ middleware frameworks: usati per integrare delle applicazioni distribuite già esistenti,

• Sulla base delle tecniche usate per estenderle◦ White-box frameworks: l'estendibilità è ottenuta attraverso l'ereditarietà e il bindingdinamico, le funzionalità esistenti sono estese creando sottoclassi o sovrascrivendometodi specifici,◦ Black-box frameworks: l'estendibilità viene raggiunta defindeno interfacce per icomponenti che possono essere inserite nel framework, le funzionalità esistenti sonoriutilizzate defindendo le componenti che si adeguano ad una particolare interfaccia eintegrandole nel framework tramite la delegazione

Librerie di classi vs FrameworkLe librerie di classi forniscono un ambito di riutilizzo più limitato con meno dominio specifico e sono passive, invece nei frameworks le classi collaborano per una famiglia di applicazioni correlate

Componenti vs frameworksI componenti sono istanze di classi autonome che vengono collegate per formare applicazioni complete. Il vantaggio è che le applicazioni non devono essere ricompilate quando i componenti cambiano.Invece i Frameworks vengono spesso utilizzati per sviluppare componenti che sono spesso inseriti in struttura black-box.

Packaging DesignImballare il design in unità discrete che possono essere modificate, compilate, linkate e riutilizzate.Costruire i moduli fisici, idealmente andrebbe utilizzato un package per ogni sottosistema.La scomposizione del sistema potrebbe non essere buona per l'implementazione.I suoi principi base sono minimizzare gli accoppiamenti e massimizzare la coesione.EuristicheOgni servizio del sottosistema viene reso disponibile per una o più interfacce all'interno delpackage. Si parte con un interface object per ogni servizio del sottosistema.Se un interface object ha troppe operazioni, è necessario rivedere il numero di interface object.Se ci sono troppi interface objects, è necessario rivedere il numero di sottosistemi.Ruoli degli sviluppatori di classi

Informazioni sulla visibilità• Class user (+: public): gli attributi e le operazioni pubblici sono accessibili da ogni classe

2018 Andrea Oian

• Class implementer (-: private): gli attributi e le operazioni private sono accessibili solamentedalle classi nelle quali sono definiti e non sono accessibili a sottoclassi o altre classi,• Class extender (#: protected): gli attributi e le operazioni protetti sono accessibili alle classinelle quali sono definiti e ad ogni discendente,

Principi dell’occultamento di informazioniSolo le operazioni di una classe hanno il permesso di manipolare i suoi attributi.

Euristiche di occultamento dell'informazioneÈ necessario definire in maniera accurata le interfacce pubbliche per le classi così come per isottosistemi. Applicare sempre il principio “need to know”: solamente se qualcuno ha necessità diaccedere all'informazione è da renderlo pubblicamente possibile.Meno dettagli l'utilizzatore della classe deve conoscere, più facilmente la classe può essere cambiata e meno facilmente verranno influenzati da cambiamenti nell'implementazione della classe. Accedere ad attributi privati potrebbe essere molto lento.

ImplementazioneImplementare significa prendere tutti i documenti dettagliati dalla fase di progettazione e trasformarli nel sistema definitivoAttività di implementazione primaria includono:-Codifica e debugging-Testare-Completamento della documentazione

Diagrammi di implementazioneComponent diagram: USATO PER DOCUMENTARE LE DIPENDENZE TRA I COMPONENTI di FILE TIPICI, SIA DIPENDENZE DI COMPILAZIONE SIA DIPENDENZE DI TEMPO DI FUNZIONAMENTODeployment diagram: USATI PER MOSTRARE LA CONFIGURAZIONE DEGLI ELEMENTI DI ELABORAZIONI IN TEMPO DI SVOLGIMENTO E I COMPONENTI E I PROCESSI DEL SOFTWARE CHE SONO COLLOCATI IN ESSI

Tool di implementazione-CASE TOOLS (STRUMENTI DEI CASI)-COMPILATORI, INTERPRETI, TEMPI DI ESECUZZIONE-EDITORI VISIVI-SISTEMI DI CONTROLLO DELLA VERSIONE-SISTEMI DI GESTIONE DEL DATABASE-tool PER IL TEST, installazione e conversione

Stile di codificaUN BUON STILE DI CODIFICA E’ IMPORTANTE PERCHE E’ I PROGRAMMI SONO SCRITTI UNA VOLTA e LETTI MOLTE VOLTE.Alcuni ASPETTI IMPORTNATI DELLO STILE DI CODIFICA sono LAYOUT, NAMING (I NOMI USATI), COMMENTING ( I COMMENTI).

Pratiche di codifica standardLe squadre si sforzano di utilizzare le stesse convenzioni di codifica in ogni ambito: Classi, variabili e metodi di denominazione, Formato del codice, Contenuto e formato del commento del codice.Documentare ogni volta che violate le convenzioni usate.

La Documentazione del codice

2018 Andrea Oian

I COMMENTI SONO TANTO IMPORTANTI QUANTO IL CODICE STESSO e bisogna sempre TENERE LA DOCUMENTAZIONE IL PIU’ VICINO POSSIBILE AL CODICE CORRELATO (METTERE LE SPECIFICHE IN COMMENTI ACCANTO AL CODICE QUANDO E’ POSSIBILE, SCRIVERE UNA BREVE DESCRIZIONE PER OGNI SINGOLO METODO(LINK ) COLLEGARE IL CODICE ALLA DOCUMENTAZIONE ESTERNA).EVITARE COMMENTI INUTILI.

Buono stile di codifica1. NOMI

UTILIZZA I DESCRITTORI INGLESE COMPLETI USA LE ABBREVIAZIONI CON PARSIMONIA E COSTANTEMENTE EVITARE NOMI LUNGHI

2. DOCUMENTAZIONE DELLE VARIABILI DOCUMENTARE LO SCOPO DI OGNI VARIABILE DOCUMENTA PERCHE’ QUALCOSA E ‘ FATTO E NON SOLO COSA E’ FATTO

3. DOCUMENTAZIONE DEI METODI PERCHE’ E COSA FA PARAMETRI/VALORE DI RITORNO COME ESSO MODIFICA L’OGGETTO PROBLEMI DI CONCORRENZA RESTRIZIONI

4. DOCUMENTAZIONE INTERNA STRUTTURE DI CONTROLLO PERCHE’ E COSA FA IL CODICE CODICE COMPLESSO O DIFFICILE

Euristiche per associazioni di implementazioneDUE POSSIBILI STRATEGIE PER LE SOCIETA DI IMPLEMENTAZIONE

ESSERE IL PIU’ UNIFORME POSSIBILE PRENDERE UNA DECISIONE INDIVIDUALE PER OGNI ASSOCIAZIONE

Implementazione dei contratti-CONTROLLARE OGNI PRE-CONDIZIONE-CONTROLLARE OGNI POST-CONDIZIONE -CONTROLLARE OGNI INVARIANTE-TRATTARE CON L’EREDITA’

MOLTI LINGUAGGI ORIENTATI AGLI OGGETTI NON HANNO UN SUPPORTO INTEGRATO PER I CONTRATTI, TUTTAVIA I MECCANISMI DI ECCEZIONI POSSONO ESSERE USATI PER SEGNALARE E MANIPOLARE LE VIOLAZIONI DEL COTRATTO.TUTTAVIA L’NTRODUZIONE DEL CODICE DI CONTROLLO RIDUCE LA PRESTAZIONE DI UNA APPLICAZIONE.

Gestione degli erroriPer gestione dell'errore si intende la prevenzione degli errori (prima che il sistema sia rilasciato), e più in dettagio si intendono numerose tecniche, come ad esempio utilizzare una buona metodologia di programmazione per ridurre la complessità, applicare la verifica per evitare bug algoritmici, rilevamento degli errori (mentre il sistema è in esecuzione). Un sistema di testing crea

2018 Andrea Oian

guasti in modo pianificato.

DefinizioniErrore: Qualsiasi discrepanza tra un valore reale misurato e a valore teorico, previstoGuasto: Una condizione che causa il malfunzionamento o il malfunzionamento del software(causa)Fallimento: L'incapacità di un software di eseguire in base al suospecifiche (effetto)

Fonti di erroreLe fonti di errore possono essere causate da cattivo design, derivate dalla soluzione errata del problema o da mancata corrispondenza da livello di istruzione a livello di battitura, oppure le modifiche di un area interessano un'altra area, o anche da semplici errori di battitura o da scelta sbagliata di variabili.

DebugginE’ un processo metodico di ricerca e riduzione del numero di bug o difetti, in un programma per computer o un pezzo di hardware elettronico, rendendolo quindi come previsto♦ passaggi di base

● Riconosci che esiste un bug● Isolare la fonte del bug● Identifica la causa del bug● Determina una correzione per il bug● Applicare la correzione e testarla

Problema di riconoscimentoSe un errore è abbastanza grave da causare la terminazione del programma in modo anomalo, l'esistenza di un bug diventa ovvio! Se l'errore è minore e causa solo risultati errati, diventa molto più difficile scoprire che esiste un bug. Ciò è particolarmente vero se è difficile o impossibileverificare i risultati del programma.

Debugging tools♦ Debuggers ● Stepping ●Breakpoint ●Inspecting variables ♦ Non traditional debugging tools ●Compilers ●Code comparators

TestingIl test implica il coinvolgimento di tutti i pezzi del progetto in un ambiente di test speciale per testare gli errori, bug e interoperabilità, al fine di verificare che il sistema soddisfi tutti i requisiti aziendali definiti in la fase di analisi.Le attività di test primarie includono:

● Scrivi le condizioni di prova● Eseguire il test del sistema● Fornire feedback per migliorare il software

Limiti del testingIntanto è impossibile testare completamente qualsiasi modulo non banale o sistema. In termini di limiti pratici Il test completo è proibitivo in termini di tempo e costi, invece in termini di limitazioni teoriche I test possono mostrare solo la presenza di bug(ad esempio, potrebbero esserci degli input per i quali un programma non si ferma).

Best practice del testingPer sviluppare un test efficace, si deve avere una comprensione dettagliata del sistema, una

2018 Andrea Oian

conoscenza del dominio delle applicazioni e delle soluzioni, conoscenza delle tecniche di test e abilità nell'applicare queste tecniche.I test vengono eseguiti al meglio da tester indipendenti infatti spesso sviluppiamo un certo atteggiamento mentale rispetto al programma dovrebbe comportarsi in un certo modo quando in realtà no.

Extreme programmingI test sono scritti prima del codice stesso. Viene utilizzato un framework di test in modo che possano essere eseguiti test automatizzati dopo ogni piccola modifica al codice.Questo può essere frequente ogni 5 o 10 minutiIn primo luogo, crei un test per definire alcuni piccoli aspetti del problema.Quindi crei il codice più semplice che lo farà testare.Quindi crei un secondo test.Quindi aggiungi del nuovo codice per fare questo nuovo test, ma non di più finché non hai ancora un terzo test.Continui finché non è rimasto nulla da testare.

Vantaggio di prova♦ Meno bug♦ Codice più gestibile♦ integrazione continua♦ Durante lo sviluppo, il programma funziona sempre, potrebbe non fare tutto il necessario, ma quello che fa è giusto

Test dei componenti♦ Test plan: Un piano di test specifica come dimostrare che il software è privo di difetti e si comporta in base alla specifica dei requisiti. ♦ Test specification: Ogni test ha una specifica di prova che documenta lo scopo del test.Le specifiche del test devono descrivere le condizioni che il software deve assumere al termine del test e un mezzo per valutare i risultati.♦ Test oracle: Un oracol test è l'insieme di risultati previsti per un insieme di test, e viene utilizzato per determinare il successo del test. Gli oracol test sono estremamente difficili da creare e sono idealmente creati dalla specifica dei requisiti.♦ Test cases: Un test case è un insieme di input per il sistema. Testare con successo un sistema dipende dalla selezione dei casi di prova rappresentativi. I casi di test scarsamente scelti possono non illuminare i difetti in un sistema. Nella maggior parte dei sistemi è impossibile eseguire test esaustivi.

Tecniche di testing♦ Glass box testing:Il collaudo a scatola bianca, noto anche con le denominazioni inglesi white box testing o clear/glass box testing ("collaudo a scatola trasparente") o structural testing ("collaudo strutturale") è una forma di collaudo che verifica il funzionamento interno di un componente software, piuttosto che le sue funzionalità. Poiché richiede la conoscenza e la comprensione della struttura interna del software, questa forma di testing è in genere a carico di un programmatore, spesso lo stesso che ha scritto il codice.Il suo funzionamento si basa su alcuni criteri che hanno lo scopo di trovare dati di test che consentano di percorrere tutto il programma. Per trovare un errore nel codice, infatti, bisogna usare dei dati che “percorrono” la parte erronea del programma. Per testare una parte di programma si introduce il concetto di cammino: una sequenza di istruzioni attraversata durante un'esecuzione. Naturalmente non esiste un criterio in grado di testare ogni singolo cammino dato l'elevato numero di questi ultimi -Black box testing: Bisogna trattare il programma come "scatola nera" , e ha come obbiettivo di rilevare il comportamento del test in risposta agli input . E’ basato sulla conoscenza del risultato atteso e divide gli input validi e invalidi. Richiede test oracle.

2018 Andrea Oian

Livelli di testing♦ Test unitario - i più piccoli elementi testabili del sistema sono testati, in genere nello stesso momento in cui quegli elementi sono implementati♦ Test di integrazione: unità integrate, componenti o i sottosistemi sono testati♦ Test di sistema: l'applicazione o il sistema completo (una o più applicazioni) sono testati♦ Test di accettazione: il sistema completo è testato dagli utenti finali per determinare la disponibilità per l'implementazione

Unit testingVengono testate le singole componenti. Viene effettuato dagli sviluppatori con l'obiettivo diconfermare che il componente o il sottosistema è stato codificato correttamente ed esegue lefunzionalità desiderate.Tipologie• Testing statico (a tempo di compilazione):

● Analisi statica● Revisione del codice■ Walk-through (informale)■ Ispezione del codice (formale)

• Testing dinamico (a runtime)◦ Black-box testing

◦ White-box testing

Integration testingTesta gruppi o collezioni di sottosistemi o, addirittura, l'intero sistema. È anch'esso svolto daglisviluppatori, con il compito di testare le interfacce tra i sottosistemi.L'intero sistema è visto come una collezione di sottosistemi determinati durante la progettazione del sistema e degli oggetti. La strategia scelta determina l'ordine nel quale i sottosistemi sono selezionati per il testing e l'integrazione.Molti guasti sono derivati da errori nell'interazione di sottosistemi e I test unitari testano l'unità solo separatamente, quindi bisogna fare il test di integrazione.

Stub e driverUn driver è un componente che chiama l'unità testata e controlla i test case.Lo stub è un componente che simula l'attività di un sottosistema mancante per rispondere allasequenza o al sottosistema chiamante e restituirgli dati fasulli. Un nome alternativo è test double.Spesso è difficile testare un sistema poiché dipende da altre componenti che non possono peròessere utilizzate in fase di test. Queste componenti possono essere sostituite con i test double.Le tipologie di test double utilizzate sono:• dummy object: un oggetto segnaposto che viene passato al codice che viene testato come unparametro ma non viene mai utilizzato• test stub: un oggetto che viene usato per rimpiazzare un componente reale in modo daforzare il sistema nella direzione che vogliamo per il test,• mock object: è un oggetto che viene usato per rimpiazzare un componente reale e che ritornavalori precaricati,• fake object: un oggetto che rimpiazza la funzionalità di un oggetto reale con una implementazione alternativa.

Strategie di integration testing♦ Big bang integration: Big Bang Integration Testing è una strategia di test di integrazione in cui tutte le unità sono collegate contemporaneamente, dando vita a un sistema completo. Quando viene adottato questo tipo di strategia di test, è difficile isolare eventuali errori rilevati, poiché non si presta attenzione alla verifica delle interfacce tra le singole unità.♦ Bottom-up integration: Ha l’unico inconveniente che verifica il sottosistema più importante per ultimo e sono necessari driver ma non stub, ed è Utile per il test di integrazione dei seguenti sistemi: Sistemi orientati agli oggetti e Sistemi in tempo reale

2018 Andrea Oian

♦ Top-down integration: Nessun driver necessario ma scrivere stub è difficile, Gli stubs devono consentire di testare tutte le condizioni possibili, Potrebbe essere richiesto un numero elevato di stubs, soprattutto se il livello più basso del sistema ne contiene molti metodi♦ Sandwich testing:il sistema viene diviso in due layer, il top layer è testato in maniera top-down, e il bottom layer in maniera bottom-up.I test del livello superiore e inferiore possono essere eseguiti in parallelo ma non verifica i singoli sottosistemi.

System testingTesta l'intero sistema. Viene svolto dagli sviluppatori per determinare se il sistema va incontro airequisiti funzionali e non funzionali.

Functional testingTesta le funzionalità del sistema. I test case sono progettati partendo dal documento di analisi deirequisiti o, meglio dal manuale utente. Il sistema viene trattato come una scatola nera.

Performance testingL'obiettivo è di violare i requisiti non funzionali, per verificare come si comporta il sistema quandoè in sovraccarico. Viene fatto scombinando gli ordini di esecuzione. Controlla la risposta del sistema a grandi quantità di dati.Le tipologie note sono:• Stress testing: Limiti di stress del sistema• Volume testing: Prova cosa succede se grandi quantità dei dati sono gestiti• Configuration testin: testa diverse configurazioni di software e hardware,• Compatibility test: testa la retrocompatibilità con sistemi esistenti• Timing test: valuta i tempi di risposta ed i tempi per eseguire una funzione• Security testing: prova a violare i requisiti di sicurezza• Environmental test: testa la tolleranza al calore, all'umidità e ai movimenti• Quality testing: testa l'affidabilità, la manutenibilità e la disponibilità• Recover testing: verifica la risposta del sistema alla presenza di errori o perdite di dati• Human factor testing: test con gli utenti finali

Acceptance testingL'obiettivo è di dimostrare che il sistema è pronto all'uso. Le scelte vengono fatte dal cliente.Molti test possono essere ripresi dall'integration testing.L'accettazione del test viene fatta dal cliente, non dagli sviluppatori.Alpha testI clienti utilizzano il software nell'ambiente degli sviluppatori, che sono pronti ad intervenire percorreggere eventuali bug.Beta testViene condotto nell'ambiente del cliente e lo sviluppatore non è presente. Il software vienerealisticamente utilizzato nell'ambiente target.

Testing object-orientedI componenti da testare sono classi di oggetti che sono istanziato come oggettiLivelli di test:♦ Test delle operazioni associate agli oggetti♦ Test delle classi di oggetti♦ Test di cluster di oggetti cooperanti♦ Test del sistema completo

Testing di classeLa copertura completa del test di una classe coinvolge:

● Test di tutte le operazioni associate a un oggetto● Impostazione e interrogazione di tutti gli attributi dell'oggetto● Esercitare l'oggetto in tutti gli stati possibili

2018 Andrea Oian

Approccio cluster testing♦ Use case o test di scenario :Il test si basa su un'interazione dell'utente con il sistema. Ha il vantaggio di testare le funzionalità del sistema come sperimentate dagli utenti.♦ Thread testing: Verifica la risposta del sistema agli eventi come thread di elaborazioneattraverso il sistema♦ Test di interazione dell'oggetto

Eredità,polimorfismo e associazione dinamica♦ Ereditarietà: I metodi ereditati da una superclasse devono essere ritestati nel filecontesto delle sottoclassi. Il test utilizzando il contesto della superclasse potrebbe non includere tutti i casi che possono verificarsi nel contesto delle sottoclassi♦ Polimorfismo: I parametri hanno più di un set di valori e un'operazione può essere implementato da più di un metodo♦ Associazione dinamica:I metodi che implementano un'operazione sono sconosciuti fino al tempo di esecuzione

Installazione e manutenzioneInstallazioneE’ il processo organizzativo di passaggio dal sistema attuale a uno nuovo. I fattori che condizionano il processo sono:

● costi● Criticità del sistema● Esperienza del computer dell'utente● Complessità del sistema● Resistenza dell'utente● Tempo

Passaggio direttoIn una data il vecchio sistema si ferma e il nuovo sistema inizia, i suoi punti a favore sono che porta benefici immediati, impone agli utenti di utilizzare il nuovo sistema ed è semplice da pianificare; ma non consente nessuna riserva in caso di problemi. Adatto per sistemi su piccola scala e a basso rischio.

Corsa parallelaIl vecchio sistema funziona insieme al nuovo sistema per un certo periodo di tempo, così le uscite dei due sistemi possono essere confrontate, quindi test continua nell'ambiente live; ma purtroppo sono necessari elevati costi di gestione, incluso il personale per la doppia immissione di dati, costi associati al confronto tra gli output di due sistemi. Adatto per sistemi business-critical e ad alto rischio.

Passaggio graduale Il nuovo sistema viene introdotto a tappe, dipartimento di dipartimento o geograficamente, così sottosistemi con un elevato ritorno sull'investimento possono essere presentati prima, ma se ci fossero dei problemi, le voci potrebbero diffondersi prima dell’implementazione. Adatto per grandi sistemi con sottosistemi indipendenti.

Revisione post implementazione♦ Rivedere il sistema: -Offre i benefici attesi? -Soddisfa i requisiti?

Rapporto di valutazione♦ Analisi costi-benefici

2018 Andrea Oian

♦ Sono stati incontrati requisiti funzionali♦ Requisiti non funzionali, Valutare se gli obiettivi misurabili sono stati raggiunti e la soddisfazione degli utenti♦ Problemi durante il progetto e soluzioni in modo che le lezioni possano essere imparato♦ esperienze positive, Cosa è andato bene?, Chi merita credito?♦ Dati quantitativi per la pianificazione, Quanto erano vicine le stime di tempo a quelle effettive? Come possiamo usare questi dati?♦ Componenti candidati per il riutilizzo, Ci sono componenti che possono essere riutilizzati in altri progetti in futuro?

ManutenzioneI sistemi devono essere mantenuti dopo che sono stati pubblicati. La manutenzione del software è la modifica di un software prodotto dopo la consegna, e questa modifica è dovuta a :● Errori corretti● Migliora le prestazioni o altri attributi● Adattare il prodotto a un ambiente modificato

Tipi di manutenzione♦ Modifiche adattive: Realizzato per adattarsi a condizioni diverse♦ modifiche correttive: Realizzato per rimuovere i difetti♦ Modifiche perfette: Cambiamenti preventivi

Attività del processo di manutenzioneLa manutenzione deve essere controllata in modo che i bug non siano introdotti e non sono apportate modifiche inutili. Le modifiche inoltre, devono essere valutate per il loro costo e il loro impatto su altre parti del sistema e quindi pianificato. Il personale di supporto ha bisogno di formazione per aiutare gli utenti durante e dopo queste attività.

Principali leggi sull'evoluzione del software♦ Cambiamento continuo: I sistemi devono essere continuamente adattati o diventano progressivamente meno soddisfacenti da usare♦ Aumento della complessità: La complessità dei sistemi in evoluzione aumenta a meno che il lavoro non venga svolto per mantenerlo o ridurlo

Documento di manutenzione♦ Database di segnalazione di bug ♦ Richieste di miglioramenti ♦ Feedback agli utenti ♦ Piani di implementazione per le modifiche

Project managementSi occupa delle attività che devono assicurare che il software venga consegnato in tempo e inaccordo con i requisiti. È necessario poiché lo sviluppo di software è sempre soggetto a limiti imposti dal budget e dai tempi stabiliti dall'organizzazione che sviluppa il software.

Criteri di successo• Consegnare il software al cliente entro il tempo accordato• Consegnare un software che soddisfi le aspettative del cliente• Mantenere i costi complessivi all'interno del budget previsto• Mantenere un team di sviluppo coeso e ben funzionante

Problemi nella gestione di un softwareIl prodotto è intangibile, poiché il software non può essere visto o toccato. I gestori non possonovedere i progressi semplicemente guardando all'artefatto che si sta costruendo.Molti progetti software sono una tantum. I progetti più grandi sono di solito in qualche modo diversi

2018 Andrea Oian

rispetto a quelli precedenti. Persino i gestori con molta esperienza potrebbero trovare difficileprevedere i problemi.I processi software sono variabili e specifici dell'organizzazione, e potrebbero essere condizionati da fattori quali dimensione della compagnia e sua organizzazione, dalla dimensione variabile del software.

Principali attività della gestione• Pianificazione del progetto (project planning): i manager sono responsabili dellapianificazione, della valutazione e della programmazione dello sviluppo del progetto edell'assegnazione delle persone a varie tasks.• Gestione del rischio (risk management): i gestori valutano i rischi che potrebbero colpire ilprogetto, • Gestione delle persone (people management): i gestori si occupano di scegliere le personeche comporranno i loro team.I manager hanno, generalmente, il dovere di informare il cliente ed i manager di più alto livellodell'azienda sui progressi del progetto.

Project planningPrevede che il lavoro venga spezzato in più parti che vengono assegnate ai membri del team.Anticipa i problemi che potrebbero sorgere e prepara soluzioni provvisorie.Questa fase viene usata per:• comunicare al team e ai clienti come verrà fatto il lavoro,• aiuta a valutare i progressi del progetto,I passaggi sono:• proposal planning: questo primo passaggio si basa sull'identificare i requisiti software.L'obiettivo è fornire le informazioni che serviranno per stabilire un prezzo per i clientitenendo conto di fattori come i costi legati allo staff, all'hardware, al software...• project startup planning: non si hanno ancora informazione circa il design el'implementazione. In questa fase si crea un piano con sufficienti dettagli per prenderedecisioni riguardo il budget e lo staff. Questo passaggio dovrebbe anche definire i meccanismidi controllo del progetto. Uno startup plan è necessario per lo sviluppo agile in modo daallocare le giuste risorse al progetto.• development planning: il piano dovrebbe essere corretto con regolarità con l'avanzare delprogetto. La pianificazione, la stima dei costi e dei rischi dovrebbero essere rivistiregolarmente.

Prezzo del softwareVengono fatte delle stime per stabilire i costi di produzione di un sistema software.Non c'è una relazione semplice tra i costi di sviluppo ed il prezzo che si chiede al cliente in quantoquesto viene influenzato da più larghe considerazione organizzative, economiche, politiche elavorative.I fattori che influenzano il prezzo possono essere:• Termini di contratto: il cliente potrebbe chiedere allo sviluppatore di mantenere la paternitàdel codice sorgente e di riutilizzarlo in altri progetti. Il prezzo potrebbe essere minore se ilcodice sorgente viene consegnato al cliente.• Incertezze nella stima dei costi• Sicurezza finanziaria: gli sviluppatori in difficoltà economiche potrebbero abbassare i prezziper ottenere il contratto. Spesso è meglio ottenere un profitto basso o solamente andare inpari piuttosto che andare in bancarotta.• Opportunità di mercato: un'organizzazione potrebbe stabilire un prezzo basso perchédesidera entrare in un nuovo segmento del mercato software.• Volatilità dei requisiti: nel caso in cui i requisiti dovessero cambiare facilmente,l'organizzazione potrebbe ridurre i prezzi per vincere il contratto o incrementare il prezzo se l'acquirente desidera un contratto a prezzo fisso.Il prezzo del software è stabilito partendo da quello che, secondo lo sviluppatore, il cliente è

2018 Andrea Oian

disposto a pagare. Se quello è inferiore ai costi di sviluppo, le funzionalità del software potrebbero essere ridotte con l'intento di aggiungere funzionalità extra in release successive.Costi aggiuntivi potrebbero venire inseriti quando cambiano requisiti.

Sviluppo plan-driven (plan-based)Si tratta di un approccio all'ingegneria del software dove il processo di sviluppo viene pianificatonel dettaglio. Viene creato un piano di progetto che registra il lavoro che deve essere fatto, che lo fa, la tabella di marcia.I gestori usano questo piano per prendere decisioni e come modo per valutare i progressi.In questo modo è possibile considerare problemi organizzativi. Eventuali problemi e dipendenzevengono identificate prima che il progetto inizi.Tuttavia, molte decisioni devono essere riviste successivamente a causa di cambiamentidell'ambiente in cui il software verrà utilizzato.

Principali sezioni del Project Plan Document• Introduzione• Organizzazione del progetto• Analisi dei rischi• Risorse hardware e software richieste• Tabella di marcia• Meccanismi di controllo e segnalazione

Integrazioni al Project Plan• Configuration management plan: descrive le procedure di gestione della configurazione e lestrutture che devono essere utilizzate• Deployment plan: descrive come il software e l'hardware associato verranno inseritenell'ambiente del cliente,• Maintenance plan: prevede i costi, i requisiti e gli sforzi necessari per il mantenimento,• Quality plan: descrive le procedure e gli standard di qualità utilizzati,• Validation plan: descrivre l'approccio, le risorse ed il programma utilizzato per lavalidazione del sistema.

Processo di pianificazioneSi tratta di un processo iterativo che inizia quando si crea un piano di progetto iniziale durante lafase di startup. I cambiamenti nel piano sono inevitabili.Cambiamenti negli obiettivi lavorativi portano a cambiamenti anche nei piani di progetto.È bene fare assuzioni realistiche anziché ottimistiche nel definire un piano di progetto.Alcuni problemi potrebbero saltare fuori durante il progetto e comportare ritardi.Le assunzioni iniziali e il programma potrebbero portare in conto problemi inattesi.La contingenza andrebbe inclusa in ogni piano in modo da non compromettere la tabella di marcianel caso in cui qualcosa vada storto.

Attenuazione del rischioAzioni di riduzione del rischio adnrebbero fatte per ridure i rischi di fallimento del progetto quandoproblemi seri durante lo sviluppo potrebbero portare a ritardi significativi.In congiunzione con queste azioni, sarebbe bene creare un nuovo project plan. Questo potrebbecomportare una rinegoziazione dei vincoli con il cliente.

Project schedulingÈ il processo in cui si decide come il lavoro verrà organizzato come task separate e come e quando queste verranno eseguite.Deve stimare un tempo necessario a completare ciascun task, gli sforzi, le risorse richieste e chilavorerà su quei task.Questo processo è costituito dalle seguenti attività:• Si divide il progetto in task e si stima il tempo e le risorse necessarie a completare ciascuna

2018 Andrea Oian

di esse,• Si organizzano i task in modo da sfruttare al meglio la forza lavoro,• Si riduce al minimo la dipendenza dei task in modo da evitare possibili ritardi,Questo processo è soggetto ad alcuni problemi:• È difficile stabilire i costi e la difficoltà di un problema,• La produttività non è proporzionale al numero di persone che lavorano ad un determinatotask,• Aggiungere nuove persone ad un progetto già iniziato provoca ritardi• Eventi inattesi possono sempre accadere, occorre quindi tenere conto della contingenza.RappresentazioneDi solito si usano delle notazioni grafiche per rappresentare la programmazione di un progetto.Queste notazoni mostrano la suddivisone del progetto in task, che non devono essere troppo piccole. Di queste task è necessario mostrare le dipendenze.

Descrizione dei taskSi indica una durata in giorni o mesi, una stima degli sforzi che mostra il numero di persone algiorno o al mese necessarie per completare il lavoro, una deadline entro la quale l'attività deve essere conclusa e un end-point.

Milestones e prodotti finitiLe milestones sono punti della programmazione che consentono di valutare i progressi.I prodotti finiti (deliverables) sono i risultati del lavoro che vengono consegnati al cliente.

2018 Andrea Oian