Ingegneria tutte

7/8/2019 Ingegneria tutte

http://slidepdf.com/reader/full/ingegneria-tutte 1/797

Ingegneria del Software T

Introduzione



Argomenti Evoluzione dello sviluppo del software Prodotto software Processo di sviluppo del software

vModelliPrototipi

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 applicazioniconsiderate in precedenza non realizzabili


Si rende necessario Progettare Realizzare Effettuare la manutenzione (manutenere )

sistemi software di grandi dimensioni



Evoluzione dello

sviluppo del software Nel settore dell’hardware,

netto, progressivo: aumento delle prestazioni riduzione dei costi




Evoluzione dello

sviluppo del software Nel settore del software:

Pochissimi i progetti terminati nei tempi stabiliti Rari i progetti che non sfondano il budget Sistemi eneralmente ieni di difetti


Sistemi così rigidamente strutturati che è

praticamente impossibile apportare significativicambiamenti senza doverli riprogettare totalmente

“Crisi del software ”



Evoluzione dello

sviluppo del software

Anni Base tecnologica Problema Rivoluzione software

1950primi calcolatori inserie

produttività Assembler

calcolatori mono- linguaggi di alto livello


utente in batch (Fortran, Cobol, Algol)

1970tecnologia deicompilatori

complessitàprogrammazionestrutturata (Pascal, C)

1980calcolatori sempre

più potenticomplessità

programmazione modulare

ADT (Ada, Modula-2)

1990workstation, reti,interfaccegrafiche,...

enormeaumentodellacomplessità

programmazione orientataagli oggetti (Smalltalk,C++, Eiffel, CLOS, ObjectPascal, Java, C#, …)



Evoluzione dello

sviluppo del software Da lavoro individuale e creativo

(software come arte) A lavoro di piccoli gruppi specializzati


Sino a lavoro di gruppi anche di grossedimensioni in cui è necessaria un’opera di

pianificazione e coordinamento(livello industriale)



Evoluzione dello

sviluppo del software Lo sviluppo del software deve evolvere in

una disciplina ingegneristica, con basi Teoriche Metodolo iche


Nel 1968, durante una conferenzasull'evoluzione del software,

viene coniato il termine“ingegneria del software ”



Ingegneria del Software Una disciplina tecnologica gestionale


sistematico quantificabile (in termini di tempi e costi)

lo sviluppo e la manutenzionedei 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 l’usodel prodotto software: documentazione tecnica manualistica di installazione manualistica di utilizzo …



Prodotto Software Può essere realizzato

per un particolare cliente per il mercato in generale


Può fare parte di un sistema di elaborazioneche comprende sia la parte software

sia la parte hardware



Prodotto Software Si sviluppa, non si fabbrica Cliente Sviluppatore/i Processo di sviluppo


Linguaggio e strumenti di modellazione Non “si consuma”…

Struttura Caratteristiche



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



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



Principali cause di fallimento Sviluppatori non all’altezza delle attività in cui sono

coinvolti Capacità e conoscenza degli sviluppatori sono i

fattori che maggiormente contribuiscono


alla produttività

Buoni sviluppatori possono fornire una soluzione, maottimi sviluppatori possono fornire

soluzioni migliori più velocemente a minor costo



Obiettivo dell’ingegneria del software Mettere in grado lo sviluppatore

di affrontare la complessitàdei grossi progetti


con le caratteristiche di qualità desiderate Gestire le risorse

(specie quelle umane) in modo produttivo

Rispettare i vincoli economici e di tempospecificati



Ingegneria tradizionale Il problema dello sviluppo del software è un

problema di gestione della complessità In altri settori, l'uomo ha imparato bene a


,come un edificio, un'automobile, uncalcolatore, un impianto industriale

Quali sono i principi usati nell'ingegneriatradizionale per affrontare la complessità?



Principi usati nell'ingegneria tradizionale

per affrontare la complessità

Suddivisione del progetto in sottoprogetti

(moduli), e così via sino ad avere modulifacilmente progettabili

Utilizzo di arti e sottosistemi ià ronti


Sviluppati in casa Comprati da fornitori esterni

Standardizzazione dei componenti

in modo che possano essere facilmentecollegabili e intercambiabili



Principi usati nell'ingegneria tradizionale

per affrontare la complessità

Utilizzo del calcolatore come ausilio per La progettazione L’esecuzione di compiti ripetitivi I calcoli


Lo sviluppo di un progetto non è lasciatoal caso o all’estro di pochi progettisti,

ma è un’attività in larga misura sistematica



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 or e n uenza sulla qualità sul costo sui tempi di realizzazione

del prodotto



Processo di sviluppo del software Stabilisce un ordine di esecuzione delle attività

Specifica quali elaborati devono essere forniti equando Assegna le attività agli sviluppatori


Fornisce criteri per monitorare il progresso dello sviluppo misurarne i risultati

pianificare i progetti futuri Copre l’intero ciclo di vita del software



Fasi del processo di sviluppo del software

1. Studio di fattibilità

2. Analisi dei requisiti3. Specifica dei requisiti


.

5. Realizzazione e collaudo dei moduli6. Integrazione e collaudo del sistema

7. Installazione e training 8. Utilizzo e manutenzione



Processo di sviluppo del software

Studio di fattibilità Valutazione preliminare dei costi e dei benefici per

stabilire se si debba avviare lo sviluppodell’applicazione Alternative possibili Scelte più ragionevoli


Risorse finanziarie e umane necessarie per l’attuazione delprogetto

Il contenuto di questa fase risulta largamentevariabile da caso a caso, in funzione del tipo diprodotto e dei ruoli del committente e del produttoredell’applicazione




Studio di fattibilità Il risultato della fase di studio di fattibilità è

un documento che dovrebbe contenerele seguenti informazioni: definizione preliminare del problema


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



Un requisito è la descrizione di un comportamento del sistema(requisito funzionale) di un vincolo


Analisi dei requisiti


sul comportamento del sistema sullo sviluppo del sistema



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 stessatessera nell’arco 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 …




Analisi dei requisiti 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



Formalizzazione dei requisiti

Validazione delle specifiche Evoluzione delle specifiche


Specifica dei requisiti


r su tato pr nc pa eil 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




Specifica dei requisiti Il DSR costituisce un riferimento per l’attività di

sviluppo del prodotto, pertanto deve essere preciso,completo e consistente – inadeguatezza dellinguaggio naturale


Il DSR definisce quali funzionalità deve fornire il sistema NON come sono realizzate le funzionalità




Specifica dei requisiti Un ulteriore modo di descrivere i requisiti funzionali

consiste nel fornire al committente una versioneiniziale del Manuale Utente

Viene anche definito il Piano di Test di Sistema che


,

sviluppo, nella fase di integrazione, si può verificare ilrispetto dei requisiti da parte del sistema sviluppato

Tutti i documenti dovrebbero essere approvati esottoscritti dal committente

Stiamo realizzando il prodotto desiderato?




Progettazione Si definisce l’architettura generale (hardware e

software) del sistema

Si decompone l’architettura software inuno o più programmi eseguibili


, 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



Progettazione object-based Tipi di dati astratti Incapsulamento

Progettazione object-oriented Ereditarietà


Progettazione

Polimorfismo

Progettazione generica rispetto ai tipi Template in C++ Generici in Java e C#

Gestione delle eccezioni Gestione degli eventi

Design pattern




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


Progettazione

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 dell’architetturasoftware può anche essere data in manierarigorosa, o addirittura formale, usando


opportuni linguaggi di specifica di progetto

Stiamo realizzando correttamente il prodotto?



Il progetto viene realizzato come insieme di

programmi e/o modulinel linguaggio di programmazione scelto(o nei linguaggi di programmazione scelti)


Realizzazione e collaudo dei moduli

“The fastest line of code to develop is line of code you don't have to write ” - Jeff Tash

Gestione delle versionidel software





Realizzazione e collaudo dei moduli Verifica del software

Analisi statica Analisi dinamica Debu in


Collaudo dei moduli (unit testing)verifica che un modulo soddisfi le specifiche diprogetto



C / C++

Java C#


Tecnologie e Linguaggi

HTML – Hypertext Markup Language DHTML – Dynamic HTML CSS – Cascading Style Sheets

Javascript




XML – eXtensible Markup Language

DTD – Document Type Definition XSD – XML Schema Definition XSL – eXtensible St lesheet Lan ua e



XSLT – XSL for Transformations

COM, COM++, DCOM, CORBA, EJB

.NET, ADO, LinQ, XAML, WPF, WF, WCF DBMS, SQL, ORM






JavaScript

DHTMLC++


CSS

XML

Java

XSLTC#

DataBase




Integrazione e collaudo del sistema Si integrano i singoli moduli

e/o programmi tra loro esi esegue il test del sistemacompleto per assicurarsi che


alfa test - il sistema è rilasciato per l’uso, maall’interno dell’organizzazione del produttore

beta test - si ha un rilascio controllato a pochi eselezionati utenti del prodotto




Controllo della qualità Uso di programmi di test

Sollecitazione dei programmi (condizionilimite)


Controllo dell'utilizzo di standard prestabiliti …



Deployment

Il sistema software viene:consegnato al cliente


Installazione e training

ns a a omesso in funzione

Training





Utilizzo e manutenzione Il sistema viene utilizzato…

Fase di manutenzioneè la fase più lunga del ciclo di vita


un pro otto so tware50-80% dei costi complessivi




Utilizzo e manutenzione Manutenzione correttiva

correzione degli errori che non sono stati scopertinelle fasi precedenti


aumento dei servizi forniti dal sistema in seguito alladefinizione di nuovi requisiti

Manutenzione perfettiva

miglioramento delle caratteristichedelle unità del sistema




Utilizzo e manutenzione Spesso il software non viene progettato per

essere modificato facilmente

V n n r m ifi h ir m n


sui programmi, senza modificare la documentazione di progetto la documentazione di test

la specifica dei requisiti ...




Utilizzo e manutenzione Re-ingegnerizzazione del software

Ristrutturazione del codice (refactoring ) Conversione del linguaggio Reverse en ineerin




Pianificazione, controllo e gestione delprocesso di sviluppo Analisi dei costi

Gestione del gruppo di lavoro


Rischi relativi ai requisiti Rischi legati alle risorse umane Rischi tecnologici

Rischi politici



Processo di sviluppo del software Alcune attività sono prevalentemente “brain intensive ” difficilmente meccanizzabili


Alcune attività possono essere svolte con l’ausilio di

strumenti CASE (Computer-Aided Software Engineering)



Strumenti CASEMediante strumenti CASE, possono

essere svolte: la scomposizione funzionale


a e n z one gra ca e e en n g oco(dati, funzioni, associazioni, …)

la definizione delle interazioni

…



Strumenti CASE Sistemi avanzati di CASE riescono a

costruire programmi completi e funzionantipartendo da questi diagrammi, purché tutte leinformazioni siano state fornite correttamente


MAIN

PROGRAMMA

CASE



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 formagrafica alla forma testuale

Sviluppare un progetto grafico completo per un

programma può essere impegnativo quanto loscrivere il programma direttamente!



Processo di sviluppo del software Modello a cascata

Modelli evolutivi Sviluppo incrementale – iterativo Modello a s irale


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

Studio di fattibilità


Implementazione

Progettazione

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 elevatipertanto, ogni fase deve essere svolta in manieraesaustiva prima di passare alla successiva,


n mo o a non generare retroaz on

Le uscite che una fase produce come ingresso per lafase successiva sono i cosiddetti semilavorati delprocesso di sviluppo:

Documentazione di tipo cartaceo Codice dei singoli moduli Sistema complessivo





Modello a cascata Oltre alle fasi, è fondamentale definire:

Semilavoratial fine di garantire che ci possa essereun’attività di controllo della qualità dei semilavorati


Dateentro le quali devono essere prodotti i semilavoratial fine di certificare l'avanzamento del processosecondo il piano stabilito





Modello a cascata I limiti sono dati dalla sua rigidità

in particolare da due assunti di fondo moltodiscutibili: Immutabilità dell’analisi


loro esigenze e di conseguenzain fase di analisi iniziale è possibile definire tutte lefunzionalità che il software deve realizzare

Immutabilità del progetto

è possibile progettare l’intero sistema prima di averscritto una sola riga di codice





Modello a cascata Nella realtà:

La visione che gli utenti hanno del sistema evolveman mano che il sistema prende forma e quindile specifiche cambiano in continuazione


Nel campo della progettazione “le idee migliorivengono in mente per ultime”, quando si cominciaa vedere qualcosa di concretoInoltre problemi di prestazioni costringono spesso

a rivedere le scelte di progetto





Modello a cascata Evoluzioni successive al modello originale

ammettono forme limitate di retroazione a un livello

Analisi


Implementazione

Progettazione

Collaudo





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 baseconcreta per meglio definire le specifiche


,

abbandonato (throw-away prototyping) e si procedea costruire il sistema reale secondo i canoni delmodello a cascata

Questo approccio risulta però quasi sempre così

dispendioso da annullare i vantaggi economici che ilmodello a cascata dovrebbe garantire





Prototipo Modello approssimato dell’applicazione

Obiettivo: essere mostrato al committente – o usatoda questi – al fine di ottenere un'indicazione suquanto 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

dell’applicazione parta inizialmente con requisiti nonperfettamente noti o instabili





Prototipo Prototipazione “throw-away ”

Il prototipo che si realizza è del tipo usa e getta

Obiettivo: comprendere le richieste del cliente e


sistema Il prototipo si concentra sulle parti che sono mal

comprese con l'obiettivo di contribuire a chiarire i

requisiti




pp

Prototipo Programmazione esplorativa

Il prototipo si trasforma progressivamente nelprodotto 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




pp

Modelli evolutivi Partendo da specifiche molto astratte, si sviluppa un

primo prototipo Da sottoporre al committente Da raffinare successivamente





pp

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 ilprodotto finito attraverso un certo numero diiterazioni


Il vantaggio fondamentale è che ad ogni iterazione èpossibile confrontarsi con gli utenti per quanto riguarda le

specifiche e le funzionalità

(raffinamento dell’analisi) rivedere le scelte di progetto

(raffinamento del design )




Modelli evolutivi L’efficacia di questi modelli si basa su due requisiti:

Uniformità fra le tecniche di analisi, design eprogrammazione Tecnologie e strumenti di sviluppo predisposti


a approcc o ncrementa e

I modelli evolutivi si sono orientati verso cicli semprepiù brevi e iterazioni sempre più veloci, fino adarrivare al modello più “radicale” che prende il nomedi Extreme Programming (XP)




Modelli evolutivi L’illustrazione, tratta da un articolo di Kent Beck, mostra

l’evoluzione dal modello a cascata, all’extreme programming





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




Extreme Programming Si basa su:

Comunicazione: ci deve essere grandecomunicazione sia tra gli sviluppatori, sia trasviluppatori e clienti


Testing: è necessario avere più codice per il test

che per il programma vero e proprio - ogniprogrammatore deve scrivere il programma di testparallelamente se non prima di scrivere il codice

effettivo




Extreme Programming Si basa su:

Semplicità: il codice deve essere il più semplicepossibile - complicare il codice tentando diprevedere futuri riutilizzi è controproducente sia


come qua co ce pro o o, s a come empo

necessario - d'altra parte, il codice semplice ecomprensibile è il più riutilizzabile

Coraggio: non si deve avere paura di modificare il

sistema che deve essere ristrutturato incontinuazione, ogni volta che si intravede unpossibile miglioramento (refactoring )



Analisi dei rischi Quale modello scegliere per il processo di sviluppo?

La scelta deve dipendere da una valutazione deirischi inerenti alle varie attività che si dovrannoeffettuare durante il processo di sviluppo


Obiettivo: minimizzare i rischi

Rischio inerente un'attivitàvalutazione (misura) dell'incertezza che si ha sulrisultato finale dell'attività



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 randi


Modelli evolutivi Alto rischio per mancanza di visibilità Basso rischio per sviluppo di nuove applicazioni

Sistemi di dimensioni piccole




Modelli ibridi Sistemi composti di sotto-sistemi

Per ogni sotto-sistema è possibile adottare undiverso modello di sviluppo Modello evolutivo

-


Modello a cascataper sotto-sistemi con specifiche ben definite

Di norma conviene creare e raffinare prototipifunzionanti del sistema o di sue parti, secondo

l’approccio incrementale - iterativo




Sviluppo incrementalesi costruisce il sistema sviluppandone

sistematicamente e in sequenza parti ben definiteuna volta costruita una parte, essa non viene piùmodificata

Sviluppo incrementale

è di fondamentale importanza essere in grado di specificare

perfettamente i requisiti della parte da costruire, prima dellasua implementazione





Sviluppo iterativosi effettuano molti passi dell’intero ciclo di sviluppo

del software, per costruire iterativamente tutto ilsistema, aumentandone ogni volta il livello didettaglio

Sviluppo iterativo

non funziona bene per progetti significativi non consente di valutare correttamente i rischi relativi alle

diverse parti del sistema





Sviluppo incrementale - iterativo Si individuano sottoparti relativamente autonome Si realizza il prototipo di una di esse Si continua con altre parti Si aumenta progressivamente l’estensione e il dettaglio dei

Sviluppo incrementale - iterativo

prototipi, tenendo conto delle altre parti interagenti

E così via…





Sviluppo incrementale - iterativo

1 3

2

1 3

2

P1'1 3

2

P1'

P2'

1 3

2

P1''

P2'


1 3

2

P1''

P2'

P3'1 3

2

P1''

P2'

P3''1 3

2

P1''

P2''

P3''1 3

2

PD1

P2''

P3''

Pn'' : Secondo prototipo

PDn : Prototipo definitivo

Pn' : Primo prototipo




Sviluppo a componenti

Progettazione OORicerca classi da

riusare

Ricerca componentida riusareAnalisi dei requisiti


Analisi OO

Scrittura del

prototipo

Valutazione

Librerie di

classi

Sviluppo classi da

riusare

Sviluppo componentida riusare

Libreria dicomponenti

Installazionee utilizzo




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 artire da simboli rafici con una semanticaben definita

Possono essere interpretabili Un modello può essere eseguito

simulazione più o meno completa del comportamento delsistema modellato

Un modello può essere tradottogenerazione del codice sorgente utilizzabilenell'implementazione del sistema





Linguaggi di modellazione Modelli semantici dei dati

Entità-Relazioni (E-R)

Modelli orientati all’elaborazione 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




Linguaggi di modellazione “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…




Linguaggi di modellazione Il linguaggio naturale è troppo impreciso

Il codice è preciso, ma troppo dettagliato

La soluzione migliore è utilizzare un linguaggio dimodellazione


Sufficientemente preciso

Flessibile dal punto di vista descrittivoper poter arrivare a un qualunque livello di dettaglio

Possibilmente standard




Linguaggi di modellazione 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 ) hadefinito 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 menoastratte di un sistema (non necessariamentesoftware)


È indipendente dal processo, anche se promuoveuno stile di analisi e progettazione: Guidato dai casi d’uso (use case driven ),

cioè dalle funzionalità che il sistema deve fornire

Iterativo e incrementale,quindi guidato dall’analisi dei rischi (risk-driven )




Unified Modeling Language Prevede meccanismi di estensione del linguaggio

stesso

È integrabile con altre tecniche


È uno standard OMG




Unified Modeling Language 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 d’uso Diagramma delle attività Diagramma degli stati Diagramma di sequenza Diagramma di comunicazione (ex di collaborazione) Diagramma dei tempi (UML 2.0) Diagramma di sintesi dell’interazione (UML 2.0)



Fattori di qualità Qualità esterne

percepibili da un osservatore esterno cheesamina il processo o il prodotto come sefosse una scatola nera (black-box )


a

Facilità d'uso Velocità …

Devono essere garantite



Fattori di qualità Qualità interne

osservabili esaminando la struttura internadel processo o prodotto, come se questofosse una scatola trasparente (white-box )


o u ar

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 ri orosa


L’obiettivo di fornire meccanismi precisi dimisura non è realisticamente raggiungibile(ad esempio, per l’affidabilità)

Fattori di qualità del software

( t )



Correttezza (correctness) Data una definizione dei requisiti che il

software deve soddisfare,il software si dice corretto se rispetta talirequisiti


I requisiti specificati risultanospesso incompleti rispetto ai

requisiti reali


( b t )



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


,

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 )


( li bilit )



Affidabilità (reliability) Il software si dice affidabile se

le funzionalità offerte corrispondono airequisiti (il software è corretto)


,

o economici (il software è robusto)

Affidabilità = Correttezza + Robustezza


à ( t dibilit )



Estendibilità (extendibility) Facilità con cui il software può essere

modificato per soddisfare nuovi requisiti

La modifica di programmi di piccole dimensioni


non un pro ema ser o

I sistemi software di dimensioni medie e grandipossono soffrire di fragilità strutturale:modificando un singolo elemento della struttura sirischia di far collassare l'intera struttura


E dibili à (extendibility)



Estendibilità (extendibility) Due principi essenziali:

Semplicità architetturale più l'architettura del sistema è semplice


Modularità e decentralizzazione più il sistema è suddiviso in moduli autonomi più è facile che una modifica coinvolga un

numero limitato di moduli


Ri bilità (reusability)



Riusabilità (reusability) Il software è riusabile se può essere

riutilizzato completamente o in parte in nuoveapplicazioni


Permette di non dover reinventare soluzioni aproblemi già affrontati e risolti

Influenza tutte le altre caratteristiche dei

prodotti software


C tibilità (compatibility)



Compatibilità (compatibility) Facilità con cui il prodotto software può

essere combinato con altri prodotti

m n i n l r


Utilizzo di standard: Nel formato dei dati che devono essere scambiati

con altre applicazioni (formato XML) Nell'interfaccia utente …


F ilità d' (ease of use)



Facilità d'uso (ease of use) Facilità con cui l'utilizzatore del

software è in grado di: Imparare ad usare il sistema


zzare s s emaFornire i dati da elaborare Interpretare i risultatiGestire condizioni di errore


Effi i (efficiency)



Efficienza (efficiency) Buon utilizzo delle risorse hardware:

Processori (tempo di calcolo)Memoria principale (occupazione di


Memorie secondarieCanali di comunicazione


Portabilità (portability)



Portabilità (portability) Facilità con cui il prodotto software può

essere trasferito su altre architetturehardware e/o software



Verificabilità (verifiability)



Verificabilità (verifiability) Facilità con cui il prodotto software può

essere sottoposto a test



Integrità (integrity)



Integrità (integrity) Protezione – sicurezza

abilità del sistema software di proteggerei vari componenti (programmi, dati,documenti) da


accessi e/o modifiche non autorizzatidi naturasia volontaria

sia involontaria


Innocuità (safety)



Innocuità (safety) Abilità del sistema software di non entrare

mai in uno stato di pericolosità intollerabile

i i mi h n r ri i i


pericolosi anche per la vita dell'uomo




Fattori di qualità del software 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 talicaratteristiche

Fattori di qualità

del processo di sviluppo del software



del processo di sviluppo del software Accettabilità (acceptability )

il processo è accettabile e utilizzabile dai responsabili dello

sviluppo? Facilità di comprensione (understandability )


Supportabilità (supportability )è possibile utilizzare strumenti CASE?

Capacità di modifica (maintainability )il processo è in grado di evolvere in caso di modificheorganizzative o di miglioramenti produttivi?

Fattori di qualità

del processo di sviluppo del software



del processo di sviluppo del software Visibilità (visibility )

dopo ogni attività, vengono prodotti documenti che permettano

di controllare l'avanzamento dei lavori? Affidabilità (reliability )


processo si ripercuotano in errori nel prodotto?

Robustezza (robustness )il processo è in grado di proseguire anche al verificarsi diproblemi imprevisti?




2. Analisi orientata agli oggetti

Analisi



Analisi Per effettuare correttamente l’analisi, è necessario

Comunicare con l’utente

Ottenere una buona conoscenza dell’area applicativa Determinare in dettaglio i requisiti del sistema


Produce un documento dei requisiti

base di partenza della fase successiva del processodi sviluppo del software, cioè la progettazione

Se non viene svolta in modo accurato, può avere

conseguenze molto serie: i costi per gestire requisitiomessi o errati possono diventare insostenibili

Analisi



Analisi Raccolta dei requisiti

Analisi del dominioProduce un modello che descrive il dominio del problema daaffrontare:


, Su cui si devono mantenere informazioni Con cui si deve interagire

Analisi dei requisitiProduce un modello che descrive le responsabilità del sistema

Che cosa deve fare il sistema per soddisfare il cliente Non come il sistema va realizzato

Analisi e gestione dei rischi



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 disviluppo


Ogni rischio presenta due caratteristiche: Probabilità che avvenga

non esistono rischi con una probabilità del 100% (sarebberovincoli al progetto)

Costo

se il rischio si realizza, ne seguono effetti indesiderati e/operdite




Analisi e gestione dei rischi Rischi relativi ai requisiti

i requisiti sono perfettamente noti?

Il rischio maggiore è quello di costruire un sistemache non soddisfa le esigenze del cliente


Rischi relativi alle risorse umane

è possibile contare sulle persone e sull’esperienzanecessarie per lo sviluppo del progetto?




Analisi e gestione dei rischi Rischi tecnologici

si sta scegliendo la tecnologia corretta?

si è in grado di aggregare correttamente i varicomponenti del progetto (ad es., GUI, DB, …)?quali saranno i possibili futuri sviluppi della


tecno og a

Rischi politicici sono delle forze politiche (anche in senso lato) ingrado di intralciare lo sviluppo del progetto?




Analisi e gestione dei rischi 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à l’attenzione che bisognerà dedicargli

Analisi

Raccolta dei requisiti



Raccolta dei requisiti Raccolta di tutte le informazioni su

cosa il sistema deve fare

secondo le intenzioni del cliente


Definire la ragione d’essere e gli obiettivi delsistema Definire i limiti del dominio del problema Identificare le funzioni principali del sistema

Analisi

Raccolta dei requisiti



Raccolta dei requisiti Non prevede passi formali,

né ha una notazione specifica, perché

dipende moltissimo dal particolare tipo di problema


eve pro urre

Un documento (testuale) Scritto dall’analista Discusso e approvato dal cliente

Un dizionario o glossario contenente la definizionedi tutti i termini e i concetti utilizzati

Analisi

Raccolta dei requisitiTi l i di i lt



Raccolta dei requisiti 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

Analisi

Raccolta dei requisitiL i d ll i i è l l



Raccolta dei requisiti 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

Analisi

Raccolta dei requisitiC f t lt i i t i



Raccolta dei requisiti Confronto con altri sistemi

Posizionare il sistema che si sta progettando rispetto

allo stato dell’arte


Le caratteristiche migliori I problemi più seri Le caratteristiche non necessarie

del nostro sistema e dei sistemi della concorrenza?

Analisi

Validazione dei requisiti Ogni requisito deve essere validato e negoziato con i clienti



a da o e de equ s t 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


r so vere

Consistenza – il nuovo requisito è in sovrapposizione e/o inconflitto con altri requisiti?

Realizzabilità – il nuovo requisito è realizzabile con le risorsedisponibili (hardware, finanziamenti, …)?

Completezza – esiste la possibilità che ci siano requisitirimasti ignorati?

Analisi

Cambiamento dei requisiti È normale che i requisiti subiscano modificazioni ed



q È normale che i requisiti subiscano modificazioni ed

evolvano nel tempo

Requisiti esistenti possono essere rimossi omodificati


uov requ s t possono essere agg unt

in una fase qualsiasi del ciclo di sviluppo Tali cambiamenti

Sono la norma, non l’eccezione

Possono diventare un grosso problema se nonopportunamente gestiti

Analisi

Cambiamento dei requisiti Più lo sviluppo è avanzato più il cambiamento è



q Più lo sviluppo è avanzato, più il cambiamento è

costoso

Modificare un requisito appena definito è facile Modificare lo stesso requisito dopo che è stato


costoso

Ogni cambiamento deve essere accuratamenteanalizzato per valutare La fattibilità tecnica

L’impatto sul resto del sistema Il costo

Analisi

Cambiamento dei requisiti Consiglio sviluppare sistemi che



q 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 l’aggiuntadi nuove funzionalità senza causare “disastri ”strutturali e/o comportamentali

Analisi

Analisi del dominio Obiettivo – identificare strutture e comportamenti



Obiettivo identificare strutture e comportamenticomuni 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 leapplicazioni 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 dall’analisi dei requisiti dei vari sistemi che



Deriva dall analisi dei requisiti dei vari sistemi cheoperano in un dominio

Aiuta ad effettuare le analisi dei nuovi sistemi, ed èda queste continuamente migliorata


Analisi del dominio


Analisi

Analisi dei requisiti Obiettivo – definire i requisiti funzionali e descrivere



q Obiettivo definire i requisiti funzionali e descrivere

il comportamento del sistema da realizzare

Si concentra sulla descrizione del sistema, delmondo esterno e dei loro costituenti fondamentali, e


non sui dettagli di come tale sistema funziona

Prima considera le entità importanti dell’ambienteesterno e del sistema, poi le raffina alla luce delleresponsabilità del sistema

Analisi

Analisi dei requisiti Deve produrre un documento dei requisiti



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

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 l’euro

Al termine della vacanza, ad ogni ospite viene consegnato un


estratto conto con la lista delle spese effettuate, nella valutascelta dal cliente

Per ogni spesa, l’elenco deve riportare la data e l’ora, il puntovendita, il tipo di acquisto e l’importo addebitato

Al termine di ogni settimana, ad ogni negozio deve essereconsegnato l’elenco degli acquisti effettuati presso i vari puntivendita associati

Esempio: Villaggio Turistico

Analisi dei Requisiti In un villaggio turistico, gli ospiti fanno spesa nei diversi negozi



gg g p p ge pagano i diversi servizi sempre e solo servendosi di una carta(simile a un bancomat) denominata Guest Card

Villaggio Turistico


sp e

Spesa

Negozio

Servizio

Carta Guest Card

Esempio: Villaggio TuristicoAnalisi 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

Ospite Può ac uistare un servizio in un ne ozio


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

Esempio: Villaggio TuristicoAnalisi dei Requisiti La valuta di riferimento è sempre l’euro



Ospite

Può acquistare un servizio in un negozio Deve pagare il servizio con la Guest Card in euro

Ne ozio


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

Esempio: Villaggio TuristicoAnalisi dei Requisiti Al termine della vacanza, ad ogni ospite viene consegnato un




Termine della vacanza – evento temporale


Estratto conto ≡ lista delle spese effettuate report di stampa

Spesa effettuata ≡ Servizio acquistato dall’ospite Cliente ≡ Ospite Valuta scelta dall’ospite

Può essere differente dalla valuta di riferimento

Esempio: Villaggio TuristicoAnalisi dei Requisiti Al termine della vacanza, ad ogni ospite viene consegnato un

l li d ll ff ll l




Ospite


eve sceg ere a va u a x pagamen o na e

Termine della vacanza – evento

Generazione dell’estratto conto acquisti

Consegna all’ospite dell’estratto conto acquisti

Pagamento finale nella valuta scelta dall’ospite

NOTA: Sarà necessario effettuare conversioni tra valute diverse

Esempio: Villaggio TuristicoAnalisi dei Requisiti Per ogni spesa, l’elenco deve riportare la data e l’ora, il punto

dit il ti di i t l’i t dd bit t



vendita, il tipo di acquisto e l’importo 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

Esempio: Villaggio TuristicoAnalisi dei Requisiti Al termine di ogni settimana, ad ogni negozio deve essere

consegnato l’elenco degli acq isti effett ati presso i ari p nti



consegnato l’elenco degli acquisti effettuati presso i vari puntivendita associati

Termine di ogni settimana – evento temporale


Generazione dell’estratto conto vendite x Punto Vendita

Consegna alla Catena Punti Vendita

AnalisiCasi d’uso e scenari I requisiti funzionali descrivono il comportamento del

sistema



sistema

I casi d’uso e i relativi scenari permettono Di formalizzare i requisiti funzionali


(e quindi di metterne in evidenza eventuali carenze)

Di comunicare meglio con il cliente

AnalisiCasi d’uso e scenari Caso d’uso



Descrizione di una richiesta fatta al sistema da una qualsiasi

entità esterna al sistema stesso (attore) Insieme di scenari legati da un obiettivo comune


cenar o – sequenza pass c e escr ve sia l’interazione tra l’attore e il sistema sia le elaborazioni necessarie per soddisfare la richiesta

dell’attore

AnalisiCasi d’uso e scenari Passi da intraprendere



Individuare il confine del sistema

Individuare gli attori Individuare i casi d’uso

’


Specificare gli scenari associati al caso d’uso

L’insieme di tutti i casi d'uso costituisce l’immaginedel sistema verso l’esterno

AnalisiCasi d’uso e scenari

Sistema

Caso d'uso



Sistema

Attore

Associazione


GestioneEsami

Esaminando Esaminatore

Effettuaesame

esame

Correggiesame


Attore



ruolo interpretato da un utente

(persona o sistema esterno) neiconfronti del sistema


Tutti gli esaminandi interpretano

lo stesso ruolo Tutti gli esaminatori interpretano

lo stesso ruolo

Esaminatore


Scenario principaled l d’



del caso d’uso

“Effettua esame”Effettua

esame


1. L’esaminando entra nel sistema (login )2. L’esaminando inizia l’esame3. L’esaminando naviga tra le domande e risponde

4. L’esaminando termina l'esame5. L’esaminando esce dal sistema (logout )

AnalisiCasi d’uso e scenari Un caso d’uso

i i t di tt t i di tt t



viene sempre avviato direttamente o indirettamente

dall’intervento di un attore che si pone un dato obiettivo l’esaminando vuole fare l’esame

’


raggiunto

l’esaminando ha fatto l’esame si conclude con fallimento quando l’obiettivo NON viene

raggiunto l’esaminando non è riuscito a fare l’esame – ad es. non è riuscito

ad effettuare il login (in questo contesto, il fatto che l’attore abbiasuperato o no l’esame è irrilevante)

AnalisiCasi d’uso e scenari Un caso d’uso viene sempre descritto dal punto di

vista di un attore e comprende



vista di un attore e comprende

0+ Precondizioni – condizioni che devono essere tutteverificate prima che il caso d’uso possa essere eseguito –vincoli sullo stato iniziale del sistema


1+ Sequenze di passi – cioè sequenze di interazioni tra

l’attore e il sistema necessarie a raggiungere l’obiettivorichiesto – potrebbero comprendere ramificazioni (if) eiterazioni (for, foreach e while)

0+ Postcondizioni – condizioni che devono essere tutte verequando il caso d’uso termina l’esecuzione di norma consuccesso

AnalisiCasi d’uso e scenari Ogni sequenza di passi deve

essere scritta in una forma narrativa strutturata



essere scritta in una forma narrativa strutturata

utilizzare il vocabolario di dominio

In tal modo, il committente’


e di conseguenza non solo sarà in grado di validare i casi d’uso ma sarà anche incoraggiato a partecipare attivamente alla

loro definizione

AnalisiCasi d’uso e scenari Tipicamente un caso d’uso comprende

uno scenario principale



u o scenario principale

eventuali scenari alternativi

che rappresentano possibili varianti del flusso che sono fatti “scattare” da opzioni, condizioni d’errore,


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

Definizionedei casi d’uso e degli scenari

1. Identificare tutti i possibili utilizzi del sistema2 Definire un attore per ogni categoria di utenza e per



2. Definire un attore per ogni categoria di utenza e per

ogni ruolo che l’utente gioca e che ha rilevanza per ilsistema


3. er c ascun attore ent care tutt g o ett vsignificativi che gli utenti si pongono e che il sistemadovrà supportare

4. Per ciascun obiettivo definire un caso d’uso

Definizionedei casi d’uso e degli scenari

5. Definire i casi d’uso• senza eccedere nella complessità e nei dettagli



• senza eccedere nella complessità e nei dettagli

• mantenendo sempre lo stesso livello di astrazione:singoli passi in un caso d’uso d’alto livello


astraz one possono essere trattat come o ett vda casi d’uso di livello d’astrazione più basso

6. Ricontrollare e validare i casi d’uso insieme agliutenti e ai committenti

AnalisiRelazioni tra casi d'uso Generalizzazione / Specializzazione

Si utilizza quando un caso d’uso è 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 d’uso “usa” almeno una volta unaltro caso d'uso

Estensione «extend» (o «extends») Si utilizza quando è necessario aggiungere un

comportamento opzionale a un caso d’uso esistente

AnalisiRelazioni tra casi d'uso



Preparaesame

Controllopassword«include»


GestioneEsami

Effettuaesame

Correggiesame

Effettuavalidazione

Scansioneretina

«include»

«include»

AnalisiRelazioni tra casi d'uso




AnalisiRelazioni tra attori

L’attoreA i i t t



Amministratore

Eredita tutti i casi d’uso’


Amministratore

Ha casi d’uso propri

Esempio: Villaggio TuristicoCasi d’uso




AnalisiDefinizione 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 that need to be satisfied for the use case toperform

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



be separately listed

List each such event as an alternative flow A use case can have as many alternative flows as required


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 therelationships between use cases


Titolo

Descrizione



Relazioni

Attori


Precondizioni

ScenarioPrincipale

Scenari alternativi

Requisiti non

funzionaliPunti aperti

AnalisiSpecifica dei requisiti

Obiettivo Specificare (cioè definire) le proprietà che il sistema dovrà avere

senza descrivere una loro possibile realizzazione



senza descrivere una loro possibile realizzazione

Approccio funzionaleAstrae sino al massimo livello il modo di funzionare di un calcolatore


Approccio orientato agli oggettiSi basa sulla stessa forma di astrazione applicata dagli uomini per

affrontare la complessità del mondo

Principio fondamentale: AstrazionePermette 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

AnalisiApproccio Funzionale Tecnica della Scomposizione Funzionale Strategia

Analisi top-down ► scegliere i passi ed i sotto-passi di



Analisi top-down ► scegliere i passi ed i sotto-passi di

elaborazione previsti per il sistema Astrazione procedurale► considerare ogni operazione come


,realizzata da un insieme di operazioni di più basso livello

L’analista concentra la sua attenzione sulla modularizzazione delleprocedure – i moduli devono essere il più possibile indipendenti

specifica le elaborazioni e le interfacce delle procedure

La scomposizione in funzioni è molto volatile(a causa del continuo cambiamento dei requisitifunzionali)

AnalisiApproccio Orientato agli Oggetti

Si basa sugli oggettiche sono molto più stabili delle funzioni Produce una specifica più resistente ai cambiamenti



Produce una specifica più resistente ai cambiamenti

Fornisce una base efficace per’


il riuso

Fornisce una rappresentazione omogeneaanalisi ► progettazione ► programmazionein 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



un modello dei dati o modello statico la parte fondamentale dell’OOA, su cui si basa tutto il resto descrive le entità del mondo reale rilevanti per il sistema


un mo e o comportamenta e o mo e o nam co completa il modello dei dati

descrive le funzionalità del sistema

L'insieme dei due modelli costituisce il punto di partenza dellasuccessiva fase di progettazione

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



Limitarsi esclusivamente a quelle classi che fanno partedel vocabolario del dominio del problema

Relazioni tra le classi


Per ogni classe Responsabilità Attributi Operazioni fondamentali

cioè servizi forniti all’esterno (interfaccia)

Attività non strettamente sequenziali, ma reiteratesino alla produzione di un modello coerente

Modello dei dati Raggruppamento delle classi in sottosistemi

Documentazione



Documentazione Diagrammi delle classi e dei sottosistemi


agramm co a oraz one ra e c ass(opzionali)

Per ogni classe, descrizione che ne specificascopo, responsabilità, attributi, operazioni

Per ogni attributo e ogni operazione, descrizione

testuale accurata

AnalisiIndividuazione delle classi Due analisti non produrranno mai due modelli delle

classi identici per lo stesso dominio applicativo



La letteratura è ricca di approcci raccomandati perl’individuazione delle classi


Approccio basato sulle frasi nominali Approccio guidato dai casi d’uso Approccio CRC

La cosa migliore è usare un approccio misto

AnalisiIndividuazione delle classi Fonti principali

Documento dei requisiti Altri documenti di tutti i tipi che descrivono il sistema



Altri documenti di tutti i tipi che descrivono il sistema

Altre fonti


Altri sistemi che funzionano nello stesso dominio o in dominianaloghi

Enciclopedie, nomenclature e documenti tecnici chedescrivono il dominio

Riutilizzare classi, gerarchie e strutture ottenute da

precedenti analisi nello stesso dominio

AnalisiIndividuazione delle classi 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)


n cano operaz on

Scegliere un solo termine significativo se più parole indicano lo

stesso concetto (sinonimi)

Il nome della classe deve essere un nome familiare all’utente o

all’esperto del dominio del problema non allo sviluppatore!

AnalisiIndividuazione delle classi Attenzione agli aggettivi e agli attributi, possono

Indicare oggetti diversi Indicare usi diversi dello stesso oggetto



gg Essere irrilevantiAd esem io:


“Studente bravo” potrebbe essere irrilevante

“Studente fuori corso” potrebbe essere una nuova classe Attenzione alle frasi passive, impersonali o con soggetti fuori

dal sistemadevono essere rese attive ed esplicite, perché potrebbero

mascherare entità rilevanti per il sistema in esame

AnalisiIndividuazione delle classi Individuare Attori con cui il sistema in esame deve interagire

PersoneDocente, Studente, Esaminatore,Esaminando



Esaminando, … Sistemi esterni

ReteLocale, Internet, DBMS, …


Dispositiviattuatori, sensori, …

Individuare Modelli e loro elementi specifici, cioè oggettidescrittivi e istanze specifiche Insegnamento – “Ingegneria del Software T”

CorsoDiStudio – “Ingegneria Informatica” Facoltà – “Ingegneria”

AnalisiIndividuazione delle classi Individuare Cose tangibili, cioè oggetti reali appartenenti al

dominio del problema Banco, LavagnaLuminosa, Schermo, Computer, …



Individuare Contenitori (fisici o logici) di altri oggetti


, , , , … ListaEsame, CommissioneDiLaurea, OrdineDegliStudi,

Window, Form, …

Individuare Eventi o Transazioni che il sistema deve gestire ememorizzare- 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, …

AnalisiIndividuazione delle classi Per determinare se includere una classe nel modello,

porsi le seguenti domande:



il sistema deve interagire in qualche modo con glioggetti della classe?


ut zzare n ormaz on attr ut contenute neg oggettdella classe

utilizzare servizi (operazioni) offerti dagli oggetti dellaclasse

quali sono le responsabilità della classe nelcontesto del sistema?

AnalisiIndividuazione delle classi Attributi e operazioni devono essere applicabili a tutti

gli oggetti della classe



Se esistono attributi con un valore ben definito solo per alcuni oggetti


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 un’analisi piùattenta potrebbe portare alla luce la gerarchia:

StudenteStudenteInCorsoStudenteFuoriCorso

AnalisiIndividuazione delle responsabilità

Responsabilità di una classe

Descrizione ad alto livello dello scopo per cui è stata definitala classe



Vengono descritti solo i servizi disponibili pubblicamente, non


,prematura

Obiettivo – aiutare nell’identificazione di Classi Attributi

Operazioni Relazioni tra le classi


Principali sorgenti di informazione Documento dei requisiti Classi già identificate



Cercare verbi che rappresentano azioni fatte da un


Utilizzare le classi già identificateper il semplice fatto di esistere, devono averealmeno una responsabilità

Annotare tutte le informazioni che gli oggetti devonomantenere e gestire


Una volta identificate, le responsabilità vannoassegnate 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


Metodo di analisi CRC (Class-Responsibility- Collaboration ) di Cunningham e Beck



Nome della classe

I collaboratorisono le altreclassi con le


Lista di responsabilità s acollaboratori

quali la classein esame

deveinteragire

Si utilizzanoschede di

cartoncino di10x15 cm

AnalisiIndividuazione delle relazioni

La maggior parte delle classi (degli oggetti)interagisce con altre classi (altri oggetti) in vari modi



Quando si modella un sistema è necessarioindividuare:


non solo le entità coinvolte nel sistema

ma anche le relazione tra tali entità Una relazione (relationship ) è una connessione tra

entità

AnalisiIndividuazione delle relazioni Nella modellazione object-oriented le relazioni più

importanti sono:

Ereditarietà



Associazione


Aggregazione

Composizione Dipendenza

Collaborazione (relazione usa) Relazione Istanza – Classe

Istanza di classe generica – Classe generica(istanza di template – template)

Relazione Classe – Metaclasse


In ogni tipo di relazione, esiste un cliente C chedipende da un fornitore di servizi F



C ha bisogno di Fper lo svolgimento di alcune funzionalità


che C non è in grado di effettuare autonomamente

Conseguenzaper il corretto funzionamento di Cè indispensabile il corretto funzionamento di F


Tipo di relazione Cliente Fornitore

Ereditarietà sottoclasse superclasse



Associazione contenitore contenuto


Dipendenza

classe dipendente(che usa)

classe da cui si

dipende (che vieneusata)

istanza classe

classe metaclasse

AnalisiIndividuazione dell’ereditarietà

La classe B(specializzazione osottoclasse ) è in relazione

I A l l A

B

A



IsA con la classe A(generalizzazione o


superc asse e ne ere ta Relazioni Attributi Operazioni AB

AnalisiIndividuazione dell’ereditarietà

L’ereditarietà deve rispecchiare una tassonomiaeffettivamente presente nel dominio del problema Non usare l’ereditarietà dell’implementazione

( i i f di li i!)



(siamo ancora in fase di analisi!)’


ad es., Studente e Dipartimento hanno entrambi un indirizzo,ma non per questo c’è ereditarietà!

La ricerca delle relazioni di ereditarietà contribuisce achiarire il significato delle varie classi e può portare

alla scoperta di nuove classi

AnalisiIndividuazione delle associazioni

Un’associazione rappresenta una relazionestrutturale tra due istanze di classi diverse o dellastessa classe



Un’associazione può


Rappresentare un contenimento logico (aggregazione) Una lista d’esame 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


AggregazioneUn oggetto x di classe X è associato a (contiene) unoggetto y di classe Y in modo non esclusivo

p ò condi idere con altri oggetti anche di tipo



x può condividere y con altri oggetti anche di tipo


Una lista d’esame contiene degli studenti Uno studente può essere contemporaneamente in

più liste d’esame La cancellazione della lista d’esame non comporta

l’eliminazione “fisica ” degli studenti in lista


ComposizioneUn oggetto x di classe X è associato a (contiene) unoggetto y di classe Y in modo esclusivoy esiste solo in quanto contenuto in x



y esiste solo in quanto contenuto in x


Un triangolo contiene tre punti (i suoi vertici)

L’eliminazione del triangolo comportal’eliminazione dei tre punti

Se la distruzione del contenitore comporta la

distruzione degli oggetti contenuti, si tratta dicomposizione, altrimenti si tratta di aggregazione


In UML La composizione è indicata con un rombo nero dalla parte

del contenitore

L’aggregazione è indicata con un rombo bianco dalla parted l t it



L aggregazione è indicata con un rombo bianco dalla partedel 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) …

PersonaSocietà

nomeindirizzo

nomeindirizzocodiceFiscaledataNascita

impiegatodatore-lavorolavora-per1 *

0..10..1marito

moglie

matrimonio

0..1

*

dirigente

sottopostodirige

PuntoPoligono{ordered}

contiene13..*



{ }


Finestra

Vari tipi di associazione.

Etichetta

BarraTitolo

Pulsante Chiusura

Pannello Bordo

1

1

11

1 1..* 1

Questo è un commentoassociato alla classePoligono.


Per individuare potenziali aggregazioni ocomposizioni, considerare Insieme-PartiComponenti Contenitore-Contenuto



Contenitore Contenuto-


…

Se contenitore e contenuto hanno un legame forte euno stesso ciclo di vita, si tratta di composizionealtrimenti, si tratta di aggregazione


Per individuare potenziali associazioni generiche,per ogni oggetto, porsi le domande A quali altri oggetti è collegato nel dominio del

problema?



problema?


a c eve ottenere n ormaz on per so s arealle sue responsabilità?


Una volta determinata la presenza di un’associazione

Tracciare la linea di connessione, eventualmente col simbolo diaggregazione o composizione dalla parte del contenitore

Se possibile dare un nome all’associazione e ai due ruoli



Se possibile, dare un nome all associazione e ai due ruoli,


Definire il valore, l’intervallo o l’insieme 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


Molteplicità

Simbolo Significato Esempi



Simbolo Significato Esempi


n va ore s ngo o

* da 0 a∞

*

n..m intervallo 0..1 1..*

n,m

insieme di valori

e/o intervalli 1,3..5,7


Attenzione alle associazioni molti a moltipossono nascondere una classe (classe diassociazione) del tipo “evento da ricordare”




Veicolo nasconde una classe CompraVendita, che

lega Proprietari e Veicoli Esempio: la connessione matrimonio tra Persona e

Persona nasconde una classe Matrimonio, che legadue Persone


1°esempio

Un proprietariopuò possedere

molti veicoli

Proprietario Veicolo

1..* 1..*

possiede

* *




essere di moltiproprietari in tempi

successivi

in comproprietà


-dataAcquisto

CompraVendita

1..* 1..** *

Legame 1 a 1


1°esempio Un proprietario

può partecipare a

piùcompravendite


-dataAcquisto

CompraVendita

1..* 1..*

* *



pcompravendite


Un veicolo puòessere contem-

poraneamente dipiù proprietari

Unacompravendita èrelativa a un soloveicolo


-dataAcquisto

CompraVendita

1..*

1..*

partecipa a

1..*

1

acquisto di


*

*

matrimonio

Persona



Relazione n-m (matrimonio) tra due oggetti della stessa classe.


Matrimonio1

data

Un Matrimonio è in effetti una classe, con due associazioni

Persona

1

marito

moglie

con oggetti di tipo Persona (marito e moglie).

*

*

AnalisiIndividuazione delle collaborazioni

Una classe A è in relazione USA con una classe B (AUSA B) quando A ha bisogno della collaborazione diB per lo svolgimento di alcune funzionalità che A non

è in grado di effettuare autonomamenteUn’operazione della classe A ha bisogno come argomento di



g Un’operazione della classe A ha bisogno come argomento di


un’istanza della classe B void fun1(B b) { … usa b … }

Un’operazione della classe A restituisce un valore di tipo B B fun2(…) { B b; … return b; }

Un’operazione della classe A utilizza un’istanza della classeB (ma non esiste un’associazione tra le due classi) void fun3(…) { B b = new B(…); … usa b … }

AnalisiIndividuazione delle collaborazioni

La relazione non è simmetricaA dipende da B, ma B non dipende da A

Evitare situazioni in cui una classe, tramite unacatena di relazioni USA, alla fine dipende da se



, p


Cliente Fornitore

Cliente

Fornitore

Nome Interfaccia

AnalisiIndividuazione degli attributi

Ogni attributo modella una proprietà atomica di unaclasse Un valore singolo Una descrizione




…

Un gruppo di valori strettamente collegati tra loro Un indirizzo Una data

…


Proprietà non atomiche di una classe devono esseremodellate come associazioni

Aff i A



* AfferisceA


-cognome-nome

Docente

-descrizione

Dipartimento

Direttore1

0..1

EDirettoDa


Il nome dell’attributo Deve essere un nome familiare

all’utente o

all’esperto del dominio del problema non allo sviluppatore!



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


Esprimere tutti i vincoli applicabili all’attributo

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



Opzionalità

votoFinale [0..1]: Votazione Unità di misura recisione



Unità di misura recisione


Visibilità (opzionale in fase di analisi)

Pubblica + Protetta # Privata –

Attenzione:gli attributi devono essere sempre privati!



Appartenenza alla classe (e non all’istanza)

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


I vincoli possono essere scritti

Utilizzando direttamente UML

Tipo Opzionalità



p


Visibilità …

Utilizzando Object Constraint Language (OCL)descritto in “The Unified Modeling Language ReferenceManual”

Come testo in formato libero in un commento UML


Persona

da memorizzare in mm.da visualizzare in cm.può essere modificata…




altezza: Integersesso: {femmina, maschio}

…età()

0..1

moglie

0..1marito

matrimonio

{self.moglie.sesso = femmina andself.marito.sesso = maschio}


In un certo istante, ogni oggetto avrà un valorespecifico per ogni attributo della classe diappartenenza: 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


-cognome-nome

Docente

-descrizione

Qualifica

* 1




-cognome-nome

-qualifica

-cognome-nome

Docente

Ricercatore Ordinario Associato


Attenzionenel caso di attributi con valore “sì o no”,il nome dell’attributo potrebbe essere uno dei valori

di un’enumerazione




tassabile (sì o no) potrebbe diventare

tipoTassazione (tassabile, esente, ridotto, ecc.)


Attenzionenel caso di attributi calcolabili (ad esempio, età),specificare sempre l’operazione di calcolo ma attr uto




ma attr uto

Se memorizzare oppure no un attributo calcolabileè una decisione progettuale, un compromesso tra tempo di calcolo spazio di memoria


Attenzionenon definire attributi che indicano il tipo (o categoria)di un oggetto

Deve essere sempre possibile ottenere il tipo di unoggetto mediante un’operazione ad esempio




oggetto mediante un operazione, ad esempio nomeClasse()

GetType() – in .NET GetType().ToString()

per avere il nome della classe


Applicare l’ereditarietà: Posizionare attributi e associazioni più generali

più in alto possibile nella gerarchia Posizionare attributi e associazioni specializzati

più in basso




più in basso

AnalisiIndividuazione delle operazioni

Per completare la fase di analisi,è necessario descrivere in modo dettagliato gliaspetti più volatili del sistema

Le operazioni (o servizi) che ogni classe deveoffrire




offrire

La sequenza temporale di tali operazioni


Operazione: azione, o insieme di azioni, che tutti glioggetti della stessa classe devono essere in grado dicompiere per raggiungere un determinato scopo

Sono in stretto rapporto con le responsabilità di una,




informazioni di stato

Si eseguono coinvolgendo uno specifico oggettodella classe (invio di un messaggio all’oggetto)

Possono anche essere assegnate a una classe enon alle sue istanze


Il nome dell’operazione Deve appartenere al vocabolario standard del

dominio del problema Potrebbe essere un verbo

ll’i ti ( i i i )




all’imperativo (scrivi, esegui, ...) o in terza persona (scrive, esegue, ...)in modo consistente in tutto il sistema

Dovrebbe iniziare con una lettera maiuscola(convenzione .NET)


Notazione UML

visibilità nomeOperazione(lista-parametri): tipoRestituito




+SetCognome(nuovoValore: string)

+GetNumIstanze(): int+Visualizza (disp: OutputDevice)


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 , ,




diagramma delle classi

Altre operazioni Devono essere determinate

servizi offerti agli altri oggetti

Compaiono nel diagramma delle classi


Operazioni standard

CostruttoreInizializza un nuovo oggetto (.ctor)

Invocato automaticamente dalla new

Effettua tutte le azioni necessarie per rilasciare le




Distruttorep

risorse possedute dall’oggettoInvocato automaticamente da GC o delete

Accessor

Get - restituisce il valore di un attributo atomico o ilriferimento a un oggetto (nel caso di associazioni)

Set - modifica il valore di un attributo atomico oppurecollega/scollega un oggetto a un altro oggetto (nel

caso di associazioni)


Classi contenitori

Operazioni standard

Aggiungi, rimuovi, conta, itera, …’–

i il i l




oggetti, non il singolo oggetto

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

Selezioni da fare sugli oggetti contenuti TrovaPartiSpecifiche()

Operazioni del tipo InviaComandoATutteLeParti()


Distribuire in modo bilanciato le operazioni nelsistema

Mettere ogni operazione “vicino ” ai dati ad essanecessari

Applicare l’ereditarietà




Applicare l’ereditarietà Posizionare le operazioni più generali più in alto possibile

nella gerarchia Posizionare le operazioni specializzate più in basso


Descrivere tutti i vincoli applicabiliall’operazione

Parametri formali, loro tipo e significato

- -




Invarianti di classe

Eccezioni sollevate Eventi che attivano l’operazione

Applicabilità dell’operazione

…


PRE-CONDIZIONEEspressione logica riguardante leaspettative sullo stato del sistema

prima che venga eseguita un’operazione Ad esempio, per l’operazione




d ese p o, pe ope a o eCalcolaRadiceQuadrata(valore),

la pre-condizione potrebbe essere: “valore ≥ 0” Esplicita in modo chiaro che

è responsabilità della procedura chiamante

controllare la correttezza degli argomenti passati


POST-CONDIZIONEEspressione logica riguardante leaspettative sullo stato del sistema

dopo l’esecuzione di un’operazione Ad esempio, per l’operazione




p , p pCalcolaRadiceQuadrata(valore),

la post-condizione potrebbe essere:“valore == risultato * risultato”


INVARIANTE di classeVincolo di classe (espressione logica)che deve essere sempre verificato sia all’inizio

sia alla fine




di tutte le operazioni pubbliche della classe

Può non essere verificato solo durante l’esecuzionedell’operazione


In caso di ridefinizione di un’operazione inuna sotto-classe

Le pre-condizioni devono essereidentiche o meno strin enti

L t di i i d




Le post-condizioni devono essere

identiche o più stringenti Gli invarianti di classe devono essere

identici o più stringenti


ECCEZIONESi verifica quando un’operazione viene invocata nel rispetto delle sue pre-condizioni ma non è in grado di terminare la propria

esecuzione nel rispetto delle post-condizioni




Esempio: Villaggio TuristicoModello dei dati

numeroPuntiVendita()importoVenditeGiorno()

importoVenditeTotale()elencaVendite()

idCatenaPuntiVenditanome : String

CatenaPuntiVendita

1




importoVenditeGiorno()importoVenditeTotale()

creaMovimento()elencaVendite()

idPuntoVendita

idProgressivo : Integer

PuntoVendita

1..*

Servizio

1..* *


importoVenditeGiorno()

importoVenditeTotale()creaMovimento()elencaVendite()

idPuntoVenditaidProgressivo : Integer

PuntoVendita

GuestCard

acquirente 1

«use»

venditore1




idMovimento : Integerdata : Dateimporto : Currency

Movimento

0..*

Acquisto

0..*

Vendita


idOspitenome : Stringindirizzo : StringdataNascita : DatesessoinizioSoggiorno : DatefineSoggiorno : Date

«actor»Ospite

speseGiorno()speseTotali()

idConto : Integer

limiteGiornaliero : Currencysaldato : Boolean

Conto

1 1

speseGiorno()speseTotali()elencaAcquisti() 1




elencaAcquisti()

abilitata()speseGiorno()speseTotali()elencaAcquisti()

idGuestCard : IntegerinizioValidità : DatefineValidità : Date

GuestCard

1..*


idOspitenome : Stringindirizzo : StringdataNascita : Date

sessoinizioSoggiorno : DatefineSoggiorno : Date

«actor»Ospite

speseGiorno()speseTotali()elencaAcquisti()




elencaAcquisti()

0..*

pagante

1 associatoA

scegliFormaDiPagamento()effettuaPagamento()elencaTuttiGliAcquisti()

OspitePaganteOspiteNonPagante

{OR}


effettuaPa amento

FormaDiPagamento haScelto

scegliFormaDiPagamento()

OspitePaganteValuta

*

elencaTuttiGliAcquisti()




effettuaPagamento()

Contante

effettuaPagamento()

idCartaDiCreditotipo : StringdataScadenza : Date

CartaDiCredito

AnalisiModello dinamico

Descrive il sistema durante il suo funzionamento

Consiste nella definizione di scenari difunzionamento del sistema, in risposta a eventi

esterni o in fasi particolarmente significative Diagrammi dei casi d’uso - evidenziano

le risposte a eventi esterni




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

all’altro


Diagrammi di interazione - descrivono lo scambio dimessaggi tra oggetti

Diagrammi di sequenza - evidenziano l’ordine in cui i messaggi vengono scambiati tra

Diagrammi di collaborazione evidenziano




Diagrammi di collaborazione - evidenziano

le connessioni tra gli oggetti e i messaggiscambiati

Entro certi limiti, un diagramma di sequenza puòessere convertito nel suo corrispondente diagrammadi collaborazione e viceversa


Non conviene spingere la definizione del modellodinamico sino ai minimi dettagli Utilizzare i diagrammi dinamici solo per descrivere

il funzionamento del sistema nei casi più critici a e n z one ettag ata tutte e operaz on e

sistema può essere fatta realizzando un prototipo




sistema può essere fatta realizzando un prototipo

funzionante

AnalisiDiagrammi di interazione

ObiettivoEvidenziare le interazioni (e quindi lo scambio dimessaggi) tra gli oggetti del sistema reale

funzionamento del sistema




Partire dai casi d’uso, cioè considerareciò che deve fare il sistema in risposta a richieste dei suoi utenti o a eventi esterni

AnalisiDiagrammi di interazione

L’invio di un messaggio (o richiesta di un servizio) da un oggetto mittente (o cliente) a un oggetto destinatario (o fornitore)

deve corrispondere a un’operazione della classe deldestinatario o di una sua superclasse




Pertanto, ogni messaggio comprenderà: il nome dell’operazione invocata gli eventuali parametri attuali un eventuale valore restituito

AnalisiDefinizione di una sequenza di messaggi

Considerare l’attore, l’evento esterno o il genericooggetto che scatena la sequenza di operazioni

Determinare il primo servizio richiesto e il fornitore ditale servizio – specificare il primo messaggio

Immedesimarsi nell’oggetto (o nella classe) chei il i hi d i




riceve il messaggio e chiedersi sono in grado di eseguire in modo autonomo l’operazione

richiesta?

In caso negativo, chiedersi

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


Iterare il procedimento, sino all’identificazione di tuttala sequenza dei messaggi

Identificare modelli comportamentali standard diinterazione tra oggetti (pattern )

Ricordarsi chett ( li t ) ò i i i




un oggetto (cliente) può inviare un messaggio

(chiedere un servizio) ad un altro oggetto (fornitore) solo durante l’esecuzione di un proprio metodo solo se conosce il fornitore


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




p

Il fornitore è il risultato dell’invio di un precedentemessaggio dentro il metodo del clientedue possibilità: Il fornitore esisteva già Il fornitore viene creato, utilizzato (e distrutto)


Se il traffico di messaggi necessari per accedere aun fornitore è troppo alto,forse è opportuno aggiungere una connessione

permanente tra cliente e fornitore Se ci sono oggetti che dominano lo scenario,

facendo quasi tutto,




q ,

forse esiste un problema di distribuzione delleresponsabilità

AnalisiDiagrammi di sequenza

Obiettivo: porre in evidenza la sequenza (e la duratatemporale) dei messaggi scambiati tra gli oggetti

cliente : Package1::ClasseA fornitore : Package1::ClasseB

messaggio1()




messaggio1()


: Dipartimento

new

Le linee verticali tratteggiate(lifeline ) indicano il tempo di

vita degli oggetti

Gli oggetti sono rettangoli con dentro i nomi sottolineatidell’oggetto e/o della relativa classe

usso empora e scorredall’alto in basso

Gli i i i d ll li




Gli ispessimenti delle lineeverticali denotanoun’elaborazione in corso

È possibile indicareesplicitamente quando un

oggetto viene creato e quandoviene distrutto


Tra gli oggetti vi possono essere invii di messaggi,denotati da frecce, e ritorni (opzionali)

messaggio1()




AnalisiDiagrammi di collaborazione

Obiettivo: porre in evidenza come gli oggetti sonoconnessi tra di loro e come collaborano





Una connessione tra oggetti: Modella le dipendenze di un oggetto per quanto

riguarda le elaborazioni, indicando la necessità di

richiedere servizi per soddisfare le sueresponsa

Mostra graficamente l’accesso 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


Gli oggetti sono rettangolicon dentro i nomisottolineati dell’oggetto e/odella relativa classe(come nei diagrammi disequenza

Le connessioni tra oggettisono mostrate come linee




sono mostrate come lineecontinue tracciate tra glioggetti


una freccia postaparallelamente allaconnessione

un numero progressivoche fornisce la osizione

L'invio di un messaggio èindicato da:

nella sequenza di invio deimessaggi

una condizione




una condizione(opzionale) tra parentesiquadre

il nome del messaggio edeventualmente i suoiargomenti

AnalisiDiagrammi di stato

Lo stato di un oggetto è dato dal valore dei suoiattributi e delle sue associazioni

In molti domini applicativi, esistono oggetti che, a

seconda del proprio stato, rispondono in maniera Dispositivi (spento, in attesa, operativo, guasto, ecc.) Transazioni complesse (in definizione, in esecuzione,




completata, fallita, ecc.) …

In questi casi, è opportuno disegnare un diagrammadi stato per l’oggetto, mostrando i possibili stati e gli

eventi che attivano transizioni da uno stato all'altro


STATOSituazione, che si verifica durante la vita diun oggetto, nella quale l’oggetto

esegue certe attività




aspetta il verificarsi di certi eventi


EVENTOFatto che avviene in un intervallo di tempo e in unaporzione di spazio così ristretti da poterlo

considerare caratterizzato da un istante e/o da ununto

Può essere:




Esterno – generato nell’ambito del mondo reale(mouse, tastiera, arrivo ordine, passaggio qualifica,…)

Interno – generato da un oggetto del sistema


Call EventOccurs when an element receives a call for an operation

Signal EventOccurs when an element receives an explicit signal fromanother element

Change EventOccurs when a designated condition (usually described as aBoolean operation) becomes true




Boolean operation) becomes true

Time EventOccurs after a designated period of time or at a specific time ordate


TRANSIZIONERelazione tra due statiS1 (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


AZIONEComputazione atomica (non interrompibile) associata a una transizione

ATTIVITComputazione non atomica (interrompibile)




associata a uno stato insieme di azioni


Notazione UML

stato

TypingPassword

nome stato




entry / setEchoVisible(false)exit / setEchoVisible(true)

do / attività


Notazione UML

evento [condizione] / azione




Stato2

transizione

AnalisiIdentificazione degli stati

Esaminare i possibili valori degli attributi di unoggetto

Determinare se le responsabilità del sistema

prevedono per valori diversi degli attributi

Descrivere mediante un diagramma di stato




tutti i possibili stati che un oggetto può assumere durante lasua vita e

come cambia lo stato dell’oggetto in conseguenza deglieventi


In Corso

Immatricolazione / Iscrivi al I anno

Iscrizione [numero esami sufficiente] / Iscrivi all'anno successivo

after: [Scadenza termini]SuperamentoEsameDiLaurea

Iscrizione [numero esami insufficiente] / Iscrivi allo stesso annoRitirato

Iscrizione [numero esami sufficiente] / Iscrivi all'anno successivoLaureato




Fuori Corso

after: [Scadenza termini]

Iscrizione [numero esami insufficiente] / Iscrivi allo stesso anno

SuperamentoEsameDiLaurea




Struttura a livellidi un'applicazione

APPLICAZIONE



Ingegneria del Software T 2

Z I O

N E

PRESENTATION MANAGER

PRESENTATION LOGIC

A P P L I C A APPLICATION LOGIC

DATA LOGIC




DATA MANAGER

3

Presentation Manager

Gestione dell’interazione

con l’utente Gestione dello schermo

Gestione della tastiera

Gestione del mouse

…PRESENTATION MANAGER

I t f fi h (GUI)




Interfacce grafiche (GUI) API (Application Programming Interface ) di sistema

browser HTML

Interfacce a caratteri emulatori

4

Data Manager

Gestione di tutti i datipersistenti

Storage

Retrieval

Management

Recovery

…

DATA MANAGER

Fil t St d d




File system RDBMS

ODBMS

…

Stored procedure Trigger

…

5

Data Manager

File system API di sistema

RDBMS: DB2, Oracle, MS SQL Server, Informix,

Sybase, … propr e ar e

ODBC (Open Data Base Connectivity ), JDBC (standard)

ODBMS: ObjectStore, …




API proprietarie

…

6

A P P L I C A

Z I O N E PRESENTATION LOGIC

APPLICATION LOGIC

DATA LOGIC

PresentationLogic

Gestione dell’interazione con l’utente a livello logico

Formattazione e visualizzazione delle informazioni (output)




Formattazione e visualizzazione delle informazioni (output ) Accettazione dei dati (input )

Prima validazione dei dati

Gestione dei messaggi di errori

7

A P P L I C A


APPLICATION LOGIC

DATA LOGIC

ApplicationLogic

Logica dell’applicazione e controllo componenti




A P P L I C A


APPLICATION LOGIC

DATA LOGIC

DataLogic

Gestione della persistenza a livello logico

Consistenza dei dati




Consistenza dei dati Apertura/chiusura file , read , write e lock / unlock

Istruzioni SQL, transazioni (commit e rollback )

Gestione degli errori

9

Z I O

N E PRESENTATION LOGIC

PRESENTATION MANAGER

PRESENTATION MIDDLEWARE

A P P L I C

APPLICATION LOGIC

DATA LOGIC

DATABASE MIDDLEWARE




DATA MANAGER

S

10

Middleware

Software che permette lacomunicazione tra processi

c e so ano co cedell’applicazione dai sottostanti formati

e protocolli di comunicazione




e protocolli di comunicazione

11

Presentation Middleware

Software di emulazione di terminalialfanumerici

Combinazione di: Web browser (lato client )

Web server

Protocollo HTTP




Protocollo HTTP

…

12

Database Middleware

Software proprietario che trasferiscesulla rete

Le richieste SQL dall’applicazione al

I dati dal DBMS all’applicazione

ODBC JDBC




ODBC, JDBC…

13

A P P L I C A

Z I O N E

APPLICATION MIDDLEWARE

PRESENTATION LOGIC

APPLICATION LOGIC

L I C A

Z I O N E

APPLICATION LOGIC




A P P L

DATA LOGIC

14

Application Middleware

Gestisce la comunicazione tra due componenti dellastessa 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


P tt i



Progettazioneorientata agli oggetti

Dall’OOA all’OOD L’OOA identifica e definisce

le responsabilità del sistema le classi e gli oggetti

entro i limiti del dominio del problema

L’OOA definisce il modello statico e il modello

dinamico del sistema indipendentemente




dinamico del sistema, indipendentemente dalla specifica implementazione dalle modalità di interazione con l’utente

dalle modalità di persistenza degli oggetti

Dall’OOA all’OOD Per realizzare un sistema funzionante,

occorre considerare anche GUI

DB Framework , librerie, componenti, … Modifiche al modello

per avere software estensibile e modulare




per avere software estensibile e modulare …

Dall’OOA all’OOD L’OOD identifica e definisce altre classi e oggettialla luce dei seguenti principi

Incapsulamento Flessibilità

Evoluzione Prestazioni Massima indipendenza possibile da

Linguaggio (e ambiente) di programmazione Sistema Operativo

Hardware




p Hardware

Si noti che mediamente le classi di analisi sono solo

tra l’1% e il 10% delle classi di progettazione!

Dall’OOA all’OOD Il paradigma ad oggetti permette

Sia di modellare il mondo reale Sia di implementare il software

Nella fase di progettazioneNON occorre creare un modello differenteda quello sviluppato nella fase di analisi




da quello sviluppato nella fase di analisi

Si utilizza un’unica notazione Sia nella fase di analisi Sia nella fase di progettazione

Dall’OOA all’OOD Durante l’OOD, il modello prodotto dall’OOA deve essere

esteso al fine di modellare/progettare i quattro componentiprincipali di ogni singola applicazione che compone il sistema

APPLICATION LOGIC – logica dell’applicazione e controllo

degli altri componenti PRESENTATION LOGIC – gestione dell’interazione con

l’utente a livello logico – nuovi oggetti: finestre, menù, bottoni,toolbar , …

DATA LOGIC – gestione della persistenza a livello logico –




DATA LOGIC gestione della persistenza a livello logico nuovi oggetti: file, record, tabelle relazionali, transazioni,istruzioni SQL, …

MIDDLEWARE – gestione dell’interazione con i (sotto)sistemiesterni e con la rete

Dall’OOA all’OOD Nell’OOD, i risultati dell’analisi possono esseremodificati per motivi di opportunità legati

all’implementazione

Le modifiche devono essere ridotte al minimo,possibile tra OOA e OOD

Principali motivi per modificare il modello OOA Progettazione logica

definizione dettagliata dell’implementazione delle classi e




definizione dettagliata dell implementazione delle classi edelle loro relazioni

Riuso di classi e/o componenti disponibili

Raggruppamento di classi del modello

Dall’OOA all’OOD 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., dell’hardware, del DBMS, ...che devono essere utilizzati




che devono essere utilizzati Livello di ereditarietà supportato Api …

Progettazione logica Progetto dello schema logico del modello

Tipi di dato Strutture dati

Operazioni

Mentre nell’analisi ci si concentra su

cosa deve fare il sistema,nella progettazione logica ci si concentra su




p g gcome deve funzionare il sistema

Progettazione logica Il passaggio dall’OOA all’OOD non è ben supportato

dagli strumenti CASE:non c’è modo di separare le due fasi

Due possibilità L’analisi sfuma nella progettazione

il modello OOA viene progressivamente aumentato ecompletato, sino alla progettazione del sistema

► l’analisi originale si perdeIl d ll OOD è t ti d l d ll




Il modello OOD è generato a partire dal modelloOOA, ma viene mantenuto distinto► l’analista deve mantenere la corrispondenza tra i duemodelli, in caso di modifiche che si ripercuotono sull’analisi

Progettazione logica Durante la progettazione logica è necessario definire

Tipi di datoche non sono stati definiti nel modello OOA

Determinazione della navigabilità delle associazioni tra classi

e relativa implementazione Strutture dati

necessarie per l’implementazione del sistema Operazioni

necessarie per l’implementazione del sistema Algoritmi




Algoritmiche implementano le operazioni

Visibilità di classi, (attributi,) operazioni, …

Navigabilità di un’associazione

Possibilità di spostarsida un qualsiasi oggetto della classe originea uno o più oggetti della classe destinazione(a seconda della molteplicità)

I messaggi possono essere inviati solo nella direzione della

frecciaOgni docente deve avereun riferimento al propriodipartimento di afferenza




Ogni dipartimento deveavere un riferimento alproprio direttore


A livello di analisi, le associazioni di contenimento edi aggregazione hanno una direzione precisadetti A il contenitore e B l’oggetto contenuto,è A che contiene B, e non viceversa

A livello implementativo, un’associazione può essere mono-direzionale quando

da A si deve poter accedere a B, ma non viceversa bi-direzionale quando

d A i d t d B




da A si deve poter accedere a B eda B si deve poter accedere velocemente ad A


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 docente deve avereun riferimento al propriodipartimento di afferenza

Ogni dipartimento deveavere i riferimenti a tutti isuoi docenti




Implementazione delle associazioni

Associazioni con molteplicità 0..1 o 1..1 Aggiungere alla classe cliente (contenitore)

un attributo membro che rappresenta

il riferimento all’o etto della classe fornitore l’indirizzo di memoria dell’oggetto l’identificatore univoco dell’oggetto (solo se persistente)

il valore dell’oggetto della classe fornitore(solo nel caso di composizione)





effettuaPagamento()

valutaScelta : Valuta

FormaDiPagamento

aggiornaCambio()

idValuta : Stringcambio : DoubledataAggiornamento : Date

Valuta

* 1

ff tt P t ()

idValuta : String

FormaDiPagamento idValuta : Stringcambio : DoubledataAggiornamento : Date

Valuta

*




effettuaPagamento()aggiornaCambio()

dataAggiornamento : Date* 1


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’

per valore, oppure per riferimento

La classe contenitore può essere realizzata, oppure




realizzata, oppure presa da una libreria (preferibilmente)


importoVenditeGiorno()importoVenditeTotale()

creaMovimento()

idPuntoVendita[1]idProgressivo[1] : Integerservizi[1..*] : Servizio

PuntoVendita

Servizio

1..* *

idPuntoVenditaidProgressivo : Integerservizi : Servizi

PuntoVendita

e enca en te




importoVenditeGiorno()importoVenditeTotale()creaMovimento()elencaVendite()

servizi : ServiziServizio

1..* *

Servizi

1 1


creaPuntoVendita()eliminaPuntoVendita()numeroPuntiVendita()

elencaServizi()

puntiVendita[1..*] : PuntoVendita

CatenaPuntiVendita

aggiungiServizio()

owner : CatenaPuntiVenditaPuntoVendita

1

1..*

Servizio Servizi




aggiungiServizio()rimuoviServizio()elencaServizi()

1..* * 1 1


creaPuntoVendita()eliminaPuntoVendita()

numeroPuntiVendita()

elencaServizi()


CatenaPuntiVendita

Servizio

1..* *

Servizi

1 1

aggiungiServizio()


1

1..*




gg g ()rimuoviServizio()elencaServizi()


creaPuntoVendita()eliminaPuntoVendita()numeroPuntiVendita()

elencaServizi()


CatenaPuntiVendita

1

aggiungiServizio()


1

1..*

Servizio

1..* *

Servizi

serviziComuni1

serviziExtra1




rimuoviServizio()elencaServizi()

1


creaPuntoVendita()eliminaPuntoVendita()

numeroPuntiVendita()


CatenaPuntiVendita

CatenaPuntiVendita

owner

11

aggiungiServizio()

owner : CatenaPuntiVendita

PuntoVendita

1

1..*

PuntoVendita

PuntiVendita

1

1




aggiungiServizio()rimuoviServizio()elencaServizi()

1..**

Classi contenitore

Una classe contenitore (o semplicemente contenitore) è unaclasse le cui istanze contengono oggetti di altre classi

Se gli oggetti contenuti sono in numero fisso e non è richiestoun 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 eoccorre una classe contenitore

Esempi di classi contenitore sono Vettori stack liste alberi




Vettori, stack , liste, alberi, …

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




del modo in cui contengono gli oggetti dell’omogeneità o eterogeneità di tali oggetti

Contenimento per valore

L’oggetto contenuto (fornitore) viene memorizzato nella struttura dati del contenitore (cliente) esiste solo in quanto contenuto fisicamente in un altro

oggetto

,viene duplicato

La distruzione del contenitore comportala distruzione degli oggetti contenuti




Contenimento per riferimento

L’oggetto contenuto esiste per conto proprio L’oggetto contenuto può essere in più contenitori

contemporaneamente

Quando un oggetto viene inserito in un contenitore,

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




il contenitore non ne viene avvisato, sorgono grossi problemi

Contenimento dioggetti 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 l’ereditarietà e sfruttare la proprietà cheun puntatore alla superclasse radice della gerarchia può




un puntatore alla superclasse radice della gerarchia puòpuntare a un’istanza di una qualunque sottoclasse

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 tipodesiderato




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à

Vettore

Vettore Integer

«bind» (Integer)




Vettore<Integer>

VettoreDiInteri

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; }

}

Classe generica Stack (C#) public void Push(T item)

{

if (_size == _array.Length)

{

T[] destinationArray = new

T arra .Len th == 0 ? defaultCa acit : _ _

(2 * _array.Length)];

Array.Copy(_array, 0, destinationArray, 0, _size);

_array = destinationArray;

} _array[_size++] = item;

}




Classe generica Stack (C#) 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;

}

Classe generica Stack (C#) public void Clear()

{

// Sets a range of elements in the System.Array

// to zero, to false, or to null,

// depending on the element type.

rra .Clear arra 0 size _ _ _size = 0;

}

} // Stack<T>




…Stack<int> s1;Stack<double> s2;Stack<DateTime> s3;Stack<Stack<int>> s4;

…

Classe generica Stack (C#)

or nt = ; <= ; ++s1.Push(j);

…while (s1.Count > 0)

{int v = s1.Pop();

// utilizzo di v




// utilizzo di v

}

Contenimento di oggetti omogenei

Vector

T

Servizi

«bind»(Servizio)

Servizio

1..**




Contenimento di oggetti eterogenei

È necessario utilizzare l’ereditarietà 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)




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

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 un’associazione tra dueoggetti è tramite un dizionario

Un dizionario è un tipo particolare di contenitore, che associadue oggetti: la chiave e il rispettivo valore

Può essere un oggetto qualsiasi

non necessariamente una stringa o un intero Deve essere unica

Il dizionario, data una chiave, ritrova in modo efficienteil valore ad essa associato





CatenaPuntiVendita PuntoVendita

1..*owner1

CatenaPuntiVendita PuntoVendita

1..*1

Entry

11

*

1

chiave valore

: PuntoVendita

: PuntoVendita

: CatenaPuntiVendita

: CatenaPuntiVendita




: PuntoVendita

Identificazione degli oggetti

Un oggetto (contenitore o no) può contenere unriferimento univoco a un altro oggetto

Come è possibile identificare univocamente un

oggetto per poterlo associare ad un altro?

Nel caso di strutture dati interamente contenute nellospazio di indirizzamento dell’applicazione,

un oggetto può essere identificato univocamentemediante il suo indirizzo (logico) di memoria




Identificazione degli oggetti

Nel caso di database o di sistemi distribuiti, ad ogni oggettodeve essere associato un identificatore univoco persistentetramite il quale deve essere possibile risalire all'oggetto stesso,sia che risieda in memoria, su disco o in rete

L’identificatore univoco è un attributo che al momento dellacreazione dell’oggetto 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




idStudente, …

Identificazione degli oggettiUn esempio reale

La tecnologia COM (MS) permette a un’applicazionedi trovare, caricare e utilizzare run-time i componentinecessari per la sua esecuzione

Ogni componente è memorizzato in una DLL (Dynamic Link Library ) – un file locale o remoto

Quando l’applicazione ha bisogno di un componente,il sistema deve essere in grado di localizzare la DLL

che contiene quel particolare componente





L’indipendenza dalla collocazione fisicanon consente di utilizzare un indirizzo fisico(pathname )

Pertanto, deve essere utilizzato un meccanismo diindirizzamento logico che permetta di identificareunivocamente il file che contiene il componente

Si utilizzano degli identificatori globali(GUID = Globally Unique Identifier )





Il concetto di GUID è stato introdotto, con un nomeleggermente diverso (UUID = Universally Unique Identifier ), dall’OSF (Open Software Foundation )nelle specifiche DCE (Distributed Computing

In DCE gli UUID vengono utilizzati per identificare idestinatari delle chiamate di procedura remota

(RPC)





Un GUID è un numero di 128 bit (16 byte)generato in modo da garantire l’unicità nello spazio enel tempo: MAC (48/64 bit) + ticks (64 bit – 100ns)rappresentato così:

- - - -

COM utilizza diversi tipi di GUID

Il tipo più importante di GUID serve aidentificare le classi di componenti:ogni classe di componenti COM è caratterizzata daun proprio identificatore che viene chiamato




un proprio identificatore che viene chiamato

CLSID (Class Identifier )


Disponendo di un CLSID, un’applicazione puòchiedere alla funzione di sistemaCoCreateInstance di creare un istanza delcomponente e di restituire un riferimento nel spazio

’ Il database di sistema di Windows (registry )

mantiene una corrispondenza tra CLSID ed entità

fisiche (DLL, EXE) che contengono l’implementazionedei componenti (server )





CoCreateInstance provvede a reperire il server tramite il registry

caricarlo in memoria (se non è già presente)

creare un’istanza e restituirne un riferimento





In .NET esiste la classe System.Guid che permettedi gestire istanze di GUID

Ad esempio, per ottenere un nuovo GUID, è

sufficiente invocare il metodo statico Guid.NewGuid() che, ovviamente, restituisce unSystem.Guid

Altri metodi e operatori permettono di confrontareGUID




Controllo della visibilità I tipi di accessi a un membro di una classe (attributo o metodo)

possono essere di tre tipi: public , ovvero visibili dall’esterno (+) private , ovvero non visibili dall’esterno (-)

protected , ovvero visibili all’esterno solo dalle sottoclassi (#) È anche possibile rendere un membro di una classe o una

intera classe visibile solo all’interno del package che contiene laclasse (visibilità di package , internal in .NET)

Infine, dichiarando una classe A friend di una classe B, aimetodi della classe A è concessa la visibilità completa di tutti imembri della classe B (C++)




Controllo della visibilità

Regole Dichiarare private (o protected ) tutti gli attributi

membro

devono essere visibili all’esterno

Dichiarare private o protected tutti gli altri metodi

Non abusare della dichiarazione friend (C++)




Interfaccia vs Classe astratta

Spesso, molte classi concettualmente eterogeneepresentano un insieme di operazioni simili in alcuni casi, un insieme di attributi simili

.

In questi casi, è conveniente

definire e realizzare un protocollo comune a taliclassi definire un’interfaccia o una classe di

generalizzazione comune dalla quale derivano




generalizzazione comune dalla quale derivano

tutte le suddette classi


Un’interfaccia 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 costanticomuni)





Una classe astratta Non può essere istanziata Può essere implementata completamente,

parzialmente o per niente – le classi derivate:

implementate

possono fornire una realizzazione alternativa a

quelle implementate Può contenere uno stato (comune a tutte lesottoclassi)

Può contenere attributi e metodi (e proprietà ed




Può contenere attributi e metodi (e proprietà ed

eventi) statici


Un’interfaccia può “ereditare” Da 0+ interfacce

“ ” Da 0+ interfacce Da 0+ classi (astratte e/o concrete)

minimo 1 classe, nel caso esista una classe radice disistema (ad es., System.Object) massimo 1 classe, nel caso in cui non sia ammessa

l’ereditarietà multipla





Un’interfaccia Deve descrivere una funzionalità semplice

implementabile da oggetti eterogenei (cioèappartenenti a classi non correlate tra di loro)

a esemp o, una c asse pu essere Clonabile (se implementa ICloneable), Vista come una lista (se implementa IList), …

Deve essere stabilese si aggiungesse un metodo a un’interfaccia già inuso, tutte le classi che implementano




quell’interfaccia dovrebbero essere modificate


Una classe astratta Può descrivere una funzionalità anche complessacomune a un insieme di oggetti omogenei(cioè appartenenti a classi strettamente correlate

tra di loro - ad esem io S stem.Enum fornisce le funzionalità di base di tutti i tipi enumerativi Può fornire un’implementazione di default

semplificando la programmazione delle sottoclassi Può essere modificata

quando si aggiunge un metodo a una classeastratta già in uso, è possibile fornireun’implementazione di default in modo tale da non




un implementazione di default , in modo tale da non

dover modificare le sottoclassi


Un’interfaccia Non può gestire la creazione delle istanze delle

classi che la implementanoLa creazione deve essere effettuata

dai costruttori delle suddette classi da (un’istanza di) una classe non correlata,

la cui unica funzionalità è la creazione di istanze

di altre classi (classe factory )





Una classe astratta Può gestire la creazione delle istanze delle sue

sottoclassiLa creazione può essere effettuata

come per l’interfaccia, ma anche da un metodo statico della classe astratta

(metodo factory )




Modifiche per utilizzareil livello di ereditarietà supportato

Se esistono strutture con ereditarietà multipla Se il linguaggio di programmazione non ammette

l’ereditarietà multipla

È necessario convertirele strutture con ereditarietà multiplain strutture con solo ereditarietà semplice





Animale

AnimaleAcquatico Mammifero

pesonome

Delfino

temperatura velocitaInAcquaprofonditaMaxnrCuccioli




Ereditarietà multipla e ripetuta


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 re az on conten mento

In questo modo, le caratteristiche delle superclassi

escluse vengono incorporate nella classespecializzata tramite contenimento e non tramiteereditarietà





Animale

pesonome

1

0,1EssereAcquatico

Delfino

temperatura

velocitaInAcquaprofonditaMax

nrCuccioli




Ereditarietà multipla che diventa associazione


2a

possibilità Appiattire tutto in una gerarchia semplice

In questo modo, una o più relazioni di ereditarietà siperdono e gli attributi e le operazioni corrispondentidevono essere ripetuti nelle classi specializzate





Animale

pesonome

Delfino

temperatura

velocitaInAcquaprofonditaMax

nrCuccioli




Ereditarietà multipla appiattita duplicando attributi e operazioni

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

er m g orare a ve oc t percep ta pu astare la memorizzazione di risultati intermedi un’accurata progettazione dell’interazione con

l’utente (ad es. utilizzando multi-threading ) Un traffico di messaggi molto elevato tra oggetti può

invece richiedere dei cambiamenti per aumentare lavelocità




Miglioramento delle prestazioni Di norma, la soluzione è che un oggetto possa

accedere direttamente ai valori di un altro oggetto(aggirando l’incapsulamento!) Utilizzare metodi inline

Utilizzare la dichiarazione friend

Combinare insieme due o più classi

Questo tipo di modifica deve essere presa inconsiderazione solo dopo che tutti gli altri aspetti del

progetto sono stati soggetti a misure e modifiche L’unico modo per sapere se una modifica contribuirà in

modo significativo a rendere il software “abbastanzaveloce” è tramite le misure e l’osservazione





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 concernedwith the maintainability of the design



Ingegneria del Software T - Design Principles2

What Makes a Design “Bad”?Misdirection: fails to meet requirements

Software Rigidity: a single change affects many other partsof the system

Software Fragility: a single change affects unexpected parts

Software Immobility: it is hard to reuse in anotherapplication

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




Software Rigidity The tendency for software to be difficult to change

Symptom: every change causes a cascade of subsequentchanges in dependent modules

Effect: managers fear to allow developers to fix non-criticalproblems – they don’t 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 unexpectedbehavior in other parts of the system (often in areas that haveno conceptual relationship with the area that was changed)

Symptom: every fix makes it worse, introducing more problems

than are solved

such software is im ossible 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 issimilar to one that another developer wrote. But the module inquestion has too much baggage that it depends upon. After

much work the develo er discovers that the work and riskrequired to separate the desirable parts of the software from theundesirable 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 hacksrather than software changes that preserve original design intent Viscosity of design: the design preserving methods are

harder to em lo than the hacks Viscosity of environment: the development environment is

slow and inefficient (compile times are very long, source codecontrol system requires hours to check in just a few files, …)

Symptom: it is easy to do the wrong thing, but hard to do theright thing

Effect: the software maintainability degenerates due to hacks,workarounds, shortcuts, temporary fixes, …




Why bad design results? Obvious reasons:

lack of design skills/design practices changing technologies time/resource constraints domain complexity, …

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 themost volatile document in the project

If our designs are failing due to the constant rain of changing

requ remen s, s our es gns a are a au

We must somehow find a way to make our designs resilient tosuch 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 themodules of the software

It is the dependency architecture that is degrading, and with itthe ability of the software to be maintained

n or er o ores a e egra a on o e epen encyarchitecture, the dependencies between modules in anapplication must be managed

Object Oriented Design is replete with principles andtechniques for managing module dependencies




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)




PremessaIl 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 sianostrettamente necessari

la forma “colta” di un rinci io ratico: “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




PremessaSemplicità e semplicismo La semplicità è un fattore importantissimo

il software deve fare i conti con una notevole componente dicomplessità, generata dal contesto in cui deve essere utilizzato

quindi è estremamente importante non aggiungere altracomplessità 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)




PremessaDivide 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 direttamentedalla qualità delle scelte di decomposizione adottate

n ques o con es o pr nc p o on amen a e :minimizzare il grado di accoppiamento tra i moduli delsistema

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)

,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 inunexpected ways when changed




The Single Responsibility PrincipleExample

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




The Single Responsibility PrincipleExample

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




The Single Responsibility PrincipleExample – 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 fieldsand methods from the old class into the new class

+ draw()




The Single Responsibility Principle Class should have only one reason to change

Several responsibilities mean several reasons forchanges more frequent changes

The SRP is one of the simplest of the principle,

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

I i d l S ft T D i P i i l




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

May be extended by adding new state or behavioral properties

Closed: Has a well-defined, published and stable interface which may not be

changed

I i d l S ft T D i P i i l




The Open/Closed Principle 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 chan in the source code of the modules

Ingegneria del Software T Design Principles21

Apparentemente si tratta di una contraddizione:come può un modulo immutabile esibire un comportamento che non siafisso nel tempo?

La risposta risiede nell’astrazione:è possibile creare astrazioni che rendono un modulo immutabile,ma rappresentano un gruppo illimitato di comportamenti




The Open/Closed Principle Il segreto sta nell’utilizzo di interfacce (o di classi astratte)

A un’interfaccia immutabile possono corrispondere innumerevoliclassi concrete che realizzano comportamenti diversi

Un modulo che utilizza astrazioni non dovrà mai essere modificato, dal momento che le astrazioni sono

mmu a mo u o c uso per e mo c e potrà cambiare comportamento, se si utilizzano nuove classi che

implementano le astrazioni (il modulo è aperto per le estensioni)





The Open/Closed PrincipleEsempio 1


Supponiamo di dover utilizzare un nuovo tipo di server!






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





CircleData

radius : float

center : Point

SquareData

origin : Point

length : float

width : float

ShapeData

shapeType : int


ShapeManipulator

drawShape(s hapeData : ShapeData)

drawCircle(circle : CircleData)

drawSquare(s quare : SquareData)

{

switch (shapeData.shapeType)

{

case SQUARE:

drawSquare((SquareData)shapeData);

break;

case CIRCLE:

drawCircle((CircleData)shapeData);

break;}

}



g g g p26

The Open/Closed PrincipleEsempio 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 isrepeated over and over again for every kind of operation that canbe performed on a shape


, sw c casestatement retains a dependency upon every possible shapethat can be drawn, thus, whenever one of the shapes is modifiedin any way, the modules all need recompilation, and possibly

modification



g g g p27


ShapeInterface

draw()

move()

<<Interface>>

SmartShapeManipulator

drawShape(shape : ShapeInterface)


Circle

draw()

move()

Square

draw()

move()

public void

drawShape(ShapeInterface shape)

{

shape.draw ();

}



The Open/Closed Principle 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


t e wor ng co e s not expose to rea age

Even if the OCP cannot be fully achieved, even partialOCP compliance can make dramatic improvements in

the structure of an application



The Open/Closed Principle1. 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



The Open/Closed PrincipleDefine 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 aparticular service

Postconditions

The properties that are guaranteed to exist after the service is

performed, if it operates without error



The Open/Closed PrincipleMake all object data private

Changes to public data are always at great risk to “open” themodule: 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 Module B

Module C Module D

Shared data

area

Module A

A’s data

Module B

B’s data

Module D

D’s data

Module C

C’s data



The Dependency Inversion Principle Depend upon abstractions

Do not depend upon concretions

High level modules should not depend on low level modulesBoth should depend on abstractions

Abstractions should not depend on details


DIP is the strategy of depending upon interfaces or abstractfunctions and classes, rather than upon concrete functions andclasses

Every dependency should target an interface, or an abstractclass

No dependency should target a concrete class



The Dependency Inversion Principle 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 dibasso livello (sono accoppiati in modo troppo stretto), icambiamenti si ro a ano e le conse uenze 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



The Dependency Inversion Principle 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 di endere da astrazioni


le astrazioni non dovrebbero dipendere dai dettagli i dettagli dovrebbero dipendere dalle astrazioni



The Dependency Inversion Principle Vediamo perché questo principio funziona:

le astrazioni contengono pochissimo codice (in teoria nulla) e quindisono poco soggette a cambiamenti

i moduli non astratti sono soggetti a cambiamenti ma questicambiamenti sono sicuri perché nessuno dipende da questi moduli

In sostanza abbiamo invertito la direzione della di endenza 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)




The Dependency Inversion PrincipleDependency Structure of a Procedural Architecture

main

HighLevelFn1 HighLevelFn2 HighLevelFn3


LowLevelFn1 LowLevelFn2 LowLevelFn3 LowLevelFn4



The Dependency Inversion PrincipleDependency Structure of an OO Architecture

HighLevel

AbstractInterface1

<<Interface>>

AbstractInterface2

<<Interface>>

AbstractInterface3

<<Interface>>

DetailImpl1 DetailImpl2 DetailImpl3




The Dependency Inversion Principle 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)




The Dependency Inversion Principle

Esempio 1 Consider a simple program that

is charged with the task of

copying characters typed on akeyboard to a printer

Assume, furthermore, that theimplementation platform does not


supports device independence

void Copy()

{

int c;

while ((c = ReadKeyboard()) != EOF)

WritePrinter(c);

}




Esempio 1 The two low level modules are

reusable: they can be used in

many other programs to gainaccess to the keyboard and theprinter – this is the same kind ofreusability that we gain fromsubroutine libraries

“ ”


reusable in any context whichdoes not involve a keyboard or aprinter

This is a shame since theintelligence of the system ismaintained in this module – it isthe “Copy” module thatencapsulates a very interestingpolicy 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 newdesired functionality

enum OutputDevice{Printer,

Disk};

void Copy(OutputDevice dev){


,more devices must participate inthe copy program, the “Copy”module will be littered withif/else statements and will be

dependent upon many lowerlevel modules it will eventually become rigidand fragile

n c;while ((c = ReadKeyboard())!= EOF){if (dev == Printer) WritePrinter(c);

else WriteDisk(c);}

}




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 (WritePrinterand ReadKeyboard)

If we could find a way to make the Copy module independent ofthe 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




Esempio 1interface Reader

{

int Read();

}

interface Writer

{


}

void Copy(Reader r, Writer w)

{

int c;

while ((c = r.Read()) != EOF)

w.Write(c);

}




Esempio 2


E se volessimo accendere un motore?




Esempio 2





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)


organizzati a livelli

Le dipendenze transitive devono essere eliminate

Policy

Layer

Mechanism

Layer

Utility

Layer

Depends on Depends on




Dipendenze transitive

PolicyLayer

Depends on

Depends on

Mechanism Interface


ec an smLayer

UtilityLayer

t ty Interface



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 aderivative of that base class is passed to it

In altre parole: un cliente che usa istanze di una classe A devepoter usare istanze di una qualsiasi sottoclasse di A

senza accorgersi della differenza



The Liskov Substitution Principle

Example

Policy

getUnitsOfRisk()

getPolicyCoverages()

getRateSteps()

PolicyRateModule

This module should not break

AutoPolicy

PersonalAutoPolicy CommercialAutoPolicy

regardless of whether a PersonalAuto or Commercial Auto or Home

Owner Policy is passed to it

HomeOwnerPolicy




The Liskov Substitution Principle

Example




The Liskov Substitution Principle OCP si basa sull’uso di classi concrete derivate da un astrazione

(interfaccia o classe astratta)

LSP costituisce una guida per creare queste classi concretemediante l’ereditarietà

La principale causa di violazioni al principio di Liskov è dato dalla

r e n z one me o v r ua ne e c ass er va e:è qui che bisogna riporre la massima attenzione

La chiave per evitare le violazioni al principio di Liskov risiedenel Design by Contract (B. Meyer)




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 eseguitocorrettamente 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 chiinvoca il metodo (cliente) e il metodo stesso (e quindi la classe a cuiappartiene) 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




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 contrattodefinito 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 sullaclasse derivata e questo porterebbe a una violazione del principio diLiskov




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;

}}



Il Quadrato è un Rettangolo? public class Rectangle

{

private double _width;

private double _height;

public double Width

{

get { return _width; }

set { _width = value; }

}

Imagine that this applicationworks well, and is installed in

many sites As is the case with all

successful software, as itsusers’ needs change, new


public double Height

{

get { return _height; }

set { _height = value; }

}

public double Area{

get { return Width * Height; }

}

}

functions are needed Imagine that one day the

users demand the ability tomanipulate squares in

addition to rectangles



Il Quadrato è un Rettangolo? Inheritance is the IsA relationship

In other words, if a new kind of object

can be said to fulfill the IsA relationshipwith an old kind of object, then theclass of the new object should bederived from the class of the old object


Clearly, a square is a rectangle for allnormal intents and purposes

Since the IsA relationship holds, it islogical to model the Square class as

being derived from Rectangle



Il Quadrato è un Rettangolo? 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, yetsi nificant roblems

Generally these problem are not foreseen until we actually try tocode the application




Il Quadrato è un Rettangolo? public class Square : Rectangle

{

public new double Width

{

get { return base.Width; }

set

{

base.Width = value;

base.Height = value;

È necessario ridefinire leproprietà Width e Height…

Notevoli differenze tra Java eC++ / C# In Java tutti i metodi sono

virtuali


}

public new double Height

{

get { return base.Height; }

set

{

base.Height = value;

base.Width = value;

}

}

}

In C++ / C# è possibiledefinire sia metodi virtuali, sia metodi non virtuali

(non polimorfici)



Il Quadrato è un Rettangolo?…

Square s = new Square();

s.Width = 5; // 5 x 5

…… Method1(s); // ?

…

void Method1(Rectangle r)

If we pass a reference to aSquare object into Method1,

the Square object will becorrupted because the heightwon’t be changed (!)

This is a clear violation of LSP

{r.Width = 10;

}

derivatives of its arguments The reason for the failure is

that Width and Height were

not declared virtual in

Rectangle




Il Quadrato è un Rettangolo? public class Rectangle

{

…

public virtual double Width

{ … }

public virtual double Height

{ … }

We can fix this easily However, when the creation of a

derived class causes us to makechanges to the base class, it oftenimplies that the design is faulty

Indeed, it violates the OCP We mi ht counter this with ar ument


…

}

public class Square : Rectangle

{

public override double Width

{ … }

public override double Height

{ … }

}

that forgetting to make Width andHeight virtual was the real designflaw, and we are just fixing it now

However, this is hard to justify sincesetting the height and width of a

rectangle are exceedingly primitiveoperations – by what reasoning wouldwe make them virtual if we did notanticipate the existence of square



Il Quadrato è un Rettangolo? 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 witha mathematical square

And regardless of what you do to a Rectangle object, it will remain amathematical rectangle

oreover, you can pass a Square nto a unct on t at accepts areference to a Rectangle, and the Square will still act like a squareand will remain consistent

Thus, we might conclude that the model is now self consistent, andcorrect

However, a model that is self consistent is not necessarilyconsistent with all its users!




Il Quadrato è un Rettangolo? public void Scale(Rectangle rectangle)

{

rectangle.Width = rectangle.Width * ScalingFactor;rectangle.Height = rectangle.Height * ScalingFactor;

}

Substituing a Square into this will result in the square being scaledtwice!

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?




Il Quadrato è un Rettangolo? Clearly, the programmer of Scale made this very reasonable

assumption

Passing a Square to functions whose programmers made thisassumption will result in problems

Therefore, there exist functions that take references toRectan le ob ects, but cannot o erate ro erl u on S uare

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




Il Quadrato è un Rettangolo? Why did the model of the Square and Rectangle go bad

After all, isn’t a Square a Rectangle?

Doesn’t 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 notconsistent with the behavior of a Rectangle object

Behaviorally, a Square is not a Rectangle! And it is behaviorthat software is really all about




Il Quadrato è un Rettangolo? 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 varyinde endentl of one another.

That independence of the two variables is an extrinsic publicbehavior that other programmers are likely to depend upon

In order for the LSP to hold, and with it the OCP, all derivativesmust conform to the behavior that clients expect of the base

classes that they use




Il Quadrato è un Rettangolo? 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 thebase class

,

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 baseclass

their behaviors and outputs must not violate any of the constraintsestablished for the base class




Il Quadrato è un Rettangolo? 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




Il Quadrato è un Rettangolo? 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]

ublic void SetHei htAndWidth()

{ 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);}

}




Il Quadrato è un Rettangolo?[TestFixture] public class RectangleFixture

{

[Test] public void SetHeightAndWidth()

{

Rectangle rectangle = GetShape();

...

}

pro ec e v r ua ec ang e e ape

{ return new Rectangle(); }

}

[TestFixture] public class SquareFixture : RectangleFixture

{

protected override Rectangle GetShape()

{ return new Square(); }

}




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, ratherthan loading the class with all the methods that theclients need, create specific interfaces for each type

of client and multiply inherit them into the class



The Interface Segregation PrincipleFat Service with Integrated Interfaces

ClientA

ClientB

Service

<<Interface>>

ClientC

clientAMethods()clientBMethods()

clientCMethods()




The Interface Segregation PrincipleSegregated Interfaces

ClientA ClientAService

clientAMethods()

<<Interface>>

<<Interface>>ServiceImpl

ClientC

clientBMethods()

ClientCService

clientCMethods()

<<Interface>>

clientAMethods()clientBMethods()

clientCMethods()




The Interface Segregation Principle Without segregation whenever a change is made to one of the

methods that ClientA calls, ClientB and ClientC may beaffected: 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 foreach type of client should be created.If two or more different client types need the same method, the methodshould be added to both of their interfaces



The Interface Segregation Principle Le fat interfaces derivano da classi i cui metodi possono essere

suddivisi in gruppi in cui ogni gruppo viene utilizzato da un diversoinsieme di client

ISP suggerisce che i client non dovrebbero vedere i gruppi di metodicome una singola classe ovvero i client non dovrebbero dipendere dainterfacce che non utilizzano

(inutile) fra i client per mezzo della fat interface Se un client richiede l’aggiunta di una nuova funzionalità all’interfaccia

ogni altro client è costretto a cambiare anche se non è interessato allanuova funzionalità

Questo crea un’inutile sforzo di manutenzione e può rendere difficiletrovare eventuali errori




Principles of Package Architecture The Reuse/Release Equivalency Principle

(REP) The Common Closure Principle (CCP) The Common Reuse Principle (CRP)




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 ofclasses, cannot be reused unless it is managed by a releasesystem of some kind

Clients will/should refuse to reuse an element unless the author


promises to keep track of version numbers, and maintain oldversions for awhile one criterion for grouping classes intopackages is reuse

Since packages are the unit of release in JAVA, they are also the

unit of reuse. Therefore architects would do well to groupreusable classes together into packages



The Common Closure Principle Classes that change together, belong together

The work to manage, test, and release a package is non-trivial ina large system.The more packages that change in any given release, thegreater the work to rebuild, test, and deploy the release we


would like to minimize the number of packages that arechanged in any given release cycle of the product

To achieve this, we group together classes that we think willchange together



The Common Reuse Principle Classes that aren’t reused together should not be grouped

together

A dependency upon a package is a dependency upon everythingwithin the package.When a package changes, and its release number is bumped, all


clients of that package must verify that they work with the newpackage - even if nothing they used within the package actuallychanged

Hence, classes that aren’t reused together should not begrouped together in a package



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 oneacka e will ever chan e . 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 andmaintenance. Later, as the architecture stabilizes, the architects

may re-factor the package structure to maximize REP and CRPfor the external re-users



Relationships between Packages The Acyclic Dependencies Principle (ADP)

The Stable Dependencies Principle (SDP) The Stable Abstractions Principle (SAP)




The Acyclic Dependencies Principle The dependencies between packages must not form cycles

Once changes to a package are made, developers can releasethe packages to the rest of the project. Before they can do thisrelease, however, they must test that the package works. To dothat, they must compile and build it with all the packages itdepends upon

A single cyclic dependency that gets out of control can make thedependency list very long

Hence, someone needs to be watching the package dependency

structure with regularity, and breaking cycles wherever theyappear




The Acyclic Dependencies Principle

Example: Acyclic Package Network

gui

comm process

modem protocol

comm_error

file





Example: Cyclic Package Networkgui

comm process

modem protocol

comm_error

file





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 thecomm_error, gui, comm, process, modem, file and run their tests

Breaking the cycle: Add new package in between Add a new Interface





Breaking Cycle by introducing an Interface

A

B

X

Y

A

B

X

YBInterfaceimplements




The Stable Abstractions Principle Stable packages should be abstract packages

Stability is related to the amount of work required tomake a change

A package with lots of incoming dependencies is very


stable because it requires a great deal of work toreconcile any changes with all the dependentpackages



The Stable Abstractions Principle

Example

A B C

X is a stable

package; hence it

should be abstract

X




The Stable Abstractions Principle

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 dependencynetwork may be very difficult to change, but according to theOCP they do not have to be difficult to extend. If the stableacka es at the bottom are also hi hl abstract then the 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 toextend





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 t 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

nvece c e pare e por e…




Design Pattern Obiettivi

Risolvere problemi progettuali specifici Rendere i progetti object-oriented più flessibili eriutilizzabili

Ogni design pattern

Cattura e formalizza l’esperienza acquisitanell’affrontare e risolvere uno specifico problemaprogettuale

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èli elementi che lo com on ono classi e istanze e

le loro relazioni, responsabilità e collaborazioni le conseguenze – descrivono vantaggi e

svantaggi dell’applicazione 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 roblemi inerenti

Ingegneria del Software T - Design Pattern6

la composizione di classi o di oggetti Pattern comportamentali (behavioral pattern )

Risolvono problemi inerenti

le modalità di interazione e di distribuzione delleresponsabilità tra classi o tra oggetti



Classificazione dei Design Pattern Pattern

di creazionePattern

strutturali Pattern

comportamentali

Abstract FactoryBuilderFactory Method

AdapterBridgeComposite

Chain of ResponsabilityCommandInterpreter


ro o ype

Singleton

ecora or

FacadeFlyweightProxy

era or

MediatorMementoObserverState

StrategyTemplate MethodVisitor



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 arantire

che nessuna altra istanza venga creata fornire un modo per accedere all’istanza 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 ordinenon 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



Pattern SINGLETON public static Singleton GetInstance()

{

if(_instance == null)

_instance = CreateInstance();return _instance;

}


private static Singleton CreateInstance()

{

if(…)

return new SubSingletonA();

else if(…)

return new SubSingletonB();else

return new 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 daun oggetto non condiviso

Non deve fare ipotesi sul contesto nel quale opera



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 unaFlyweightFactory


e ywe g ey

{if(flyweights[key] not exist)

create flyweights[key]return flyweights[key]

}



Pattern FLYWEIGHT Dichiara un’interfaccia tramite la quale i flyweight possonoricevere dal cliente lo stato estrinseco e operareGestisce lo stato estrinseco


Implementa l’interfaccia ememorizza lo stato intrinseco

Crea i flyweightGestisce la condivisione dei flyweight



Pattern FLYWEIGHT

Esempio Si supponga di usare il pattern flyweight per

condividere delle icone tra vari clienti


P FLYWEIGHT



Pattern FLYWEIGHT

Esempio Lo stato intrinseco (memorizzato nel flyweight)

comprenderà tutte le informazioni che i clienti devono

(e possono) condividere: Nome dell’icona Bitmap dell’icona


mens on or g na , …

Lo stato estrinseco (memorizzato nel cliente)comprenderà il contesto in cui l’icona dovrà esseredisegnata (dipendente dal singolo cliente): Posizione dell’icona 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


Algorithm()

«interface»Strategy

Algorithm()

ConcreteStrategy1

Algorithm()

ConcreteStrategy2

Algorithm()

ConcreteStrategy3

ClientInterface()

en

* 1



Pattern STRATEGY

Algorithm()

«interface»Strategy

ClientInterface()

Client

* 1

Dichiara un’interfaccia comunea tutti gli algoritmi supportati


Algorithm()

ConcreteStrategy1

Algorithm()

ConcreteStrategy2

Algorithm()

ConcreteStrategy3

Implementa l’interfaccia e forniscel’implementazione di un algoritmo

Referenzia l’oggetto che implementa unalgoritmoPuò dichiarare un’interfaccia che permettaall’oggetto Strategy di accedere ai dati delcliente

P tt STRATEGY



Pattern STRATEGY

Esempio Allineamento del testo di un paragrafo

Esistono politiche diverse di allineamento


Pattern STRATEGY



Pattern STRATEGY

Esempio AlignerBase

suddivide il testo in linee (Format)

delega alle sue sottoclassi l’allineamento delle singole linee(FormatLine)

Paragraph utilizza i servizi di un “Aligner” specificato


nam camen e run- me

È possibile realizzare gli “Aligner” utilizzando il patternflyweight

Esempio



Pattern ADAPTER

Converte l’interfaccia originale di una classenell’interfaccia (diversa) che si aspetta il cliente

Permette a classi che hanno interfacce incompatibilidi lavorare insieme


usa quan o si vuole riutilizzare una classe esistente e la sua interfaccia non è conforme a quella

desiderata

Noto anche come wrapper



Pattern ADAPTER

Operation()

Target

Client

Dichiara l’interfaccia cheil cliente vuole vedere

Utilizza l’oggetto tramite l’interfaccia di Target


a aptee

Operation() SpecificOperation()1 1

adaptee.SpecificOperation()

Definisce un’interfaccia proprietaria,diversa da quella che il cliente vuole vedere

Adatta l’interfaccia di Adapteeall’interfaccia di Target



Pattern ADAPTER

In C++, si potrebbe scrivere:class Adapter : public Target, private Adaptee

Cioè ereditare l’interfaccia di Target el’implementazione di Adaptee


In un linguaggio in cui non è ammesso ereditarel’implementazione, conviene utilizzare lacomposizione

Esempio



Pattern DECORATOR

Permette di aggiungere responsabilità a un oggettodinamicamente

Fornisce un’alternativa flessibile allaspecializzazione In alcuni casi le estensioni ossibili sono talmente tante che


per poter supportare ogni possibile combinazione, si dovrebbedefinire un numero troppo elevato di sottoclassi



Pattern DECORATOR

TextBox BorderTextBox FilledTextBox VerticalTextBox BorderFilledTextBox BorderVerticalTextBox


BorderFilledVerticalTextBox FilledVerticalTextBox

E se volessi 2 o più bordi

Cambiare il font …



Pattern DECORATOR

Operation()

Component

ConcreteComponent Decorator component

1

component

Operation() Operation() *

Operation()

AddedState

ConcreteDecoratorA

Operation()AddedBehaviour()

ConcreteDecoratorB

component.Operation()

base.Operation()AddedBehaviour()


P DECORATOR



Pattern DECORATOR

Component (interfaccia o classe astratta) Dichiara l’interfaccia di tutti gli oggetti

ai quali deve essere possibile aggiungere dinamicamenteresponsabilità

ConcreteComponent


e n sce un po ogge o a qua e eve essere poss e

aggiungere dinamicamente responsabilità Decorator (classe astratta)

Mantiene un riferimento a un oggetto di tipo Component edefinisce un’interfaccia conforme all’interfaccia di Component

ConcreteDecorator Aggiunge responsabilità al componente referenziato

Pattern DECORATOR



Pattern DECORATOR

«interface»IComponent

TextFrame Decorator

component

*

1

component

Bordered Filled Text

Bordered Bordered

BorderedFrame FilledFrame VerticalTextFrame


Esempio

E dit i tà di i



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 dell’ereditarietà è che sia validoil 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

E dit i tà di i



Rettangolo

+ «property» Altezza : double

+ «property» Larghezza : double

- _altezza : double

- _larghezza : double+ «get» Altezza ( )+ «set» Altezza ( )

+ «get» Larghezza ( )

+ «set» Larghezza ( )

ModificatoreDiDimensioni

+ Modifica ( )«use»

Ereditarietà dinamica

Un quadrato è un rettangolo con la soladifferenza che altezza e larghezza devono essereuguali

Esempio S1

Quadrato


+ «property» Larghezza : double+ «property» Lato : double

+ «get» Altezza ( )+ «set» Altezza ( )

+ «get» Larghezza ( )+ «set» Larghezza ( )

+ «get» Lato ( )

+ «set» Lato ( )

n qua rato a un v nco o n p r spetto a

rettangolo In realtà, una sotto-classe

Deve supportare tutto il comportamento dellaclasse base ed eventualmente aggiungerne dinuovo (extends)

Può modificare alcuni aspetti del comportamento NON può e non deve aggiungere vincoli

comportamentali alla classe base!


E dit i tà di i



Ereditarietà dinamica Il metodo Modifica della classe ModificatoreDiDimensioni

funziona correttamente su un Rettangolo

ma NON funziona correttamente su un Quadrato

Quindi non è possibile passare un’istanza di Quadrato dove è’


Liskov è violato!)

Conclusione: un quadrato NON è un rettangolo perché pone deinuovi vincoli al concetto di rettangolo

Come possiamo tenere conto di ciò che il rettangolo e il quadratohanno in comune?




Ereditarietà dinamica«interface»

IParallelogramma



+ «get» Altezza ( )

+ «set» Altezza ( )+ «get» Larghezza ( )


Esempio S2


Rettangolo



- _altezza : double

- _larghezza : double





+ Modifica ( )«use»

Quadrato



+ «property» Lato : double

- _lato : double




+ «get» Lato ( )

+ «set» Lato ( )




Ereditarietà dinamica 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




Ereditarietà dinamica 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


e n sco qua ro c ass concre e c e er vano a a c asse as ra a

Parallelogramma (o implementano IParallelogramma):Rettangolo, Quadrato, Rombo, ParallelogrammaGenericoUso 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, unrombo o un parallelogramma generico




Ereditarietà dinamica2. Lati e angoli sono modificabili

Definisco un’unica classe concreta Parallelogramma le cui istanzepossono comportarsi a seconda del loro stato come: un rettangolo,

un quadrato, un rombo, o un parallelogramma generico





Ereditarietà dinamica Come può un oggetto cambiare comportamento,

al cambiare del suo stato?

1a

possibilità: si cambia la classe dell’oggetto run-time – nellamaggior parte dei linguaggi di programmazione a oggetti, questonon è possibile (inoltre, è meglio che un oggetto non possacambiare 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 unmeccanismo di delega, grazie al quale l’oggetto è in grado dicomportarsi come se avesse cambiato classe

Pattern STATE



Pattern STATE

AbstractState

+ Handle ( )

ConcreteStateA

ConcreteStateB

Context

+ Operation ( )

- _state

1

Operation()

{ _state.Handle(); }


Localizza il comportamento specifico di uno stato e suddivide ilcomportamento in funzione dello stato

Le classi concrete contengono la logica di transizione da uno

stato all’altro Permette anche di emulare l’ereditarietà multipla

Pattern STATE



Pattern STATE

Parallelogramma



+ «property» Nome : string

+ «property» Colore : Color- _altezza : double

- _larghezza : double

+ Parallelogramma ( )

- StateChanged ( )

Tipo

+ «property» Nome : string

+ «property» Colore : Color

+ DeterminaTipo ( )

+ «get» Nome ( )

+ «get» Colore ( )

- _tipo


+ Modifica ( ) «use»

+ «set» Altezza ( )

+ «get» Larghezza ( )+ «set» Larghezza ( )

+ «get» Nome ( )


TipoRettangolo

+ «property» Nome : string+ «property» Colore : Color

+ «get» Nome ( )


TipoQuadrato

+ «property» Nome : string+ «property» Colore : Color

+ «get» Nome ( )


Esempio S3

39Ingegneria del Software T - Design Pattern

Pattern COMPOSITE



Pattern COMPOSITE

Permette di comporre oggetti in una struttura ad albero, al finedi rappresentare una gerarchia dioggetti contenitori-oggetti contenuti

Permette ai clienti di trattare in modo uniformeoggetti singoli e oggetti composti


children

Pattern COMPOSITE



Pattern COMPOSITE

Component (classe astratta) Dichiara l’interfaccia Realizza il comportamento di default

Client Accede e manipola gli oggetti della composizione

attraverso l’interfaccia di Component


children

Pattern COMPOSITE



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

Pattern COMPOSITE



Pattern COMPOSITE

Component

1

*

parent

Components

0..1child

*

children


Il contenitore dei figli deve essere un attributo di Composite epuò essere di qualsiasi tipo (array , lista, albero, tabella hash , …)

Composite

10..1

Pattern COMPOSITE



Pattern COMPOSITE

Riferimento esplicito al genitore (parent ) Semplifica l’attraversamento e la gestione della struttura

L’attributo che contiene il riferimento al genitore e la relativagestione devono essere posti nella classe Component Invariante


componente devono essere (gli unici) figli di quel componente incapsulare l’assegnamento di parent nei metodi Add eRemove della classe Composite, oppure

incapsulare le operazioni di Add e Remove nella setdell’attributo parent della classe Component

Pattern COMPOSITE



Pattern COMPOSITE

public class Composite : Component

{

…

public void Add(Component aChild)

{

=


throw new ArgumentException(…);

_children.Add(aChild);

aChild._parent = this;

}

…}

Pattern COMPOSITE



Pattern COMPOSITE

public class Composite : Component

{

…

public void Remove(Component aChild){

if(aChild.Parent != this)


…

if(!_children.Contains(aChild))throw new ArgumentException(…);

_children.Remove(aChild);

aChild._parent = null;

}

…

}

Pattern COMPOSITE



Pattern COMPOSITE public class Component

{

…

public Composite Parent

{get { return _parent; }

set

{


= _

{

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 l’interfaccia diComponent► in Component devono essereinserite tutte le operazioni che devono essere


utilizzate dai clienti - nella maggior parte dei casi,Component definisce una realizzazione di defaultche le sotto classi devono ridefinire

Alcune di queste operazioni possono essere prive

di significato per gli oggetti foglia( Add, Remove, …)

Pattern COMPOSITE



TrasparenzaDichiaro tutto al livello più alto, in modo che il cliente

possa trattare gli oggetti in modo uniformema… il cliente potrebbe cercare di fare cose senzasenso, come aggiungere figli alle foglie


Se scegliamo la trasparenza Add e Remove devono avere una realizzazione di default

che genera un’eccezione dovremmo disporre di un modo per verificare se è possibile

aggiungere figli all’oggetto su cui si vuole agire

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);

Pattern COMPOSITE



SicurezzaTutte le operazioni sui figli vengono messe in

Composite – a questo punto, qualsiasi invocazionesulle foglie genera un errore in fase di compilazionema… il cliente deve conoscere e gestire due


interfacce differenti

Se scegliamo la sicurezza dobbiamo disporre di un modo per verificare se l’oggetto su

cui si vuole agire è un Composite

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);

Pattern VISITOR



Permette di definire una nuova operazione da effettuare su glielementi di una struttura, senza dover modificare le classidegli elementi coinvolti

Ad esempio, si consideri la rappresentazione di un programmacome “abstract syntax tree ” (AST) – un albero i cui nodi


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 l’albero in un formato leggibile …

Pattern VISITOR



Per l’AST utilizziamo il pattern Composite

optimize()generateCode()print()

ComponentNode

Client

root

1


LeafNode CompositeNode

optimize()

generateCode()print()

VariableNode

optimize()


ConstantNode

optimize()


AssignmentNode

Pattern VISITOR



In seguito potremmo voler effettuare altri tipi di operazioni controllare che le variabili siano state inizializzate prima

dell’uso ristrutturare automaticamente il programma calcolare varie metriche


…

Se distribuiamo le operazioni sui vari tipi di nodo, otteniamo unsistema che è difficile da capire

manutenere modificare

Pattern VISITOR



La soluzione è quella di eliminare le singole operazioni dall’AST(la cui responsabilità principale è quella di rappresentare unprogramma sotto forma di albero)

Tutto il codice relativo ad un singolo tipo di operazione (ades. generazione del codice) viene raccolto in una singolaclasse


I nodi dell’AST devono accettare la visita delle istanze di queste

nuove classi (visitor ) Per aggiungere un nuovo tipo di operazione, è sufficiente

progettare una nuova classe

Pattern VISITOR



Il Visitor deve dichiarareun’operazione per ogni tipo di nodo concreto

VisitVariable(in node : VariableNode)VisitConstant(in node : ConstantNode)

NodeVisitor


s ss gnmen n no e : ss gnmen o e

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

Pattern VISITOR



Ogni nodo deve dichiarareun’operazione per accettare un generico visitor

Accept(in v : NodeVisitor)

ComponentNode Client

root

1


LeafNode CompositeNode


VariableNode


ConstantNode


AssignmentNode

v.VisitVariable(this) v.VisitConstant(this) v.VisitAssignment(this)

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 l’operazione da effettuare sulla


VisitConcreteElementA(in e : ConcreteElementA)VisitConcreteElementB(in e : ConcreteElementB)

Visitor

VisitConcreteElementA(in e : ConcreteElementA)VisitConcreteElementB(in e : ConcreteElementB)

ConcreteVisitor1

VisitConcreteElementA(in e : ConcreteElementA)

VisitConcreteElementB(in e : ConcreteElementB)

ConcreteVisitor2

Pattern VISITOR



Element (classe astratta o interfaccia) Dichiara un metodo Accept che accetta un Visitor come

argomento

ConcreteElement Definisce il metodo Accept


Accept(in v : Visitor)

Element

ObjectStructure


ConcreteElementA


ConcreteElementB

v.VisitConcreteElementA(this) v.VisitConcreteElementB(this)

Pattern VISITOR



ObjectStructure Può essere realizzata come Composite o come normale

collezione (array , lista, …) Deve poter enumerare i suoi elementi Deve dichiarare un’interfaccia che permetta a un cliente di far

visitare la struttura a un Visitor


Visitor

Element ObjectStructure

Client

Pattern VISITOR



Facilita l’aggiunta 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 dataoperazione Nasconde i dettagli di come tale operazione debba essere

eseguita

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


necessar o nser re un nuovo meto o Visit

in tutti i Visitor esistenti► la gerarchia Element deve essere poco o per nullamodificabile – cioè essere stabile

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 l’operazione ogni Visitor può modificare il proprio

stato – ad esempio, per accumulare dei valori o altro

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);

}

…}

Pattern VISITOR



: ObjectStructure a : ConcreteElementA

v : ConcreteVisitor1

b : ConcreteElementB

Accept

: Client

new()

VisitConcreteElementA(a)

Accept(v)

OperazioneX()

(v)


Accept(v) VisitConcreteElementB

OperazioneY()

(b)

Pattern VISITOR



Double dispatch

L’operazione che deve essere effettuata dipende

dal tipo di due oggetti il visitor

l’elemento


Accept è un’operazione di tipo double dispatch

Esempio + EsempioDecorator

Il Pattern

Model / View / Controller (MVC)



Model / View / Controller (MVC) Utilizzato per realizzare le interfacce utenti in Smalltalk-80

Permette di suddividere un’applicazione, o anche la solainterfaccia dell’applicazione, in tre parti Modello elaborazione / stato View (o viewport ) output


on ro er npu

Il Pattern




Model / View / Controller (MVC)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 notificadell’evento

In Java, deve estendere la classejava.util.Observable

Il Pattern




Model / View / Controller (MVC)View

Gestisce un’area di visualizzazione, nella quale presentaall’utente una vista dei dati gestiti dal modello

Mappa i dati (o parte dei dati) del modello in oggetti visuali


Si registra presso il modello per ricevere l’evento dicambiamento di stato

In Java, deve implementare l’interfacciajava.util.Observer

Il Pattern




Model / View / Controller (MVC)Controller

Gestisce gli input dell’utente(mouse, tastiera, …)

Mappa le azioni dell’utente in comandi


operazioni appropriate

In Java, è un listener

Il Pattern




Model / View / Controller (MVC)InputOutput


Model

Esempio




Introduzione alFramework .NET

Tecnologia COMComponent Object Model



1993 COM is a platform-independent, distributed,

object-oriented system for creating binarysoftware components that can interact

I n g e gn

COM is not an object-oriented language but a

standard

COM specifies an object model and

programming requirements that enable COMobjects to interact with other objects

er i a d el S of t w ar eT

2




interface IUnknown

{

virtual HRESULT QueryInterface(IID iid, void **ppvObject) = 0;

virtual ULONG AddRef(void) = 0;

virtual ULONG Release(void) = 0;

};I n g e gn

QueryInterface is used to obtain a pointer to another interface,

given a GUID that uniquely identifies that interface (commonlyknown as an interface ID, or IID) – if the COM object does notimplement that interface, an E_NOINTERFACE error is returnedinstead

AddRef is used by clients to indicate that a COM object is beingreferenced Release is used by clients to indicate that they have finished

using the COM object


3




I n g e gn

The COM specifications require a technique calledreference counting to ensure that individual objects

remain alive as long as there are clients which haveacquired access to one or more of its interfaces and,conversel that the same ob ect is ro erl dis osed e

r i a d el S of t w ar eT

4

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 ormore objects are circularly referenced




I n g e gn

Ereditarietà solo con composizione e delega

interface IService2 : IService1


5

Component1

IService1

Component2

IService2




I n g e gn

The location of each component is stored in theWindows registry

There can be only one version of a certain componentinstalled


6

deployment of COM-based applications, due to thepossibility that different programs, or even differentversions of the same program, may be designed towork with different versions of the same COM

component This condition is known as DLL hell

Framework .NET



I n g e gn

È un ambiente di esecuzione(runtime environment ) – 2002 v.1.0

Semplifica lo sviluppo e il deployment

’ er i a d el S of t w ar eT

7

Unifica il modello di programmazione È completamente indipendente da COM È fortemente integrato con COM

Sviluppo semplificato



I n g e gn

Ambiente object-oriented

– Qualsiasi entità è un oggetto – Classi ed ereditarietà pienamente supportati – Anche tra linguaggi diversi


8

Riduzione errori comuni di programmazione – Linguaggi fortemente tipizzati – Type Checker

– Errori non gestiti – generazione di eccezioni – Meno memory leak – Garbage Collector

Indipendenza dalla piattaforma



I n g e gn

.NET è un’implementazione di CLI – Common Language Infrastructure

CLI e il linguaggio C# sono standard ECMA – ECMA-334 C# , ECMA-335 CLI e

r i a d

el S of t w ar eT

9

Esistono altre implementazioni di CLI: – SSCLI (Shared Source CLI by Microsoft, per

Windows, FreeBSD e Macintosh) - Rotor

– Mono (per Linux) – DotGNU

– Intel OCL (Open CLI Library) – …

Standard ECMA-335



I n g e gn

Defines the Common Language Infrastructure (CLI) inwhich applications written in multiple high level

languages may be executed in different systemenvironments without the need to rewrite thea lication to take into consideration the uni ue e

r i a d

el S of t w ar eT

10

characteristics of those environments

CLI is a runtime environment, with: – 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



I n g e gn

Libertà di scelta del linguaggio – Tutte le funzionalità del framework .NET sono

disponibili a tutti i linguaggi .NET – I componenti di un’applicazione possono essere

er i a d

el S of t w ar eT

11

scr con vers nguagg

Impatto sui tool – Tool disponibili per tutti i linguaggi:

Debugger, Profiler, ecc.

Framework .NET



I n g e gn

Concetti chiave: – (Microsoft) Intermediate Language - (MS)IL – Common Language Runtime - CLR

ambiente di esecuzione runtime per le applicazioni .NET e

r i a d

el S of t w ar eT

12

codice gestito (managed )

– Common Type System - CTStipi di dato supportati dal framework .NETconsente di fornire un modello di programmazione unificato

– Common Language Specification - CLSregole che i linguaggi di programmazione devono seguire peressere interoperabili all’interno del framework .NETsottoinsieme di CTS

Codice interpretato



I n g e gn

er i a d

el S of t w ar eT

13

Interprete EsecuzioneSorgenti

Codice nativo



I n g e gn

CompilatoreSorgenti

er i a d

el S of t w ar eT

14

Codicenativo(.EXE)

Esecuzione

Codice IL



I n g e gn

Codice

IL(Assembly)

.EXE/.DLL

Compilatore.NETSorgenti

er i a d

el S of t w ar eT

15

CodicenativoEsecuzioneCompilatore

JIT

Codice IL



I n g e gn

Sorgenti

Codice

IL(Assembly).EXE/.DLL

Compilatore.NET

er i a d

el S of t w ar eT

16

CodicenativoEsecuzioneCompilatore

JIT

Codice +

metadati

Codice IL



I n g e gn

CodiceIL

(Assembly).EXE/.DLL

Compilatore

.NETSorgenti

Ambiente di

esecuzione.NET Runtime

er i a d

el S of t w ar eT

17

Codicenativo

Esecuzione

CompilatoreJIT

Assembly

Unità minima per la distribuzione il versioning e la



I n g e gn

Unità minima per la distribuzione, il versioning e lasecurity

– 1+ file Manifest

’ er i a d

el S of t w ar eT

18

–

Type metadata

– Metadati che descrivono completamente tutti i tipi contenutinell’assembly

Codice in Intermediate Language

– Ottenuto da un qualsiasi linguaggio di programmazione Risorse

– Immagini, icone, …

Assembly



I n g e gn

Single-File Assembly

Calc.dll

Multi-File Assembly

Calc.dll

Util.dll

Type Metadata er i a d

el S of t w ar eT

19

Manifest

Type Metadata

IL Code

Resources

Type Metadata

IL Code

IL Code

Pict.gif

Resource

Assembly

.assembly Hello { }



I n g e gn

.asse b y e o { }

.assembly extern mscorlib { }

.method public static void main()

{

.entrypoint er i a d

el S of t w ar eT

20

ldstr "Hello IL World!"

call void [mscorlib]System.Console::WriteLine(class System.String)

ret

}

ilasm helloil.il

Assembly

Assembly privati



I n g e gn

Assembly privati

– Utilizzati da un’applicazione specifica

– Directory applicazione (e sub-directory ) Assembly condivisi

er i a d

el S of t w ar eT

21

– – Global Assembly Cache (GAC) – c:\windows\assembly

Assembly scaricati da URL

– Download cache

– c:\windows\assembly\download GACUTIL.EXE

– Tool a linea di comando per esaminare GAC e download cache

Deployment semplificato

Installazione senza effetti collaterali



I n g e gn

Installazione senza effetti collaterali – Applicazioni e componenti possono essere

condivisi o privati

er i a d

el S of t w ar eT

22

secuz one s e- y-s e

– Diverse versioni dello stesso componente possonocoesistere, anche nello stesso processo

Metadati

Descrizione dell’assembly - Manifest



I n g e gn

Descrizione dell assembly Manifest – Identità: nome, versione, cultura [, public key]

– Lista dei file che compongono l’assembly – Riferimenti ad altri assembly da cui si dipende

’ er i a d

el S of t w ar eT

23

–

Descrizione dei tipi contenuti nell’assembly – Nome, visibilità, classe base, interfacce – Campi, metodi, proprietà, eventi, …

Attributi – Definiti dal compilatore – Definiti dal framework – Definiti dall’utente

Tool che usano i metadati

Compilatori



I n g e gn

Compilatori – Compilazione condizionale

Ambienti RAD – Informazioni sulle ro rietà dei com onenti e

r i a d

el S of t w ar eT

24

Categoria

Descrizione – Editor personalizzati di tipi di proprietà

Analisi dei tipi e del codice – Intellisense – ILDASM – Anakrino, Reflector

Common Language Runtime

VB C C# JS i t



I n g e gn

Common Language Specification

VB C++ C# JScript …

er i a d

el S of t w ar eT

25

Base Class Library


Data and XML

eServices

serInterface


IL CLR offre vari servizi alle applicazioni



I n g e gn

IL CLR offre vari servizi alle applicazioni

Managed code (MSIL)

er i a d

el S of t w ar eT

26

Sistema operativo (Win32, …)

Runtime (CLR)

Funzionalità esistenti (es. I/Osu file) mediate da CLR

Funzionalità specifiche di CLR (es. Garbage Collector)


Base Class Library Support



I n g e gn

Thread Support COM Marshaler

Base Class Library Support

er i a d

el S of t w ar eT

27

Class Loader

MSIL to Native

Compilers (JIT)

Code

Manager

Garbage

Collector (GC)

Security Engine Debug Engine

Sicurezza e affidabilitàdel codice

Separazione spazi di memoria in un processo



I n g e gn

p p pcon AppDomain

Controllo del codice e sicurezza dei tipi – Cast non sicuri e

r i a d

el S of t w ar eT

28

– Variabili non inizializzate

– Accessi ad array oltre i limiti di allocazione

Garbage Collector

Garbage Collector per tutti gli oggetti .NET



I n g e gn

g p g gg Gestione del ciclo di vita degli oggetti Gli oggetti vengono distrutti automaticamente

er i a d

el S of t w ar eT

29

A differenza di COM, non ci si basa sul

Reference Counting

– Maggiore velocità di allocazione – Consentiti i riferimenti circolari – Perdita della distruzione deterministica

Algoritmo Mark-and-Compact

Garbage Collector edistruzione deterministica

In alcuni casi serve un comportamento di



I n g e gn

pfinalizzazione deterministica

– Riferimenti a oggetti non gestiti – Utilizzo di risorse che devono essere rilasciate


30

appena termina il loro utilizzo

Non è possibile utilizzare il metodo Finalize(in C# il distruttore), in quanto non èrichiamabile direttamente

È necessario implementare l’interfacciaIDisposable

Gestione delle eccezioni

Un’eccezione èU di i di



I n g e gn

– Una condizione di errore – Un comportamento inaspettato

incontrato durante l’esecuzione del programma Un’eccezione uò essere enerata dal e


31

– Codice del programma in esecuzione

– Ambiente di runtime In CLR, un’eccezione è un oggetto che eredita dalla

classe System.Exception

Gestione uniforme - elimina – Codici HRESULT di COM – Codici di errore Win32 – …

Gestione delle eccezioni

Concetti universali



I n g e gn

– Lanciare un’eccezione (throw)

– Catturare un’eccezione (catch) – Eseguire codice di uscita da un blocco controllato


32

(finally)

Disponibile in tutti i linguaggi .NETcon sintassi diverse

Altri servizi del CLR

Reflection



I n g e gn

– Analisi dei metadati di un assembly

– Generazione di un assembly dinamico Remotin e


33

– Chiamata di componenti remoti (.NET)

Interoperabilità (COM, Platform Invoke )

Reflection

È possibile interrogare un assembly caricato in



I n g e gn

memoria

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


34

– Parametri

È possibile forzare il caricamento in memoria diun assembly con i metodi Load / LoadFrom

Common Type System

Tipi di dato supportati dal framework .NETAll b di t tti i li i NET



I n g e gn

– Alla base di tutti i linguaggi .NET

Consente di fornire un modello di programmazioneunificato e


35

- ,funzionali – Esaminate caratteristiche di 20 linguaggi – Tutte le funzionalità disponibili con IL – Ogni linguaggio utilizza alcune caratteristiche

Common Language Specification – Regole di compatibilità tra linguaggi – Sottoinsieme di CTS

Common Type System

Alla base di tutto ci sono i tipi:classi strutture interfacce enumerativi delegati



I n g e gn

classi, strutture, interfacce, enumerativi, delegati

Fortemente tipizzato (compile-time ) Object-oriented


36

– amp , me o , p n ca , propr e , ...

Overload di funzioni (compile-time ) Invocazione metodi virtuali risolta a run-time

Ereditarietà singola di implementazione Ereditarietà multipla di interfacce Gestione strutturata delle eccezioni

Common LanguageSpecification

Regole per gli identificatoriUnicode case sensitivity



I n g e gn

– Unicode, case-sensitivity

– Keyword

Regole di overload più restrittive e


37

Devono essere supportate interfacce multiple con

metodi dello stesso nome Regole per costruttori degli oggetti Regole per denominazione proprietà ed eventi

Common LanguageSpecification

CommonType System

MicrosoftManaged C++

FujitsuCOBOL



I n g e gn

Type System ExtensionsExtensions


38

COBOLCOBOL C++C++

CLS

Common Type SystemTipi nativi

CTS C#

System.Object object



I n g e gn

System.String string

System.Boolean boolSystem.Char char

S stem.Sin le float er i a d el S of t w ar eT

39

System.Double double

System.Decimal decimalSystem.SByte sbyte

System.Byte byte

System.Int16 short

System.UInt16 ushort

System.Int32 int

System.UInt32 uint

System.Int64 long

System.UInt64 ulong

Common Type System

Tutto è un oggettoS t Obj t è l l di



I n g e gn

– System.Object è la classe radice

Due categorie di tipi e


40

–

Riferimenti a oggetti allocati sull’heap gestito Indirizzi di memoria

– Tipi valore

Allocati sullo stack o parte di altri oggetti

Sequenza di byte

Common Type SystemTipi valore

I tipi valore comprendono:Ti i i iti i (b ilt i )



I n g e gn

– Tipi primitivi (built-in )

Int32, … Single, Double

er i a d e

l S of t w ar eT

41

Boolean Char

– Tipi definiti dall’utente Strutture (struct)

Enumerativi (enum )

Common Type SystemTipi valore vs tipi riferimento

v.height

v width

public struct Size

{

bli i t h i ht



I n g e gn

Stack

v.width

r

public int height;

public int width;

} public class CSize

{ er i a d e

l S of t w ar eT

42

Heap

heightwidth

Class CSize

public int height;

public int width;

} public static void Main()

{

Size v; // v istanza di Sizev.height = 100; // okCSize r; // r è un referencer.height = 100; // NO, r non assegnator = new CSize(); // r fa riferimento a un CSizer.height = 100; // ok, r inizializzata

}


public struct Point{private int x, y;



I n g e gn

private int _x, _y;

public Point(int x, int y)

{ _x = x; _y = y;

er i a d e

l S of t w ar eT

43

public int X

{ get { return _x; }set { _x = value; }

}

public int Y{

get { return _y; }set { _y = value; }

}}


public class Rectangle

{

Point v1;



I n g e gn

Point v1;

Point v2;

…

} er i a d e

l S of t w ar eT

44

…

Rectangle r = new Rectangle();

v1._x v1._y v2._x v2._y

r


…

Point[] points = new Point[100];

for (int i = 0; i < 100; i++)



I n g e gn

for (int i = 0; i < 100; i++)

points[i] = new Point(i, i);

…

’ er i a d e

l S of t w ar eT

45

a ne, r mane so o ogge o ne eap (l’array di Point)

…


for (int i = 0; i < 100; i++)

{

points[i].X = i; points[i].Y = i;

}

…


public class Point{ private int _x, _y;



I n g e gn

public Point(int x, int y)

{ _x = x; _y = y;

er i a d e

l S of t w ar eT

46

public int X

{ get { return _x; }set { _x = value; }

}

public int Y{

get { return _y; }set { _y = value; }

}}



{

Point v1;



I n g e gn

Point v1;

Point v2;

…

} er i a d e

l S of t w ar eT

47

…

Rectangle r = new Rectangle();

r

v1 v2

_x _y

_x _y


…


for (int i = 0; i < 100; i++)



I n g e gn

for (int i 0; i < 100; i++)

points[i] = new Point(i, i);

…

’ er i a d e

l S of t w ar eT

48

a ne, r mangono ogge ne eap (1 array di Point + 100 Point)

…


for (int i = 0; i < 100; i++)

{

points[i].X = i; points[i].Y = i;

}

… NO!

Object

Common Type SystemTipi valore e tipi riferimento



I n g e gn

ValueType Exception Array String Delegate Attribute EventArgs

er i a d e

l S of t w ar eT

49

«struct»

Enum«delegate»

MulticastDelegate«struct»

Int32

«delegate»

EventHandler

«struct»

Double«struct»

DateTime

«enumeration»

DayOfWeek

Sunday = 0

Monday = 1

Tuesday = 2

Wednesday = 3

Thursday = 4

Friday = 5

Saturday = 6

«struct»

Boolean

Boxing / Unboxing

Un qualsiasi tipo valore può essere automaticamenteconvertito in un tipo riferimento (boxing ) mediante un

i li i



I n g e gn

up cast implicito a System.Object

int i = 123;

object o = i; er i a d e

l S of t w ar eT

50

Un tipo valore “boxed ” può tornare ad essere un tipovalore standard (unboxing ) mediante un down cast esplicitoint k = (int) o;

Un tipo valore “boxed ” è un clone indipendente

Boxing / Unboxing

int i = 123;

object o = i;

int k = (int) o;



I n g e gn

STACK HEAP er i a d e

l S of t w ar eT

51

i 123

o

k 123

Int32123

Modello di esecuzione

VBSourceCode

Compiler

C++C#

Compiler Compiler



I n g e gn

Compiler

Assembly AssemblyAssemblyIL

Compiler Compiler

er i a d e

l S of t w ar eT

52

CLR

Operating System Services

Common Language Runtime JIT Compiler

NativeCode

ManagedCode

ManagedCode

ManagedCode

UnmanagedCode

CLR Services

Ngen

Framework .NET 1.1

System.Web

UI

HtmlControls

System.Windows.Forms

Design ComponentModelCompilation



I n g e gn

Caching Security

WebControls System.Drawing

Drawing2D Printing

Hosting

Handlers

er i a d e

l S of t w ar eT

53

System

System.Data System.Xml

Globalization

Diagnostics

Configuration

Collections

Resources

Reflection

IO

Threading

Text

Security

SqlClient

OleDb

SQLTypes

Common

RuntimeInteropServices

Remoting

Serialization

Configuration SessionState Imaging Text

XPath

Xsl

Serialization

Schema

Framework .NET

Il framework non è una “scatola nera”

E possibile estendere una qualsiasi classe



I n g e gn

E possibile estendere una qualsiasi classe.NET (non sealed ) mediante ereditarietà

er i a d e

l S of t w ar eT

54

, – si usa e si estende la classe stessa

– non si utilizza uno strato intermedio (wrapper )

L’ereditarietà è 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 (*)



I n g e gn

p, gg , p y p ( )

T. Archer, A. Whitechapel , Inside C#, Second Edition (*) M. J. Young , XML Step by Step, Second Edition (*)

* er i a d e

l S of t w ar eT

55

. . , .

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




Working with Types

Tipi in .NET

Dal punto di vista del modo in cui le istanze vengono gestite inmemoria (rappresentazione, tempo di vita, …),i tipi possono essere distinti in:

R f t



– Reference type

– Value type

I n g e gn

,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)

er i a d e

l S of t w ar eT

2

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



I n g e gn

– 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 ti o er i a d e

l S of t w ar eT

– 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 Tipi a livello base Tipi annidati

private Non applicabileVisibile nel tipo

contenitore (default)



I n g e gn

p ppcontenitore (default )

Visibile nel tipo

er i a d e

l S of t w ar eT

sottotipi

internal Visibile nell’assembly contenitore (default ) Visibile nell’assembly

contenitore

protected internal Non applicabile

Visibile sia nel tipocontenitore e nei suoi

sottotipi, sia nell’assembly contenitore

public Visibilità completa Visibilità completa

4


Modificatore Dati Operazioni - Eventi

private default Visibile nel tipo

contenitore (default)



I n g e gn

p contenitore (default )

Visibile nel tipo er i a d el S of t w ar eT

Applicare

esclusivamente acostanti

ed eventualmente acampi read-only

(è comunque preferibile

l’accesso mediante unaproprietà)

sottotipi

internal Visibile nell’assembly contenitore

protected internal

Visibile sia nel tipocontenitore e nei suoi

sottotipi, sia nell’assembly contenitore

public Visibilità completa

5


Non sono applicabili nei seguenti casi: – Costruttori di tipo (statici)

sempre inaccessibili – invocati direttamente dal CLR



I n g e gn

p

– Distruttori (finalizer )sempre inaccessibili – invocati direttamente dal CLR


– Membri di interfaccesempre pubblici

– Membri di enum sempre pubblici

– Implementazione esplicita di membri di interfaccevisibilità particolare (pubblici/privati), non modificabile

– Namespace

sempre pubblici

6

Regole

Massimizzare l’incapsulamentominimizzando la visibilità

Information hiding a livello di assembly



I n g e gn

– Dichiarare public solo i tipi significativi dal punto di vista concettuale Information hiding a livello di classe


– c arare public so o meto , propr et e event s gn cat v apunto di vista concettuale

– Dichiarare protected solo le funzionalità che devono essere visibilinelle classi derivate, ma non esternamentead esempio, costruttori particolari, metodi e proprietà virtuali non

public

Information hiding a livello di field

– Field private e proprietà public – Field private e proprietà protected

7

Costanti

Una costante è un simbolo che identifica un valore che non puòcambiare

Il tipo della costante può essere solo un tipo considerato primitivodal CLR (compreso string)



I n g e gn

dal CLR (compreso string) Il valore deve essere determinabile compile-time


,

public const int MaxValue = 2147483647;

public const int MinValue = -2147483648;

In una classe contenitore di dimensioni prefissate, si potrebbedefinire:

public const int MaxEntries = 100; // Warning!

Si noti l’utilizzo della maiuscola iniziale

È possibile applicare const anche alle variabili locali

8

Field

Un field è un data member che può contenere: – un valore (un istanza di un value type ), oppure – un riferimento (a un’istanza di un reference type )



I n g e gn

in genere, la realizzazione di un’associazione Può essere:


– di istanza (default ), oppure – di tipo (static)

Può essere: – read-write (default ), oppure – read-only (readonly)

inizializzato nella definizione o nel costruttore

Esiste sempre un valore di default (0, 0.0, false, null)

9

Field

Qual è la differenza tra le seguenti definizioni:

public const int MaxEntries = 100;



I n g e gn

public static readonly int MaxEntries = 100;

“ ” er i a d el S of t w ar eT

,cliente – se il valore viene modificato e se il cliente e il fornitore sono inassembly diversi, è necessario ricompilare anche il codice del cliente

Nel secondo caso, l’accesso al field MaxEntries è quello standard: ilvalore è in memoria ed è necessario reperirlo – se il valore vienemodificato 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 veramenteimmutabili nel tempo (nelle versioni del programma), negli altricasi utilizzare field statici read-only il valore di MaxEntries non è una costante “vera” perché in una



I n g e gn

il valore di MaxEntries non è una costante vera perché in unaversione successiva del programma potrebbe cambiare


os an

– il nome dovrebbe iniziare con una lettera maiuscola

– di solito, dovrebbe essere pubblica (ma non è sempre così) Field

– il nome deve iniziare con “_” seguito da una lettera minuscola – deve essere privata (accesso sempre mediante proprietà)

Field read-only

– scegliere, a seconda delle situazioni, una delle due convenzioniprecedenti

11

Modificatori di metodi

virtual

abstract



I n g e gn

override override sealed / sealed override


Applicabili a: – Metodi

– Proprietà (metodi get e set) – Indexer (metodi get e set)

– Eventi (metodi add e remove)di istanza (cioè non statici)

12

Modificatori di metodivirtual

The implementation of a virtual method can be changedby an overriding member in a derived class

When a virtual method is invoked, the run-time type of the object



I n g e gn

is checked for an overriding member – 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 { … } }

13

Modificatori di metodiabstract

Use the abstract modifier to indicate that the methoddoes not contain implementation

Abstract methods have the following features



I n g e gn

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


The implementation is provided by an overriding method

It is an error to use the static or virtual modifiers in anabstract method declaration

protected abstract void Method(); public abstract int Property

{ get; set; } public abstract int this[int index]{ get; }

14

Modificatori di metodioverride

An override method provides a (new) implementation of a memberinherited from a base class - the method overridden by an overridedeclaration is known as the overridden base method

The overridden base method



I n g e gn

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

er i a d el

S of t w ar eT

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 { … } }

15

MetodiPassaggio degli argomenti

Tre tipi di argomenti: – In (default in C#)

L’argomento deve essere inizializzato



I n g e gn

L’argomento viene passato per valore (per copia) Eventuali modifiche del valore dell’argomento non hanno effetto sul

chiamante er i a d el

S of t w ar eT

– In/Out (ref in C#) L’argomento deve essere inizializzato L’argomento viene passato per riferimento

Eventuali modifiche del valore dell’argomento hanno effetto sulchiamante

– Out (out in C#)

L’argomento può NON essere inizializzato L’argomento viene passato per riferimento

Le modifiche del valore dell’argomento (l’inizializzazione è obbligatoria)hanno effetto sul chiamante

16

MetodiPassaggio degli argomenti In

Value type

– Viene passata una copia dell’oggetto – Eventuali modifiche vengono effettuate sulla copia e non hanno

alcun effetto sull’oggetto originale



I n g e gn

Reference type

– ’ er i a d el

S of t w ar eT

– Eventuali modifiche dell’oggetto referenziato hanno effetto

– Eventuali modifiche del riferimento vengono effettuate sulla copia enon hanno alcun effetto sul riferimento originale

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)

17

I

MetodiPassaggio degli argomenti In/Out

Value type

– Viene passato l’indirizzo dell’oggetto – Eventuali modifiche agiscono direttamente sull’oggetto originale

R f



In g e gn

Reference type – Viene passato l’indirizzo del riferimento all’oggetto

’ er i a d el

S of t w ar eT

– – Eventuali modifiche del riferimento agiscono direttamente sul

riferimento originale

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)

18

I

MetodiPassaggio degli argomenti

class/struct Persona …

…

Persona p1 = new Persona(“Tizio”); // p1 == Tizio

Method1(p1);



In g e gn

// p1 == Tizio Method2(ref p1);

er i a d el

S of t w ar eT

// p1 == Sempronio

…

static void Method1(Persona p){ p = new Persona(“Caio”); // p == Caio

}

static void Method2(ref Persona p){ p = new Persona(“Sempronio”); // p == Sempronio

}19

I

MetodiPassaggio degli argomenti Out

Value type e Reference type

– Viene passato l’indirizzo dell’oggetto o del riferimento all’oggettocome nel caso In/Out

– Non è necessario che l’oggetto o il riferimento siano inizializzati prima



n g e gn

di essere passati come argomento – L’oggetto o il riferimento DEVONO essere inizializzati nel metodo a

er i a d el

S of t w ar eT

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

}

20

I n

Regole

Utilizzare prevalentemente il passaggio standard per valore Utilizzare il passaggio per riferimento (ref o out) solo se

strettamente necessario

2 l i d i i l hi



n g e gn

– 2+ valori da restituire al chiamante – 1+ valori da utilizzare e modificare nel metodo

’ er i a d el

S of t w ar eT

– ceg ere re se ogge o passa o come argomen o eve essere gstato inizializzato

– Scegliere out se è responsabilità del metodo inizializzarecompletamente l’oggetto passato come argomento

void Swap(ref int value1, ref int value2){ … }

void SplitCognomeNome(string cognomeNome,out string cognome, out string nome)

{ … }

21

I n

MetodiNumero 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



n g e gn

Soluzioni possibili:

er i a d el

S of t w ar eT

– Overloading del metodo Add Svantaggio: posso solo codificare un numero finito di metodi

– Definire un solo metodo Add che accetti un numero variabile diargomenti

int Add(params int[] operands){

int total = 0;foreach (int operand in operands)total += operand;

return total;}

22

I n

MetodiNumero variabile di argomenti

Non solo posso scrivere: Add(a,b); Add(10,20,30); Add(x1,x2,x3,x4);



n g e gn

Ma anche:

er i a d el

S of t w ar eT

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 });23

I n

Costruttori di istanza

Responsabilità: inizializzare correttamente lo stato dell’oggettoappena creato (nulla di più!)

In mancanza di altri costruttori, esiste sempre un costruttore di

default senza argomenti che semplicemente invoca il costruttore



n g e gn

default senza argomenti che, semplicemente, invoca il costruttoresenza argomenti della classe base er i a d el

S of t w ar eT

Nel caso delle classi, il costruttore senza argomenti può esseredefinito dall’utente

Nel caso delle strutture, il costruttore senza argomenti NON puòessere definito dall’utente (per motivi di efficienza)

In entrambi i casi, è possibile definire altri costruttori con differente

signature e differente visibilità

24

I n


public abstract class DataAdapterManager

{

private readonly IDataTable _dataTable;

private readonly IConnectionManager _connectionManager;



g e gn

protected DataAdapterManager(IDataTable dataTable,IConnectionMana er connectionMana er e

r i a d el

S of t w ar eT

{

if(dataTable == null)

throw new ArgumentNullException("dataTable");if(connectionManager == null)

throw new ArgumentNullException("connectionManager");

_dataTable = dataTable;

_connectionManager = connectionManager;

}

…

}

25

I n g


public class XmlDataAdapterManager : DataAdapterManager

{

private readonly Encoding _encoding;

public XmlDataAdapterManager(IDataTable dataTableXmlConnectionManager xmlConnectionManager)



g e gn

public XmlDataAdapterManager(IDataTable dataTable,XmlConnectionManager xmlConnectionManager)

: this dataTable xmlConnectionMana er Encodin .Unicode er i a d el

S of t w ar eT

{ }

public XmlDataAdapterManager(IDataTable dataTable,XmlConnectionManager xmlConnectionManager,Encoding encoding)

: base(dataTable, xmlConnectionManager)

{

_encoding = encoding;}

…

}

26

I n g

Costruttori di tipo

Responsabilità: inizializzare correttamente lo stato comune atutte le istanze della classe – field statici

Dichiarato static

Implicitamente private



g e gn

Implicitamente private

er i a d el

S of t w ar eT

empre senza argomen – no over oa ng

Può accedere esclusivamente ai membri (field , metodi, …) statici

della classe Se esiste, viene invocato automaticamente dal CLR

– Prima della creazione della prima istanza della classe – Prima dell’invocazione di un qualsiasi metodo statico della classe

Non basare il proprio codice sull’ordine di invocazione dicostruttori di tipo

27

I n g

Costruttori di tipo

class MyType{

static int _x = 5;…

}

Viene definitoimplicitamente uncostruttore di tipo



g e gn

}class MyType Del tutto analogo al

er i a d el

S of t w ar eT

{static int _x;static MyType() { _x = 5; }…

}

class MyType{

static int _x = 5;static MyType() { _x = 10; }…

}

caso precedente

_x viene primainizializzato a 5 e

quindi a 10

28

I n g

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 effettivamenteutilizzata



g e gn

Devono essere inizializzati solo se la classe viene effettivamenteutilizzata er i a d el

S of t w ar eT

public class A {

private static XmlDocument _xmlDocument;

static A(){ _xmlDocument = new XmlDocument();

_xmlDocument.Load(…);}…

}

29

I n g

Costruttori ed eccezioni

Supponiamo che – un costruttore lanci un’eccezione e – l’eccezione non venga gestita all’interno del costruttore stesso

(quindi arrivi al chiamante)



g e gn

(quindi arrivi al chiamante)

er i a d el

S of t w ar eT

Nel caso di costruttori di istanzanessun problema!

In C++ è una situazione non facilmente gestibile

Nel caso di costruttori di tipola classe NON è più utilizzabile!

TypeInitializationException

30

I n g

Interfacce

In C#, un’interfaccia può contenere esclusivamente: – Metodi – considerati pubblici e astratti – Proprietà – considerate pubbliche e astratte – Indexer – considerati pubblici e astratti – Eventi – considerati pubblici e astratti



e gn

co s de at pubb c e ast att

er i a d el

S of t w ar eT

In CLR, un’interfaccia è considerata una particolare classeastratta di sistema che (ovviamente) non deriva daSystem.Object – però, le classi che la implementano derivanoper forza da System.Object

Un’interfaccia – 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 un’interfaccia,

avviene un boxing del value type (con conseguente copia delvalore)!

31

I n g e

Implementazione di unainterfaccia

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

}



e gn

public class A : IBehavior er i a d el

S of t w ar eT

{ public void Method() // virtual sealed{ … }

public int Property // virtual sealed{

get { … }set { … }

}

public int this[int index] // virtual sealed{get { … }

}}

32

I n g e

Implementazione di unainterfaccia

public class A : IBehavior{ public virtual void Method(){ … }

public virtual int Property

{get { }



e gn

get { … } e

r i a d el

S of t w ar eT

…}

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

I n g e

Implementazione di unainterfaccia / classe astratta

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

}



e gn


pu c c ass :{ public override void Method() …

public override int Property … public override int this[int index] …}

34

I n g e

Implementazione esplicitadi una interfaccia

public class A : IBehavior{

void IBehavior.Method(){ … }

int IBehavior.Property{



e gn

et … er i a d el S of t w ar eT

set { … }

}

int IBehavior.this[int index]{get { … }

}}

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

• Name hiding• Avoiding name ambiguity

35

I n g e

Implementazione esplicitadi una interfaccia

public interface IMyInterface1{ void Close(); }

public interface IMyInterface2{ void Close(); }

public class MyClass : IMyInterface1, IMyInterface2{



gn

{


void IMyInterface1.Close(){ … }void IMyInterface2.Close()

{ … } public void Close(){ … }

}

MyClass a = new MyClass(…);((IMyInterface1) a).Close(); // Ok!((IMyInterface2) a).Close(); // Ok!a.Close(); // Ok!

36




Framework .NET

I n g e g

Framework .NET Overview

Object

ValueType Exception Array String Delegate Attribute EventArgs



gn


«struct»

Enum

«delegate»

MulticastDelegate

«struct»

Int32

«delegate»

EventHandler

«struct»

Double

«struct»

DateTime

«enumeration»

DayOfWeek

Sunday = 0

Monday = 1

Tuesday = 2

Wednesday = 3Thursday = 4

Friday = 5

Saturday = 6

«struct»

Boolean

2

I n g e g

System.Object

Supports all classes in the .NET Framework classhierarchy and provides low-level services to derivedclasses

This is the ultimate superclass of all classes in the



gn

p er i a d el S of t w ar eT

. Because all classes in the .NET Framework are

derived from Object, every method defined in theObject class is available in all objects in the

system

3

I n g e g

System.Object

Object



gn


+ O ject

# 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

4

I n g e g

System.Object

Derived classes can and do override some of thesemethods, including:– Equals - Supports comparisons between objects

– ToString - Manufactures a human-readable text



gn


– GetHashCode - Generates a number

corresponding to the value of the object to supportthe use of a hash table– Finalize - Performs cleanup operations before an

object is automatically reclaimed

5

I n g e g

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



n


,override this method to support value equality

For reference types, equality is defined as objectequality; that is, whether the references refer to thesame object

For value types, equality is defined as bitwise equalityThe ValueType class supports value types

6

I n g e gn

Object.Equals

The following statements must be true for allimplementations of the Equals method.In the list, x, y, and z represent object references that

are not a null reference– x.Equals(x) returns true



n


– 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 trueif and only if x.Equals(z) returns true

– Successive calls to x.Equals(y) return the same value aslong 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

7

I n g e gn

Object.Equals

For some kinds of objects, it is desirable to haveEquals test for value equality instead of referentialequality

Such implementations of Equals return true if thetwo objects have the same “value”, even if they are not



n


t e same nstance The type’s implementer decides what constitutes an

object’s “value”, but it is typically some or all the datastored 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 theString class returns true for any two stringinstances that contain exactly the same characters inthe same order

8

I n g e gn

Object.Equals

Types that override Equals must also overrideGetHashCode; otherwise, Hashtable might not workcorrectly

If your programming language supports operator



n

er i a d el S

of t w ar eT

equality operator for a given type, that type shouldoverride the Equals methodSuch implementations of the Equals method should

return the same results as the equality operator

9

I n g e gn

Object.Equals

public class Point

{

private readonly int x, y;

…

public override bool Equals(object obj)

{

-



n

er i a d el S

of t w ar eT

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

I n g e gn

Object.Equals

public class SpecialPoint : Point

{

private readonly int w;

…

public SpecialPoint(int x, int y, int w) : base(x, y)

{

=



er i a d el S

of t w ar eT

}


{ return base.Equals(obj) &&

w == ((SpecialPoint) obj).w;

}


{return base.GetHashCode() ^ w;

}

}

11

I n g e gn

Object.Equals


{

private readonly Point a, b;

…


{

== = e



er i a d el S

of t w ar eT

return false;

Rectangle r = (Rectangle) obj;

// Uses Equals to compare variables.return a.Equals(r.a) && b.Equals(r.b);

}


{

return a.GetHashCode() ^ b.GetHashCode();}

}

12

I n g e gn

Object.Equals

public struct Complex

{

private readonly double re, im;

…


{return obj is Complex && this == (Complex) obj;

e



er i a d el S

of t w ar eT


{

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

I n g e gn

System.ValueType

One or more fields of the derivedtype 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 foruse as a key in a hash table. In

that case, consider writing your

Object

e

e e own mpemen a on o e as



er i a d el S

of t w ar eT

# ValueType ( )

+ GetHashCode ( ) : System.Int32+ Equals ( [in] obj : System.Object ) : System.Boolean

+ ToString ( ) : System.StringThe default implementation of

the Equals method uses

reflection to compare the

corresponding fields of obj and

this instance. Override the Equalsmethod for a particular type to

improve the performance of the

method and more closely

represent the concept of equality

for the type.

own mpemen a on o e asCode that more closely

represents the concept of a hash

code for the type.

14

I n g e gn

System.Boolean

ValueType «interface»

IComparable

+ CompareTo ( [in] obj : System.Object ) : System.Int32

«interface»

IConvertible

+ ToType ( )

+ ToString ( ) + ToDateTime ( )

+ ToDecimal ( ) e

+ ToDouble ( )



er i a d el S

of t w ar eT

«struct»

Boolean

+ TrueString : System.String

+ FalseString : System.String

+ ToString ( [in] provider : System.IFormatProvider ) : System.String+ GetTypeCode ( ) : System.TypeCode




+ ToString ( ) : System.String

+ Parse ( [in] value : System.String ) : System.Boolean

+ ToDouble ( )

+ ToSingle ( )

+ ToUInt64 ( )

+ ToInt64 ( )

+ ToUInt32 ( ) + ToInt32 ( )

+ ToUInt16 ( )

+ ToInt16 ( )

+ ToByte ( )

+ ToSByte ( )

+ ToChar ( )

+ ToBoolean ( )

+ GetTypeCode ( )

15

I n g e gn

System.Int32

ValueType

IComparable

«interface»

IFormattable

+ ToString ( [in] format : System.String , [in] formatProvider : System.IFormatProvider ) : System.String

«struct» e

n



er i a d el S

of t w ar eT

IConvertible+ MaxValue : System.Int32+ MinValue : System.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



+ 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...

16

I n g e gn

System.IComparable

Compares the current instance with another object of the same

type -

«interface»

IComparable


e



ri a d el S

of t w ar eT

order of the comparands The return value has these meanings:

– 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 valuetype that implements this interface; otherwise, an

ArgumentException is thrown17

I n g e gn

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 – e

r

th i i d t t



ri a d el S

of t w ar eT

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

Esempio 118

I n g e gn

System.IComparable

Se volessi: – Ordinare i punti in ordine decrescente – Ordinare dei film

Per genere, oppure e

r Per titolo



r

i a d el S

of t w ar eT

Per titolo

– Ordinare degli studenti Per cognome e nome, oppure Per matricola, oppure Per corso di studio

–

…

19

I n g e gn

System.Collections.IComparer

This interface is used in conjunction with the Array.Sort and Array.BinarySearch methods

«interface»IComparer

+ Compare ( [in] x : System.Object , [in] y : System.Object ) : System.Int32

e

r



ri a d el S

of t w ar eT

Comparer

- _up : bool = true

+ Comparer ( )

+ Comparer ( [in] up : bool )

+ Compare ( [in] obj1 : object , [in] obj2 : object ) : int

«struct»

Point

+ «property» X : int

+ «property» Y : int- _x : int

- _y : int

+ Point ( )

+ ToString ( )

+ CompareTo ( )

IComparerIComparable

«use»

Esempio 120

I n g e gn

System.IConvertible

This interface provides methods to convert the valueof an instance of an implementing type to a commonlanguage runtime type that has an equivalent value

The common language runtime types areBoolean, SByte, Byte, Int16, UInt16, Int32,

«interface»IConvertible

+ ToType ( ) + ToString ( )

+ ToDateTime ( )

+ ToDecimal ( )

+ ToDouble ( )

+ ToSingle ( )

+ ToUInt64 ( )

e

r i

, , , , ,D i l D t Ti Ch and St i

+ ToUInt32 ( )



i a d el S

of t w ar eT

Decimal, DateTime, Char, and String

If there is no meaningful conversion to a common

language runtime type, then a particular interfacemethod implementation throwsInvalidCastException - For example, if thisinterface is implemented on a Boolean type, the

implementation of the ToDateTime method throwsan exception because there is no meaningfulDateTime equivalent to a Boolean type

+ ToUInt32 ( ) + ToInt32 ( )

+ ToUInt16 ( )

+ ToInt16 ( )

+ ToByte ( ) + ToSByte ( )

+ ToChar ( )

+ ToBoolean ( )

+ GetTypeCode ( )

21

I n g e gn

System.Convert

In System.Int32, l’implementazionedell’interfaccia System.IConvertible è unesempio di “explicit interface implementation ”:

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

Convert

+ DBNull : System.Object

+ GetTypeCode ( )

+ IsDBNull ( )

+ ChangeType ( )+ ToBoolean ( )

+ ToChar ( )+ ToSingle ( )

+ ToDouble ( )

e

r i

+ ToDecimal ( )

+ ToDateTime ( )



i a d el S

of t w ar eT

È necessario scrivere:

((IConvertible) x).ToDouble(…)

Se necessario, utilizzare la classe Convert:

Convert.ToDouble(x)

+ ToDateTime ( )

+ ToByte ( )

+ ToSByte ( )+ ToInt16 ( )

+ ToUInt16 ( )+ ToInt32 ( )

+ ToUInt32 ( )

+ ToInt64 ( )

+ ToUInt64 ( )

+ ToString ( )+ ToBase64String ( )

+ ToBase64String ( )

+ FromBase64String ( )

+ ToBase64CharArray ( )

+ FromBase64CharArray ( )

22

I n g e gn

System.Convert

Throws an exception if the conversion is not supported bool b = Convert.ToBoolean(DateTime.Today);

// InvalidCastException

Performs checked conversions

int k = 300; e

r i

y e = y e ; ==b t b C t T B t (k) // O fl E ti



a d el S

of t w ar eT

byte b = Convert.ToByte(k); // OverflowException

In alcuni casi, esegue un arrotondamento:double d = 42.72;int k = (int) d; // k == 42int k = Convert.ToInt32(d); // k == 43

Is also useful if you have a string that you want to convert to anumeric value:string myString = "123456789";int myInt = Convert.ToInt32(myString);

23

I n g e gn

Conversione di tipo

Widening conversion occurs when a value of one type isconverted 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) e

r i a

–



a d el S

of t w ar eT

Narrowing conversion occurs when a value of one type isconverted to a value of another type that is of a smaller size – Da Int32 a Byte

– Da Int32 a SByte

– Da Int32 a Int16



24

I n g e gn

Conversione di tipo

Conversioni implicite – non generano eccezioni – Conversioni numeriche

Il tipo di destinazione dovrebbe essere in grado di contenere, senzaperdita di informazione, tutti i valori ammessi dal tipo di partenza

Eccezione: e

r i a

n = ;

float b = k1;



a d el S

of t w ar eT

float b = k1;

int k2 = (int) b; // k2 == 1234567936

– Up castPrincipio di sostituibilità: deve sempre essere possibile utilizzareuna classe derivata al posto della classe base

B b = new B(…); // class B : A

A a = b;

25

I n g e gn

Conversione di tipo

Conversioni esplicite – possono generare eccezioni – Conversioni numeriche

Il tipo di destinazione non sempre è in grado di contenere il valore deltipo di partenza

int k1 = -1234567891;

e

r i a



a d el S

of t w ar eT

int k1 = -1234567891;

uint k2 = checked((uint) k1); // OverflowException

int k1 = -1234567891;

uint k2 = Convert.ToUInt32(k1); // OverflowException

26

I n g e gn

Conversione di tipo

Conversioni esplicite – possono generare eccezioni – Down cast

A a = new B(…); // class B : A B b = (B) a; // Ok

a = new A(…); e

r i a



a d el S

of t w ar eT

if(a is B) // if(a.GetType() == typeof(B)){

b = (B) a; // Non genera eccezioni…}

b = a as B; // b = (a is B) ? (B) a : null;if(b != null)

{ …}

27

I n g e gn

Conversione di tipo

Boxing – up cast (conversione implicita)

int k1 = 100;

object o = k1; // Copia!

k1 = 200;

e

r i a Unboxing – down cast (conversione esplicita)



d el S

of t w ar eT

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

28

I n g e gn

Conversione di tipodefinite dall’utente

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 l’utilizzo automatico (cast implicito)

e

r i a

me o o non eve generare eccez on La keyword explicit indica la necessità di un cast esplicito



d el S

of t w ar eT

La keyword explicit indica la necessità di un cast esplicitoIl 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

Esempio 1 - Digit29

I n g e gn

Conversioni a string

Conversioni a string (di un Int32):– ToString()

int k1 = -1234567891;

string str = k1.ToString(); // str == “-1234567891”

– ToStrin strin formatStrin e

r i a

the instance is formatted with the



d el S

of t w ar eT

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”

30

I n g e gn

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 itemsof the form, {index[,alignment][:formatString]}

int k1 = -1234567891; e

r i a d

String.Format(“{0}”,k1); // = “-1234567891”



d el S

of t w ar eT

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

I

n g e gn

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

“- ” e

r i a d

.

Int32.Parse(null); // ArgumentNullException



d el S

of t w ar eT

– Int32.Parse(string str,

System.Globalization.NumberStyles style)

NumberStyles determines the styles permitted in numericstring arguments that are passed to the Parse methods of thenumeric base type classes

32

I

n g e gn

Conversioni da string

«enumeration»

NumberStyles

None = 0

AllowLeadingWhite = 1 AllowTrailingWhite = 2

AllowLeadingSign = 4

AllowTrailingSign = 8

AllowParentheses = 16

AllowDecimalPoint = 32

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 e

r i a d

ow ousan s =

AllowExponent = 128

AllowCurrencySymbol = 256

flags



d el S

of t w ar eT

Int32.Parse(“-1.234.567.891”,System.Globalization.NumberStyles.Number); // ok

Int32.Parse(“B669FD2D”,System.Globalization.NumberStyles.HexNumber); // ok

AllowCurrencySymbol 256 AllowHexSpecifier = 512

Integer = 7

HexNumber = 515Number = 111

Float = 167

Currency = 383

Any = 511

33

I

n g e gn

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”

e

r i a d

Convert.ToString(k1,16); “b669fd2d”



d el S of t w ar eT

Conversioni da string (in un Int32):

– Convert.ToInt32(string str, int fromBase)fromBase = 2, 8, 10, 16

Convert.ToInt32(“-1234567891”); // -1234567891Convert.ToInt32(“-1234567891”,10); // -1234567891Convert.ToInt32(“B669FD2D”,16); // -1234567891Convert.ToInt32(“0xB669FD2D”,16); // -1234567891Convert.ToInt32(“B669FD2D”,10); // FormatException

34

I

n g e gn

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 stringrepresentation

NumberFormatInfo

TECNICHE AVANZATE

e

r i a d

« n er ace»

IFormatProvider DateTimeFormatInfo



d el S of t w ar eT

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 valueof an object

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

CultureInfo

35

I

n g e gn

System.Double

Follows IEEE 754 specification Supports ± 0, ± Infinity, NaN

Epsilon represents the

smallest positive Double > 0

ValueType

IComparable

IConvertible

«struct»

Double

+ MinValue : System.Double

+ MaxValue : System.Double

+ Epsilon : System.Double+ NegativeInfinity : System.Double

IFormattable e

r i a d

e ry arse me o s ethe Parse method, except this

.

+ NaN : System.Double

+ ToString ( )



el S of t w ar eT

method does not throw an

exception if the conversion fails – If the conversion succeeds, thereturn value is true and theresult parameter is set to theoutcome of the conversion

– If the conversion fails, thereturn value is false and theresult parameter is set to zero

g ( )

+ GetTypeCode ( )

+ ToString ( )

+ CompareTo ( )+ GetHashCode ( )+ Equals ( )

+ ToString ( )

+ IsInfinity ( )

+ IsPositiveInfinity ( )

+ IsNegativeInfinity ( )

+ IsNaN ( )

+ ToString ( )+ Parse ( )

+ Parse ( )

+ Parse ( )

+ Parse ( )

+ TryParse ( )36

I n g e gn

System.Enum

Enum provides methods to – Compare instances of this class – Convert the value of an instance

to its string representation

– Convert the stringre resentation of a number to

«struct»

Enum

# Enum ( )

+ ToString ( )

+ GetTypeCode ( )

IComparable

ValueType

IConvertible

e

r i a d e

an instance of this classCreate an instance of a

+ ompare o

+ GetHashCode ( )

+ Equals ( )

P ( )



el S of t w ar eT

– Create an instance of aspecified enumeration and value

You can also treat an Enum as abit field

+ Parse ( )

+ GetUnderlyingType ( )

+ GetValues ( )+ GetName ( )

+ GetNames ( )+ IsDefined ( )

+ Format ( )

+ ToObject ( )

Esempio 1 - Color37

I n g e gn

System.DateTime

Represents an instant intime, typically expressed asa date and time of day

The DateTime value type

represents dates and timeswith values ranging from

ValueType

IComparable

IConvertible

«struct»

DateTime

+ MinValue : System.DateTime+ MaxValue : System.DateTime

+ « ro ert » Date : S stem.DateTime e

r i a d e

: : m n g , anuary1, 0001 Anno Domini(C E ) 11 59 59

IFormattable

+ «property» Day : System.Int32

+ «property» DayOfWeek : System.DayOfWeek

+ «property» DayOfYear : System.Int32



el S of t w ar eT

(Common Era) to 11:59:59

P.M., December 31, 9999A.D. (C.E.) Time values are measured

in 100ns units called ticks DateTime represents an

instant in time, whereas aTimeSpan represents atime interval

p p y y y+ «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

38

I n g e gn

System.String

String

«interface»IEnumerable

+ GetEnumerator ( ) : System.Collections.IEnumerator

«interface»ICloneable

+ Clone ( ) : System.Object

Object

IComparable

e

r i a d e

.

+ «property» Length : System.Int32IConvertible



el S of t w ar eT

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 139

I n g e gn

System.ICloneable

Clone creates a new object that is a copy of the current instance

Clone can be implemented either as

«interface»ICloneable


Supports cloning, which creates a new instanceof a class with the same value as an existinginstance

e

r i a d e

– a shallow copy, only the top-level objects are duplicated, no newinstances of any fields are created



el S of t w ar eT

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 (oroccasionally a derived type of) the current object

40

I n g e gn

GetEnumerator returns an enumerator that can be used to

iterate through a collection

Exposes the enumerator, whichsupports a simple iteration overa collection

«interface»IEnumerable

+ GetEnumerator ( ) : System.Collections.IEnumerator

System.Collections.IEnumerable

e

r i a d e

«interface»

IEnumerator Enumerators only allow reading the data

in the collection



l S of t w ar eT

+ «property» Current : System.Object

+ Reset ( ) + MoveNext ( ) : System.Boolean

+ «get» Current ( ) : System.Object

in the collection

Enumerators cannot be used to modifythe 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 refers41

I n g e gn

Non deve essere implementata direttamente da una classecontenitore

Deve essere implementata da una classe separata(eventualmente annidata nella classe contenitore) che fornisce la

funzionalità di iterare sulla classe contenitore

System.Collections.IEnumerator

e

r i a d el

contemporaneamente più enumeratori sulla stessa classecontenitore



l S of t w ar eT

contenitore

La classe contenitore deve implementare l’interfacciaIEnumerable

Se una classe contenitore viene modificata, tutti gli enumeratoriad essa associati vengono invalidati e non possono più essere

utilizzati (InvalidOperationException)

42

I n g e gn


IEnumerator enumerator = enumerable.GetEnumerator();

while (enumerator.MoveNext())

{

MyType obj = (MyType) enumerator.Current;

… e

r i a d el



l S of t w ar eT

foreach (MyType obj in enumerable)

{

…

}

43

I n g e gn


public class Contenitore : IEnumerable

{

…

public IEnumerator GetEnumerator()

{ e

r i a d el

}



S o

f t w ar eT

class Enumeratore : IEnumerator{

public Enumeratore(Contenitore contenitore) …

}}

Esempio 1 - Contenitore44

I n g e gn

System.Array

Array

+ «property» Length : System.Int32

+ « property» R ank : System.Int32

+ « property» SyncRoot : System.Object+ « property» IsReadO nly : System.Boolean

+ « property» IsFixedSize : System.Boolean

«interface»

I C o l l e c t i o n

+ « property» Count : System .Int32

+ « property» SyncRoot : System.Object+ «property» IsSynchronized : System .Boolean

O b j e c tI C lo n e a b le I E n u m e ra b le

e

r i a d el

+ «property» IsSynchronized : System .Boolean

+ GetEnumerator ( )

+ CopyTo ( )

+ Clone ( )

«interface»



S o

f t w ar eT

+ Clone ( )

+ CreateInstance ( )

+ Clear ( )+ GetValue ( )

+ SetValue ( )

+ GetLength ( )

+ GetUpperBound ( )

+ GetLowerBound ( )

+ BinarySearch ( )

+ IndexOf ( )

+ LastIndexOf ( )

+ Reverse ( )

+ Sort ( )

+ Init ia l ize ( )

+ CopyTo ( )

+ CreateInstance ( )

+ Copy ( )

«interface»

I L i s t

+ « property» Item(System .Int32) : System.Object

+ « property» IsRea dOnly : System .Boolean

+ « property» IsFixedSize : System.Boolean

+ RemoveAt ( )

+ Remove ( )

+ Insert ( )

+ IndexOf ( )

+ Clear ( )

+ Conta ins ( )

+ A dd ( )

45

I n g e gn

System.Array

One-dimensional arraysint[] a = new int[3];

int[] b = new int[] {3, 4, 5};

int[] c = {3, 4, 5}; e

r i a d el

SomeClass[] d = new SomeClass[10];

// array of values (directly in the array)



S o

f t w ar eT

// array of values (directly in the array)

SomeStruct[] e = new SomeStruct[10];

46

I n

g e gn

System.Array

Multidimensional arrays (jagged)// array of references to other arrays

int[][] a = new int[2][];

// cannot be initialized directly e

r i a d el S

, ,

a[1] = new int[] {4, 5, 6};



S o

f t w ar eT

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];47

I n

g e gn

System.Array

Jagged (like in Java)int[][] a = new int[2][];

a[0] = new int[3];

a[1] = new int[4];

…

a

a[0]

a[1]

a[0][1]

e

r i a d el S

int x = a[0][1];

Rectangular (more



S o

f t w ar eT

Rectangular (morecompact and efficient)int[,] a = new int[2, 3];

…

int x = a[0, 1];

aa[0,1]

48




Delegati ed Eventi

I n

g e gn

Delegati

Sono oggetti che possono contenereil 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) e

r i a d el S

Simili ai puntatori a funzione del C/C++,ma object-oriented e molto più potenti



S o

f t w ar eT

Utilizzo standard: funzionalità di callback – Elaborazione asincrona

– Elaborazione cooperativa (il chiamato fornisce una parte delservizio, il chiamante fornisce la parte rimanente – es. qsort in C)

– Gestione degli eventi (chi è interessato a un certo evento si registrapresso il generatore dell’evento, specificando il metodo che gestiràl’evento)

2

I n

g e gn

C/C++PUNTATORI A FUNZIONI

int funX(char c);int funY(char c);

int (*g)(char c) = NULL;

...

g = cond1 ? funX : funY; e

r i a d el S

...

… g('H') … ≡ … (*g)('H') …



S o

f t w ar eT

3

I n

g e gn

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 }; e

r i a d el S

...

fun[m]("stringa di caratteri"); ≡

(*fun[m])("stringa di caratteri");



S o

f t w ar eT

fun0

fun1

fun2

fun[0]

fun[1]

fun[2]

4

I n

g e gn

Delegati

Dichiarazione di un nuovo tipo di delegatoche può contenere il riferimento a un metodo che ha un unicoargomento intero e restituisce un intero:

delegate int Action(int param);

e

r i a d el S o

Action action;



o

f t w ar eT

Inizializzazione di un delegato:action = new Action(nomeMetodoStatico);

…

action = new Action(obj.nomeMetodo);

Invocazione del metodo referenziato dal delegato:

int k1 = action(10);

5

I n

g e gn

DelegatiEsempio


class Class1

{

static void Main(string[] args)

{ction action e

r i a d el S o

action = new Action(Raddoppia);

Console.WriteLine("Risultato: {0}", action(10));

action = new Action(Dimezza);



o

f t w ar eT



}

static int Raddoppia(int x)

{ return x * 2; }

static int Dimezza(int x){ return x / 2; }

}

Risultato: 20Risultato: 5

6

I n

g e gn

DelegatiEsempio

delegate int Action(int param);class Class1

{

static void Main(string[] args)

{

Go(new Action(Raddoppia)); e

r i a d el S o

o new c on mezza ;

}

static void Go(Action action)



o

f t w ar eT

{ Console.WriteLine("Risultato: {0}", action(10));

}

static int Raddoppia(int x)

{ return x * 2; }

static int Dimezza(int x){ return x / 2; }

}

Risultato: 20Risultato: 5

7

I n

g e gn

DelegatiEsempio

Un delegato può contenere anche il riferimento a un metodoNON statico – in questo caso mantiene un riferimento ancheall’oggetto su cui invocare il metodo


class Class1 e

r i a d el S o

{

private int _y;

public Class1(int y)



o

f t w ar eT

public Class1(int y)

{ _y = y; }

public int Moltiplica(int x)

{ return x * _y; }

public int Dividi(int x)

{ return x / _y; }…

}

8

I n

g e gn

DelegatiEsempio

static void Main(string[] args){

Action action;

Class1 c = new Class1(5);

action = new Action(Raddoppia);

Console.WriteLine("Risultato: {0}", action(10)); e

r i a d el S o



action = new Action(c.Moltiplica);



o

f t w ar eT

Console.WriteLine("Risultato: {0}", action(10));action = new Action(c.Dividi);


}Risultato: 20Risultato: 5Risultato: 50Risultato: 2

9

I n

g e gn

Delegati

Esempio3.Step1 – Delegati anonimi – Lambda expressions

– Reflector e

r i a d el S o

Esempio3.Step2



f t w ar eT

10

I n

g e gn

DelegatiMulticasting

Possibilità di creare una lista di metodi che vengono chiamati – automaticamente e – in sequenza

all’atto della chiamata del delegato

e

r i a d el S o

Per aggiungere un metodo alla lista: +=

Action action = new Action(Fun1);



f t w ar eT

… action(10) … // Fun1(10)action += new Action(Fun2);

… action(10) … // Fun1(10), Fun2(10)

Per togliere un metodo dalla lista: -=

action -= new Action(Fun1);

… action(10) … // Fun2(10)

11

I n

g e gn

Delegati

Invocation of a delegate instance whose invocation list containsmultiple entries proceeds by invoking each of the methods on theinvocation list, synchronously, in order

Each method so called is passed the same set of arguments as

was given to the delegate instance e

r i a d el S o

– each method invocation will occur with a reference to the same

variable



f t w ar eT

– changes to that variable by one method in the invocation list will bevisible to methods further down the invocation list

If the delegate invocation includes output parameters or a returnvalue

– their final value will come from the invocation of the last delegate inthe list

12

I n

g e gn

DelegatiEsempio multicasting

delegate string Action(ref string param);class Class1

{

static string ToUpper(ref string str)

{str = str.ToU er return str e

r i a d el S o

}

static string TrimEnd(ref string str)

{



f t w ar eT

str = str.TrimEnd(); return str;

}

static string TrimStart(ref string str)

{

str = str.TrimStart(); return str;}

…

13

I n

g e gn

DelegatiEsempio multicasting

static void Main(string[] args){

string s1 = " abcdefghijk ";

Action action =

new Action(ToUpper) +new Action(TrimStart) + e

r i a d el S o

new Action(TrimEnd);

Console.WriteLine("s1a: \"" + action(ref s1) + "\"");

Console.WriteLine("s1b: \"" + s1 + "\"");



f t w ar eT

}

}

s1a: "ABCDEFGHIJK"s1b: "ABCDEFGHIJK"

14

I n

g e gn

Delegati

A delegate instance encapsulates one or more methods (with aparticular set of arguments and return type), each of which isreferred 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 e

r i a d el S o

An interesting and useful property of a delegate is that it does notknow or care about the class of the object that it references



f t w ar eT

Any object will perfectly do; all that matters is that the method'sargument types and return type match the delegate's

This makes delegates suited for anonymous invocation

15

I n

g e gn

Delegati

In C#, la dichiarazione di un nuovo tipo di delegato definisceautomaticamente una nuova classe derivata dalla classeSystem.MulticastDelegate

System.Object e

r i a d el S o

.

System.MulticastDelegate

Action



f t w ar eT

Pertanto, sulle istanze di Action è possibile invocare i metodidefiniti a livello di classi di sistema

16

I n

g e gn

Delegati

ICloneable

Object

«interface»

ISerializable

+ GetObjectData ( )

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....


# RemoveImpl ( [in] d : System.Delegate ) : System.Delegate

# CombineImpl ( [in] d : System.Delegate ) : System.Delegate

# GetMethodImpl ( ) : System.Reflection.MethodInfo+ GetInvocationList ( ) : System.Delegate[]

e

r i a d el S o

# DynamicInvo eImp in args : System.O ject : System.O ject



+ 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



f t w ar eT

«delegate»

MulticastDelegate

+ 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

I n

g e gn

DelegatiEsempio

Action action =new Action(ToUpper) +

new Action(TrimStart) +

new Action(TrimEnd);

…

foreach (Action a in action.GetInvocationList()) e

r i a d el S of t w

Console.WriteLine(a.Method.Name);

ToUpperTrimStart



tw ar eT

foreach (Action a in action.GetInvocationList())

Console.WriteLine(a.Method.ToString());

TrimEnd

System.String ToUpper(System.String ByRef)System.String TrimStart(System.String ByRef)System.String TrimEnd(System.String ByRef)

18

I n

g e gn

DelegatiEsempio Boss-Worker

È necessario modellare un’interazione tra due componenti – un Worker che effettua un’attività (o lavoro) – un Boss che controlla l’attività dei suoi Worker

Ogni Worker deve notificare al proprio Boss: – quando il lavoro inizia

e

r i a d el S of t w

– quando il lavoro è in esecuzione – quando il lavoro finisce



tw ar eT

Soluzioni possibili: – class-based callback relationship

– interface-based callback relationship

– delegate-based callback relationship

– eventi

19

I n

g e gn

A class-basedcallback relationship: caller

class Worker { private Boss _boss;

public void Advise(Boss boss)

{ _boss = boss; }

public void DoWork()

{" " e

r i a d el S of t w

.

if(_boss != null) _boss.WorkStarted(this);

Console.WriteLine("Worker: work progressing");

if(_boss != null) _boss.WorkProgressing(this);

C l W it Li ("W k k l t d")



tw ar eT

Console.WriteLine("Worker: work completed");if(_boss != null)

{

int grade = _boss.WorkCompleted(this);

Console.WriteLine("Worker grade = {0}",grade);

}}

}20

I n g e gn

A class-basedcallback relationship: target

class Boss{

public void WorkStarted(Worker worker)

{

// Boss doesn't care

} e

r i a d el S of t w

public void WorkProgressing(Worker worker)

{


}



w ar eT

} public int WorkCompleted(Worker worker)

{

Console.WriteLine("It's about time!");

return 2; // Out of 10}

}

21

I n g e gn

A class-basedcallback relationship: registration

class Universe{

static void Main()

{

Worker peter = new Worker();

Boss boss = new Boss(); e

r i a d el S of t w

peter.Advise(boss);

peter.DoWork();

}

}



w ar eT

}

Worker

+ Advise ( [in] boss : Boss )

+ DoWork ( )

Boss

+ WorkStarted ( [in] worker : Worker )

+ WorkProgressing ( [in] worker : Worker )

+ WorkCompleted ( [in] worker : Worker ) : int

- _boss

«use»

22

I n g e gn

Interface-basedcallback relationship

Interface-based designs are incrementally better than class-baseddesigns 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 e

r i a d el S of t w

An interface used for callbacks:

interface IWorkerEvents



w ar eT

interface IWorkerEvents{

void WorkStarted(Worker worker);

void WorkProgressing(Worker worker);

int WorkCompleted(Worker worker);}

23

I n g e gn

An interface-basedcallback relationship: caller

class Worker { private IWorkerEvents _target;

public void Advise(IWorkerEvents target)

{ _target = target; }


{" " e

r i a d el S of t w

.

if(_target != null) _target.WorkStarted(this);


if(_target != null) _target.WorkProgressing(this);

Console WriteLine("Worker: work completed");



war eT

Console.WriteLine( Worker: work completed );if(_target != null)

{

int grade = _target.WorkCompleted(this);


}}

}24

I n g e gn

An interface-basedcallback relationship: target

class Boss : IWorkerEvents{

public void WorkStarted(Worker worker)

{


} e

r i a d el S of t w a

public void WorkProgressing(Worker worker)

{


}



war eT

} public int WorkCompleted(Worker worker)

{

Console.WriteLine("It's about time!");

return 4; // Out of 10

}

}

25

I n g e gn

An interface-basedcallback relationship

Worker

+ Advise ( [in] target : IWorkerEvents )

+ DoWork ( )

«interface»

IWorkerEvents




- _target

«use»

e


Boss




ar eT

( [ ] )



26

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

I n g e gn

– The result is that the objects become intertwined (closelycoupled) and can't easily be reused

Solution

er i a d el S of t w a



Solution

– Create a loosely-bound one-to-many relationship between anobject 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

ar eT

Pattern OBSERVER

There are two mechanisms which can be used to implement aloose coupling between a subject and its observers

Dependency allows an observer to register an interest in ALL

aspects of another object

I n g e gn

– it can do something sensible in response

Events allow an observer to register an interest in a specificaspect of another object (publisher) and even request that a

er i a d el S of

t w a



aspect of another object (publisher) and even request that aparticular message is routed to them – when the publisher triggers an event the routing is automatic

28

ar eT

I n g e gn

Pattern OBSERVER

e

r i a d el S of

t w a



r eT

29

I n g e gn

A delegate-basedcallback relationship

Un delegato è un’entità type-safe riconosciuta e gestita dal CLRche 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 e

r i a d el S of

t w ar

– – Support multiple call targets – Support asynchronous method invocation



r eT

30

I n g

e gn

A delegate used for callbacks

interface IWorkerEvents{

void WorkStarted(Worker worker);

void WorkProgressing(Worker worker);

int WorkCompleted(Worker worker); e

r i a d el S of

t w ar



r eT

delegate void WorkStarted(Worker worker);

delegate void WorkProgressing(Worker worker);

delegate int WorkCompleted(Worker worker);

31

I n g

e gn

A delegate-basedcallback relationship: caller

class Worker { public WorkStarted Started;

public WorkProgressing Progressing;

public WorkCompleted Completed;


{" " e

r i a d el S of

t w ar

.

if(Started != null) Started(this);


if(Progressing != null) Progressing(this);

Console.WriteLine("Worker: work completed");if(Completed != null)



r eT if(Completed != null)

{

int grade = Completed(this);


}}

}32

I n g

e gn

Adelegate-basedcallback relationship: target

class Boss{

public int WorkCompleted(Worker worker)

{

Console.WriteLine("Better...");

return 6; // Out of 10 e

r i a d el S of

t w ar e

}

}



eT

33

I n g

e gn

Adelegate-basedcallback relationship

Worker

+ DoWork ( )

Boss


«delegate»

WorkProgressing

«delegate»WorkStarted

«use»

+ Started

+ Progressing

e

r i a d el S of

t w ar e

WorkCompleted + Completed

WorkStarted

+ Started



eT

Worker

+ DoWork ( )

Boss

+ WorkCompleted ( [ in] worker : Worker ) : int

WorkCompleted

WorkProgressing

WorkStarted

«use»

+ Completed

+ Progressing

34

I n g

e gn

Adelegate-basedcallback relationship: registration

class Universe{

static void Main()

{


Boss boss = new Boss(); e

r i a d el S of

t w ar e

peter.Completed =

new WorkCompleted(boss.WorkCompleted);

peter.DoWork();

}}



eT

}

35

I n g

e gn

A delegate-basedcallback relationship

e

r i a d el S of t w ar e



eT

36

I n g

e gn

Multiple target registration

class Universe

{

static void WorkerStartedWork(Worker worker)

{

Console.WriteLine

("Universe notices working starting"); e


static int WorkerDoneWorking(Worker worker)

{

Console.WriteLine

("Universe notices is worker done");return 7;



eT

}

static void Main()

{

…}

}

37

I n g

e gn

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); e


peter.Progressing = null;

peter.Completed(peter);

// Preferred registration syntax: peter.Completed += new WorkCompleted(WorkerDoneWorking);



T p p p ( g);

peter.DoWork();

38

I n g

e gn

A multicast delegate

e




T

39

I n g

e gn

Iterating throughregistered targets

class Worker

{


{

// Start and progress with work...

Console.WriteLine("Worker: work completed"); e


{

foreach (WorkCompleted wc in Completed.GetInvocationList())

{

int grade = wc(this);Console.WriteLine("Worker grade = {0}",grade);



T

}

}

}

…}

40

I n g

e gn

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)

Public registration methods coupled with private delegate field is e


better, but tedious if done manually

event modifier automates support for

– public [un]registration and



T

– private implementation

41

I n g

e gn

An event-basedcallback relationship: caller

class Worker {

public event WorkStarted Started;

public event WorkProgressing Progressing;

public event WorkCompleted Completed;


{ " " e


.

if(Started != null) Started(this);


if(Progressing != null) Progressing(this);

Console.WriteLine("Worker: work completed");if(Completed != null)



T

{

int grade = Completed(this);


}}

}42

I n g

e gn

An event-basedcallback relationship: registration


Boss boss = new Boss();

// Illegal: assignment to event field not supported:

peter.Completed = new WorkCompleted(boss.WorkCompleted);

peter.Started = new WorkStarted(WorkerStartedWork); e


peter.Progressing = null;

// Illegal: execution of event not supported:

peter.Completed(peter);

// Registration still supported:



T // Registration still supported:

peter.Completed += new WorkCompleted(WorkerDoneWorking);

peter.DoWork();

43

I n g

e gn

An event-basedcallback relationship

Worker

+ DoWork ( )

Boss


«delegate»

WorkProgressing

«delegate»WorkStarted

«use»«event»

+ Progressing

«event»

+ Started

e


WorkCompleted + Completed



T

44

I n g

e gn

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

TECNICHE AVANZATE

e


custom ze – Client-side access syntax not affected – You must provide storage for registered clients



T

45

I n g

e gn

Customizing event registration

class Worker

{ …

public event WorkProgressing Progressing

{

add

{

TECNICHE AVANZATE

e

r i a d el S of t

w ar eT

. .

{ _progressing += value; }

else

{ throw new InvalidOperationException

("Must register before noon."); }}

remove



remove

{ _progressing -= value; }

}

private WorkProgressing _progressing;…

}

46

I n g

e gn

Eventi

Evento: “Fatto o avvenimento determinante nei confronti di una situazione oggettiva o soggettiva ”

In programmazione, un evento può essere scatenato – dall’interazione con l’utente (click del mouse, …)

– dalla logica del programma e

r i a d el S of t

w ar eT

Event sender – l’oggetto (o la classe) che scatena (raises otriggers ) l’evento (sorgente dell’evento)

Event receiver – l’oggetto (o la classe) per il quale l’evento èdeterminante e che quindi desidera essere notificato quandol’evento si verifica (cliente)



l evento si verifica (cliente)

Event handler – il metodo (dell’event receiver ) che viene eseguito

all’atto della notifica

47

I n g

e gn

Eventi

Quando si verifica l’evento,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 e

r i a d el S of t

w ar eT

anonime)



48

I n g

e gn

Dichiarazione di un evento

Un evento incapsula un delegatoè quindi necessario dichiarare un tipo di delegato prima dipoter dichiarare un evento

By convention, event delegates in the .NET Framework have two

parameters e

r i a d el S of t

w ar eT

– 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



Many events, including some user interface events such asmouse clicks, do not generate event data

In such situations, the event delegate provided in the class libraryfor the no-data event, System.EventHandler, is adequate

49

I n g

e gn


public delegate void EventHandler(

object sender, EventArgs e);

System.Object

System.Delegate e

r i a d el S of t

w ar eT

.

System.EventHandler

La classe System.EventArgs viene utilizzata quando un eventonon deve passare informazioni aggiuntive ai propri gestori



Se i gestori dell’evento hanno bisogno di informazioni aggiuntive,è necessario derivare una classe dalla classe EventArgs e

aggiungere i dati necessari

50

I n g

e gn


public event EventHandler Changed;

In pratica, Changed è un delegato, ma la keyword event nelimita

– la visibilità e e

r i a d el S of t

w ar eT

– le possibilità di utilizzo

Una volta dichiarato, l’evento può essere trattato come un

delegato di tipo specialein particolare, può:



– essere null se nessun cliente si è registrato

– essere associato a uno o più metodi da invocare

51

I n g

e gn

Invocazione di un evento

Per scatenare un evento è opportuno definire un metodo protettovirtuale OnNomeEvento è invocare sempre quello public event EventHandler Changed;

protected virtual void OnChanged(){

if(Chan ed != null) e

r i a d el S of t

w ar eT

Changed(this, EventArgs.Empty);

}

…

OnChanged();

…



Limitazione rispetto ai delegatiL’invocazione dell’evento può avvenire solo

all’interno della classe nella quale l’evento è stato dichiarato(benché l’evento sia stato dichiarato public)

52

I n g e gn

Agganciarsi a un evento( hooking up to an event )

Al di fuori della classe in cui l’evento è stato dichiarato, un eventoviene visto come un delegato con accessi molto limitati

Le sole operazioni effettuabili sono: – Aggiungere un nuovo delegato alla lista dei delegati

mediante l’operatore += e


– Rimuovere un delegato dalla lista dei delegatimediante l’operatore -=



53

I n g e gn

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 all’atto

della notifica dell’evento (con la stessa signature dell’evento):

void ListChanged(object sender, EventArgs e)

{ … } e


Creare un delegato dello stesso tipo dell’evento e farlo riferire almetodo:

EventHandler listChangedHandler =new EventHandler(ListChanged);



Aggiungere il delegato alla lista dei delegati associati all’evento,utilizzando l’operatore +=:

List.Changed += listChangedHandler;

54

I n g e gn

Sganciarsi da un evento

Per smettere di ricevere le notifiche di un evento, il cliente deve: Rimuovere il delegato dalla lista dei delegati associati all’evento,

utilizzando l’operatore -=:

List.Changed -= listChangedHandler; e


Per aggiungere e rimuovere un delegato dalla lista dei delegatiassociati all’evento si può anche scrivere:

List.Changed += new EventHandler(ListChanged);

Li t Ch d E tH dl (Li tCh d)



List.Changed -= new EventHandler(ListChanged);

List.Changed += ListChanged; // C# 2.0

List.Changed -= ListChanged; // C# 2.0

55

I n g e gn

Eventi

Since += and -= are the only operations that are permitted on anevent 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 e


Events provide a generally useful way for objects to signal statechanges that may be useful to clients of that object

Events are an important building block for creating classes thatcan be reused in a large number of different programs



56


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

I n g e gn

,




2

Why Have Metadata?

“Provided that a component comes withenough information to be self-describing, the

interfaces supported by a component can be

dynamically explored”

I n g e gn

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

I n g e gn

++ as a so a e support or un- me ype 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 I n g e gn

– COM – Type Libraries

– CORBA – Interface Repository




5

COM IDL

import "oaidl.idl";

import "ocidl.idl";

#include "olectl.h"

[ object,

uuid(29AABB7F-E702-11D2-89CF-004033412CFC),

dual, helpstring("IPolyCtl Interface"),

I n g e gn

pointer_default(unique) ]

interface IPolyCtl : IDispatch

{

[ propget, id(1),

helpstring("property Sides") ]

HRESULT Sides([out, retval] short *pVal);

[ t id(1)




[ propput, id(1),

helpstring("property Sides") ]

HRESULT Sides([in] short newVal);};

6

IDL Reflection

IDLs are an additional requirement for developers tounderstand

Interface Repositories and Type Libraries can behoused in separate files to the type they describe

I n g e gn

Java/.NET use reflection

The metadata is generated from the type’s definition

The metadata is stored with the type’s definition if you have the definition you have the metadata and




vice versa

7

Reflection

Reflection can be used – To examine the details of an assembly

– To instantiate objects and call methods discovered atruntime

– To create, compile, and execute assemblies on the fly

I n g e

gn

.NET classes that deal with providing reflection can be

found in:– System

– System.Reflection

er i a d el S of t w

ar eT



System.Reflection

– System.Reflection.Emit

8

Application Domain

Assemblies, modules and types

Assembly AssemblyI n g e

gn

Module Module

T

TypeType

Module

T

Type


ar eT



Type Type

9

System.Type

System.Typeis the focal point of reflection

– All objects and values are instances of types

– Can discover type of object or valueType t0 = obj.GetType();

= " "

I n g e

gn

.

– Can reference type by symbolic nameType t2 = typeof(System.String);

Type t3 = Type.GetType("System.String");

– Types are themselves instances of type System.Type

There is a single Type object


ar eT



There is a single Type object

for each type defined in the system

10

System.Type

I n g e

gn


ar eT



11

System.Type

I n g e

gn


ar eT



Esempio 5.112

System.Type

Some methods:– Type[] GetInterfaces();

– MemberInfo[] GetMembers();

– ConstructorInfo[] GetConstructors();

– MethodInfo[] GetMethods();

I n g e

gn

– FieldInfo[] GetFields();

– PropertyInfo[] GetProperties();

– EventInfo[] GetEvents();

– object[] GetCustomAttributes();


ar eT



13

Reflection and

the CLR type system

I n g e

gn


ar eT



14

The reflection object model

GetNestedTypes

I n g e

gn


ar eT



Esempio 5.215

EsempioEnumerating all types in an Assembly

1. Use Assembly.Load to load a .NET assemblyreturns an Assembly

2. Assembly.GetModules

returns an array of Module

I n g e

gn

.

, .

returns an array of Type

4. For each Type, …


ar eT



Esempio 5.316

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

I n g e

gn

.

…

– Can invoke property getters and setters

propertyInfo.GetValue(…)

propertyInfo.SetValue(…)

Public members always accessible

Non-public members accessible if callers hold sufficientpermissions


ar eT



pe ss o s

Esempio 5.417

System.Activator

Dynamically create instances

Activator.CreateInstance is the late-bound equivalent tooperator new

– Allocates storage for new type instance

– Calls specified constructor

I n g e

gn

– e urns gener c o ec re erence

T1 t = (T1) Activator.CreateInstance(typeof(T1));

T1 t = (T1) Activator.CreateInstance(typeof(T1),

object[] args);


ar eT



Esempio 5.518

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 thatsystem is called reification.Programming a system to not only use reified information but also

to mani ulate this information is called meta- ro rammin .

TECNICHE AVANZATE

I n g e

gn

…meta-programming can be used to dynamically create newclasses, insert them into an existing inheritance graph andinstantiate them”

Szyperski, C.,Component Software [Addison-Wesley, 1998]

• Reificazione: Concretizzazione di un’astrazione


ar eT



• Reificazione: Concretizzazione di un astrazione

19

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

TECNICHE AVANZATE

I n g e

gn

– Reflection.Emit a ows you o wr e ou e necessary o

create and compile the assembly

– You can then call this assembly from with the program thatcreated it

– The assembly can be stored to disk so that other programscan use it


ar eT



20

Meta-Programming in .NET

System.Reflection

– AssemblyName

Fully describes an assembly's unique identity

System.Reflection.Emit

– AssemblyBuilder

TECNICHE AVANZATE

I n g e

gn

Defines and represents a dynamic assembly

– ModuleBuilder

Defines and represents a module

–

TypeBuilderDefines and creates new instances of classes during runtime

– MethodBuilder

Defines and represents a method (or constructor) on a dynamic class


ar eT



p ( ) y

– ILGenerator

Generates Microsoft intermediate language (MSIL) instructions

21

Assembly: MyAssembly

Module: MyModule

Dynamically Creating a Type

TECNICHE AVANZATE

I n g e

gn

Method: MyMethod

WriteLine("Hello World!");


ar eT



Esempio 5.622

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 oncertain functionality

I n g e

gn

– 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


ar eT



23

Creating

Custom Attributes

Declare the attribute class

public class AuthorAttribute : System.Attribute

Declare constructors

Declare properties

I n g e

gn

Specifies some of the characteristics of the class

– The target of the attribute ( AttributeTargets) – a quali elementil’attributo è applicabile

– Whether or not the attribute can be inherited (Inherited) – Whether or not multiple instances of an attribute can exist for an

element ( AllowMultiple)


ar eT



Esempio 5.7 – AuthorAttribute24

Using

Custom Attributes

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

Attribute parameters passed

– by position or

– by name

I n g e

gn

[ Author("Bellavia",

Contact="[email protected]") ]

Nome di una proprietà


ar eT



Esempio 5.7 – MyClass25

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 theGetCustomAttributes method

object[] X.GetCustomAttributes(inherit);

I n g e

gn

.

,

inherit specifies whether to search this member's inheritancechain to find the attributes

Xè – un’istanza di

Assembly, Module

MemberInfo

ParameterInfo


ar eT



ParameterInfo

Esempio 5.726


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 un’area di memoria dove memorizzare il suo stato

Passi per utilizzare un oggetto di tipo riferimento:

I n g e gn

– Allocare memoria per l’oggettoin seguito a una new (istruzione newobj di IL)

– Inizializzare la memoria per rendere utilizzabile l’oggettovalori di default + costruttore

– Usare l’oggetto

– Eseguire un clean up dello stato dell’oggetto, se necessarioFinalize (distruttore in C# e C++), Dispose, Close


ar eT



– Liberare la memoria

responsabilità del Garbage Collector (GC)

2

Ciclo di vita di un oggetto

I n g e gn

e

r i a d el S of t w

ar eT



3

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) l’indirizzo dipartenza della regione

I n g e gn

NextObjPtr


ar eT



4


Quando deve eseguire una newobj, il CLR – Calcola la dimensione in byte dell’oggetto e aggiunge

all’oggetto due campi di 32 (o 64) bit Un puntatore alla tabella dei metodi Un campo SyncBlockIndex

I n g e gn

– 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 dell’oggetto (this ≡ thisObjPtr)


ar eT



– Restituisce il riferimento all’oggetto

5


NextOb Ptr

I n g e gn

Oggetti “vivi”

Oggetti non raggiungibili

Tecnica di allocazionecompletamente diversada quella del C/C++


ar eT



Spazio libero

6

Garbage Collector

Verifica se nell’heap esistono oggetti non più utilizzati

dall’applicazione – Ogni applicazione ha un insieme di radici (root ) – Ogni radice è un puntatore che contiene l’indirizzo di un

oggetto di tipo riferimento oppure vale null

I n g e gn

– 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 l’indirizzo di un oggetto di tiporiferimento – Gli oggetti “vivi” sono quelli raggiungibili direttamente o

indirettamente dalle radici– Gli oggetti garbage sono quelli NON raggiungibili


ar eT



Gli oggetti garbage sono quelli NON raggiungibili

direttamente o indirettamente dalle radici

7

Garbage Collector

Quando parte, il GC ipotizza che tutti gli oggetti sianogarbage

Quindi, scandisce le radici e per ogni radice marca

– L’eventuale oggetto referenziato e

I n g e gn

– 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


ar eT



oggetti NON marcati sono non raggiungibili e quindigarbage

8

Garbage Collector

Fase 1: Mark

I n g e gn

Oggetti “vivi”

NextObjPtr

Root set


ar eT



Oggetti non raggiungibiliSpazio libero

9

Garbage Collector

Rilascia la memoria usata dagli oggetti nonraggiungibili

Compatta la memoria ancora in uso,modificando nello stesso tempo tutti i riferimenti

I n g e gn

Unifica la memoria disponibile, aggiornando il valore di NextObjPtr

Tutte le operazioni che il GC effettua sono possibili inquanto – Il tipo di un oggetto è sempre noto


ar eT



– È possibile utilizzare i metadati per determinare quali field dell’oggetto fanno riferimento ad altri oggetti

10

Garbage Collector

Fase 2: Compact

Spazio recuperatoI n g e g

n

Oggetti “vivi”

NextObjPtr

Root set


ar eT



Oggetti non raggiungibiliSpazio libero

11

Finalization

Non è responsabilità del GC, ma del programmatore Se un oggetto contiene esclusivamente

– tipi valore e/o – riferimenti a oggetti managed

I n g e g

n

,

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 larisorsa, prima della deallocazione dell’oggetto


ar eT



, p gg

12

Finalization

Ad esempio, un oggetto di tipoSystem.IO.FileStream

– Prima deve aprire un file e memorizzare in un suo field

l’handle del file (una risorsa di S.O. unmanaged ) – Quindi usa tale handle nei metodi Read e Write

I n g e g

n

– Infine, deve rilasciare l’handle nel metodo Finalize

In C# – NON è possibile definire il metodo Finalize

– È necessario definire un distruttore (sintassi C++)


ar eT



13

Finalization

public class OSHandle

{// Field contenente l’handle della risorsa unmanaged private readonly IntPtr _handle;

// Proprietà che restituisce il valore dell’handle public IntPtr Handle

I n g e g

n

{ 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); }

I n g e g

n

ne seguen e co ce ovv amen e n :

protected override void Finalize()

{

try

{ CloseHandle(_handle); }

finally

{ base.Finalize(); }




}

15

Finalization

Il metodo Finalize dovrebbe essere utilizzatosolo per rilasciare risorse unmanaged cheappartengono all’oggetto su cui eseguire il metodo

Nel metodo Finalize si dovrebbe evitare

I n g e g

n

– Potrei cercare di accedere a un oggetto sul quale il GC ha giàinvocato il corrispondente metodo Finalize e che quindipotrebbe essere in uno stato non ben definito

Tutti i metodi Finalize vengono eseguiti in un thread dedicato (diverso da quello del GC) – pertanto, nelcodice non si devono fare ipotesi sul thread inesecuzione




16

Il pattern Dispose

L’invocazione del metodo Finalize non avviene in

modo deterministico Inoltre, non essendo un metodo pubblico, il metodoFinalize non può essere invocato direttamente

Nel caso di utilizzo di risorse che devono essere

I n g e g

n

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 ilcorrispondente 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 unservizio di clean up esplicito ai suoi utilizzatori

I n g e g

n

Innanzi tutto, il tipo deve implementare l’interfacciaIDisposable

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

I n g e g

n

// e che quindi implementano IDisposable

…// Costruttore/i…

~MyClass(){

Dispose(false);

}

Invocazione NONdeterministica




19

Il pattern Dispose

// Metodo da invocare per un rilascio deterministico

public void Dispose(){

Dispose(true);

// Take yourself off of the Finalization queue to prevent

Invocazionedeterministica

I n g e g

n

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 simultaneouslylock (this)

{

I n g e g

n

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 calleddirectly or indirectly by a user's codeManaged and unmanaged resources can be disposed

– if disposing == false, the method has been called

b the runtime from inside the finalizer and

I n g e g

n

you should not reference other objectsOnly unmanaged resources can be disposed

if(disposing)

{

// Dispose managed resources

}

// Dispose unmanaged resources




22

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()

I n g e g

n

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)

I n g e g

n

try{if(disposing){ // Dispose managed resources }// Dispose unmanaged resources _disposed = true;}finally{ base.Dispose(disposing); }

}

}


r eT



}}

24

Il pattern Dispose

dal lato del cliente – senza using

…

Byte[] bytesToWrite = new Byte[] {1,2,3,4,5};FileStream fs = null;

try

{

“ ”

I n g e g

n

.

, .fs.Write(bytesToWrite, 0, bytesToWrite.Length);

}

finally

{if(fs != null) fs.Close();

}

…


r eT



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))

{

I n g e g

n

.

, , .}

…

All’uscita del blocco using, viene sempre invocatoautomaticamente il metodo Dispose Il tipo della variabile definita nella parte iniziale di using deve

implementare l’interfaccia IDisposable


r eT



26


Interfaccia utente



I n g e g

n


The System.Windows.Forms namespace contains

classes for creating Windows-based applications

The classes can be grouped into the following

categories:

e


r eT

– orm, on ro , an ser on ro – Controls

– Components

–

Common Dialog Boxes



2

I n g e g

n


e


r eT



3

I n g e g

n

Elements of a

Windows Application

Windows/Dialog BoxesForm

Idle Processing

Message Pump

e


r eT

Message Handling /Application LifetimeSystem.Windows.Forms.

Application

MenusMenuItemMainMenuContextMenu

ControlsButtonComboBoxListBox

TextBoxD t G id

ZZZ…



DataGridEtc…Spy++

4

I n g e g

n

HelloWorld

Windows Application

using System;

using System.Windows.Forms;

namespace HelloWorld

{

static class Program e


r eT

[STAThread] // COM threading model

static void Main()

{

Application.EnableVisualStyles();

Application.SetCompatibleTextRenderingDefault(false); Application.Run(new HelloWorldForm());

}

}

}



5

I n g e g

n

HelloWorld

Windows Application

namespace HelloWorld

{ public partial class HelloWorldForm : Form

{

public HelloWorldForm()

{ e


r eT

}

protected override void OnPaint(PaintEventArgs e)

{

base.OnPaint(e);e.Graphics.DrawString("Hello World!",

new Font("Arial",36), Brushes.Blue, 10, 100);

}

}

}S tit i



Sostituire con Label6

I n g e gn

Creating

Windows Applications

Typical windows-application design

– One or more classes derived from System.Windows.Form

Derived classes

– Affect instance appearance and behavior by setting e


r eT

– 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



7

I n g e gn

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)

– Background threads used for lengthy non-UI functionality e


r eT

Typical windows-applications development

– Design UI with VisualStudio .NET

Possible to do anything directly via code

– Also use classes in System.Drawing namespace



8

I n g e gn

System.Drawing namespace

Full of types used heavily in windows applications

Implements basic graphic objects – Classes: Graphics, Font, Brush, Pen, Icon, Bitmap, ...

– Instance Creators: Brushes, Pens, SystemBrushes,S stemColors S stemIcons Cursors

e


r eT

– Structures: Point, Size, Rectangle, Color, ...

System.Drawing.Graphics

– 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(), ...



9

I n g e gn

System.Windows.Forms.Application

Non-instantiable class with public static methods and

properties Used to handle windows-application infrastructure

– Message pump methods

e


r eT

Exit() - Informs all message pumps that they must terminate,

and then closes all application forms after the messages havebeen processed

– Application level events

Idle, ApplicationExit



10

I n g e gn

Controls

A control is a component that provides (or enables)

user-interface (UI) capabilities The .NET Framework provides two base classes for

controls:– e


r eT

. . . for client-side Windows Forms controls

– System.Web.UI.Control

for ASP.NET server controls

All controls in the .NET Framework class library derivedirectly or indirectly from these two classes



11

I n g e gn

Controls

The System.Windows.Forms namespace provides a

variety of control classes that allow you to create richuser interfaces

Some controls are designed for data entry– TextBox, ComboBox, …

e


r eT

Other controls display application data– Label, ListView, …

The namespace also provides controls for invoking

commands within the application– Button, ToolBar, …



12

I n g e gn

System.Windows.Forms.Control

Base-class for all controls/forms in managed code

– Provides the base functionality for all controls that aredisplayed on a Form

– Derives from Component

– Wraps an underlying OS window handle

e


r eT

mp emen s many – Properties for modifying settings of an instance

Size, BackColor, ContextMenu, ...

– 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



13

I n g e gn

System.Windows.Forms.Control

Derived classes override and specialize functionality

– Specialized methods, properties, and events TextBox – PasswordChar, Undo(), Copy()

Button – Image, PerformClick()

– The Form class is derived from Control

e


r eT

To create a custom control that is a composite ofother controls, use the UserControl class



14

I n g e gn

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 e


r eT

– on a n a ma n menu – Contain a title-bar, system menu, minimize/maximize

– Implement MDI - Multiple Document Interface

– Manage dialog buttons

– ...

Your applications derive from Form to create

– Windows

– Dialog boxes



15

I n g e gn

Using Forms

Create a Form-derived class

class BlueForm : Form { public BlueForm(){ BackColor = Color.Blue; }

}

e


r eT

1. Start message loop and display form

Application.Run(new BlueForm());

2. Show the derived form (modeless)

Form form = new BlueForm(); // Display on currentform.Show(); // thread’s message loop

3. Show the derived form as a dialog (modal)

Form form = new BlueForm(); // Display on current

form.ShowDialog(); // thread’s message loop



16

I n g e gn

Using Forms

In the type’s constructor

– Set properties – Create child controls

Use the Controls property to add controls to the form

– Setup the form’s menu

e


– OnFormClosing(), OnPaint(), OnMouseMove(), ...

– Do not override when default functionality is ok (usually thecase)

– When overriding a virtual method, usually call the base-

implementation of the method protected override void OnPaint(PaintEventArgs e){ base.OnPaint(e);// Do some work

}



17

I n g e gn

Multiple Document Interface

Nel costruttore della MainForm:

– IsMdiContainer = true;

Per aggiungere una ChildForm:– Form childForm = new ChildForm();childForm.MdiParent = mainForm;

e


childForm.Show();



18

I n g e gn

Using Controls

Create the control

Button ctrl = new Button(); // Create a button

Set properties

ctrl.Text = "A Button"; // set its textctrl.Location = new Point(10, 10); // and location

e


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 handlerctrl.Click += new EventHandler(ButtonClicked);



19

I n g e gn

Common Dialog Boxes

Common dialog boxes can be used to give your application a

consistent user interface when performing tasks such as openingand 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 toand enter the name of a file to open or save

e


– The FontDialog class displays a dialog box to change elements of

the Font object used by your application

– The PageSetupDialog, PrintPreviewDialog, andPrintDialog classes display dialog boxes that allow the user to

control aspects of printing documents 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



20

I n g e gn

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

– Control over unmanaged resources

e


– - 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 .NETFramework; a component developer does not have to do anyadditional work to take advantage of the base design-time

functionality



21

I n g e gn

Components

The System.Windows.Forms namespace provides

classes that do not derive from the Control class butstill provide visual features to a Windows-basedapplication

e


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

I n g e gn

Working with Menu’s

MainMenu, ContextMenu, and MenuItem are derived from

Menu Menu includes a collection of MenuItem ’s

e


MainMenu ContextMenu MenuItem

Parent1

*

Menu.MenuItemCollection

1 MenuItems1

1

Item []

*

23



23

I n g e gn


Create a MainMenu (or ContextMenu)

MainMenu mainMenu = new MainMenu();

Add MenuItem s to the MainMenu

MenuItem menuItem1 = new MenuItem("&File");

e


. .

Add sub- MenuItem s

MenuItem menuItem2 = new MenuItem("E&xit");

menuItem1.MenuItems.Add(menuItem2);

Set Form ’s Menu property to the instance of the MainMenu

myForm.Menu = mainMenu;

24



24

I n g e gn


Define event handlers

private void ExitHandler(object sender, EventArgs e){

Close();

}

e


Register event handlers menuItem2.Click += new EventHandler(ExitHandler);

25



25


Principi e concetti object-oriented



Dal caos iniziale…

Data DataCode

Programmazione strutturata

Ingegneria del Software T2

Data

DataCode

o e

Code

Variabili globali

Goto



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 nell’accesso 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, Böhm e Jacopini dimostrano che

qualsiasi programma che utilizza istruzioni GOTOpuò essere riscritto senza GOTO, a patto di avere a

disposizione tre tipi di strutture di controllo:se uenza ri etizione e alternativa


Nel 1968, Dijkstra discute in modo approfonditogli effetti deleteri del GOTO sulla qualità del

software, e in particolare sulla sua leggibilità e

modificabilità



…alla programmazione basata sugli oggetti

ADT (Abstract D ata T ype )

dati + codice che opera sui datiinterfaccia (visibile) + implementazione (nascosta)

Lo stato di un oggetto è accessibile solo mediantel’interfaccia del suo ADT


Information hiding è il principio teorico

Incapsulamentoè la tecnica utilizzata

Data

Code



Tipo di dato astratto Per definire un ADT, occorre definire

un’interfaccia (interface): un insieme di operazioni pubbliche

applicabili ai singoli oggetti di quel tipo


, una classe (class) che implementa l’interfaccia dell’ADT:

un insieme di attributi privati(implementazione della struttura dati specifica)

un insieme di metodi pubblici (implementazionedell’interfaccia) e di metodi privatiche 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 dell’ADT) daeventuali 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 …



1

2

3

ADT Lista di interi Interfaccia:

Add(int item)

Insert(int index, int item)

Remove(int item)

RemoveAt(int index)


…

Implementazione: Array

Linked list

…

1 2 3

1 2

3



Data

de

lista1

Data

lista1

AbstractCode

IList Cliente

ADT Lista di interi


Data

Code

lista2

Data

lista2

Static Data

Code

ArrayList



Abstract

Code

IList

ADT Lista di interi

Cliente


Static Data

Code

LinkedList

Data

l i s t a

2

Data

l i s t a

3

Data

l i s t a

4

Static Data

Code

ArrayList

Data

l i s t a

1



Oggetti & classi Ogni oggetto:

è identificabile in modo univoco(ha una sua identità)

ha un insieme di attributi

ha uno stato


ha un insieme di operazioni

che operano sul suo stato

che forniscono servizi ad altri oggetti

ha un comportamento

interagisce con altri oggetti



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 l’implementazione di un


Run time , ogni oggetto è un’istanza 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



Notazione UML Una classe si rappresenta come un rettangolo

diviso in 1 o 3 sezioni

«attore»Esaminando

Nome della classe

Stereotipo


matricolacognomenome…

GetMatricola()GetCognomeNome()

EffettuaEsame()…

Attributi

Operazioni



Notazione UML


matricolacognome

La prima sezione contiene il nome della classe

(in grassetto + in corsivo se astratta)può contenere

lo stereotipo della classe(ad esempio, controllore, attore, evento,tabella, ecc.)


…

GetMatricola()GetCognomeNome()EffettuaEsame()…

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»IStudente

GetMatricola ()GetCognomeNome ()…

«interface»IEsaminando

EffettuaEsame ()…



matricolacognomenome…




Notazione UML


matricolacognome

IStudente


…


IEsaminando



Notazione UML

ArrayList


lista1

«instanceOf»

: rra y s



Le classi possono essere organizzate in una gerarchia digeneralizzazione o di ereditarietà

che mostra la relazione tra classi di oggetti generiche eclassi di oggetti più specifiche

Gli oggetti della sottoclasse devono essere in grado diesibire tutti i comportamenti e le proprietà esibiti dagli

…alla programmazione orientata agli oggetti


oggett appartenent a a superc asse, n mo o ta e apoter 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 osservabiledall'esterno



Ereditarietà Attributi e operazioni comuni

devono essere specificati una volta sola

Attributi e operazioni specificivengono aggiunti e/o ridefiniti

…alla programmazione orientata agli oggetti


e vo Semplificare la definizione e la realizzazione

di tipi di dato simili

Permette di esprimere esplicitamente le caratteristiche comuni,

sino dalle prime attività dell’analisi



Ereditarietà (inheritance) Model inheritance

Subtype inheritance Extension inheritance Restriction inheritance View inheritance

Software inheritance Reification inheritance

reflecting "is-a" relations betweenabstractions in the model

reflecting "is-a" relations betweenabstractions in the model

expressing relations within the software

expressing relations within the software


Structure inheritance Implementation inheritance Facility inheritance

Constant inheritance Machine inheritance

Variation inheritance Functional variation inheritance Type variation inheritance Uneffecting inheritance

a special case that may pertain eitherto the software or to the model

a special case that may pertain eitherto the software or to the model

itself rather than in the model

itself rather than in the model



Ereditarietà di interfaccia o subtyping

(ed ereditarietà di estensione) meccanismo di compatibilità fra tipi:

una sottoclasse è un sottotipo compatibile con tutti i tipidefiniti lungo la sua catena ereditaria (relazione IsA)

Ereditarietà


Ereditarietà di realizzazione (o di implementazione) osubclassing meccanismo di riuso:

si riutilizza il codice definito nelle superclassi

ammessa in C++, non ammessa in Java e .NET



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

un’altra classe

Ad esempio, la classe Finestra ha bisogno diutilizzare la classe Rettangolo per memorizzare posizione e dimensione fare calcoli di sovrapposizione con altre finestre


...

Potrei definire Finestra come sottoclasse diRettangolo (ma una Finestra NON è un Rettangolo)

Finestra eredita e quindi ha accesso diretto a dati eoperazioni (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

La definizione è statica (compile-time ) L’implementazione della sottoclasse è facile

da modificare, può definire i propri metodi e

Rettangolo

Finestra


La superclasse definisce parte dellarappresentazione fisica della sottoclasse,legando a sé la sottoclasse, rompendo

l’incapsulamento (Finestra vede i membriprotected di Rettangolo) e rendendo piùdifficile il riuso della sottoclasse



Composizione e delega Esiste un’alternativa più interessante:

inserire un Rettangolo nella struttura dati di

una Finestra: una Finestra contiene unRettangolo(una Finestra è composta, tra le altre cose,da un Rettan olo

Rettangolo

Finestra


Una Finestra ha accesso indiretto alleoperazioni pubbliche di un Rettangolo(una Finestra delega al Rettangolol’esecuzione di alcuni compiti)

Le interfacce delle classi restanoindipendenti



Composizione e delega L’associazione tra Finestra e

Rettangolo può avveniredinamicamente (run-time )

Maggiore flessibilità ed

Figura

Finestra


Quindi

se e solo se vale la relazione IsA,

usare l’ereditarietà

altrimenti, usare la composizione

Retta ngolo Cerc hio



Capacità

della stessa cosa di apparire in forme diverse incontesti diversi

di cose diverse di apparire sotto la stessa forma inun determinato contesto

Polimorfismo




Polimorfismo

Classificazione Cardelli-Wegner

Universale

Per inclusione Programmazioneobject-oriented

Programmazioneobject-oriented

Parametrico Programmazione

Programmazione


Polimorfismo

Ad hoc

Overloading5 + 10

5.2 + 11.7

5 + 105.2 + 11.7

Coercion 5 + 11.7

5 + 11.7



Overriding (ridefinizione) dei metodi

Definizione di un metodo astratto (sicuro)

Ridefinizione di un metodo concreto (meno sicuro)

Binding dinamico (o late-binding)

Polimorfismo (per inclusione)




Ereditarietà sempliceogni 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à


re tar et mu t p aalmeno 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



Ereditarietà multipla Tra due o più classi di una gerarchia possono esistere dei vincoli

{overlapping} o {disjoin}

Veicolo

{disjoint}{overlapping}


VeicoloMilitare

Taxi Corazzata

Un reticolo di veicoli

VeicoloCivile VeicoloTerrestre VeicoloAcquatico

CarroArmato BarcaAVela



Ereditarietà multipla

Veicolo OggettoMilitare

OggettoCivile

VeicoloTerrestre VeicoloAcquatico


Taxi Corazzata

Una gerarchia multipla di veicoli, senza antenati ripetuti

CarroArmato BarcaAVela



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)


semp Docente

Docenti (contiene una collezione di docenti)

CorsoDiStudio

CorsiDiStudio AttivitaFormativa

AttivitàFormativa – accettato in C#

Ingegneria tutte

Documents

Transcript of Ingegneria tutte