FUNZIONE QUALITÀ E SICUREZZA Controllo delle copie Il presente documento, se non preceduto dalla pagina di controllo identificata con il numero della copia, il destinatario, la data e la firma autografa del Responsabile della Qualità, è da ritenersi copia informativa non controllata. Guida Metodologica Pattern Architetturali Java SQC609006 ver. 2 Guida Metodologica Pattern Architetturali Java SQC609006 VER. 2 Pag. 1/42 FUNZIONE QUALITÀ E SICUREZZA Sommario 1 Scopo e campo di applicazione 3 2 Riferimenti 3 2.1 Controllo del Documento: Stato delle revisioni 3 2.2 Documenti esterni 3 2.3 Documenti interni 3 2.4 Termini e Definizioni 3 3 Introduzione 4 4 Design pattern 5 5 Vantaggi dei pattern 5 6 Pattern di creazione 6 6.1 Singleton 6 6.2 Factory Method 6 6.3 Prototype 8 6.4 Abstract Factory 9 6.5 Builder 10 7 Pattern di struttura 10 7.1 Facade 10 7.2 Composite/Container 12 7.3 Adapter 13 7.4 Proxy/Stub 14 7.5 Decorator o Filter 15 7.6 Flyweight 16 8 Pattern di comportamento 17 8.1 Template Method 17 8.2 Chain of Responsibility 18 8.3 Iterator o Enumeration 18 8.4 Command 19 8.5 Mediator 20 8.6 Observer 22 8.7 State 23 8.8 Strategy 24 8.9 Visitor 25 9 Presentation tier pattern 26 9.1 Model-View-Controller 26 9.2 Estensioni del pattern MVC 27 9.2.1 Front Controller 27 9.2.2 Service to Worker 28 9.3 View Avanzate 29 9.3.1 View Helper 29 9.3.2 Composite View 30 10 Business tier pattern 32 10.1 Composite Entity 32 10.2 Business Delegate 33 10.3 Session Facade 34 10.4 Service Locator 36 10.5 Service Activator 38 11 Communication Pattern 39 11.1 Data Transfer Object Pattern (DTO) 39 12 Data Access Pattern 40 12.1 Data Access Object Pattern (DAO) 41 Guida Metodologica Pattern Architetturali Java SQC609006 VER. 2 Pag. 2/42 FUNZIONE QUALITÀ E SICUREZZA 1 Scopo e campo di applicazione Scopo del presente documento è fornire una panoramica dei pattern più comuni usati nella programmazione ad oggetti. Sebbene nel trattare i pattern ci si possa astrarre dal linguaggio di programmazione utilizzato, questo documento farà riferimento esplicito al loro impiego nel linguaggio Java e, più in particolare, nella tecnologia j2ee. Come conseguenza, essendo il tema trattato di natura prettamente tecnica, ovvero corredato nella sua esposizione da diagrammi, codici d’esempio, scenari comuni e casi reali, si ritiene necessario che il lettore possieda una buona conoscenza dei principi dell'object-orientation e della programmazione in Java. Un pò di pratica di programmazione è di sicuro aiuto perché affrontare i pattern avendo già una esperienza implementativa permette di riconoscerli più facilmente. 2 Riferimenti 2.1 Controllo del Documento: Stato delle revisioni Vers. Descrizione delle modifiche apportate nella revisione alla versione precedente Cap. modificati 2 Revisione Logo Aziendale N.A. 2.2 Documenti esterni • NORMA UNI EN ISO 9001:2008 - Sistemi di gestione per la qualità – Requisiti; • NORMA UNI EN ISO 9004:2000 - Sistemi di gestione per la qualità - Linee guida per il miglioramento delle prestazioni; • NORMA UNI EN ISO 9000:2005 - Sistemi di gestione per la qualità – Fondamenti e terminologia • A Pattern Language: Towns, Buildings, Construction [C. Alexander; Oxford University Press; 1977] • Design Patterns, Elements of Reusable Object-Oriented Software [E. Gamma, R. Helm, R. Johnson, J. Vlissides (Gang Of Four - GOF); Addison Wesley; 1995] • A System of Patterns [F. Bushmann, R. Meunier, H. Rohnert, P. Sommerlad, M. Stal (Gang of Five); John Wiley & Sons; 1996] • Nota Informativa - Design Patterns e Idiomi Java [E. Grasso, 1998] • The Design Patterns Java Companion [J. W. Cooper; Addison Wesley; 1998] • Advanced JavaServer Pages [D.M.Geary; Prentice Hall PTR; 2001] • EJB™ Design Patterns - Advanced Patterns, Processes, and Idioms [F. Marinescu; John Wiley & Sons; 2002] • J2EE Design Patterns [W. Crawford, J. Kaplan; O'Reilly; 2003] 2.3 Documenti interni Manuale della Qualità ACI Informatica; Sistema di Gestione per la Qualità vigente. Guida Metodologica Linee Guida Naming & Coding Conventions per Java Guida Metodologica Java Best Practices 2.4 Termini e Definizioni Per i termini, sigle e acronimi contenuti in questo documento si fa riferimento al Glossario dei termini utilizzati nel Sistema Qualità. Framework software che provvede ad uno strato di isolamento tra le applicazioni e le specifiche implementazioni di risorse o servizi al di sotto di esse. Idioma Un idioma è un soluzione di basso livello che esprime un dettaglio implementativo di un componente in relazione ad un determinato linguaggio ed alle sue caratteristiche. Un esempio può essere preso dalla programmazione Java dove uno degli idiomi più usati è il ciclo: Esempio 1 for (i=0; i<max; i++) { … //do something } Libreria Traduzione del temine inglese library . Il termine identifica in generale un insieme di funzioni, procedure o servizi a disposizione dell'utente, solitamente nelle vesti di programmatore. A grandi linee, le library possono essere classificate a seconda della tipologia di binding (ovvero la modalità con cui vengono "attaccate" al Programma che le utilizza) in dinamiche o statiche . Guida Metodologica Pattern Architetturali Java SQC609006 VER. 2 Pag. 3/42 FUNZIONE QUALITÀ E SICUREZZA 3 Introduzione La fase di progettazione di un sistema software è un’attività cruciale che si interpone tra la fase di analisi e quella di implementazione. Durante la fase di progettazione viene approfondito e specializzato quanto prodotto dalla precedente fase di analisi per avvicinarsi a quanto utile e specifico alla successiva fase d implementazione. E’ per questo che non è raro che la fase di progettazione introduca, rispetto ai modelli iniziali dell’analisi, nuovi oggetti, nuove responsabilità, nuove relazioni e nuove regole di collaborazione. Non che si tratti, ovviamente, di uno stravolgimento strutturale o di una decisa correzione di rotta. Fattori riconducibili a decisioni di quel tipo, del resto, dovrebbero piuttosto comportare una ripartenza o una iterazione dell’intero processo dalle sue fasi iniziali. Piuttosto si tratta dell’evoluzione del sistema dalla sua idea in astratto alla sua applicazione nel concreto, ovvero della necessità di calare la struttura ed il funzionamento teorico del sistema verso la realtà pratica dei linguaggi, delle tecnologie, degli ambienti operativi che saranno il target dell’implementazione Fare una buona progettazione ha, per questo, molto a che vedere con l’esperienza e la conoscenza pratica. In effetti, molto del lavoro di un buon progettista è fondato sulla conoscenza pratica acquisita, cioè sull’uso di soluzioni sperimentate con successo nel passato per risolvere problemi simili. In altre parole, un progettista esperto, avendo maturato la conoscenza di molteplici scenari e soluzioni ed avendo da questi fatti suoi gli elementi di invarianza distintivi di alcune classi di problemi, è in grado di riconoscere, nello specifico di ogni sistema, la possibilità e lo spazio per l’applicazione di modelli (o pattern) di soluzioni noti. La parola “pattern”, in effetti, ha un significato molto più generale dell’italiano ‘modello’ o ‘campione’; nel contesto in esame, comunque, esso indica in qualche maniera una situazione o una problematica nota per cui si ha a disposizione almeno un approccio risolutivo. Il concetto di pattern è un concetto ingegneristico ma non necessariamente informatico. Tanto è vero che la prima definizione di patterrn, risalente al 1977, si deve a Christofer Alexander che la applicò nel campo dell’ingegneria civile. Nonostante ciò la definizione data da Alexander è ancora valida ed è applicabile senza nessuna variazione all’ingegneria informatica. Infatti, secondo Alexander: Definizione 1 Each pattern describes a problem which occurs over and over again in our environment, and then describes the core of the solution to this problem in such a way that you can use this solution a million times over, without ever doing it the same way twice. Quindi un pattern serve a risolvere un problema ricorrente documentando una soluzione provata con successo diverse volte. I pattern non hanno la pretesa di inventare nulla. Sono solo una descrizione di pratiche di buon senso che normalmente si imparano dopo lunghi tirocini di esperienza. Un pattern non è inventato, ma riconosciuto, estrapolato e classificato. Il processo è induttivo: se mi accorgo di usare una certa soluzione per risolvere problemi simili, questa soluzione può essere analizzata, estrapolata dal contesto per renderla astratta e più facilmente applicabile in altri domini, e infine catalogata, indicando nome, problema, soluzione e conseguenze. In questo processo di astrazione, la descrizione del pattern diventa sufficientemente generica perché rappresenti la soluzione a una famiglia di problemi. Un pattern funziona come uno stampo in cui le sue componenti sono istanziate nei vari casi concreti. Guida Metodologica Pattern Architetturali Java SQC609006 VER. 2 Pag. 4/42 FUNZIONE QUALITÀ E SICUREZZA 4 Design pattern Tra i primi ad applicare il concetto di pattern al design a oggetti individuandone i più importanti sono stati Gamma, Helm, Johnson, Vlissides (detti GOF = Gang Of Four) con il libro “Design Patterns, Elements of Reusable Object-Oriented Software”, considerato la “bibbia” dei pattern. Il libro di Gamma e soci è soprattutto un catalogo di 23 pattern, ciascuno descritto sottolineando quattro elementi essenziali: 1. Nome . Sembra ovvio, ma dare nomi indicativi ai pattern è molto importante. Un nome è un modo immediato e veloce per individuare un problema di design. Avere questi nomi nel proprio vocabolario permette di comunicare con altri designer passando complesse soluzioni di design con il semplice scambio di una parola. Dire “qui ho usato il Singleton perché dovevo essere sicuro che la risorsa fosse allocata una sola volta” comunica immediatamente la soluzione al problema e il problema stesso. 2. Problema . Per definizione un pattern serve per risolvere un problema. 3. Soluzione . Descrive la struttura del pattern: gli elementi partecipanti e le forme di collaborazione e interazione tra questi.