|
|||||||||||||||||||||||||||||||||
Il mese scorso ho analizzato un problema facendo un uso elementare di alcuni diagrammi UML. Nell'ultimo diagramma illustrato avevo individuato una struttura convincente. Prima di buttarmi nell'implementazione vorrei compiere un ulteriore passaggio di analisi, e individuare in anticipo i problemi che potrebbero sorgere in fase implementativa: ormai ho capito che e' molto piu' facile spostare qualche freccia su di un diagramma piuttosto che riscrivere centinaia di righe di codice! Quello che voglio e' definire una vera e propria riproduzione in scala di quella che divertera' un'applicazione java, attingendo questa volta alla mia personale esperienza di programmatore. |
|||||||||||||||||||||||||||||||||
Interfaccia
utente
La scorsa volta avevo completamente trascurato l'aspetto grafico dell'applicazione. La mia attenzione era rivolta alla definizione del dominio applicativo, e il dominio applicativo e' indipendente dalla volonta' di creare un'applicazione a finestre o un programma a console. Mi spiego: Word 2000, Vi ed Emacs, per quanto siano tre programmi completamente diversi tra loro nell'aspetto e nell'interfaccia utente, sono comunque dei programmi di videoscrittura. Essi risolvono lo stesso problema, e condividono lo stesso dominio applicativo. In definitiva essi potrebbero nascere dallo stesso diagramma di specifica. Ma nel passaggio all'implementazione entrano in gioco fattori come i servizi offerti dalle API di sistema o le abitudini degli utenti. Per nostra fortuna con Java disponiamo della piu' bella e completa API grafica del mondo (YEAH!). Una
delle prerogative piu' affascinanti del package SWING e' la definizione
di un nuovo approccio alla gestione degli eventi grafici. La classe AbstractAction
(ovvero le sue sottoclassi) raduna in un unico posto:
Ecco una classe di esempio che definisce una Action il cui nome e' "New", la cui icona e' "new.gif" che la chiamata del metodo newDocument() nella classe MiniPad. public
class NewAction extends AbstractAction
La cosa piu' divertente e' che, se voglio creare un bottone che esegua questa azione, non devo fare altro che creare un'istanza di NewAction ed aggiungerla (col metodo add(Action a)) ad una JToolbar. La stessa cosa se voglio un elemento su un menu' a tendina: JToolBar
toolbar = new JToolbar(); // crea la toolbar
Ecco una rappresentazione della gerarchia delle MPAction:
dove
MPAbstractAction definisce un costruttore e delle costanti comuni.
laddove
la classe Gui e' una sottoclasse di JFrame che definisce i seguenti metodi:
L'utente
osserva la Gui (che fornisce una vista sullo stato del sistema), ma agisce
sul sistema attraverso le Action. Questa separazione funzionale e' invisibile
all'utente, che ha l'impressione, quando preme un pulsante, di agire direttamente
sull'interfaccia grafica (ho ripreso questo framework dal modello MCW delle
Swing, in particolare studiando il sorgente della classe JTextArea
e dei suoi antenati.)
Ereditarieta'
e specializzazione
Per
creare un framework generale posso agire in questa maniera:
In
questo diagramma ho definito la classe JavaMiniPad come sottoclasse (specializzata)
di AbstractMiniPad.
Con un piccolo lavoro aggiuntivo ho risolto il mio problema, e allo stesso tempo ho fornito ai miei colleghi di tutto il mondo una soluzione pronta all'uso per creare editor C, C++, Pascal o quant'altro. Una
volta ho letto questa frase: "ricorda che i bravi programmatori scrivono
del buon codice, mentre i programmatori eccezionali lo copiano alla grande".
In effetti il saccheggio e' il vero motore dell'innovazione nel campo dello
sviluppo del software, e java consacra questo principio grazie al costrutto
dell'ereditarieta', che altro non e' che una forma di scippo legalizzato.
Per lenire i sensi di colpa cerco di progettare le mie classi in modo da
semplificarne il riuso e fornisco, quando possibile, il codice sotto licenza
GPL (vedi www.gpl.org)
La comunicazione
tra oggetti: i Diagrammi di Sequenza
Un Diagramma di Sequenza mostra come gli oggetti comunicano tra loro durante lo svolgimento di una specifica attivita'. Si leggono dall'alto verso il basso e da sinistra verso destra (seguendo la numerazione). Ogni freccia (corrispondente ad una chiamata di metodo) e' numerata per indicare la precisa sequenza delle azioni. I rettangoli gialli rappresentano oggetti (istanze di classi), e pertanto e' possibile mostrare nello stesso diagramma istanze diverse della stessa classe, nel caso siano coinvolte in una stessa operazione. A questo punto il modello e' abbastanza dettagliato da suggerire con precisione l'implementazione:
public
void compile()
Verso
l'implementazione e oltre: la Generazione di Codice
Come
si vede dallo screenshot, l'utente ha a disposizione una JTextArea per
l'editing e una per l'output del compilatore. Le funzioni (open, save,
compile ecc....) sono accessibili attraverso i pulsanti (disegnati dal'amico
Andrea Anzani) e sono replicate sul menu a tendina "File". Il Programma
rispetta le specifiche definite inizialmente, e rappresenta un buon punto
di partenza per un Editor. Chiaramente e' ancora lontano dall'essere un
programma completo e ricco di funzioni: tocca a voi ora migliorarlo.
JiniPad: un progetto
Open Source
www.lib.disco.unimib.it/students/ginian/jinipade scaricare una copia di JiniPad, che affronta (e risolve) problematiche piu' avanzate come: - Syntax
Highligth
Il
progetto (che amplia la struttura del MiniPad), e' interamente documentato
in UML, e ogni sviluppo prevede una fase preliminare di analisi e discussione.
E' un progetto Open Source, per cui vi invito ad utilizzarlo, a metterci
le mani sopra e a scrivermi se avete critiche o suggerimenti.
Bibliografia e Letture Consigliate "UML
Distilled" second edition
"Open
Sources - Voices from the Open Source Revolution"
"Occhio
nel Cielo"
|
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
può farlo scrivendo a mokainfo@mokabyte.it |
|||||||||||||||||||||||||||||||||
|
|||||||||||||||||||||||||||||||||
|