Ingegneria del software: dai requisiti all'architettura.

Transcript

1 Ingegneria del software: dai requisiti all'architettura

2 Bologna: Omid Ehsani Solution Lightcode S.r.l. (

3 Pisa: Lorenzo Barbieri Solution ObjectWay S.p.a. ( Co-fondatore del Gruppo Italiano Utenti Solution Architect (GUISA

4 Trento: Andrea Saltarello Solution Managed Designs S.r.l. ( Presidente dello User Group Italiano.NET (UGIdotNET Co-fondatore del Gruppo Italiano Utenti Solution Architect (GUISA

5 Agenda Solution Architecture Overview Principi di Analisi Modellare la soluzione: da UML ai Domain Specific Languages Break Domain Model e architetture layered Pranzo Progettare Data Access Layer User Interface Architecture Break Architetture real world Q&A

6 Solution Architecture Overview Andrea Saltarello Solution Managed Designs S.r.l. (

7 Cosa è l Architettura? Secondo la definizione ANSI/IEEE Std : L organizzazione basilare di un sistema, rappresentato dalle sue componenti, dalle relazioni che esistono tra di loro e con l ambiente circostante, e dai principi che governano la sua progettazione e evoluzione."

8 Architettura: cosa? L architettura di un sistema *è* definita durante la fase di progettazione. L architettura *non è* parte dell analisi: l analisi si concentra su cosa deve fare il sistema La progettazione si concentra su come esso debba farlo

9 L architetto: Architetto: le responsabilità Recepisce i requisiti funzionali (emersi durante l analisi) e quelli non funzionali (es: availability, scalabilità, security ) Effettua una analisi del rapporto costi/benefici per determinare il miglior modo di soddisfare i requisiti, eventualmente ricorrendo a componenti commerciali o comunque già sviluppati Suddivide i grandi sistemi in (layer di) sottosistemi individualmente assegnabili ad uno sviluppatore o ad un gruppo di lavoro Genera specifiche : sketch, modelli o prototipi per comunicare al gruppo di lavoro le modalità di realizzazione

10 Architettura: luoghi comuni Architetto!= Analista Architetto!= Project Manager Architettura!= Design Al limite Design Architettura Architetto : Developer

11 Principi di Analisi Lorenzo Barbieri Solution ObjectWay S.p.a. (

12 Requisito: una definizione 1. Condizione o capacità che occorre all utente per risolvere un problema o raggiungere un obiettivo 2. Condizione o capacità che deve essere raggiunta o posseduta dal sistema per soddisfare un contratto, standard, specifica o altro documento formale 3. La rappresentazione documentata di una condizione o capacità (1 o 2)

13 Requisiti: la teoria La norma ISO9126, pubblicata nella sua prima versione nel 1991, ha definito il modello dei requisiti qualitativi del software. Secondo tale modello i requisiti sono raggruppabili in 6 "caratteristiche" e in 21 "sottocaratteristiche, distinte fra caratteristiche esterne (orientate all utente) e caratteristiche interne (orientate allo sviluppo e manutenzione).

14 Requisiti: Caratteristiche Funzionalità Disponibilità Usabilità Efficienza Manutenibilità Portabilità Idoneità Maturità Comprensione Tempo Risposta Analizzabilità Adattabilità Accuratezza Tolleranza Apprendimento Utilizzo Risorse Modificabilità Installabilità Interoperabilità Recupero Utilizzabilità Stabilità Coesistenza Sicurezza Attrattiva Collaudabilità Sostituibilità Concordanza Funzionali Non Funzionali

15 Recepire i requisiti La mancanza di requisiti o la mancanza della loro gestione sono tra le cause principali del fallimento dei progetti Recepire i requisiti significa circoscrivere il problema Non sempre è semplice definire i confini di un sistema. Per chiarire meglio i confini può essere utile introdurre il concetto di Attore

16 Attori Un attore è un umano, una macchina o un altro sistema Un attore usa il sistema o è coinvolto durante l uso del sistema (ha una interazione diretta col sistema) Gli attori non sono parte del nostro sistema

17 Casi d uso: introduzione Storie di uso del sistema, user stories Ogni caso d uso è una collezione di scenari di uso Ogni caso d uso è scatenato da almeno un attore Ogni caso d uso descrive: tutti i possibili di modi (scenari) per ottenere un preciso valore o obiettivo per un particolare attore tutte le eccezioni che non permettono di ottenere il valore o l obiettivo Lo stile con cui è scritto varia dall informale/romanzato al formale/pseudocodice deve essere comprensibile al target (in questa fase lo stakeholder)

18 Casi d uso: utilità Rappresentazione grafica sintetica Identificare chi interagisce col sistema Identificare quali interfacce il sistema avrà e verso chi Accordarsi col cliente sulle macrofunzionalità (feature) Raggruppare le feature per attore (obiettivi di ciascun attore) Aiutare a verificare che non si stiano tralasciando feature

19 Requisiti Utente vs. Requisiti Software I Requisiti Utente che abbiamo visto fino ad adesso sono definiti dall utente (li scriviamo attraverso il processo di elicitazione) I Requisiti Software servono per descrivere in maniera completa il sistema. Un Requisito Software: descrive un comportamento del sistema soddisfa un bisogno dell utente, un vincolo, uno standard, etc...

20 Software Requirements Specifications Una SRS deve essere leggibile da: Stakeholder, committenti, etc... (è la base del contratto) Team di progetto (è la base dell analisi, dell architettura e del design) Team di test Team che prepara la documentazione In pratica tutti i soggetti coinvolti nel progetto

21 Specificare i requisiti funzionali tramite Use Case In questa fase gli Use Case saranno molto più dettagliati di quelli usati (opzionalmente) nella fase precedente. Uno use case: è un completo e significativo flusso di interazioni fra attori e sistema è iniziato da un attore che richiama una certa funzionalità del sistema, che reagisce per fornire qualcosa di valore all attore L insieme di tutti gli use case definisce tutti i modi possibili di usare il sistema

22 Cosa non deve contenere una SRS? Design - Come soddisfare i requisiti Test - Come sapere se i requisiti sono stati soddisfatti Piani di progetto Quando e come i requisiti saranno implementati

23 Architettura: esprimere il modello I modelli permettono di rappresentare formalmente un sistema. Tipicamente, è di grande aiuto avvalersi di un formalismo per la modellazione. Lo standard de iure (ma anche de facto) per la modellazione è UML (Unified Modeling Language)

24 Introduzione a Unified Modeling Language Riccardo Golia Solution Architect

25 Agenda Introduzione I tre approcci di UML Classificazione dei diagrammi Diagramma dei casi d uso Diagramma delle classi Diagramma di sequenza

26 Cosa è UML UML (Unified Modeling Language) è una famiglia di notazioni grafiche basate su meta-modello per la descrizione e la rappresentazione di un sistema software basato sul paradigma orientato agli oggetti (Object-Oriented). Notazione: insieme di elementi grafici aggregati a formare diversi diagrammi, ciascuno dedicato a descrivere un diverso aspetto del sistema software. Meta-modello: schema che definisce i concetti stessi di UML al fine di aumentarne il rigore formale per rendere possibile la trasformazione delle notazioni in codice sorgente e viceversa.

27 I tre approcci di UML UML introduce un livello di astrazione maggiore rispetto ai linguaggi di programmazione per agevolare la discussione sulle scelte di design. La sua adozione avviene tipicamente con uno dei seguenti approcci: UML come abbozzo (sketch) Documentazione, discussione e condivisione delle idee Basso rigore formale Selettività: focalizzazione solo su alcuni aspetti dell applicazione Bassa, se non nessuna dipendenza dal tool di modellazione UML come progetto (blueprint) Completezza Alto rigore formale Forward e reverse (round-trip) engineering Forte dipendenza dal tool di modellazione UML come linguaggio di programmazione Diagrammi compilabili No forward e reverse engineering Fortissima dipendenza dal tool di modellazione

28 UML come abbozzo

29 UML come progetto

30 UML come linguaggio

31 Classificazione dei diagrammi 1/2 Diagrammi strutturali: Diagramma delle classi Diagramma degli oggetti Diagramma di deployment Diagramma dei package Diagramma dei componenti Diagramma di struttura composita [*] [*] Novità di UML 2.0

32 Classificazione dei diagrammi 2/2 Diagrammi comportamentali: Diagramma dei casi d uso Diagramma di interazione: Diagramma di sequenza Diagramma di comunicazione Diagramma di interazione generale [*] Diagramma di temporizzazione [*] Diagramma di macchina a stati Diagramma delle attività [*] Novità di UML 2.0

33 Diagramma dei casi d uso 1/5 E un diagramma comportamentale. Serve per identificare i requisiti funzionali di un sistema tramite la descrizione delle interazioni del sistema stesso con le entità ad esso esterne. Uno scenario è una sequenza di passi che caratterizzano una particolare interazione col sistema. Ciascun caso d uso rappresenta un insieme di scenari che hanno tra loro in comune lo scopo finale dell interazione. I diagrammi dei casi d uso sono alla base della definizione delle caratteristiche funzionali di un sistema software.

34 Diagramma dei casi d uso 2/5 Sistema Parte dell applicazione che svolge una funzione specifica. Attore Rappresenta qualcosa o qualcuno che interagisce col sistema. Caso d uso Azione intrapresa da un attore nell ambito del sistema. Relazione Collega gli attori ai casi d uso, oppure attori e casi d uso tra loro stessi: relazione di associazione (tra attori e casi d uso) relazione di inclusione (tra casi d uso) relazione di estensione (tra casi d uso) relazione di generalizzazione (tra casi d uso e tra attori)

35 Diagramma dei casi d uso 3/5 Relazione di associazione Attore Relazione di inclusione Relazione di estensione Relazione di generalizzazione Casi d uso

36 Diagramma dei casi d uso 4/5 Relazione di inclusione: il caso d uso è esteso obbligatoriamente dal caso d uso a cui è collegato. Relazione di estensione: il caso d uso è esteso facoltativamente dal caso d uso che gli è collegato. Si noti il senso della freccia invertito.

37 Diagramma dei casi d uso 5/5 Compilazione di un ordine Per compilare un ordine, il cliente deve poter associare ad esso i suoi dati reperibili in funzione del codice cliente o del nominativo, e i dati del prodotto reperibili tramite il codice dell articolo, la descrizione o la categoria merceologica. Il sistema deve calcolare il prezzo del prodotto in funzione di eventuali sconti associati al cliente e verificare la disponibilità a magazzino dell articolo richiesto.

38 Diagramma delle classi 1/5 E il diagramma più conosciuto ed usato. E un diagramma strutturale, statico. Descrive la struttura delle classi che compongono il sistema software e identifica le relazioni statiche esistenti tra le classi stesse. Permette di individuare le dipendenze tra le classi.

39 Diagramma delle classi 2/5 Classi: Nome (fully-qualified: package::nome_classe) Attributi: visibilità nome : tipo molteplicità = default {proprietà} Operazioni: visibilità nome ([direzione nome : tipo = default]*) : tipo di ritorno {proprietà} Visibilità delle caratteristiche: + public, private, # protected, ~ package Caratteristiche statiche Associazioni semplici e associazioni bidirezionali Classi di associazione Molteplicità Generalizzazioni Aggregazione e composizione Dipendenze Note e vincoli Interfacce e classi astratte Classi parametriche Enumerazioni

40 Diagramma delle classi 3/5 Interfaccia Interfaccia Attributi Operazioni Nota Vincolo Generalizzazione Composizione Dipendenza Associazione Classe Molteplicità

41 Diagramma delle classi 4/5 Aggregazione Rappresenta la relazione fra un aggregato e le sue parti costitutive, dove ciascuna parte può esistere indipendentemente dall aggregato. Composizione Rappresenta la relazione fra un aggregato e le sue parti costitutive, dove ciascuna parte non può esistere senza la classe complessiva. Le parti per esistere necessitano della classe intera, la cui distruzione comporta a cascata la distruzione delle sue parti.

42 Classi astratte Caratteristiche statiche Diagramma delle classi 5/5 Classi parametriche Enumerazioni

43 Diagramma di sequenza 1/5 E un diagramma comportamentale, di interazione dinamica. E il diagramma di interazione più usato. Descrive la collaborazione di un insieme di oggetti che collettivamente hanno l onere di implementare un determinato comportamento. Documenta generalmente il comportamento di un singolo scenario. Include gli oggetti e i messaggi scambiati tra di essi durante l esecuzione di un caso d uso particolare.

44 Diagramma di sequenza 2/5 Partecipante Un oggetto attivo o una entità che partecipa allo scenario descritto dal diagramma di sequenza. Messaggio Sincrono (in genere una chiamata a funzione): l oggetto chiamante rimane in attesa che l esecuzione della funzione invocata sia terminata prima di procedere. Simbolo: Asincrono: non c è bisogno di aspettare la risposta per procedere nella computazione. Simbolo: Ritorno: rappresenta il valore ritornato in seguito all invocazione di una funzione. Simbolo:

45 Diagramma di sequenza 3/5 Found message Partecipanti Attivazione Linea di vita Messaggi sincroni Messaggio di ritorno

46 Diagramma di sequenza 4/5 Creazione di partecipanti Distruzione di partecipanti Chiamata interna

47 Diagramma di sequenza 5/5 Cicli e condizioni: loop: ciclo alt: condizione (if then else) opt: condizione (if then)

48 Sequenza vs Comunicazione

49 Introduzione ai Domain Specific Languages Omid Ehsani Solution Lightcode S.r.l. (

50 Da UML a DSL 1/3 UML è eccellente per abbozzare, progettare, comunicare, documentare E universalmente conosciuto Può descrivere molti aspetti del software Può essere utilizzato a vari livelli: dal più astratto al più dettagliato La tentazione di utilizzarlo per progettare sviluppare documentare in un solo colpo è molto forte... come il lato oscuro della forza!!! Ma...

51 Da UML a DSL 2/3... Ma gli innumerevoli tentativi di sviluppare con UML hanno lasciato sul campo molte vittime Mantenere i modelli aggiornati è estremamente oneroso Quando i modelli non rispecchiano più il codice non servono più a nulla! Tool costosi e spesso non integrati o all altezza delle aspettative Spesso invece che descrivere logiche complesse con i formalismi visuali si fa prima a scrivere codice!... E soprattutto UML descrive il dominio del problema in termini generici: Ampio raggio di utilizzo, ma non adatto ad automatismi

52 Da UML a DSL 3/3 I DSL (Domain Specific Language) invece hanno l obiettivo, e l ambizione, di trasformare i modelli nel prodotto finale Legati ad un dominio specifico e molto ristretto Basati su modelli, generalmente visuali Alto livello di astrazione Estremamente produttivi, facili da utilizzare Generano / Sono il prodotto finale

53 DSL: La tariffazione telefonica Call Record base rate: /s call length call store friend discount rate: /s calendar month friends calls other calls call length store bill billing period

54 Software Factories Un modello organizzativo per industrializzare lo sviluppo del software Linee di produzione Guida contestuale Frameworks, tools, assets MDD (Model Driven Development) => DSL

55 Object Oriented Design Andrea Saltarello Solution Managed Designs S.r.l. (

56 Object Oriented Design overview Come procedere? Secondo l autorevole Gangs of Four : You must find pertinent objects, factor them into classes at the right granularity, define class interfaces and inheritance hierarchies, and estabilish key relationships among them. In pratica, dobbiamo rielaborare il frutto dell analisi tenendo in considerazione le possibilità offerte dall orientamento all oggetto.

57 Diagramma dei casi d uso: un esempio Gestione vendite Internet Client Recupero Ordini Cliente Aggiungi Cliente Database Agente di televendita Rimuovi Cliente

58 OOD: dagli Use Case alle Classi La descrizione dei casi d uso è alla base del design delle classi Sostantivi = classi o attributi A user requests the orders for a customer by using a particular customer ID. The ID is validated by the database, and an error message is displayed if the customer does not exist. If the ID matches a customer, the customer s name, address, and date of birth are retrieved, in addition to any outstanding orders for the customer. Details about each order are retrieved, including the ID, the date, and the individual order items that make up an order. Verbi = operazioni (metodi) Esempi: ValidateCustomer, RetrieveOrders, RetrieveOrderItems

59 Object Oriented Design overview (Reloaded) Possiamo migliorare la struttura statica applicandovi dei design pattern

60 Design Patterns Defined "Each pattern describes a problem which occurs over and over again in our environment, and then describes the core solution to that problem, in such a way that you can use the solution a million times over, without ever doing it the same way twice. Christopher Alexander A Pattern Language, 1977

61 OOD: Design Patterns I pattern costituiscono soluzioni sperimentate a problemi concreti, utilizzabili in contesti applicativi differenti. Possiamo pensare ad un pattern come alla descrizione di un problema comune e di una soluzione generalmente applicabile, fattorizzati in maniera elegante....oppure ancora... Possiamo pensare ai pattern come ad un gergo evoluto per trasmettere idee e comprendere i problemi e le soluzioni in modo più efficiente.

62 Design Patterns unleashed Il Testo di riferimento è: Design Patterns: Elements of Reusable Object-Oriented Software di Erich Gamma, Richard Helm, Ralph Johnson e John Vlissides Sono loro la Gang of Four... da cui [GoF]

63 Design Patterns applied I design pattern ci aiutano a risolvere problemi di tutti i giorni. Esempi: Ricordate VB6? La default instance si ottiene con Singleton Conoscete ADO.NET? La dipendenza dal provider si elimina con Factory Method

64 Design Patterns applied: Factory method Problema: Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.

65 Design Patterns: il verbo? I pattern sono: Le Sacre Scritture? L A-Team? Oppure La Forza?

66 Dice il saggio Non dobbiamo pensare ai pattern come a dogmi, bensì come alle centurie di Nostradamus: vanno interpretati

67 Pattern vs. Idiomi Un pattern insiste sul paradigma, è un modello, un esempio generico Un idioma insiste sulla tecnologia, è una soluzione specifica ad un linguaggio Ad esempio: Observer vs. delegate/eventi Iterator vs. IEnumerator

68 Idiomatic Design Un design idiomatico rinuncia alla genericità della soluzione basata su pattern a favore di una implementazione basata sulle caratteristiche della tecnologia disponibile

69 Design idiomatico vs..net Classi o strutture? Strutture se il tipo è immutabile ed ha un footprint <= 16 bytes Classi se il footprint è > 16 bytes e/o avete bisogno di ereditarietà Non usare List nelle API pubbliche, preferendo: IList System.Collections.ObjectModel.Collection<T>

70 Application Modeling Andrea Saltarello Solution Managed Designs S.r.l. (

71 Agenda Overview dei pattern architetturali Transaction Script Table Module Active Record Domain Model Service Layer

72 Pattern Architetturali Esistono alcune blueprint utilizzabili per definire l architettura di base di una applicazione: sono pattern architetturali la cui grana è più grossa dei comuni design pattern

73 Transaction Script [P of EAA, 110] Organizes business logic by procedures where each procedure handles a single request from the presentation. Most business applications can be thought of as a series of transactions. A transaction may view some information as organized in a particular way, another will make changes to it. Each interaction between a client system and a server system contains a certain amount of logic. In some cases this can be as simple as displaying information in the database. In others it may involve many steps of validations and calculations. A Transaction Script organizes all this logic primarily as a single procedure, making calls directly to the database or through a thin database wrapper. Each transaction will have its own Transaction Script, although common subtasks can be broken into subprocedures.

74 Transaction Script In pratica In pratica: significa implementare una funzione per ogni operazione atomica Logica procedurale infilata dentro una applicazione basata su toolkit OO

75 Transaction Script : pro & contro Pro: Bassa difficoltà di implementazione Contro: Prono a duplicazione del codice

76 Table Module [P of EAA, 125] A Table Module organizes domain logic with one class per table in the data-base, and a single instance of a class contains the various procedures that will act on the data. The primary distinction with Domain Model (116) is that, if you have many orders, a Domain Model (116) will have one order object per order while a Table Module will have one object to handle all orders.

77 Table Module In pratica Le parole DataTable e incapsulamento vi suggeriscono qualcosa?

78 Table Module : Pro & Contro Pro: Built-in in ADO.NET, e ben supportato da Visual Studio (Typed Dataset) Un solo Table Module per differenti data source Contro: Non ha il concetto di identità degli oggetti Poco OO

79 Active Record [P of EAA, 160] An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data. An object carries both data and behavior. Much of this data is persistent and needs to be stored in a database. Active Record uses the most obvious approach, putting data access logic in the domain object. This way all people know how to read and write their data to and from the database.

80 Active Record In pratica Una entità per ogni tabella Le entità hanno struttura analoga a quelle delle tabelle del database Le entità contengono la logica di persistenza Le entità contengono logica di dominio It's often hard to tell the difference between a Row Data Gateway and an Active Record. The crux of the matter is whether there's any domain logic present, if so you have an Active Record. A Row Data Gateway should contain only database access logic, and no domain logic. (cit.)

81 Active Record: Pro e Contro Pro: (Relativamente) Semplice da implementare Toolkit che lo supportano/supporteranno (Castle Project, LINQ to SQL) Contro: Fortemente accoppiato allo schema del database

82 Domain Model pattern [P of EAA, 116] An object model of the domain that incorporates both behavior and data. At its worst business logic can be very complex. Rules and logic describe many different cases and slants of behavior, and it's this complexity that objects were designed to work with. A Domain Model creates a web of interconnected objects, where each object represents some meaningful individual, whether as large as a corporation or as small as a single line on an order form.

83 Domain Model In pratica La modellazione object oriented pura e requisite driven della realtà trattata dal dominio del problema Le entità contengono both data and behaviour

84 Domain Model : Pro & Contro Pro: Manutenibilità e flessibilità notevoli Massimo sfruttamento del paradigma OO Contro: La gestione della persistenza può rivelarsi onerosa In assenza di logiche complesse l onere di implementazione non è giustificato

85 Persistenza del Domain Model Il Domain Model rappresenta lo schema dati della nostra applicazione, ma prima o poi dobbiamo fare i conti con la gestione della persistenza dei dati, tipicamente affidata ad un Mapper

86 Data Mapper [P of EAA, 165] A layer of Mappers (473) that moves data between objects and a database while keeping them independent of each other and the mapper itself. The Data Mapper is a layer of software that separates the in-memory objects from the database. Its responsibility is to transfer data between the two and also to isolate them from each other. With Data Mapper the in-memory objects needn't know even that there's a database present; they need no SQL interface code, and certainly no knowledge of the database schema. Since it's a form of Mapper, Data Mapper itself is even unknown to the domain layer.

87 Data Mapper In pratica Esistono delle classi CRUD sulla cui interfaccia appaiono le classi del Domain Model quali vettori dei dati, cioè: Accettano in ingresso istanze del Domain Model Restituiscono istanze del Domain Model

88 Domain Model anemici Un Domain Model è anemico quando viene privato (in parte) del proprio comportamento. Poiché può essere conveniente rendere Persistence Ignorant il Domain Model, ne consegue che l anemia non è una caratteristica on/off, bensì un indicatore

89 Service Layer [P of EAA, 133] Defines an application's boundary with a layer of services that establishes a set of available operations and coordinates the application's response in each operation. A Service Layer defines an application's boundary [Cockburn PloP] and its set of available operations from the perspective of interfacing client layers. It encapsulates the application's business logic, controlling transactions and coordinating responses in the implementation of its operations

90 Service Layer In pratica L approccio appena descritto è spesso definito SOA (Service Oriented Architecture) Quando implementiamo una SOA, i servizi fungono da Remote Facade [P of EAA, 388] verso la business logic da essi incapsulata, quindi: interfacce CRUDy non sono SOA gli oggetti veicolati sono dei semplici DTO Il servizio non implementa la business logic, bensì la usa (ad esempio, scriptando il Domain Model [P of EAA, 116])

91 Ricapitolando In ottica SOA, i servizi: non distribuiscono oggetti, bensì messaggi: il servizio ed il consumer concordano sul contratto da essi definito sono autonomi, e fungono da remote facade verso business logic ad essi locale Se dobbiamo distribuire oggetti,.net offre una *vera* tecnologia ORB: si chiama Remoting e può essere utilizzato anche con http

92 Architettura: un esempio Ipotizziamo una applicazione enterprise con i soliti requisiti: DB-independent (tecnologia e struttura) GUI-independent (almeno Win e Web)

93 Applicazioni Enterprise I più penseranno che siano le applicazioni che usano i computer che appaiono in Star Trek, ma secondo Fowler sono: Applicazioni che usano e consumano una considerevole mole di dati, applicandovi logiche complesse e variabili nel tempo (libera cit. da [P of EAA], N.d.T.)

94 Enterprise application design Per soddisfare i requisiti, optiamo per una architettura stratificata su 3 livelli: presentation, business, data Concentrare la logica applicativa nel business layer facilita l implementazione di GUI eterogenee Isolare l accesso ai dati in un DAL (Data Access Layer) permette di disaccoppiare la business logic dal DB

95 Responsabilità 3-layer Architecure Costruzione delle View Binding View/Entity Tiene solitamente lo stato dell applicazione Tiene la logica di flusso tra View

96 Responsabilità 3-layer Architecure Servizi Applicativi Regole di Business Gestione dello stato delle Entity

97 Responsabilità 3-layer Architecure Logica di Accesso al Database Richiamo di Stored Proc su DB Restituzione di DTO, DataReader, DataSet

98 Data Access Layer Andrea Saltarello Solution Managed Designs S.r.l. ( Giancarlo Sudano Solution ObjectWay S.p.a. (

99 Disegno di un DAL Requisiti del nostro DAL: Indipendenza dallo schema fisico Indipendenza dal DBMS Configurabile come plug-in

100 Business layer vs. Data layer La nostra applicazione disporrà di un DAL specifico per ogni DBMS supportato; definiremo quindi l API che sarà implementata da ogni DAL La business logic riceverà un riferimento al DAL corrente, che sarà creato da una factory Per assicurare l indipendenza dalla struttura del DB, il business layer e il DAL comunicheranno utilizzando esclusivamente istanze di business entities o DTO

101 Architettura del DAL Separiamo la definizione del DAL dalla sua implementazione mediante il pattern Separated Interface [P of EAA, 476] Il business layer riceverà un riferimento al DAL corrente, che sarà creato da una Abstract Factory [GoF, 87]

102 Separated Interface pattern [P of EAA, 476] Defines an interface in a separate package from its implementation. As you develop a system, you can improve the quality of its design by reducing the coupling between the system's parts. A good way to do this is to group the classes into packages and control the dependencies between them This way a client that needs the dependency to the interface can be completely unaware of the implementation. The Separated Interface provides a good plug point for Gateway

103 Abstract Factory pattern Creates an instance of several families of classes Provide an interface for creating families of related or dependent objects without specifying their concrete classes.

104 Unit of Work [P of EAA, 184] When you're pulling data in and out of a database, it's important to keep track of what you've changed. Similarly you have to insert new objects you create and remove any objects you delete. A Unit of Work keeps track of everything you do during a business transaction that can affect the database.

105 Template Method [GoF, 325] Define the skeleton of an algorithm in an operation, deferring some steps to subclasses. Template Method lets subclasses redefine certain steps of an algorithm without changing the algorithm's structure.

106 Query Object [P of EAA, 316] An object that represents a database query. A Query Object is an interpreter [GoF], that is, a structure of objects that can form itself into a SQL query. You can create this query by referring to classes and fields rather than tables and columns. In this way those who write the queries can do so independently of the database schema and changes to the schema can be localized in a single place.

107 Identity Map [GoF, 195] Ensures that each object gets loaded only once by keeping every loaded object in a map. Looks up objects using the map when referring to them

108 DAL: Advanced Features Poiché disaccoppiato dalla applicazione, il DAL può implementare varie strategie di ottimizzazione dell accesso ai dati, tra le quali: Lazy load Gestione del lock

109 Lazy Load pattern [P of EAA, 200] An object that doesn't contain all of the data you need but knows how to get it. For loading data from a database into memory it's handy to design things so that as you load an object of interest you also load the objects that are related to it. ( ) A Lazy Load interrupts this loading process for the moment, leaving a marker in the object structure so that if the data is needed it can be loaded only when it is used. As many people know, if you're lazy about doing things you'll win when it turns out you don't need to do them at all.

110 Optimistic Offline Lock [P of EAA, 416] Prevents conflicts between concurrent business transactions by detecting a conflict and rolling back the transaction. Data integrity is at risk once two sessions begin to work on the same records and lost updates are quite possible. Also, with one session editing data that another is reading an inconsistent read becomes likely. ( ) Optimistic Offline Lock solves this problem by validating that the changes about to be committed by one session don't conflict with the changes of another session.

111 Introduzione agli ORM Un Object Relational Mapper è un toolkit consistente in: Una API per eseguire operazioni CRUD Un linguaggio (o API) per la definizione di query operanti su classi e proprietà Una modalità di mapping di metadati (classi<->tabelle, proprietà<->colonne) Noi useremo NHibernate beta (3), porting del framework di persistenza Hibernate per Java

112 DAL: Object/Relational Mapping Se volessimo utilizzare ORM (es: NHibernate) potremmo usare il pattern Adapter [GoF, 139] per trasformarne l interfaccia in quella del DAL (Mapper / Table Data Gateway).

113 Adapter pattern [GoF, 87] Match interfaces of different classes Convert the interface of a class into another interface clients expect. Adapter lets classes work together that couldn't otherwise because of incompatible interfaces.

114 User Interface Architecture Corrado Cavalli Managed Designs S.r.l. (

115 Approccio alla user interface La UI è spesso snobbata E l architettura che conta Area meno nobile Ultima parte ad essere sviluppata Legata Visual Studio 2005 Mancanza di guidelines architetturali Design patterns vs UI?

116 Il problema Realizzare una UI la quale: Non vincoli il modello Possa essere sostituibile Rappresentazione grafica Tecnologia realizzativa (Win/Web/WPF, ) Supporti lo unit-testing

117 La soluzione Applicare i patterns alla UI! (no Transaction Script ) Abbandonare la modalità RAD di Visual Studio Usare VS come semplice designer Impoverire la UI Yes, more code

118 The patterns Model View Controller Model View Presenter Supervising Controller Passive View Presenter First

119 Actors Model Implementa le funzionalità di business E indipendente dal contesto di utilizzo View Implementa la logica di presentazione Rappresenta i dati esposti dal model Gestisce le interazioni con l utente Controller Implementa la logica di controllo Gestisce i comandi della View verso il model Può agire sulla view

120 MVC - Model View Controller Update state Set state Model Change view View Controller User action View e Controller conoscono Model Entrambi agiscono verso Model Model è indipendente da View e Controller

121 MVP - Supervising Controller Set state Model IView Update view View Presenter User action View è aggiornata via Databinding Nei casi complessi interviene il Presenter Le gestures sono delegate al Presenter

122 MVP Passive view Set state Model IView Update view View Presenter User action Solo Presenter conosce Model Solo Presenter agisce verso Model View è passiva (Passive View) Model è indipendente da Presenter

123 Presenter First IModel Set state Model IView Update view View Presenter User event Intercambiabilità di Model, View e Presenter Gli attori sono totalmente disaccoppiati

124 Vantaggi IView Presenter IModel Mock Object Mock Object Unit Testing tool Indipendenza della View Testing indipendente del Presenter

125 MVP Applied: Demo NSK Main Presenter Main Presenter Customers Presenter Customer Presenter Navigation Service Model

126 Bibliografia [GoF] Design Patterns: Elements of Reusable Object-Oriented Software, Erich gamma et al, Addison-Wesley [P of EAA] Pattern of Enterprise Application Architecture, Martin Fowler, Addison-Wesley [DDD] Domain Driven Design, Eric Evans, Addison-Wesley

127 Link: Active Record Pattern, Wikipedia: DomainSpecificLanguage, Bliki Martin Fowler: ml Domain-specific programming language, Wikipedia:

128 Link: GUISA: Wiki UGIdotNET: MSDN Architecture Center: rsemsdn/architetti/default.mspx

129 Credits Solution Architecture Overview: Andrea Saltarello [Managed Designs S.r.l.] Principi di Analisi: Lorenzo Barbieri [ObjectWay S.p.a.] Introduzione a UML Riccardo Golia Introduzione ai Domain Specific Languages Omid Ehsani [Lightcode S.r.l.] Domain Model e architetture layered Andrea Saltarello [Managed Designs S.r.l.] Progettare Data Access Layer Andrea Saltarello [Managed Designs S.r.l.] Giancarlo Sudano [ObjectWay S.p.a.] UI Architecture Corrado Cavalli [Managed Designs S.r.l.]

130 Q&A