Systematic Object Oriented Design
White Paper


Un buon design è la chiave per la riuscita di ogni progetto.

L a tecnologia ad oggetti viene spesso adottata per le sue grandi promesse: classi riusabili, applicazioni estendibili, migliore qualità del prodotto finale. Tuttavia, per ottenere realmente tali benefici è necessaria una notevole esperienza. Non è quindi raro che l'introduzione della tecnologia ad oggetti non sia seguita dai tanto attesi miglioramenti nello sviluppo.
Chi prova ad avvicinarsi alla progettazione attraverso le note metodologie (Coad, Booch, OMT, UML, ecc) si accorge rapidamente che l'enfasi viene posta sul processo di sviluppo (produzione di diagrammi delle classi, degli oggetti, scenari di interazione, diagrammi di stato, ecc) e sui buoni princìpi di progettazione ("gli oggetti devono essere autonomi", "le astrazioni non devono dipendere dai dettagli", ecc). Ben poco viene detto su come ottenere tali risultati. Nel migliore dei casi vengono presentati alcuni esempi, lasciando a chi legge il difficile compito di astrarre le tecniche utilizzate e di applicarle all'interno dei propri progetti. Ancora peggio, spesso gli esempi si riferiscono a classi di infrastruttura (liste, alberi, semplici componenti di interfaccia), non ai più complessi scenari applicativi in cui molte classi cooperano per ottenere un risultato.
Non a caso, negli ultimi anni si è andato affermando l'uso dei design pattern: soluzioni sperimentate a problemi di design ricorrenti. Mentre gran parte delle metodologie sono guidate dai princìpi di progettazione, i pattern nascono dalla pratica e sono effettivamente molto utili per evitare di reinventare la ruota. L'uso dei pattern, tuttavia, oltre ad essere limitato all'impiego di soluzioni già sperimentate, richiede anche una visione molto acuta, che nuovamente si ottiene solo con l'esperienza. I pattern di design propongono soluzioni a macro-problemi che vanno identificati in anticipo: è molto difficile partire con un design semplice e migliorarlo gradualmente attraverso l'uso dei pattern. Infine, proprio perché affrontano macro-problemi, molti pattern sono difficili da capire a fondo: spesso pattern diversi sembrano essere varianti di un unico concetto, e non è affatto facile scegliere "il pattern giusto".
Il problema maggiore dell'approccio "a princìpi" è che tali princìpi non forniscono alcuna guida concreta verso un design che rispetti i princìpi stessi. Una delle ragioni è la pretesa di catturare sotto un unico principio un numero enorme di casi: purtroppo, quando si sale troppo nella scala dell'astrazione, si rischia di perdere la necessaria concretezza.
Il problema principale dell'approccio "a pattern" è che le soluzioni proposte sono di livello troppo alto, troppo strutturate, mentre in pratica ci troviamo spesso a combattere con problemi localizzati. Anzi, in molti casi è necessario trovare soluzioni localizzate per evitare che le modifiche abbiano un impatto globale sul progetto. Inoltre i pattern lasciano molti dettagli inespressi, per guadagnare in generalità, e proprio nei dettagli si annidano molti problemi di realizzazione.

Un approccio sistematico
Da diversi anni ho iniziato a codificare l'esperienza acquisita come progettista e system architect in grandi progetti. Di fronte ad ogni scelta di design, che normalmente risolvevo sulla base dell'esperienza in modo quasi automatico, ho cercato di fermarmi, di formalizzare le regole che stavo adottando e di risalire ai princìpi che si nascondevano dietro tali regole. L'approccio alla progettazione che ne è derivato è decisamente diverso dai precedenti.
Pur cercando di trarre il massimo beneficio dai due approcci su descritti, il Systematic OOD non si concentra né sui grandi princìpi né sulle macro soluzioni, ma su tecniche basilari di trasformazione.
Il concetto di fondo è molto semplice: ottenere un design "banale", che non rispetta nessun principio di buona progettazione, è decisamente semplice. Molti di noi possono anche saltare questa fase e passare direttamente a scrivere del codice. Naturalmente, in molti casi i risultati non brilleranno per riusabilità, manutenibilità, estendibilità e così via. Tuttavia, fissata una struttura di massima, gli ingredienti mancanti sono spesso una serie di piccoli accorgimenti, di scelte localizzate, di interventi mirati che modificano il design originale e lo riportano entro schemi più eleganti e flessibili. Queste trasformazioni vengono applicate "al volo" dai progettisti esperti, facendo sembrare la progettazione un'arte difficile da imparare. Quello che ho cercato di fare è proprio di codificare il maggior numero possibile di queste regole di trasformazione. In molti casi, si tratta di tecniche estremamente semplici, una volta che sono state presentate; scoprirle, però, richiede uno sforzo molto grande. Spesso per identificare una tecnica che si può spiegare in pochi minuti occorrono settimane di lavoro. Fortunatamente, tale sforzo è soltanto a carico di chi vuole estendere le basi del metodo, non di chi utilizza le tecniche nel lavoro di ogni giorno. Mentre i metodi basati sui grandi princìpi lasciano ai progettisti lo sforzo di imparare a rispettarli, il mio obiettivo è di spostare le difficoltà su chi propone nuove tecniche, non su chi deve applicarle.

In una visione più organica, l'approccio alla progettazione che ho chiamato Systematic OOD si basa su diversi elementi:

Un insieme di condizioni, verificabili in modo sistematico ed oggettivo, che possono portare a problemi di vario tipo (impossibilità di riusare una classe, o di supportare nuove funzionalità, o di estendere una gerarchia, eccetera). Ogni condizione viene fatta risalire alla violazione un principio di design, ma non pretende di catturare una casistica troppo ampia: si preoccupa invece di essere verificabile e costruttiva. Il progettista verifica l'insorgere di queste condizioni durante la normale attività di progettazione.

Un insieme di tecniche di trasformazione. Per ogni condizione problematica, esistono diverse tecniche di trasformazione che possono essere applicate, in modo sistematico, per eliminare il problema e riportare il progetto entro il rispetto dei migliori princìpi di design. La scelta della migliore tecnica dipende ovviamente dai molti fattori al contorno, e richiede quindi una valutazione del progettista che mantiene un ruolo molto importante: il Systematic OOD non ha come obiettivo il deskilling del progettista.

Un insieme di criteri per valutare le qualità relative di design alternativi. Spesso ci troviamo di fronte a delle scelte di progetto e non abbiamo basi concrete sulle quali decidere. Esistono però dei criteri fondamentali, come stratificazione, coesione ed accoppiamento, che possono essere adattati anche al paradigma ad oggetti e possono fornire una guida oggettiva in molte situazioni.

È importante notare che il Systematic OOD non si pone in competizione o in contrasto con alcuna metodologia esistente. Non richiede di apprendere una nuova notazione, o di abbandonare metodi e tool sinora utilizzati. Sia che usiate Booch, OMT, UML, un approccio informale al design, o altro ancora, potete applicare con successo le tecniche del Systematic OOD. Io ho avuto modo di utilizzarle in contesti molto diversi, in progetti di media e grande dimensione, senza nessun problema di integrazione con i diversi processi di sviluppo. L'obiettivo è di colmare le lacune lasciate dagli approcci tradizionali, non di sostituirsi a loro. Nello stesso senso, nulla impedisce di usare i pattern insieme alle regole di trasformazione del Systematic OOD. Anzi, usare un pattern diventa decisamente più semplice una volta comprese le regole di trasformazione che lo generano. I più noti pattern di design (ad esempio l'Observer, o Document/View che dir si voglia) sono infatti tutti ottenibili partendo da un design "banale" ed applicando le regole di trasformazione proprie del Systematic OOD. Ma ovviamente, mantengono la loro importanza individuale e possono essere usati in un unico passo da chi voglia utilizzarli come elementi di design.

Obiettivi del worklab
Obiettivo del worklab Systematic Object Oriented Design è di presentare alcune delle condizioni e delle tecniche di trasformazione più utili. Ho scelto le tecniche che più frequentemente ho utilizzato ed ho visto utilizzare da chi ha avuto modo di seguire questo metodo di progettazione, in modo da presentare in un tempo contenuto (quattro ore) materiale sufficiente ad influenzare positivamente l'approccio di ogni giorno al design.
L'obiettivo reale del worklab è di trasmettere ai partecipanti le tecniche di trasformazione fondamentali, che ogni progettista deve padroneggiare per essere realmente produttivo nel paradigma ad oggetti. Sono certo che rimarrete stupiti dalla semplicità delle regole di trasformazione, ma anche dalla loro potenza. Penso che ogni regola di trasformazione che vedrete trovi un utilizzo nella progettazione di ogni giorno: ho volutamente evitato gli esempi più esoterici, che servono a mettere in mostra le capacità di chi li espone ma non trovano applicazione in molti progetti reali. Non a caso, ogni tecnica viene presentata facendo riferimento ad un caso reale di utilizzo, non a situazioni improbabili ed accademiche.
Naturalmente il Systematic OOD non si esaurisce nelle tecniche che vedremo nelle quattro ore del worklab. Si tratta di un metodo aperto, in continuo sviluppo e raffinamento. Il materiale presentato rappresenta però un condensato di tecniche di applicazione immediata.

Argomenti presentati
Un worklab si sviluppa anche in base alle domande ed all'interazione con i partecipanti. Ho quindi raccolto solo per sommi capi gli argomenti che intendo coprire. L'approccio sarà decisamente hands-on, impostato su esempi concreti e problematiche reali di progettazione.

Systematic OOD: dai principi di progettazione alle tecniche di trasformazione.

Dipendenze di uso tra classi. Riusabilità ed estendibilità. Astrazioni e dettagli.

Dipendenze circolari. Stratificazione del design. Tecniche di trasformazione.

Accoppiamenti tra classi concrete. Estendibilità. Tecniche di trasformazione.

Dipendenze di istanziazione. Riusabilità ed estendibilità. Tecniche di trasformazione.

Oggetti come entità autonome. Manutenibilità e riuso. Legge di Demeter. Tecniche di trasformazione.

Accoppiamento e Coesione nel paradigma ad oggetti. Classi manager.

I temi trattati sono particolarmente importanti per chi utilizza linguaggi di programmazione con type checking statico (C++, Java, Eiffel, Ada95), anche se molti argomenti sono di indubbio interesse anche per chi utilizzi linguaggi con controllo dinamico come Smalltalk. Non solo, anche chi utilizza abitualmente strumenti RAD con un buon supporto per la programmazione ad oggetti (come Delphi) puo' sicuramente ricavare informazioni utili per il lavoro di ogni giorno.

Per maggiori informazioni
Chi avesse delle domande sul worklab può rivolgersi direttamente a me via email: il mio indirizzo è pescio@eptacom.net. Recentemente ho anche pubblicato alcuni articoli che illustrano i fondamenti o le applicazioni del Systematic OOD:

Potete trovarli seguendo il link alle mie pubblicazioni.