Framework e UML Ing. R. Turco
1 Copyright 2003
–
R. Turco
Introduzione Un framework è una struttura semi-completa, riusabile, e relativa ad uno specifico dominio di problema. problema. Disporre di un framework permette di poter affrontare rapidamente diversi problemi di uno stesso dominio grazie alla facilità di riuso, inoltre permette di reagire in modo efficiente ed efficace ai cambiamenti dei requisiti.
Principio di Hollywood Un framework ha una modalità di riuso completamente diversa, ad esempio, da un componente o da un toolkit. Una libreria riusabile riusabile o un’API di un middleware middleware vanno richiamati dal nostro applicativo. Il framework, invece, per risolvere il particolare problema richiama i componenti custom aggiunti. In altri termini un framework si basa sul principio di Hollywood “Non chiamateci, Vi chiameremo!”.
Figura 1
L’utilizzo dei framework si avvicina molto al concetto di integrazione di software commerciale, con la differenza che oltre alla parte custom si produce anche il framework ai fini del dominio del problema ma col vantaggio che è riusabile per tutti i problemi appartenenti allo stesso dominio.
La metafora dell’hardware Il framework fa da “telaio” a cui aggiungere “moduli software”, proprio come se fosse un a scheda madre (un’infrastruttura) a cui aggiungere altre schede per espandere le funzionalità dell’hardware. Il framework, infatti, viene concepito con degli “ hot-spot”, punti di aggancio a cui attaccare le parti di software custom che permettono di specializzare il tutto in riferimento alla risoluzione del problema particolare.
2 Copyright 2003
–
R. Turco
Hot-Spot e Hook In letteratura si usano diversi termini per indicare gli hot-spot. Gli hot-spot sono tipicamente classi astratte o gruppi di classi astratte del framework, a cui è possibile aggiungere per ereditarietà altre funzionalità attraverso dei metodi “ hook” (aggancio o uncino). Un classico esempio di hook è dato dal Design Pattern “Template Method” nella figura successiva.
Figura 2
Il Template Template Method permette alla sottoclasse aggiunta di effettuare l’overload dei metodi il che consente di cambiare il comportamento dei metodi senza cambiare la struttura. Per i motivi di sopra un Hot_spot è definito come l’insieme costituito dai metodi hook e dal Template Method . Per tale definizione e ricordando cosa sono i Design Pattern, si conclude che anche i Design Pattern sono degli Hot-spot.
Figura 3
3 Copyright 2003
–
R. Turco
In figura 3 si mostra che anzicchè aggiungere metodi Hook è possibile far in modo che il Template Method crei una classe Template Anchor, cioè una classe il cui compito è creare oggetti Hook e poi sfruttare il polimorfismo dei metodi, ad esempio Process() e Execute(). Da questa prima parte si capisce che i Pattern danno un grosso contributo alla realizzazione dei framework.
Come si generalizza un framework Non è semplice creare immediatamente un framework, almeno finchè non si conosce bene il dominio del problema delle applicazioni da creare. In alcuni casi solo dopo aver sperimentato due o tre soluzioni diverse si riesce ad avere la competenza per realizzare un framework. In altri casi, invece, i problemi da affrontare hanno degli elementi caratteristici in comune ed è possibile, quindi, progettare un framework da subito.
Supponiamo che il dominio del problema sia quello del “software per giochi” e che i giochi in questione siano: Bump-Em car (auto-scontro); Brick-world; Tennis da tavolo.
Figura 4
Per individuare delle aree generaliz zabili (hot-spot) bisogna capire cosa hanno in comune i tre giochi: 1. l’ ostacolo ostacolo (muro, tavolo da tennis) contro cui urta la pallina o l’auto; 2. il controllore di gioco che pilota l’auto, e le racchette (brick world o tennis da tavolo). 3. l’ oggetto oggetto con cui si gioca (auto, pallina) In questo caso vanno considerati almeno tre oggetti object oriented: un ostacolo: wall, brick o table; un oggetto in movimento: pallina, auto; un controller di brick o di tennis da tavolo.
4 Copyright 2003
–
R. Turco
Figura 5
Il framework avrà le parti tratteggiate come hot-spot, che saranno classi astratte nel caso C++ o interfacce nel caso Java. A tali classi astratte si agganceranno i tre giochi. Il framework dovrà avere nel suo interno: un event loop; un window refresh ; un oggetto in movimento (indipendentemente da cosa sia); la rilevazione di collisioni. Le classi astratte saranno: Controller; Bouncer (l’oggetto che fa la collisione: auto, pallina del bri ck o del tennis) Obstacle In figura LinearBall fa riferimento alla pallina da ten nis (che fa una traiettoria lineare).
Focus sul dominio della soluzione L’analisi della realtà consente una modellizzazione modellizzazione del dominio del problema com’è noto, fino fino a giungere al dominio della soluzione. Il framework focalizza la sua attenzione subito sul dominio della soluzione ed è per questo che alcune volte si parla di application framework. Un framework, di conseguenza, è un’istanza di uno specifico dominio di architettura software (DSSA).
Confronto Framework e Architetture Architetture E’ difficile definire definire la differenza tra framework ed architettura perché si tratta soprattutto di sfumature. 5 Copyright 2003
–
R. Turco
Un’architettura è sicuramente un modello ripetibile di infrastruttura, che ri solve un problema e, poiché è finalizzata alla realizzazione di un prodotto, risulta adatta a singoli prodotti e non a linee di prodotti. D’altra parte quando si parla di architettura non ci si focalizza sui suoi dettagli che la specializzano. Ma per far funzionare un’architettura per un altro prodotto spesso occorrono modifiche consistenti. Un framework è senz’altro un’infrastruttura o un’architettura ed è: generalizzata; riusabile; specializzabile. Per cui un framework è riusabile per più prodotti appartenenti allo stesso dominio del problema. Di conseguenza un framework è un’architettura ma non è vero il contrario. contrario.
Confronto Framework e Pattern Un framework è: un’istanza concreta di un’architettura; un’architettura ; incorpora Pattern a livello di micro-architettura; Un Pattern è una micro-architettura astratta. Un Pattern cattura l’idea che è presente dietro un disegno, individuando oggetti, collaborazione e responsabilità. I Pattern aiutano a dare flessibilità al framework perché permettono di creare la struttura e la relazione tra Hook ed Anchor, che sono i building block che rendono possibile un framework.
Assemblaggio diverso di Hook e Anchor Le classi Anchor ed Hook già viste in figura 3, possono essere combinate fra l oro in modo diverso secondo precisi pattern. pattern. Esaminiamo tale problematica.
Figura 6
La figura 6 mostra una relazione 1:1 tra Anchor ed Hook. SomeClass dispone di un reference a SomeHook attraverso SomeClass.oHook(). Il metodo oHook è privato.
6 Copyright 2003
–
R. Turco
Figura 7
In figura 7 viene presentata una variante alla figura 6, dove le due classi discendono da una classe Padre. Applicando un minimo di refactoring alla figura 7 è possibile spostare verso l’alto i dettagli della relazione; ad esempio si può spostare il metodo oHook come in figura 8 e di conseguenze nasce una relazione self.
Figura 8
Nella parte sinistra della figura 8, tutti i discendenti ereditano la relazione self. Questo ha almeno due conseguenze: 1. il diagramma è come se si semplificasse come nella parte sinistra della figura 8 2. è possibile usare la struttura di sopra per concatenare oggetti in una chain (Figura 9)
Figura 9
In figura 10 viene presentata pr esentata una composizione di Template Method. In realtà su questa struttura Gamma ha definito i pattern Builder, Strategy, B ridge.
Figura 10
7 Copyright 2003
–
R. Turco
RIFERIMENTI [DR1] Martin Fowler – UML Distilled – Prima edizione italiana [DR2] Leszeck A. Maciaszek - Sviluppo di sistemi informativi con UML [DR3] Rosario Turco – Usabilità e ripetibilità dei processi produttivi software [DR4] Rosario Turco – Modellare Modellare con l’UML ed i colori [DR5] Robert C. Martin – Design Principles and Design Patterns [DR6] Gamma, Helm, Johnson,Vlissides – Design Patterns – Elementi per il riuso di software a oggetti – Prima edizione italiana [DR7] Rosario Turco - Pattern e la “GRASP Oriented Analysis” [DR8] Rosario Turco - Risoluzione problemi con UML
8 Copyright 2003
–
R. Turco
INDICE FRAMEWORK E UML ........................................... ...................... .......................................... ........................................... .................................... .............. 1 INTRODUZIONE INTRODUZIONE .......................................... ..................... ........................................... ........................................... .......................................... ..................... 2 PRINCIPIO DI HOLLYWOOD HOLLYWOOD ......................................... .................... ........................................... ........................................... ........................ ... 2 LA METAFORA DELL’HAR DWARE DWARE ........................................... ..................... ........................................... ...................................... .................
2
HOT-SPOT E HOOK .......................................... .................... ............................................ ........................................... ...................................... ................. 3 COME SI GENERALIZZA GENERALIZZA UN FRAMEWORK .......................................... ..................... ........................................... ......................... ... 4 UN ESEMPIO DI PROGETTAZIONE .......................................... ................................................................. ............................................. ...................................... ................ 4
FOCUS SUL DOMINIO DELLA SOLUZIONE ................................... ................................ ...................... .......... 5 CONFRONTO FRAMEWORK E ARCHITETTURE ......................................... .................... .......................................... ..................... 5 CONFRONTO FRAMEWORK FRAMEWORK E PATTERN ........................................... ...................... .......................................... ............................ ....... 6 ASSEMBLAGGIO DIVERSO DIVERSO DI HOOK E ANCHOR ..................................... ................ .......................................... ..................... 6 RIFERIMENTI ............................................................................................................. 8
9 Copyright 2003
–
R. Turco
