Principi di Programmazione Object-Oriented Modello ad oggetti



Scaricare 445 b.
24.01.2018
Dimensione del file445 b.


Principi di Programmazione Object-Oriented


Modello ad oggetti

  • Concetto di oggetto riconducibile a diversi settori:

    • Software engineering
    • Linguaggi di programmazione
    • Basi di dati
    • Intelligenza Artificiale


Approcci alla produzione di programmi

  • Programmazione in the small

    • Progetto di algoritmi e strutture dati
  • Programmazione in the large

    • Software engineering


Metodi per la produzione di programmi

  • Metodi tradizionali:

    • programmazione strutturata orientata alle funzioni:
      • flusso di controllo
      • flusso di dati
  • Metodi attuali:

    • programmazione orientata agli oggetti:
      • classe
      • oggetti
      • servizi


Strumenti per la progettazione

  • Orientati alle funzioni:

    • Diagramma di flusso (in the small)
    • Analisi e progetto strutturato (in the large)
  • Orientati agli oggetti:

    • OOSE, OMT, ecc. (in the large)
      • Unified Modeling Language UML


Approcci e Metodi



Modello del software

  • Necessità di modellare un sistema:

    • creare una astrazione del sistema attraverso cui specificarne la struttura ed il comportamento.
  • Il modello di un software deve rappresentare le informazioni trasformate dal software, le funzioni e sottofunzioni che effettuano tali trasformazioni e il comportamento del sistema conseguente alle trasformazioni stesse



Processo software

  • Definisce la strategia adottata nella realizzazione del software.

    • Comprende metodi, tecniche e strumenti.
    • Si fonda sul concetto di qualità totale
    • E’ caratterizzato da:
      • Attività portanti
      • Un insieme di compiti: punti di controllo, prodotti intermedi (modelli, documenti), punti di garanzia dalla qualità.
      • Attività ausiliarie: garanzie dalla qualità, gestione delle configurazioni


Processo di sviluppo unificato

  • Fasi del ciclo di vita

    • Avviamento: consente di stabilire l’effettiva realizzabilità del progetto
    • Elaborazione: preparazione del piano del progetto
    • Costruzione: implementazione di un sistema funzionante per un ristretto numero di utenti tester
    • Transizione: consegna ai clienti del sistema completamente funzionante


Workflow del Processo Unificato

  • Requisiti: costruzione del modello dei casi d’uso che definisce i requisiti funzionali del sistema modellato

  • Analisi: raffinamento e strutturazione dei requisiti funzionali descritti nel modello dei casi d’uso mediante la costruzione del modello di analisi

  • Progetto: descrizione della realizzazione fisica dei casi d’uso costruzione di un modello di progetto ed un modello di deployment

  • Implementazione:definizione dei componenti software che realizzazione gli elementi del modello di progetto

  • Test: descrizione dei dati test e delle modalità secondo cui condurre i test del sistema nel modello di test



Modelli UML associati a ciascun workflow

    • dei casi d’uso
    • di analisi
    • di progetto
    • di implementazione
    • di test
    • di deployment
  • Lo sviluppo di ciascun modello è condotto in modo trasversale attraverso le 4 fasi del processo unificato



Iterazioni e raffinamenti

  • Occorre adottare un modello iterativo e incrementale nel processo di sviluppo

    • Iterazione:
      • un progetto che attraversa trasversalmente ciascuno dei workflow del processo unificato
    • Raffinamento:
      • è prodotto in ciascuna iterazione
      • versione del progetto con maggiori funzionalità rispetto alla versione precedente
  • Scopo dell’approccio:



Punti di vista sul sistema

  • I 6 modelli sono sviluppati in modo incrementale attraverso i 5 workflow e attraverso le 4 fasi del processo unificato

  • E’ possibile definire diversi punti di vista sul sistema sotto cui considerare i diversi modelli



Punti di vista su un sistema software



Modello guidato dai casi d’uso

  • UML considera un sistema secondo prospettive diverse in base agli utilizzatori

  • Fondamentale è la prospettiva dei casi d’uso che rappresentano la descrizione di un particolare aspetto del sistema

  • La modellazione in UML è guidata dai casi d’uso



Casi d’uso

  • Definiscono gli scenari d’uso del sistema

  • Offrono una descrizione dei modi in cui il sistema sarà utilizzato.

  • Scenario:

    • una sequenza di passi che descrivono l’interazione tra un utente ed il sistema
  • Per la descrizione dei casi d’uso occorre individuare:

    • attori
      • principali
      • secondari
    • ruoli
  • E’ un testo informale che descrive il ruolo di un attore nel corso dell’interazione con il sistema



Rappresentazione grafica in UML

  • Attore



Concetti object oriented

  • Oggetto: una entità del mondo reale

  • Classe:un insieme di oggetti aventi le stesse caratteristiche

  • Attributi: proprietà di classi ed oggetti che ne definiscono le caratteristiche

  • Metodi: definiscono il comportamento di un oggetto

  • Operazioni: definiscono il comportamento degli oggetti istanze di una classe



Principi object oriented

  • Ereditarietà:

    • ciascuna classe può essere definita in termini di una classe esistente. La nuova classe (sottoclasse) contiene automaticamente la definizione di elementi propri della classe originaria (superclasse)
  • Polimorfismo:

    • pluralità di forme, gli oggetti possono ridefinire le operazioni della classe di cui fanno parte
  • Information Hiding (incapsulamento):

    • ciascuna classe nasconde al proprio interno i dettagli implementativi


Esempio: ereditarietà

  • Classificazione delle specie animali



Oggetto

  • Identità: espressa da un nome

  • Stato: include le proprietà dette attributi che descrivono gli oggetti

  • Comportamento: rappresentato da funzioni dette metodi che utilizzano o cambiano il valore degli attributi



Classe

  • Un insieme di oggetti aventi le stesse caratteristiche. E’ caratterizzata da:

    • Identità: definisce il nome della classe
    • Attributi: la classe non ha stato, ma definisce proprietà locali che sono l’astrazione delle proprietà comuni agli oggetti istanze della classe
    • Operazioni: definiscono il comportamento della classe. Rappresentano i servizi che possono essere richiesti da un oggetto. I metodi sono implementazioni delle operazioni


Visibilità delle proprietà

  • Una classe è concettualmente divisa in due parti:

  • Una parte visibile che fornisce l’unico modo tramite il quale è possibile operare sugli oggetti della classe e descrive che cosa, in termini di operazioni ammissibili è possibile fare sugli oggetti

  • Una parte nascosta il cui contenuto non è visibile all’esterno della classe e che riguarda come le funzionalità visibili sono realizzate



Rappresentazione grafica in UML

  • Classe



Relazioni tra classi

  • Associazione: connessione strutturale tra classi

  • Aggregazione: relazione in cui una o più classi sono parti di una classe intera

  • Generalizzazione: (ereditarietà) relazione in cui una classe (sottoclasse) eredita gli attributi e le operazioni di una superclasse

    • multipla
    • semplice


Rappresentazione in UML delle relazioni tra classi



Relazioni tra i casi d’uso

    • Inclusione:
      • un caso d’uso include esplicitamente il comportamento di un altro in un punto specifico dell’azione.
      • Il meccanismo serve per eliminare comportamenti ripetuti all’interno di più casi d’uso
    • Estensione:
      • un caso d’uso include implicitamente il comportamento di un altro in uno o più punti detti di estensione
      • Il meccanismo è utilizzato per fattorizzare comportamenti opzionali o che si verificano in determinate circostanze
    • Generalizzazione:
      • analoga alla generalizzazione per le classi


Rappresentazione in UML delle relazioni tra casi d’uso



Diagrammi UML

  • Strutturali

    • Delle classi
    • Degli oggetti
  • Comportamentali

    • Casi d’uso (use case)
    • Attività (activity diagram)
    • Sequenza
    • Collaborazione
    • Transizione di stato (state/transition diagram)
  • Architetturali

    • Componenti


Workflow di Analisi

  • Scopo del workflow di analisi è delineare un modello di analisi

  • Il modello di analisi

    • si compone di una serie di diagrammi che descrivono il software nel suo contesto operativo rispetto ai requisiti.
    • rappresenta le informazioni, le funzionalità e il comportamento nel contesto degli elementi di un modello ad oggetti


Diagramma delle classi

  • Rappresenta la struttura del sistema che si sta sviluppando

  • Descrive il tipo degli oggetti che compongono il sistema e le relazioni statiche tra loro esistenti

  • Mostra gli attributi e le operazioni di una classe



Diagramma degli oggetti

  • Rappresenta una parte della struttura del sistema che si sta modellando

  • Rappresenta oggetti e valori specifici per gli attributi



Diagramma dei casi d’uso

  • Descrive le funzionalità fondamentali che il sistema deve realizzare in termini di scenari di utilizzo del sistema

  • Descrive gli scenari percepiti in modi diversi dai diversi attori

  • Contiene la rappresentazione degli attori e dei casi d’uso usando delle frecce per associare gli attori ai casi d’uso con cui interagiscono



Diagramma di casi d’uso



Package di analisi

  • Rappresenta il raggruppamento concettuale di elementi dell’analisi.

  • Comprende le classi di analisi e rappresenta le loro interazioni



Workflow di progetto

  • Nel workflow di progetto si delinea il modello di progetto.

  • Nel modello di progetto:

    • si indicano gli oggetti derivati da ciascuna classe e le loro interazioni
    • si implementano i comportamenti e le comunicazioni
    • si rappresenta dinamicamente il comportamento del sistema mediante la modellazione delle comunicazioni fra gli oggetti


Messaggio

  • Rappresenta la comunicazione tra due oggetti o all’interno di un oggetto

  • La comunicazione è rappresentata da due tipi di diagrammi:

    • di collaborazione
    • di sequenza
  • che rappresentano la stessa informazione con diversi dettagli



Diagramma di sequenza

  • Specifica come gli oggetti interagiscono evidenziando la sequenza temporale dei messaggi scambiati

  • Il diagramma ha due dimensioni

    • sull’asse orizzontale sono rappresentati gli oggetti che interagiscono
    • sull’asse verticale la sequenza temporale dei messaggi


Elementi del diagramma di sequenza

  • Gli oggetti sono rappresentati come box in cima ad una linea tratteggiata verticale

    • Lifeline: rappresenta la vita dell’oggetto
    • Box di attivazione: rappresenta il periodo durante il quale l’oggetto ha il controllo del flusso


Diagramma di sequenza



Diagramma di collaborazione

  • Illustra come gli oggetti interagiscono evidenziando le relazioni tra gli oggetti che collaborano

  • Le relazioni sono specificate anche nel diagramma delle classi; in questo diagramma assumono la forma di link istanza della associazione



Diagramma di collaborazione



Raffinamento della struttura del sistema

  • Il modello di progetto include oltre ai diagrammi di collaborazione e di sequenza che modellano gli aspetti dinamici del comportamento del sistema anche diagrammi che modellano gli aspetti strutturali

  • Raffinando la struttura del modello, il diagramma delle classi viene arricchito con ulteriori informazioni riguardanti le operazioni e gli attributi.

  • Le classi diventano più specifiche: classi di progetto



Classi di progetto

  • Dettagli di attributi e di operazioni

    • Visibilità
      • pubblica +
      • protetta #
      • privata -
    • Dettagli di attributi
      • molteplicità
      • modificabilità
      • frozen
    • Dettagli di operazioni
      • proprietà per l’esecuzione parallela e thread


Attività e azioni

  • Attività:

    • E’ un lavoro svolto da un oggetto in maniera continuativa
    • Può essere suddivisa in attività più semplici
  • Azione:

    • E’ un insieme di computazioni eseguibili in modo indivisibile (è atomica)
    • Si assume che sia istantanea


Diagramma delle attività

  • Rappresenta azioni sequenziali o parallele

  • E’ necessario rappresentare punti di sincronismo



Ciclo di vita di un oggetto

  • Evento:

    • Qualcosa che accade ed ha rilevanza per un oggetto
  • Stato:

    • Condizioni in cui un oggetto può trovarsi durante il suo ciclo di vita
  • Transizione:



Diagramma di stato

  • Rappresenta la macchina a stati di un oggetto. Indica:

    • Gli stati che un oggetto può assumere durante il suo ciclo di vita
    • Gli eventi a cui può rispondere
    • Le possibili risposte che può fornire a quegli eventi
    • Le transizioni tra gli stati dell’oggetto


Diagramma di stato



Package di progetto

  • Rappresenta il raggruppamento degli elementi di progetto. Comprende i diagrammi:

    • di sequenza
    • di collaborazione
    • di stato
    • delle attività
    • delle classi di progetto


Workflow di implementazione

  • Si sviluppa il modello di implementazione

    • Illustra come gli elementi del modello di progetto sono organizzati in componenti software sotto forma di file di codice sorgente, librerie collegate dinamicamente ecc.


Elementi del sistema

  • Package:

    • Raggruppamento concettuale di elementi del modello
  • Componente:

    • Raggruppamento di elementi fisici del sistema
    • Rappresenta un modulo di codice
  • Package e componenti possono coincidere ma anche essere differenti: una singola classe può essere presente in più componenti ma essere definita in un solo package



Diagramma di componenti

  • Illustra i componenti di un sistema e le relative dipendenze.

  • Dipendenze: mostrano come i cambiamenti apportati ad un componente si ripercuotono sugli altri. Esistono dipendenze:

    • di comunicazione
    • di compilazione


Diagramma di deployment

  • Mostra le relazioni fisiche tra i componenti software ed hardware del sistema finito.

  • Le unità computazionali sono rappresentate come nodi

  • Le associazioni tra nodi rappresentano le connessioni fisiche usate dai componenti del sistema per interagire



Diagramma di deployment



Fattori di qualità del SW

  • Qualità esterne

    • Riusabilità
    • Estendibilità


Riusabilità: vantaggi

  • Riduce la quantità di lavoro necessario

  • Evita di ripetere le fasi di sviluppo

  • Aumenta la qualità del software: il codice è già stato testato verificato e l’uso

  • Software più affidabile



Fattori di qualità influenzati dall’approccio OO



Esempio: diagramma delle classi

  • Classe



Esempio: diagramma dei casi d’uso



Esempio: diagramma delle classi






©astratto.info 2017
invia messaggio

    Pagina principale