Concetti di Object Orientation Docente: Gabriele Lombardi lombardi@dsi.unimi.it © 2010 - 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. © 2010 - CEFRIEL

Sommario Paradigmi di programmazione Modelli concettuali SLIDE CONTENUTO Paradigmi di programmazione Precedenti all’OOP e loro limiti, OOP, successivi. Modelli concettuali Domain Driven Design, Separation of Concerns. Modellare la realtà Oggetti e classi, incapsulamento, UML. Riutilizzo del codice Relazioni tra oggetti, pattern GRASP. Modularizzazione Una gerarchia di astrazioni differenti. Metaprogrammazione Quando, come, perché. Esempi Analizziamo un caso reale. © 2010 - 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 l’applicazione di regole; Mathematica Logical programming: strutturato, dichiarativo, orientato alla manipolazione di sequenti logici con cui effettuare dimostrazione automatica di teoremi (logici di primo e second’ordine); 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! © 2010 - CEFRIEL

Paradigmi di programmazione Spaghetti programming: Procedurale: Object Oriented Programming: © 2010 - 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). © 2010 - CEFRIEL

Identificare ciò che appartiene al dominio: 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 l’utente. © 2010 - CEFRIEL

per lo più gli esperti di dominio: noi … 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!!! © 2010 - 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 d’obbligo; processo fortemente iterativo; l’ottimo 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 nell’uomo: possiamo comprendere al massimo 5-8 concetti assieme; gerarchie di astrazioni a granularità differente: es.: composizione di valori e/o entità = aggregati. © 2010 - CEFRIEL

Modellare la realtà Basi teoriche dell’OOP: 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. © 2010 - CEFRIEL

Descrizione di una classe di oggetti: 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 © 2010 - CEFRIEL

Modellare la realtà: l’UML Diagramma delle classi: rappresenta la struttura statica del modello: cosa contiene.. con quali relazioni. Colorazione??? © 2010 - CEFRIEL

Modellare la realtà: l’UML Diagramma di sequenza: rappresenta l’evoluzione di un caso d’uso: chi chiama cosa e quando. © 2010 - CEFRIEL

Modellare la realtà: l’UML Diagramma dei casi d’uso: 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 è l’evoluzione dei thread/processi nel sistema? © 2010 - CEFRIEL

Riutilizzo del codice Metodi: Classi coese: Associazioni: 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. © 2010 - CEFRIEL

minimizzare il numero di dipendenze; 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à” dall’implementazione; NON esagerare con l’astrazione: si finisce per non raggiungere l’obiettivo. © 2010 - 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 dell’ambito di interesse (dominio). © 2010 - CEFRIEL

Modularizzazione Sistema (distribuito?): Applicazione/Modulo: 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 d’uso (?). 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. © 2010 - CEFRIEL

Meta-programmazione Scopo: Strumenti: Esempi: 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?). © 2010 - CEFRIEL

Considerare in particolar modo: 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; l’interazione col sistema da parte degli operatori: creazione e battezzo treni; tracking materiale rotabile; imprevisti (motrici rotte, ritardi, incidenti); storico dell’accaduto e logging. BUON LAOVORO (a me compreso!) per una soluzione parziale (da completare per esercizio) si veda Code\00_OOConcepts\Ferrovie. © 2010 - CEFRIEL

Da qui? Il Domain Driven Design (DDD): “Domain Driven Design”, Evans è 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); “Design Patterns, Elements of Reusable Object-Oriented Software”, Gamma, Helm, Johnson, Vissides © 2010 - 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 © 2010 - CEFRIEL

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