L’Azuki framework è un application framework Java rilasciato sotto licenza LGPL (Lesser General Public License) con l’obiettivo di risolvere alcuni problemi ricorrenti nel ciclo di sviluppo, attraverso la creazione di componenti indipendenti e la definizione delle dipendenze fra i componenti (weaving).

Relativamente all’importanza della prima fase, basti pensare che il framework stesso è costruito per componenti (bean); ci sono Azuki Bean basilari, kernel), standard e dei maggiori open project con cui è integrato. Il framework facilita anche la creazione di propri bean: basta incapsulare tutto il codice necessario in un JAR e creare un descrittore di deployment XML, che dichiara un POJO (Plain Old Java Object).

L’importanza di creare componenti indipendenti aumenta senza dubbio la modularità, con la possibilità di ottenere un sistema flessibile e plug-and-play; inoltre si riduce la complessità — riconosciuta universalmente come la bestia da domare da tutti i trattati di ingegneria del software — in quanto permette di concentrarsi su singole parti, riducendo il numero di dettagli da considerare in un dato momento. Ne beneficia anche il riuso e la possibilità di localizzare le funzionalità, con una conseguente chiarezza complessiva su tutto il sistema e facilità di manutenzione e testing.

Il procedimento di weaving è eseguito da uno strumento grafico chiamato weaver; l’analisi dell’architettura software è facilitata da esso perchè offre diverse prospettive delle interazioni fra i componenti, consentendo ragionamenti più profondi e accurati sulle scelte progettuali relative al design di alto livello e all’implementazione di funzionalità. La visualizzazione dei componenti può essere ottenuta attraverso differenti livelli, filtrando alcuni aspetti della loro integrazione. Il risultato del processo è immagazzinato in un file XML, che consente la creazione di versioni personalizzate del prodotto senza la necessità di modificare il core.

Il framework implementa la SoC (Separation of Concerns). Il termine concern non è di facile descrizione, e si può definire come un requisito specifico, funzionalità o considerazione relativa all’obiettivo del sistema. Questo approccio fa sì che sia più facile la suddivisione del lavoro e l’assegnazione delle responsabilità, relativamente alle esigenze e ai ruoli degli sviluppatori. Al di là di una potente combinazione di design pattern, la comunicazione tra i bean è ottenuta con l’utilizzo di diverse tecniche di programmazione: AOP (Aspect Oriented Programming); Dependency Injection; EBP (Event-Based Processing); Contextual Programming.

L’AOP si eleva su altre metodologie fornendo il supporto per l’implementazione di funzionalità trasversali al sistema (crosscutting concerns), migliorando la modularità, la chiarezza e ponendo rimedio ai maggiori problemi che risiederebbero nell’implementazione di simili funzionalità, secondo un approccio classico: code scattering e code tangling. Il modello Dependency Injection è implementato dal weaver ed ha lo scopo di delegare al framework la specifica delle interazioni fra i componenti.

L’EBP è una tecnica leggera e ad alte prestazioni per lo scambio di messaggi tra i bean. Essa supporta due modelli di messaggistica: point to point e publish and subscribe. La programmazione contestuale fornisce il concetto di context, che gestisce le informazioni condivise da componenti facenti parte della stessa catena. Con questo è possibile regolare l’accoppiamento, rendendolo un po’ più alto se c’è necessità di alta coesione, o rendendolo più basso per massimizzare il riuso e la flessibilità. Invito a dare un’occhiata ai sorgenti e magari a scaricare il framework. E’ anche disponibile un video di 20 secondi che mostra il weaver.

di Roberto Casadei - Programmazione.it