La presentazione è in caricamento. Aspetta per favore

La presentazione è in caricamento. Aspetta per favore

© 2010 - CEFRIEL Concetti di Object Orientation Docente: Gabriele Lombardi

Presentazioni simili


Presentazione sul tema: "© 2010 - CEFRIEL Concetti di Object Orientation Docente: Gabriele Lombardi"— Transcript della presentazione:

1 © CEFRIEL Concetti di Object Orientation Docente: Gabriele Lombardi

2 © CEFRIEL The present original document was produced by CEFRIEL and the Teacher for the benefit and internal use of this course, and nobody else may claim any right or paternity on it. No right to use the document for any purpose other than the Intended purpose and no right to distribute, disclose, release, furnish or disseminate it or a part of it in any way or form to anyone without the prior express written consent of CEFRIEL and the Teacher. © copyright Cefriel and the Teacher-Milan-Italy-23/06/2008. All rights reserved in accordance with rule of law and international agreements.

3 © CEFRIEL Sommario SLIDECONTENUTO Paradigmi di programmazione Precedenti allOOP e loro limiti, OOP, successivi. Modellare la realtà Oggetti e classi, incapsulamento, UML. Modelli concettuali Domain Driven Design, Separation of Concerns. Riutilizzo del codice Relazioni tra oggetti, pattern GRASP. Modularizzazione Una gerarchia di astrazioni differenti. Esempi Analizziamo un caso reale. Metaprogrammazione Quando, come, perché.

4 © CEFRIEL Paradigmi di programmazione Spaghetti programming: –destrutturato, imperativo, (quasi) mai buono; assembly, basic Procedurale: –strutturato, imperativo, basato sul come e non sul cosa, funzione come unità minima; C, Pascal Funzionale: –strutturato, dichiarativo (circa), basato sul cosa e non sul come (circa), orientato alla formalizzazione matematica (mantenendo legami con il procedurale); lisp, scheme Symbolic programming: –strutturato, dichiarativo, orientato alla sostituzione di simboli tramite lapplicazione di regole; Mathematica Logical programming: –strutturato, dichiarativo, orientato alla manipolazione di sequenti logici con cui effettuare dimostrazione automatica di teoremi (logici di primo e secondordine); Prolog, Golog Stream programming: –strutturato, procedurale (spesso visuale), orientato alla definizione di stream di elaborazione; HP VEE, LabView Object Oriented Programming: –strutturato, misto dichiarativo/procedurale, oggetti e classi come concetti chiave; Java, C++ Object Based Programming: –strutturato, procedurale, tutto è un oggetto, istanziazione tramite clonazione (prototyping); Python, SmallTalk …e molti altri!

5 © CEFRIEL Paradigmi di programmazione Spaghetti programming: Procedurale: Object Oriented Programming:

6 © CEFRIEL Paradigmi di programmazione OOP vs DDD: –Object Oriented Programming: paradigma di programmazione – definisce gli strumenti sintattico/semantici con cui descrivere formalmente la soluzione al problema posto (programma). NON si tratta di una metodologia – NON definisce come affrontare il problema; – NON definisce come identificarne il modello concettuale. –Domain Driven Design: metodologia di identificazione del modello – definisce gli strumenti concettuali con cui identificare e descrivere il modello astratto per il problema nel suo dominio; NON si tratta di un paradigma – NON definisce gli strumenti di formalizzazione (linguaggio); – NON definisce quale paradigma utilizzare (indipendente da esso).

7 © CEFRIEL Modelli concettuali Identificare ciò che appartiene al dominio: –valori: immodificabili, senza identità, senza storia; es.: numeri, stringhe, equazioni (?), … –entità: modificabili, con identità, con storia; es.: utenti, carrelli, prenotazioni (?), … –servizi: non rappresentano qualcosa, ma offrono funzionalità coese, rispecchianti funzionalità del SW; es.: pagamenti, registrazione utenti, … … ma non troppo! –un dominio non va rappresentato per quello che è … –… ma per quello che rappresenta per lutente.

8 © CEFRIEL Modelli concettuali Definire il modello: –Chi lo conosce? per lo più gli esperti di dominio: –ma inconsapevolmente, vanno aiutati.. mentre ci aiutano. noi … –… a priori no, le conoscenze di base sono fuorvianti. –Chi sa(prebbe) rappresentarlo? noi (in teoria): –tramite strumenti teorici ed esperienza pratica. gli esperti di dominio … –… in genere no.. ma tentano comunque di suggerircelo. Parola chiave: collaborazione!!!

9 © CEFRIEL Modelli concettuali Problemi: –comprensione tra collaboratori diversi: definire un linguaggio comune (degli esperti): –definizione di un ubiquitous language. massimizzare la comunicazione (tra opposti): –ottimo tramite le dinamiche dominanti di Nash. –tempi sempre molto (troppo) stretti: Serve per ieri!; trade-off sempre dobbligo; –processo fortemente iterativo; –lottimo si ottiene per approssimazioni successive. falso problema: –tentare di ottenere prematuramente un prodotto finito porta ad un enorme dispendio di tempo ed energie per il suo mantenimento. –complessità ingovernabile: intrinseco nelluomo: –possiamo comprendere al massimo 5-8 concetti assieme; gerarchie di astrazioni a granularità differente: –es.: composizione di valori e/o entità = aggregati.

10 © CEFRIEL Modellare la realtà Basi teoriche dellOOP: –modellazione della realtà come: classificazione degli oggetti che ne fanno parte; identificazione delle istanze; descrizione della loro struttura; descrizione delle loro capacità. –interazione tramite: messaggi scambiati tra oggetti; concetto di richiesta/risposta (al posto del concetto di chiamata a funzione). –identificazione e specificazione di: relazioni tra le classi di oggetti; contratto di comunicazione (pre., inv. e post.). –separazione concettuale tra: interfacce come punti di accesso/comunicazione; implementazione delle operazioni.

11 © CEFRIEL Modellare la realtà Descrizione di una classe di oggetti: –nome della classe stessa nel linguaggio di dominio; –caratteristiche che identificano le istanze attributi; –capacità comunicative e attive metodi. Incapsulamento: –nascondere la struttura interna: mostrare il comportamento (cosa) e non il funzionamento (come). Polimorfismo: –la relazione è un nella gerarchia dei tipi; –principio di sostituibilità di Liskov. Nome Attributi Metodi

12 © CEFRIEL Modellare la realtà: lUML Diagramma delle classi: –rappresenta la struttura statica del modello: cosa contiene.. con quali relazioni. Colorazione???

13 © CEFRIEL Modellare la realtà: lUML Diagramma di sequenza: –rappresenta levoluzione di un caso duso: chi chiama cosa e quando.

14 © CEFRIEL Modellare la realtà: lUML Diagramma dei casi duso: –Quali attori interagiscono con il sistema, e come? –Quali casi di utilizzo e quali eccezioni interessano? Diagramma dei package: –Quali pacchetti esistono e con quali responsabilità? Diagramma di deploy: –Il sistema fisico da quali nodi/componenti è formato? –Quali sono le relazioni tra componenti SW e HW? Diagramma degli stati: –Quali sono le specifiche degli automi a stati finiti? Diagrammi di attività: –Quali sono le componenti concorrenti? –Qual è levoluzione dei thread/processi nel sistema?

15 © CEFRIEL Riutilizzo del codice Metodi: –utilizzandoli come procedure (mattoncini riutilizzabili); Classi coese: –offrono funzionalità generali e riutilizzabili; Associazioni: –permettono di utilizzare funzionalità esterne; Ereditarietà: –ottenimento a gratis ti funzionalità già esistenti; Astrazione: –tramite interfacce e polimorfismo; –permettono di astrarre maggiormente; Moduli, framework e meta-programmazione: –aventi lo scopo di semplificare lo sviluppo di sistemi complessi; Annotazioni: –programmazione dichiarativa immersa in un paradigma OO.

16 © CEFRIEL Riutilizzo del codice Pattern GRASP: –Low copuling (basso accoppiamento): minimizzare il numero di dipendenze; –High coesion (alta coesione): Massimizzare la specificità delle features. Regole auree: –identificare le sotto-problematiche separate; –costruire moduli per risolverle … … in maniera separata dal resto; –separare le capacità dallimplementazione; –NON esagerare con lastrazione: si finisce per non raggiungere lobiettivo.

17 © CEFRIEL Modularizzazione Pattern GoF: –Creational: singleton, factory method, abstract factory, builder, prototype; –Structural: adapter, composite, decorator, facade, … –Behavioral: chain of responsibility, command, iterator, observer, state, strategy, template method … Altri pattern: –Enterprise (e J2EE); –Parallel Programming; –Real-time e sfaty-systems programming; –… specifici dellambito di interesse (dominio).

18 © CEFRIEL Modularizzazione Sistema (distribuito?): –una o più applicazioni cooperanti. Applicazione/Modulo: –SW capace di svolgere azioni di interesse. Framework: –strumento generale di descrizione di un dominio; –permette di affrontare in maniera più semplice un problema. Pacchetti: –insieme di meccanismi cooperanti per la risoluzione di un sotto- problema o di un aspetto del problema affrontato. Meccanismi: –classi che interagiscono per affrontare un caso duso (?). Aggregati/Servizi: –descrivono valori/entità o funzionalità composte. Valori/entità: –descrivono qualcosa manipolato dal sistema SW. Attributi e metodi: –descrivono le caratteristiche del qualcosa a cui appartengono.

19 © CEFRIEL Meta-programmazione Scopo: –costruire nuovi strumenti di programmazione; –non (sempre) può modificare la sintassi; –deve semplificare sia lo sviluppo che la comprensibilità del SW prodotto. Strumenti: –macro e template (a compile-time); –Reflection (se disponibile); –Linguaggi autodescrittivi (con operatori e altro); –Astrazioni (per descrivere concetti e non sintassi). Esempi: –stream programming; –symbolic manipulation (esempio LINQ?).

20 © CEFRIEL Esempio pratico Progettiamo un sistema di gestione di una linea ferroviaria orari + annunci al pubblico. Considerare in particolar modo: –la gestione della persistenza su DB; –linterazione col sistema da parte degli operatori: creazione e battezzo treni; tracking materiale rotabile; imprevisti (motrici rotte, ritardi, incidenti); –storico dellaccaduto e logging. BUON LAOVORO (a me compreso!) –per una soluzione parziale (da completare per esercizio) si veda Code\00_OOConcepts\Ferrovie.

21 © CEFRIEL Da qui? Il Domain Driven Design (DDD): –è propedeutico per una buona comprensione; –fornisce basi solide per la progettazione; –suggerisce una metodologia iterativa di sviluppo; –da leggere: Domain Driven Design, Evans Design Pattern: –permettono di affrontare correttamente le problematiche classiche di progettazione; –ne esistono moltissimi specializzati (vedasi EE); –da leggere: Design Patterns, Elements of Reusable Object- Oriented Software, Gamma, Helm, Johnson, Vissides

22 © CEFRIEL Addendum di OOP Esempio: invio di una mail. –programmazione procedurale: –funzioni vengono richiamate per svolgere compiti coesi; –insiemi di funzioni formano moduli di libreria (stesso scopo). –OOP: –le classi fanno le veci degli insiemi di funzioni (moduli); –gli oggetti sono dati più le funzionalità di manipolazione; –gli oggetti rappresentano entità attive, non più passive. mittente ______ _____ ______ crea_connessione _____ chiudi_connessione _____ invia_dati _____

23 © CEFRIEL Esempio precedente in esecuzione spedisciMail Mittente new Conessione inviaDati chiudi tempo stack Record di attivazione Oggetti Messaggi


Scaricare ppt "© 2010 - CEFRIEL Concetti di Object Orientation Docente: Gabriele Lombardi"

Presentazioni simili


Annunci Google