Il documento analizza i pattern e i framework nel contesto del riuso object-oriented, evidenziando errori comuni sulla natura dei pattern e le loro funzionalità. I pattern sono definiti come strumenti concettuali per la risoluzione di problemi ricorrenti e non possono garantirne automaticamente la riusabilità o produttività. Viene anche discusso il concetto di framework come progetto riusabile che integra classi astratte e facilita sia il riuso del codice che del design.

1. Patterns, Frameworks, Components Breve panoramica del riuso Object Oriented STEFANO FAGO 21 Maggio 2001

2. Errori comuni sui PATTERN Cosa non sono i pattern Cosa non fanno i pattern Andremo ad esaminare:

3. Cosa non sono i PATTERN Errore 1: “Un pattern è una soluzione a un problema in un contesto”. Non è un’affermazione corretta; manca il fondamen tale aspetto di ricorsività che denota un pattern.

4. Cosa non sono i PATTERN(cont) Errore 2: “I pattern sono regole, trucchi programmativi, strutture dati”. L’affermazione è errata dato che un pattern è in primis uno strumento concettuale del tutto svin colato dall’aspetto implementativo; anche per questo non può essere applicato meccanicamente come una regola ma necessita di training e ragiona mento.

5. Cosa non sono i PATTERN(cont) Errore 3: “Visto uno, visti tutti”. L’affermazione risulta errata in quanto non solo è possibile distinguere i pattern per il loro scopo, ma esiste un ampio range di stili, detta gli, maturità, qualità.

6. Cosa non sono i PATTERN(cont) Errore 4: “I pattern necessitano di appositi tool e supporto metodologico per essere effetivamente utilizzabili”. In quanto strumento concettuale un pattern non è legato ad uno specifico tool o supporto metodolo gico. E’ da evidenziarsi però il fatto che la metodo logia object oriented si presenta come terreno fertile per la crescita dei pattern e l’automazione del loro processo descrittivo.

7. Cosa non fanno i PATTERN Errore 5: “I pattern garantiscono software con alti livelli di riusabilità e produttività”. Errore 6: “i pattern permettono la generazione di un’intera architettura”. I pattern non danno garanzie di alcun tipo sono però uno strumento concettuale che se opportunamente usato favorisce, in ultima analisi, la flessibilità e riusabilità di un progetto.

8. Cosa non fanno i PATTERN (cont) Errore 7: “I pattern sono per (object oriented) design e implementazione” Questa affermazione viene facilmente smentita considerando il fatto che i DESIGN PATTERN sono solo una parte di una famiglia di tool concettuali che riguarda anche altri aspetti dell’ingegneria del software. Il fatto che le comunità legate al design object oriented siano state particolarmente recettive sull’argomento, non deve elidere il carattere di generalità dei pattern.

9. Cosa non fanno i PATTERN (cont) Errore 8: “Non c’e alcuna evidenza che i pattern aiutino qualcuno”. E’ estremamente semplice trovare documentazione ed esperienze concrete che dimostrino l’apporto positivo determinatosi dalla diffusione dei pattern in generale.

10. quindi i PATTERN sono... soluzioni riusabili per problemi ricorrenti strumenti concettuali che catturano la soluzione di una famiglia di problemi strumenti concettuali utili anche ad esprimere architetture vincenti... … ma devono possedere un nome per essere facilmente riferiti ed ne devono essere puntualmente descritti i possibili trade-off (limiti, conseguenze, vantaggi, variazioni, suggerimenti implementativi…).

11. I FRAMEWORKS Cosa è un Framework Concetti chiave dei Frameworks Frameworks e Patterns Andremo a discutere su:

12. Cosa è un FRAMEWORK Un framework è un design riusabile di tutto o parte di un sistema, rappresentato da un insieme di classi astratte e dal modo in cui le loro istanze interagiscono. Un framework è lo scheletro di un’applicazione che può essere customizzato da uno sviluppatore.

13. Cosa è un FRAMEWORK(cont) Le due definizioni che abbiamo visto sembrano in contraddizione ma in realtà non lo sono in quanto la prima descrive la “struttura” di un framework, mentre la seconda ne evidenzia lo “scopo”. I FRAMEWORK sono una tecnica di riuso object oriented!

14. Cosa è un FRAMEWORK(cont) Le tecniche di riuso sono generalmente mirate al raggiungimento di due scopi distinti e non sempre contemporanei: il riuso del codice (es. librerie software) il riuso del design (es. design patterns). Un FRAMEWORK permette quanto il riuso del codice che il riuso del design!

15. Concetti CHIAVE Classe Astratta Modello Collaborativo Inversione del Controllo

16. Concetti CHIAVE Classe Astratta Una classe astratta è una classe che possiede almeno un metodo non implementato, definito “astratto”. Se normalmente una classe è considerata “lo stampo” per la creazione di oggetti, una classe astratta è “il template” per le sottoclassi da cui deriveranno le specifiche applicazioni. Le classi astratte sono il progetto delle componenti di un framework!

17. Concetti CHIAVE (cont) Modello Collaborativo Un framework è rappresentato da un insieme di classi astratte e da come queste interagiscono. Quest’ultimo aspetto implica la definizione del framework come MODELLO COLLABORATIVO riferito alle componenti del framework stesso. Un framework si pone come pattern dell’interazione tra le sue componenti ed in ciò si esprime la sua capacità di riuso del design!

18. Concetti CHIAVE (cont) I concetti ora visti nascono dalla giusta strutturazione di tre elementi alla base della filosofia object orieted: DATA ABSTRACTION : classi astratte per l’incapsulamento e la tipizzazione POLIMORFISMO : per concepire elementi generici capaci di operare con un ampio spettro di collaboratori EREDITARIETA’ : per promuove il riuso del codice.

19. Concetti CHIAVE (cont) Inversione del Controllo Lo sviluppatore non scrive codice per coordinare le componenti. Lo sviluppatore deve determinare le componenti che aderendo alla logica collaborativa del framework verranno coordinate da quest’ultimo. I framework assumono il controllo della applicazione e non il contrario!

20. Frameworks e Pattern I frameworks promuovono anche il riuso del design e cercano di risolvere determinati problemi ricorsivi. E’ per questi motivi che possono essere correlati ai pattern. Un Framework vuol dire anche riuso del codice e questa sua natura implementativa fa si che non si possa definirlo come pattern. Le applicazioni usando un framework ne adottano il modello collaborativo ed in ciò possono determinarsi dei pattern!

21. Frameworks e Pattern (cont) Il rapporto con i DESIGN PATTERN della GoF è particolare ed è stretto. Il perché sta nel fatto che i pattern in questione nascono essenzialmente da un’opera di disamina di framework vincenti onde isolare entità object oriented riusabili. I Design Pattern sono gli elementi micro-architetturali dei frameworks!

22. … quindi un Framework è... Riuso del codice: Riuso del design: Riuso dell’analisi: crea applicazioni da librerie di componenti e usa l’ereditarietà per il riuso delle implementazioni. modello collaborativo che coordina i diversi elementi che lo determinano. Descrive il tipo di oggetti di rilievo e fornisce il vocabolario per ragionare e discutere sul dominio del problema d’interesse.

23. … una visione d’insieme...

24. Wolfgang Pree’s METAPATTERNS Lo scopo del lavoro di W. Pree è quello di ottenere un tool potente ma semplice per semplificare la creazione di framework. Questo è possibile usando i concetti chiave sottesi ai framework ed innalzando il livello di astrazione considerato. Sarà quindi possibile isolare concetti di design (patterns) fondamentali da usare come building block nella determinazione di nuovi framework.

25. Wolfgang Pree’s METAPATTERNS (cont) Frozen Spot Hot Spot Template Method Hook Method termini e concetti usati: elemento di invariabilità nel framework Elemento di variazione che determina la flessibilità di un framework metodo di una classe astratta che coordina generalmente più hook method metodo astratto che determina il comportamento spefico nelle sottoclassi di un framework

26. Wolfgang Pree’s METAPATTERNS (cont) Il punto di partenza del lavoro di Pree è l’osservazione che nelle diverse componenti di un framework sono evidenziabili dei punti di variazione (classi e/o metodi) che permettono l’adattamento, anche a run-time, del framework in relazione ad una specifica applicazione. Tali elementi sono gli HOT SPOT.

27. Wolfgang Pree’s METAPATTERNS (cont) Hot Spot e Frozen Spot si traducono nel meta-livello proposto da Pree in HOOK e TEMPLATE, i principali metapattern che consideriamo. Dalla diversa collocazione di tali elementi e dalla loro diversa composizione derivano i metapattern che determinano il tool cercato.

28. Wolfgang Pree’s METAPATTERNS (cont) Unification : template e hook sono nella stessa classe del framework.

29. Wolfgang Pree’s METAPATTERNS (cont) Separation: hook e template sono in classi separate indicate rispettivamente come hook class e template class. Da questo metapattern derivano quelli indicati come connection e recursive connection .

30. Wolfgang Pree’s METAPATTERNS (cont) Connection: con relazioni 1:1 e 1:n

31. Wolfgang Pree’s METAPATTERNS (cont) Recursive Connection: questa volta risulta che la template class e sottoclasse della hook class con relazioni 1:1 e 1:n

32. Wolfgang Pree’s METAPATTERNS (cont) Vediamo un immediato riscontro del Tool di Pree. E’ possibile catalogare e riconoscere i GoF pattern nel nuovo metalivello. GoF pattern riconducibili al separation metapattern: Abstract Factory, Builder, Command, Interpreter, Observer, Prototype, State, Strategy. Gof pattern riconducibili al recursive combination pattern: Composite(1:n), Decorator(1:1), Chain Of Responsa bility(1:1 con unification).

33. COMPONENTS Cosa è una COMPONENTE Concetti chiave Components e Frameworks

34. Cosa è una COMPONENTE Una COMPONENTE è un package di servizi software implementati, language-neutral, presentati in un “contenitore” incapsulato e rimpiazzabile, a cui si accede tramite una o più interfacce pubbliche. Una componente non è limitata ad una specifica applicazione o piattaforma.

35. Cosa è una COMPONENTE (cont) Language-neutral : non significa scritte in un linguaggio universale, ma progettate ed utilizzabili in modo tale che componenti scritte in linguaggi diversi possano effettivamente collaborare. Incapsulamento : ogni componente può essere sviluppata indipendentemente dalle altre perchè risulta incapsulata nella propria unità di sviluppo e testing.

36. Cosa è una COMPONENTE (cont) No Singola Piattaforma : una stessa componente può essere concepita con una data interfaccia ma implementata per piattaforme differenti. Riusabile per più applicativi : una componente offre dei servizi che possono trovare impiego in applicativi differenti determinando il riuso della componente.

37. Concetti chiave INTERFACCIA IMPLEMENTAZIONE DEPLOYMENT

38. Concetti chiave: INTERFACCIA Un interfaccia indica all’utente della componente, generalmente riferito come CONSUMER, cosa la data componente può fare. Un consumer dovrebbe conoscere come usare la componente solo grazie a quanto deducibile dall’interfaccia.

39. Concetti chiave: IMPLEMENTAZIONE Un implementazione rappresenta il codice che permette il funzionamento di una componente. L’implementazione può variare e quindi una componente può avere più implementazioni. Ad esempio, una componente che offre servizi di tipo IP potrebbe avere un’implementazione relativa al TCP ed un’altra relativa all’ UDP.

40. Concetti chiave: DEPLOYMENT Il DEPLOYMENT di una componente è il file fisico (eseguibile) realizzato per l’effettiva esecuzione ed utilizzo della componente.

41. Components e Frameworks Un framework può essere visto come una componente perché riusabile all’interno di un’applicazione con altri framework ed anche perché vendibile da un dato produttore come artefatto completo; ma, in effetti… Un Framework è più propriamente un CONTESTO RIUSABILE per le COMPONENTI.

42. Components e Frameworks(cont) Un Framework, come modello collaborativo, permette la coordinazione delle diverse componenti eventualmente usate per lo specifico applicativo. Un Framework usando le date componenti e gestendo il flusso di controllo degli applicativi da esso derivati, permette il riuso delle componenti stesse.

43. Components e Frameworks(cont) Una componente nasce con lo scopo di soddisfare una o più specifiche esigenze traducibili in servizi offerti dalla componente stessa. Un framework, visto come insieme di template di classi, permette la creazione di nuove componenti e servizi anche non inizialmente previsti.