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.

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 o un’API di un 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 una
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 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.

Un esempio di progettazione
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 generalizzabili (hot-spot) bisogna capire cosa hanno in comune i tre
giochi:
1. l’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 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 brick o del tennis)
 Obstacle

In figura LinearBall fa riferimento alla pallina da tennis (che fa una traiettoria lineare).

Focus sul dominio della soluzione

L’analisi della realtà consente una modellizzazione del dominio del problema com’è noto, 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

E’ difficile 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 risolve 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.

Confronto Framework e Pattern

Un framework è:
 un’istanza concreta di 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 loro in modo
diverso secondo precisi 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 una composizione di Template Method. In realtà su questa

struttura Gamma ha definito i pattern Builder, Strategy, Bridge.

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 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 .......................................................................................................... 2
PRINCIPIO DI HOLLYWOOD ....................................................................................... 2
LA METAFORA DELL’HARDWARE ................................................................................. 2
HOT-SPOT E HOOK ...................................................................................................... 3
COME SI GENERALIZZA UN FRAMEWORK ................................................................... 4
UN ESEMPIO DI PROGETTAZIONE ....................................................................................................... 4
FOCUS SUL DOMINIO DELLA SOLUZIONE ................................................................... 5
CONFRONTO FRAMEWORK E ARCHITETTURE .............................................................. 5
CONFRONTO FRAMEWORK E PATTERN ....................................................................... 6
ASSEMBLAGGIO DIVERSO DI HOOK E ANCHOR .......................................................... 6
RIFERIMENTI ............................................................................................................. 8

9
Copyright 2003 – R. Turco