corso oop & ood

Corso di Object Oriented Design &

Programming

Torino, 29 Giugno 2009ing. Roberto Basile

lunedì 29 giugno 2009

Paradigmi di programmazioneUn paradigma di programmazione è uno stile fondamentale di programmazione, ovvero un insieme di strumenti concettuali forniti da un linguaggio di programmazione per la stesura di programmi, e determina il modo in cui il programmatore concepisce e percepisce il programma.

Programmazione Procedurale (anni ’60)Si racchiudono in procedure e funzioni le parti di codice che hanno uno scopo e che vengono richiamate da un programma principale.

Programmazione Strutturata (primi anni ’70)Si introduce il concetto di controllore che migliora la leggibilità e manutenibilità del codice. Eliminato il concetto di GoTo ed il problema del cosiddetto spaghetti code.

Programmazione Modulare (anni ’70)Si definiscono dei moduli funzionalmente distinti e autonomi che interagiscono tra loro ma il cui sviluppo può essere realizzato in modo separato da più gruppi di programmatori.

Programmazione Orientata agli Oggetti (anni ’80)Definisce una unica entità (la classe) che contiene sia dati che metodi per agire su di essi.

Aspect programming (anni 2000) Basato sulla OOP cerca di risolvere il problema di modellare codice trasversale a tutti gli oggetti. Es. Logging e Security. Esistono degli “osservatori” che guardano le interazioni tra gli

Object Oriented Programming


Generalità

La programmazione orientata agli oggetti (OOP) è una tecnica nata dall’esigenza di affrontare problemi di crescente complessità cercando di massimizzare la robustezza del codice prodotto in relazione ai frequenti riadattamenti (Refactoring) che nell’esperienza ci si è accorti essere attività rilevante nel processo di sviluppo di una applicazione (Software Life Cycle).

Tale metodologia è focalizzata sul dato più che sul processo nel suo complesso; essa mira alla realizzazione di parti di codice autoconsistenti e riusabili detti appunto Oggetti che siano in grado di manipolare le strutture dati di cui hanno bisogno, nascondendo al “mondo esterno” i dettagli implementativi che ne garantiscono il funzionamento corretto.



Principi chiave

La OOP ha tre principi cardine:

Incapsulamento (Encapsulation)

E’ la realizzazione dell’Information Hiding ovvero del principio secondo il quale è bene nascondere all’interno dell’oggetto tutto ciò di cui l’oggetto fa uso per il suo funzionamento, esponendo le sole funzionalità indispensabili per comunicare con altri oggetti.

Ereditarietà (Inheritance)

E’ la capacità di poter creare strutture gerarchiche di oggetti nelle quali un oggetto figlio eredita alcune caratteristiche dall’oggetto padre (metodi e attributi).

Polimorfismo (Polymophism)

E’ la possibilità di ridefinire metodi ed attributi negli oggetti derivati (che ereditano) con comportamenti differenti da quelli dell’oggetto padre.



Parole chiave

Classe: è la definizione dell’archetipo della realtà che si descrive. Es. Droide

Oggetto: è uno specifico elemento reale ed utilizzabile della classe. Es. C-3PO

Istanza: sinonimo di oggetto.

Metodo: è la procedura o funzione che agisce sullo stato di un oggetto

Messaggio: è la chiamata ad un metodo da parte di un altro oggetto. Es. C-3PO.Move()

Attributo: è una variabile interna ad una classe che concorre a definirne lo stato. Es. Private Sensor as Radar

Proprietà: è il metodo col quale si scrive o si legge un attributo di una classe. Es. C-3PO.GetBatteryLevel()

Ereditarietà: è la possibilità di creare gerarchie di classi in cui alcuni metodi o attributi risiedono nella classe base

Polimorfismo: è la possibilità di definire uno stesso nome di metodo con comportamenti diversi

Astrazione: è la caratteristica principale delle classi che consente di trattare ad alto livello i problemi

Incapsulamento: è l’azione di nascondere al mondo esterno parti di funzionamento interno alla classe



Incapsulamento(1)

L’information hiding viene implementata nella OOP mediante la definizione di CLASSE.

La classe è un modo per realizzare strutture composte da dati e metodi che li elaborano; esse consentono di istanziare OGGETTI che ne rappresentano le funzionalità utilizzabili nei programmi sotto forma di variabili.

ATTRIBUTI: sono le variabili che rappresentano lo stato interno dell’oggetto; possono essere di tipi base del linguaggio oppure di tipo classe definita nel programma stesso. Un attributo accessibile può essere scritto (SET) o letto (GET) mediante apposite proprietà (PROPERTIES) che possono anche specificare solo uno dei due accessi (proprietà Read Only, Write Only o Read & Write).

METODI: rappresentano il sistema che l’oggetto adotta per comunicare con l’esterno, emettendo o ricevendo MESSAGGI.



Incapsulamento(2)

Metodi e Attributi possiedono dei MODIFICATORI che consentono di alterarne la visibilità all’esterno della classe.

Privati (Private)

Sono visibili e quindi utilizzabili esclusivamente all’interno della classe che li definisce. Il loro scopo è quello di implementare meccanismi di funzionamento interni o rappresentano parti dello stato che non devono essere resi pubblici.

Pubblici (Public)

Sono visibili e utilizzabili da tutti gli elementi del programma; essi rappresentano lo stato o le funzionalità che la classe rende disponibili per interagire con essa.

Protetti (Protected)

Sono visibili ed utilizzabili solo dalle classi che gerarchicamente si trovano al di sotto della classe principale e quindi che da essa ereditano; per ogni altro componente del programma essi risultano non visibili e non utilizzabili.



Incapsulamento(3)

Statici (Static)

Sono metodi o attributi di classe e non di istanza il che implica che per chiamarli o per leggerne il valore non serve istanziare alcun oggetto. Ogni istanza di una classe contenete metodi o attributi statici può accedere a questi elementi che condivide con tutte le altre istanze.

Es. Contatore di istanze di una classe

Finali (Final)

Sono metodi dei quali si vincola a non poterli più ridefinire; lo stesso modificatore è applicabile alle classi delle quali non si vuole più consentire l’ereditarietà.

Virtuali (Virtual)

Sono tutti quei metodi che non contengono implementazione e che ad esempio risiedono nelle interfacce; questi metodi tipicamente sono implicitamente definiti come Must Inherits ovvero devono essere ridefiniti nelle classi che estendono l’interfaccia di cui fanno parte.



Incapsulamento(4)

Vantaggi dell’incapsulamento sono

Robustezza

Nascondendo ciò che non è necessario esporre si sfavorisce un utilizzo non ortodosso della struttura dati interna.

Es. Stack o Queue implementate con vettori e variabili di stato Empty, Full, CurrentElement sono soggette ad un inserimento ed estrazione di elementi del vettore con accesso diretto anzichè con Push() e Pop()

Indipendenza

Il “mondo esterno” conosce solamente l’interfaccia con la quale dialogare con l’oggetto mentre la sua implementazione è nascosta e quindi aggiornabile indipendentemente da chi sta già utilizzando l’oggetto.

Es. Metodo Draw() che disegna un quadrato. La prima versione utilizza quattro chiamate ad una DrawLine() mentre la versione successiva e più performante utilizza una unica DrawBox()

Riusabilità

Essendo moduli autocosistenti, le classi si prestano ad essere riutilizzate in più parti dello stesso applicativo o in applicativi diversi, magari raccolte in Package.



Esempio


Public Class Demo Private _nome As String Private _dataNascita As Date Private _eta As Integer

Public ReadOnly Property Eta() As Integer Get Return _eta End Get End Property

Public Property Nome() As String Get Return _nome End Get Set(ByVal value As String) _nome = value End Set End Property

Public Property DataDiNascita() As Date Get Return _dataNascita End Get Set(ByVal value As Date) _dataNascita = value End Set End Property

Public Sub New(ByVal iNome As String, ByVal iDataNascita As Date) _nome = iNome _dataNascita = iDataNascita _eta = Now.Year - _dataNascita.Year ' Modo scorretto di calcolare l'età :-) End Sub

Public Overrides Function ToString() As String Return _nome + " nato il " + _dataNascita.ToString("D") + " di età " + _eta.ToString + " anni" End Function

End Class


Ereditarietà(1)

Rappresenta la possibilità di definire una classe derivandola da una già esistente, acquisendo i metodi e gli attributi di quest’ultima.

La classe dalla quale si eredita viene detta SUPERCLASSE mentre la derivata si indica con SOTTOCLASSE.


Questo meccanismo consente di creare gerarchie di classi che hanno in comune certe caratteristiche e funzionalità che possono essere specializzate nelle classi derivate per aderire al comportamento specifico desiderato.


Ereditarietà(2)

L’ereditarità ha il vantaggio che è possibile centralizzare tutto il codice che accomuna le classi derivate, minimizzando quindi i punti in cui intervenire in caso di refactoring.

E’ anche un ottimo sistema per tenere “pulito” il codice e organizzarlo in modo chiaro e comprensibile, usando per esempio INTERFACCE o classi ASTRATTE.

Una Interface è una classe che definisce la struttura di un oggetto senza occuparsi dell’implementazione, che invece sarà realizzata da tutte le classi che da lei deriveranno (si dice che una classe “estende” o “implementa” un’interfaccia).

Una Abstract Class è una classe che defininisce la struttura di un oggetto e può anche implementarne alcuni metodi generici per tutta la gerarchia.



Ereditarietà(3)

Interface vs Abstract classLe interfacce possono definire metodi e proprietà ma non attributi

Le classi abstract possono fornire una implementazione per i metodi e possono definire attributi

Una classe può estendere molte interfacce ma eredita solo da una classe

Entrambe non possono essere istanziate

Le interfacce definiscono le “abilità” che un insieme di classi devono avere per svolgere un compito. Es. Interfaccia Sortable

Una abstract class definisce anche il “modo” con cui una classe deve svolgere un compito. Es. metodo implementato nella classe abstract

Le interfaccie obbligano la classe che le estende ad implementare tutti i suoi metodi mentre le abstract seguono il principio dell’ereditarietà



Ereditarietà(4)

Quando usare l’ereditarietà ? Classi astratte, Interfacce o semplice ?

Va usata in tutti i casi in cui è presente una palese gerarchia tra gli elementi che compongono il problema da risolvere; il beneficio principale consiste nella minor stesura di codice, nella possibilità di centralizzarlo e nell’approccio top-down al problema.

Se vi sono oggetti che sono utili per identificare una categoria ma che non saranno mai istanziati allora è bene indirizzarsi alle interfacce o alle classi astratte; al contrario se una classe non solo è genitrice di una gerarchia ma anch’essa sarà realmente utilizzata allora si può realizzare un’ereditarietà semplice.



Ereditarietà(5)

Nel caso in cui si sia scelta la prima strada si può considerare che l’uso delle interfacce è utile quando oggetti possono doverne estendere più di una e quando non sia chiaro a priori o sia poco indentificabile un’implementazione comune per tutta la gerarchia.

Interfacce e classi astratte rappresentano appunto un concetto astratto e di alto livello utile per individuare linee guida nello sviluppo.



Polimorfismo(1)

Per comportamento polimorfico si intende la possibilità di un oggetto di effettuare azioni (metodi) che hanno risultati differenti in base all’oggetto sul quale vengono invocati, all’interno di una gerarchia di classi.

Es.


MyRover.RotateRight()

RightWheel.Speed=10;

LeftWheel.Speed=20;

MyHexapod.RotateRight()

RightLegs.MoveBackward();

LeftLegs.MoveForward();


Polimorfismo(2)

Il polimorfismo ha diversi vantaggi:

Migliora le performance

Un metodo implementato nella classe base viene successivamente raffinato per svolgere meglio compiti di dettaglio nelle classi derivate.

Es. Object.Draw() nella classe base implementato con una draw di un punto alla volta mentre nell’oggetto Rectangle è implementato con la primitiva Object.DrawBox()

Agevola il rapid prototyping

Si implementa un metodo nella classe base con funzionalità generiche che vengono specializzate solo nel divenire del progetto.

Consente una visione omogenea delle funzionalità

E’ possibile assegnare lo stesso nome a metodi che hanno comportamenti differenti, ad esempio perchè agiscono su un numero diverso di parametri, pur avendo la medesima finalità; altresì è possibile utilizzare lo stesso nome e numero di parametri ma per ottenere risultati diversi ma omogenei per funzionalità.

Es. Object.ToString(), Persona.ToString(), Azienda.ToString()



Polimorfismo(3)

Il polimorfismo si realizza mediante due tecniche:

Overloading

Effettuare overloading di un metodo significa dichiararlo più volte all’interno della stessa classe o in classi gerarchicamente dipendenti, mantenendone il nome ma variandone la SIGNATURE.

Es. Cerchio.Draw(center as Point,radius as Integer)

Cerchio.Draw(x as Integer,y as Integer,radius as Integer)

Cerchio.Draw(upperLeftPoint as Point,width as Integer,height as Integer)

Overriding

L’overriding consiste nel ridefinire un metodo di una classe base in una derivata ottenendo che l’oggetto istanziato chiamerà a run-time il metodo che realmente ha implementato utilizzando la tecnica del late binding.



Polimorfismo(4)

ll polimorfismo è particolarmente utile quando la versione del metodo da eseguire viene scelta sulla base del tipo di oggetto effettivamente contenuto in una variabile a runtime invece che al momento della compilazione; questo viene detto dinamic binding o late binding.


Private Sub Main()

Dim robots As New List(Of IRobot)

Dim rover1 As New Rover

Dim rover2 As New Rover

Dim hexapod As New Hexapod

robots.Add(rover1)

robots.Add(rover2)

robots.Add(hexapod)

For Each r As IRobot In robots

r.Move(10)

Next

For Each r As IRobot In robots

r.Turn(1)

Next

End Sub


Guidelines

Nascondere i dati non strettamente necessari e fornire astrazione funzionale (Abstract Data Type) usando l’incapsulamento.

Usare le superclassi per definire il codice comune a molte classi piuttosto che

distribuire lo stesso codice in più classi diverse.

Usare l’ereditarietà per specializzare i comportamenti del codice comune nelle sottoclassi.

Usare il polimorfismo per semplificare il codice e promuovere il riuso di quello già implementato.

Se possibile sfruttare il dinamic binding per generalizzare lo scambio di messaggi tra oggetti.

Utilizzare librerie di classi già esistenti eventualmente estendendole piuttosto che reimplementare codice ex novo.



Object Oriented DesignE’ il processo di pianificazione di un sistema di oggetti che cooperano per la risoluzione di un problema software.

Ciclo di vita del software: comprende tutte le attività dall’analisi inziale fino all’obsolescenza (sviluppo, aggiornamento, manutenzione)

Procedimento formale per lo sviluppo del software

Descrive le varie fasi da compiere

Fornisce le linee guida su come eseguire le fasi

Fasi principali del processo di sviluppo

Analisi

Progettazione

Implementazione

Collaudo

Object Oriented Design


AnalisiStabilire cosa deve fare il programma finale e non come lo deve fare

Documento dei requisiti (SRS - Software Specification Requirements)Descrive cosa il programma sarà in grado di fare quando verrà terminato; stabilisce una sorta di contratto nel quale si identificano le funzionalità ed i limiti dell’applicativo desiderato.

Manuale utente (User Manual)Descrive come l’utente dovrà utilizzare il programma equindi anche i risultati attesi.

Valutazione delle prestazioniOccorre analizzare i dati in ingresso al programma valutandone i carichi massimi ed i tempi di risposta coinvolti per evitare che a progetto finito e con i dati reali, l’applicativo si comporti in modo inaccettabile in termini di reattività nel fornire i risultati. Altro aspetto di fondamentale importanza lo ricopre il fabbisogno di spazio disco e spazio ram.

Es. una cattiva progettazione può portare a run-time ad un eccessiva formazione di thread che utilizzano troppa ram con la conseguente paginazione su disco ed un rallentamento delle performance.



Progettazione

Pianificazione di come implementare il sistema

Scoprire le strutture per la soluzione del problema

Decidere i metodi e le classi

Risultato:

Descrizione delle classi e dei metodi

Diagrammi delle relazioni tra classi



Implementazione, Collaudo e Installazione Implementazione

Scrivere il codice relativo alle classi definite nella fase di progettazione, compilare ed effettuare il debugging del codice.

Collaudo

Effettuare una serie di test atti a verificare che tutti i punti indicati nell’SRS siano correttamente implementati.

Produzione di un documento di test che mostri il pool di verifiche effettuate

Installazione

Installare sulle macchine target l’applicativo prodotto mediante un apposito installatore che potrebbe essere anche dotato del meccanismo di aggiornamento mediante patch per versioni successive del prodotto.Valutazione del feedback da parte dell’utilizzatore finale.



Modelli di sviluppo


!"#$%"%&'()*+&%,-.+$$(/0+ %-!&1'($$()*+&%

! Implementazione" Scrivere e compilare il codice

" Il codice implementa le classi e i metodi scopertinella fase di progettazione

" Risultato: il programma

! Collaudo" Eseguire test per vedere se il programma

funziona correttamente

" Risultato: un documento riassuntivo dei test eseguiti e dei relativi risultati

! Installazione" Utenti installano ed usano il programma per gli

scopi previsti

23+4%''()*+&% 5+3"($%6-"+0%$$+ (-7(17('(

8(&&*-1%''(&'(9

! Metodo sequenziale di

esecuzione delle fasi della

progettazione formale

! Se applicato in maniera

rigida, questo modello non

produce risultati

soddisfacenti

" Spesso è utile ripetere le

varie fasi iterativamenteraffinando progressivamente

il progetto

!$-"+0%$$+ (-1#*3($%-8:;<<9

! Suddivide il processo di sviluppo in fasi multiple

! Le fasi iniziali si concentrano sulla realizzazione di prototipidel sistema

" Quello che si impara su un prototipo si usa sul prototiposuccessivo

! Problema: numero di iterazioni elevato, il processo puòrichiedere molto tempo per essere completato

=*>%$$* 0* (''*>*'? &%$ 23+7%0*"%&'+

@()*+&($% A&*5*7('+-81>*$/##('+3*-AB=9

!"#$%"%&'()*+&%,-.+$$(/0+ %-!&1'($$()*+&%

! Implementazione" Scrivere e compilare il codice

" Il codice implementa le classi e i metodi scopertinella fase di progettazione

" Risultato: il programma

! Collaudo" Eseguire test per vedere se il programma

funziona correttamente

" Risultato: un documento riassuntivo dei test eseguiti e dei relativi risultati

! Installazione" Utenti installano ed usano il programma per gli

scopi previsti

23+4%''()*+&% 5+3"($%6-"+0%$$+ (-7(17('(

8(&&*-1%''(&'(9

! Metodo sequenziale di

esecuzione delle fasi della

progettazione formale

! Se applicato in maniera

rigida, questo modello non

produce risultati

soddisfacenti

" Spesso è utile ripetere le

varie fasi iterativamenteraffinando progressivamente

il progetto

!$-"+0%$$+ (-1#*3($%-8:;<<9

! Suddivide il processo di sviluppo in fasi multiple

! Le fasi iniziali si concentrano sulla realizzazione di prototipidel sistema

" Quello che si impara su un prototipo si usa sul prototiposuccessivo

! Problema: numero di iterazioni elevato, il processo puòrichiedere molto tempo per essere completato

=*>%$$* 0* (''*>*'? &%$ 23+7%0*"%&'+

@()*+&($% A&*5*7('+-81>*$/##('+3*-AB=9

Modello a cascata Modello a spirale

E’ un metodo sequenziale che ripropone le fasi della progettazione formale.

Se usato pedissequamente non produce risultati soddisfacenti.

E’ utile iterare alcune fasi per affinare il processo.

Prevede la suddivisione del processo in fasi di prototipazione e reingegnerizzazione per ottenere miglioramenti dal prototipo precedente.

Problema: numero di iterazioni anche elevato quindi tempi di realizzazione potenzialmente lunghi.


Use Case (1)


Gli Use Case Diagram (UCD) sono diagrammi dedicati alla descrizione delle funzioni o servizi offerti da un sistema, così come sono percepiti e utilizzati dagli attori che interagiscono col sistema stesso.

SystemIl sistema nel suo complesso è rappresentato come un rettangolo vuoto; questo simbolo viene messo in relazione con altri model element che rappresentano caratteristiche del sistema.

Actor Gli attori sono rappresentati graficamente nel diagramma da un'icona che rappresenta un uomo stilizzato (stickman). Formalmente, un attore è una classe. Un attore rappresenta un ruolo coperto da un certo insieme di entità interagenti col sistema (inclusi utenti umani, altri sistemi software, dispositivi hardware e così via).

Use Case Un caso d'uso è rappresentato graficamente come un'ellisse contenente un nome; esso rappresenta una funzione o servizio offerto dal sistema a uno o più attori.


Use Case (2)



Class Diagram(1)


ClasseUna classe rappresenta una categoria di entità dette istanze o oggetti; ogni classe è corredata da un insieme di attributi che ne descrivono le caratteristiche e da operazioni che ne descrivono il comportamento:

1. nome della classe

2. gli attributi

3. le operazioni

AssociazioniDue classi possono essere legate da associazioni che rappresentano i legami (link) che sussistono fra gli oggetti delle classi associate. Le associazioni possono essere corredate da informazioni aggiuntive relative alla molteplicità.

Dipendenze Due classi possono essere legate da una relazione di dipendenza indicante che la definizione di una delle due fa riferimento all'altra.

Generalizzazione Due classi possono essere legate da una relazione di generalizzazione, che indica che una delle due (superclasse) si può considerare una generalizzazione dell'altra (sottoclasse).


Class Diagram(2)



Sequence Diagram(1)


E’ un diagramma utilizzato per descrivere uno scenario.Uno scenario è una determinata sequenza di azioni in cui tutte le scelte sono state già effettuate; in pratica nel diagramma non compaiono scelte, né flussi alternativi.Il Sequence Diagram descrive le relazioni che intercorrono, in termini di messaggi, tra Attori, Oggetti o Entità del sistema che si sta rappresentando.

Messaggi

Un messaggio è un'informazione che viene scambiata tra due entità. Solitamente chi invia il messaggio, la parte attiva, è l'attore.Il messaggio è sincrono, se l'emittente rimane in attesa di una risposta, o asincrono, nel caso l'emittente non aspetti la risposta e questa può arrivare in un secondo momento.


Sequence Diagram(2)



corso oop & ood

Documents