Fortran 90

Programmazione ad oggetti in Fortran 90

Come sfruttare le grandi potenzialità della programmazione ad oggetti in fortran 90

La tecnologia ad oggetti è spesso adottata per le sue grandi promesse: classi riusabili, applicazioni estendibili, maggior manutenibilità, facilità di test, in conclusione migliore qualità del prodotto finale. Tuttavia per ottenere realmente tali benefici è necessaria una notevole esperienza che si acquisisce solo attraverso il lavoro su grandi progetti. Non è quindi raro che l'introduzione della tecnologia ad oggetti nello sviluppo del software non sia seguita dai tanto attesi miglioramenti. Molti programmatori affrontano il problema da risolvere semplicemente associando le classiche procedure o funzioni della programmazione strutturata ai metodi della programmazione orientata agli oggetti; associano le variabili globali della prima alle variabili di classe della seconda e via dicendo. Risultato: una programmazione procedurale incapsulata in una sintassi orientata agli oggetti. Evidentemente si tratta di un approccio sbagliato. Non per niente è più semplice per un principiante imparare a programmare ad oggetti, che per un vecchio programmatore procedurale. Quando programmiamo ad oggetti dobbiamo abbandonare il paradigma basato su azioni indipendenti. Non dobbiamo pensare in termini di cosa fare, ma di far lavorare insieme oggetti che si scambiano informazioni cioè messaggi. In pratica dobbiamo strutturare il nostro ambiente come un mondo virtuale in cui esseri di varia natura, chiamati oggetti, comunicano fra loro richiedendosi reciprocamente servizi e scambiandosi dati. Ogni oggetto appartiene ad una categoria, le cui responsabilità sono ben definite. Tali categorie si chiamano classi. Le capacità che ha ogni oggetto di comunicare e di compiere attività specifiche si chiamano metodi. Le informazioni gestite direttamente dall'oggetto e che sono parte integrante della sua definizione, sono le sue variabili interne, che determinano il suo stato. Esistono poi metodi e oggetti detti di classe perché tipici dell'intera categoria piuttosto che del singolo oggetto. Le classi possono essere poi organizzate secondo una gerarchia ereditaria del tipo: il gatto è un carnivoro, ma è anche, più in generale, un mammifero; e un mammifero è un animale. La programmazione Object Oriented è diventata lo stile di programmazione nell'industria del software negli ultimi dieci anni. La ragione di questo è da ricercare nella crescita di dimensione dei progetti software.E' diventato estremamente difficile riuscire a capire un programma sviluppato con approccio procedurale una volta che esso raggiunge una certa dimensione. I programmi Object Oriented sono più semplici da scrivere, capire e mantenere.Le ragioni fondamentali sono: i programmi OO tendono ad essere scritti in termini di oggetti del mondo reale; questo fa si che siano più semplici da capire, ma rende più difficoltoso il loro progetto iniziale; i programmi OO incoraggiano l'incapsulamento: i dettagli dell'implementazione di un oggetto sono nascosti all'utilizzatore dell'oggetto (client); i programmi OO incoraggiano la modularità. Questo significa che "porzioni" di programma non dipendono da altre porzioni del programma stesso. Queste porzioni possono essere riutilizzate in futuri progetti rendendo più semplice la realizzazione dei nuovi lavori.
La programmazione OO, confrontata con l'approccio procedurale, richiede un lavoro inizialmente più difficile, perché il compito di identificare gli oggetti e di individuare i messaggi, comporta una serie di operazioni complesse.
Il processo di disegno del software è tipicamente diviso in due fasi distinte:
• Object Oriented Analysis (OOA)
• Object Oriented Design (OOD).
Nella fase OOA, le domande che ci porremo saranno: "Di che cosa il mio programma necessita?", "Quali classi saranno presenti nel mio programma?", "Qual è la responsabilità di ciascuna classe?".Ci sono tre attività che si devono fare nella fase dell'analisi:

•determinare la funzionalità del sistema: analisi delle esigenze;
•creare una lista delle classi che sono parte del sistema;
•distribuire le funzionalità del sistema attraverso le classi individuate.

Una buona analisi ha queste caratteristiche: le classi sono relativamente piccole e molte di queste sono abbastanza generali da prevedere di poterle usare in futuri progetti; le responsabilità e il controllo sono distribuiti, in altre parole il progetto non ha un centro esplicito; ci sono poche assunzioni riguardo al linguaggio di programmazione da usare.
Nella fase OOD ci chiederemo: "Come gestirà la classe le sue responsabilità?", "Quali informazioni sono necessarie alla classe?", "Come comunicheranno le classi tra loro?", "come le informazioni passano attraverso il nostro sistema". In conclusione ci chiederemo: "Quali sono gli attributi e i metodi che ciascuna classe deve avere?".Una classe raramente viene costruita senza metterla in relazione in qualche modo con altre classi. Per descrivere graficamente le relazioni tra un insieme di classi inserite in un progetto si usano dei simboli particolari.
Nel Fortran 90 sono stati introdotti i moduli, essi rappresentano un metodo comodo per impacchettare questi nuovi tipi di dati e le operazioni su di essi. I moduli si possono utilizzare all'interno di una stessa applicazione oppure richiamare da applicazioni differenti, come si può vedere dalla figura qui sopra. Il costrutto dei moduli fornisce un supporto pratico ed efficace per la programmazione object-oriented e, al tempo stesso, consente una programmazione più efficiente ed elegante, infatti le classi a cui prima più volte si è fatto riferimento possono essere assimilate a dei moduli liberamente utilizzabili da diversi programmi.

• » Invia tramite EMAIL
• » Versione per la STAMPA
• » Le vostre opinioni

I link correlati all'argomento

• Manuali in fortran 90
• Compilatore fortran 90