Concetti di Object Orientation Docente: Gabriele Lombardi



Scaricare 445 b.
24.01.2018
Dimensione del file445 b.


Concetti di Object Orientation

  • Docente: Gabriele Lombardi

  • lombardi@dsi.unimi.it






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:

  • 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


Paradigmi di programmazione

  • Spaghetti programming:

  • Procedurale:

  • Object Oriented Programming:



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


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;
  • … ma non troppo!

    • un dominio non va rappresentato per quello che è …
    • … ma per quello che rappresenta per l’utente.


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



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.


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.


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:



Modellare la realtà: l’UML

  • Diagramma delle classi:

    • rappresenta la struttura statica del modello:
      • cosa contiene.. con quali relazioni.


Modellare la realtà: l’UML

  • Diagramma di sequenza:

    • rappresenta l’evoluzione di un caso d’uso:
      • chi chiama cosa e quando.


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?


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.


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.


Modularizzazione

  • Pattern GoF:

    • Creational:
    • 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).


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


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?).


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.


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


Addendum di OOP

  • Esempio: invio di una mail.

    • programmazione procedurale:
    • 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.


Esempio precedente in esecuzione






©astratto.info 2017
invia messaggio

    Pagina principale