Analisi e Progettazione Object Oriented : un'introduzione (5W)
di Claudio De Sio Cesari
-Cosa sono l'Analisi e la Progettazione Object Oriented e chi sono gli autori (What & Who)?
Con il termine Object Orientation (OO) ci si riferisce ad una serie di tecniche per la modellazione dei sistemi software. Non esiste una documentazione ufficiale che descrive gli argomenti dell'OO, che sia universalmente riconosciuta, quindi non ha senso parlare di standard. Ciò che sicuramente bisogna sottolineare, è l'ispirazione che trae l'OO dai concetti che ci circondano nel mondo reale. Ogni argomento dell'OO, infatti, ha un suo equivalente concetto nella realtà che ci circonda e ciò dovrebbe sicuramente favorirne l'apprendimento. Questi argomenti vengono poi largamente sfruttati nel ciclo di sviluppo del software, soprattutto nelle fasi di analisi e progettazione (OOA&D). Sono noti per esempio i vantaggi derivanti in termini di progettazione dell'applicazione del concetto di ereditarietà mediante la specializzazione di una classe. L'analisi e la progettazione object oriented, nel moderno scenario dell'ingegneria del software, svolgono un ruolo sempre più determinante per lo sviluppo di software robusto ed estensibile. La base teorica per poter affrontare in maniera corretta le fasi di analisi e progettazione object oriented, è costituita dall'esperienza nel campo, e, se non la si possiede direttamente, bisogna attingere dal pensiero di chi ne possiede. Ci riferiamo agli autori delle più diffuse metodologie object oriented, che sono considerati tra i massimi esperti a livello mondiale. Qualche nome: G. Booch, J. Rumbaugh, I. Jacobson, P. Coad, E. Yourdon, K. Beck, W.Cunningham, B. Meyer.
-Dove e quando sono nate l'Analisi e la Progettazione Object Oriented (Where & When)?
Stiamo parlando di una "scienza", che si è sviluppata a partire dagli anni '60, ma che si è iniziata ad affermare presso il grande pubblico a partire dai primi anni '80. Infatti, si può far risalire l'origine dell'OO, ad una serie di articoli apparsi sulle riviste specializzate dell'epoca che inauguravano teorie critiche verso lo stile procedurale della programmazione di quegli anni. Immaginiamo lo scenario del periodo: linguaggi come il Cobol ed il Fortran, erano utilizzati in maniera massiccia in molte applicazioni professionali con risultati ottimi e sempre più entusiasmanti. Critiche del tutto teoriche al paradigma procedurale, furono interpretate da molti semplicemente come "fuori luogo", ma oggi sappiamo che più che altro si doveva parlare di critiche "fuori tempo"! Infatti, al sempre più frenetico progresso degli hardware, era ovviamente accompagnato da un progresso dei software che, utilizzando nuove risorse, dovevano gestire una sempre crescente quantità di variabili e di funzioni. I limiti del paradigma procedurale furono evidenti verso la fine degli anni '70, quando ormai la filosofia di creare software aveva ormai preso una strada definitiva. Il software doveva essere "estensibile", per adattarsi alle nuove tecnologie che nascevano oramai come funghi. Si iniziarono a rilasciare software in versioni successive (1.0, 1.2, 2.0 etc.), e questo ovviamente richiedeva un continuo aggiornamento del codice. Ecco che allora strumenti come le variabili globali (1), ed il famigerato comando GOTO (2), non risultarono più sufficienti per apportare modifiche incrementali, anzi si rivelarono dannose(3) per lo stesso ciclo di vita dell'applicazione. L'affermarsi definitivo dell'Object Orientation nell'analisi e la progettazione del software è coinciso con l'affermarsi del linguaggio C++ nella comunità dei programmatori. Possiamo però affermare che da quando ha visto la luce il linguaggio Java (1995), vuoi per naturale evolversi delle cose, vuoi per l'ottimo supporto che questo linguaggio offre ai paradigmi object oriented, il numero dei sostenitori dell'OOA&D sono cresciuti considerevolmente in numero. Un altro contributo probabilmente decisivo è stata la nascita di UML.
-Perchè fare Analisi e Progettazione Object Oriented (Why)?
Siete sicuri di saper programmare ad oggetti? Le vostre applicazioni da quante classi sono composte? A che servono gli oggetti? I metodi statici sono una manna dal cielo? Sicuramente per i programmatori più estremisti e per quelli meno esperti, l'analisi e la progettazione potrebbero significare solo una perdita di tempo, ma la realtà è ben diversa. Come formatore ho dovuto dimostrare a suon di esempi tante volte della reale utilità dell'OOA&D. Per esempio, in molti pensano che il processo di generalizzazione, che ci porta a creare una superclasse comune a più classi che condividono alcune caratteristiche e/o funzionalità, sia paragonabile alla tecnica di "copia e incolla"! (Anzi il copia e incolla non ci fa creare una classe in più!!!). È una materia estremamente ampia e teorica, e di conseguenza, definibile complessa. Spesso, soprattutto durante la fase di analisi, i nostri ragionamenti assomigliano da vicino a ragionamenti filosofici e questo sembra allontanarci dalla codifica di codice funzionante. In realtà questo darà alla nostra applicazione maggiori chance di corretto funzionamento ... provare per credere...
NOTE
Per variabile globale si intende una variabile la cui dichiarazione è posta all'interno del "programma chiamante", ovvero la funzione principale dell'applicazione, punto di partenza per convenzione dell'applicazione stessa. Una variabile globale rappresenta una scorciatoia invitante per apportare modifiche ad un'applicazione.
Il comando GOTO, permette al flusso di un'applicazione di saltare ad una determinata riga di codice, senza tenere conto del workflow logico del programma. Un tipico utilizzo di questo comando, è quello di forzare il flusso di un'applicazione le cui variabili globali assumono valori indesiderati.
L'utilizzo contemporaneo di variabili globali e del comando GOTO hanno fatto sì che fosse coniato il termine dispregiativo "Spaghetti code" per la programmazione procedurale, giacchè i programmi, crescendo in dimensioni, davano sempre più l'idea di una massa aggrovigliata di spaghetti!