Sebbene molti l'abbiano valutato come un cambiamento tecnologico, la programmazione ad oggetti (OOP) ha rappresentato, nel settore dello sviluppo del software, un cambiamento ben più profondo.
Il cambiamento non è stato solo su come produrre il software ma soprattutto su come pensarlo e come costruirlo.
Fino all'avvento dell'OOP, il software era concepito in una scenario al centro del quale si trovava l'elaboratore ed il compito del software era quello di adattarsi all'architettura dell'hardware (il cosiddetto modello di Van Neumann).
Il software era rappresentato da procedure che manipolavano dati, il cui contenuto risiedeva nei data base e la cui struttura non aveva nessun reale legame al problema da risolvere se non quello di rappresentare l'astrazione dell'ambiente e dei problemi che il software avrebbe dovuto risolvere (il cosiddetto modello dei dati).
Il concetto di oggetto ha totalmente modificato questo punto di vista: al centro dello scenario non c'è più l'elaboratore, ma il mondo reale, di cui l'oggetto rappresenta un modello, destinato a risolvere il problema da trattare facendo operare l'oggetto stesso su un elaboratore, la cui struttura e caratteristiche tecniche sono, a questo punto, del tutto irrilevante rispetto ai contenuti del problema.
L'oggetto è l'archivio per le informazioni private da trattare mediante il programma incorporato nell'oggetto (dato che il concetto di data base non esiste più come concetto primitivo nell'OOP); dati e programmi sono così inscindibili, esattamente come capita nella realtà che l'oggetto modellizza.
Nel mondo reale, infatti, ogni entità contiene i suoi dati e la conoscenza necessaria a manipolarli.
Esattamente come nel mondo reale, l'oggetto può avere un'auto-percezione e può interagire con altri oggetti, rispondendo a domande che questi gli pongono mediante un opportuno protocollo.
La costruzione del software ad oggetti richiede quindi un paradigma realizzativo totalmente diverso dal tradizionale, che è basato su una mentalità ed obiettivi diversi, anche se il risultato finale può essere assolutamente identico (esteriormente) nei due approcci.
Non è affatto detto che l'esperienza e la capacità in un ambiente di programmazione (tradizionale o ad oggetti) sia condizione sufficiente (o costituisca un vantaggio) per affrontare l'altro.
Una metafora chiarirà il concetto: chi fosse bravissimo ad utilizzare i numeri romani non è detto che per questo, abbia vantaggi nell'utilizzo dei numeri arabi.
É ovvio però che per entrambi, la moltiplicazione di due numeri dovrà dare lo stesso valore, anche se espresso in forme diverse; tuttavia, il paradigma utilizzato per il raggiungimento del risultato sarà differente, presentando vantaggi e svantaggi a seconda del problema a cui è applicato.
Pertanto, quando ci si riferisce ad un oggetto informatico, nella realtà ci si riferisce a:
un modello della realtà
un aggregato inscindibile di dati e comportamenti. (dove, con
quest'ultimo termine, intenderemo le cose che l'oggetto è capace di
fare.
Per comprendere l'importanza della logica fuzzy per questo tipo di ambiente, occorre analizzare ed approfondire i due punti precedenti.
Cos'è un modello
Dato che esiste una teoria che si occupa dei modelli, esistono
definizioni assolutamente rigorose che spiegano cosa si intende con
questo termine; qui non ci interessa il rigore che la teoria è in
grado di offrire e ci accontenteremo di una definizione intuitiva;
definiremo pertanto un modello come rappresentazione della realtà
in grado di identificarne gli elementi importanti per la riproduzione
di aspetti di rilievo per i nostri obiettivi.
Gli elementi caratteristici di un modello sono quindi:
l'esistenza di un sistema di riferimento, composto di elementi legati tra loro da relazioni
un obiettivo per cui è interessante osservare questo sistema
una trasformazione, in cui le caratteristiche del sistema
originale che possono essere di rilievo sono riportate nella sua
rappresentazione (che è appunto il modello.
Nell'approccio ad oggetti, la manipolazione del modello da parte dell'elaboratore è la chiave di risoluzione del problema.
Questo mette in evidenza la profonda differenza dell'ambiente ad oggetti rispetto a quello tradizionale: la soluzione passa attraverso un approccio "analogico" anzichè uno "digitale".
L'obiettivo di un'applicazione ad oggetti è quindi quello di riuscire
a rappresentare nel modo migliore il sistema di riferimento mediante
una serie di oggetti , che ne rappresentano l'applicazione stessa.
A seconda dei casi e della granulazione di riferimento, il modello può essere rappresentato da un oggetto atomico o da più oggetti interagenti fra di loro: in questo caso preferiremo parlare di "componente" piuttosto che di "oggetto"
Ovviamente, quanto più i dettagli della realtà sono riproducibili con semplicità e precisione, tanto più l'oggetto offrirà vantaggi come strumento di problem-solving.
L'obiettivo di un ambiente ad oggetti è quindi tipicamente di facilitare la modellizzazione della realtà in componenti informatiche destinate ad essere manipolate in modo efficiente dall'elaboratore.
Cosa sono i dati ed i comportamenti di un oggetto
Dal punto di vista tecnologico, l'oggetto è una ristrutturazione degli elementi che costituivano l'ambiente di elaborazione tradizionale e cioè dati e procedure.
Ma mentre nell'approccio tradizionali dati e procedure sono entità autonome e separabili, questo non è più vero nella tecnologia OOP.
I dati ed i programmi, inscindibilmente legati, sono la realizzazione dell'oggetto, ossia del modello della realtà.
Questa inscindibilità è esattamente la struttura del mondo reale (non informatico) che viene rappresentato nell'oggetto, senza la quale un approccio modellistico risulterebbe estremamente complicato da realizzare.
Gli oggetti vengono progettati identificando la loro struttura dati, ma soprattutto vengono progettati identificando i servizi che questi ci possono offrire.
Questi servizi rappresentano quello che una volta erano le procedure.
Ma mentre le procedure dovevano volta a volta adattarsi ai dati (da esse separati, seppure fondamentali per il loro corretto funzionamento), i servizi offerti dagli oggetti (basati su dati strutturalmente ben definite all'istante stesso della nascita dell'oggetto), rappresentano una vera e propria identificazione del come utilizzare un oggetto per risolvere il problema nel mondo reale di cui l'oggetto è un modello.
Se vogliamo, quindi possiamo dare una definizione meno tecnologica ma più "modellistica" di un oggetto dicendo che un oggetto è una cristallizzazione di conoscenza (di come risolvere un problema) finalizzato al riuso dove evidenzieremo, con l'ultimo obiettivo, la capacità di un oggetto, una volta creato, di diventare un fornitore di servizi.
Ancora una volta appare importante sottolineare la differenza dell'OOP rispetto all'approccio procedurale.
Gli oggetti sono contenitori di dati e questo implica che una delle travi portanti dell'elaborazione procedurale e cioè il concetto di data base (inteso come entità dove i dati sono memorizzati) è irrilevante e non necessario: l'oggetto stesso è l'archivio.
È quindi evidente che dal punto di vista dell'utilizzabilità dell'oggetto, l'aspetto di rilievo non è costituito dai suoi dati, ma dall'insieme dei suoi servizi, che identificheremo, nel loro complesso, con il termine di comportamento dell'oggetto.
Da quanto detto precedentemente, appare chiaro che un oggetto sarà utile quanto più rappresenta accuratamente le realtà.
Dal punto di vista di un oggetto, la realtà sarà costituita da due aspetti:
l'elaboratore, in cui l'oggetto viene manipolato
il mondo reale di tutti i giorni, da cui nascono le problematiche da risolvere
L'elaboratore rappresenta lo strumento stesso che giustifica l'esistenza dell'oggetto: senza l'elaboratore, il modello rappresentato dall'oggetto non potrebbe avere nessun potere risolutivo, attribuendo all'oggetto solo un contenuto descrittivo.
Il mondo reale rappresenta invece l'origine stessa degli oggetti: senza il mondo reale l'elaboratore non sarebbe di nessuna utilità, dato che non esisterebbero problemi da risolvere.
Il comportamento di un oggetto è quindi indirizzato sia all'elaboratore che al mondo reale; in genere, tutti i comportamenti dell'oggetto sono orientati all'utilizzo della logica binaria, che è lo strumento standard su cui è basato tutto l'approccio scientifico ed in particolare la logica base dell'elaboratore.
In questa logica un'entità appartiene o non appartiene ad un determinato insieme e questa logica è basata sul principio del terzo escluso, imponendo che non siano possibili appartenenze contemporanee a più insiemi di una stessa entità.
Questo approccio è perfetto per i comportamenti che si riferiscono all'elaboratore, dato che questo è strutturato per interpretare correttamente questo tipo di logica.
Il problema si pone viceversa per i comportamenti che modellizzano il mondo reale.
Il mondo reale non è basato sulla logica binaria, che ne rappresenta un modello utile per la rappresentazione scientifica, ma lontano dalla percezione del mondo di tutti i giorni.
Il mondo reale è basato sull'ambiguità e sull'incertezza, che quindi devono essere eliminate (con costi e difficoltà elevate) per poterne fare un modello destinato all'elaboratore.
Si immagini di avere modellizzato un cliente di un'azienda: mentre possiamo facilmente modellizzare un comportamento che ci dica il suo fatturato, è difficile un comportamento in grado di dirci se il cliente è "interessante", data l'ambiguità legata a questo termine.
Le difficoltà legate ad un mondo incerto ed ambiguo sono superabili se pensiamo di utilizzare una logica diversa da quella tradizionale per andare a modellizzare direttamente alcuni comportamenti derivanti dal mondo reale.
Questo tipo di logica è disponibile ormai da più di 30 anni: si tratta della logica fuzzy (in italiano logica sfumata), che è un'estensione della logica tradizionale ed una vera e propria matematicizzazione del linguaggio comune.
La possibilità di utilizzare una logica binaria per l'aspetto computistico e della logica fuzzy per modellizzare il mondo reale è esattamente l'obiettivo di FuzzyWorld, un framework di oggetti in grado di permettere l'utilizzo della logica sfumata.
Nella seconda parte dell'articolo, verrà presentata una introduzione a questa teoria e un parziale approfondimento di FuzzyWorld; nel seguito la sua struttura verrà presentata nel dettaglio utilizzando i patterns informatici che lo costituiscono.
Informazioni sull'autore
Lorenzo Schiavina, laureato in Economia e Commercio all'Università Cattolica nel 1967. Specializzato in Ricerca Operativa nel 1968. Esperienza di analisi e programmazione presso grandi aziende. Responsabile tecnico del Centro di Calcolo di Busto dell'Università Cattolica dal 1972 al 1975. Esperienza nel settore finanziario con particolare riferimento ai contratti a premio. Fondatore di EDOR M.Q. nel 1972. Professore di Ricerca Operativa presso la Facoltà di Matematica dell'Università Cattolica (Brescia) dal 1982. Esperienza di OOP dal 1982. Probabilmente primo utilizzatore in Italia di Smalltalk.
Discuti sul forum
Stampa
![[LM]](../../../images/skin/default/icons/lm_sm.png){kind=icon}
.
Made with GIMP
& WPP.