Principi di programmazione OO

Transcript

1 Principi di programmazione OO Ing. Paolo Vaccari Giovedì 9 e 16 Marzo 2006 Corsi Speciali L.143/04 - SSIS TOSCANA 2005/2006

2 Principi di programmazione OO Prima lezione: Programmazione OO e procedurale Introduzione all OOP UML Seconda lezione: Linguaggi Oggetti e C++ Esempi

3 Prima lezione Programmazione procedurale e OO Differenze Problemi e soluzioni Orientamento agli oggetti UML Introduzione all OOP A cosa serve l UML Tipi di diagrammi

4 Procedurale e OO Quando si scrive un programma si crea dentro il calcolatore un modello di una porzione del mondo reale. I linguaggi di programmazione procedurali consentono di costruire modelli che privilegiano l aspetto procedurale, cioè le operazioni (funzioni) I linguaggi di programmazione OO consentono di costruire modelli che privilegiano le entità (i valori)

5 Procedurale e OO I linguaggi di programmazione tradizionali (C, Fortran, Basic, Pascal) sono procedurali Un programma/sottoprogramma viene visto come la trasformazione degli argomenti di ingresso X in un risultato Y, secondo la procedura P X P Y

6 Procedurale e OO La programmazione procedurale è ottima per produrre codice di dimensioni modeste, ma non ideale per progetti complessi e per le moderne esigenze industriali Il codice procedurale è: difficile da riutilizzare difficile da sviluppare in team di più persone non riflette in maniera naturale il nostro modo di pensare

7 Procedurale e OO Vantaggi della programmazione OO: favorisce la suddivisione del codice in unità funzionalmente indipendenti possono essere sviluppate autonomamente e contemporaneamente da più programmatori l uso degli oggetti ci riporta all esperienza quotidiana e risulta quindi più intuitivo ci porta a scrivere codice meno complicato, più facile da capire, correggere, aggiornare e riutilizzare impedisce alcuni errori e problemi nell accesso e manipolazione dei dati che i linguaggi procedurali non riescono ad evitare.

8 Orientamento agli oggetti Un oggetto è una entità composta da: proprietà che caratterizzano l oggetto e ne definiscono lo stato funzioni che possono essere eseguite sull oggetto e che possono modificare lo stato dell oggetto Lampadina accesa = falso vero accendi() spegni() Tipo oggetto Proprietà dell oggetto Funzioni che possono essere eseguite sull oggetto

9 Orientamento agli oggetti Tutti gli oggetti di uno stesso tipo formano una classe di oggetti (oggetto = istanza di una classe) Una classe è caratterizzata da: Proprietà a cui è associato un tipo che rappresenta l insieme dei possibili valori che oggetti appartenenti alla classe possono avere per la proprietà (bool, integer, real, string, etc.) Funzioni che possono essere eseguite sugli oggetti appartenenti alla classe

10 Orientamento agli oggetti Gli oggetti descritti tramite proprietà e funzioni sono una astrazione degli oggetti reali dei quali si considerano solo le caratteristiche necessarie per l applicazione da sviluppare Esempio: in una applicazione bancaria l altezza di una persona non è una informazione rilevante mentre lo è in una applicazione medica. Viceversa per il codice fiscale...

11 Orientamento agli oggetti Principi: Identità dell oggetto: ogni oggetto ha una propria identità univoca in tutto il sistema Occultamento dei dati (data hiding): i dati interni all oggetto sono nascosti all esterno Uso vietato Dati Funzioni private Uso consentito Funzioni pubbliche

12 Orientamento agli oggetti Principi: Ereditarietà: gli oggetti possono ereditare da altri oggetti comportamenti e proprietà aggiungendone dei propri Polimorfismo: funzioni con lo stesso nome possono avere una semantica diversa secondo il contesto in cui vengono chiamate

13 UML UML: Unified Modelling Language E la principale notazione standardizzata a livello internazionale Analogia con le norme standardizzate di disegno in altri campi dell ingegneria (norme UNI) Notazione, non metodologia Standardizzazione del modo di raffigurare i concetti permette di scambiare documenti di specifica, progetto e implementazione, non ambigui e comprensibili da tutti

14 UML Problema committente/fornitore: buona parte dei problemi nella costruzione e nel funzionamento di un prodotto software sono imputabili a incomprensioni tra il cliente/committente e il fornitore Il primo ha confusamente in mente di cosa ha bisogno, il secondo vuole proporre soluzioni di più basso costo di produzione possibile. Se il linguaggio comune continua a essere il linguaggio naturale, un eventuale accordo sarà comunque viziato dalla soggettività dei due stakeholders Necessità di un linguaggio comune il più possibile formalizzato, non ambiguo e comprensibile anche a un non tecnico

15 Le classi Una classe è una descrizione di un insieme di oggetti che condividono gli stessi attributi, operazioni, relazioni e semantica. Graficamente è rappresentata per mezzo di un rettangolo suddiviso in tre sezioni: nome, attributi, operazioni. Lampadina accesa = falso vero colore = azzurro accendi() spegni() Nome Attributi Operazioni (metodi)

16 Le classi: visibilità Tipologie di visibilità: Pubblica (+): l attributo/metodo è accessibile da qualsiasi altro oggetto che possiede un riferimento all oggetto che lo contiene; Privata (-): l attributo/metodo è accessibile solo all interno della rispettiva classe; Protetta (#): l attributo/metodo è accessibile da tutte le classi che ereditano da quella che lo contiene.

17 Le classi: visibilità Esempi: Attributi accessibili solo dai metodi della classe Data Metodi accessibili da chi usa la classe Data -giorno:int -mese:int -anno:int Data +set(g:int, m:int, a:int):bool +add(ngiorni:int) Attributo accessibile dalle classi derivate da Risorsa Risorsa #nome:string +set(n:string)

18 Le classi: relazioni Le classi possono essere collegate tra loro da relazioni: un pilota comanda un aeroplano la luce verde è parte di un semaforo Queste relazioni, come le classi, possono essere identificate a partire dalla descrizione informale del problema Tre tipi fondamentali di relazioni: dipendenza, generalizzazione e associazione

19 Le classi: relazioni La relazione di dipendenza è soprattutto legata ad aspetti implementativi Esprime il fatto che una classe dipende in qualche modo da un'altra classe Ad esempio: si usa quando una classe in un suo metodo usa un altra classe per svolgere un compito Le associazioni e le relazioni di specializzazione sono implicitamente anche relazioni di dipendenza Dipendente CodiceFiscale La classe Dipendente dipende dalla classe CodiceFiscale

20 Le classi: relazioni L associazione può essere contraddistinta da ruoli e molteplicità Ordini Clienti clientedal getordini 1 emette 0..* emesso da dataordine stato calcolatasse calcolatotale setstato 1 Articoli codice descrizione peso prezzo 1 nell ordine riguarda articolo 0..* 1..* DettagliOrdine quantità calcolapeso calcolaprezzo

21 Le classi: relazioni Aggregazione: tipo particolare di associazione è un'associazione più forte esprime concetto è parte di ( part of ), che si ha quando un insieme è relazionato con le sue parti Composizione: altro tipo di associazione è un'aggregazione più forte appartenenza molto forte A volte la differenza non è facile da individuare...

22 Le classi: relazioni Generalizzazione/Specializzazione padre-figlio: ereditarietà relazione è un ( is a )

23 Le classi: relazioni Altro esempio di ereditarietà:

24 Le classi: classi astratte Classi astratte: rappresentano un concetto o una categoria senza un corrispettivo reale (non possono essere istanziate) FiguraGeometrica rappresenta un concetto astratto che non può essere istanziato se non tramite una classe derivata (e.g.: Poligono) In UML le classi astratte si identificano con <<abstract>> FiguraGeometrica <<abstract>> #nome:string +setnome(n:string)

25 Le classi: interfacce Una interfaccia rappresenta un insieme di funzionalità che una classe offre a chi la usa Più classi possono implementare una stessa interfaccia Una interfaccia è una classe senza proprietà e solo con operazioni: <<interface>> GestioneRisorse aggiungirisorsa(r:risorsa) eliminarisorsa(r:risorsa)

26 Le classi: interfacce Una classe può implementare una interfaccia La classe Progetto realizza l interfaccia GestioneRisorse, quindi dovrà implementare le funzioni aggiungirisorsa e eliminarisorsa Progetto <<interface>> GestioneRisorse aggiungirisorsa(r:risorsa) eliminarisorsa(r:risorsa)

27 Le classi: interfacce Una classe può usare una interfaccia La classe GestioneRisorseUI che realizza l interfaccia utente per inserire e cancellare risorse usa un oggetto che implementa l interfaccia GestioneRisorse. Il concetto di uso è piuttosto generico GestioneRisorseUI <<use>> <<interface>> GestioneRisorse aggiungirisorsa(r:risorsa) eliminarisorsa(r:risorsa)

28 Le classi: interfacce Più in dettaglio una classe può essere associata con una interfaccia La classe GestioneRisorseUI è associata con un oggetto che implementa l interfaccia GestioneRisorse. GestioneRisorseUI gestisce 1 <<interface>> GestioneRisorse aggiungirisorsa(r:risorsa) eliminarisorsa(r:risorsa)

29 Le classi: interfacce Un oggetto GestioneRisorseUI è associato con un qualsiasi oggetto che implementa l interfaccia GestioneRisorse GestioneRisorseUI Notazione per l'implementazione delle interfacce GestioneRisorseUI gestisce gestisce GestioneRisorse Progetto GestioneRisorse RisorseDisponibili

30 Le classi: esempio Un diagramma delle classi concettuale

31 Diagrammi UML Requisiti funzionali Diagrammi di casi d uso: i requisiti sono rappresentati come attività Modello di dominio Diagramma delle classi: mostra la struttura del dominio tramite classi Modello orientato agli oggetti del sistema Diagramma delle classi: mostra la struttura del sistema Collaborazione degli oggetti Diagramma di sequenza Diagramma di collaborazione: mostrano la collaborazione dinamica tra gli oggetti per realizzare un caso d uso Stato dell oggetto Diagramma degli stati: mostra gli stati attraverso cui passa un oggetto

32 I Casi d Uso Per descrivere i requisiti funzionali del sistema si considerano degli esempi di uso del sistema Un caso d uso è una unità isolata e consistente che rappresenta una parte della funzionalità del sistema; dovrebbe costituire una unità logica di applicazione al sistema Il diagramma dei casi d uso raccoglie questi casi d uso e mostra chi usa il caso d uso (attore) le relazioni tra i casi d uso E un diagramma di alto livello che dà un visione molto approssimata del sistema I requisiti sono espressi nella descrizione dei casi d uso più che nel diagramma dei casi d uso.

33 Diagramma dei Casi d Uso Elementi di base: Comprare biglietto Caso d uso identificato da un titolo che lo descrive Acquirente Eseguire prenotazione Attore, chi usa il caso d uso. Può essere una persona fisica ma anche un sistema esterno Linea di comunicazione tra attore e caso d uso indica che l attore usa il caso d uso

34 Diagramma dei Casi d Uso Relazioni tra attori: Iscrizione Studente Richiesta certificato iscrizione Generalizzazione: lo Studente Lavoratore e uno Studente, i casi d uso che si applicano ad uno Studente valgono anche per uno Studente Lavoratore, ma non viceversa Studente Lavoratore Richiesta esenzione

35 Diagramma dei Casi d Uso Relazioni tra casi d uso: include Si usa per evidenziare delle funzionalità di base (ma non troppo ) Inclusione, il caso d uso Iscrizione esame prevede al suo interno l esecuzione del caso d uso Inserimento matricola Studente Iscrizione esame <<include>> Inserimento <<include>> matricola Richiesta certificato iscrizione Anche il caso d uso Richiesta certificato iscrizione prevede al suo interno l esecuzione del caso d uso Inserimento matricola

36 Diagramma dei Casi d Uso Relazioni tra casi d uso: extend Condition: { se l utente vuole la ricevuta } Extension point: ricevuta extension point: ricevuta <<extend>> Stampa ricevuta Prelevare al bancomat Cliente Estensione, il caso d uso Prelevare al bancomat e esteso in alcuni punti indicati da ricevuta dal caso d uso Stampa ricevuta L estensione può essere condizionata.

37 Diagramma dei Casi d Uso Relazioni tra casi d uso: generalizzazione Verifica con impronta digitale extension point: ricevuta <<include>> Verifica identità Verifica con password Prelevare al bancomat Cliente <<extend>> Stampa ricevuta Generalizzazione, il caso d uso Verifica con password e una specializzazione del caso d uso Verifica identità

38 Diagramma dei Casi d Uso Raggruppamento casi d uso in sistemi: Prelevare al bancomat Cliente Amministratore Sportello Bancomat Ricarica telefonino al bancomat Rifornimento contante Sportello bancomat Servizio bancario Sistema da specificare

39 Diagrammi dei Casi d Uso Considerazioni: Il diagramma dei casi d uso ha solo una funzione riassuntiva sui casi d uso del sistema e non e fondamentale (il diagramma non i casi d uso) Se sono presenti centinaia di casi d uso il diagramma diventa ingestibile e praticamente inutile, si possono dividere i casi d uso per sotto-sistemi

40 Descrizione Casi d Uso La descrizione di un caso d uso deve avere: Un identificativo univoco Un titolo che riporti la funzionalità del caso d uso Una breve descrizione, riassunto dei requisiti espressi dall utente Presupposti per l esecuzione del caso d uso La sequenza delle interazioni tra attore ed il sistema, contrassegnate da E per indicare l attore, e da A per indicare la risposta del sistema Gli effetti del caso d uso sul sistema (cambiamento di stato) Osservazioni che aiutino la comprensione del caso d uso e requisiti non funzionali (es. tempi risposta) La descrizione dei casi d uso non è standardizzata Comunque il caso d uso deve essere scritto in modo che sia comprensibile dal committente Non è necessario entrare troppo nel dettaglio

41 Descrizione Casi d Uso Numero: 1 Titolo: Prelievo bancomat Breve descrizione: il cliente effettua un prelievo al bancomat Presupposti: nessuno Descrizione procedimento: E1) il cliente inserisce la carta bancomat A1) il sistema valida la carta inserita Esecuzione caso d uso Verifica Identità A2) il sistema presenta la scelta dell importo da prelevare E2) il cliente seleziona l importo e preme esegui A3) il sistema richiede se il cliente vuole la stampa della ricevuta E3) l utente preme SI o NO A4) Il sistema emette la carta E4) il cliente ritira la carta A5) Il sistema eroga il denaro richiesto E5) il cliente ritira il denaro A6) se l utente ha premuto SI - Extension point: ricevuta Effetti: Il credito residuo per il periodo viene diminuito dell importo inserito, l importo viene addebitato sul conto Osservazioni: Il sistema deve validare l identità entro 1 minuto

42 Modello di Dominio Il modello di dominio mostra gli oggetti più importanti del dominio applicativo e le loro relazioni Si usa il diagramma delle classi Classi Associazioni Generalizzazione/specializzazione Si può creare prima dei casi d uso per capire quali sono gli oggetti che i casi d uso devono gestire

43 Modello di Dominio Classi Persona nome : string codicefiscale : string datanascita : date Classe con attributi Persona Classe con attributi e metodi nascosti o non specificati Persona nome : string codicefiscale : string datanascita : date verificacodicefiscale( ) Classe con attributi e metodi Specializzazione/generalizzazione Persona Dipendente Il Dipendente è una Persona ed eredita da questa tutte le sue caratteristiche

44 Modello di Dominio Associazioni Ogni Dipendente ha una propria Scrivania: Dipendente 1 Lavora-a > 1 Scrivania Ogni Dipendente lavora in un Gruppo di Lavoro che e formato da almeno un Dipendente: Dipendente 1..* Lavora-in 1 Gruppo lavoro Un Attore lavora a più Film con Ruolo diverso e ad un Film lavorano più Attori con ruoli diversi: Attore * * Film Ruolo

45 Modello di Dominio Associazione di composizione Progetto 1 * Gruppo lavoro Indica che un oggetto (indicato dal rombo pieno) è composto da altri oggetti Se l oggetto composto cessa di esistere cessano di esistere anche tutti i suoi componenti Il progetto è una composizione di gruppi di lavoro, se il progetto viene eliminato tutti i gruppi di lavoro che vi lavoravano vengono eliminati

46 Modello di Dominio Associazione di aggregazione Gruppo lavoro 1 * Dipendenti Indica che un oggetto (indicato dal rombo vuoto) è una aggregazione di altri oggetti Se l oggetto aggregato cessa di esistere non cessano di esistere anche i suoi componenti Il gruppo di lavoro è una aggregazione di dipendenti, se il gruppo di lavoro viene eliminato i dipendenti continuano a esistere se non vengono licenziati.

47 Diagramma degli stati Il diagramma degli stati evidenzia gli stati attraverso cui un oggetto passa in base alle interazioni con l esterno Esempio: cancelletto girevole Transizione di Stato (dipende dalla moneta!) quando l utente passa (evento Pass) esegue il Lock e passa nello stato Locked

48 Diagramma degli stati Un po più complicato

49 Diagramma di Collaborazione Il diagramma delle classi e dei casi d uso sono diagrammi statici Il diagramma di collaborazione è un diagramma dinamico che fa vedere come gli oggetti collaborano tra loro Si usa per far vedere come viene realizzato un caso d uso (o una sua parte)

50 Diagramma di Collaborazione Elementi: 1. L oggetto a esegue il metodo metodo1 sull oggetto b a : Oggetto 1: metodo1( ) b : Oggetto 2. L oggetto b esegue il metodo metodo2 sull oggetto d un certo numero di volte (*) 2: metodo1( ) 1.1 *: metodo2( ) c : Oggetto 2.1*: metodo2( ) d : Oggetto 3. L oggetto a esegue il metodo metodo1 sull oggetto c 4. L oggetto c esegue il metodo metodo2 sull oggetto d un certo numero di volte (*)

51 Diagramma di Sequenza E un diagramma dinamico che mostra lo svolgimento temporale delle interazioni tra oggetti a:oggetto b:oggetto scegli() calcola() L oggetto a esegue il metodo calcola sull oggetto b Tempo metodo() Viene restituito il valore calcolato (può essere omessa la freccia) L oggetto a esegue il metodo metodo sull oggetto a stesso

52 Diagramma di Sequenza In un metodo si possono creare e/o distruggere degli oggetti a:oggetto L oggetto a crea un nuovo oggetto b nell esecuzione del metodo scegli Tempo scegli() nuovo() b:oggetto calcola() distruggi() Viene distrutto l oggetto b

53 Diagramma interazione sottosistemi Indica come interagiscono i sottosistemi Il sottosistema Amministrazione usa l interfaccia pubblicata dal sottosistema Cassa Amministrazione Dati Cassa Il sottosistema Amministrazione fornisce l interfaccia Dati che viene usata dal sottosistema Chiosco Chiosco

54 Diagramma Componenti Indica come interagiscono i componenti Amministrazione Il componente Amministrazione usa i servizi dei componenti DB Amministrazione e Comunicazioni Amministrazione DB Amministrazione Chiosco Comunicazioni Amministrazione Comunicazioni Chiosco

55 Diagramma delle classi Nella fase di progetto al modello di dominio si aggiungono altri dettagli: Visibilità degli attributi e metodi Navigabilità delle associazioni Metodi delle classi Inoltre: si operano trasformazioni al modello nel caso il linguaggio di programmazione adottato non supporti delle caratteristiche usate nella modellazione del dominio (es.: Java e C# non supportano ereditarietà multipla) si aggiungono classi di supporto per esempio per realizzare associazioni Si usano i diagrammi di collaborazione e sequenza per mostrare le interazioni tra gli oggetti tramite i metodi

56 Diagramma delle classi Navigabilità delle associazioni Le associazioni possono avere una indicazione di navigabilità per indicare la direzione in cui si vuole percorrere l associazione Gruppo lavoro 1 * Dipendenti La direzione della freccia indica che da un Gruppo di lavoro si vuole sapere quali sono i dipendenti del gruppo

57 Diagramma delle classi I Package Per gestire la complessità del diagramma delle classi, le classi che sono tra loro in relazione possono essere riunite in un package e possono essere mostrate in un diagramma in modo compatto Risorse Risorsa Risorsa (from Risorse) Progetto Progetto

58 Riferimenti Documentazione: OMG ( La casa dell'uml (specifiche e tutorial) Software: ArgoUML ( open source (licenza BSD) Windows, Linux, Mac (con Java VM) Java (reverse engineering) BoUML ( open source (licenza GPL) Windows, Linux, Mac (con librerie QT) C++, Java (generazione e reverse ) Microsoft Visio