Ingegneria Tutte

Ingegneria del Software T
Introduzione
Argomenti
Evoluzione dello sviluppo del software Prodotto software Processo di sviluppo del software
Attivit Modelli Prototipi Linguaggi di modellazione UML
Fattori di qualit
Ingegneria del Software T 1.2
Evoluzione dello sviluppo del software

Seconda met degli anni '60 l'avvento dei calcolatori di terza generazione (circuiti integrati), rende possibili applicazioni considerate in precedenza non realizzabili Si rende necessario
Progettare Realizzare Effettuare la manutenzione (manutenere)
sistemi software di grandi dimensioni


Nel settore dellhardware, netto, progressivo:
aumento delle prestazioni riduzione dei costi
1.4

Nel settore del software:
Pochissimi i progetti terminati nei tempi stabiliti Rari i progetti che non sfondano il budget Sistemi generalmente pieni di difetti Sistemi cos rigidamente strutturati che praticamente impossibile apportare significativi cambiamenti senza doverli riprogettare totalmente
Crisi del software
1.5

Anni 1950 1960 1970 1980 Base tecnologica
primi calcolatori in serie calcolatori monoutente in batch tecnologia dei compilatori calcolatori sempre pi potenti workstation, reti, interfacce grafiche,...
Problema
produttivit produttivit complessit complessit enorme aumento della complessit
Rivoluzione software
Assembler linguaggi di alto livello (Fortran, Cobol, Algol) programmazione strutturata (Pascal, C) programmazione modulare ADT (Ada, Modula-2) programmazione orientata agli oggetti (Smalltalk, C++, Eiffel, CLOS, Object Pascal, Java, C#, )
1.6
1990

Da lavoro individuale e creativo (software come arte) A lavoro di piccoli gruppi specializzati (livello artigianale) Sino a lavoro di gruppi anche di grosse dimensioni in cui necessaria unopera di pianificazione e coordinamento (livello industriale)
1.7

Lo sviluppo del software deve evolvere in una disciplina ingegneristica, con basi
Teoriche Metodologiche
Nel 1968, durante una conferenza sull'evoluzione del software, viene coniato il termine ingegneria del software
1.8
Ingegneria del Software

Una disciplina tecnologica gestionale che permette di affrontare in modo sistematico quantificabile (in termini di tempi e costi) lo sviluppo e la manutenzione dei prodotti software
Prodotto Software
Codice che, quando eseguito, svolge una funzione prestabilita con prestazioni prestabilite Strutture dati mediante le quali il codice tratta adeguatamente le informazioni Documenti che descrivono le operazioni e luso del prodotto software:
documentazione tecnica manualistica di installazione manualistica di utilizzo
1.10
Prodotto Software
Pu essere realizzato
per un particolare cliente per il mercato in generale
Pu fare parte di un sistema di elaborazione che comprende

sia la parte software sia la parte hardware
1.11
Prodotto Software
Si sviluppa, non si fabbrica
Cliente Sviluppatore/i Processo di sviluppo Linguaggio e strumenti di modellazione
Non si consuma Struttura Caratteristiche
1.12
Sviluppo del software

Esistono molti esempi di
Progetti falliti Tempi e costi non rispettati Soluzioni non corrette Sistemi non gestibili
Il successo di un progetto
Non pu essere garantito determinato
Principalmente da fattori umani Solo secondariamente da scelte tecnologiche
1.13
Principali cause di fallimento

Necessit del cliente comprese male o in modo insufficiente Requisiti del cliente troppo instabili Mancanza di cooperazione tra cliente e sviluppatori Attese non realistiche da parte del cliente Mancanza di benefici per il cliente Fornitura insufficiente di risorse da parte del cliente
1.14
Principali cause di fallimento

Sviluppatori non allaltezza delle attivit in cui sono coinvolti Capacit e conoscenza degli sviluppatori sono i fattori che maggiormente contribuiscono
alla qualit del software alla produttivit
Buoni sviluppatori possono fornire una soluzione, ma ottimi sviluppatori possono fornire
soluzioni migliori pi velocemente a minor costo
1.15
Obiettivo dellingegneria del software

Mettere in grado lo sviluppatore di affrontare la complessit dei grossi progetti
Sviluppare prodotti con le caratteristiche di qualit desiderate Gestire le risorse (specie quelle umane) in modo produttivo Rispettare i vincoli economici e di tempo specificati
1.16
Ingegneria tradizionale
Il problema dello sviluppo del software un problema di gestione della complessit In altri settori, l'uomo ha imparato bene a progettare e costruire sistemi complessi, come un edificio, un'automobile, un calcolatore, un impianto industriale Quali sono i principi usati nell'ingegneria tradizionale per affrontare la complessit?
1.17
Principi usati nell'ingegneria tradizionale per affrontare la complessit

Suddivisione del progetto in sottoprogetti (moduli), e cos via sino ad avere moduli facilmente progettabili Utilizzo di parti e sottosistemi gi pronti
Sviluppati in casa Comprati da fornitori esterni
Standardizzazione dei componenti in modo che possano essere facilmente collegabili e intercambiabili
1.18
Principi usati nell'ingegneria tradizionale per affrontare la complessit

Utilizzo del calcolatore come ausilio per
La progettazione Lesecuzione di compiti ripetitivi I calcoli
Lo sviluppo di un progetto non lasciato al caso o allestro di pochi progettisti, ma unattivit in larga misura sistematica
1.19
Processo di sviluppo del software

Insieme strutturato di attivit che regolano lo sviluppo di un prodotto software La struttura del processo di sviluppo pu avere una forte influenza
sulla qualit sul costo sui tempi di realizzazione
del prodotto
1.20

Stabilisce un ordine di esecuzione delle attivit Specifica quali elaborati devono essere forniti e quando Assegna le attivit agli sviluppatori Fornisce criteri per monitorare il progresso dello sviluppo misurarne i risultati pianificare i progetti futuri Copre lintero ciclo di vita del software
1.21
Fasi del processo di sviluppo del software

1. 2. 3. 4. 5. 6. 7. 8.
Studio di fattibilit Analisi dei requisiti Specifica dei requisiti Progettazione Realizzazione e collaudo dei moduli Integrazione e collaudo del sistema Installazione e training Utilizzo e manutenzione
Studio di fattibilit
Valutazione preliminare dei costi e dei benefici per stabilire se si debba avviare lo sviluppo dellapplicazione
Alternative possibili Scelte pi ragionevoli Risorse finanziarie e umane necessarie per lattuazione del progetto
Il contenuto di questa fase risulta largamente variabile da caso a caso, in funzione del tipo di prodotto e dei ruoli del committente e del produttore dellapplicazione
1.23
Il risultato della fase di studio di fattibilit un documento che dovrebbe contenere le seguenti informazioni:
definizione preliminare del problema possibili scenari che illustrino eventuali diverse strategie di soluzione costi, tempi e modalit di sviluppo per le diverse alternative
Il committente pu allocare risorse finanziarie perch venga condotto uno studio di fattibilit completo
1.24
Analisi dei requisiti

Un requisito la descrizione
di un comportamento del sistema (requisito funzionale) di un vincolo (requisito non funzionale)
sul comportamento del sistema sullo sviluppo del sistema
1.25

Applicazione per la gestione di uno sportello tipo bancomat:
Requisiti funzionali:
Il sistema dovr validare la tessera inserita dal cliente Il sistema dovr validare il PIN inserito dal cliente Il sistema dovr erogare non pi di 500 alla stessa tessera nellarco delle 24 ore
Requisiti non funzionali:

Il sistema dovr essere scritto in C++ Il sistema dovr validare la tessera entro 3 secondi Il sistema dovr validare il PIN entro 3 secondi
1.26

Si stabiliscono funzionalit (requisiti funzionali) vincoli (requisiti non funzionali) obiettivi consultando gli utenti (analisi congiunta) Knowledge of what users really want often is the single most important factor in the failure or success of a software project. It's also one of the most neglected factors - Johnson, Skoglund and Wisniewsky
1.27
Specifica dei requisiti

Formalizzazione dei requisiti
Validazione delle specifiche Evoluzione delle specifiche
Il risultato principale il Documento di Specifica dei Requisiti (DSR)

elenca tutti i requisiti che il prodotto software deve soddisfare un contratto tra sviluppatori e cliente per la fornitura del prodotto software
1.28

Il DSR costituisce un riferimento per lattivit di sviluppo del prodotto, pertanto deve essere preciso, completo e consistente inadeguatezza del linguaggio naturale Il DSR definisce quali funzionalit deve fornire il sistema NON come sono realizzate le funzionalit
1.29

Un ulteriore modo di descrivere i requisiti funzionali consiste nel fornire al committente una versione iniziale del Manuale Utente Viene anche definito il Piano di Test di Sistema che descrive le modalit con cui, al termine dello sviluppo, nella fase di integrazione, si pu verificare il rispetto dei requisiti da parte del sistema sviluppato Tutti i documenti dovrebbero essere approvati e sottoscritti dal committente
Stiamo realizzando il prodotto desiderato?

Progettazione
Si definisce larchitettura generale (hardware e software) del sistema
Si decompone larchitettura software in uno o pi programmi eseguibili Per ogni programma, si descrivono: le funzioni che svolge le relazioni con gli altri programmi Si decompone ogni programma eseguibile in pi moduli Per ogni modulo, si descrivono: le funzioni che svolge le relazioni con gli altri moduli
1.31
Progettazione
Progettazione object-based
Tipi di dati astratti Incapsulamento
Progettazione object-oriented
Ereditariet Polimorfismo
Progettazione generica rispetto ai tipi

Template in C++ Generici in Java e C#
Gestione delle eccezioni Gestione degli eventi Design pattern

Progettazione
Architettura del sistema
Modello repository Modello client-server Modello abstract-machine
Controllo del sistema

Controllo centralizzato Sistemi event-driven
Concorrenza Progetto di interfacce utente Progetto di basi di dati

Progettazione
Risultato: documento di specifiche di progetto nel quale la definizione dellarchitettura software pu anche essere data in maniera rigorosa, o addirittura formale, usando opportuni linguaggi di specifica di progetto Stiamo realizzando correttamente il prodotto?
1.34
Realizzazione e collaudo dei moduli

Il progetto viene realizzato come insieme di programmi e/o moduli
nel linguaggio di programmazione scelto (o nei linguaggi di programmazione scelti)
The fastest line of code to develop is line of code you don't have to write - Jeff Tash
Gestione delle versioni del software

Realizzazione e collaudo dei moduli

Verifica del software
Analisi statica Analisi dinamica Debugging Collaudo dei moduli (unit testing) verifica che un modulo soddisfi le specifiche di progetto
1.36
Tecnologie e Linguaggi
C / C++ Java C# HTML Hypertext Markup Language DHTML Dynamic HTML CSS Cascading Style Sheets Javascript
1.37
XML eXtensible Markup Language DTD Document Type Definition XSD XML Schema Definition XSL eXtensible Stylesheet Language XSLT XSL for Transformations COM, COM++, DCOM, CORBA, EJB .NET, ADO, LinQ, XAML, WPF, WF, WCF DBMS, SQL, ORM
C++
Java Script XSLT
DHTML
C#
CSS
Data Base
Java XML
1.39
Integrazione e collaudo del sistema

Si integrano i singoli moduli e/o programmi tra loro e si esegue il test del sistema completo per assicurarsi che le specifiche siano soddisfatte
alfa test - il sistema rilasciato per luso, ma allinterno dellorganizzazione del produttore beta test - si ha un rilascio controllato a pochi e selezionati utenti del prodotto
Controllo della qualit

Uso di programmi di test Sollecitazione dei programmi (condizioni limite) Controllo dell'utilizzo di standard prestabiliti
1.41
Installazione e training
Deployment Il sistema software viene:
consegnato al cliente installato messo in funzione
Training
1.42
Utilizzo e manutenzione
Il sistema viene utilizzato Fase di manutenzione
la fase pi lunga del ciclo di vita di un prodotto software 50-80% dei costi complessivi
1.43
Manutenzione correttiva
correzione degli errori che non sono stati scoperti nelle fasi precedenti
Manutenzione adattativa
aumento dei servizi forniti dal sistema in seguito alla definizione di nuovi requisiti
Manutenzione perfettiva
miglioramento delle caratteristiche delle unit del sistema
1.44
Spesso il software non viene progettato per essere modificato facilmente Vengono apportate modifiche direttamente sui programmi, senza modificare
la documentazione di progetto la documentazione di test la specifica dei requisiti ...
1.45
Re-ingegnerizzazione del software
Ristrutturazione del codice (refactoring) Conversione del linguaggio Reverse engineering
1.46
Pianificazione, controllo e gestione del processo di sviluppo

Analisi dei costi Gestione del gruppo di lavoro
Gestione dei rischi

Rischi relativi ai requisiti Rischi legati alle risorse umane Rischi tecnologici Rischi politici
1.47

Alcune attivit
sono prevalentemente brain intensive difficilmente meccanizzabili
Alcune attivit
possono essere svolte con lausilio di strumenti CASE (Computer-Aided Software Engineering)
Strumenti CASE
Mediante strumenti CASE, possono essere svolte:
la scomposizione funzionale la definizione grafica delle entit in gioco (dati, funzioni, associazioni, ) la definizione delle interazioni
1.49
Strumenti CASE
Sistemi avanzati di CASE riescono a costruire programmi completi e funzionanti partendo da questi diagrammi, purch tutte le informazioni siano state fornite correttamente
MAIN PROGRAMMA CASE
1.50
Strumenti CASE
Il processo non cos automatizzato come appare in prima battuta Uno strumento CASE non crea del software ma traduce il progetto di un sistema dalla forma grafica alla forma testuale Sviluppare un progetto grafico completo per un programma pu essere impegnativo quanto lo scrivere il programma direttamente!
1.51

Modello a cascata Modelli evolutivi Sviluppo incrementale iterativo Modello a spirale Modelli specializzati
Sviluppo a componenti Modello dei metodi formali Sviluppo aspect-oriented Sviluppo model driven Unified Process (UP - RUP)
Modello a cascata (waterfall model)

Fasi distinte, in cascata tra loro con retroazione finale

Analisi
Progettazione
Implementazione
Collaudo
Manutenzione
Modello a cascata
Il modello si fonda sul presupposto che introdurre cambiamenti sostanziali nel software in fasi avanzate dello sviluppo ha costi troppo elevati pertanto, ogni fase deve essere svolta in maniera esaustiva prima di passare alla successiva, in modo da non generare retroazioni Le uscite che una fase produce come ingresso per la fase successiva sono i cosiddetti semilavorati del processo di sviluppo:
Documentazione di tipo cartaceo Codice dei singoli moduli Sistema complessivo
1.54
Modello a cascata
Oltre alle fasi, fondamentale definire: Semilavorati
al fine di garantire che ci possa essere unattivit di controllo della qualit dei semilavorati
Date
entro le quali devono essere prodotti i semilavorati al fine di certificare l'avanzamento del processo secondo il piano stabilito
1.55
Modello a cascata
I limiti sono dati dalla sua rigidit in particolare da due assunti di fondo molto discutibili:
Immutabilit dellanalisi gli utenti sono in grado di esprimere esattamente le loro esigenze e di conseguenza in fase di analisi iniziale possibile definire tutte le funzionalit che il software deve realizzare Immutabilit del progetto possibile progettare lintero sistema prima di aver scritto una sola riga di codice
1.56
Modello a cascata
Nella realt:
La visione che gli utenti hanno del sistema evolve man mano che il sistema prende forma e quindi le specifiche cambiano in continuazione Nel campo della progettazione le idee migliori vengono in mente per ultime, quando si comincia a vedere qualcosa di concreto Inoltre problemi di prestazioni costringono spesso a rivedere le scelte di progetto
1.57
Modello a cascata
Evoluzioni successive al modello originale ammettono forme limitate di retroazione a un livello
Analisi
Progettazione
Implementazione
Collaudo
1.58
Modello a cascata
Per evitare problemi, prima di iniziare a lavorare sul sistema vero e proprio meglio realizzare un prototipo in modo da fornire agli utenti una base concreta per meglio definire le specifiche Una volta esaurito il compito, il prototipo viene abbandonato (throw-away prototyping) e si procede a costruire il sistema reale secondo i canoni del modello a cascata Questo approccio risulta per quasi sempre cos dispendioso da annullare i vantaggi economici che il modello a cascata dovrebbe garantire
1.59
Prototipo
Modello approssimato dellapplicazione Obiettivo: essere mostrato al committente o usato da questi al fine di ottenere un'indicazione su quanto il prototipo colga i reali fabbisogni Deve essere sviluppabile
in tempi brevi con costi minimi
Alternativa interessante in tutti i casi in cui lo sviluppo dellapplicazione parta inizialmente con requisiti non perfettamente noti o instabili
1.60
Prototipo
Prototipazione throw-away
Il prototipo che si realizza del tipo usa e getta Obiettivo: comprendere le richieste del cliente e quindi migliorare la definizione dei requisiti del sistema Il prototipo si concentra sulle parti che sono mal comprese con l'obiettivo di contribuire a chiarire i requisiti
1.61
Prototipo
Programmazione esplorativa
Il prototipo si trasforma progressivamente nel prodotto finale Obiettivo: lavorare a stretto contatto con il cliente per
Chiarire completamente i requisiti Giungere a un prodotto finale
Prima, si sviluppano le parti del sistema che sono ben chiare (requisiti ben compresi) Quindi, si aggiungono nuove parti/funzionalit come proposto dal cliente
Modelli evolutivi
Partendo da specifiche molto astratte, si sviluppa un primo prototipo Da sottoporre al committente Da raffinare successivamente
1.63
Modelli evolutivi
Esistono diversi modelli di tipo evolutivo, ma tutti in sostanza propongono un ciclo di sviluppo in cui un prototipo iniziale evolve gradualmente verso il prodotto finito attraverso un certo numero di iterazioni Il vantaggio fondamentale che ad ogni iterazione possibile confrontarsi con gli utenti per quanto riguarda le specifiche e le funzionalit (raffinamento dellanalisi) rivedere le scelte di progetto (raffinamento del design)
Modelli evolutivi
Lefficacia di questi modelli si basa su due requisiti: Uniformit fra le tecniche di analisi, design e programmazione Tecnologie e strumenti di sviluppo predisposti allapproccio incrementale I modelli evolutivi si sono orientati verso cicli sempre pi brevi e iterazioni sempre pi veloci, fino ad arrivare al modello pi radicale che prende il nome di Extreme Programming (XP)
1.65
Modelli evolutivi
Lillustrazione, tratta da un articolo di Kent Beck, mostra levoluzione dal modello a cascata, allextreme programming
1.66
Modelli evolutivi
Problemi
Il processo di sviluppo non visibile (ad es., documentazione non disponibile) Il sistema sviluppato poco strutturato (modifiche frequenti) richiesta una particolare abilit nella programmazione (team ristretto)
Applicabilit
Sistemi di piccole dimensioni Parti di sistemi pi grandi Sistemi che avranno breve durata
1.67
Extreme Programming
Si basa su:
Comunicazione: ci deve essere grande comunicazione sia tra gli sviluppatori, sia tra sviluppatori e clienti Testing: necessario avere pi codice per il test che per il programma vero e proprio - ogni programmatore deve scrivere il programma di test parallelamente se non prima di scrivere il codice effettivo
1.68
Extreme Programming
Si basa su:
Semplicit: il codice deve essere il pi semplice possibile - complicare il codice tentando di prevedere futuri riutilizzi controproducente sia come qualit di codice prodotto, sia come tempo necessario - d'altra parte, il codice semplice e comprensibile il pi riutilizzabile Coraggio: non si deve avere paura di modificare il sistema che deve essere ristrutturato in continuazione, ogni volta che si intravede un possibile miglioramento (refactoring)
Analisi dei rischi

Quale modello scegliere per il processo di sviluppo? La scelta deve dipendere da una valutazione dei rischi inerenti alle varie attivit che si dovranno effettuare durante il processo di sviluppo Obiettivo: minimizzare i rischi Rischio inerente un'attivit valutazione (misura) dell'incertezza che si ha sul risultato finale dell'attivit
1.70
Analisi dei rischi

Modello a cascata
Alto rischio per nuovi sistemi con requisiti non stabili Basso rischio per sviluppo di sistemi ben specificati e con tecnologia assestata Sistemi di dimensioni medie o grandi
Modelli evolutivi
Alto rischio per mancanza di visibilit Basso rischio per sviluppo di nuove applicazioni Sistemi di dimensioni piccole
1.71
Modelli ibridi
Sistemi composti di sotto-sistemi Per ogni sotto-sistema possibile adottare un diverso modello di sviluppo
Modello evolutivo per sotto-sistemi con specifiche ad alto rischio Modello a cascata per sotto-sistemi con specifiche ben definite
Di norma conviene creare e raffinare prototipi funzionanti del sistema o di sue parti, secondo lapproccio incrementale - iterativo
1.72
Sviluppo incrementale
Sviluppo incrementale si costruisce il sistema sviluppandone sistematicamente e in sequenza parti ben definite una volta costruita una parte, essa non viene pi modificata
di fondamentale importanza essere in grado di specificare perfettamente i requisiti della parte da costruire, prima della sua implementazione
1.73
Sviluppo iterativo
Sviluppo iterativo si effettuano molti passi dellintero ciclo di sviluppo del software, per costruire iterativamente tutto il sistema, aumentandone ogni volta il livello di dettaglio
non funziona bene per progetti significativi non consente di valutare correttamente i rischi relativi alle diverse parti del sistema
1.74
Sviluppo incrementale - iterativo

Si individuano sottoparti relativamente autonome Si realizza il prototipo di una di esse Si continua con altre parti Si aumenta progressivamente lestensione e il dettaglio dei prototipi, tenendo conto delle altre parti interagenti E cos via
1.75

1 2 3 P1' 1 2 3 P1' 1 P2' 2 3 P1'' 1 P2' 2 3
P1'' 1 P2' 2
P3' 3
P1'' 1 P2' 2
P3'' 3
P1'' 1 P2'' 2
P3'' 3
PD1 1 P2'' 2
P3'' 3
Pn' : Primo prototipo PDn : Prototipo definitivo
Pn'' : Secondo prototipo
1.76
Sviluppo a componenti
Ricerca classi da Ricerca componenti da riusare riusare
Progettazione OO
Analisi OO
Librerie di Libreria di componenti classi
Installazione e utilizzo
Scrittura del prototipo Sviluppo classi da Sviluppo componenti da riusare riusare
Valutazione
1.77
Linguaggi di modellazione
Permettono di descrivere (modellare) un sistema di qualche natura Possono essere grafici o testuali
Se grafici, sono basati su uno o pi tipi di diagrammi, costruiti a partire da simboli grafici con una semantica ben definita
Possono essere interpretabili

simulazione pi o meno completa del comportamento del sistema modellato generazione del codice sorgente utilizzabile nell'implementazione del sistema
Un modello pu essere eseguito Un modello pu essere tradotto
Modelli semantici dei dati
Entit-Relazioni (E-R)
Modelli orientati allelaborazione dati

Diagrammi di Flusso dei Dati (Data-Flow Diagrams, DFD)
Modelli orientati alla classificazione

Modelli orientati agli oggetti
Modelli operazionali
Automi a stati finiti Reti di Petri
Modelli descrittivi
Logica del primo ordine Logica temporale
1.79
Nessun cliente vi ringrazier per avergli fornito diagrammi accurati; quello che vorranno da voi software funzionante Perch usare un linguaggio di modellazione? Dobbiamo risolvere un problema di comunicazione tra i progettisti tra i progettisti e il committente tra i progettisti presenti e i progettisti futuri
1.80
Il linguaggio naturale troppo impreciso Il codice preciso, ma troppo dettagliato La soluzione migliore utilizzare un linguaggio di modellazione
Sufficientemente preciso Flessibile dal punto di vista descrittivo per poter arrivare a un qualunque livello di dettaglio Possibilmente standard
1.81
Esiste ormai una convergenza su un unico linguaggio di modellazione di tipo grafico: UML (Unified Modeling Language) Sviluppato verso la met degli anni '90 da Grady Booch, James Rambaugh, Ivar Jacobson Nel 1999, OMG (Object Management Group) ha definito la versione 1.3 del linguaggio (http://www.omg.org) La versione corrente la 2.1 (http://www.uml.org)
Unified Modeling Language

un linguaggio di modellazione grafico Permette di creare varie descrizioni pi o meno astratte di un sistema (non necessariamente software) indipendente dal processo, anche se promuove uno stile di analisi e progettazione:
Guidato dai casi duso (use case driven), cio dalle funzionalit che il sistema deve fornire Iterativo e incrementale, quindi guidato dallanalisi dei rischi (risk-driven)
1.83

Prevede meccanismi di estensione del linguaggio stesso integrabile con altre tecniche orientato agli oggetti uno standard OMG
1.84

Diagrammi strutturali
Diagramma delle classi Diagramma degli oggetti Diagramma dei componenti Diagramma dei package Diagramma di deployment Diagramma delle strutture composite (UML 2.0)
Diagrammi comportamentali
Diagramma dei casi duso Diagramma delle attivit Diagramma degli stati Diagramma di sequenza Diagramma di comunicazione (ex di collaborazione) Diagramma dei tempi (UML 2.0) Diagramma di sintesi dellinterazione (UML 2.0)
Fattori di qualit
Qualit esterne percepibili da un osservatore esterno che esamina il processo o il prodotto come se fosse una scatola nera (black-box)
Affidabilit Facilit d'uso Velocit
Devono essere garantite

Fattori di qualit
Qualit interne osservabili esaminando la struttura interna del processo o prodotto, come se questo fosse una scatola trasparente (white-box)
Modularit Leggibilit
Influenzano le qualit esterne Sono un modo per realizzare le qualit esterne

Fattori di qualit del software

Molti dei fattori di qualit del software sono definibili soltanto in maniera
Intuitiva Poco rigorosa
Lobiettivo di fornire meccanismi precisi di misura non realisticamente raggiungibile (ad esempio, per laffidabilit)
1.88
Correttezza (correctness)
Data una definizione dei requisiti che il software deve soddisfare, il software si dice corretto se rispetta tali requisiti I requisiti specificati risultano spesso incompleti rispetto ai requisiti reali
1.89
Robustezza (robustness)
Il software si dice robusto se si comporta in maniera accettabile anche in corrispondenza di situazioni anomale e comunque non specificate nei requisiti Nel caso di situazioni anomale, il software non deve causare disastri (perdita di dati o peggio) o termina l'esecuzione in modo pulito o entra in una modalit particolare, in cui non sono pi attive alcune funzionalit (graceful degradation mode)
1.90
Affidabilit (reliability)
Il software si dice affidabile se
le funzionalit offerte corrispondono ai requisiti (il software corretto) in caso di guasto, non produce danni fisici o economici (il software robusto) Affidabilit = Correttezza + Robustezza
1.91
Estendibilit (extendibility)
Facilit con cui il software pu essere modificato per soddisfare nuovi requisiti
La modifica di programmi di piccole dimensioni non un problema serio I sistemi software di dimensioni medie e grandi possono soffrire di fragilit strutturale: modificando un singolo elemento della struttura si rischia di far collassare l'intera struttura
1.92
Estendibilit (extendibility)
Due principi essenziali: Semplicit architetturale
pi l'architettura del sistema semplice pi facile da modificare
Modularit e decentralizzazione
pi il sistema suddiviso in moduli autonomi pi facile che una modifica coinvolga un numero limitato di moduli
1.93
Riusabilit (reusability)
Il software riusabile se pu essere riutilizzato completamente o in parte in nuove applicazioni Permette di non dover reinventare soluzioni a problemi gi affrontati e risolti Influenza tutte le altre caratteristiche dei prodotti software
1.94
Compatibilit (compatibility)
Facilit con cui il prodotto software pu essere combinato con altri prodotti Omogeneit nel progetto Utilizzo di standard:
Nel formato dei dati che devono essere scambiati con altre applicazioni (formato XML) Nell'interfaccia utente
1.95
Facilit d'uso (ease of use)

Facilit con cui l'utilizzatore del software in grado di:
Imparare ad usare il sistema Utilizzare il sistema Fornire i dati da elaborare Interpretare i risultati Gestire condizioni di errore
1.96
Efficienza (efficiency)
Buon utilizzo delle risorse hardware:
Processori (tempo di calcolo) Memoria principale (occupazione di memoria) Memorie secondarie Canali di comunicazione
1.97
Portabilit (portability)
Facilit con cui il prodotto software pu essere trasferito su altre architetture hardware e/o software
1.98
Verificabilit (verifiability)
Facilit con cui il prodotto software pu essere sottoposto a test
1.99
Integrit (integrity)
Protezione sicurezza abilit del sistema software di proteggere i vari componenti (programmi, dati, documenti) da accessi e/o modifiche non autorizzati di natura sia volontaria sia involontaria
1.100
Innocuit (safety)
Abilit del sistema software di non entrare mai in uno stato di pericolosit intollerabile Caso di sistemi che possono essere critici e pericolosi anche per la vita dell'uomo
1.101

Alcune caratteristiche sono in contrapposizione, ad esempio: efficienza vs portabilit L'importanza dell'una o dell'altra caratteristica varia (pu variare) a seconda del settore applicativo Il costo del software aumenta esponenzialmente se richiesto un livello molto alto di una qualunque di tali caratteristiche
1.102
Fattori di qualit del processo di sviluppo del software

Accettabilit (acceptability)
il processo accettabile e utilizzabile dai responsabili dello sviluppo?
Facilit di comprensione (understandability)

facile capire la definizione del processo?
Supportabilit (supportability)
possibile utilizzare strumenti CASE?
Capacit di modifica (maintainability)

il processo in grado di evolvere in caso di modifiche organizzative o di miglioramenti produttivi?
1.103
Fattori di qualit del processo di sviluppo del software

Visibilit (visibility)
dopo ogni attivit, vengono prodotti documenti che permettano di controllare l'avanzamento dei lavori?
Affidabilit (reliability)
il processo definito in modo tale da evitare che errori nel processo si ripercuotano in errori nel prodotto?
Robustezza (robustness)
il processo in grado di proseguire anche al verificarsi di problemi imprevisti?
1.104
2. Analisi orientata agli oggetti
Analisi
Per effettuare correttamente lanalisi, necessario
Comunicare con lutente Ottenere una buona conoscenza dellarea applicativa Determinare in dettaglio i requisiti del sistema
Produce un documento dei requisiti base di partenza della fase successiva del processo di sviluppo del software, cio la progettazione Se non viene svolta in modo accurato, pu avere conseguenze molto serie: i costi per gestire requisiti omessi o errati possono diventare insostenibili
2.2
Analisi
Raccolta dei requisiti Analisi del dominio
Produce un modello che descrive il dominio del problema da affrontare: la porzione del mondo reale, rilevante per il sistema Su cui si devono mantenere informazioni Con cui si deve interagire
Produce un modello che descrive le responsabilit del sistema Che cosa deve fare il sistema per soddisfare il cliente Non come il sistema va realizzato
2.3
Analisi e gestione dei rischi

Analisi sistematica e completa di tutti i possibili rischi che possono fare fallire o intralciare la realizzazione del sistema in una qualsiasi fase del processo di sviluppo Ogni rischio presenta due caratteristiche:
Probabilit che avvenga non esistono rischi con una probabilit del 100% (sarebbero vincoli al progetto) Costo se il rischio si realizza, ne seguono effetti indesiderati e/o perdite
2.4

Rischi relativi ai requisiti i requisiti sono perfettamente noti? Il rischio maggiore quello di costruire un sistema che non soddisfa le esigenze del cliente Rischi relativi alle risorse umane possibile contare sulle persone e sullesperienza necessarie per lo sviluppo del progetto?
2.5

Rischi tecnologici si sta scegliendo la tecnologia corretta? si in grado di aggregare correttamente i vari componenti del progetto (ad es., GUI, DB, )? quali saranno i possibili futuri sviluppi della tecnologia? Rischi politici ci sono delle forze politiche (anche in senso lato) in grado di intralciare lo sviluppo del progetto?
2.6

Strategia reattiva o alla Indiana Jones
Niente paura, trover una soluzione
Strategia preventiva
Si mette in moto molto prima che inizi il lavoro tecnico Si individuano i rischi potenziali, se ne valutano le probabilit e gli effetti e si stabilisce un ordine di importanza Si predispone un piano che permetta di reagire in modo controllato ed efficace Pi grande un rischio Maggiore sar lattenzione che bisogner dedicargli
2.7
Analisi
Raccolta dei requisiti

Raccolta di tutte le informazioni su cosa il sistema deve fare secondo le intenzioni del cliente Obiettivi Definire la ragione dessere e gli obiettivi del sistema Definire i limiti del dominio del problema Identificare le funzioni principali del sistema
2.8
Analisi

Non prevede passi formali, n ha una notazione specifica, perch dipende moltissimo dal particolare tipo di problema Deve produrre Un documento (testuale) Scritto dallanalista Discusso e approvato dal cliente Un dizionario o glossario contenente la definizione di tutti i termini e i concetti utilizzati
Analisi

Tipologie di persone coinvolte
Analista Utente Esperto del dominio (non sempre indispensabile)
Metodi utilizzati
Interviste, questionari Studio di documenti che esprimono i requisiti in forma testuale Osservazione passiva o attiva del processo da modellare Studio di sistemi software esistenti Prototipi
2.10
Analisi

La gestione delle interviste molto complessa i clienti potrebbero
Avere solo una vaga idea dei requisiti Non essere in grado di esprimere i requisiti in termini comprensibili Chiedere requisiti non realizzabili o troppo costosi Fornire requisiti in conflitto Essere poco disponibili a collaborare
2.11
Analisi

Confronto con altri sistemi Posizionare il sistema che si sta progettando rispetto allo stato dellarte Quali sono Le caratteristiche migliori I problemi pi seri Le caratteristiche non necessarie del nostro sistema e dei sistemi della concorrenza?
2.12
Analisi
Validazione dei requisiti

Ogni requisito deve essere validato e negoziato con i clienti prima di essere riportato nel documento dei requisiti Attivit svolta in parallelo alla raccolta
Validit il nuovo requisito inerente il problema da

risolvere?
Consistenza il nuovo requisito in sovrapposizione e/o in

conflitto con altri requisiti?
Realizzabilit il nuovo requisito realizzabile con le risorse

disponibili (hardware, finanziamenti, )?
Completezza esiste la possibilit che ci siano requisiti

rimasti ignorati?
Analisi
Cambiamento dei requisiti

normale che i requisiti subiscano modificazioni ed evolvano nel tempo Requisiti esistenti possono essere rimossi o modificati Nuovi requisiti possono essere aggiunti in una fase qualsiasi del ciclo di sviluppo Tali cambiamenti Sono la norma, non leccezione Possono diventare un grosso problema se non opportunamente gestiti
Analisi

Pi lo sviluppo avanzato, pi il cambiamento costoso Modificare un requisito appena definito facile Modificare lo stesso requisito dopo che stato implementato nel software potrebbe essere molto costoso Ogni cambiamento deve essere accuratamente analizzato per valutare La fattibilit tecnica Limpatto sul resto del sistema Il costo
Analisi

Consiglio sviluppare sistemi che
Siano il pi possibile resistenti ai cambiamenti dei requisiti Inizialmente, eseguano esclusivamente e nel modo migliore i soli compiti richiesti In seguito, siano in grado di sostenere laggiunta di nuove funzionalit senza causare disastri strutturali e/o comportamentali
2.16
Analisi
Analisi del dominio

Obiettivo identificare strutture e comportamenti comuni a tutti i sistemi software di una particolare area applicativa Non legata a un progetto specifico Scopo primario la riusabilit di schemi di progettazione e di componenti software per tutte le applicazioni che operano su un dato dominio Esempi di domini sono:
Il controllo del traffico aereo La gestione aziendale Le operazioni bancarie
Analisi
Analisi del dominio

Deriva dallanalisi dei requisiti dei vari sistemi che operano in un dominio Aiuta ad effettuare le analisi dei nuovi sistemi, ed da queste continuamente migliorata
Analisi del dominio
2.18
Analisi

Obiettivo definire i requisiti funzionali e descrivere il comportamento del sistema da realizzare Si concentra sulla descrizione del sistema, del mondo esterno e dei loro costituenti fondamentali, e non sui dettagli di come tale sistema funziona Prima considera le entit importanti dellambiente esterno e del sistema, poi le raffina alla luce delle responsabilit del sistema
2.19
Analisi

Deve produrre un documento dei requisiti, nel quale i requisiti funzionali devono essere specificati in modo chiaro e conciso, in modo da poter essere letti e compresi Il documento dei requisiti: Formalizza le necessit del cliente Stabilisce un elenco di obblighi Fornisce la base per il successivo sviluppo del sistema
2.20
Esempio: Villaggio Turistico
Raccolta dei Requisiti

In un villaggio turistico, gli ospiti fanno spesa nei diversi negozi e pagano i diversi servizi sempre e solo servendosi di una carta (simile a un bancomat) denominata Guest Card La valuta di riferimento sempre leuro Al termine della vacanza, ad ogni ospite viene consegnato un estratto conto con la lista delle spese effettuate, nella valuta scelta dal cliente Per ogni spesa, lelenco deve riportare la data e lora, il punto vendita, il tipo di acquisto e limporto addebitato Al termine di ogni settimana, ad ogni negozio deve essere consegnato lelenco degli acquisti effettuati presso i vari punti vendita associati
2.21
Analisi dei Requisiti

In un villaggio turistico, gli ospiti fanno spesa nei diversi negozi e pagano i diversi servizi sempre e solo servendosi di una carta (simile a un bancomat) denominata Guest Card Villaggio Turistico Ospite Spesa Negozio Servizio Carta Guest Card
2.22

In un villaggio turistico, gli ospiti fanno spesa nei diversi negozi e pagano i diversi servizi sempre e solo servendosi di una carta (simile a un bancomat) denominata Guest Card Ospite
Pu acquistare un servizio in un negozio Deve pagare il servizio con la Guest Card
Negozio
Eroga servizi Incassa il pagamento del servizio mediante Guest Card
Servizio
Ha un costo
Guest Card
Unico mezzo per effettuare i pagamenti

La valuta di riferimento sempre leuro Ospite
Pu acquistare un servizio in un negozio Deve pagare il servizio con la Guest Card in euro
Negozio
Eroga servizi il cui costo in euro Incassa il pagamento del servizio mediante Guest Card in euro
Servizio
Ha un costo in euro
Guest Card
Permette di effettuare i pagamenti in euro
Valuta di riferimento
Unica in tutto il Villaggio Turistico In euro

Al termine della vacanza, ad ogni ospite viene consegnato un estratto conto con la lista delle spese effettuate, nella valuta scelta dal cliente Termine della vacanza evento temporale Estratto conto lista delle spese effettuate report di stampa Spesa effettuata Servizio acquistato dallospite Cliente Ospite Valuta scelta dallospite Pu essere differente dalla valuta di riferimento
2.25

Al termine della vacanza, ad ogni ospite viene consegnato un estratto conto con la lista delle spese effettuate, nella valuta scelta dal cliente Ospite Deve scegliere la valuta x pagamento finale Termine della vacanza evento Generazione dellestratto conto acquisti Consegna allospite dellestratto conto acquisti Pagamento finale nella valuta scelta dallospite NOTA: Sar necessario effettuare conversioni tra valute diverse
2.26

Per ogni spesa, lelenco deve riportare la data e lora, il punto vendita, il tipo di acquisto e limporto addebitato Spesa Acquisto o Movimento Data e ora del movimento Punto di vendita (NON coincide con Negozio!) Tipo di acquisto Importo in euro Punto Vendita Catena Punti Vendita (ex Negozio) Tipo di Acquisto Servizio
2.27

Al termine di ogni settimana, ad ogni negozio deve essere consegnato lelenco degli acquisti effettuati presso i vari punti vendita associati Termine di ogni settimana evento temporale Generazione dellestratto conto vendite x Punto Vendita Consegna alla Catena Punti Vendita
2.28
Analisi
Casi duso e scenari

I requisiti funzionali descrivono il comportamento del sistema I casi duso e i relativi scenari permettono
Di formalizzare i requisiti funzionali Di comprendere meglio il funzionamento del sistema (e quindi di metterne in evidenza eventuali carenze) Di comunicare meglio con il cliente
2.29
Analisi
Casi duso e scenari

Caso duso
Descrizione di una richiesta fatta al sistema da una qualsiasi entit esterna al sistema stesso (attore) Insieme di scenari legati da un obiettivo comune
Scenario sequenza di passi che descrive

sia linterazione tra lattore e il sistema sia le elaborazioni necessarie per soddisfare la richiesta dellattore
2.30
Analisi
Casi duso e scenari

Passi da intraprendere
Individuare il confine del sistema Individuare gli attori Individuare i casi duso
Specificare il caso duso Specificare gli scenari associati al caso duso
Linsieme di tutti i casi d'uso costituisce limmagine del sistema verso lesterno
2.31
Analisi
Casi duso e scenari

Caso d'uso Sistema Attore Associazione
Prepara esame
Effettua esame
Esaminando
Correggi esame GestioneEsami Ingegneria del Software T
Esaminatore
2.32
Analisi
Casi duso e scenari

Attore ruolo interpretato da un utente (persona o sistema esterno) nei confronti del sistema
Esaminando
Tutti gli esaminandi interpretano lo stesso ruolo Tutti gli esaminatori interpretano lo stesso ruolo
Esaminatore
2.33
Analisi
Casi duso e scenari

Effettua esame
Scenario principale del caso duso Effettua esame
Esaminando
1. 2. 3. 4. 5.
Lesaminando entra nel sistema (login) Lesaminando inizia lesame Lesaminando naviga tra le domande e risponde Lesaminando termina l'esame Lesaminando esce dal sistema (logout)
Analisi
Casi duso e scenari

Un caso duso
viene sempre avviato direttamente o indirettamente dallintervento di un attore che si pone un dato obiettivo
lesaminando vuole fare lesame
si conclude con successo quando lobiettivo viene raggiunto

lesaminando ha fatto lesame
si conclude con fallimento quando lobiettivo NON viene raggiunto

lesaminando non riuscito a fare lesame ad es. non riuscito ad effettuare il login (in questo contesto, il fatto che lattore abbia superato o no lesame irrilevante)
2.35
Analisi
Casi duso e scenari

Un caso duso viene sempre descritto dal punto di vista di un attore e comprende
0+ Precondizioni condizioni che devono essere tutte verificate prima che il caso duso possa essere eseguito vincoli sullo stato iniziale del sistema 1+ Sequenze di passi cio sequenze di interazioni tra lattore e il sistema necessarie a raggiungere lobiettivo richiesto potrebbero comprendere ramificazioni (if) e iterazioni (for, foreach e while) 0+ Postcondizioni condizioni che devono essere tutte vere quando il caso duso termina lesecuzione di norma con successo
2.36
Analisi
Casi duso e scenari

Ogni sequenza di passi deve
essere scritta in una forma narrativa strutturata utilizzare il vocabolario di dominio
In tal modo, il committente

potr comprendere facilmente la descrizione dei casi duso
e di conseguenza
non solo sar in grado di validare i casi duso ma sar anche incoraggiato a partecipare attivamente alla loro definizione
2.37
Analisi
Casi duso e scenari

Tipicamente un caso duso comprende
uno scenario principale eventuali scenari alternativi che rappresentano possibili varianti del flusso che sono fatti scattare da opzioni, condizioni derrore, violazione della sicurezza,
Ogni scenario
potrebbe essere descritto formalmente mediante un diagramma di sequenza, ma viene descritto mediante il linguaggio naturale, che pi adeguato nella fase di raccolta dei requisiti
2.38
Definizione dei casi duso e degli scenari

1. 2.
3.
4.
Identificare tutti i possibili utilizzi del sistema Definire un attore per ogni categoria di utenza e per ogni ruolo che lutente gioca e che ha rilevanza per il sistema Per ciascun attore identificare tutti gli obiettivi significativi che gli utenti si pongono e che il sistema dovr supportare Per ciascun obiettivo definire un caso duso
2.39
Definizione dei casi duso e degli scenari

5.
6.
Definire i casi duso senza eccedere nella complessit e nei dettagli mantenendo sempre lo stesso livello di astrazione: singoli passi in un caso duso dalto livello dastrazione possono essere trattati come obiettivi da casi duso di livello dastrazione pi basso Ricontrollare e validare i casi duso insieme agli utenti e ai committenti
2.40
Analisi
Relazioni tra casi d'uso

Generalizzazione / Specializzazione
Si utilizza quando un caso duso simile ad un altro, ma fa qualcosa di pi applicabile anche agli attori un attore pu essere la specializzazione di un altro attore
Inclusione include (o uses)

Si utilizza quando un caso duso usa almeno una volta un altro caso d'uso
Estensione extend (o extends)

Si utilizza quando necessario aggiungere un comportamento opzionale a un caso duso esistente
2.41
Analisi

Prepara esame Controllo password
include
Effettua esame
include
Effettua validazione
include
Correggi esame
Scansione retina GestioneEsami
2.42
Analisi
2.43
Analisi
Relazioni tra attori

Lattore Amministratore
Utente
Eredita tutti i casi duso dellattore Utente Ha casi duso propri
Amministratore
2.44
Casi duso
2.45
Analisi Definizione degli scenari - 1

Introduction
Describe a quick background of the use case
Actors
List the actors that interact and participate in this use case
Pre-conditions
Pre-conditions that need to be satisfied for the use case to perform
Post-conditions
Define the different states in which you expect the system to be in, after the use case executes
Basic Flow
List the primary events that will occur when this use case is executed

Alternative flows
Any subsidiary events that can occur in the use case should be separately listed List each such event as an alternative flow A use case can have as many alternative flows as required
Special Requirements
Business rules for the basic and alternative flows should be listed as special requirements in the use case narration These business rules will also be used for writing test cases Both success and failure scenarios should be described here
Use case relationships

For complex systems, it is recommended to document the relationships between use cases
2.47

Titolo Descrizione Relazioni Attori Precondizioni Scenario Principale Scenari alternativi Requisiti non funzionali Punti aperti
Analisi

Obiettivo
Specificare (cio definire) le propriet che il sistema dovr avere senza descrivere una loro possibile realizzazione
Approccio funzionale
Astrae sino al massimo livello il modo di funzionare di un calcolatore
Approccio orientato agli oggetti
Si basa sulla stessa forma di astrazione applicata dagli uomini per affrontare la complessit del mondo
Principio fondamentale: Astrazione
Permette di gestire la complessit intrinseca del mondo reale Ignorare gli aspetti che non sono importanti per lo scopo attuale Concentrarsi maggiormente su quelli che lo sono
2.49
Analisi
Approccio Funzionale
Tecnica della Scomposizione Funzionale Strategia
Analisi top-down scegliere i passi ed i sotto-passi di elaborazione previsti per il sistema Astrazione procedurale considerare ogni operazione come
una singola entit, nonostante tale operazione sia effettivamente realizzata da un insieme di operazioni di pi basso livello concentra la sua attenzione sulla modularizzazione delle procedure i moduli devono essere il pi possibile indipendenti specifica le elaborazioni e le interfacce delle procedure
Lanalista
La scomposizione in funzioni molto volatile (a causa del continuo cambiamento dei requisiti funzionali)
Analisi
Approccio Orientato agli Oggetti

Si basa sugli oggetti che sono molto pi stabili delle funzioni
Produce una specifica pi resistente ai cambiamenti
Fornisce una base efficace per

lanalisi del dominio il riuso
Fornisce una rappresentazione omogenea analisi progettazione programmazione in quanto si utilizzano

gli stessi principi la stessa notazione gli stessi oggetti
Analisi
Analisi orientata agli oggetti
Produce un modello dei dati o modello statico
la parte fondamentale dellOOA, su cui si basa tutto il resto descrive le entit del mondo reale rilevanti per il sistema
un modello comportamentale o modello dinamico

completa il modello dei dati descrive le funzionalit del sistema
L'insieme dei due modelli costituisce il punto di partenza della successiva fase di progettazione
2.52
Modello dei dati

Analisi del dominio del problema al fine di individuare
Oggetti e classi rilevanti per il sistema da sviluppare
Limitarsi esclusivamente a quelle classi che fanno parte del vocabolario del dominio del problema
Relazioni tra le classi Per ogni classe Responsabilit Attributi Operazioni fondamentali cio servizi forniti allesterno (interfaccia)
Attivit non strettamente sequenziali, ma reiterate sino alla produzione di un modello coerente
Modello dei dati

Raggruppamento delle classi in sottosistemi Documentazione
Diagrammi delle classi e dei sottosistemi Diagrammi di collaborazione tra le classi (opzionali) Per ogni classe, descrizione che ne specifica scopo, responsabilit, attributi, operazioni Per ogni attributo e ogni operazione, descrizione testuale accurata
2.54
Analisi
Individuazione delle classi

Due analisti non produrranno mai due modelli delle classi identici per lo stesso dominio applicativo La letteratura ricca di approcci raccomandati per lindividuazione delle classi
Approccio basato sulle frasi nominali Approccio guidato dai casi duso Approccio CRC
La cosa migliore usare un approccio misto
2.55
Analisi

Fonti principali
Documento dei requisiti Altri documenti di tutti i tipi che descrivono il sistema
Altre fonti
Altri sistemi che funzionano nello stesso dominio o in domini analoghi Enciclopedie, nomenclature e documenti tecnici che descrivono il dominio
Riutilizzare classi, gerarchie e strutture ottenute da precedenti analisi nello stesso dominio
2.56
Analisi

Elencare i nomi (semplici o composti) che compaiono nei documenti raccolti, convertendoli al singolare Eliminare i nomi che sicuramente
non si riferiscono a classi indicano attributi (dati di tipo primitivo) indicano operazioni
Scegliere un solo termine significativo se pi parole indicano lo stesso concetto (sinonimi) Il nome della classe deve essere un nome familiare
allutente o allesperto del dominio del problema non allo sviluppatore!
2.57
Analisi

Attenzione agli aggettivi e agli attributi, possono Indicare oggetti diversi Indicare usi diversi dello stesso oggetto Essere irrilevanti Ad esempio: Studente bravo potrebbe essere irrilevante Studente fuori corso potrebbe essere una nuova classe Attenzione alle frasi passive, impersonali o con soggetti fuori dal sistema devono essere rese attive ed esplicite, perch potrebbero mascherare entit rilevanti per il sistema in esame
2.58
Analisi

Individuare Attori con cui il sistema in esame deve interagire Persone
Docente, Studente, Esaminatore, Esaminando,
Sistemi esterni Dispositivi
ReteLocale, Internet, DBMS, attuatori, sensori,
Individuare Modelli e loro elementi specifici, cio oggetti descrittivi e istanze specifiche
Insegnamento Ingegneria del Software T CorsoDiStudio Ingegneria Informatica Facolt Ingegneria
2.59
Analisi

Individuare Cose tangibili, cio oggetti reali appartenenti al dominio del problema
Banco, LavagnaLuminosa, Schermo, Computer,
Individuare Contenitori (fisici o logici) di altri oggetti

Facolt, Dipartimento, Aula, SalaTerminali, ListaEsame, CommissioneDiLaurea, OrdineDegliStudi, Window, Form,
Individuare Eventi o Transazioni che il sistema deve gestire e memorizzare - possono avvenire in un certo istante (ad es., una vendita) o - possono durare un intervallo di tempo (ad es., un affitto)
Appello, EsameScritto, Registrazione, AppelloDiLaurea,
Analisi

Per determinare se includere una classe nel modello, porsi le seguenti domande: il sistema deve interagire in qualche modo con gli oggetti della classe?
utilizzare informazioni (attributi) contenute negli oggetti della classe utilizzare servizi (operazioni) offerti dagli oggetti della classe
quali sono le responsabilit della classe nel contesto del sistema?
2.61
Analisi

Attributi e operazioni devono essere applicabili a tutti gli oggetti della classe Se esistono
attributi con un valore ben definito solo per alcuni oggetti della classe e/o operazioni applicabili solo ad alcuni oggetti della classe
siamo in presenza di ereditariet

Esempio: dopo una prima analisi, la classe Studente potrebbe contenere un attributo booleano inCorso, ma unanalisi pi attenta potrebbe portare alla luce la gerarchia: Studente StudenteInCorso StudenteFuoriCorso
Analisi
Individuazione delle responsabilit

Responsabilit di una classe
Descrizione ad alto livello dello scopo per cui stata definita la classe Vengono descritti solo i servizi disponibili pubblicamente, non quelli privati interni alla classe, la cui definizione sarebbe prematura
Obiettivo aiutare nellidentificazione di

Classi Attributi Operazioni Relazioni tra le classi
Analisi

Principali sorgenti di informazione
Documento dei requisiti Classi gi identificate
Cercare verbi che rappresentano azioni fatte da un oggetto del sistema Utilizzare le classi gi identificate per il semplice fatto di esistere, devono avere almeno una responsabilit Annotare tutte le informazioni che gli oggetti devono mantenere e gestire
Analisi

Una volta identificate, le responsabilit vanno assegnate alle classi in base ai seguenti criteri: Distribuire le responsabilit in modo bilanciato (molti oggetti che si scambiano messaggi) Assegnare le responsabilit al livello pi generale possibile salendo la gerarchia delle classi Mantenere il comportamento collegato alle informazioni ad esso necessarie
2.65
Analisi

Metodo di analisi CRC (Class-ResponsibilityCollaboration) di Cunningham e Beck
Nome della classe Lista di collaboratori
Lista di responsabilit
I collaboratori sono le altre classi con le quali la classe in esame deve interagire Si utilizzano schede di cartoncino di 10x15 cm
2.66
Analisi
Individuazione delle relazioni

La maggior parte delle classi (degli oggetti) interagisce con altre classi (altri oggetti) in vari modi Quando si modella un sistema necessario individuare:
non solo le entit coinvolte nel sistema ma anche le relazione tra tali entit
Una relazione (relationship) una connessione tra entit
2.67
Analisi

Nella modellazione object-oriented le relazioni pi importanti sono: Ereditariet Associazione
Associazione generica Aggregazione Composizione
Dipendenza
Collaborazione (relazione usa) Relazione Istanza Classe
Istanza di classe generica Classe generica (istanza di template template)
Relazione Classe Metaclasse

Analisi

In ogni tipo di relazione, esiste un cliente C che dipende da un fornitore di servizi F C ha bisogno di F per lo svolgimento di alcune funzionalit che C non in grado di effettuare autonomamente Conseguenza per il corretto funzionamento di C indispensabile il corretto funzionamento di F
2.69
Analisi

Tipo di relazione Ereditariet Associazione Cliente sottoclasse contenitore classe dipendente (che usa) Dipendenza istanza classe
Fornitore superclasse contenuto classe da cui si dipende (che viene usata) classe metaclasse
2.70
Analisi
Individuazione dellereditariet
La classe B (specializzazione o sottoclasse) in relazione IsA con la classe A (generalizzazione o superclasse) e ne eredita
Relazioni Attributi Operazioni A B
B A
2.71
Analisi
Individuazione dellereditariet
Lereditariet deve rispecchiare una tassonomia effettivamente presente nel dominio del problema
Non usare lereditariet dellimplementazione (siamo ancora in fase di analisi!) Non usare lereditariet solo per riunire caratteristiche comuni ad es., Studente e Dipartimento hanno entrambi un indirizzo, ma non per questo c ereditariet!
La ricerca delle relazioni di ereditariet contribuisce a chiarire il significato delle varie classi e pu portare alla scoperta di nuove classi
2.72
Analisi
Individuazione delle associazioni

Unassociazione rappresenta una relazione strutturale tra due istanze di classi diverse o della stessa classe Unassociazione pu
Rappresentare un contenimento logico (aggregazione)
Una lista desame contiene degli studenti
Rappresentare un contenimento fisico (composizione)

Un triangolo contiene tre vertici
Non rappresentare un reale contenimento

Una fattura si riferisce a un cliente Un evento legato a un dispositivo
Analisi

Aggregazione
Un oggetto x di classe X associato a (contiene) un oggetto y di classe Y in modo non esclusivo x pu condividere y con altri oggetti anche di tipo diverso (che a loro volta possono contenere y) Una lista desame contiene degli studenti Uno studente pu essere contemporaneamente in pi liste desame La cancellazione della lista desame non comporta leliminazione fisica degli studenti in lista
Analisi

Composizione
Un oggetto x di classe X associato a (contiene) un oggetto y di classe Y in modo esclusivo y esiste solo in quanto contenuto in x Un triangolo contiene tre punti (i suoi vertici) Leliminazione del triangolo comporta leliminazione dei tre punti Se la distruzione del contenitore comporta la distruzione degli oggetti contenuti, si tratta di composizione, altrimenti si tratta di aggregazione
Analisi

In UML
La composizione indicata con un rombo nero dalla parte del contenitore Laggregazione indicata con un rombo bianco dalla parte del contenitore
Ad ogni associazione possibile aggiungere:

Un nome (e una direzione di lettura del nome) I ruoli delle classi coinvolte La molteplicit, cio il numero di oggetti che possono partecipare all'associazione Il contenimento (aggregazione o composizione)
2.76
matrimonio marito Societ nome indirizzo Persona 1 lavora-per * nome indirizzo datore-lavoro impiegato codiceFiscale dataNascita sottoposto * 0..1 0..1 moglie dirigente 0..1 dirige
1 Poligono
contiene
3..* Punto {ordered}
Questo un commento associato alla classe Poligono. 1
Finestra
1 1..* 1
BarraTitolo
1 1 1
Pannello
Bordo
Etichetta
Pulsante Chiusura
Vari tipi di associazione.
2.77
Analisi

Per individuare potenziali aggregazioni o composizioni, considerare
Insieme-PartiComponenti Contenitore-Contenuto Collezione-Membri
Se contenitore e contenuto hanno un legame forte e uno stesso ciclo di vita, si tratta di composizione altrimenti, si tratta di aggregazione
2.78
Analisi

Per individuare potenziali associazioni generiche, per ogni oggetto, porsi le domande A quali altri oggetti collegato nel dominio del problema? Da chi deve ottenere informazioni per soddisfare alle sue responsabilit?
2.79
Analisi

Una volta determinata la presenza di unassociazione Tracciare la linea di connessione, eventualmente col simbolo di aggregazione o composizione dalla parte del contenitore Se possibile, dare un nome allassociazione e ai due ruoli, scegliendolo tra i termini del dominio del problema Definire il valore, lintervallo o linsieme di valori e/o intervalli del limite inferiore la connessione opzionale? il limite inferiore 0 la connessione obbligatoria? il limite inferiore 1 limite superiore la connessione singola? il limite superiore 1 la connessione multipla? il limite superiore > 1
Analisi

Molteplicit
Simbolo
n * n..m n,m
Significato
valore singolo da 0 a intervallo insieme di valori e/o intervalli
Esempi
1 * 0..1 1..* 1,3..5,7
2.81
Analisi

Attenzione alle associazioni molti a molti possono nascondere una classe (classe di associazione) del tipo evento da ricordare Esempio: la connessione propriet tra Proprietario e Veicolo nasconde una classe CompraVendita, che lega Proprietari e Veicoli Esempio: la connessione matrimonio tra Persona e Persona nasconde una classe Matrimonio, che lega due Persone
2.82
Analisi

1esempio
Un proprietario pu possedere molti veicoli Un veicolo pu essere di molti proprietari
in tempi successivi in compropriet Legame 1 a 1
Proprietario
Proprietario possiede Veicolo
* 1..*
* 1..*
1..* *
1..* * Veicolo
CompraVendita -dataAcquisto
2.83
Analisi

1esempio
Un proprietario pu partecipare a pi compravendite Un veicolo pu essere contemporaneamente di pi proprietari Una compravendita relativa a un solo veicolo
Proprietario 1..* partecipa a 1..* CompraVendita -dataAcquisto 1..* acquisto di Veicolo 1
1..* * Proprietario
1..* * Veicolo
CompraVendita -dataAcquisto
2.84
Analisi

Persona
*
matrimonio
*
Relazione n-m (matrimonio) tra due oggetti della stessa classe.
Persona
1
marito
*
Matrimonio data
moglie Un Matrimonio in effetti una classe, con due associazioni con oggetti di tipo Persona (marito e moglie).
2.85
Analisi
Individuazione delle collaborazioni

Una classe A in relazione USA con una classe B (A USA B) quando A ha bisogno della collaborazione di B per lo svolgimento di alcune funzionalit che A non in grado di effettuare autonomamente
Unoperazione della classe A ha bisogno come argomento di unistanza della classe B
void fun1(B b) { usa b }
Unoperazione della classe A restituisce un valore di tipo B

B fun2() { B b; return b; }
Unoperazione della classe A utilizza unistanza della classe B (ma non esiste unassociazione tra le due classi)
void fun3() { B b = new B(); usa b }
2.86
Analisi
Individuazione delle collaborazioni

La relazione non simmetrica A dipende da B, ma B non dipende da A Evitare situazioni in cui una classe, tramite una catena di relazioni USA, alla fine dipende da se stessa
Cliente Fornitore
Nome Interfaccia
Cliente Fornitore
Analisi
Individuazione degli attributi

Ogni attributo modella una propriet atomica di una classe Un valore singolo Una descrizione Un importo Un gruppo di valori strettamente collegati tra loro Un indirizzo Una data
2.88
Analisi

Propriet non atomiche di una classe devono essere modellate come associazioni
* Docente -cognome -nome
AfferisceA
1 Dipartimento -descrizione
EDirettoDa 1 Direttore 0..1
2.89
Analisi

Il nome dellattributo
Deve essere un nome familiare allutente o allesperto del dominio del problema non allo sviluppatore! Non deve essere il nome di un valore (qualifica s, ricercatore no) Deve iniziare con una lettera minuscola
Esempi
cognome dataDiNascita annoDiImmatricolazione
Analisi

Esprimere tutti i vincoli applicabili allattributo Tipo (semplice, struttura, enumerativo)
cognome: string sesso: {maschio, femmina}
Valori ammessi Valore di default

sesso: {maschio, femmina} = maschio
Vincoli di creazione o di accesso Vincoli dovuti ai valori di altri attributi

Analisi

Esprimere tutti i vincoli applicabili allattributo Opzionalit
votoFinale [0..1]: Votazione
Unit di misura, precisione Visibilit (opzionale in fase di analisi) Pubblica + Protetta # Privata Attenzione: gli attributi devono essere sempre privati!
Analisi

Esprimere tutti i vincoli applicabili allattributo Appartenenza alla classe (e non allistanza) Attributi (e associazioni) possono essere di classe, cio essere unici nella classe e quindi non fare parte della struttura dati delle istanze
-numIstanze: int = 0
2.93
Analisi

I vincoli possono essere scritti
Utilizzando direttamente UML
Tipo Opzionalit Visibilit
Utilizzando Object Constraint Language (OCL)

descritto in The Unified Modeling Language Reference Manual
Come testo in formato libero in un commento UML

Analisi

da memorizzare in mm. da visualizzare in cm. pu essere modificata
Persona altezza: Integer sesso: {femmina, maschio} et() 0..1 marito matrimonio {self.moglie.sesso = femmina and self.marito.sesso = maschio}
0..1 moglie
2.95
Analisi

In un certo istante, ogni oggetto avr un valore specifico per ogni attributo della classe di appartenenza: informazione di stato Attenzione: attributi con valore non applicabile o con valore opzionale o a valori multipli (enumerazioni) possono nascondere ereditariet o una nuova classe
Analisi

Docente -cognome -nome Qualifica -descrizione * 1
Docente -cognome -nome -qualifica

Docente -cognome -nome
Ricercatore
Ordinario
Associato
2.97
Analisi

Attenzione nel caso di attributi con valore s o no, il nome dellattributo potrebbe essere uno dei valori di unenumerazione ad esempio: tassabile (s o no) potrebbe diventare tipoTassazione (tassabile, esente, ridotto, ecc.)
2.98
Analisi

Attenzione nel caso di attributi calcolabili (ad esempio, et), specificare sempre loperazione di calcolo mai lattributo Se memorizzare oppure no un attributo calcolabile una decisione progettuale, un compromesso tra tempo di calcolo spazio di memoria
2.99
Analisi

Attenzione non definire attributi che indicano il tipo (o categoria) di un oggetto Deve essere sempre possibile ottenere il tipo di un oggetto mediante unoperazione, ad esempio nomeClasse() GetType() in .NET
GetType().ToString() per avere il nome della classe
2.100
Analisi

Applicare lereditariet:
Posizionare attributi e associazioni pi generali pi in alto possibile nella gerarchia Posizionare attributi e associazioni specializzati pi in basso
2.101
Analisi
Individuazione delle operazioni

Per completare la fase di analisi, necessario descrivere in modo dettagliato gli aspetti pi volatili del sistema Le operazioni (o servizi) che ogni classe deve offrire La sequenza temporale di tali operazioni
2.102
Analisi

Operazione: azione, o insieme di azioni, che tutti gli oggetti della stessa classe devono essere in grado di compiere per raggiungere un determinato scopo Sono in stretto rapporto con le responsabilit di una classe, escluse le responsabilit di mantenere le informazioni di stato Si eseguono coinvolgendo uno specifico oggetto della classe (invio di un messaggio alloggetto) Possono anche essere assegnate a una classe e non alle sue istanze
2.103
Analisi

Il nome delloperazione
Deve appartenere al vocabolario standard del dominio del problema Potrebbe essere un verbo allimperativo (scrivi, esegui, ...) o in terza persona (scrive, esegue, ...) in modo consistente in tutto il sistema Dovrebbe iniziare con una lettera maiuscola (convenzione .NET)
2.104
Analisi

Notazione UML
visibilit nomeOperazione(lista-parametri): tipoRestituito
+GetCognome(): string +SetCognome(nuovoValore: string) +GetNumIstanze(): int +Visualizza(disp: OutputDevice)
2.105
Analisi

Operazioni standard
Operazioni che tutti gli oggetti hanno per il semplice fatto di esistere e di avere degli attributi e delle relazioni con altri oggetti Sono implicite e, di norma, non compaiono nel diagramma delle classi
Altre operazioni
Devono essere determinate
servizi offerti agli altri oggetti
Compaiono nel diagramma delle classi

Analisi

Operazioni standard Costruttore
Inizializza un nuovo oggetto (.ctor) Invocato automaticamente dalla new Effettua tutte le azioni necessarie per rilasciare le risorse possedute dalloggetto Invocato automaticamente da GC o delete Get - restituisce il valore di un attributo atomico o il riferimento a un oggetto (nel caso di associazioni)
Distruttore
Accessor
Set - modifica il valore di un attributo atomico oppure collega/scollega un oggetto a un altro oggetto (nel caso di associazioni)
2.107
Analisi

Classi contenitori Operazioni standard
Aggiungi, rimuovi, conta, itera,
Altre operazioni riguardano linsieme degli oggetti, non il singolo oggetto

Calcoli da effettuare sugli oggetti contenuti
CalcolaSulleParti(), Totalizza()
Selezioni da fare sugli oggetti contenuti

TrovaPartiSpecifiche()
Operazioni del tipo

InviaComandoATutteLeParti()
Analisi

Distribuire in modo bilanciato le operazioni nel sistema Mettere ogni operazione vicino ai dati ad essa necessari Applicare lereditariet
Posizionare le operazioni pi generali pi in alto possibile nella gerarchia Posizionare le operazioni specializzate pi in basso
2.109
Analisi

Descrivere tutti i vincoli applicabili alloperazione
Parametri formali, loro tipo e significato Pre-condizioni e post-condizioni Invarianti di classe Eccezioni sollevate Eventi che attivano loperazione Applicabilit delloperazione
Analisi

PRE-CONDIZIONE
Espressione logica riguardante le aspettative sullo stato del sistema prima che venga eseguita unoperazione Ad esempio, per loperazione CalcolaRadiceQuadrata(valore), la pre-condizione potrebbe essere: valore 0 Esplicita in modo chiaro che responsabilit della procedura chiamante controllare la correttezza degli argomenti passati
Analisi

POST-CONDIZIONE
Espressione logica riguardante le aspettative sullo stato del sistema dopo lesecuzione di unoperazione Ad esempio, per loperazione CalcolaRadiceQuadrata(valore), la post-condizione potrebbe essere: valore == risultato * risultato
2.112
Analisi

INVARIANTE di classe
Vincolo di classe (espressione logica) che deve essere sempre verificato sia allinizio sia alla fine di tutte le operazioni pubbliche della classe Pu non essere verificato solo durante lesecuzione delloperazione
2.113
Analisi

In caso di ridefinizione di unoperazione in una sotto-classe
Le pre-condizioni devono essere identiche o meno stringenti Le post-condizioni devono essere identiche o pi stringenti Gli invarianti di classe devono essere identici o pi stringenti
2.114
Analisi

ECCEZIONE
Si verifica quando unoperazione viene invocata nel rispetto delle sue pre-condizioni ma non in grado di terminare la propria esecuzione nel rispetto delle post-condizioni
2.115
Modello dei dati

CatenaPuntiVendita idCatenaPuntiVendita nome : String numeroPuntiVendita() importoVenditeGiorno() importoVenditeTotale() elencaVendite() 1
1..* PuntoVendita idPuntoVendita idProgressivo : Integer importoVenditeGiorno() importoVenditeTotale() creaMovimento() elencaVendite()
Servizio 1..* *
2.116
Modello dei dati

PuntoVendita idPuntoVendita idProgressivo : Integer importoVenditeGiorno() importoVenditeTotale() creaMovimento() elencaVendite() 1 venditore use GuestCard acquirente 1
Acquisto Vendita Movimento idMovimento : Integer data : Date importo : Currency
0..*
0..*
2.117
Modello dei dati

actor Ospite idOspite nome : String indirizzo : String dataNascita : Date sesso inizioSoggiorno : Date fineSoggiorno : Date speseGiorno() speseTotali() elencaAcquisti() Conto idConto : Integer limiteGiornaliero : Currency saldato : Boolean speseGiorno() speseTotali() elencaAcquisti() 1
1..* GuestCard idGuestCard : Integer inizioValidit : Date fineValidit : Date abilitata() speseGiorno() speseTotali() elencaAcquisti()
2.118
Modello dei dati

actor Ospite idOspite nome : String indirizzo : String dataNascita : Date sesso inizioSoggiorno : Date fineSoggiorno : Date speseGiorno() speseTotali() elencaAcquisti()
{OR}
OspitePagante scegliFormaDiPagamento() effettuaPagamento() elencaTuttiGliAcquisti()
1 pagante
associatoA
0..*
OspiteNonPagante
2.119
Modello dei dati
OspitePagante haScelto scegliFormaDiPagamento() effettuaPagamento() elencaTuttiGliAcquisti() 1 1 FormaDiPagamento effettuaPagamento() * 1 Valuta
Contante effettuaPagamento()
CartaDiCredito idCartaDiCredito tipo : String dataScadenza : Date effettuaPagamento()
2.120
Analisi
Modello dinamico
Descrive il sistema durante il suo funzionamento Consiste nella definizione di scenari di funzionamento del sistema, in risposta a eventi esterni o in fasi particolarmente significative Diagrammi dei casi duso - evidenziano le risposte a eventi esterni Diagrammi di stato - evidenziano i possibili stati che un oggetto pu assumere gli eventi che attivano transizioni da uno stato allaltro
Analisi
Modello dinamico
Diagrammi di interazione - descrivono lo scambio di messaggi tra oggetti Diagrammi di sequenza - evidenziano lordine in cui i messaggi vengono scambiati tra gli oggetti Diagrammi di collaborazione - evidenziano le connessioni tra gli oggetti e i messaggi scambiati Entro certi limiti, un diagramma di sequenza pu essere convertito nel suo corrispondente diagramma di collaborazione e viceversa
Analisi
Modello dinamico
Non conviene spingere la definizione del modello dinamico sino ai minimi dettagli Utilizzare i diagrammi dinamici solo per descrivere il funzionamento del sistema nei casi pi critici La definizione dettagliata di tutte le operazioni del sistema pu essere fatta realizzando un prototipo funzionante
2.123
Analisi Diagrammi di interazione

Obiettivo Evidenziare le interazioni (e quindi lo scambio di messaggi) tra gli oggetti del sistema reale Modellare solo gli scenari veramente cruciali al funzionamento del sistema Partire dai casi duso, cio considerare ci che deve fare il sistema in risposta a richieste dei suoi utenti o a eventi esterni
2.124
Analisi Diagrammi di interazione

Linvio di un messaggio (o richiesta di un servizio) da un oggetto mittente (o cliente) a un oggetto destinatario (o fornitore) deve corrispondere a unoperazione della classe del destinatario o di una sua superclasse Pertanto, ogni messaggio comprender: il nome delloperazione invocata gli eventuali parametri attuali un eventuale valore restituito
2.125
Analisi Definizione di una sequenza di messaggi

Considerare lattore, levento esterno o il generico oggetto che scatena la sequenza di operazioni Determinare il primo servizio richiesto e il fornitore di tale servizio specificare il primo messaggio Immedesimarsi nelloggetto (o nella classe) che riceve il messaggio e chiedersi
sono in grado di eseguire in modo autonomo loperazione richiesta?
In caso negativo, chiedersi

a quali altri oggetti devo inviare messaggi per ottenere i dati e/o i (sotto) servizi mancanti?

Iterare il procedimento, sino allidentificazione di tutta la sequenza dei messaggi Identificare modelli comportamentali standard di interazione tra oggetti (pattern) Ricordarsi che un oggetto (cliente) pu inviare un messaggio (chiedere un servizio) ad un altro oggetto (fornitore) solo durante lesecuzione di un proprio metodo solo se conosce il fornitore
2.127

Il fornitore un oggetto globalmente accessibile (una classe o un oggetto globale) Il fornitore contenuto nel cliente (per valore o per riferimento) Il fornitore stato passato come parametro attuale al metodo del cliente Il fornitore il risultato dellinvio di un precedente messaggio dentro il metodo del cliente due possibilit: Il fornitore esisteva gi Il fornitore viene creato, utilizzato (e distrutto)

Se il traffico di messaggi necessari per accedere a un fornitore troppo alto, forse opportuno aggiungere una connessione permanente tra cliente e fornitore Se ci sono oggetti che dominano lo scenario, facendo quasi tutto, forse esiste un problema di distribuzione delle responsabilit
2.129
Analisi Diagrammi di sequenza

Obiettivo: porre in evidenza la sequenza (e la durata temporale) dei messaggi scambiati tra gli oggetti
cliente : Package1::ClasseA
fornitore : Package1::ClasseB
messaggio1()
2.130

Gli oggetti sono rettangoli con dentro i nomi sottolineati delloggetto e/o della relativa classe
new : Dipartimento
Le linee verticali tratteggiate (lifeline) indicano il tempo di vita degli oggetti Il flusso temporale scorre dallalto in basso Gli ispessimenti delle linee verticali denotano unelaborazione in corso possibile indicare esplicitamente quando un oggetto viene creato e quando viene distrutto
2.131

Tra gli oggetti vi possono essere invii di messaggi, denotati da frecce, e ritorni (opzionali)
unCliente messaggio1()
unFornitore
2.132
2.133
2.134
Analisi Diagrammi di collaborazione

Obiettivo: porre in evidenza come gli oggetti sono connessi tra di loro e come collaborano
2.135

Una connessione tra oggetti:
Modella le dipendenze di un oggetto per quanto riguarda le elaborazioni, indicando la necessit di richiedere servizi per soddisfare le sue responsabilit Mostra graficamente laccesso di un oggetto (il cliente) ad un altro oggetto (il fornitore del servizio) e la richiesta di un servizio in stretto rapporto con le collaborazioni di un oggetto
2.136

Gli oggetti sono rettangoli con dentro i nomi sottolineati delloggetto e/o della relativa classe (come nei diagrammi di sequenza) Le connessioni tra oggetti sono mostrate come linee continue tracciate tra gli oggetti
2.137

L'invio di un messaggio indicato da: una freccia posta parallelamente alla connessione un numero progressivo che fornisce la posizione nella sequenza di invio dei messaggi una condizione (opzionale) tra parentesi quadre il nome del messaggio ed eventualmente i suoi argomenti
2.138
Analisi Diagrammi di stato

Lo stato di un oggetto dato dal valore dei suoi attributi e delle sue associazioni In molti domini applicativi, esistono oggetti che, a seconda del proprio stato, rispondono in maniera diversa ai messaggi ricevuti
Dispositivi (spento, in attesa, operativo, guasto, ecc.) Transazioni complesse (in definizione, in esecuzione, completata, fallita, ecc.)
In questi casi, opportuno disegnare un diagramma di stato per loggetto, mostrando i possibili stati e gli eventi che attivano transizioni da uno stato all'altro
Analisi Diagrammi di stato STATO

Situazione, che si verifica durante la vita di un oggetto, nella quale loggetto soddisfa certe condizioni esegue certe attivit aspetta il verificarsi di certi eventi
2.140
Analisi Diagrammi di stato EVENTO

Fatto che avviene in un intervallo di tempo e in una porzione di spazio cos ristretti da poterlo considerare caratterizzato da un istante e/o da un punto
Pu essere:
Esterno generato nellambito del mondo reale (mouse, tastiera, arrivo ordine, passaggio qualifica, ) Interno generato da un oggetto del sistema
2.141

Call Event
Occurs when an element receives a call for an operation
Signal Event
Occurs when an element receives an explicit signal from another element
Change Event Time Event
Occurs when a designated condition (usually described as a Boolean operation) becomes true Occurs after a designated period of time or at a specific time or date
2.142
TRANSIZIONE
Relazione tra due stati S1 (stato di partenza) e S2 (stato di arrivo) indicante che un oggetto inizialmente nello stato S1 in seguito al verificarsi di un particolare evento e se sono soddisfatte certe condizioni, effettuer certe azioni ed entrer nello stato S2
2.143
AZIONE
Computazione atomica (non interrompibile) associata a una transizione
ATTIVIT
Computazione non atomica (interrompibile) associata a uno stato insieme di azioni
2.144

Notazione UML
stato nome stato
TypingPassword
entry / setEchoVisible(false) exit / setEchoVisible(true) do / attivit
2.145

Notazione UML
Stato1
evento [condizione] / azione
Stato2
transizione
2.146
Analisi Identificazione degli stati

Esaminare i possibili valori degli attributi di un oggetto Determinare se le responsabilit del sistema prevedono
comportamenti diversi per valori diversi degli attributi
Descrivere mediante un diagramma di stato

tutti i possibili stati che un oggetto pu assumere durante la sua vita e come cambia lo stato delloggetto in conseguenza degli eventi
2.147

Iscrizione [numero esami sufficiente] / Iscrivi all'anno successivo
Immatricolazione / Iscrivi al I anno In Corso
SuperamentoEsameDiLaurea after: [Scadenza termini]
Ritirato
Iscrizione [numero esami insufficiente] / Iscrivi allo stesso anno Iscrizione [numero esami sufficiente] / Iscrivi all'anno successivo
Laureato
after: [Scadenza termini]
SuperamentoEsameDiLaurea
Fuori Corso
Iscrizione [numero esami insufficiente] / Iscrivi allo stesso anno
2.148
Struttura a livelli di un'applicazione
APPLICAZIONE
PRESENTATION MANAGER
APPLICAZIONE
PRESENTATION LOGIC
APPLICATION LOGIC
DATA LOGIC
DATA MANAGER
Presentation Manager
Gestione dellinterazione con lutente Gestione dello schermo Gestione della tastiera Gestione del mouse
Interfacce grafiche (GUI)

API (Application Programming Interface) di sistema browser HTML
Interfacce a caratteri
emulatori
Ingegneria del Software T 4
Data Manager
DATA MANAGER
Gestione di tutti i dati persistenti Storage Retrieval Management Recovery
File system RDBMS ODBMS
Stored procedure Trigger
Data Manager
File system
API di sistema
RDBMS: DB2, Oracle, MS SQL Server, Informix, Sybase,

API proprietarie ODBC (Open Data Base Connectivity), JDBC (standard)
ODBMS: ObjectStore,
API proprietarie
APPLICAZIONE
PRESENTATION LOGIC APPLICATION LOGIC DATA LOGIC
Presentation Logic
Gestione dellinterazione con lutente a livello logico

Formattazione e visualizzazione delle informazioni (output) Accettazione dei dati (input) Prima validazione dei dati Gestione dei messaggi di errori
APPLICAZIONE
Application Logic
Logica dellapplicazione e controllo componenti
APPLICAZIONE
Data Logic
Gestione della persistenza a livello logico

Consistenza dei dati Apertura/chiusura file, read, write e lock/unlock Istruzioni SQL, transazioni (commit e rollback) Gestione degli errori
PRESENTATION MIDDLEWARE
APPLICAZIONE
PRESENTATION LOGIC
APPLICATION LOGIC
DATA LOGIC
DATABASE MIDDLEWARE
DATA MANAGER
10
Middleware
Software che permette la comunicazione tra processi API che isolano il codice dellapplicazione dai sottostanti formati e protocolli di comunicazione
11
Presentation Middleware
Software di emulazione di terminali alfanumerici Combinazione di:
Web browser (lato client) Web server Protocollo HTTP
12
Database Middleware
Software proprietario che trasferisce sulla rete
Le richieste SQL dallapplicazione al DBMS I dati dal DBMS allapplicazione
ODBC, JDBC
13
APPLICAZIONE
PRESENTATION LOGIC
APPLICATION LOGIC
APPLICATION MIDDLEWARE
APPLICAZIONE
APPLICATION LOGIC
DATA LOGIC
14
Application Middleware
Gestisce la comunicazione tra due componenti della stessa applicazione meno vincoli progettuali
Point-to-point (P2P) Remote procedure call (RPC) Message queuing middleware (MQM) Message oriented middleware (MOM), P2P + MQM Object request broker (ORB) Distributed transaction monitor (DTM)
Pu anche interconnettere tipi diversi di middleware
15
Progettazione orientata agli oggetti
DallOOA allOOD
LOOA identifica e definisce le responsabilit del sistema le classi e gli oggetti entro i limiti del dominio del problema LOOA definisce il modello statico e il modello dinamico del sistema, indipendentemente dalla specifica implementazione dalle modalit di interazione con lutente dalle modalit di persistenza degli oggetti
DallOOA allOOD
Per realizzare un sistema funzionante, occorre considerare anche GUI DB Framework, librerie, componenti, Modifiche al modello per avere software estensibile e modulare
DallOOA allOOD
LOOD identifica e definisce altre classi e oggetti alla luce dei seguenti principi
Incapsulamento Flessibilit Evoluzione Riuso Prestazioni Massima indipendenza possibile da
Linguaggio (e ambiente) di programmazione Sistema Operativo Hardware
Si noti che mediamente le classi di analisi sono solo tra l1% e il 10% delle classi di progettazione!
DallOOA allOOD
Il paradigma ad oggetti permette
Sia di modellare il mondo reale Sia di implementare il software
Nella fase di progettazione NON occorre creare un modello differente da quello sviluppato nella fase di analisi Si utilizza ununica notazione
Sia nella fase di analisi Sia nella fase di progettazione
DallOOA allOOD
Durante lOOD, il modello prodotto dallOOA deve essere esteso al fine di modellare/progettare i quattro componenti principali di ogni singola applicazione che compone il sistema APPLICATION LOGIC logica dellapplicazione e controllo degli altri componenti PRESENTATION LOGIC gestione dellinterazione con lutente a livello logico nuovi oggetti: finestre, men, bottoni, toolbar, DATA LOGIC gestione della persistenza a livello logico nuovi oggetti: file, record, tabelle relazionali, transazioni, istruzioni SQL, MIDDLEWARE gestione dellinterazione con i (sotto)sistemi esterni e con la rete
DallOOA allOOD
NellOOD, i risultati dellanalisi possono essere modificati per motivi di opportunit legati allimplementazione Le modifiche devono essere ridotte al minimo indispensabile, per mantenere il massimo accordo possibile tra OOA e OOD Principali motivi per modificare il modello OOA
Progettazione logica definizione dettagliata dellimplementazione delle classi e delle loro relazioni Riuso di classi e/o componenti disponibili Raggruppamento di classi del modello
DallOOA allOOD
Principali motivi per modificare il modello OOA
Miglioramento delle prestazioni Aggiunta di caratteristiche specifiche
Gestione persistenza Gestione comunicazioni Diagnostica,
Supporto alla portabilit Se e solo se vincolanti, caratteristiche del linguaggio di programmazione, del S.O., dellhardware, del DBMS, ... che devono essere utilizzati
Livello di ereditariet supportato Api
Progettazione logica
Progetto dello schema logico del modello Tipi di dato Strutture dati Operazioni Mentre nellanalisi ci si concentra su cosa deve fare il sistema, nella progettazione logica ci si concentra su come deve funzionare il sistema
Il passaggio dallOOA allOOD non ben supportato dagli strumenti CASE: non c modo di separare le due fasi Due possibilit Lanalisi sfuma nella progettazione
il modello OOA viene progressivamente aumentato e completato, sino alla progettazione del sistema lanalisi originale si perde
Il modello OOD generato a partire dal modello OOA, ma viene mantenuto distinto
lanalista deve mantenere la corrispondenza tra i due modelli, in caso di modifiche che si ripercuotono sullanalisi
Durante la progettazione logica necessario definire
Tipi di dato che non sono stati definiti nel modello OOA Determinazione della navigabilit delle associazioni tra classi e relativa implementazione Strutture dati necessarie per limplementazione del sistema Operazioni necessarie per limplementazione del sistema Algoritmi che implementano le operazioni Visibilit di classi, (attributi,) operazioni,
11
Navigabilit di unassociazione
Possibilit di spostarsi da un qualsiasi oggetto della classe origine a uno o pi oggetti della classe destinazione (a seconda della molteplicit) I messaggi possono essere inviati solo nella direzione della freccia
Ogni docente deve avere un riferimento al proprio dipartimento di afferenza
Ogni dipartimento deve avere un riferimento al proprio direttore Ingegneria del Software T 12
A livello di analisi, le associazioni di contenimento e di aggregazione hanno una direzione precisa detti A il contenitore e B loggetto contenuto, A che contiene B, e non viceversa A livello implementativo, unassociazione pu essere mono-direzionale quando da A si deve poter accedere a B, ma non viceversa bi-direzionale quando da A si deve poter accedere a B e da B si deve poter accedere velocemente ad A
13
Dal punto di vista implementativo, la bi-direzionalit
molto efficiente ma occorre tenere sotto controllo la consistenza delle strutture dati utilizzate per la sua implementazione
Ogni dipartimento deve avere i riferimenti a tutti i suoi docenti Ogni docente deve avere un riferimento al proprio dipartimento di afferenza
14
Implementazione delle associazioni

Associazioni con molteplicit 0..1 o 1..1 Aggiungere alla classe cliente (contenitore) un attributo membro che rappresenta il riferimento alloggetto della classe fornitore
lindirizzo di memoria delloggetto lidentificatore univoco delloggetto (solo se persistente)
il valore delloggetto della classe fornitore (solo nel caso di composizione)
15

Valuta FormaDiPagamento valutaScelta : Valuta effettuaPagamento() * 1 idValuta : String cambio : Double dataAggiornamento : Date aggiornaCambio()
Valuta FormaDiPagamento idValuta : String effettuaPagamento() * 1 idValuta : String cambio : Double dataAggiornamento : Date aggiornaCambio()
16

Associazioni con molteplicit 0..* o 1..* Utilizzare una classe (classe contenitore) le cui istanze sono collezioni di (riferimenti a) oggetti della classe fornitore Aggiungere alla classe cliente un attributo che rappresenta unistanza della classe contenitore per valore, oppure per riferimento La classe contenitore pu essere realizzata, oppure presa da una libreria (preferibilmente)
17

PuntoVendita idPuntoVendita[1] idProgressivo[1] : Integer servizi[1..*] : Servizio importoVenditeGiorno() importoVenditeTotale() creaMovimento() elencaVendite()
Servizio 1..* *
PuntoVendita idPuntoVendita idProgressivo : Integer servizi : Servizi importoVenditeGiorno() importoVenditeTotale() creaMovimento() elencaVendite()
Servizio 1..* *
Servizi 1 1
18

CatenaPuntiVendita puntiVendita[1..*] : PuntoVendita creaPuntoVendita() eliminaPuntoVendita() numeroPuntiVendita() elencaServizi() 1 1..* PuntoVendita owner : CatenaPuntiVendita Servizio 1..* * Servizi 1 1 aggiungiServizio() rimuoviServizio() elencaServizi()
19

CatenaPuntiVendita puntiVendita[1..*] : PuntoVendita Servizio 1..* * Servizi 1 1 creaPuntoVendita() eliminaPuntoVendita() numeroPuntiVendita() elencaServizi() 1 1..* PuntoVendita owner : CatenaPuntiVendita aggiungiServizio() rimuoviServizio() elencaServizi()
20

CatenaPuntiVendita 1 puntiVendita[1..*] : PuntoVendita creaPuntoVendita() eliminaPuntoVendita() numeroPuntiVendita() elencaServizi() 1 Servizio 1..* * 1 serviziExtra PuntoVendita owner : CatenaPuntiVendita 1 aggiungiServizio() rimuoviServizio() elencaServizi() serviziComuni 1 Servizi 1..*
21

CatenaPuntiVendita puntiVendita[1..*] : PuntoVendita creaPuntoVendita() eliminaPuntoVendita() numeroPuntiVendita() elencaServizi() 1
PuntiVendita 1 CatenaPuntiVendita owner 1 1
1..* PuntoVendita owner : CatenaPuntiVendita aggiungiServizio() rimuoviServizio() elencaServizi()
PuntoVendita * 1..*
22
Classi contenitore
Una classe contenitore (o semplicemente contenitore) una classe le cui istanze contengono oggetti di altre classi Se gli oggetti contenuti sono in numero fisso e non richiesto un particolare ordine, pu essere sufficiente un vettore predefinito del linguaggio Se gli oggetti contenuti sono in numero variabile o hanno un ordine da mantenere, allora un vettore predefinito non basta e occorre una classe contenitore Esempi di classi contenitore sono Vettori, stack, liste, alberi,
23
Classi contenitore
Funzionalit minime di una classe contenitore Memorizzare (e quindi tenere insieme) gli oggetti della collezione Aggiungere un oggetto alla collezione Togliere un oggetto dalla collezione Trovare un oggetto in una collezione Enumerare (iterare su) gli oggetti della collezione I contenitori possono essere classificati in funzione del modo in cui contengono gli oggetti dellomogeneit o eterogeneit di tali oggetti
24
Contenimento per valore

Loggetto contenuto (fornitore) viene memorizzato nella struttura dati del contenitore (cliente) esiste solo in quanto contenuto fisicamente in un altro oggetto Quando un oggetto deve essere inserito in un contenitore, viene duplicato La distruzione del contenitore comporta la distruzione degli oggetti contenuti
25
Contenimento per riferimento

Loggetto contenuto esiste per conto proprio Loggetto contenuto pu essere in pi contenitori contemporaneamente Quando un oggetto viene inserito in un contenitore, non viene duplicato ma ne viene memorizzato solo il riferimento La distruzione del contenitore non comporta la distruzione degli oggetti contenuti Se un oggetto contenuto viene cancellato e il contenitore non ne viene avvisato, sorgono grossi problemi
26
Contenimento di oggetti omogenei ed eterogenei

Un contenitore pu contenere una collezione di oggetti omogenei, cio tutti dello stesso tipo oggetti eterogenei, cio di tipo diverso Per implementare contenitori di oggetti omogenei (sia per valore, sia per riferimento) sono ideali le classi generiche (template) Per implementare contenitori di oggetti eterogenei (solo per riferimento) necessario usare lereditariet e sfruttare la propriet che un puntatore alla superclasse radice della gerarchia pu puntare a unistanza di una qualunque sottoclasse
27
Contenimento di oggetti omogenei

Classi generiche (template) Il tipo degli oggetti contenuti viene lasciato generico e ci si concentra sugli algoritmi di gestione della collezione di oggetti Quando serve una classe contenitore di oggetti appartenenti a una classe specifica, sufficiente istanziare la classe generica, specificando il tipo desiderato
28
Classi generiche
Classi in cui uno o pi tipi (e/o valori) sono parametrici Ogni istanza di una classe generica costituisce una classe indipendente non esiste un legame di ereditariet
T Vettore
bind (Integer)
Vettore<Integer> VettoreDiInteri
29
Classe generica Stack (C#)

public class Stack<T> { private T[] _array; private int _size; private const int _defaultCapacity = 4; private static T[] _emptyArray = new T[0]; public Stack() { _array = _emptyArray; _size = 0; } public int Count { get { return _size; } }

public void Push(T item) { if (_size == _array.Length) { T[] destinationArray = new T[(_array.Length == 0) ? _defaultCapacity : (2 * _array.Length)]; Array.Copy(_array, 0, destinationArray, 0, _size); _array = destinationArray; } _array[_size++] = item; }
31

public T Peek() { if (_size == 0) throw new InvalidOperationException("_size == 0"); return _array[_size - 1]; } public T Pop() { if (_size == 0) throw new InvalidOperationException("_size == 0"); T local = _array[--_size]; _array[_size] = default(T); return local; }

public void Clear() { // Sets a range of elements in the System.Array // to zero, to false, or to null, // depending on the element type. Array.Clear(_array, 0, _size); _size = 0; } } // Stack<T>
33

Stack<int> s1; Stack<double> s2; Stack<DateTime> s3; Stack<Stack<int>> s4; for (int j = 1; j <= 20; j++) s1.Push(j); while (s1.Count > 0) { int v = s1.Pop(); // utilizzo di v }
34
Contenimento di oggetti omogenei
T Vector bind(Servizio)
* Servizi
1..* Servizio
35
Contenimento di oggetti eterogenei

necessario utilizzare lereditariet La classe contenitore pu essere generica, ma solo per quanto attiene la gestione dei riferimenti agli oggetti contenuti Nei linguaggi come Smalltalk, Java e C#, tutte le classi derivano da una sola classe radice In C#, la classe radice object (System.Object)
36
Contenimento di oggetti eterogenei

In alcuni linguaggi (ad es. Java), i valori primitivi NON DERIVANO dalla classe radice, pertanto una classe contenitore Non pu contenere valori primitivi eterogenei ad esempio, se 120 non deriva dalla classe radice necessario usare new Integer(120) In altri linguaggi (ad es. C#), i valori primitivi DERIVANO dalla classe radice, pertanto una classe contenitore Pu contenere valori primitivi eterogenei (boxing)
Esempio 2

Un modo alternativo per implementare unassociazione tra due oggetti tramite un dizionario Un dizionario un tipo particolare di contenitore, che associa due oggetti: la chiave e il rispettivo valore La chiave Pu essere un oggetto qualsiasi non necessariamente una stringa o un intero Deve essere unica Il dizionario, data una chiave, ritrova in modo efficiente il valore ad essa associato
38

1 owner 1..*
1 CatenaPuntiVendita
1..* Entry * 1 Dictionary
1
PuntoVendita
: PuntoVendita : PuntoVendita
chiave
valore
: CatenaPuntiVendita
: CatenaPuntiVendita : PuntoVendita
39
Identificazione degli oggetti

Un oggetto (contenitore o no) pu contenere un riferimento univoco a un altro oggetto Come possibile identificare univocamente un oggetto per poterlo associare ad un altro? Nel caso di strutture dati interamente contenute nello spazio di indirizzamento dellapplicazione, un oggetto pu essere identificato univocamente mediante il suo indirizzo (logico) di memoria
40

Nel caso di database o di sistemi distribuiti, ad ogni oggetto deve essere associato un identificatore univoco persistente tramite il quale deve essere possibile risalire all'oggetto stesso, sia che risieda in memoria, su disco o in rete Lidentificatore univoco un attributo che al momento della creazione delloggetto viene inizializzato con: un valore generato automaticamente dal sistema il valore della chiave primaria di una tabella relazionale, Il nome di tale attributo potrebbe essere idDocente idStudente,
41
Un esempio reale
La tecnologia COM (MS) permette a unapplicazione di trovare, caricare e utilizzare run-time i componenti necessari per la sua esecuzione Ogni componente memorizzato in una DLL (Dynamic Link Library) un file locale o remoto Quando lapplicazione ha bisogno di un componente, il sistema deve essere in grado di localizzare la DLL che contiene quel particolare componente
42
Un esempio reale
Lindipendenza dalla collocazione fisica non consente di utilizzare un indirizzo fisico (pathname) Pertanto, deve essere utilizzato un meccanismo di indirizzamento logico che permetta di identificare univocamente il file che contiene il componente Si utilizzano degli identificatori globali (GUID = Globally Unique Identifier)
43
Un esempio reale
Il concetto di GUID stato introdotto, con un nome leggermente diverso (UUID = Universally Unique Identifier), dallOSF (Open Software Foundation) nelle specifiche DCE (Distributed Computing Environment) In DCE gli UUID vengono utilizzati per identificare i destinatari delle chiamate di procedura remota (RPC)
44
Un esempio reale
Un GUID un numero di 128 bit (16 byte) generato in modo da garantire lunicit nello spazio e nel tempo: MAC (48/64 bit) + ticks (64 bit 100ns) rappresentato cos: {32bb8320-b41b-11cf-a6bb-0080c7b2d682} COM utilizza diversi tipi di GUID Il tipo pi importante di GUID serve a identificare le classi di componenti: ogni classe di componenti COM caratterizzata da un proprio identificatore che viene chiamato CLSID (Class Identifier)
Un esempio reale
Disponendo di un CLSID, unapplicazione pu chiedere alla funzione di sistema CoCreateInstance di creare un istanza del componente e di restituire un riferimento nel spazio di indirizzamento dellapplicazione stessa Il database di sistema di Windows (registry) mantiene una corrispondenza tra CLSID ed entit fisiche (DLL, EXE) che contengono limplementazione dei componenti (server)
46
Un esempio reale
CoCreateInstance provvede a reperire il server tramite il registry caricarlo in memoria (se non gi presente) creare unistanza e restituirne un riferimento
47
Un esempio reale
In .NET esiste la classe System.Guid che permette di gestire istanze di GUID Ad esempio, per ottenere un nuovo GUID, sufficiente invocare il metodo statico Guid.NewGuid() che, ovviamente, restituisce un System.Guid Altri metodi e operatori permettono di confrontare GUID
48
Controllo della visibilit

I tipi di accessi a un membro di una classe (attributo o metodo) possono essere di tre tipi: public, ovvero visibili dallesterno (+) private, ovvero non visibili dallesterno (-) protected, ovvero visibili allesterno solo dalle sottoclassi (#) anche possibile rendere un membro di una classe o una intera classe visibile solo allinterno del package che contiene la classe (visibilit di package, internal in .NET) Infine, dichiarando una classe A friend di una classe B, ai metodi della classe A concessa la visibilit completa di tutti i membri della classe B (C++)
49
Controllo della visibilit

Regole Dichiarare private (o protected) tutti gli attributi membro Dichiarare public solo i metodi (le operazioni) che devono essere visibili allesterno Dichiarare private o protected tutti gli altri metodi Non abusare della dichiarazione friend (C++)
50
Interfaccia vs Classe astratta

Spesso, molte classi concettualmente eterogenee presentano un insieme di operazioni simili in alcuni casi, un insieme di attributi simili es. gestione della persistenza In questi casi, conveniente definire e realizzare un protocollo comune a tali classi definire uninterfaccia o una classe di generalizzazione comune dalla quale derivano tutte le suddette classi

Uninterfaccia
Non pu essere istanziata Non contiene alcuna implementazione le classi derivate devono realizzare tutte le funzionalit Non pu contenere uno stato Non pu contenere attributi e metodi (e propriet ed eventi) statici (a parte eventuali costanti comuni)
52

Una classe astratta
Non pu essere istanziata Pu essere implementata completamente, parzialmente o per niente le classi derivate: devono realizzare le funzionalit non implementate possono fornire una realizzazione alternativa a quelle implementate Pu contenere uno stato (comune a tutte le sottoclassi) Pu contenere attributi e metodi (e propriet ed eventi) statici

Uninterfaccia pu ereditare
Da 0+ interfacce
Una classe astratta pu ereditare

Da 0+ interfacce Da 0+ classi (astratte e/o concrete)
minimo 1 classe, nel caso esista una classe radice di sistema (ad es., System.Object) massimo 1 classe, nel caso in cui non sia ammessa lereditariet multipla
54

Uninterfaccia
Deve descrivere una funzionalit semplice implementabile da oggetti eterogenei (cio appartenenti a classi non correlate tra di loro) ad esempio, una classe pu essere Clonabile (se implementa ICloneable), Vista come una lista (se implementa IList), Deve essere stabile se si aggiungesse un metodo a uninterfaccia gi in uso, tutte le classi che implementano quellinterfaccia dovrebbero essere modificate

Una classe astratta
Pu descrivere una funzionalit anche complessa comune a un insieme di oggetti omogenei (cio appartenenti a classi strettamente correlate tra di loro) - ad esempio, System.Enum fornisce le funzionalit di base di tutti i tipi enumerativi Pu fornire unimplementazione di default semplificando la programmazione delle sottoclassi Pu essere modificata quando si aggiunge un metodo a una classe astratta gi in uso, possibile fornire unimplementazione di default, in modo tale da non dover modificare le sottoclassi

Uninterfaccia
Non pu gestire la creazione delle istanze delle classi che la implementano La creazione deve essere effettuata dai costruttori delle suddette classi da (unistanza di) una classe non correlata, la cui unica funzionalit la creazione di istanze di altre classi (classe factory)
57

Una classe astratta
Pu gestire la creazione delle istanze delle sue sottoclassi La creazione pu essere effettuata come per linterfaccia, ma anche da un metodo statico della classe astratta (metodo factory)
58
Modifiche per utilizzare il livello di ereditariet supportato

Se esistono strutture con ereditariet multipla Se il linguaggio di programmazione non ammette lereditariet multipla
necessario convertire le strutture con ereditariet multipla in strutture con solo ereditariet semplice
59

Animale nome peso
Mammifero temperatura nrCuccioli
AnimaleAcquatico velocitaInAcqua profonditaMax
Delfino
Ereditariet multipla e ripetuta
60

1a possibilit Scegliere la pi significativa tra le superclassi ed ereditare esclusivamente da questa Tutte le altre superclassi diventano possibili ruoli e vengono connesse con relazioni di contenimento In questo modo, le caratteristiche delle superclassi escluse vengono incorporate nella classe specializzata tramite contenimento e non tramite ereditariet
61

Animale nome peso
Delfino
0,1 1
EssereAcquatico velocitaInAcqua profonditaMax
Ereditariet multipla che diventa associazione
62

2a possibilit Appiattire tutto in una gerarchia semplice In questo modo, una o pi relazioni di ereditariet si perdono e gli attributi e le operazioni corrispondenti devono essere ripetuti nelle classi specializzate
63

Animale nome peso
Delfino velocitaInAcqua profonditaMax
Ereditariet multipla appiattita duplicando attributi e operazioni
64
Miglioramento delle prestazioni

Il software con le prestazioni migliori fa la cosa giusta abbastanza velocemente (cio, soddisfacendo i requisiti e/o le attese del cliente) pur rimanendo entro costi e tempi preventivati Per migliorare la velocit percepita pu bastare la memorizzazione di risultati intermedi unaccurata progettazione dellinterazione con lutente (ad es. utilizzando multi-threading) Un traffico di messaggi molto elevato tra oggetti pu invece richiedere dei cambiamenti per aumentare la velocit
Miglioramento delle prestazioni

Di norma, la soluzione che un oggetto possa accedere direttamente ai valori di un altro oggetto (aggirando lincapsulamento!)
Utilizzare metodi inline Utilizzare la dichiarazione friend Combinare insieme due o pi classi
Questo tipo di modifica deve essere presa in considerazione solo dopo che tutti gli altri aspetti del progetto sono stati soggetti a misure e modifiche
Lunico modo per sapere se una modifica contribuir in modo significativo a rendere il software abbastanza veloce tramite le misure e losservazione
Design Principles
Design quality
Design quality is an elusive concept Quality depends on specific organisational priorities A good design may be
the most reliable, the most efficient, the most maintainable, the cheapest,
The attributes discussed here are concerned with the maintainability of the design
Ingegneria del Software T - Design Principles
What Makes a Design Bad?

Misdirection: fails to meet requirements Software Rigidity: a single change affects many other parts
of the system
Software Fragility: a single change affects unexpected parts

of the system
Software Immobility: it is hard to reuse in another

application
Viscosity: it is hard to do the right thing, but easy to do the

wrong thing
Software Rigidity
The tendency for software to be difficult to change Symptom: every change causes a cascade of subsequent changes in dependent modules Effect: managers fear to allow developers to fix non-critical problems they dont know when the developers will be finished
Software Fragility
The tendency of the software to break in many places every time it is changed changes tend to cause unexpected behavior in other parts of the system (often in areas that have no conceptual relationship with the area that was changed) Symptom: every fix makes it worse, introducing more problems than are solved such software is impossible to maintain Effect: every time managers authorize a fix, they fear that the software will break in some unexpected way
Software Immobility
The inability to reuse software from other projects or from parts of the same project Symptom: a developer discovers that he needs a module that is similar to one that another developer wrote. But the module in question has too much baggage that it depends upon. After much work, the developer discovers that the work and risk required to separate the desirable parts of the software from the undesirable parts are too great to tolerate Effect: and so the software is simply rewritten instead of reused
Viscosity
Developers usually find more than one way to make a change: some preserve the design, others do not (i.e. they are hacks) The tendency to encourage software changes that are hacks rather than software changes that preserve original design intent Viscosity of design: the design preserving methods are harder to employ than the hacks Viscosity of environment: the development environment is slow and inefficient (compile times are very long, source code control system requires hours to check in just a few files, ) Symptom: it is easy to do the wrong thing, but hard to do the right thing Effect: the software maintainability degenerates due to hacks, workarounds, shortcuts, temporary fixes,
7 Ingegneria del Software T - Design Principles
Why bad design results?

Obvious reasons:
lack of design skills/design practices changing technologies time/resource constraints domain complexity,
Not so obvious:
software rotting is a slow process even originally clean and elegant design may degenerate over the months/years requirements often change in the way the original design or designer did not anticipate unplanned and improper module dependencies creep in dependencies go unmanaged
Requirement Changes
We, as software engineers, know full well that requirements change Indeed, most of us realize that the requirements document is the most volatile document in the project If our designs are failing due to the constant rain of changing requirements, it is our designs that are at fault We must somehow find a way to make our designs resilient to such changes and protect them from rotting
Dependency Management
Each of the four symptoms mentioned above is either directly, or indirectly caused by improper dependencies between the modules of the software It is the dependency architecture that is degrading, and with it the ability of the software to be maintained In order to forestall the degradation of the dependency architecture, the dependencies between modules in an application must be managed Object Oriented Design is replete with principles and techniques for managing module dependencies
10
Design Principles
The Single Responsibility Principle (SRP) The Open/Closed Principle (OCP) The Dependency Inversion Principle (DIP) The Liskov Substitution Principle (LSP) The Interface Segregation Principle (ISP)
11
Premessa
Il principio zero
Il principio zero un principio di logica noto come rasoio di Occam: Entia non sunt multiplicanda praeter necessitatem ovvero: non bisogna introdurre concetti che non siano strettamente necessari la forma colta di un principio pratico: Quello che non c non si rompe (H. Ford) Tra due soluzioni bisogna preferire quella che introduce il minor numero di ipotesi e che fa uso del minor numero di concetti
12
Premessa
Semplicit e semplicismo
La semplicit un fattore importantissimo il software deve fare i conti con una notevole componente di complessit, generata dal contesto in cui deve essere utilizzato quindi estremamente importante non aggiungere altra complessit arbitraria Il problema che la semplicit richiede uno sforzo non indifferente ( molto pi facile essere complicati che semplici) in generale le soluzioni pi semplici vengono in mente per ultime Bisogna fare poi molta attenzione ad essere semplici ma non semplicistici Keep it as simple as possible but not simpler (A. Einstein)
13
Premessa
Divide et impera
La decomposizione una tecnica fondamentale per il controllo e la gestione della complessit Non esiste un solo modo per decomporre il sistema la qualit della progettazione dipende direttamente dalla qualit delle scelte di decomposizione adottate In questo contesto il principio fondamentale : minimizzare il grado di accoppiamento tra i moduli del sistema Da questo principio possibile ricavare diverse regole: minimizzare la quantit di interazione fra i moduli eliminare tutti i riferimenti circolari fra moduli
The Single Responsibility Principle

There should never be more than one reason for a class to change (R. Martin) A class has a single responsibility: it does it all, does it well, and does it only (One Responsibility Rule B. Meyer) If a class has more then one responsibility, then the responsibilities become coupled Changes to one responsibility may impair or inhibit the class ability to meet the others This kind of coupling leads to fragile designs that break in unexpected ways when changed
15
Example
One application does computational geometry

it uses Rectangle to help it with the mathematics of geometric shapes it never draws the rectangle on the screen
The other application is graphical in nature

it may also do some computational geometry, but it definitely draws the rectangle on the screen
Example
The Rectangle class has two responsibilities

the first responsibility is to provide a mathematical model of the geometry of a rectangle the second responsibility is to render the rectangle on a graphical user interface
17
Example Refactoring
A better design is to separate the two responsibilities into two completely different classes
Extract Class: create a new class and move the relevant fields and methods from the old class into the new class
+ draw()
18

Class should have only one reason to change Several responsibilities mean several reasons for changes more frequent changes The SRP is one of the simplest of the principle, and one of the hardest to get right
Conjoining responsibilities is something that we do naturally Finding and separating those responsibilities from one another is much of what software design is really about
19
The Open/Closed Principle

The most important principle for designing reusable entities
Software entities (classes, modules, functions, ) should be open for extension, but closed for modification
Open:
May be extended by adding new state or behavioral properties
Closed:
Has a well-defined, published and stable interface which may not be changed
20

We should write our modules so that
they can be extended, without requiring them to be modified
In other words, we want to be able

to change what the modules do, without changing the source code of the modules Apparentemente si tratta di una contraddizione: come pu un modulo immutabile esibire un comportamento che non sia fisso nel tempo? La risposta risiede nellastrazione: possibile creare astrazioni che rendono un modulo immutabile, ma rappresentano un gruppo illimitato di comportamenti
21

Il segreto sta nellutilizzo di interfacce (o di classi astratte) A uninterfaccia immutabile possono corrispondere innumerevoli classi concrete che realizzano comportamenti diversi Un modulo che utilizza astrazioni
non dovr mai essere modificato, dal momento che le astrazioni sono immutabili (il modulo chiuso per le modifiche) potr cambiare comportamento, se si utilizzano nuove classi che implementano le astrazioni (il modulo aperto per le estensioni)
22
Esempio 1
Supponiamo di dover utilizzare un nuovo tipo di server!
23
Esempio 1
Client is closed to changes in implementation of IServer Client is open for extension through new IServer implementations Without IServer the Client is open to changes in Server
Esempio 1
25
Esempio 2
ShapeData
shap eType : int
SquareDat a CircleData radius : float center : Point

origin : Point length : float width : float
public void drawShape(ShapeData shapeData) { switch (shapeData.shapeType) { ca se SQUARE: drawSquare((SquareData)shapeData); break; ca se CIRC LE: drawCircle((CircleData)shapeData); break; } }
ShapeManipulator
dra wSh ape(s hapeData : ShapeData) dra wC ircle(circle : Circl eData) dra wSq uare(square : SquareData )
26
Esempio 2
If I need to create a new shape, such as a Triangle, I must modify drawShape In a complex application the switch/case statement above is repeated over and over again for every kind of operation that can be performed on a shape Worse, every module that contains such a switch/case statement retains a dependency upon every possible shape that can be drawn, thus, whenever one of the shapes is modified in any way, the modules all need recompilation, and possibly modification
27
Esempio 2
SmartShapeManipulator
drawShap e(shape : Sha peInterface)
<<Interface>> ShapeInterface draw() move()
public void drawS hape(ShapeInterface s hape) { shape.draw (); }
Circle draw() move()
Square draw() move()
28

When the majority of modules in an application conform to the OCP, then
new features can be added to the application by adding new code rather than by changing working code the working code is not exposed to breakage
Even if the OCP cannot be fully achieved, even partial OCP compliance can make dramatic improvements in the structure of an application
29

1. Consider all potential usage of a module 2. Document the public interface Distribute widely and allow time for debate 3. Minimize public behavior Carefully limit visible behavior to minimize future change (behavior changes the interface!) 4. Never change the published interface Fixes or enhancements must not effect existing users
30
The Open/Closed Principle Define a Stable Interface

Clearly define and document:
Public Behavior
The expected service to be performed, as experienced by any client code which uses it Do not include private (localized) behavior
Preconditions
The properties that must be true prior to any attempt to use a particular service
Postconditions
The properties that are guaranteed to exist after the service is performed, if it operates without error
31
The Open/Closed Principle Make all object data private

Changes to public data are always at great risk to open the module:
They may have a rippling effect requiring changes at many unexpected locations Errors can be difficult to completely find and fix fixes may cause errors elsewhere
Module A As data
Module A
Module B
Module B Module C Cs data
Module C
Module D
Bs data
Shared data area
Module D Ds data
32
The Dependency Inversion Principle

Depend upon abstractions Do not depend upon concretions High level modules should not depend on low level modules Both should depend on abstractions Abstractions should not depend on details Details should depend on abstractions DIP is the strategy of depending upon interfaces or abstract functions and classes, rather than upon concrete functions and classes Every dependency should target an interface, or an abstract class No dependency should target a concrete class
33

I moduli di basso livello contengono la maggior parte del codice e della logica implementativa e quindi sono i pi soggetti a cambiamenti Se i moduli di alto livello dipendono dai dettagli dei moduli di basso livello (sono accoppiati in modo troppo stretto), i cambiamenti si propagano e le conseguenze sono:
Rigidit: bisogna intervenire su un numero elevato di moduli Fragilit: si introducono errori in altre parti del sistema Immobilit: i moduli di alto livello non si possono riutilizzare perch non si riescono a separare da quelli di basso livello
34

Il principio di inversione delle dipendenze cerca di porre rimedio a questi problemi La sua formulazione pi comune :
i moduli di alto livello non dovrebbero dipendere dai dettagli dei moduli di basso livello entrambi dovrebbero dipendere da astrazioni le astrazioni non dovrebbero dipendere dai dettagli i dettagli dovrebbero dipendere dalle astrazioni
35

Vediamo perch questo principio funziona:
le astrazioni contengono pochissimo codice (in teoria nulla) e quindi sono poco soggette a cambiamenti i moduli non astratti sono soggetti a cambiamenti ma questi cambiamenti sono sicuri perch nessuno dipende da questi moduli
In sostanza abbiamo invertito la direzione della dipendenza fra i moduli:

prima i moduli meno dettagliati (alto livello) dipendevano da moduli pi dettagliati (basso livello), ora moduli pi dettagliati (concreti) dipendono da moduli meno dettagliati (astratti)
36

Dependency Structure of a Procedural Architecture
main
HighLevelFn1
HighLevelFn2
HighLevelFn3
LowLevelFn1
LowLevelFn2
LowLevelFn3
LowLevelFn4
37

Dependency Structure of an OO Architecture
HighLevel
<<Interface>> Abs tractInterface1
<<Interface>> AbstractInt erface2
<<Int erface>> AbstractInt erface3
DetailImpl1
DetailImpl2
DetailImpl3
38

I dettagli del sistema sono stati isolati fra di loro, separati da un muro di astrazioni stabili, e questo impedisce ai cambiamenti di propagarsi (design for change) Nel contempo i singoli moduli sono maggiormente riusabili perch sono disaccoppiati fra di loro (design for reuse)
39
Esempio 1
Consider a simple program that is charged with the task of copying characters typed on a keyboard to a printer Assume, furthermore, that the implementation platform does not have an operating system that supports device independence
void Copy() { int c; while ((c = ReadKeyboard()) != EOF) WritePrinter(c); }
40
Esempio 1
The two low level modules are reusable: they can be used in many other programs to gain access to the keyboard and the printer this is the same kind of reusability that we gain from subroutine libraries The Copy module is not reusable in any context which does not involve a keyboard or a printer This is a shame since the intelligence of the system is maintained in this module it is the Copy module that encapsulates a very interesting policy that we would like to reuse
void Copy() { int c; while ((c = ReadKeyboard()) != EOF) WritePrinter(c); }
Esempio 1
Consider a new program that copies keyboard characters to a disk file We could modify the Copy module to give it the new desired functionality As time goes on, and more and more devices must participate in the copy program, the Copy module will be littered with if/else statements and will be dependent upon many lower level modules it will eventually become rigid and fragile
enum OutputDevice { Printer, Disk }; void Copy(OutputDevice dev) { int c; while ((c = ReadKeyboard()) != EOF) { if (dev == Printer) WritePrinter(c); else WriteDisk(c); } }
42
Esempio 1
One way to characterize the problem above is to notice that the module containing the high level policy (Copy) is dependent upon the low level detailed modules that it controls (WritePrinter and ReadKeyboard) If we could find a way to make the Copy module independent of the details that it controls, then
we could reuse it freely we could produce other programs which used this module to copy characters from any input device to any output device
43
Esempio 1
interface Reader { int Read(); } interface Writer { void Write(char); } void Copy(Reader r, Writer w) { int c; while ((c = r.Read()) != EOF) w.Write(c); }
44
Esempio 2
E se volessimo accendere un motore?
45
Esempio 2
46
Dipendenze transitive
...all well structured object-oriented architectures have clearly-defined layers, with each layer providing some coherent set of services though a well-defined and controlled interface (Grady Booch) I sistemi software dovrebbero essere stratificati, cio organizzati a livelli Le dipendenze transitive devono essere eliminate
Policy Layer
Depends on
Mechanism Layer
Depends on
Utility Layer
47
Dipendenze transitive
Policy Layer
Depends on
Mechanism Interface Mechanism Layer

Depends on
Utility Interface
Utility Layer
48
The Liskov Substitution Principle

Subclasses should be substitutable for their base classes (Barbara Liskov) All derived classes must honor the contracts of their base classes (Design by Contract Bertrand Meyer)
A client of a base class should continue to function properly if a derivative of that base class is passed to it In altre parole: un cliente che usa istanze di una classe A deve poter usare istanze di una qualsiasi sottoclasse di A senza accorgersi della differenza
49
Example
Policy
getUnitsOfRisk() getPolicyCoverages() getRateSteps()
PolicyRateModule
HomeOwnerPolicy
Aut oP olicy
This module should not break regardless of whether a Personal Auto or Commercial Auto or Home Owner Policy is passed to it
PersonalAutoPolicy
CommercialAutoPolicy
50
Example
51

OCP si basa sulluso di classi concrete derivate da un astrazione (interfaccia o classe astratta) LSP costituisce una guida per creare queste classi concrete mediante lereditariet La principale causa di violazioni al principio di Liskov dato dalla ridefinizione di metodi virtuali nelle classi derivate: qui che bisogna riporre la massima attenzione La chiave per evitare le violazioni al principio di Liskov risiede nel Design by Contract (B. Meyer)
52
Design by Contract
Nel Design by Contract ogni metodo ha un insieme di pre-condizioni requisiti minimi che devono essere soddisfatti dal chiamante perch il metodo possa essere eseguito correttamente un insieme di post-condizioni requisiti che devono essere soddisfatti dal metodo nel caso di esecuzione corretta Questi due insiemi di condizioni costituiscono un contratto tra chi invoca il metodo (cliente) e il metodo stesso (e quindi la classe a cui appartiene) Le pre-condizioni vincolano il chiamante Le post-condizioni vincolano il metodo Se il chiamante garantisce il verificarsi delle pre-condizioni, il metodo garantisce il verificarsi delle post-condizioni
53
Design by Contract
Quando un metodo viene ridefinito in una sottoclasse le pre-condizioni devono essere identiche o meno stringenti le post-condizioni devono essere identiche o pi stringenti Questo perch un cliente che invoca il metodo conosce il contratto definito a livello della classe base, quindi non in grado: di soddisfare pre-condizioni pi stringenti o di accettare post-condizioni meno stringenti In caso contrario, il cliente dovrebbe conoscere informazioni sulla classe derivata e questo porterebbe a una violazione del principio di Liskov
54
Design by Contract
public class BaseClass { public virtual int Calculate(int val) { Precondition(-10000 <= val && val <= 10000); int result = val / 100; Postcondition(-100 <= result && result <= 100); return result; } } public class SubClass : BaseClass { public override int Calculate(int val) { Precondition(-20000 <= val && val <= 20000); int result = Math.Abs(val) / 200; Postcondition(0 <= result && result <= 100); return result; } }
55
Il Quadrato un Rettangolo?
public class Rectangle { private double _width; private double _height; public double Width { get { return _width; } set { _width = value; } } public double Height { get { return _height; } set { _height = value; } } public double Area { get { return Width * Height; } } }
Imagine that this application works well, and is installed in many sites As is the case with all successful software, as its users needs change, new functions are needed Imagine that one day the users demand the ability to manipulate squares in addition to rectangles
56
Inheritance is the IsA relationship In other words, if a new kind of object can be said to fulfill the IsA relationship with an old kind of object, then the class of the new object should be derived from the class of the old object Clearly, a square is a rectangle for all normal intents and purposes Since the IsA relationship holds, it is logical to model the Square class as being derived from Rectangle
57
This use of the IsA relationship is considered by many to be one of the fundamental techniques of Object Oriented Analysis A square is a rectangle, and so the Square class should be derived from the Rectangle class However this kind of thinking can lead to some subtle, yet significant, problems Generally these problem are not foreseen until we actually try to code the application
58
public class Square : Rectangle { public new double Width { get { return base.Width; } set { base.Width = value; base.Height = value; } } public new double Height { get { return base.Height; } set { base.Height = value; base.Width = value; } } }
necessario ridefinire le propriet Width e Height Notevoli differenze tra Java e C++ / C# In Java tutti i metodi sono virtuali In C++ / C# possibile definire
sia metodi virtuali, sia metodi non virtuali (non polimorfici)
59
Square s = new Square(); s.Width = 5; // 5 x 5 Method1(s); // ? void Method1(Rectangle r) { r.Width = 10; }
If we pass a reference to a Square object into Method1, the Square object will be corrupted because the height wont be changed (!) This is a clear violation of LSP Method1 does not work for derivatives of its arguments The reason for the failure is that Width and Height were not declared virtual in Rectangle
60
public class Rectangle { public virtual double Width { } public virtual double Height { } }
public class Square : Rectangle { public override double Width { } public override double Height { } }
We can fix this easily However, when the creation of a derived class causes us to make changes to the base class, it often implies that the design is faulty Indeed, it violates the OCP We might counter this with argument that forgetting to make Width and Height virtual was the real design flaw, and we are just fixing it now However, this is hard to justify since setting the height and width of a rectangle are exceedingly primitive operations by what reasoning would we make them virtual if we did not anticipate the existence of square
61
At this point in time we have two classes, Square and Rectangle, that appear to work No matter what you do to a Square object, it will remain consistent with a mathematical square And regardless of what you do to a Rectangle object, it will remain a mathematical rectangle Moreover, you can pass a Square into a function that accepts a reference to a Rectangle, and the Square will still act like a square and will remain consistent Thus, we might conclude that the model is now self consistent, and correct However, a model that is self consistent is not necessarily consistent with all its users!
62
public void Scale(Rectangle rectangle) { rectangle.Width = rectangle.Width * ScalingFactor; rectangle.Height = rectangle.Height * ScalingFactor; }
Scale invokes members of what it believes to be a Rectangle Substituing a Square into this will result in the square being scaled twice! So here is the real problem: was the programmer who wrote Scale justified in assuming that changing the width of a Rectangle leaves its height unchanged?
63
Clearly, the programmer of Scale made this very reasonable assumption Passing a Square to functions whose programmers made this assumption will result in problems Therefore, there exist functions that take references to Rectangle objects, but cannot operate properly upon Square objects These functions expose a violation of the LSP The addition of the Square derivative of Rectangle has broken these function the OCP has been violated
64
Why did the model of the Square and Rectangle go bad After all, isnt a Square a Rectangle? Doesnt the IsA relationship hold? No! A square might be a rectangle, but a Square object is definitely not a Rectangle object Why? Because the behavior of a Square object is not consistent with the behavior of a Rectangle object Behaviorally, a Square is not a Rectangle! And it is behavior that software is really all about
65
The LSP makes clear that in OOD the IsA relationship pertains to behavior. Not intrinsic private behavior, but extrinsic public behavior; behavior that clients depend upon For example, the author of Scale depended on the fact that rectangles behave such that their height and width vary independently of one another. That independence of the two variables is an extrinsic public behavior that other programmers are likely to depend upon In order for the LSP to hold, and with it the OCP, all derivatives must conform to the behavior that clients expect of the base classes that they use
66
The rule for the preconditions and postconditions for derivatives, is: when redefining a routine, you may only replace its precondition by a weaker one, and its postcondition by a stronger one In other words, when using an object through its base class interface, the user knows only the preconditions and postconditions of the base class Thus, derived classes must not expect such users to obey preconditions that are stronger then those required by the base class they must accept anything that the base class could accept Also, derived classes must conform to all the postconditions of the base class their behaviors and outputs must not violate any of the constraints established for the base class
67
The contract of Rectangle height and width are independent, can set one while the other remains unchanged Square violates the contract of the base class
68
If we look at the test fixture for our Rectangle we get some idea of the contract for a Rectangle:
[TestFixture] public class RectangleFixture { [Test] public void SetHeightAndWidth() { Rectangle rectangle = new Rectangle(); int expectedWidth = 3, expectedHeight = 7; rectangle.Width = expectedWidth; rectangle.Height = expectedHeight; Assertion.AssertEquals(expectedWidth, rectangle.Width); Assertion.AssertEquals(expectedHeight, rectangle.Height); } }
69
[TestFixture] public class RectangleFixture { [Test] public void SetHeightAndWidth() { Rectangle rectangle = GetShape(); ... } protected virtual Rectangle GetShape() { return new Rectangle(); } } [TestFixture] public class SquareFixture : RectangleFixture { protected override Rectangle GetShape() { return new Square(); } }
70
The Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use Many client specific interfaces are better than one general purpose interface If you have a class that has several clients, rather than loading the class with all the methods that the clients need, create specific interfaces for each type of client and multiply inherit them into the class
71
The Interface Segregation Principle Fat Service with Integrated Interfaces

ClientA
<<Interface>> Service ClientB

clientAMethods() clientBMethods() clientCMethods()
ClientC
72
The Interface Segregation Principle Segregated Interfaces

ClientA <<Interface>> ClientAService
clientAMethods()
ClientB
<<Interface>> ClientBService
clientBMethods()
ServiceImpl
clientAMethods() clientBMethods() clientCMethods()
ClientC
<<Interface>> ClientCService
clientCMethods()
73

Without segregation whenever a change is made to one of the methods that ClientA calls, ClientB and ClientC may be affected: it may be necessary to recompile and redeploy them With segregation if the interface for ClientA needs to change, ClientB and ClientC will remain unaffected The ISP does not recommend that every class that uses a service have its own special interface class that the service must inherit from. Rather, clients should be categorized by their type, and interfaces for each type of client should be created. If two or more different client types need the same method, the method should be added to both of their interfaces
74

Le fat interfaces derivano da classi i cui metodi possono essere suddivisi in gruppi in cui ogni gruppo viene utilizzato da un diverso insieme di client ISP suggerisce che i client non dovrebbero vedere i gruppi di metodi come una singola classe ovvero i client non dovrebbero dipendere da interfacce che non utilizzano Se non si rispetta ISP si crea una forma indiretta di accoppiamento (inutile) fra i client per mezzo della fat interface Se un client richiede laggiunta di una nuova funzionalit allinterfaccia ogni altro client costretto a cambiare anche se non interessato alla nuova funzionalit Questo crea uninutile sforzo di manutenzione e pu rendere difficile trovare eventuali errori
75
Principles of Package Architecture

The Reuse/Release Equivalency Principle (REP) The Common Closure Principle (CCP) The Common Reuse Principle (CRP)
76
The Release/Reuse Equivalency Principle

The granule of reuse is the granule of release A reusable element, be it a component, a class, or a cluster of classes, cannot be reused unless it is managed by a release system of some kind Clients will/should refuse to reuse an element unless the author promises to keep track of version numbers, and maintain old versions for awhile one criterion for grouping classes into packages is reuse Since packages are the unit of release in JAVA, they are also the unit of reuse. Therefore architects would do well to group reusable classes together into packages
77
The Common Closure Principle

Classes that change together, belong together The work to manage, test, and release a package is non-trivial in a large system. The more packages that change in any given release, the greater the work to rebuild, test, and deploy the release we would like to minimize the number of packages that are changed in any given release cycle of the product To achieve this, we group together classes that we think will change together
78
The Common Reuse Principle

Classes that arent reused together should not be grouped together A dependency upon a package is a dependency upon everything within the package. When a package changes, and its release number is bumped, all clients of that package must verify that they work with the new package - even if nothing they used within the package actually changed Hence, classes that arent reused together should not be grouped together in a package
79
Principles of Package Architecture
Discussion
These three cannot simultaneously be satisfied The REP and CRP makes life easy for re-users, whereas the CCP makes life easier for maintainers The CCP strives to make packages as large as possible (after all, if all the classes live in just one package, then only one package will ever change). The CRP, however, tries to make packages very small Early in a project, architects may set up the package structure such that CCP dominates for ease of development and maintenance. Later, as the architecture stabilizes, the architects may re-factor the package structure to maximize REP and CRP for the external re-users
80
Relationships between Packages

The Acyclic Dependencies Principle (ADP) The Stable Dependencies Principle (SDP) The Stable Abstractions Principle (SAP)
81
The Acyclic Dependencies Principle

The dependencies between packages must not form cycles Once changes to a package are made, developers can release the packages to the rest of the project. Before they can do this release, however, they must test that the package works. To do that, they must compile and build it with all the packages it depends upon A single cyclic dependency that gets out of control can make the dependency list very long Hence, someone needs to be watching the package dependency structure with regularity, and breaking cycles wherever they appear
82
Example: Acyclic Package Network

gui
comm
process
modem
protocol
file
comm_error
83
Example: Cyclic Package Network

gui
comm
process
modem
protocol
file
comm_error
84
Discussion
In the acyclic scenario to release the protocol package, the engineers would have to build it with the latest release of the comm_error package, and run their tests In the cyclic scenario to release the protocol package, the engineers would have to build it with the latest release of the comm_error, gui, comm, process, modem, file and run their tests Breaking the cycle:
Add new package in between Add a new Interface
85
The Acyclic Dependencies Principle Breaking Cycle by introducing an Interface
implements
BInterface
86
The Stable Abstractions Principle

Stable packages should be abstract packages Stability is related to the amount of work required to make a change A package with lots of incoming dependencies is very stable because it requires a great deal of work to reconcile any changes with all the dependent packages
87
Example
A B C
X is a stable package; hence it should be abstract
88
Discussion
The packages at the top are instable and flexible The packages at the bottom are very difficult to change The highly stable packages at the bottom of the dependency network may be very difficult to change, but according to the OCP they do not have to be difficult to extend. If the stable packages at the bottom are also highly abstract, then they can be easily extended It is possible to compose our application from instable packages that are easy to change, and stable packages that are easy to extend
89
Design Pattern
Design Pattern
Nel 1977, Christopher Alexander disse: "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to that problem, in such a way that you can use the solution a million times over, without ever doing it the same way twice" Parlava di costruzioni civili e di citt
2 Ingegneria del Software T - Design Pattern
Design Pattern
La stessa frase applicabile anche alla progettazione object-oriented In questo caso, le soluzioni utilizzeranno
oggetti, classi e interfacce invece che pareti e porte
Ingegneria del Software T - Design Pattern
Design Pattern
Obiettivi Risolvere problemi progettuali specifici Rendere i progetti object-oriented pi flessibili e riutilizzabili Ogni design pattern Cattura e formalizza lesperienza acquisita nellaffrontare e risolvere uno specifico problema progettuale Permette di riutilizzare tale esperienza in altri casi simili
Design Pattern
Ogni design pattern ha quattro elementi essenziali un nome (significativo) identifica il pattern il problema descrive quando applicare il pattern la soluzione descrive il pattern, cio gli elementi che lo compongono (classi e istanze) e le loro relazioni, responsabilit e collaborazioni le conseguenze descrivono vantaggi e svantaggi dellapplicazione del pattern Permettono di valutare le alternative progettuali
Classificazione dei Design Pattern

Pattern di creazione (creational pattern) Risolvono problemi inerenti il processo di creazione di oggetti Pattern strutturali (structural pattern) Risolvono problemi inerenti la composizione di classi o di oggetti Pattern comportamentali (behavioral pattern) Risolvono problemi inerenti le modalit di interazione e di distribuzione delle responsabilit tra classi o tra oggetti
Classificazione dei Design Pattern

Pattern di creazione
Abstract Factory Builder Factory Method Prototype Singleton
Pattern strutturali
Adapter Bridge Composite Decorator Facade Flyweight Proxy
Pattern comportamentali
Chain of Responsability Command Interpreter Iterator Mediator Memento Observer State Strategy Template Method Visitor
Pattern SINGLETON
Assicura che una classe abbia una sola istanza e fornisce un punto di accesso globale a tale istanza La classe deve:
tenere traccia della sua sola istanza intercettare tutte le richieste di creazione, al fine di garantire che nessuna altra istanza venga creata fornire un modo per accedere allistanza unica
Pattern SINGLETON
public class Singleton { attributi membro di istanza private static Singleton _instance = null; protected Singleton() { inizializzazione istanza } public static Singleton GetInstance() { if(_instance == null) _instance = new Singleton(); return _instance; } metodi pubblici, protetti e privati }
Pattern SINGLETON
Alternativa: classe non istanziabile con soli membri statici Perch un singleton?
Creo il singleton (e quindi lo inizializzo) solo la prima volta che mi serve Gli attributi membro di classe vengono inizializzati in un ordine non definito prima che il controllo passi al main (eccezione: costruttore statico in C#) Posso specializzare il singleton e creare nella GetInstance una istanza specializzata che dipende dal contesto corrente
10
Pattern SINGLETON
public static Singleton GetInstance() { if(_instance == null) _instance = CreateInstance(); return _instance; } private static { if() return new else if() return new else return new }
11
Singleton CreateInstance()
SubSingletonA(); SubSingletonB(); SubSingletonC();
Pattern FLYWEIGHT
Descrive come condividere oggetti leggeri (cio a granularit molto fine) in modo tale che il loro uso non sia troppo costoso Un flyweight un oggetto condiviso che pu essere utilizzato simultaneamente ed efficientemente da pi clienti (del tutto indipendenti tra loro) Bench condiviso, non deve essere distinguibile da un oggetto non condiviso Non deve fare ipotesi sul contesto nel quale opera
12
Pattern FLYWEIGHT
Distinzione tra stato intrinseco e stato estrinseco Stato intrinseco Non dipende dal contesto di utilizzo e quindi pu essere condiviso da tutti i clienti Memorizzato nel flyweight Stato estrinseco Dipende dal contesto di utilizzo e quindi non pu essere condiviso dai clienti Memorizzato nel cliente o calcolato dal cliente Viene passato al flyweight quando viene invocata una sua operazione
Pattern FLYWEIGHT
Per assicurare una corretta condivisione, i clienti non devono istanziare direttamente i flyweight ma devono ottenerli esclusivamente tramite una FlyweightFactory GetFlyweight(key) { if(flyweights[key] not exist) create flyweights[key] return flyweights[key] }
14
Pattern FLYWEIGHT
Gestisce lo stato estrinseco Dichiara uninterfaccia tramite la quale i flyweight possono ricevere dal cliente lo stato estrinseco e operare
Crea i flyweight Gestisce la condivisione dei flyweight
Implementa linterfaccia e memorizza lo stato intrinseco
15
Pattern FLYWEIGHT Esempio

Si supponga di usare il pattern flyweight per condividere delle icone tra vari clienti
16
Pattern FLYWEIGHT Esempio

Lo stato intrinseco (memorizzato nel flyweight) comprender tutte le informazioni che i clienti devono (e possono) condividere:
Nome dellicona Bitmap dellicona Dimensioni originali,
Lo stato estrinseco (memorizzato nel cliente) comprender il contesto in cui licona dovr essere disegnata (dipendente dal singolo cliente):
Posizione dellicona Dimensioni richieste,
Esempio
Pattern STRATEGY
Permette di
definire un insieme di algoritmi tra loro correlati, incapsulare tali algoritmi in una gerarchia di classi e rendere gli algoritmi intercambiabili
Client ClientInterface() * 1 interface Strategy Algorithm()
ConcreteStrategy1 ConcreteStrategy2 ConcreteStrategy3 Algorithm() Algorithm() Algorithm()
18
Pattern STRATEGY
Dichiara uninterfaccia comune a tutti gli algoritmi supportati
Client ClientInterface() * 1
interface Strategy Algorithm()
ConcreteStrategy1 ConcreteStrategy2 ConcreteStrategy3 Algorithm() Algorithm() Algorithm()
Referenzia loggetto che implementa un algoritmo Pu dichiarare uninterfaccia che permetta alloggetto Strategy di accedere ai dati del cliente
Implementa linterfaccia e fornisce limplementazione di un algoritmo
Pattern STRATEGY Esempio

Allineamento del testo di un paragrafo Esistono politiche diverse di allineamento
20
Pattern STRATEGY Esempio

AlignerBase
suddivide il testo in linee (Format) delega alle sue sottoclassi lallineamento delle singole linee (FormatLine)
Paragraph utilizza i servizi di un Aligner specificato dinamicamente run-time possibile realizzare gli Aligner utilizzando il pattern flyweight
Esempio
Pattern ADAPTER
Converte linterfaccia originale di una classe nellinterfaccia (diversa) che si aspetta il cliente Permette a classi che hanno interfacce incompatibili di lavorare insieme Si usa quando si vuole riutilizzare una classe esistente e la sua interfaccia non conforme a quella desiderata Noto anche come wrapper
22
Pattern ADAPTER
Utilizza loggetto tramite linterfaccia di Target
Target Client Operation()
Dichiara linterfaccia che il cliente vuole vedere
Adapter Operation()
adaptee 1
adaptee
Adaptee SpecificOperation()
adaptee.SpecificOperation()
Adatta linterfaccia di Adaptee allinterfaccia di Target
Definisce uninterfaccia proprietaria, diversa da quella che il cliente vuole vedere
23
Pattern ADAPTER
In C++, si potrebbe scrivere:
class Adapter : public Target, private Adaptee
Cio ereditare linterfaccia di Target e limplementazione di Adaptee In un linguaggio in cui non ammesso ereditare limplementazione, conviene utilizzare la composizione
Esempio
Pattern DECORATOR
Permette di aggiungere responsabilit a un oggetto dinamicamente Fornisce unalternativa flessibile alla specializzazione
In alcuni casi, le estensioni possibili sono talmente tante che per poter supportare ogni possibile combinazione, si dovrebbe definire un numero troppo elevato di sottoclassi
25
Pattern DECORATOR
TextBox
BorderTextBox FilledTextBox VerticalTextBox BorderFilledTextBox BorderVerticalTextBox BorderFilledVerticalTextBox FilledVerticalTextBox
E se volessi
2 o pi bordi Cambiare il font
26
Pattern DECORATOR
Component Operation() 1
component
ConcreteComponent Operation()
Decorator Operation()
component * component.Operation()
ConcreteDecoratorA AddedState Operation()
ConcreteDecoratorB Operation() AddedBehaviour()
base.Operation() AddedBehaviour()
27
Pattern DECORATOR
Component (interfaccia o classe astratta)
Dichiara linterfaccia di tutti gli oggetti ai quali deve essere possibile aggiungere dinamicamente responsabilit
ConcreteComponent
Definisce un tipo di oggetto al quale deve essere possibile aggiungere dinamicamente responsabilit
Decorator (classe astratta)

Mantiene un riferimento a un oggetto di tipo Component e definisce uninterfaccia conforme allinterfaccia di Component
ConcreteDecorator
Aggiunge responsabilit al componente referenziato
Pattern DECORATOR
interface IComponent 1
component
component TextFrame Decorator *
BorderedFrame
FilledFrame
VerticalTextFrame
Bordered
Filled
Text
Bordered
Bordered
Esempio
29
Ereditariet dinamica
Una sotto-classe deve sempre essere una versione pi specializzata della sua super-classe (o classe base) Un buon test sul corretto utilizzo dellereditariet che sia valido il principio di sostituibilit di Liskov: B una sotto-classe di A se e solo se ogni programma che utilizzi oggetti di classe A pu utilizzare oggetti di classe B senza che il comportamento logico del programma cambi Perch ci sia valido, necessario che:
le pre-condizioni di tutti i metodi della sotto-classe siano uguali o pi deboli le post-condizioni di tutti i metodi della sotto-classe siano uguali o pi forti ogni metodo ridefinito nella sotto-classe deve mantenere la semantica del metodo originale
Rettangolo + property Altezza : double + property Larghezza : double - _altezza : double - _larghezza : double + get Altezza ( ) + set Altezza ( ) + get Larghezza ( ) + set Larghezza ( ) use ModificatoreDiDimensioni + Modifica ( )
Esempio S1
Un quadrato un rettangolo con la sola differenza che altezza e larghezza devono essere uguali Un quadrato ha un vincolo in pi rispetto al rettangolo
Quadrato + property Altezza : double + property Larghezza : double + property Lato : double + get Altezza ( ) + set Altezza ( ) + get Larghezza ( ) + set Larghezza ( ) + get Lato ( ) + set Lato ( )
In realt, una sotto-classe

Deve supportare tutto il comportamento della classe base ed eventualmente aggiungerne di nuovo (extends) Pu modificare alcuni aspetti del comportamento NON pu e non deve aggiungere vincoli comportamentali alla classe base!
31
Il metodo Modifica della classe ModificatoreDiDimensioni
funziona correttamente su un Rettangolo ma NON funziona correttamente su un Quadrato
Quindi non possibile passare unistanza di Quadrato dove prevista unistanza di Rettangolo (il principio di sostituzione di Liskov violato!) Conclusione: un quadrato NON un rettangolo perch pone dei nuovi vincoli al concetto di rettangolo Come possiamo tenere conto di ci che il rettangolo e il quadrato hanno in comune?
interface IParallelogramma + property Altezza : double + property Larghezza : double + get Altezza ( ) + set Altezza ( ) + get Larghezza ( ) + set Larghezza ( )
Esempio S2
Quadrato + property Altezza : double + property Larghezza : double + property Lato : double - _lato : double + get Altezza ( ) + set Altezza ( ) + get Larghezza ( ) + set Larghezza ( ) + get Lato ( ) + set Lato ( )
Rettangolo + property Altezza : double + property Larghezza : double - _altezza : double - _larghezza : double + get Altezza ( ) + set Altezza ( ) + get Larghezza ( ) + set Larghezza ( ) ModificatoreDiDimensioni use + Modifica ( )
33
Cosa intendiamo esattamente per Rettangolo e per Quadrato? Rettangolo: parallelogramma i cui angoli sono retti Parallelogramma: quadrilatero i cui lati opposti sono paralleli tra loro Quadrilatero: poligono avente quattro lati e quattro angoli
Quadrilateri notevoli sono il quadrato, il rettangolo, il parallelogramma, il rombo e il trapezio
Poligono: figura geometrica limitata da una linea poligonale chiusa Rombo: parallelogramma equilatero in cui gli angoli adiacenti sono diversi tra loro Quadrato: parallelogramma equilatero ed equiangolo
34
Cosa intendiamo esattamente per Rettangolo e per Quadrato nella nostra applicazione? Ipotesi: abbiamo a che fare esclusivamente con parallelogrammi
1. Lati e angoli NON sono modificabili
Definisco quattro classi concrete che derivano dalla classe astratta Parallelogramma (o implementano IParallelogramma): Rettangolo, Quadrato, Rombo, ParallelogrammaGenerico Uso una factory che in base ai valori dei lati e degli angoli mi istanzia un rettangolo (che NON deve avere i lati uguali), un quadrato, un rombo o un parallelogramma generico
35
2. Lati e angoli sono modificabili
Definisco ununica classe concreta Parallelogramma le cui istanze possono comportarsi a seconda del loro stato come: un rettangolo, un quadrato, un rombo, o un parallelogramma generico
36
Come pu un oggetto cambiare comportamento, al cambiare del suo stato? 1a possibilit: si cambia la classe delloggetto run-time nella maggior parte dei linguaggi di programmazione a oggetti, questo non possibile (inoltre, meglio che un oggetto non possa cambiare classe durante la sua esistenza la classe di un oggetto deve basarsi sulla sua essenza e non sul suo stato) 2a possibilit: si utilizza il pattern State che usa un meccanismo di delega, grazie al quale loggetto in grado di comportarsi come se avesse cambiato classe
37
Pattern STATE
Context + Operation ( ) - _state AbstractState 1 + Handle ( )
Operation() { _state.Handle(); } ConcreteStateA + Handle ( ) ConcreteStateB + Handle ( )
Localizza il comportamento specifico di uno stato e suddivide il comportamento in funzione dello stato Le classi concrete contengono la logica di transizione da uno stato allaltro Permette anche di emulare lereditariet multipla
38
Pattern STATE
ModificatoreDiDimensioni + Modifica ( ) use Parallelogramma + property Altezza : double + property Larghezza : double + property Nome : string + property Colore : Color - _altezza : double - _larghezza : double + Parallelogramma ( ) - StateChanged ( ) + get Altezza ( ) + set Altezza ( ) + get Larghezza ( ) + set Larghezza ( ) + get Nome ( ) + get Colore ( ) - _tipo
Tipo
+ property Nome : string + property Colore : Color + DeterminaTipo ( )
+ get Nome ( ) + get Colore ( )
TipoRettangolo + property Nome : string + property Colore : Color + get Nome ( ) + get Colore ( )
TipoQuadrato + property Nome : string + property Colore : Color + get Nome ( ) + get Colore ( )
Esempio S3
Pattern COMPOSITE
Permette di comporre oggetti in una struttura ad albero, al fine di rappresentare una gerarchia di oggetti contenitori-oggetti contenuti Permette ai clienti di trattare in modo uniforme oggetti singoli e oggetti composti
children
40
Pattern COMPOSITE
Component (classe astratta)
Dichiara linterfaccia Realizza il comportamento di default
Client
Accede e manipola gli oggetti della composizione attraverso linterfaccia di Component
children
41
Pattern COMPOSITE
Leaf
Descrive oggetti foglia cio senza figli Definisce il comportamento di tali oggetti
Composite
Descrive oggetti che hanno figli contenitori Definisce il comportamento di tali oggetti
children
42
Pattern COMPOSITE
* Component child children 0..1 *
Components parent Composite 0..1 1 1
Il contenitore dei figli deve essere un attributo di Composite e pu essere di qualsiasi tipo (array, lista, albero, tabella hash, )
43
Pattern COMPOSITE
Riferimento esplicito al genitore (parent)
Semplifica lattraversamento e la gestione della struttura Lattributo che contiene il riferimento al genitore e la relativa gestione devono essere posti nella classe Component Invariante Tutti gli elementi che hanno come parent lo stesso componente devono essere (gli unici) figli di quel componente incapsulare lassegnamento di parent nei metodi Add e Remove della classe Composite, oppure incapsulare le operazioni di Add e Remove nella set dellattributo parent della classe Component
44
Pattern COMPOSITE
public class Composite : Component { public void Add(Component aChild) { if(aChild.Parent != null) throw new ArgumentException(); _children.Add(aChild); aChild._parent = this; } }
45
Pattern COMPOSITE
public class Composite : Component { public void Remove(Component aChild) { if(aChild.Parent != this) throw new ArgumentException(); if(!_children.Contains(aChild)) throw new ArgumentException(); _children.Remove(aChild); aChild._parent = null; } }
46
Pattern COMPOSITE
public class Component { public Composite Parent { get { return _parent; } set { if(value != _parent) { if(_parent != null) _parent.Remove(this); if(value != null) value.Add(this); } } } }
Pattern COMPOSITE
Massimizzazione dell'interfaccia Component Un obiettivo del pattern Composite quello di fare in modo che il cliente veda solo linterfaccia di Component in Component devono essere inserite tutte le operazioni che devono essere utilizzate dai clienti - nella maggior parte dei casi, Component definisce una realizzazione di default che le sotto classi devono ridefinire Alcune di queste operazioni possono essere prive di significato per gli oggetti foglia (Add, Remove, )
Pattern COMPOSITE
Trasparenza
Dichiaro tutto al livello pi alto, in modo che il cliente possa trattare gli oggetti in modo uniforme ma il cliente potrebbe cercare di fare cose senza senso, come aggiungere figli alle foglie Se scegliamo la trasparenza
Add e Remove devono avere una realizzazione di default che genera uneccezione dovremmo disporre di un modo per verificare se possibile aggiungere figli alloggetto su cui si vuole agire
49
Pattern COMPOSITE
// Il cliente conosce solo Component Component parent = ComponentFactory.CreateInstance(); Component child = ComponentFactory.CreateInstance(); // Prima di inserire un figlio, // occorre controllare se possibile if(parent.IsComposite()) parent.Add(child);
50
Pattern COMPOSITE
Sicurezza
Tutte le operazioni sui figli vengono messe in Composite a questo punto, qualsiasi invocazione sulle foglie genera un errore in fase di compilazione ma il cliente deve conoscere e gestire due interfacce differenti Se scegliamo la sicurezza
dobbiamo disporre di un modo per verificare se loggetto su cui si vuole agire un Composite
51
Pattern COMPOSITE
// Il cliente conosce Component e Composite Component child = ComponentFactory.CreateComponent(); Composite parent1 = ComponentFactory.CreateComposite(); parent1.Add(child); Component parent2 = ComponentFactory.CreateComponent(); // Errore di compilazione parent2.Add(child); // Prima di inserire un figlio, // occorre controllare se possibile e fare un cast if(parent2 is Composite) ((Composite) parent2).Add(child);
52
Pattern VISITOR
Permette di definire una nuova operazione da effettuare su gli elementi di una struttura, senza dover modificare le classi degli elementi coinvolti Ad esempio, si consideri la rappresentazione di un programma come abstract syntax tree (AST) un albero i cui nodi descrivono elementi sintattici del programma Su tale albero devono poter essere effettuate molte operazioni di tipo diverso Controllare che tutte le variabili siano definite Eseguire delle ottimizzazioni Generare il codice macchina Stampare lalbero in un formato leggibile
Pattern VISITOR
Per lAST utilizziamo il pattern Composite
root Client 1 ComponentNode optimize() generateCode() print()
LeafNode
CompositeNode
VariableNode optimize() generateCode() print()
ConstantNode optimize() generateCode() print()
AssignmentNode optimize() generateCode() print()
54
Pattern VISITOR
In seguito potremmo voler effettuare altri tipi di operazioni controllare che le variabili siano state inizializzate prima delluso ristrutturare automaticamente il programma calcolare varie metriche Se distribuiamo le operazioni sui vari tipi di nodo, otteniamo un sistema che difficile da capire manutenere modificare
55
Pattern VISITOR
La soluzione quella di eliminare le singole operazioni dallAST (la cui responsabilit principale quella di rappresentare un programma sotto forma di albero) Tutto il codice relativo ad un singolo tipo di operazione (ad es. generazione del codice) viene raccolto in una singola classe I nodi dellAST devono accettare la visita delle istanze di queste nuove classi (visitor) Per aggiungere un nuovo tipo di operazione, sufficiente progettare una nuova classe
56
Pattern VISITOR
Il Visitor deve dichiarare unoperazione per ogni tipo di nodo concreto
NodeVisitor VisitVariable(in node : VariableNode) VisitConstant(in node : ConstantNode) VisitAssignment(in node : AssignmentNode)
CodeGeneratingVisitor VisitVariable(in node : VariableNode) VisitConstant(in node : ConstantNode) VisitAssignment(in node : AssignmentNode)
TypeCheckingVisitor VisitVariable(in node : VariableNode) VisitConstant(in node : ConstantNode) VisitAssignment(in node : AssignmentNode)
57
Pattern VISITOR
Ogni nodo deve dichiarare unoperazione per accettare un generico visitor
root Client 1 ComponentNode Accept(in v : NodeVisitor)
LeafNode
CompositeNode
VariableNode Accept(in v : NodeVisitor)
ConstantNode Accept(in v : NodeVisitor)
AssignmentNode Accept(in v : NodeVisitor)
v.VisitVariable(this)
v.VisitConstant(this)
v.VisitAssignment(this)
58
Pattern VISITOR
Visitor (classe astratta o interfaccia) Dichiara un metodo Visit per ogni classe di elementi concreti ConcreteVisitor Definisce tutti i metodi Visit Globalmente definisce loperazione da effettuare sulla struttura e (se necessario) ha un proprio stato
Visitor VisitConcreteElementA(in e : ConcreteElementA) VisitConcreteElementB(in e : ConcreteElementB)
ConcreteVisitor1 VisitConcreteElementA(in e : ConcreteElementA) VisitConcreteElementB(in e : ConcreteElementB)
ConcreteVisitor2 VisitConcreteElementA(in e : ConcreteElementA) VisitConcreteElementB(in e : ConcreteElementB)
59
Pattern VISITOR
Element (classe astratta o interfaccia) Dichiara un metodo Accept che accetta un Visitor come argomento ConcreteElement Definisce il metodo Accept
Element Accept(in v : Visitor)
ObjectStructure
ConcreteElementA Accept(in v : Visitor)
ConcreteElementB Accept(in v : Visitor)
v.VisitConcreteElementA(this)
v.VisitConcreteElementB(this)
60
Pattern VISITOR
ObjectStructure Pu essere realizzata come Composite o come normale collezione (array, lista, ) Deve poter enumerare i suoi elementi Deve dichiarare uninterfaccia che permetta a un cliente di far visitare la struttura a un Visitor
Client
Visitor
ObjectStructure
Element
61
Pattern VISITOR
Facilita laggiunta di nuove operazioni possibile aggiungere nuove operazioni su una struttura esistente, semplicemente aggiungendo un nuovo visitor concreto Senza il pattern Visitor, sarebbe necessario aggiungere un metodo ad ogni classe degli elementi della struttura Ogni Visitor concreto Raggruppa i metodi necessari ad eseguire una data operazione Nasconde i dettagli di come tale operazione debba essere eseguita
62
Pattern VISITOR
Incapsulamento Ogni Visitor deve essere in grado di accedere allo stato degli elementi su cui deve operare difficile aggiungere una nuova classe ConcreteElement Per ogni nuova classe ConcreteElement necessario inserire un nuovo metodo Visit in tutti i Visitor esistenti la gerarchia Element deve essere poco o per nulla modificabile cio essere stabile
63
Pattern VISITOR
Visita di elementi non correlati Non necessario che tutti gli elementi da visitare derivino da una classe comune VisitClasseA(ClasseGerarchiaA a); VisitClasseB(ClasseGerarchiaB b); Stato Durante loperazione ogni Visitor pu modificare il proprio stato ad esempio, per accumulare dei valori o altro
64
Pattern VISITOR
public class CompositeElement : Element { private List<Element> _children; public override void Accept(Visitor visitor) { foreach (Element aChild in _children) aChild.Accept(visitor); visitor.VisitCompositeElement(this); } }
65
Pattern VISITOR
: Client : ObjectStructure a : ConcreteElementA new() Accept(v) Accept(v) VisitConcreteElementA(a) OperazioneX() v : ConcreteVisitor1 b : ConcreteElementB
Accept(v)
VisitConcreteElementB (b) OperazioneY()
66
Pattern VISITOR
Double dispatch
Loperazione che deve essere effettuata dipende dal tipo di due oggetti
il visitor lelemento
Accept unoperazione di tipo double dispatch
Esempio + EsempioDecorator
67
Il Pattern Model / View / Controller (MVC)

Utilizzato per realizzare le interfacce utenti in Smalltalk-80 Permette di suddividere unapplicazione, o anche la sola interfaccia dellapplicazione, in tre parti Modello elaborazione / stato View (o viewport) output Controller input
68

Modello
Gestisce un insieme di dati logicamente correlati Risponde alle interrogazioni sui dati Risponde alle istruzioni di modifica dello stato Genera un evento quando lo stato cambia Registra (in forma anonima) gli oggetti interessati alla notifica dellevento In Java, deve estendere la classe java.util.Observable
69

View
Gestisce unarea di visualizzazione, nella quale presenta allutente una vista dei dati gestiti dal modello Mappa i dati (o parte dei dati) del modello in oggetti visuali Visualizza tali oggetti su un (particolare) dispositivo di output Si registra presso il modello per ricevere levento di cambiamento di stato In Java, deve implementare linterfaccia java.util.Observer
70

Controller
Gestisce gli input dellutente (mouse, tastiera, ) Mappa le azioni dellutente in comandi Invia tali comandi al modello e/o alla view che effettuano le operazioni appropriate In Java, un listener
71

Output Input
View
Controller
Model
Esempio
Introduzione al Framework .NET
Tecnologia COM
Component Object Model 1993 COM is a platform-independent, distributed, object-oriented system for creating binary software components that can interact COM is not an object-oriented language but a standard COM specifies an object model and programming requirements that enable COM objects to interact with other objects
Ingegneria del Software T Ingegneria del Software T

2
Tecnologia COM
Component Object Model
interface IUnknown { virtual HRESULT QueryInterface(IID iid, void **ppvObject) = 0; virtual ULONG AddRef(void) = 0; virtual ULONG Release(void) = 0; };

3
QueryInterface is used to obtain a pointer to another interface, given a GUID that uniquely identifies that interface (commonly known as an interface ID, or IID) if the COM object does not implement that interface, an E_NOINTERFACE error is returned instead AddRef is used by clients to indicate that a COM object is being referenced Release is used by clients to indicate that they have finished using the COM object
Tecnologia COM
The COM specifications require a technique called reference counting to ensure that individual objects remain alive as long as there are clients which have acquired access to one or more of its interfaces and, conversely, that the same object is properly disposed of when all code that used the object have finished with it and no longer require it A COM object is responsible for freeing its own memory once its reference count drops to zero Reference counting may cause problems if two or more objects are circularly referenced

4
Tecnologia COM
Component Object Model Ereditariet solo con composizione e delega
interface IService2 : IService1
5
ISe rvi ce1 Component2 Compone nt1
IService2
Tecnologia COM
The location of each component is stored in the Windows registry There can be only one version of a certain component installed This limitation can seriously complicate the deployment of COM-based applications, due to the possibility that different programs, or even different versions of the same program, may be designed to work with different versions of the same COM component This condition is known as DLL hell

6
Framework .NET
un ambiente di esecuzione (runtime environment) 2002 v.1.0 Semplifica lo sviluppo e il deployment Aumenta laffidabilit del codice Unifica il modello di programmazione completamente indipendente da COM fortemente integrato con COM

7
Sviluppo semplificato
Ambiente object-oriented

8
Qualsiasi entit un oggetto Classi ed ereditariet pienamente supportati Anche tra linguaggi diversi Linguaggi fortemente tipizzati Type Checker Errori non gestiti generazione di eccezioni Meno memory leak Garbage Collector
Riduzione errori comuni di programmazione

Indipendenza dalla piattaforma .NET unimplementazione di CLI

9
Common Language Infrastructure ECMA-334 (C#), ECMA-335 (CLI) SSCLI (Shared Source CLI by Microsoft, per Windows, FreeBSD e Macintosh) - Rotor Mono (per Linux) DotGNU Intel OCL (Open CLI Library)
CLI e il linguaggio C# sono standard ECMA
Esistono altre implementazioni di CLI:

Standard ECMA-335
Defines the Common Language Infrastructure (CLI) in which applications written in multiple high level languages may be executed in different system environments without the need to rewrite the application to take into consideration the unique characteristics of those environments CLI is a runtime environment, with:

10
a file format a common type system an extensible metadata system an intermediate language access to the underlying platform a factored base class library
Piattaforma multi-linguaggio Libert di scelta del linguaggio

11
Tutte le funzionalit del framework .NET sono disponibili a tutti i linguaggi .NET I componenti di unapplicazione possono essere scritti con diversi linguaggi Tool disponibili per tutti i linguaggi: Debugger, Profiler, ecc.
Impatto sui tool
Framework .NET
Concetti chiave:

12
(Microsoft) Intermediate Language - (MS)IL Common Language Runtime - CLR

ambiente di esecuzione runtime per le applicazioni .NET il codice che viene eseguito sotto il suo controllo si dice codice gestito (managed)
Common Type System - CTS

tipi di dato supportati dal framework .NET consente di fornire un modello di programmazione unificato
Common Language Specification - CLS

regole che i linguaggi di programmazione devono seguire per essere interoperabili allinterno del framework .NET sottoinsieme di CTS
Codice interpretato
Sorgenti
Interprete
Esecuzione
13
Codice nativo
Sorgenti
Compilatore

14
Codice nativo (.EXE)
Esecuzione
Codice IL
Sorgenti
Compilatore .NET
Codice IL (Assembly)
.EXE/.DLL
Compilatore JIT
Codice nativo
Esecuzione
15
Codice IL
Sorgenti
Compilatore .NET Codice + metadati
.EXE/.DLL
Compilatore JIT
Codice nativo
Esecuzione
16
Codice IL
Sorgenti
Ambiente di Compilatore esecuzione .NET .NET Runtime
.EXE/.DLL
Compilatore JIT
Codice nativo
Esecuzione
17
Assembly
Unit minima per la distribuzione, il versioning e la security

18
1+ file Metadati che descrivono lassembly stesso Metadati che descrivono completamente tutti i tipi contenuti nellassembly Ottenuto da un qualsiasi linguaggio di programmazione Immagini, icone,
Manifest
Type metadata
Codice in Intermediate Language
Risorse
Assembly
Single-File Assembly
Multi-File Assembly Util.dll
Calc.dll Manifest Type Metadata
Calc.dll Manifest Type Metadata

19
Type Metadata
IL Code
IL Code
IL Code
Pict.gif Resource
Resources
Assembly
.assembly Hello { } .assembly extern mscorlib { } .method public static void main() { .entrypoint ldstr "Hello IL World!" call void [mscorlib]System.Console::WriteLine (class System.String) ret }

20
ilasm helloil.il
Assembly
Assembly privati

21
Utilizzati da unapplicazione specifica Directory applicazione (e sub-directory) Utilizzati da pi applicazioni Global Assembly Cache (GAC) c:\windows\assembly Download cache c:\windows\assembly\download Tool a linea di comando per esaminare GAC e download cache
Assembly condivisi

Assembly scaricati da URL

GACUTIL.EXE
Deployment semplificato
Installazione senza effetti collaterali

22
Applicazioni e componenti possono essere

condivisi o privati
Esecuzione side-by-side
Diverse versioni dello stesso componente possono coesistere, anche nello stesso processo
Metadati
Descrizione dellassembly - Manifest

23
Identit: nome, versione, cultura [, public key] Lista dei file che compongono lassembly Riferimenti ad altri assembly da cui si dipende Permessi necessari per lesecuzione Nome, visibilit, classe base, interfacce Campi, metodi, propriet, eventi, Definiti dal compilatore Definiti dal framework Definiti dallutente
Descrizione dei tipi contenuti nellassembly

Attributi

Tool che usano i metadati

Compilatori

24
Compilazione condizionale Informazioni sulle propriet dei componenti

Categoria Descrizione
Ambienti RAD
Editor personalizzati di tipi di propriet Intellisense ILDASM Anakrino, Reflector
Analisi dei tipi e del codice

Common Language Runtime

VB C++ C# JScript
Common Language Specification Web Services User Interface

25
Data and XML Base Class Library

IL CLR offre vari servizi alle applicazioni
Managed code (MSIL)
26
Common Language Runtime (CLR) Funzionalit specifiche di CLR (es. Garbage Collector) Funzionalit esistenti (es. I/O su file) mediate da CLR
Sistema operativo (Win32, )

Base Class Library Support Thread Support
27
COM Marshaler Exception Manager Debug Engine Code Manager Garbage Collector (GC)
Type Checker Security Engine MSIL to Native Compilers (JIT)
Class Loader
Sicurezza e affidabilit del codice Separazione spazi di memoria in un processo con AppDomain Controllo del codice e sicurezza dei tipi

28
Cast non sicuri Variabili non inizializzate Accessi ad array oltre i limiti di allocazione
Garbage Collector
Garbage Collector per tutti gli oggetti .NET Gestione del ciclo di vita degli oggetti Gli oggetti vengono distrutti automaticamente quando non sono pi referenziati A differenza di COM, non ci si basa sul Reference Counting


29
Maggiore velocit di allocazione Consentiti i riferimenti circolari Perdita della distruzione deterministica
Algoritmo Mark-and-Compact
Garbage Collector e distruzione deterministica In alcuni casi serve un comportamento di finalizzazione deterministica

Riferimenti a oggetti non gestiti Utilizzo di risorse che devono essere rilasciate appena termina il loro utilizzo

30
Non possibile utilizzare il metodo Finalize (in C# il distruttore), in quanto non richiamabile direttamente necessario implementare linterfaccia IDisposable
Gestione delle eccezioni

Uneccezione

31
Una condizione di errore Un comportamento inaspettato
incontrato durante lesecuzione del programma Uneccezione pu essere generata dal

Codice del programma in esecuzione Ambiente di runtime
In CLR, uneccezione un oggetto che eredita dalla classe System.Exception Gestione uniforme - elimina

Codici HRESULT di COM Codici di errore Win32
Gestione delle eccezioni

Concetti universali

32
Lanciare uneccezione (throw) Catturare uneccezione (catch) Eseguire codice di uscita da un blocco controllato (finally)
Disponibile in tutti i linguaggi .NET con sintassi diverse
Altri servizi del CLR

Reflection

33
Analisi dei metadati di un assembly Generazione di un assembly dinamico Chiamata di componenti remoti (.NET)
Remoting
Interoperabilit (COM, Platform Invoke)
Reflection
possibile interrogare un assembly caricato in memoria

Tipi (classi, interfacce, enumeratori, etc.) Membri (attributi, propriet, metodi, etc.) Parametri

34
possibile forzare il caricamento in memoria di un assembly con i metodi Load/LoadFrom
Common Type System

Tipi di dato supportati dal framework .NET
Alla base di tutti i linguaggi .NET
Consente di fornire un modello di programmazione unificato Progettato per linguaggi object-oriented, procedurali e funzionali


35
Esaminate caratteristiche di 20 linguaggi Tutte le funzionalit disponibili con IL Ogni linguaggio utilizza alcune caratteristiche Regole di compatibilit tra linguaggi Sottoinsieme di CTS
Common Language Specification

Common Type System

Alla base di tutto ci sono i tipi: classi, strutture, interfacce, enumerativi, delegati Fortemente tipizzato (compile-time) Object-oriented

36
Campi, metodi, tipi nidificati, propriet, ...
Overload di funzioni (compile-time) Invocazione metodi virtuali risolta a run-time Ereditariet singola di implementazione Ereditariet multipla di interfacce Gestione strutturata delle eccezioni

Regole per gli identificatori

37
Unicode, case-sensitivity Keyword
Regole di overload pi restrittive Nessun puntatore unmanaged Devono essere supportate interfacce multiple con metodi dello stesso nome Regole per costruttori degli oggetti Regole per denominazione propriet ed eventi

Fujitsu COBOL Extensions
38
Common Type System
Microsoft Managed C++ Extensions
COBOL CLS
C++
Common Type System Tipi nativi

CTS System.Object System.String System.Boolean
39
C# object string bool char float double decimal sbyte byte short ushort int uint long ulong
System.Char System.Single System.Double System.Decimal System.SByte System.Byte System.Int16 System.UInt16 System.Int32 System.UInt32 System.Int64 System.UInt64
Common Type System

Tutto un oggetto

40
System.Object la classe radice
Due categorie di tipi
Tipi riferimento
Riferimenti a oggetti allocati sullheap gestito Indirizzi di memoria
Tipi valore
Allocati sullo stack o parte di altri oggetti Sequenza di byte
Common Type System Tipi valore I tipi valore comprendono:

41
Tipi primitivi (built-in)

Int32, Single, Double Decimal Boolean Char
Tipi definiti dallutente

Strutture (struct) Enumerativi (enum)
Common Type System Tipi valore vs tipi riferimento

public struct Size { public int height; public int width; } public class CSize { public int height; public int width; } public static void Main() { Size v; // v istanza di Size v.height = 100; // ok CSize r; // r un reference r.height = 100; // NO, r non assegnato r = new CSize(); // r fa riferimento a un CSize r.height = 100; // ok, r inizializzata }
v.height v.width r

42
Stack
height width
Heap
Class CSize

public struct Point { private int _x, _y; public Point(int x, int y) { _x = x; _y = y; } public int X { get { return _x; } set { _x = value; } } public int Y { get { return _y; } set { _y = value; } } }
43

public class Rectangle { Point v1; Point v2; } Rectangle r = new Rectangle();

44
r v1._x v1._y v2._x v2._y

Point[] points = new Point[100]; for (int i = 0; i < 100; i++) points[i] = new Point(i, i);

45
Alla fine, rimane 1 solo oggetto nellheap (larray di Point)

Point[] points = new Point[100]; for (int i = 0; i < 100; i++) { points[i].X = i; points[i].Y = i; }

public class Point { private int _x, _y; public Point(int x, int y) { _x = x; _y = y; } public int X { get { return _x; } set { _x = value; } } public int Y { get { return _y; } set { _y = value; } } }
46

public class Rectangle { Point v1; Point v2; } Rectangle r = new Rectangle();

47
_x
_y
v1
v2
_x
_y

Point[] points = new Point[100]; for (int i = 0; i < 100; i++) points[i] = new Point(i, i);

48
Alla fine, rimangono 101 oggetti nellheap (1 array di Point + 100 Point)
Point[] points = new Point[100]; for (int i = 0; i < 100; i++) { points[i].X = i; points[i].Y = i; }
NO!
Common Type System Tipi valore e tipi riferimento
Object
String
Array
ValueType
EventArgs
Attribute
Exception
Delegate

49
struct DateTime
struct Enum
struct Double
struct Int32
struct Boolean
delegate MulticastDelegate
enumeration DayOfWeek Sunday = 0 Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6
delegate EventHandler
Boxing / Unboxing
Un qualsiasi tipo valore pu essere automaticamente convertito in un tipo riferimento (boxing) mediante un up cast implicito a System.Object
50
int i = 123; object o = i;
Un tipo valore boxed pu tornare ad essere un tipo valore standard (unboxing) mediante un down cast esplicito
int k = (int) o;
Un tipo valore boxed un clone indipendente
Boxing / Unboxing
int i = 123; object o = i; int k = (int) o;
51
STACK
HEAP
i 123 o k 123
Int32 123
Modello di esecuzione
Source Code
52
VB Compiler Assembly
C# Compiler Assembly
C++ Compiler Assembly
IL
Ngen
Common Language Runtime JIT Compiler
Native Code
Managed Code CLR Services
Managed CLR Code
Managed Code
Unmanaged Code
Operating System Services
Framework .NET 1.1

System.Web Compilation Handlers Hosting Caching Configuration
53
System.Windows.Forms Design ComponentModel
UI HtmlControls WebControls Security SessionState
System.Drawing Drawing2D Imaging Printing Text
System.Data OleDb SqlClient Common SQLTypes System Collections Configuration Diagnostics Globalization IO Reflection Resources Security Text Threading Xsl XPath
System.Xml Schema Serialization
Runtime InteropServices Remoting Serialization
Framework .NET
Il framework non una scatola nera E possibile estendere una qualsiasi classe .NET (non sealed) mediante ereditariet Diversamente da COM,

54
si usa e si estende la classe stessa non si utilizza uno strato intermedio (wrapper)
Lereditariet cross-language
Bibliografia
Libri di base: D. S. Platt, Introducing Microsoft .NET, Second Edition (*) J. Sharp, J. Jagger, Microsoft Visual C# .NET Step by Step (*) T. Archer, A. Whitechapel, Inside C#, Second Edition (*) M. J. Young, XML Step by Step, Second Edition (*) R. M. Riordan, Microsoft ADO.NET Step by Step (*) Libri avanzati: J. Richter, Applied Microsoft .NET Framework Programming C. Petzold, Programming Microsoft Windows with C# (*) S. Lidin, Inside Microsoft .NET IL Assembler
(*) Disponibile nella biblioteca del DEIS

55
Working with Types
Tipi in .NET
Dal punto di vista del modo in cui le istanze vengono gestite in memoria (rappresentazione, tempo di vita, ), i tipi possono essere distinti in:

Reference type Value type

2
Dal punto di vista sintattico (sintassi del linguaggio C#), i tipi possono essere distinti in:

Classi class Interfacce interface Strutture struct Enumerativi enum Delegati delegate Array []
In .NET, si concretizzano sempre in una classe (anche nel caso di tipi built-in e di interfacce)
Tipi in .NET
In generale, un tipo pu contenere la definizione di 0+:

Costanti sempre implicitamente associate al tipo Campi (field) read-only o read-write, associati alle istanze o al tipo Metodi associati alle istanze o al tipo Costruttori di istanza o di tipo Operatori sempre associati al tipo Operatori di conversione sempre associati al tipo Propriet associate alle istanze o al tipo Indexer sempre associati alle istanze Eventi associati alle istanze o al tipo Tipi annidati

3
Modificatori di visibilit
Modificatore private
4
Tipi a livello base Non applicabile
Tipi annidati Visibile nel tipo contenitore (default) Visibile nel tipo contenitore e nei suoi sottotipi Visibile nellassembly contenitore
Visibile sia nel tipo contenitore e nei suoi sottotipi, sia nellassembly contenitore
protected
Non applicabile Visibile nellassembly contenitore (default)
internal
protected internal
Non applicabile
public
Visibilit completa
Visibilit completa
Modificatore private
5
Dati default
Operazioni - Eventi Visibile nel tipo contenitore (default) Visibile nel tipo contenitore e nei suoi sottotipi Visibile nellassembly contenitore
Visibile sia nel tipo contenitore e nei suoi sottotipi, sia nellassembly contenitore
protected
Applicare esclusivamente a costanti ed eventualmente a campi read-only ( comunque preferibile laccesso mediante una propriet)
internal
protected internal
public
Visibilit completa
Non sono applicabili nei seguenti casi:

Costruttori di tipo (statici) sempre inaccessibili invocati direttamente dal CLR Distruttori (finalizer) sempre inaccessibili invocati direttamente dal CLR Membri di interfacce sempre pubblici Membri di enum sempre pubblici Implementazione esplicita di membri di interfacce visibilit particolare (pubblici/privati), non modificabile Namespace sempre pubblici

6
Regole
Massimizzare lincapsulamento minimizzando la visibilit Information hiding a livello di assembly
Dichiarare public solo i tipi significativi dal punto di vista concettuale Dichiarare public solo metodi, propriet ed eventi significativi dal punto di vista concettuale Dichiarare protected solo le funzionalit che devono essere visibili nelle classi derivate, ma non esternamente ad esempio, costruttori particolari, metodi e propriet virtuali non public Field private e propriet public Field private e propriet protected

7
Information hiding a livello di classe

Information hiding a livello di field

Costanti
Una costante un simbolo che identifica un valore che non pu cambiare Il tipo della costante pu essere solo un tipo considerato primitivo dal CLR (compreso string) Il valore deve essere determinabile compile-time Ad esempio, in Int32 esistono:
public const int MaxValue = 2147483647; public const int MinValue = -2147483648;

8
In una classe contenitore di dimensioni prefissate, si potrebbe definire:

public const int MaxEntries = 100; // Warning!
Si noti lutilizzo della maiuscola iniziale possibile applicare const anche alle variabili locali
Field
Un field un data member che pu contenere:

un valore (un istanza di un value type), oppure un riferimento (a unistanza di un reference type) in genere, la realizzazione di unassociazione di istanza (default), oppure di tipo (static) read-write (default), oppure read-only (readonly) inizializzato nella definizione o nel costruttore

9
Pu essere:

Pu essere:

Esiste sempre un valore di default (0, 0.0, false, null)
Field
Qual la differenza tra le seguenti definizioni:
public const int MaxEntries = 100; public static readonly int MaxEntries = 100; Nel primo caso, la costante MaxEntries viene iniettata nel codice del cliente se il valore viene modificato e se il cliente e il fornitore sono in assembly diversi, necessario ricompilare anche il codice del cliente Nel secondo caso, laccesso al field MaxEntries quello standard: il valore in memoria ed necessario reperirlo se il valore viene modificato e se il cliente e il fornitore sono in assembly diversi, NON necessario ricompilare anche il codice del cliente
10
Regole
Definire const solo le costanti vere, cio i valori veramente immutabili nel tempo (nelle versioni del programma), negli altri casi utilizzare field statici read-only il valore di MaxEntries non una costante vera perch in una versione successiva del programma potrebbe cambiare Costanti


11
il nome dovrebbe iniziare con una lettera maiuscola di solito, dovrebbe essere pubblica (ma non sempre cos) il nome deve iniziare con _ seguito da una lettera minuscola deve essere privata (accesso sempre mediante propriet) scegliere, a seconda delle situazioni, una delle due convenzioni precedenti
Field

Field read-only
Modificatori di metodi
virtual abstract override override sealed / sealed override Applicabili a:


12
Metodi Propriet (metodi get e set) Indexer (metodi get e set) Eventi (metodi add e remove)
di istanza (cio non statici)
Modificatori di metodi virtual

The implementation of a virtual method can be changed by an overriding member in a derived class When a virtual method is invoked, the run-time type of the object is checked for an overriding member


13
Late binding Polimorfismo
By default, methods are non-virtual It is an error to use the virtual modifier on a static method
protected virtual void Method() { } public virtual int Property { get { } set { } } public virtual int this[int index] { get { } }
Modificatori di metodi abstract

Use the abstract modifier to indicate that the method does not contain implementation Abstract methods have the following features

An abstract method is implicitly a virtual method Abstract method declarations are only permitted in abstract classes

14
The implementation is provided by an overriding method It is an error to use the static or virtual modifiers in an abstract method declaration
protected abstract void Method(); public abstract int Property { get; set; } public abstract int this[int index] { get; }
Modificatori di metodi override

An override method provides a (new) implementation of a member inherited from a base class - the method overridden by an override declaration is known as the overridden base method The overridden base method

Must be virtual, abstract, or override Must have the same signature as the override method

15
You cannot override a non-virtual or static method An override declaration cannot change the accessibility of the overridden base method Use of the sealed modifier prevents a derived class from further overriding the method
protected override void Method() { } public override sealed int Property { get { } set { } } public override int this[int index] { get { } }
Metodi
Passaggio degli argomenti
Tre tipi di argomenti:
In (default in C#)
Largomento deve essere inizializzato Largomento viene passato per valore (per copia) Eventuali modifiche del valore dellargomento non hanno effetto sul chiamante

16
In/Out (ref in C#)

Largomento deve essere inizializzato Largomento viene passato per riferimento Eventuali modifiche del valore dellargomento hanno effetto sul chiamante
Out (out in C#)

Largomento pu NON essere inizializzato Largomento viene passato per riferimento Le modifiche del valore dellargomento (linizializzazione obbligatoria) hanno effetto sul chiamante
Metodi
Passaggio degli argomenti In
Value type

Viene passata una copia delloggetto Eventuali modifiche vengono effettuate sulla copia e non hanno alcun effetto sulloggetto originale Viene passata una copia del riferimento alloggetto Eventuali modifiche delloggetto referenziato hanno effetto Eventuali modifiche del riferimento vengono effettuate sulla copia e non hanno alcun effetto sul riferimento originale

17
Reference type

Point p1 = new Point(0,0); Method1(p1); Console.WriteLine("{0}",p1); static void Method1(Point p) { p.X = 100; p.Y = 100; }
Se Point una classe (100,100) Se Point una struttura (0,0)
Metodi
Passaggio degli argomenti In/Out
Value type

Viene passato lindirizzo delloggetto Eventuali modifiche agiscono direttamente sulloggetto originale Viene passato lindirizzo del riferimento alloggetto Eventuali modifiche delloggetto referenziato hanno effetto Eventuali modifiche del riferimento agiscono direttamente sul riferimento originale
Reference type


18
Point p1 = new Point(0,0); Method2(ref p1); Console.WriteLine("{0}",p1); static void Method2(ref Point p) { p.X = 100; p.Y = 100; }
Se Point una classe (100,100) Se Point una struttura (100,100)
Metodi
Passaggio degli argomenti
class/struct Persona Persona p1 = new Persona(Tizio); Method1(p1); // p1 == Tizio Method2(ref p1); // p1 == Sempronio static void Method1(Persona p) { p = new Persona(Caio); // }
//
p1 == Tizio

19
p == Caio
static void Method2(ref Persona p) { p = new Persona(Sempronio); // }
p == Sempronio
Metodi
Passaggio degli argomenti Out
Value type e Reference type

Viene passato lindirizzo delloggetto o del riferimento alloggetto come nel caso In/Out Non necessario che loggetto o il riferimento siano inizializzati prima di essere passati come argomento Loggetto o il riferimento DEVONO essere inizializzati nel metodo a cui sono stati passati come argomento

20
Point p1; Method3(out p1); static void Method3(out Point p) { // In questo punto il compilatore suppone che // p NON sia inizializzato p.X = 100; p.Y = 100; // Non compila! p = new Point(100,100); // indispensabile }
Regole
Utilizzare prevalentemente il passaggio standard per valore Utilizzare il passaggio per riferimento (ref o out) solo se strettamente necessario

2+ valori da restituire al chiamante 1+ valori da utilizzare e modificare nel metodo Scegliere ref se loggetto passato come argomento deve essere gi stato inizializzato Scegliere out se responsabilit del metodo inizializzare completamente loggetto passato come argomento

21
void Swap(ref int value1, ref int value2) { } void SplitCognomeNome(string cognomeNome, out string cognome, out string nome) { }
Metodi
Numero variabile di argomenti
Si supponga di dover scrivere:
Add(a,b); // a+b Add(10,20,30); // 10+20+30 Add(x1,x2,x3,x4); // x1+x2+x3+x4
22
Soluzioni possibili:

Overloading del metodo Add Svantaggio: posso solo codificare un numero finito di metodi Definire un solo metodo Add che accetti un numero variabile di argomenti
int Add(params int[] operands) { int total = 0; foreach (int operand in operands) total += operand; return total; }
Metodi
Numero variabile di argomenti
Non solo posso scrivere:
Add(a,b); Add(10,20,30); Add(x1,x2,x3,x4);
23
Ma anche:
Add(); // restituisce 0 int[] numbers = { 10,20,30,40,50 }; Add(numbers); Add(new int[] { 10,20,30,40,50 }); Add(new int[] { x1,x2,x3,x4,x5 });
Zucchero sintattico:
Add(x1,x2,x3,x4); Add(new int[] { x1,x2,x3,x4 });
Costruttori di istanza
Responsabilit: inizializzare correttamente lo stato delloggetto appena creato (nulla di pi!) In mancanza di altri costruttori, esiste sempre un costruttore di default senza argomenti che, semplicemente, invoca il costruttore senza argomenti della classe base Nel caso delle classi, il costruttore senza argomenti pu essere definito dallutente Nel caso delle strutture, il costruttore senza argomenti NON pu essere definito dallutente (per motivi di efficienza) In entrambi i casi, possibile definire altri costruttori con differente signature e differente visibilit
24
public abstract class DataAdapterManager { private readonly IDataTable _dataTable; private readonly IConnectionManager _connectionManager;
protected DataAdapterManager(IDataTable dataTable, IConnectionManager connectionManager) { if(dataTable == null) throw new ArgumentNullException("dataTable"); if(connectionManager == null) throw new ArgumentNullException("connectionManager"); _dataTable = dataTable; _connectionManager = connectionManager; } }
25
public class XmlDataAdapterManager : DataAdapterManager { private readonly Encoding _encoding; public XmlDataAdapterManager(IDataTable dataTable, XmlConnectionManager xmlConnectionManager) : this(dataTable, xmlConnectionManager, Encoding.Unicode) { } public XmlDataAdapterManager(IDataTable dataTable, XmlConnectionManager xmlConnectionManager, Encoding encoding) : base(dataTable, xmlConnectionManager) { _encoding = encoding; } }
26
Costruttori di tipo
Responsabilit: inizializzare correttamente lo stato comune a tutte le istanze della classe field statici Dichiarato static Implicitamente private Sempre senza argomenti no overloading Pu accedere esclusivamente ai membri (field, metodi, ) statici della classe Se esiste, viene invocato automaticamente dal CLR


27
Prima della creazione della prima istanza della classe Prima dellinvocazione di un qualsiasi metodo statico della classe
Non basare il proprio codice sullordine di invocazione di costruttori di tipo
Costruttori di tipo
class MyType { static int _x = 5; } class MyType { static int _x; static MyType() { _x = 5; } } class MyType { static int _x = 5; static MyType() { _x = 10; } } Viene definito implicitamente un costruttore di tipo

28
Del tutto analogo al caso precedente
_x viene prima inizializzato a 5 e quindi a 10
Regole
Definire un costruttore di tipo solo se strettamente necessario, cio se i campi statici della classe

NON possono essere inizializzati in linea Devono essere inizializzati solo se la classe viene effettivamente utilizzata

29
public class A { private static XmlDocument _xmlDocument; static A() { _xmlDocument = new XmlDocument(); _xmlDocument.Load(); } }
Costruttori ed eccezioni
Supponiamo che

30
un costruttore lanci uneccezione e leccezione non venga gestita allinterno del costruttore stesso (quindi arrivi al chiamante)
Nel caso di costruttori di istanza

nessun problema! In C++ una situazione non facilmente gestibile
Nel caso di costruttori di tipo

la classe NON pi utilizzabile! TypeInitializationException
Interfacce
In C#, uninterfaccia pu contenere esclusivamente:

Metodi considerati pubblici e astratti Propriet considerate pubbliche e astratte Indexer considerati pubblici e astratti Eventi considerati pubblici e astratti

31
In CLR, uninterfaccia considerata una particolare classe astratta di sistema che (ovviamente) non deriva da System.Object per, le classi che la implementano derivano per forza da System.Object Uninterfaccia

Pu essere implementata sia dai reference type, sia dai value type considerata sempre un reference type Attenzione: se si effettua il cast di un value type a uninterfaccia, avviene un boxing del value type (con conseguente copia del valore)!
Implementazione di una interfaccia

public interface IBehavior { void Method(); int Property { get; set; } int this[int index] { get; } } public class A : IBehavior { public void Method() // { } public int Property { get { } set { } } //

32
virtual sealed virtual sealed
public int this[int index] { get { } } }
//
virtual sealed
Implementazione di una interfaccia

public class A : IBehavior { public virtual void Method() { } public virtual int Property { get { } set { } } public virtual int this[int index] { get { } } } public class B : A { public override void Method() public override int Property public override int this[int index] }
33
Implementazione di una interfaccia / classe astratta

public abstract class A : IBehavior { public abstract void Method(); public abstract int Property { get; set; } public abstract int this[int index] { get; } } public class B : A { public override void Method() public override int Property public override int this[int index] }

34
Implementazione esplicita di una interfaccia

public class A : IBehavior { void IBehavior.Method() { } int IBehavior.Property { get { } set { } } int IBehavior.this[int index] { get { } } Name
hiding Avoiding name ambiguity

Ok!
A a = new A(); a.Method(); // Non compila! ((IBehavior) a).Method(); //

35
Implementazione esplicita di una interfaccia

public interface IMyInterface1 { void Close(); } public interface IMyInterface2 { void Close(); }
36
public class MyClass : IMyInterface1, IMyInterface2 { void IMyInterface1.Close() { } void IMyInterface2.Close() { } public void Close() { } } MyClass a = new MyClass(); ((IMyInterface1) a).Close(); ((IMyInterface2) a).Close(); a.Close(); // Ok!
// //
Ok! Ok!
Framework .NET
Framework .NET Overview
Object
String
Array
ValueType
EventArgs
Attribute
Exception
Delegate

2
struct DateTime
struct Enum
struct Double
struct Int32
struct Boolean
enumeration DayOfWeek Sunday = 0 Monday = 1 Tuesday = 2 Wednesday = 3 Thursday = 4 Friday = 5 Saturday = 6
delegate EventHandler
System.Object
Supports all classes in the .NET Framework class hierarchy and provides low-level services to derived classes This is the ultimate superclass of all classes in the .NET Framework; it is the root of the type hierarchy Because all classes in the .NET Framework are derived from Object, every method defined in the Object class is available in all objects in the system

3
System.Object

4
Object + Object ( ) # Finalize ( ) + GetHashCode ( ) : System.Int32 + Equals ( [in] obj : System.Object ) : System.Boolean + ToString ( ) : System.String + Equals ( [in] objA : System.Object , [in] objB : System.Object ) : System.Boolean + ReferenceEquals ( [in] objA : System.Object , [in] objB : System.Object ) : System.Boolean + GetType ( ) : System.Type # MemberwiseClone ( ) : System.Object
System.Object
Derived classes can and do override some of these methods, including: Equals - Supports comparisons between objects ToString - Manufactures a human-readable text string that describes an instance of the class GetHashCode - Generates a number corresponding to the value of the object to support the use of a hash table Finalize - Performs cleanup operations before an object is automatically reclaimed

5
Object.Equals
public virtual bool Equals(object obj); Return value: true if this is equal to obj otherwise, false The default implementation of Equals supports reference equality only, but derived classes can override this method to support value equality For reference types, equality is defined as object equality; that is, whether the references refer to the same object For value types, equality is defined as bitwise equality The ValueType class supports value types

6
Object.Equals
The following statements must be true for all implementations of the Equals method. In the list, x, y, and z represent object references that are not a null reference


7
x.Equals(x) returns true x.Equals(y) returns the same value as y.Equals(x) x.Equals(y) returns true if both x and y are NaN (x.Equals(y) && y.Equals(z)) returns true if and only if x.Equals(z) returns true Successive calls to x.Equals(y) return the same value as long as the objects referenced by x and y are not modified x.Equals(a null reference) returns false
Implementations of Equals must not throw exceptions
Object.Equals
For some kinds of objects, it is desirable to have Equals test for value equality instead of referential equality Such implementations of Equals return true if the two objects have the same value, even if they are not the same instance The types implementer decides what constitutes an objects value, but it is typically some or all the data stored in the instance variables of the object For example, the value of a String is based on the characters of the string; the Equals method of the String class returns true for any two string instances that contain exactly the same characters in the same order

8
Object.Equals
Types that override Equals must also override GetHashCode; otherwise, Hashtable might not work correctly If your programming language supports operator overloading and if you choose to overload the equality operator for a given type, that type should override the Equals method Such implementations of the Equals method should return the same results as the equality operator

9
Object.Equals
public class Point { private readonly int x, y; public override bool Equals(object obj) { //Check for null and compare run-time types. if(obj == null || GetType() != obj.GetType()) return false; Point p = (Point) obj; return (x == p.x) && (y == p.y); } public override int GetHashCode() { return x ^ y; } }

10
Object.Equals
public class SpecialPoint : Point { private readonly int w; public SpecialPoint(int x, int y, int w) : base(x, y) { this.w = w; } public override bool Equals(object obj) { return base.Equals(obj) && w == ((SpecialPoint) obj).w; } public override int GetHashCode() { return base.GetHashCode() ^ w; } }

11
Object.Equals
public class Rectangle { private readonly Point a, b; public override bool Equals(object obj) { if(obj == null || GetType() != obj.GetType()) return false; Rectangle r = (Rectangle) obj; // Uses Equals to compare variables. return a.Equals(r.a) && b.Equals(r.b); } public override int GetHashCode() { return a.GetHashCode() ^ b.GetHashCode(); } }

12
Object.Equals
public struct Complex { private readonly double re, im; public override bool Equals(object obj) { return obj is Complex && this == (Complex) obj; } public override int GetHashCode() { return re.GetHashCode() ^ im.GetHashCode(); } public static bool operator ==(Complex x, Complex y) { return x.re == y.re && x.im == y.im; } public static bool operator !=(Complex x, Complex y) { return !(x == y); } }

13
System.ValueType
Object
ValueType
# ValueType ( ) + GetHashCode ( ) : System.Int32 + Equals ( [in] obj : System.Object ) : System.Boolean + ToString ( ) : System.String
One or more fields of the derived type is used to calculate the return value. If one or more of those fields contains a mutable value, the return value might be unpredictable, and unsuitable for use as a key in a hash table. In that case, consider writing your own implementation of GetHash Code that more closely represents the concept of a hash code for the type.

14
The default implementation of the Equals method uses reflection to compare the corresponding fields of obj and this instance. Override the Equals method for a particular type to improve the performance of the method and more closely represent the concept of equality for the type.
System.Boolean
interface IComparable
ValueType
interface IConvertible
+ CompareTo ( [in] obj : System.Object ) : System.Int32
struct Boolean + TrueString : System.String + FalseString : System.String + ToString ( [in] provider : System.IFormatProvider ) : System.String + GetTypeCode ( ) : System.TypeCode + CompareTo ( [in] obj : System.Object ) : System.Int32 + GetHashCode ( ) : System.Int32 + Equals ( [in] obj : System.Object ) : System.Boolean + ToString ( ) : System.String + Parse ( [in] value : System.String ) : System.Boolean
+ ToType ( ) + ToString ( ) + ToDateTime ( ) + ToDecimal ( ) + ToDouble ( ) + ToSingle ( ) + ToUInt64 ( ) + ToInt64 ( ) + ToUInt32 ( ) + ToInt32 ( ) + ToUInt16 ( ) + ToInt16 ( ) + ToByte ( ) + ToSByte ( ) + ToChar ( ) + ToBoolean ( ) + GetTypeCode ( )

15
System.Int32
interface IFormattable
ValueType
+ ToString ( [in] format : System.String , [in] formatProvider : System.IFormatProvider ) : System.String

16
IComparable IConvertible + MaxValue : System.Int32 + MinValue : System.Int32
struct Int32
+ ToString ( [in] provider : System.IFormatProvider ) : System.String + GetTypeCode ( ) : System.TypeCode + ToString ( [in] format : System.String , [in] provider : System.IFormatProvider ) : System.String + CompareTo ( [in] value : System.Object ) : System.Int32 + GetHashCode ( ) : System.Int32 + Equals ( [in] obj : System.Object ) : System.Boolean + ToString ( ) : System.String + ToString ( [in] format : System.String ) : System.String + Parse ( [in] s : System.String ) : System.Int32 + Parse ( [in] s : System.String , [in] style : System.Globalization.NumberStyles ) : System.Int32 + Parse ( [in] s : System.String , [in] provider : System.IFormatProvider ) : System.Int32 + Parse ( [in] s : System.String , [in] style : System.Globalization.NumberStyles , [in] provider : Sys...
System.IComparable
interface IComparable
+ CompareTo ( [in] obj : System.Object ) : System.Int32
Compares the current instance with another object of the same type Return Value: a 32-bit signed integer that indicates the relative order of the comparands The return value has these meanings:


17
Less than zero - this instance is less than obj Zero - this instance is equal to obj Greater than zero - this instance is greater than obj
By definition, any object compares greater than a null reference The parameter obj must be the same type as the class or value type that implements this interface; otherwise, an ArgumentException is thrown
System.IComparable
Notes to Implementers: For any objects A, B and C, the following must be true:

A.CompareTo(A) is required to return zero If A.CompareTo(B) returns zero then B.CompareTo(A) is required to return zero If A.CompareTo(B) returns zero and B.CompareTo(C) returns zero then A.CompareTo(C) is required to return zero If A.CompareTo(B) returns a value other than zero then B.CompareTo(A) is required to return a value of the opposite sign If A.CompareTo(B) returns a value x not equal to zero, and B.CompareTo(C) returns a value y of the same sign as x, then A.CompareTo(C) is required to return a value of the same sign as x and y

18
Esempio 1
System.IComparable
Se volessi:

19
Ordinare i punti in ordine decrescente Ordinare dei film

Per genere, oppure Per titolo
Ordinare degli studenti

Per cognome e nome, oppure Per matricola, oppure Per corso di studio
System.Collections.IComparer
interface IComparer
+ Compare ( [in] x : System.Object , [in] y : System.Object ) : System.Int32
This interface is used in conjunction with the Array.Sort and Array.BinarySearch methods It provides a way to customize the sort order of a collection
IComparable IComparer

20
struct Point + property X : int + property Y : int - _x : int - _y : int + Point ( ) + ToString ( ) + CompareTo ( ) use
Comparer - _up : bool = true + Comparer ( ) + Comparer ( [in] up : bool ) + Compare ( [in] obj1 : object , [in] obj2 : object ) : int
Esempio 1
System.IConvertible
interface IConvertible
+ ToType ( ) + ToString ( ) + ToDateTime ( ) + ToDecimal ( ) + ToDouble ( ) + ToSingle ( ) + ToUInt64 ( ) + ToInt64 ( ) + ToUInt32 ( ) + ToInt32 ( ) + ToUInt16 ( ) + ToInt16 ( ) + ToByte ( ) + ToSByte ( ) + ToChar ( ) + ToBoolean ( ) + GetTypeCode ( )
This interface provides methods to convert the value of an instance of an implementing type to a common language runtime type that has an equivalent value The common language runtime types are Boolean, SByte, Byte, Int16, UInt16, Int32, UInt32, Int64, UInt64, Single, Double, Decimal, DateTime, Char, and String If there is no meaningful conversion to a common language runtime type, then a particular interface method implementation throws InvalidCastException - For example, if this interface is implemented on a Boolean type, the implementation of the ToDateTime method throws an exception because there is no meaningful DateTime equivalent to a Boolean type

21
System.Convert
Convert + DBNull : System.Object + GetTypeCode ( ) + IsDBNull ( ) + ChangeType ( ) + ToBoolean ( ) + ToChar ( ) + ToSingle ( ) + ToDouble ( ) + ToDecimal ( ) + ToDateTime ( ) + ToByte ( ) + ToSByte ( ) + ToInt16 ( ) + ToUInt16 ( ) + ToInt32 ( ) + ToUInt32 ( ) + ToInt64 ( ) + ToUInt64 ( ) + ToString ( ) + ToBase64String ( ) + ToBase64String ( ) + FromBase64String ( ) + ToBase64CharArray ( ) + FromBase64CharArray ( )
In System.Int32, limplementazione dellinterfaccia System.IConvertible un esempio di explicit interface implementation:

int x = 32; double d = x.ToDouble(); // No!

22
necessario scrivere:
((IConvertible) x).ToDouble()
Se necessario, utilizzare la classe Convert:

Convert.ToDouble(x)
System.Convert
Throws an exception if the conversion is not supported
bool b = Convert.ToBoolean(DateTime.Today); // InvalidCastException
Performs checked conversions

int k = 300; byte b = (byte) k; // b == 44 byte b = Convert.ToByte(k); //

23
OverflowException
In alcuni casi, esegue un arrotondamento:

double d = 42.72; int k = (int) d; // k == 42 int k = Convert.ToInt32(d); // k == 43
Is also useful if you have a string that you want to convert to a numeric value:
string myString = "123456789"; int myInt = Convert.ToInt32(myString);
Conversione di tipo
Widening conversion occurs when a value of one type is converted to another type that is of equal or greater size

Da Int32 a Int64 Da Int32 a UInt64 Da Int32 a Single (con possibile perdita di precisione) Da Int32 a Double

24
Narrowing conversion occurs when a value of one type is converted to a value of another type that is of a smaller size

Da Int32 a Byte Da Int32 a SByte Da Int32 a Int16 Da Int32 a UInt16 Da Int32 a UInt32
Conversione di tipo
Conversioni implicite non generano eccezioni
Conversioni numeriche Il tipo di destinazione dovrebbe essere in grado di contenere, senza perdita di informazione, tutti i valori ammessi dal tipo di partenza Eccezione:
int k1 = 1234567891; float b = k1; int k2 = (int) b; //

25
k2 == 1234567936
Up cast Principio di sostituibilit: deve sempre essere possibile utilizzare una classe derivata al posto della classe base
B b = new B(); A a = b; // class B : A
Conversione di tipo
Conversioni esplicite possono generare eccezioni
Conversioni numeriche Il tipo di destinazione non sempre in grado di contenere il valore del tipo di partenza
int k1 = -1234567891; uint k2 = (uint) k1; // k2 == 3060399405

26
int k1 = -1234567891; uint k2 = checked((uint) k1); int k1 = -1234567891; uint k2 = Convert.ToUInt32(k1);
//
OverflowException
// OverflowException
Conversione di tipo
Conversioni esplicite possono generare eccezioni
Down cast
A a = new B(); // class B : A B b = (B) a; // Ok

27
a = new A(); b = (B) a; //
InvalidCastException
if(a is B) // if(a.GetType() == typeof(B)) { b = (B) a; // Non genera eccezioni } b = a as B; // if(b != null) { } b = (a is B) ? (B) a : null;
Conversione di tipo
Boxing up cast (conversione implicita)
int k1 = 100; object o = k1; k1 = 200; // Copia!

28
Unboxing down cast (conversione esplicita)

int k2 = (int) o; // k1 = 200, k2 = 100
double d1 = (double) k1; // Ok d1 = k1; // Ok d1 = o; // Non compila! d1 = (double) o; // InvalidCastException d1 = (int) o; // Ok
Conversione di tipo definite dallutente

public static implicit operator typeOut(typeIn obj) public static explicit operator typeOut(typeIn obj) Metodi statici di una classe o di una struttura La keyword implicit indica lutilizzo automatico (cast implicito) Il metodo non deve generare eccezioni La keyword explicit indica la necessit di un cast esplicito Il metodo pu generare eccezioni typeOut il tipo del risultato del cast typeIn il tipo del valore da convertire typeIn o typeOut deve essere il tipo che contiene il metodo
29
Esempio 1 - Digit
Conversioni a string
Conversioni a string (di un Int32): ToString()
int k1 = -1234567891; string str = k1.ToString(); // str == -1234567891

30
ToString(string formatString)
the instance is formatted with the NumberFormatInfo for the current culture k1.ToString(X); // = B669FD2D k1.ToString(C); // = - 1.234.567.891,00 k1.ToString(C0); // = - 1.234.567.891 k1.ToString(N0); // = -1.234.567.891 k1.ToString(E); // = -1,234568E+009
Conversioni a string
Conversioni a string (di un Int32):
String.Format(string format, params object[] args) The format parameter is embedded with zero or more format items of the form, {index[,alignment][:formatString]} int k1 = -1234567891; String.Format({0},k1); // = -1234567891 String.Format({0:X},k1); // = B669FD2D String.Format({0,5:X},k1); // = B669FD2D String.Format({0,10:X},k1); // = B669FD2D String.Format({0,-10:X},k1); // = B669FD2D String.Format({0:N0},k1); // = -1.234.567.891

31
Conversioni da string
Conversioni da string (in un Int32): Int32.Parse(string str)
Int32.Parse(-1234567891); // -1234567891 Int32.Parse(-1.234.567.891); // FormatException Int32.Parse(); // FormatException Int32.Parse(-1234567891999); // OverflowException Int32.Parse(null); // ArgumentNullException

32
Int32.Parse(string str, System.Globalization.NumberStyles style) NumberStyles determines the styles permitted in numeric string arguments that are passed to the Parse methods of the numeric base type classes
Conversioni da string
enumeration NumberStyles None = 0 AllowLeadingWhite = 1 AllowTrailingWhite = 2 AllowLeadingSign = 4 AllowTrailingSign = 8 AllowParentheses = 16 AllowDecimalPoint = 32 AllowThousands = 64 AllowExponent = 128 AllowCurrencySymbol = 256 AllowHexSpecifier = 512 Integer = 7 HexNumber = 515 Number = 111 Float = 167 Currency = 383 Any = 511
The symbols to use for currency symbol, thousands separator, decimal point indicator, and leading sign are specified by NumberFormatInfo The attributes of NumberStyles are set by using the bitwise inclusive OR of the field flags

33
Int32.Parse(-1.234.567.891, System.Globalization.NumberStyles.Number); // ok Int32.Parse(B669FD2D, System.Globalization.NumberStyles.HexNumber); // ok
Conversioni a/da string

Conversioni a string (di un Int32): Convert.ToString(int value, int toBase) toBase = 2, 8, 10, 16
int k1 = -1234567891; Convert.ToString(k1); // -1234567891 Convert.ToString(k1,10); // -1234567891 Convert.ToString(k1,16); // b669fd2d
34
Conversioni da string (in un Int32): Convert.ToInt32(string str, int fromBase) fromBase = 2, 8, 10, 16
Convert.ToInt32(-1234567891); // -1234567891 Convert.ToInt32(-1234567891,10); // -1234567891 Convert.ToInt32(B669FD2D,16); // -1234567891 Convert.ToInt32(0xB669FD2D,16); // -1234567891 Convert.ToInt32(B669FD2D,10); // FormatException
TECNICHE AVANZATE
System.IFormattable
interface IFormattable
+ ToString ( [in] format : System.String , [in] formatProvider : System.IFormatProvider ) : System.String
Provides functionality to format the value of an object into a string representation

NumberFormatInfo interface IFormatProvider DateTimeFormatInfo

35
+ GetFormat ( [in] formatType : System.Type ) : System.Object

CultureInfo
Provides a mechanism for retrieving an object to control formatting

interface ICustomFormatter
+ Format ( [in] format : System.String , [in] arg : System.Object , [in] formatProvider : System.IFormatProvider ) : System.String
Defines a method that supports custom, user-defined formatting of the value of an object
System.Double
ValueType
IComparable
struct Double + MinValue : System.Double + MaxValue : System.Double + Epsilon : System.Double + NegativeInfinity : System.Double + PositiveInfinity : System.Double + NaN : System.Double + ToString ( ) + GetTypeCode ( ) + ToString ( ) + CompareTo ( ) + GetHashCode ( ) + Equals ( ) + ToString ( ) + IsInfinity ( ) + IsPositiveInfinity ( ) + IsNegativeInfinity ( ) + IsNaN ( ) + ToString ( ) + Parse ( ) + Parse ( ) + Parse ( ) + Parse ( ) + TryParse ( )
Follows IEEE 754 specification Supports 0, Infinity, NaN Epsilon represents the smallest positive Double > 0 The TryParse method is like the Parse method, except this method does not throw an exception if the conversion fails
IConvertible IFormattable

36
If the conversion succeeds, the return value is true and the result parameter is set to the outcome of the conversion If the conversion fails, the return value is false and the result parameter is set to zero
System.Enum
ValueType
Enum provides methods to

struct Enum IComparable IConvertible IFormattable # Enum ( ) + ToString ( ) + GetTypeCode ( ) + CompareTo ( ) + GetHashCode ( ) + Equals ( ) + Parse ( ) + GetUnderlyingType ( ) + GetValues ( ) + GetName ( ) + GetNames ( ) + IsDefined ( ) + Format ( ) + ToObject ( )
Compare instances of this class Convert the value of an instance to its string representation Convert the string representation of a number to an instance of this class Create an instance of a specified enumeration and value

37
You can also treat an Enum as a bit field
Esempio 1 - Color
System.DateTime
ValueType
IComparable IConvertible IFormattable
struct DateTime + MinValue : System.DateTime + MaxValue : System.DateTime + property Date : System.DateTime + property Day : System.Int32 + property DayOfWeek : System.DayOfWeek + property DayOfYear : System.Int32 + property Hour : System.Int32 + property Millisecond : System.Int32 + property Minute : System.Int32 + property Month : System.Int32 + property Now : System.DateTime + property UtcNow : System.DateTime + property Second : System.Int32 + property Ticks : System.Int64 + property TimeOfDay : System.TimeSpan + property Today : System.DateTime + property Year : System.Int32
Represents an instant in time, typically expressed as a date and time of day The DateTime value type represents dates and times with values ranging from 12:00:00 midnight, January 1, 0001 Anno Domini (Common Era) to 11:59:59 P.M., December 31, 9999 A.D. (C.E.) Time values are measured in 100ns units called ticks DateTime represents an instant in time, whereas a TimeSpan represents a time interval

38
System.String
interface IEnumerable Object interface ICloneable
+ GetEnumerator ( ) : System.Collections.IEnumerator
+ Clone ( ) : System.Object

39
IComparable
String + Empty : System.String + property Length : System.Int32
IConvertible
An immutable, fixed-length string of Unicode characters A String is called immutable because its value cannot be modified once it has been created Methods that appear to modify a String actually return a new String containing the modification If it is necessary to modify the actual contents of a string-like object, use the System.Text.StringBuilder class
Esempio 1
System.ICloneable
interface ICloneable
+ Clone ( ) : System.Object
Supports cloning, which creates a new instance of a class with the same value as an existing instance
Clone creates a new object that is a copy of the current instance Clone can be implemented either as

40
a shallow copy, only the top-level objects are duplicated, no new instances of any fields are created public object Clone() { return MemberwiseClone(); }
a deep copy, all objects are duplicated
Clone returns a new instance that is of the same type as (or occasionally a derived type of) the current object
System.Collections.IEnumerable
Exposes the enumerator, which supports a simple iteration over a collection
interface IEnumerable
+ GetEnumerator ( ) : System.Collections.IEnumerator
GetEnumerator returns an enumerator that can be used to iterate through a collection

interface IEnumerator + property Current : System.Object

41
+ Reset ( ) + MoveNext ( ) : System.Boolean + get Current ( ) : System.Object
Enumerators only allow reading the data in the collection Enumerators cannot be used to modify the underlying collection
Reset returns the enumerator to its initial state MoveNext moves to the next item in the collection, returning true if the operation was successful false if the enumerator has moved past the last item Current returns the object to which the enumerator currently refers
System.Collections.IEnumerator
Non deve essere implementata direttamente da una classe contenitore Deve essere implementata da una classe separata (eventualmente annidata nella classe contenitore) che fornisce la funzionalit di iterare sulla classe contenitore Tale suddivisione di responsabilit permette di utilizzare contemporaneamente pi enumeratori sulla stessa classe contenitore La classe contenitore deve implementare linterfaccia IEnumerable Se una classe contenitore viene modificata, tutti gli enumeratori ad essa associati vengono invalidati e non possono pi essere utilizzati (InvalidOperationException)

42
IEnumerator enumerator = enumerable.GetEnumerator(); while (enumerator.MoveNext()) { MyType obj = (MyType) enumerator.Current; }

43
foreach (MyType obj in enumerable) { }
public class Contenitore : IEnumerable { public IEnumerator GetEnumerator() { return new Enumeratore(this); } class Enumeratore : IEnumerator { public Enumeratore(Contenitore contenitore) } }

44
Esempio 1 - Contenitore
System.Array
IC lo n e a b le O b je c t IE n u m e ra b le
A rra y
+ + + + + + + + + + + + + + + + + + + + + + + + + p rop e rty p rop e rty p rop e rty p rop e rty p rop e rty p rop e rty Le ngt h : Sys te m .Int 32 R a nk : Sys t e m .Int3 2 Sync R o o t : Sys t e m .O b je c t Is R e a d O nly : Sys te m .B o ole a n Is F ixe d Siz e : Sys te m .B oo le a n Is Sync hro niz e d : Sys t e m .B o o le a n )
int e rfa c e IC o lle c tio n + p ro pe rty C o unt : Sys t e m .Int3 2 + p ro pe rty Sync R oo t : Sys te m .O b je c t + p ro pe rty Is Sync hro niz e d : Sys t e m .B o o le a n

45
+ C o pyT o ( )
G e t E num e ra to r ( C o p yT o ( ) C lo ne ( ) C re a t e Ins ta nc e ( C le a r ( ) G e t V a lue ( ) Se tV a lue ( ) G e t Le ng th ( ) G e t U pp e rB ound ( G e t Lo w e rB ound ( B ina rySe a rc h ( ) Inde xO f ( ) La s tInd e xO f ( ) R e ve rs e ( ) So rt ( ) Init ia liz e ( ) C o p yT o ( ) C re a t e Ins ta nc e ( Copy ( )
int e rfa c e IL is t + p ro pe rty Ite m ( Sys te m .Int 32 ) : Sys te m .O b je c t + p ro pe rty Is R e a d O nly : Sys te m .B o o le a n + p ro pe rty Is F ixe d Siz e : Sys te m .B o ole a n
) )
+ + + + + + +
R e m ove A t R e m ove ( Ins e rt ( ) Inde xO f ( C le a r ( ) C o nta ins ( A dd ( )
( ) ) ) )
System.Array
One-dimensional arrays
int[] a = new int[3]; int[] b = new int[] {3, 4, 5}; int[] c = {3, 4, 5}; // array of references SomeClass[] d = new SomeClass[10]; // array of values (directly in the array) SomeStruct[] e = new SomeStruct[10];
46
System.Array
Multidimensional arrays (jagged)
// array of references to other arrays int[][] a = new int[2][]; // cannot be initialized directly a[0] = new int[] {1, 2, 3}; a[1] = new int[] {4, 5, 6};
47
Multidimensional arrays (rectangular)

// block matrix int[,] a = new int[2, 3]; // can be initialized directly int[,] b = {{1, 2, 3}, {4, 5, 6}}; int[,,] c = new int[2, 4, 2];
System.Array
Jagged (like in Java)
int[][] a = new int[2][]; a[0] = new int[3]; a[1] = new int[4]; int x = a[0][1];
a[0][1] a a[0] a[1]

48
Rectangular (more compact and efficient)

int[,] a = new int[2, 3]; int x = a[0, 1];
a a[0,1]
Delegati ed Eventi
Delegati
Sono oggetti che possono contenere il riferimento (type safe) a un metodo, tramite il quale il metodo pu essere invocato Oggetti funzione (functor) oggetti che si comportano come una funzione (metodo) Simili ai puntatori a funzione del C/C++, ma object-oriented e molto pi potenti Utilizzo standard: funzionalit di callback


2
Elaborazione asincrona Elaborazione cooperativa (il chiamato fornisce una parte del servizio, il chiamante fornisce la parte rimanente es. qsort in C) Gestione degli eventi (chi interessato a un certo evento si registra presso il generatore dellevento, specificando il metodo che gestir levento)
C/C++ PUNTATORI A FUNZIONI
int funX(char c); int funY(char c); int (*g)(char c) = NULL; ... g = cond1 ? funX : funY; oppure: g = cond1 ? &funX : &funY; ... g('H') (*g)('H')

3
C/C++: ARRAY DI PUNTATORI A FUNZIONI
void fun0(char *s); void fun1(char *s); void fun2(char *s); void (*fun[])(char *s) = { fun0, fun1, fun2 }; ... fun[m]("stringa di caratteri"); (*fun[m])("stringa di caratteri");
fun0 fun[0] fun[1] fun[2] fun2 fun1

4
Delegati
Dichiarazione di un nuovo tipo di delegato che pu contenere il riferimento a un metodo che ha un unico argomento intero e restituisce un intero:
delegate int Action(int param);
5
Definizione di un delegato:
Action action;
Inizializzazione di un delegato:
action = new Action(nomeMetodoStatico); action = new Action(obj.nomeMetodo);
Invocazione del metodo referenziato dal delegato:

int k1 = action(10);
Delegati
Esempio
delegate int Action(int param); class Class1 { static void Main(string[] args) { Action action; action = new Action(Raddoppia); Console.WriteLine("Risultato: {0}", action(10)); action = new Action(Dimezza); Console.WriteLine("Risultato: {0}", action(10)); } static int Raddoppia(int x) { return x * 2; } static int Dimezza(int x) Risultato: 20 { return x / 2; } } Risultato: 5

6
Delegati
Esempio
delegate int Action(int param); class Class1 { static void Main(string[] args) { Go(new Action(Raddoppia)); Go(new Action(Dimezza)); } static void Go(Action action) { Console.WriteLine("Risultato: {0}", action(10)); } static int Raddoppia(int x) { return x * 2; } static int Dimezza(int x) Risultato: 20 { return x / 2; } } Risultato: 5

7
Delegati
Esempio
Un delegato pu contenere anche il riferimento a un metodo NON statico in questo caso mantiene un riferimento anche alloggetto su cui invocare il metodo
8
delegate int Action(int param); class Class1 { private int _y; public Class1(int y) { _y = y; } public int Moltiplica(int x) { return x * _y; } public int Dividi(int x) { return x / _y; } }
Delegati
Esempio
static void Main(string[] args) { Action action; Class1 c = new Class1(5); action = new Action(Raddoppia); Console.WriteLine("Risultato: {0}", action = new Action(Dimezza); Console.WriteLine("Risultato: {0}", action = new Action(c.Moltiplica); Console.WriteLine("Risultato: {0}", action = new Action(c.Dividi); Console.WriteLine("Risultato: {0}", }

9
action(10)); action(10)); action(10)); action(10));
Risultato: Risultato: Risultato: Risultato:
20 5 50 2
Delegati
Esempio3.Step1

10
Delegati anonimi Lambda expressions Reflector
Esempio3.Step2
Delegati
Multicasting
Possibilit di creare una lista di metodi che vengono chiamati automaticamente e in sequenza allatto della chiamata del delegato Per aggiungere un metodo alla lista: +=
Action action = new Action(Fun1); action(10) // Fun1(10) action += new Action(Fun2); action(10) // Fun1(10), Fun2(10)

11
Per togliere un metodo dalla lista: -=

action -= new Action(Fun1); action(10) // Fun2(10)
Delegati
Invocation of a delegate instance whose invocation list contains multiple entries proceeds by invoking each of the methods on the invocation list, synchronously, in order Each method so called is passed the same set of arguments as was given to the delegate instance If such a delegate invocation includes reference parameters


12
each method invocation will occur with a reference to the same variable changes to that variable by one method in the invocation list will be visible to methods further down the invocation list
If the delegate invocation includes output parameters or a return value
their final value will come from the invocation of the last delegate in the list
Delegati
Esempio multicasting
delegate string Action(ref string param); class Class1 { static string ToUpper(ref string str) { str = str.ToUpper(); return str; } static string TrimEnd(ref string str) { str = str.TrimEnd(); return str; } static string TrimStart(ref string str) { str = str.TrimStart(); return str; }

13
Delegati
Esempio multicasting
static void Main(string[] args) { string s1 = " abcdefghijk "; Action action = new Action(ToUpper) + new Action(TrimStart) + new Action(TrimEnd); Console.WriteLine("s1a: \"" + action(ref s1) + "\""); Console.WriteLine("s1b: \"" + s1 + "\""); } }

14
s1a: "ABCDEFGHIJK" s1b: "ABCDEFGHIJK"
Delegati
A delegate instance encapsulates one or more methods (with a particular set of arguments and return type), each of which is referred to as a callable entity For static methods, a callable entity consists of just a method For instance methods, a callable entity consists of an instance and a method on that instance An interesting and useful property of a delegate is that it does not know or care about the class of the object that it references Any object will perfectly do; all that matters is that the method's argument types and return type match the delegate's This makes delegates suited for anonymous invocation

15
Delegati
In C#, la dichiarazione di un nuovo tipo di delegato definisce automaticamente una nuova classe derivata dalla classe System.MulticastDelegate
16
System.Object System.Delegate System.MulticastDelegate Action
Pertanto, sulle istanze di Action possibile invocare i metodi definiti a livello di classi di sistema
Delegati
Object ICloneable interface ISerializable
Delegate
+ property Method : System.Reflection.MethodInfo + property Target : System.Object # Delegate ( [in] target : System.Object , [in] method : System.String ) # Delegate ( [in] target : System.Type , [in] method : System.String ) + GetObjectData ( [in] info : System.Runtime.Serialization.SerializationInfo , [in] context : System.... + Clone ( ) : System.Object # RemoveImpl ( [in] d : System.Delegate ) : System.Delegate # CombineImpl ( [in] d : System.Delegate ) : System.Delegate # GetMethodImpl ( ) : System.Reflection.MethodInfo + GetInvocationList ( ) : System.Delegate[] # DynamicInvokeImpl ( [in] args : System.Object[] ) : System.Object + GetHashCode ( ) : System.Int32 + Equals ( [in] obj : System.Object ) : System.Boolean + DynamicInvoke ( [in] args : System.Object[] ) : System.Object + Combine ( [in] a : System.Delegate , [in] b : System.Delegate ) : System.Delegate + Combine ( [in] delegates : System.Delegate[] ) : System.Delegate + Remove ( [in] source : System.Delegate , [in] value : System.Delegate ) : System.Delegate + CreateDelegate ( [in] type : System.Type , [in] target : System.Object , [in] method : System.Str... + CreateDelegate ( [in] type : System.Type , [in] target : System.Object , [in] method : System.Str... + CreateDelegate ( [in] type : System.Type , [in] target : System.Type , [in] method : System.Strin... + CreateDelegate ( [in] type : System.Type , [in] method : System.Reflection.MethodInfo ) : Syste... + get Method ( ) : System.Reflection.MethodInfo + get Target ( ) : System.Object + op_Equality ( [in] d1 : System.Delegate , [in] d2 : System.Delegate ) : System.Boolean + op_Inequality ( [in] d1 : System.Delegate , [in] d2 : System.Delegate ) : System.Boolean + RemoveAll ( [in] source : System.Delegate , [in] value : System.Delegate ) : System.Delegate

17
+ GetObjectData ( )
Delegati
Esempio
Action action = new Action(ToUpper) + new Action(TrimStart) + new Action(TrimEnd); foreach (Action a in action.GetInvocationList()) Console.WriteLine(a.Method.Name); ToUpper TrimStart TrimEnd foreach (Action a in action.GetInvocationList()) Console.WriteLine(a.Method.ToString()); System.String ToUpper(System.String ByRef) System.String TrimStart(System.String ByRef) System.String TrimEnd(System.String ByRef)
18
Delegati
Esempio Boss-Worker
necessario modellare uninterazione tra due componenti

un Worker che effettua unattivit (o lavoro) un Boss che controlla lattivit dei suoi Worker quando il lavoro inizia quando il lavoro in esecuzione quando il lavoro finisce class-based callback relationship interface-based callback relationship delegate-based callback relationship eventi
Ogni Worker deve notificare al proprio Boss:


19
Soluzioni possibili:

A class-based callback relationship: caller

class Worker { private Boss _boss; public void Advise(Boss boss) { _boss = boss; } public void DoWork() { Console.WriteLine("Worker: work started"); if(_boss != null) _boss.WorkStarted(this); Console.WriteLine("Worker: work progressing"); if(_boss != null) _boss.WorkProgressing(this); Console.WriteLine("Worker: work completed"); if(_boss != null) { int grade = _boss.WorkCompleted(this); Console.WriteLine("Worker grade = {0}",grade); } } }

20
A class-based callback relationship: target

class Boss { public void WorkStarted(Worker worker) { // Boss doesn't care } public void WorkProgressing(Worker worker) { // Boss doesn't care } public int WorkCompleted(Worker worker) { Console.WriteLine("It's about time!"); return 2; // Out of 10 } }

21
A class-based callback relationship: registration

class Universe { static void Main() { Worker peter = new Worker(); Boss boss = new Boss(); peter.Advise(boss); peter.DoWork(); } }
Boss + WorkStarted ( [in] worker : Worker ) + WorkProgressing ( [in] worker : Worker ) + WorkCompleted ( [in] worker : Worker ) : int

22
Worker + Advise ( [in] boss : Boss ) + DoWork ( )
- _boss
use
Interface-based callback relationship

Interface-based designs are incrementally better than class-based designs for modeling bi-directional relationships

More flexible than class-based design Does not constrain implementer's choice of base type As with class-based approach, requires callee to conform to/change type hierarchy

23
An interface used for callbacks:

interface IWorkerEvents { void WorkStarted(Worker worker); void WorkProgressing(Worker worker); int WorkCompleted(Worker worker); }
An interface-based callback relationship: caller

class Worker { private IWorkerEvents _target; public void Advise(IWorkerEvents target) { _target = target; } public void DoWork() { Console.WriteLine("Worker: work started"); if(_target != null) _target.WorkStarted(this); Console.WriteLine("Worker: work progressing"); if(_target != null) _target.WorkProgressing(this); Console.WriteLine("Worker: work completed"); if(_target != null) { int grade = _target.WorkCompleted(this); Console.WriteLine("Worker grade = {0}",grade); } } }

24
An interface-based callback relationship: target

class Boss : IWorkerEvents { public void WorkStarted(Worker worker) { // Boss doesn't care } public void WorkProgressing(Worker worker) { // Boss doesn't care } public int WorkCompleted(Worker worker) { Console.WriteLine("It's about time!"); return 4; // Out of 10 } }

25
An interface-based callback relationship
Worker + Advise ( [in] target : IWorkerEvents ) + DoWork ( )
- _target
interface IWorkerEvents + WorkStarted ( [in] worker : Worker ) + WorkProgressing ( [in] worker : Worker ) + WorkCompleted ( [in] worker : Worker ) : int

26
use
Boss + WorkStarted ( [in] worker : Worker ) + WorkProgressing ( [in] worker : Worker ) + WorkCompleted ( [in] worker : Worker ) : int
Pattern OBSERVER
Context A change in one object (the subject) will sometimes require other objects (observers) to be updated This relationship can be explicitly coded in the subject, but this requires knowledge about, how the observers should be updated The result is that the objects become intertwined (closely coupled) and can't easily be reused Solution Create a loosely-bound one-to-many relationship between an object and others that depend on it A change in the object will result in the others receiving a notification, enabling them to update themselves accordingly

27
Pattern OBSERVER
There are two mechanisms which can be used to implement a loose coupling between a subject and its observers Dependency allows an observer to register an interest in ALL aspects of another object

28
the observer then has to sort out what actually changed at runtime so it can do something sensible in response
Events allow an observer to register an interest in a specific aspect of another object (publisher) and even request that a particular message is routed to them
when the publisher triggers an event the routing is automatic
Pattern OBSERVER
29
A delegate-based callback relationship

Un delegato unentit type-safe riconosciuta e gestita dal CLR che si pone tra 1 caller e 0+ call target

Do not require type compatibility like classes/interfaces Enforce only a single method signature (not a name) Act like a tiny interface with one method Facilitate component integration without source code access Support multiple call targets Support asynchronous method invocation

30
A delegate used for callbacks

interface IWorkerEvents { void WorkStarted(Worker worker); void WorkProgressing(Worker worker); int WorkCompleted(Worker worker); }

31
delegate void WorkStarted(Worker worker); delegate void WorkProgressing(Worker worker); delegate int WorkCompleted(Worker worker);
A delegate-based callback relationship: caller

class Worker { public WorkStarted Started; public WorkProgressing Progressing; public WorkCompleted Completed; public void DoWork() { Console.WriteLine("Worker: work started"); if(Started != null) Started(this); Console.WriteLine("Worker: work progressing"); if(Progressing != null) Progressing(this); Console.WriteLine("Worker: work completed"); if(Completed != null) { int grade = Completed(this); Console.WriteLine("Worker grade = {0}",grade); } } }

32
A delegate-based callback relationship: target

class Boss { public int WorkCompleted(Worker worker) { Console.WriteLine("Better..."); return 6; // Out of 10 } }

33
delegate WorkStarted
+ Started
delegate WorkProgressing + Progressing
Worker + DoWork ( ) use
Boss + WorkCompleted ( [in] worker : Worker ) : int

34
delegate WorkCompleted + Completed
+ Started
WorkStarted
Worker + Progressing WorkProgressing + DoWork ( ) use
Boss + WorkCompleted ( [in] worker : Worker ) : int
+ Completed WorkCompleted
A delegate-based callback relationship: registration

class Universe { static void Main() { Worker peter = new Worker(); Boss boss = new Boss(); peter.Completed = new WorkCompleted(boss.WorkCompleted); peter.DoWork(); } }

35
36
Multiple target registration

class Universe { static void WorkerStartedWork(Worker worker) { Console.WriteLine ("Universe notices working starting"); } static int WorkerDoneWorking(Worker worker) { Console.WriteLine ("Universe notices is worker done"); return 7; } static void Main() { } }

37
Multiple target registration

Worker peter = new Worker(); Boss boss = new Boss(); // Istruzioni possibili ma da evitare: peter.Completed = new WorkCompleted(boss.WorkCompleted); peter.Started = new WorkStarted(WorkerStartedWork); peter.Progressing = null; peter.Completed(peter); // Preferred registration syntax: peter.Completed += new WorkCompleted(WorkerDoneWorking); peter.DoWork();

38
A multicast delegate
39
Iterating through registered targets

class Worker { public void DoWork() { // Start and progress with work... Console.WriteLine("Worker: work completed"); if(Completed != null) {
foreach (WorkCompleted wc in Completed.GetInvocationList())

40
{ int grade = wc(this); Console.WriteLine("Worker grade = {0}",grade); } } } }
Dai delegati agli eventi

Using public fields for registration offers too much access Client can overwrite previously registered target(s) Client can invoke target(s)
41
Public registration methods coupled with private delegate field is better, but tedious if done manually event modifier automates support for

public [un]registration and private implementation
An event-based callback relationship: caller

class Worker { public event WorkStarted Started; public event WorkProgressing Progressing; public event WorkCompleted Completed; public void DoWork() { Console.WriteLine("Worker: work started"); if(Started != null) Started(this); Console.WriteLine("Worker: work progressing"); if(Progressing != null) Progressing(this); Console.WriteLine("Worker: work completed"); if(Completed != null) { int grade = Completed(this); Console.WriteLine("Worker grade = {0}",grade); } } }

42
An event-based callback relationship: registration

Worker peter = new Worker(); Boss boss = new Boss(); // Illegal: assignment to event field not supported: peter.Completed = new WorkCompleted(boss.WorkCompleted); peter.Started = new WorkStarted(WorkerStartedWork); peter.Progressing = null; // Illegal: execution of event not supported: peter.Completed(peter); // Registration still supported: peter.Completed += new WorkCompleted(WorkerDoneWorking); peter.DoWork();

43
An event-based callback relationship
delegate WorkStarted
+ Started
event + Progressing delegate WorkProgressing event Worker + DoWork ( ) use Boss + WorkCompleted ( [in] worker : Worker ) : int

44
delegate WorkCompleted
event + Completed
TECNICHE AVANZATE
Customizing event registration

User-defined event registration handlers may be provided One benefit of writing your own registration methods is control Alternative property-like syntax supports user-defined registration handlers Allows you to make registration conditional or otherwise customized Client-side access syntax not affected You must provide storage for registered clients

45
TECNICHE AVANZATE
Customizing event registration

class Worker { public event WorkProgressing Progressing { add { if(DateTime.Now.Hour < 12) { _progressing += value; } else { throw new InvalidOperationException ("Must register before noon."); } } remove { _progressing -= value; } } private WorkProgressing _progressing; }

46
Eventi
Evento: Fatto o avvenimento determinante nei confronti di una situazione oggettiva o soggettiva In programmazione, un evento pu essere scatenato

dallinterazione con lutente (click del mouse, ) dalla logica del programma

47
Event sender loggetto (o la classe) che scatena (raises o triggers) levento (sorgente dellevento) Event receiver loggetto (o la classe) per il quale levento determinante e che quindi desidera essere notificato quando levento si verifica (cliente) Event handler il metodo (dellevent receiver) che viene eseguito allatto della notifica
Eventi
Quando si verifica levento, il sender invia un messaggio di notifica a tutti i receiver in pratica, invoca gli event handler di tutti i receiver In genere, il sender NON conosce n i receiver, n gli handler Il meccanismo che viene utilizzato per collegare sender e receiver/handler il delegato (che permette invocazioni anonime)

48
Dichiarazione di un evento
Un evento incapsula un delegato quindi necessario dichiarare un tipo di delegato prima di poter dichiarare un evento By convention, event delegates in the .NET Framework have two parameters


49
the source that raised the event and the data for the event
Custom event delegates are needed only when an event generates event data Many events, including some user-interface events such as mouse clicks, do not generate event data In such situations, the event delegate provided in the class library for the no-data event, System.EventHandler, is adequate
public delegate void EventHandler( object sender, EventArgs e); System.Object System.Delegate System.MulticastDelegate System.EventHandler La classe System.EventArgs viene utilizzata quando un evento non deve passare informazioni aggiuntive ai propri gestori Se i gestori dellevento hanno bisogno di informazioni aggiuntive, necessario derivare una classe dalla classe EventArgs e aggiungere i dati necessari
50
public event EventHandler Changed; In pratica, Changed un delegato, ma la keyword event ne limita la visibilit e le possibilit di utilizzo Una volta dichiarato, levento pu essere trattato come un delegato di tipo speciale in particolare, pu: essere null se nessun cliente si registrato

51
essere associato a uno o pi metodi da invocare
Invocazione di un evento
Per scatenare un evento opportuno definire un metodo protetto virtuale OnNomeEvento invocare sempre quello
public event EventHandler Changed; protected virtual void OnChanged() { if(Changed != null) Changed(this, EventArgs.Empty); } OnChanged();
52
Limitazione rispetto ai delegati Linvocazione dellevento pu avvenire solo allinterno della classe nella quale levento stato dichiarato (bench levento sia stato dichiarato public)
Agganciarsi a un evento
(hooking up to an event)
Al di fuori della classe in cui levento stato dichiarato, un evento viene visto come un delegato con accessi molto limitati Le sole operazioni effettuabili sono: Aggiungere un nuovo delegato alla lista dei delegati mediante loperatore +=

53
Rimuovere un delegato dalla lista dei delegati mediante loperatore -=
Agganciarsi a un evento
(hooking up to an event)
Per iniziare a ricevere le notifiche di un evento, il cliente deve: Definire il metodo (event handler) che verr invocato allatto della notifica dellevento (con la stessa signature dellevento):
54
void ListChanged(object sender, EventArgs e) { }
Creare un delegato dello stesso tipo dellevento e farlo riferire al metodo:

EventHandler listChangedHandler = new EventHandler(ListChanged);
Aggiungere il delegato alla lista dei delegati associati allevento, utilizzando loperatore +=:
List.Changed += listChangedHandler;
Sganciarsi da un evento
Per smettere di ricevere le notifiche di un evento, il cliente deve: Rimuovere il delegato dalla lista dei delegati associati allevento, utilizzando loperatore -=:
55
List.Changed -= listChangedHandler; Per aggiungere e rimuovere un delegato dalla lista dei delegati associati allevento si pu anche scrivere: List.Changed += new EventHandler(ListChanged); List.Changed -= new EventHandler(ListChanged); List.Changed += ListChanged; List.Changed -= ListChanged; // // C# 2.0 C# 2.0
Eventi
Since += and -= are the only operations that are permitted on an event outside the type that declares the event, external code

can add and remove handlers for an event, but cannot in any other way obtain or modify the underlying list of event handlers

56
Events provide a generally useful way for objects to signal state changes that may be useful to clients of that object Events are an important building block for creating classes that can be reused in a large number of different programs
Metadati e introspezione
Metadata
Metadata is data that describes other data. For example, the definition of a class is metadata
Rumbaugh, J. et al, Object Oriented Modeling and Design [Prentice Hall, 1991]

2
Why Have Metadata?

Provided that a component comes with enough information to be self-describing, the interfaces supported by a component can be dynamically explored
Szyperski, C., Component Software [Addison-Wesley, 1998]

3
C++ Metadata
A C++ header file may be considered metadata Clients can include this file at compile time to use the types it declares Clients then link with the types definition C++ has also added support for RTTI (Run-Time Type Information), a very limited runtime metadata facility

4
Interface Definition Language

C++ headers files are language specific Providing information across different languages is a difficult issue COM and CORBA use the IDL (Interface Definition Language) to provide metadata


5
COM Type Libraries CORBA Interface Repository
COM IDL
import "oaidl.idl"; import "ocidl.idl"; #include "olectl.h" [ object, uuid(29AABB7F-E702-11D2-89CF-004033412CFC), dual, helpstring("IPolyCtl Interface"), pointer_default(unique) ] interface IPolyCtl : IDispatch { [ propget, id(1), helpstring("property Sides") ] HRESULT Sides([out, retval] short *pVal); [ propput, id(1), helpstring("property Sides") ] HRESULT Sides([in] short newVal); };

6
IDL
Reflection
IDLs are an additional requirement for developers to understand Interface Repositories and Type Libraries can be housed in separate files to the type they describe Java/.NET use reflection The metadata is generated from the types definition The metadata is stored with the types definition if you have the definition you have the metadata and vice versa

7
Reflection
Reflection can be used

8
To examine the details of an assembly To instantiate objects and call methods discovered at runtime To create, compile, and execute assemblies on the fly
.NET classes that deal with providing reflection can be found in:

System System.Reflection System.Reflection.Emit
Assemblies, modules and types
Application Domain
Assembly Assembly
9
Module Type
Module Type Type
Module Type Type
System.Type
System.Type is the focal point of reflection

10
All objects and values are instances of types Can discover type of object or value Type t0 = obj.GetType(); Type t1 = "Pippo".GetType(); Can reference type by symbolic name Type t2 = typeof(System.String); Type t3 = Type.GetType("System.String"); Types are themselves instances of type System.Type
There is a single Type object for each type defined in the system
System.Type
11
System.Type
Esempio 5.1
12
System.Type
Some methods:

13
Type[] GetInterfaces(); MemberInfo[] GetMembers(); ConstructorInfo[] GetConstructors(); MethodInfo[] GetMethods(); FieldInfo[] GetFields(); PropertyInfo[] GetProperties(); EventInfo[] GetEvents(); object[] GetCustomAttributes();
Reflection and the CLR type system
14
The reflection object model

GetNestedTypes
Esempio 5.2
15
Esempio
Enumerating all types in an Assembly Use Assembly.Load to load a .NET assembly returns an Assembly Assembly.GetModules returns an array of Module For each Module, call Module.GetTypes returns an array of Type For each Type,
1.
2.
16
3.
4.
Esempio 5.3
Very late binding

Types may be instantiated and/or members accessed in a very late bound manner
Can instantiate type in memory, choosing constructor to call Activator.CreateInstance(type, ) Can invoke methods methodInfo.Invoke() Can invoke property getters and setters propertyInfo.GetValue() propertyInfo.SetValue()

17
Public members always accessible Non-public members accessible if callers hold sufficient permissions
Esempio 5.4
System.Activator
Dynamically create instances Activator.CreateInstance is the late-bound equivalent to operator new

Allocates storage for new type instance Calls specified constructor Returns generic object reference

18
T1 t = (T1) Activator.CreateInstance(typeof(T1)); T1 t = (T1) Activator.CreateInstance(typeof(T1), object[] args);
Esempio 5.5
TECNICHE AVANZATE
Meta-Programming
... the fundamental problem is always the same: preserve information available at compile time for inspection at runtime. Making such information about a system available within that system is called reification. Programming a system to not only use reified information but also to manipulate this information is called meta-programming. meta-programming can be used to dynamically create new classes, insert them into an existing inheritance graph and instantiate them
Szyperski, C., Component Software [Addison-Wesley, 1998]

19
Reificazione: Concretizzazione di unastrazione
TECNICHE AVANZATE
Meta-Programming in .NET
A number of classes function together to achieve this goal in .NET By using the previous objects, and others, you can build an assembly on the fly

20
Reflection.Emit allows you to write out the IL necessary to create and compile the assembly You can then call this assembly from with the program that created it The assembly can be stored to disk so that other programs can use it
TECNICHE AVANZATE
Meta-Programming in .NET
System.Reflection
AssemblyName
Fully describes an assembly's unique identity
System.Reflection.Emit

21
AssemblyBuilder
Defines and represents a dynamic assembly
ModuleBuilder
Defines and represents a module
TypeBuilder
Defines and creates new instances of classes during runtime
MethodBuilder
Defines and represents a method (or constructor) on a dynamic class
ILGenerator
Generates Microsoft intermediate language (MSIL) instructions
TECNICHE AVANZATE
Dynamically Creating a Type
Assembly: MyAssembly Module: MyModule Type: Esempio5.MyType Method: MyMethod WriteLine("Hello World!");
22
Esempio 5.6
Custom Attributes
Are an easy way to add information to the metadata for any application element
Can be applied to an assembly using special syntax
Can be used so that clients can automatically pick up on certain functionality

23
Are visible via reflection
Are supported in any .NET language Are really just common classes that derive from System.Attribute
Can contain methods and properties
Creating Custom Attributes

Declare the attribute class
public class AuthorAttribute : System.Attribute
Declare constructors Declare properties Apply the AttributeUsageAttribute (opzionale) Specifies some of the characteristics of the class

24
The target of the attribute (AttributeTargets) a quali elementi lattributo applicabile Whether or not the attribute can be inherited (Inherited) Whether or not multiple instances of an attribute can exist for an element (AllowMultiple)
Esempio 5.7 AuthorAttribute
Using Custom Attributes

C# uses IDL-like syntax with [ ] prior to the definition of the target Attribute parameters passed

by position or by name
Primo argomento del costruttore

25
[ Author("Bellavia", Contact="giuseppe.bellavia@unibo.it") ]
Nome di una propriet
Esempio 5.7 MyClass
Accessing the Custom Attributes

Once the custom attributes have been created, you use Reflection in order to read them You can get a list of custom attributes by calling the GetCustomAttributes method
object[] X.GetCustomAttributes(inherit); object[] X.GetCustomAttributes(attributeType,inherit);

26
inherit specifies whether to search this member's inheritance chain to find the attributes X
unistanza di Assembly, Module MemberInfo ParameterInfo
Esempio 5.7
Garbage Collector
Utilizzo di un oggetto
In un ambiente object-oriented, ogni oggetto che deve essere utilizzato dal programma

descritto da un tipo Ha bisogno di unarea di memoria dove memorizzare il suo stato Allocare memoria per loggetto in seguito a una new (istruzione newobj di IL) Inizializzare la memoria per rendere utilizzabile loggetto valori di default + costruttore Usare loggetto Eseguire un clean up dello stato delloggetto, se necessario Finalize (distruttore in C# e C++), Dispose, Close Liberare la memoria responsabilit del Garbage Collector (GC)

2
Passi per utilizzare un oggetto di tipo riferimento:
Ciclo di vita di un oggetto
Allocazione della memoria

In fase di inizializzazione di un processo, il CLR

Riserva una regione contigua di spazio di indirizzamento managed heap Memorizza in un puntatore (NextObjPtr) lindirizzo di partenza della regione

4
NextObjPtr

Quando deve eseguire una newobj, il CLR
Calcola la dimensione in byte delloggetto e aggiunge alloggetto due campi di 32 (o 64) bit
Un puntatore alla tabella dei metodi Un campo SyncBlockIndex

5
Controlla che ci sia spazio sufficiente a partire da NextObjPtr in caso di spazio insufficiente:
garbage collection OutOfMemoryException
thisObjPtr = NextObjPtr; NextObjPtr += sizeof(oggetto); Invoca il costruttore delloggetto (this thisObjPtr) Restituisce il riferimento alloggetto

6
NextObjPtr
Tecnica di allocazione completamente diversa da quella del C/C++ Oggetti vivi Oggetti non raggiungibili Spazio libero
Garbage Collector
Verifica se nellheap esistono oggetti non pi utilizzati dallapplicazione

7
Ogni applicazione ha un insieme di radici (root) Ogni radice un puntatore che contiene lindirizzo di un oggetto di tipo riferimento oppure vale null Le radici sono:
Variabili globali e field statici di tipo riferimento Variabili locali o argomenti attuali di tipo riferimento sugli stack dei vari thread Registri della CPU che contengono lindirizzo di un oggetto di tipo riferimento
Gli oggetti vivi sono quelli raggiungibili direttamente o indirettamente dalle radici Gli oggetti garbage sono quelli NON raggiungibili direttamente o indirettamente dalle radici
Garbage Collector
Quando parte, il GC ipotizza che tutti gli oggetti siano garbage Quindi, scandisce le radici e per ogni radice marca
8
Leventuale oggetto referenziato e Tutti gli oggetti a loro volta raggiungibili a partire da tale oggetto
Se durante la scansione incontra un oggetto gi marcato in precedenza, lo salta

Sia per motivi di prestazioni Sia per gestire correttamente riferimenti ciclici
Una volta terminata la scansione delle radici, tutti gli oggetti NON marcati sono non raggiungibili e quindi garbage
Garbage Collector Fase 1: Mark
NextObjPtr
Root set
Oggetti vivi Oggetti non raggiungibili Spazio libero

9
Garbage Collector
Rilascia la memoria usata dagli oggetti non raggiungibili Compatta la memoria ancora in uso, modificando nello stesso tempo tutti i riferimenti agli oggetti spostati! Unifica la memoria disponibile, aggiornando il valore di NextObjPtr Tutte le operazioni che il GC effettua sono possibili in quanto

10
Il tipo di un oggetto sempre noto possibile utilizzare i metadati per determinare quali field delloggetto fanno riferimento ad altri oggetti
Garbage Collector Fase 2: Compact
Spazio recuperato NextObjPtr
Root set
Oggetti vivi Oggetti non raggiungibili Spazio libero

11
Finalization
Non responsabilit del GC, ma del programmatore Se un oggetto contiene esclusivamente

12
tipi valore e/o riferimenti a oggetti managed
(maggior parte dei casi), non necessario eseguire alcun codice particolare Se un oggetto contiene almeno un riferimento a un oggetto unmanaged (in genere, una risorsa del S.O.)
file, connessione a database, socket, mutex, bitmap,
necessario eseguire del codice per rilasciare la risorsa, prima della deallocazione delloggetto
Finalization
Ad esempio, un oggetto di tipo System.IO.FileStream

13
Prima deve aprire un file e memorizzare in un suo field lhandle del file (una risorsa di S.O. unmanaged) Quindi usa tale handle nei metodi Read e Write Infine, deve rilasciare lhandle nel metodo Finalize
In C#

NON possibile definire il metodo Finalize necessario definire un distruttore (sintassi C++)
Finalization
public class OSHandle { // Field contenente lhandle della risorsa unmanaged private readonly IntPtr _handle; // Propriet che restituisce il valore dellhandle public IntPtr Handle { get { return _handle; } } public OSHandle(IntPtr handle) { _handle = handle; } OSHandle() { CloseHandle(_handle); } [System.Runtime.InteropServices.DllImport(Kernel32)] private extern static bool CloseHandle(IntPtr handle); }
14
Finalization
Il compilatore C# trasforma il codice del distruttore
OSHandle() { CloseHandle(_handle); }

15
nel seguente codice (ovviamente in IL):

protected override void Finalize() { try { CloseHandle(_handle); } finally { base.Finalize(); } }
Finalization
Il metodo Finalize dovrebbe essere utilizzato solo per rilasciare risorse unmanaged che appartengono alloggetto su cui eseguire il metodo Nel metodo Finalize si dovrebbe evitare di accedere ad altri oggetti managed

16
Potrei cercare di accedere a un oggetto sul quale il GC ha gi invocato il corrispondente metodo Finalize e che quindi potrebbe essere in uno stato non ben definito
Tutti i metodi Finalize vengono eseguiti in un thread dedicato (diverso da quello del GC) pertanto, nel codice non si devono fare ipotesi sul thread in esecuzione
Il pattern Dispose
Linvocazione del metodo Finalize non avviene in modo deterministico Inoltre, non essendo un metodo pubblico, il metodo Finalize non pu essere invocato direttamente Nel caso di utilizzo di risorse che devono essere rilasciate appena termina il loro uso, questa situazione problematica Si pensi a file aperti o a connessioni a database che vengono chiusi solo quando il GC invoca il corrispondente metodo Finalize In questi casi, di fondamentale importanza rilasciare (Dispose) o chiudere (Close) la risorsa in modo deterministico

17
Il pattern Dispose
I tipi che vogliono offrire questa funzionalit devono implementare il pattern Dispose Il pattern Dispose fissa le convenzioni da seguire quando si vuole definire un tipo in grado di offrire un servizio di clean up esplicito ai suoi utilizzatori Innanzi tutto, il tipo deve implementare linterfaccia IDisposable
public interface IDisposable { void Dispose(); }
18
Il pattern Dispose
public class MyClass : IDisposable { // Riferimenti a risorse unmanaged // Riferimenti a risorse managed // che contengono riferimenti a risorse unmanaged // e che quindi implementano IDisposable Invocazione NON // Costruttore/i deterministica ~MyClass() { Dispose(false); }

19
Il pattern Dispose
// Metodo da invocare per un rilascio deterministico public void Dispose() Invocazione { deterministica Dispose(true); // Take yourself off of the Finalization queue to prevent // finalization code for this object from executing a second time GC.SuppressFinalize(this); } // Metodo alternativo (opzionale) per una chiusura deterministica public void Close() { Dispose(); }

20
Il pattern Dispose
// Track whether Dispose has been called private bool _disposed = false; protected virtual void Dispose(bool disposing) { // Syncronize threads calling Dispose/Close simultaneously lock (this) { if(!_disposed) // Check to see if Dispose has already been called { if(disposing) { // Dispose managed resources } // Dispose unmanaged resources _disposed = true; } } }

21
Il pattern Dispose
Dispose(bool disposing) executes in two distinct scenarios:
if disposing == true, the method has been called directly or indirectly by a user's code Managed and unmanaged resources can be disposed if disposing == false, the method has been called by the runtime from inside the finalizer and you should not reference other objects Only unmanaged resources can be disposed

22
if(disposing) { // Dispose managed resources } // Dispose unmanaged resources
Il pattern Dispose
// Allow your Dispose method to be called multiple times, // but throw an exception if the object has been disposed // Whenever you do something with this class, // check to see if it has been disposed public void DoSomething() { if(_disposed) throw new ObjectDisposedException(); }

23
Il pattern Dispose
in una classe derivata
private bool _disposed = false; protected override void Dispose(bool disposing) { lock (this) { if(!_disposed) { try { if(disposing) { // Dispose managed resources } // Dispose unmanaged resources _disposed = true; } finally { base.Dispose(disposing); } } } }

24
Il pattern Dispose
dal lato del cliente senza using
Byte[] bytesToWrite = new Byte[] {1,2,3,4,5}; FileStream fs = null; try { fs = new FileStream(Temp.dat, FileMode.Create); fs.Write(bytesToWrite, 0, bytesToWrite.Length); } finally { if(fs != null) fs.Close(); }

25
Il pattern Dispose
dal lato del cliente con using
Byte[] bytesToWrite = new Byte[] {1,2,3,4,5}; using (FileStream fs = new FileStream(Temp.dat, FileMode.Create)) { fs.Write(bytesToWrite, 0, bytesToWrite.Length); }

26
Alluscita del blocco using, viene sempre invocato automaticamente il metodo Dispose Il tipo della variabile definita nella parte iniziale di using deve implementare linterfaccia IDisposable
Interfaccia utente
System.Windows.Forms
The System.Windows.Forms namespace contains classes for creating Windows-based applications The classes can be grouped into the following categories:

2
Form, Control, and UserControl Controls Components Common Dialog Boxes
System.Windows.Forms
Elements of a Windows Application

Message Pump
Idle Processing
Windows/Dialog Boxes
Form

4
ZZZ
Message Handling / Application Lifetime
System.Windows.Forms. Application
Menus
MenuItem MainMenu ContextMenu
Controls
Button ComboBox ListBox TextBox DataGrid Etc
Spy++
HelloWorld Windows Application

using System; using System.Windows.Forms; namespace HelloWorld { static class Program { [STAThread] // COM threading model static void Main() { Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new HelloWorldForm()); } } }

5
HelloWorld Windows Application

namespace HelloWorld { public partial class HelloWorldForm : Form { public HelloWorldForm() { InitializeComponent(); } protected override void OnPaint(PaintEventArgs e) { base.OnPaint(e); e.Graphics.DrawString("Hello World!", new Font("Arial",36), Brushes.Blue, 10, 100); } } }

6
Sostituire con Label
Creating Windows Applications

Typical windows-application design
One or more classes derived from System.Windows.Form
Derived classes
7
Affect instance appearance and behavior by setting properties Create objects to implement GUI controls
Buttons, text boxes, menus, timers, custom controls, etc.
Add controls to their UI Implement methods to handle GUI events

Buttons clicks, menu selections, mouse movements, timer events, etc. Default behavior implemented by base classes
Creating Windows Applications

Typical windows-application threading
A single thread dedicated to UI

Runs the message pump Can do other things, but blocks only briefly (or never)

8
Background threads used for lengthy non-UI functionality
Typical windows-applications development
Design UI with VisualStudio .NET

Possible to do anything directly via code
Also use classes in System.Drawing namespace
System.Drawing namespace
Full of types used heavily in windows applications Implements basic graphic objects

9
Classes: Graphics, Font, Brush, Pen, Icon, Bitmap, ... Instance Creators: Brushes, Pens, SystemBrushes, SystemColors, SystemIcons, Cursors Structures: Point, Size, Rectangle, Color, ... Important class that represents a drawing surface Can be in-memory, form-based, or HDC-based Used by forms applications to draw and paint on controls
DrawString(), DrawImage(), FillEllipse(), FillRectangle(), ...
System.Drawing.Graphics

System.Windows.Forms.Application
Non-instantiable class with public static methods and properties Used to handle windows-application infrastructure
10
Message pump methods

Run(Form form) Exit() - Informs all message pumps that they must terminate, and then closes all application forms after the messages have been processed
Application level events

Idle, ApplicationExit
Controls
A control is a component that provides (or enables) user-interface (UI) capabilities The .NET Framework provides two base classes for controls:

11
System.Windows.Forms.Control
for client-side Windows Forms controls
System.Web.UI.Control
for ASP.NET server controls
All controls in the .NET Framework class library derive directly or indirectly from these two classes
Controls
The System.Windows.Forms namespace provides a variety of control classes that allow you to create rich user interfaces Some controls are designed for data entry

12
TextBox, ComboBox, Label, ListView,
Other controls display application data
The namespace also provides controls for invoking commands within the application
Button, ToolBar,
System.Windows.Forms.Control Base-class for all controls/forms in managed code

13
Provides the base functionality for all controls that are displayed on a Form Derives from Component Wraps an underlying OS window handle Properties for modifying settings of an instance
Size, BackColor, ContextMenu, ...
Implements many

Methods for performing actions on an instance

Show(), Hide(), Invalidate(), ...
Events for external registration for event notification

Click, DragDrop, ControlAdded, ...
Instances of Control can contain child controls
System.Windows.Forms.Control Derived classes override and specialize functionality
Specialized methods, properties, and events

TextBox PasswordChar, Undo(), Copy() Button Image, PerformClick()

14
The Form class is derived from Control
To create a custom control that is a composite of other controls, use the UserControl class
System.Windows.Forms.Form
A specialized derivation of Control used to implement a top-level window or dialog Gains much of its functionality from base classes Specialized to


15
Contain a main menu Contain a title-bar, system menu, minimize/maximize Implement MDI - Multiple Document Interface Manage dialog buttons ... Windows Dialog boxes
Your applications derive from Form to create

Using Forms
Create a Form-derived class
class BlueForm : Form { public BlueForm() { BackColor = Color.Blue; } }

16
1. Start message loop and display form

Application.Run(new BlueForm());
2. Show the derived form (modeless)

Form form = new BlueForm(); form.Show(); // Display on current // threads message loop
3. Show the derived form as a dialog (modal)

Form form = new BlueForm(); form.ShowDialog(); // Display on current // threads message loop
Using Forms
In the types constructor

17
Set properties Create child controls Use the Controls property to add controls to the form Setup the forms menu OnFormClosing(), OnPaint(), OnMouseMove(), ... Do not override when default functionality is ok (usually the case) When overriding a virtual method, usually call the baseimplementation of the method
protected override void OnPaint(PaintEventArgs e) { base.OnPaint(e); // Do some work }
Override virtual methods for handling GUI

Multiple Document Interface

Nel costruttore della MainForm:
IsMdiContainer = true; Form childForm = new ChildForm(); childForm.MdiParent = mainForm; childForm.Show();
Per aggiungere una ChildForm:

18
Using Controls
Create the control
Button ctrl = new Button(); // Create a button
Set properties
19
ctrl.Text = "A Button"; // set its text ctrl.Location = new Point(10, 10); // and location
Add the control to your forms Controls collection

myForm.Controls.Add(ctrl); // Add the control to form
Define event handler

private void ButtonClicked(object sender, EventArgs e) { MessageBox.Show("The button was clicked!"); }
Register for event notification

// Register ButtonClicked as an event handler ctrl.Click += new EventHandler(ButtonClicked);
Common Dialog Boxes

Common dialog boxes can be used to give your application a consistent user interface when performing tasks such as opening and saving files, manipulating the font or text color, or printing
The OpenFileDialog and SaveFileDialog classes provide the functionality to display a dialog box that allows the user to browse to and enter the name of a file to open or save The FontDialog class displays a dialog box to change elements of the Font object used by your application The PageSetupDialog, PrintPreviewDialog, and PrintDialog classes display dialog boxes that allow the user to control aspects of printing documents

20
In addition, the System.Windows.Forms namespace provides the MessageBox class for displaying a message box that can display and retrieve data from the user
Components
In programming, the term component is generally used for an object that is reusable and can interact with other objects A .NET Framework Component satisfies those general requirements and additionally provides features such as


21
Control over unmanaged resources Design-time support A component can be used in a rapid application development (RAD) environment A component can be added to the toolbox of Visual Studio .NET, can be dragged and dropped onto a form, and can be manipulated on a design surface Note that base design-time support is built into the .NET Framework; a component developer does not have to do any additional work to take advantage of the base design-time functionality
Components
The System.Windows.Forms namespace provides classes that do not derive from the Control class but still provide visual features to a Windows-based application The ToolTip and ErrorProvider classes provide information to the user The Menu, MenuItem, and ContextMenu classes provide the ability display menus to the user to invoke commands within an application The Help and HelpProvider classes enable you to display help information to the user of your applications

22
Working with Menus

MainMenu, ContextMenu, and MenuItem are derived from Menu Menu includes a collection of MenuItems
23
Menu 1 * * MainMenu ContextMenu MenuItem Item [] 1 1 Parent 1 MenuItems
Menu.MenuItemCollection
Working with Menus

Create a MainMenu (or ContextMenu)
MainMenu mainMenu = new MainMenu();
Add MenuItems to the MainMenu

24
MenuItem menuItem1 = new MenuItem("&File"); mainMenu.MenuItems.Add(menuItem1);
Add sub-MenuItems
MenuItem menuItem2 = new MenuItem("E&xit"); menuItem1.MenuItems.Add(menuItem2);
Set Forms Menu property to the instance of the MainMenu

myForm.Menu = mainMenu;
Working with Menus

Define event handlers
private void ExitHandler(object sender, EventArgs e) { Close(); }

25
Register event handlers

menuItem2.Click += new EventHandler(ExitHandler);
Principi e concetti object-oriented
Dal caos iniziale

Data Data
Variabili globali
Code Code
Data
Programmazione strutturata
Goto
Code
Data
Code
Dal caos iniziale

Fortran (versione iniziale) Caos nel flusso di controllo
IF(espressione logica) GOTO 10 IF(espressione logica) 10,20 IF(espressione aritmetica) 10,20,30
Caos nellaccesso ai dati

Istruzione COMMON: REAL V1(10,10), V2(10,10) LOGICAL V3 INTEGER V4 COMMON /NOME/ Vl, V2, V3, V4
C/C++ Uso indiscriminato delle variabili globali
alla programmazione strutturata

Nel 1966, Bhm e Jacopini dimostrano che qualsiasi programma che utilizza istruzioni GOTO pu essere riscritto senza GOTO, a patto di avere a disposizione tre tipi di strutture di controllo: sequenza, ripetizione e alternativa Nel 1968, Dijkstra discute in modo approfondito gli effetti deleteri del GOTO sulla qualit del software, e in particolare sulla sua leggibilit e modificabilit
alla programmazione basata sugli oggetti

ADT (Abstract Data Type) dati + codice che opera sui dati interfaccia (visibile) + implementazione (nascosta) Lo stato di un oggetto accessibile solo mediante linterfaccia del suo ADT Information hiding il principio teorico Incapsulamento la tecnica utilizzata
Data Code
Tipo di dato astratto

Per definire un ADT, occorre definire
uninterfaccia (interface):
un insieme di operazioni pubbliche applicabili ai singoli oggetti di quel tipo
Per implementare un ADT, occorre definire

una classe (class) che implementa linterfaccia dellADT:
un insieme di attributi privati (implementazione della struttura dati specifica) un insieme di metodi pubblici (implementazione dellinterfaccia) e di metodi privati che accedono in esclusiva a tali attributi
Information hiding Incapsulamento

Un ADT nasconde ai suoi utilizzatori (clienti) tutti i dettagli
della sua struttura interna e del suo funzionamento interno
Obiettivo
Nascondendo le scelte progettuali (spesso soggette a cambiamenti), si proteggono le altre parti del programma (i clienti dellADT) da eventuali cambiamenti di tali scelte
Vantaggi
Minimizzazione delle modifiche da fare durante le fasi di sviluppo e di manutenzione Aumento della possibilit di riutilizzo
Tecnica applicabile a tutti i livelli

Singoli attributi membro di una classe Singoli componenti del sistema
7 Ingegneria del Software T
ADT Lista di interi

Interfaccia:
Add(int item) Insert(int index, int item) Remove(int item) RemoveAt(int index)
1 2 3
Implementazione:
Array Linked list
1 2 2 3
3 8 Ingegneria del Software T
ADT Lista di interi

Cliente
IList
Code Data Code

2
Data
ArrayList
lista
Data
lista
Data
1
lista
lista
Abstract Code
Static Data
Code
ADT Lista di interi

Cliente
IList
Abstract Code
ArrayList LinkedList
Data
Static Data
Static Data
Data
Data
Data
10
4 at sil
Code
Code
3 at sil
1 at sil 2 at sil
Oggetti & classi

Ogni oggetto:
identificabile in modo univoco (ha una sua identit) ha un insieme di attributi ha uno stato (insieme dei valori associati ai suoi attributi) ha un insieme di operazioni
che operano sul suo stato che forniscono servizi ad altri oggetti
ha un comportamento interagisce con altri oggetti
11
Oggetti & classi

Gli oggetti sono raggruppabili in classi Ogni classe descrive oggetti con caratteristiche comuni, cio:
con gli stessi attributi con le stesse operazioni (lo stesso comportamento)
Compile time, ogni classe definisce limplementazione di un tipo di dato astratto Run time, ogni oggetto unistanza di una classe (traduzione comune anche se impropria del termine instance) Un'istanza un particolare oggetto di una determinata classe e quindi di un particolare tipo Ogni istanza separata dalle altre, ma condivide le sue caratteristiche generali con gli altri oggetti della stessa classe
12
Notazione UML
Una classe si rappresenta come un rettangolo diviso in 1 o 3 sezioni
attore Esaminando matricola cognome nome GetMatricola() GetCognomeNome() EffettuaEsame() Stereotipo
Nome della classe
Attributi
Operazioni
13
Notazione UML
La prima sezione contiene
il nome della classe (in grassetto + in corsivo se astratta)
attore Esaminando matricola cognome nome GetMatricola() GetCognomeNome() EffettuaEsame()
pu contenere
lo stereotipo della classe (ad esempio, controllore, attore, evento, tabella, ecc.) il nome del pacchetto (package, namespace ad esempio, Quizzer::Esaminando)
La seconda sezione contiene

gli attributi
La terza sezione contiene

le operazioni (in corsivo se astratte)
Notazione UML
interface interface
IStudente GetMatricola() GetCognomeNome()

IEsaminando EffettuaEsame()
attore Esaminando matricola cognome nome GetMatricola() GetCognomeNome() EffettuaEsame() 15 Ingegneria del Software T
Notazione UML
attore Esaminando IStudente matricola cognome nome GetMatricola() GetCognomeNome() EffettuaEsame()
IEsaminando
16
Notazione UML
ArrayList
lista1:ArrayList
instanceOf
:Arra yList
lis ta1
17
alla programmazione orientata agli oggetti

Le classi possono essere organizzate in una gerarchia di generalizzazione o di ereditariet che mostra la relazione tra classi di oggetti generiche e classi di oggetti pi specifiche Gli oggetti della sottoclasse devono essere in grado di esibire tutti i comportamenti e le propriet esibiti dagli oggetti appartenenti alla superclasse, in modo tale da poter essere "sostituiti" liberamente a questi ultimi (principio di sostituibilit di Liskov) La sottoclasse pu
esibire caratteristiche aggiuntive rispetto alla superclasse eseguire in maniera differente alcune delle funzionalit della superclasse, a patto che questa differenza non sia osservabile dall'esterno
alla programmazione orientata agli oggetti

Ereditariet
Attributi e operazioni comuni devono essere specificati una volta sola Attributi e operazioni specifici vengono aggiunti e/o ridefiniti Obiettivo Semplificare la definizione e la realizzazione di tipi di dato simili Permette di esprimere esplicitamente le caratteristiche comuni, sino dalle prime attivit dellanalisi
19
Ereditariet (inheritance)
Model inheritance
Subtype inheritance Extension inheritance Restriction inheritance View inheritance
reflecting "is-a" relations between abstractions in the model
Software inheritance
Reification inheritance Structure inheritance Implementation inheritance Facility inheritance
Constant inheritance Machine inheritance expressing relations within the software itself rather than in the model
Variation inheritance
Functional variation inheritance Type variation inheritance Uneffecting inheritance
a special case that may pertain either to the software or to the model
Ereditariet
Ereditariet di interfaccia o subtyping (ed ereditariet di estensione)
meccanismo di compatibilit fra tipi: una sottoclasse un sottotipo compatibile con tutti i tipi definiti lungo la sua catena ereditaria (relazione IsA) consente il polimorfismo per inclusione
Ereditariet di realizzazione (o di implementazione) o subclassing

meccanismo di riuso: si riutilizza il codice definito nelle superclassi ammessa in C++, non ammessa in Java e .NET
21
Ereditariet (di interfaccia)

Persona
Docente
Studente
Un Docente una Persona

un Docente pu essere utilizzato come una Persona
Uno Studente una Persona

uno Studente pu essere utilizzato come una Persona
Non detto che una Persona sia un Docente o uno Studente E se una Persona sia un Docente, sia uno Studente?
Ereditariet di realizzazione
Spesso una classe ha bisogno di utilizzare i servizi di unaltra classe Ad esempio, la classe Finestra ha bisogno di utilizzare la classe Rettangolo per
memorizzare posizione e dimensione fare calcoli di sovrapposizione con altre finestre ...
Potrei definire Finestra come sottoclasse di Rettangolo (ma una Finestra NON un Rettangolo)
Finestra eredita e quindi ha accesso diretto a dati e operazioni (public e protected) di Rettangolo i clienti della classe Finestra NON hanno accesso a dati e operazioni (anche se public) della classe Rettangolo
Ereditariet di realizzazione
In C++:
public class Finestra : private Rettangolo
Retta ngolo
La definizione statica (compile-time) Limplementazione della sottoclasse facile da modificare, pu definire i propri metodi e continuare a usare quelli della superclasse La superclasse definisce parte della rappresentazione fisica della sottoclasse, legando a s la sottoclasse, rompendo lincapsulamento (Finestra vede i membri protected di Rettangolo) e rendendo pi difficile il riuso della sottoclasse
Fine stra
Composizione e delega
Esiste unalternativa pi interessante: inserire un Rettangolo nella struttura dati di una Finestra: una Finestra contiene un Rettangolo (una Finestra composta, tra le altre cose, da un Rettangolo) Una Finestra ha accesso indiretto alle operazioni pubbliche di un Rettangolo (una Finestra delega al Rettangolo lesecuzione di alcuni compiti) Le interfacce delle classi restano indipendenti
Retta ngolo
Fine stra
25
Composizione e delega
Lassociazione tra Finestra e Rettangolo pu avvenire dinamicamente (run-time) Maggiore flessibilit ed estendibilit!
Retta ngolo Fine stra
Figura
Cerc hio
Quindi
se e solo se vale la relazione IsA, usare lereditariet altrimenti, usare la composizione
Polimorfismo
Capacit
della stessa cosa di apparire in forme diverse in contesti diversi di cose diverse di apparire sotto la stessa forma in un determinato contesto
27
Polimorfismo
Classificazione Cardelli-Wegner
Programmazione object-oriented
Per inclusione Universale Parametrico Polimorfismo Overloading Ad hoc Coercion
Programmazione generica
5 + 10 5.2 + 11.7
5 + 11.7
28
Polimorfismo (per inclusione)

Overriding (ridefinizione) dei metodi
Definizione di un metodo astratto (sicuro) Ridefinizione di un metodo concreto (meno sicuro)
Binding dinamico (o late-binding)
29
Ereditariet
Ereditariet semplice ogni classe della gerarchia deriva
da una e una sola superclasse (Java, .NET) al pi da una superclasse (C++) la struttura che si ottiene sempre un albero
Ereditariet multipla almeno una classe della gerarchia deriva da 2+ superclassi (possibile in C++) Se esistono antenati comuni
la struttura che si ottiene un reticolo si hanno conflitti di nome la gestione pu diventare molto complessa
30
Ereditariet multipla
Tra due o pi classi di una gerarchia possono esistere dei vincoli {overlapping} o {disjoin}
Veicolo {overlapping} {disjoint}
VeicoloTerrestre
VeicoloAcquatico
VeicoloMilitare
VeicoloCivile
CarroArmato
Taxi
Corazzata
BarcaAVela
Un reticolo di veicoli
31
Ereditariet multipla
Veicolo OggettoMilitare
OggettoCivile VeicoloTerrestre VeicoloAcquatico
CarroArmato
Taxi
Corazzata
BarcaAVela
Una gerarchia multipla di veicoli, senza antenati ripetuti
32
Regole di naming (.NET)

I nomi delle classi devono
iniziare con una lettera maiuscola indicare al singolare un oggetto della classe, oppure indicare al plurale gli oggetti contenuti nella classe (se la classe una classe contenitore)
Esempi
Docente Docenti (contiene una collezione di docenti) CorsoDiStudio CorsiDiStudio AttivitaFormativa AttivitFormativa accettato in C#

Ingegneria Tutte

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Ingegneria Tutte

Uploaded by

Copyright:

Available Formats

Ingegneria del Software T

Evoluzione dello sviluppo del software

sistemi software di grandi dimensioni

Evoluzione dello sviluppo del software

Ingegneria del Software T

Evoluzione dello sviluppo del software

Crisi del software

Ingegneria del Software T

Evoluzione dello sviluppo del software

Ingegneria del Software T

Evoluzione dello sviluppo del software

Ingegneria del Software T

Evoluzione dello sviluppo del software

Ingegneria del Software T

Ingegneria del Software

Ingegneria del Software T

Pu fare parte di un sistema di elaborazione che comprende

Ingegneria del Software T

Non si consuma Struttura Caratteristiche

Ingegneria del Software T

Sviluppo del software

Ingegneria del Software T

Principali cause di fallimento

Ingegneria del Software T

Principali cause di fallimento

Ingegneria del Software T

Obiettivo dellingegneria del software

Ingegneria del Software T

Ingegneria del Software T

Principi usati nell'ingegneria tradizionale per affrontare la complessit

Ingegneria del Software T

Principi usati nell'ingegneria tradizionale per affrontare la complessit

Ingegneria del Software T

Processo di sviluppo del software

Ingegneria del Software T

Processo di sviluppo del software

Ingegneria del Software T

Fasi del processo di sviluppo del software

Processo di sviluppo del software

Ingegneria del Software T

Processo di sviluppo del software

Ingegneria del Software T

Processo di sviluppo del software

Analisi dei requisiti

Ingegneria del Software T

Processo di sviluppo del software

Analisi dei requisiti

Requisiti non funzionali:

Ingegneria del Software T

Processo di sviluppo del software

Analisi dei requisiti

Ingegneria del Software T

Processo di sviluppo del software

Specifica dei requisiti

Il risultato principale il Documento di Specifica dei Requisiti (DSR)

Ingegneria del Software T

Processo di sviluppo del software

Specifica dei requisiti

Ingegneria del Software T

Processo di sviluppo del software

Specifica dei requisiti

Stiamo realizzando il prodotto desiderato?

Processo di sviluppo del software