# Processo Sviluppo Software
## Software Processes
### DevOps
DevOps rappresenta una "cultura" che promuove la collaborazione tra le parte di **development** e quella di **operation** per rilasciare codice alla produzione in modo veloce, automatico e ripetibile. Include:
- Continuous Development.
- Continuous Integration.
- Continuous Testing.
- Continuous Deployment.
- Continuous Monitorin.

**Ruoli DevOps**: DevOps evangelist, quality assurance, automation exprert, code release manager, security engineer, software developer/tester.

Solitamente sfrutta virtualizzazione e container. I principi principali sono: automatizzare tutto quello che è possibile automatizzare; Monitorare e testare tutto.
In Dev si svolgono: plan, code, build, test ed in ops release deploy, operate e monitor.
Le varie fasi possono essere stutturate all'interno di una pipeline, in questo modo build, test e deply possono essere articolare come in un workflow complesso ma automatico.
Si vuole rendere l'evoluzione in produzione incrementale sia per quanto riguarda:
- *user*: **Dark Launching**: studiare l'impatto di nuove funzionalità front end.
- *user*: **Canary Releases**: studiare l'impatto di un nuovo back end.
- *user*: **User experimentation**: capire se un nuovo sistema risulta migliore del precedente, per farlo vengono fatte usare ad utenti diversi le varie versioni e si monitorano i risultati.
- *requests* **Gradual upgrades**: rilasciare la versione aggiornata ad un numero sempre maggiore di utenti.
- *components* **Rolling update**: Aggiornare un componente di un sistema distribuito alla volta.
- *non incremental with backups* **Blue/Green deployment**: 2 setup hardware identici ed isolati, su uno si trova la versione vecchia e sull'altro quella nuova. Spostiamo il traffico sulla nuova versione ed in caso di malfunzionamento possiamo sempre rispostarlo sulla vecchia. Inoltre, una volta completati i test possiamo usare l'istanza con la vecchia versione per memorizzare una copia di quella nuova.
- *non incremental with backups* **Rainbow deployments**: generalizza il concetto green/blue per far coesistere più update sequienziali.

### Risk managment
Disciplina per l'identificazione e l'eliminazione dei rischi prima che diventino concrete minacce.
**Risk exposure**: $RE = P(UO) * L(UO)$: $UO$ rappresenta un unsatisfactory output, $P(UO)$ la probabilità che accada e $L(UO)$ l'eventuali perdite.
**Risk triggers**: evento che permette al rischio d'accadere: individuando i risk-triggers posso monitorarli in modo da poter lavorare alla prevenzione del rischio in caso tali triggers si verifichino.

Esistono 2 tipi di rischio:
1. **Process-related**: hanno un impatto negativo sugli obiettivi di sviluppo (ritardi, costi aggiuntivi ecc).
2. **Product-related**: hanno un impatto negativo sugli obiettivi funzionali/non funzionali del sistema (problemi di sicurezza ecc).

#### Come gestire i rischi:

1.**Risk Identification**: analizzo una lista dei rischi più frequenti, aggiuntivamente posso effettuare brainstormings o effettuare confronti con prodotti simili. In ogni caso non avrò mai la certezza di aver individuato tutti i rischi esistenti.

2.**Risk analysis**: individuare le probabilità che un rischio accada e quanti danni provocherebbe in caso accadesse. Tale procedura risulta prettamente empirica e l'esperienza è lo stumento principale. In questa fase potrebbe esser necessario prendere decisioni.

Posso utilizzare di **decision tree** per effettuare la scelta migliore

Inoltre posso ragionare su quali sono le cause di ogni rischio ed individuare le loro combinazioni. Posso infatti usare un **risk tree**: Una rappresentazione ad albero della relazione tra fallimenti, cause e conseguenze: 
Posso infine trovare un **cut-set** di tale albero, ossia un insieme di foglie la cui attivazione simultanea implica l'avvenimento della radice.

3.**Risk Prioritization**: Bisogna individuare i rischi sui quali concenetrarsi, risulta impossibile controllare tutti i rischi. Posso stimare $P(UO)$ e $L(UO)$ per ogni rischio e trattare i rischi che massimizzano questo valore. Rapprensentando ogni rischio in un grafico nel quale la $x$ rappresenta l'eventuale perdita mentre la $y$ la probabilità che accada allora mi devo concentrare sui punti che stanno in alto a destra.

4.**Risk Management Planning**: Per ogni rischio devo produrre un piccolo documento nel quale vengono discussi quali sono gli obiettivi, i relativi tempi, chi è responsabile di cosa, come affrontarlo ecc...
Anche in questo caso esistono delle liste per la gestione dei rischi più comuni.
Come scelgo quale misura attuare per affrontare un determinato rischio? **Risk Reduction Levarage**: $RRL(R, CM) = \frac{RE(R) - RE(R / CM)}{Cost(CM)}$.
Posso anche utilizzare **Defect Detection Prevention**:
1. Calcolare la matrice di impatto e calcolare:
- $Criticality(r) = P(r) \times \Sigma_{obj}{(W(obj) \times Impact(r, obj))}$
- $Loss(obj) = W(obj) \times \Sigma_{r}{(P(r) \times Impact(r, obj))}$
- 
2. Calcolare la matrice di efficacia delle contromisure:
- $combinedReduction(r) = 1 - \prod_{cm}(1 - Reduction(cm, r))$.
- $overallEffect(cm) = \Sigma_{r}(Reduction(cm, r) \times Criticality(r))$
- 

**Managment and Contingency Plan**: Management plan: include azioni per prevenire i risk-triggers. Contingency plan: include azioni da attura in caso il risk-trigger si sia attivato.

5.**Risk Monitoring/ Risk Resolution**:
- Risk monitoring: Monitoraggio del rischio. Impossibile monitorare attivamente tutti i rischi: Top-10 risk items tracking.
- Risk resolution: Attuare una strategia di risoluzione in caso si presenti il rischio.

### Capability Maturity Model Integration
La maturità del processo di sviluppo è descritta tramite un insieme di livelli di maturità e le relative metriche. **CMM**: collezioni di indicazioni per aiutara aziende a migliorare il loro processo di sviluppo. **Better Process = Better Product**.


Ci sono 22 process areas. CMMI valuta per ogni process area la qualità e la rappresenta tramite livelli.
**Capability level**: livello di abilità in un area specifica.
**Maturity level**: livello di process areas collegate tra loro

## Requirements Engineering

### Introduzione a Requirements Engineering

**Mondo:** Parte problematica del mondo reale, fatta da componenti umani(persone, organizzazioni) e componenti fisici(dispositivi ecc).
**Macchina:** Cosa deve essere installato per risolvere il problema.
**RE**: Insieme coordinato di attività per esplorare, valutare, documentare, consolidare, rivisitare, gli obiettivi, le capacità le qualità, i limiti, le assunzioni di un sistema software. RE si occupa di trattare gli effetti della macchina desiderati sul mondo, le assunzioni e le proprietà rilevanti del mondo in questione.
**System-as-is**: Sistema prima dell'implementazione della macchina.
**System-to-be**: Come dovrebbe essere il sistema una volta compiuta l'implementazione della macchina.
**System requirements**: Cosa dovrà fare il system-to-be formulato rispetto ai fenomeni nell'ambiente.
**Software requirements**: Cosa dovrà fare il software-to-be formulato in termini di fenomeni condivisi tra ambiente e software.
Esistono principalmente 2 catagorie di requisiti:
1. **Descrittivi**: requisiti di dominio non modificabili.
2. **Prescrittivi**: requisiti che possono essere rilassati o modificati.

**Modello a 4 variabili**: 
Vari requisiti:
- **Requisiti di sistema**:prescrittivi, $\subset C \times M$.
- **Requisiti software**: prescrittivi, $\subset I \times O$.
- **Proprietà di dominio**: descrittivi, $\subset C \times M$.
- **Assunzioni**: generalmente prescrittive, $\subset (O \times C \cup C \times M \cup M \times I)$.
- **Definizioni**: forniscono un significato preciso a concetti del sistema.
Possiamo dire che i requisiti software traducono i requisiti di sistema usando proprietà ed assunzioni.

I requisiti possono anche essere classificati in:
- **Funzionali**: dicono ciò che il software-to-be dovrebbe fornire.
- **Non funzionali**: dicono come il software-to-be dovrebbe funzionare(performance, sicurezza ecc).

Possibili qualità di un processo di analisi dei requisiti:
- Completezza (impossibile da raggiungere).
- Consistenza.
- Adeguatezza.
- Non ambiguità.
- Misurabilità.
- Pertinenza.
- Fattibilità.
- Comprensabilità.
- Buona Struttura.
- Modificabilità.
- Tracciabilità.
Processo di analisi dei requisiti:

### Elicitazione dei requisiti
Il primo passo consiste nell'identifacazione degli stakeholders. Per capire a fondo il dominio bisogna necessariamente individuare i portatori di interesse. Nella pratica bisogna interagire con essi in modo di discutere i punti chiave. Risulta fondamentale avere un rapporto di fiducia con i vari portatori di interesse. I 2 criteri principali per categorizzare gli stakeholders sono: il loro interesse ed il loro potere.

**Elicitazione dei requisiti**
**Artifact driven**:
- **Background Study**: Studio del dominio, dell'organizzazione(grafici, business plans, ...) e studio del system-as-is. L'obiettivo è la raccolta di dati e conoscenze fondamentali.
- *Vantaggi*: fornisce una buona base di partenza per l'interazione con gli stakeholders.
- *Svantaggi*: la documentazione potrebbe essere molto voluminosa, le informazioni utili devono essere estratte manualmente.
- **Questionari**: Consistono nell'inviare una lista di domande(principalmente a risposta chiusa) agli stakeholders. Le opzioni fornite sono spesso qualitative (likert'scale).
- *Vantaggi*: efficaci per raccogliere opinioni soggettive velocemente, economicamente in maniera remota.
- *Svantaggi:* Potrebbe essere "basato", ha una struttura rigida, potrebbero rispondere in pochi o rispondere poco seriamente.
- **Storyboard**: Hanno lo scopo di acquisire informazioni tramite esempi concreti. Raccontano una "storia" tramite una sequenza di snapshots(frasi, bozze, disegni). Possono essere attive o passive in base alla partecipazione dello stakeholder.
- **Scenari**: MOstrano sequenze di interazioni tipiche tra i vari componenti del sistema. Possono essere classficati come:
- Positivi: se rappresentano una situazione che il sistema deve considerare.
- Negativi: se rappresentano una situazioni che il sistema deve escludere.
- Normali: se rappresentano situazioni in cui tutto procede come atteso.
- Anormali: se rappresentano situazioni eccezionali (comunque positivi).
- *Vantaggi*: esempi/controesempi concreti. Buone dimostrazioni per gli stakeholders.
- *Svantaggi*: esiste un numero esponenziale di scenari, potenzialmente troppo specifi oppure potrebbero contenere informazioni non rilevanti.
- **Prototipi/Mockups**: Utili per ottenere un feedback immediato tramite bozze del software da implementare. Un prototipo rappresenta un'implementazione veloce di alcuni aspetti che verranno poi usati come basi del sistema mentre un mock up rappresenta una piccola rappresentazione ai soli fini dimostrativi.
- *Vantaggi*: forniscono una visualizzazione concreta del software-to-be.
- *Svantaggi*: il codice prodotto potrebbe essere difficile da riutilizzare, potrebbero essere fuorvianti.
- **Knowledge reuse**:Hanno l'obiettivo di velocizzere l'apprendimento delle conoscenze basandosi su esperienze con sistemi simili. 1 Ottenere informazioni da sistemi simili. 2 Adattare tali informazioni per il sistema corrente. 3 Validare i risultati ottenuti.
- *Vantaggi*: riduci gli sforzi per l'elicitazione, utile per completare i requisiti.
- *Svantaggi*: funziona solo nel raro caso in cui il sistema di riferimento assomiglia a quello in fase di sviluppo.

**Stakeholder-driven**:
- **Interviews**: Rappresenta la tecnica principale e consiste nel selezionare uno(o più) stakeholder al quale porre domande per registrarne le risposte. Le risposte vengono inserite in un report che viene poi inviato all'intervistato stesso per la validazione. Nel caso in cui fossero presenti più stakeholders contemporaneamente si risparmi tempo ma si da meno attenzione ad ognuno di loro. Le interviste possono essere strutturate o meno.
- **Osservazioni e studi etnografici**: Certi task sono difficili da spiegare a parole ma sono facili da visualizzare (allacciarsi le scarpe). Le osservazioni possono essere:
- Passive: non si interferisce con chi performa il task, si guarda da fuori.
- Attive: si partecipa attivamente al task.
- *Vantaggi*: potrebbero rivelare conoscenze/problemi nascosti. Le informazioni acquisite sono contestualizzate.
- *Svantaggi*: lenti e costosi, potenzialmente inaccurati, concentrati sul system-as-is.
- **Sessioni di gruppo**: simili alle interviste ma ci sono più interazioni con gruppi diversi, spesso vengono usati grafici o presentazioni. Possono essere stutturate(ogni partecipante ha un ruolo preciso) o non strutturate (i ruoli non sono specificati). Servono per generare idee e validarle.
- *Vantaggi*: viene fatta un'ampia esplorazione, vengono risolti conflitti.
- *Svantaggi*: la composizione dei gruppi risulta critica. Rischio di non avere una buona struttura e risultare in uno spreco di tempo.

#### Valutazione dei requisiti
Bisogna identificare ed eliminare possibili inconsistenze:
- **Terminology clash**: Un concetto con più nomi.
- **Designation clash**: Più concetti con un solo nome.
- **Structure clash**: Un concetto strutturato diversamente in più luoghi.
- **Strong conflict**: Più requisiti non soddisfacibili contemporaneamente.
- **Weak conflict**: Più requisiti non soddisfacibili contemporaneamente sotto certe condizioni.

Per eliminare gli errori dei primi 3 primi risulta necessario creare un dizionare dei termini.
Per gestire i conflitti:
Per trovare i conflitti posso usare una matrice di interazione: 
Per trovare soluzioni bisogna esplorare soluzioni diverse e confrontarle.
Per valutarle bisogna verificare il loro contributo a: funzioni non critiche, risoluzione di rischi.

**Priorità dei requisiti**: Per ogni requisito valuto quanto contribuisce rispetto al valore ed al costo. Costruisco 2 matrice di confronto, in ognuna il valore nella riga $i$, colonna $j$ confronta il contributo del requisito $i$ confrontato con il contributo del requisito $j$ e tale contributo può essere sia valutato sia sotto il punto di vista del costo sia sotto il punto di vista del valore.
Se $R[i]j[j]$ vale x significa che il contributo del requisito i rispetto a quello del requisito $j$ risulta, in base al valore di x:
- $x = 1$: equo.
- $x = 3$: leggermente maggiore.
- $x = 5$: molto maggiore.
- $x = 7$: estremamente maggiore.
- $x = 9$: totalmente maggiore.
Essendo il contributo simmetrico se $R[i][j]$ vale $x$ allora $R[j][i]$ deve valere $\frac{1}{x}$.

Per capire dunque a quali requisiti dare priorità tu devi calcolare quella matrice sia per il costo sia per il valore, normalizzarne le colonne e fare la media sulle righe. In questo modo trovi per ogni requisito (quindi ogni riga) un valore che ti indica quando contribuisce in percentuale tale requisito per quanto riguarda costo/valore.

Poi crei un grafico dove ogni requisito viene identificato da un punto 2d (contributo costo, contributo valore) trovati come descritto precedentemente, e sceglierai di dare maggior priorità a quelli che stanno a sinistra ed in alto 

### Documentazione dei requisiti.
Dare una definizione precisa di tutte le le caratteristiche scelte per il sistema: obiettivi, concetti, proprietà di dominio, assunzioni, responsabilità.. e organizzarle in modo efficiente e capibile da tute le parti in questione.
1.**Linguaggio naturale**: il linguaggio naturale non ha nessuna limitazione, fornendo espressività illimitata, e risulta capibile da tutti. Allo stesso tempo lascia spazio ad errori ed ambiguità. Per migliorare la situazione si può strutturare il linguaggio naturale in modo di avere regole locali per i requisiti e regole globali per la loro organizzazione.
Un requisito dovrebbe:
- Essere scritto in base a chi lo legge.
- Dire cosa fare prima di farlo.
- Prima motiva, poi riassume.
- Definire i concetti prima di usarli.
- Essere comprensibile.
- Evitare gergo o acronimi.
- Usare esempi o diagrammi.

Per ogni requisito bisogna individuare: identificatore, categoria, specifica, fit criterion(rende un criterio misurabile), fonte, razionale, interazione con gli altri requisiti, priorità, stabilità e condivisione.
**Regole globali**:
- Grouping: mettere nella stessa categoria elementi con fattori comuni.
- Template globali per standardizzare l'RD(requirements document): Standard IEEE std-830  

2.**Notazioni semi-formali**: sintassi definita formalmente. Usato per sostituire o completare il linguaggio naturale. Dedicato a specifici aspetti del sistema. Spesso utilizzano grafici. Esempi di diagrammi:
- **Context Diagrams**: dichiara i componenti del sistema e le loro interfaccie(cosa fa parte e cosa non fa pare del sistema).
- **Problem Diagrams**: presentano una visione riassunta della problematica da risolvere.
- **Frame Diagrams**: Catturano pattern frequenti nei problemi del sistema.
- **Dataflow Diagrams**: Catturano operazioni del sistema collegate dalle dipendenze dei dati, memorizzano dunque il flusso dei dati. (I collegamenti rappresentano input ed output).

Esistono inoltre strutture concettuali per rappresentare aspetti del sistema come:
- **Diagrammi entità relazione**
- **Diagrammi dei casi d'uso**.
- **Event Trace Diagrams**: Mostrano le interazioni tra diverse componenti del sistema.
- **SADT Diagrams(attività/dati)** Structured analysis and design technique: catturano le attività o i dati in un sistema.
- **Actigram**: collega le attività tramite collegamenti che indicano la dipendenza dei dati usati/prodotti. Freccie:
- Sinistra: Input.
- Destra: Output.
- Sopra: Dati/Eventi controllati.
- Sotto: Processore.
- **Datagram**: collega i dati tramite collegamenti che indicano la dipendenza "di controllo"
- Sinistra: Producing attivity.
- Destra: Consuming attivity;
- Sopra: Validation.
- Sotto: Risorse richieste.
- **State Machine Diagrams**: Rappresentano le attività come un diagramma a stati finiti che ne rappresenta lo svolgimento.
- **Statechart**: Composizione parallela di State Machine Diagrams.
- **R-NET Diagrams**: Catturano tutte le risposte necessarie ad un singolo stimolo. Catena di operazioni di risposta da eseguire da parte di un componente del sistema. Ottimi per visualizzare.

Per un singolo sistema si possono utilizzare molteplici diagramma, esistono inoltre delle regole di consistenza tra diagrammi, che specificano delle condizioni che devono essere rispettate necessariamente da diagrammi che rappresentano lo stesso oggetto, in modo da garantire la loro consistenza.

*Vantaggi*: Coprono gli aspetti importanti, facili da capire e condividere.
*Svantaggi*: Potrebbero essere vaghi, solo gli aspetti principali sono formalizzati, analisi automatica limitata.

3.**Notazioni formali**: Sia la sintassi sia la semantica sono formalmente definiti. Molto utili per domini molto critici. Tra parti: dichiarazione, asserzione e strutturazione. Linguaggi
## Software Development
### Model View Control
#### Design Patterns:
Controller Designs:
- **Page Controller**: viene creato un controller per ogni pagina. Ogni controller deve:
- Recuperare i parametri della richiesta ed invocare la logica.
- Selezionare la view successiva.
- Preparare i dati per la presentazione.

- **Front Controller**: Viene creato un unico controller che esegue tutti i comandi comuni a tutte le operazioni, individua poi il componente specifico per eseguire la richiesta e passa il controllo ad esso. Viene creata una gerarchia di comandi(ognuno corrisponde ad un'operazione). Ogni comando corrisponde ad una classe.

- **Intercepting Filters**: Spesso utilizzato con il front controller, aggiunge a richiesta/risposte diverse funzionalità(login/autenticazione/conversione di dati). Vengono eseguiti tra l'attivo della richiesta al web server e l'arrivo della richiesta al target. Formano una catena di filtri(filter chain) gestiti dal filter manager. Solitamente il web server offre il filter manager e la filter chain, bisogna solo implementare i singoli filtri in base alle funzionalità richieste. 

- **Application Controller**: non trattato.

View Designs:
- **Template View**: Rappresenta il design più comune, alterna una parte statica (template) ad una parte generata dinamicamente tramite chiamate al model (l'**helper** svolge tali chiamate). Separa la view dall'implementazione della logica. La pagina viene creata dal controller ed usata dalla view. Utilizza dei marker nel HTML per la parte dinamica.
- **Tranform View**: Pagina generata dinamicamente trasformando i dati in HTML. Solitamente trasforma dati memorizzati in XML in pagine HTML(XSLT). Il **transformer** legge i dati dal model e li trasforma in HTML. Il focue viene dato alle entità da trasformare. Rende difficile includere la logica applicativa nella view ma diventa semplice effettura i test.
- **Two-Step View**: l'HTML viene generato in 2 step:
1. Viene generata una pagina "logica".
2. Viene effettuato il render della pagina.

Può essere implementata in 2 modi:
1. 2 trasformazioni XSLT consecutive.
2. Utilizzo di template view per la logica, e custom tags per il rendering.

Le sessioni possono essere mantenute tramite campi nascosti e cocckies, una sessione è un insieme di richieste simili.
Spring MVC offre: front controller, intercepting filter ed è disegnato attorno ad un dispatcher servlet che gestisce tutte le richieste/risposte.

### Object Relation Mapping.
Gateway: incapsula l'accesso ad una risorsa esterna in una classe e traduce le richieste di accesso alla risorsa esterna. Pattern per i gateway di una base di dati.
- Table data gateway: 1 oggetto per tabella.
- Row data gateway: 1 oggetto per ogni record.
- Active record: 1 oggetto per ogni record (versione ottimizzata del row data gw) Non esiste separazione tra business logic e meccanismi di persistenza:
- Implementa sia la business logic sia logica di mapping con il db.
- Metodi finder(statici): query sql che ritornano una collezione di oggetti.
- Metodi gateway: Metodi non statici:
- Metodi per il load: vrea un'istanza come risultato di una query SQL.
- Costruttore: Crea una nuova istanza da rendere persistente.
- Write/Insert/Update.
- Data Mapper: Un livello software indipendente dedicato alla persistenza. La logica di dominio viene separata dal database e dalle query. Le interfacce permettono l'accesso al mapper in modo indipendente dall'implementazione.

**Pattern ORM**:
**Unit of work**: problematica: quando sicronizzare gli oggetti in memoria ed il database?
1. Una transizione di sistema per ogni transazione business, volendo garantire la correttezza la transazione di sistema deve rimanere aperta per tutta la durata della transazione business. Attesa per le interazioni con l'utente troppo lunga. 
2. Una transazione di sistema per ogni operazione con il database. In questo modo le transazioni di sistema sono brevi come desiderato, ma si perde la consistenza. 
3. Traccia le operazioni della business logic ed attua tutti i cambiamenti in un'unica transazione di sistema. Nel caso in cui la transazione di sistema fallisca viene annullata la transazione business. Questa soluzione risulta essere la più pratica. 

Volendo implementare la terza soluzione si pone il problema su come tracciare le operazioni effettuate durante la business transaction. Viene usata un' **Unit of Work** (UoW) che memorizza tutti i cambiamenti per poi effettuarli in un'unica transazione di sistema (o eventualmente svolge un rollback). L'UoW incapsula tutti gli update/insert/delete, mantiene l'intergrità della base di dati ed evita deadlocks. Utilizza vari metodi per memorizzare le operazioni (registerNew(), registerDirty(), registerClean(), registerDeleted());

**Locking**: Molteplici business transaction potrebbero essere aperte contemporaneamente, in base al livello di concorrenza dell'applicazione posso applicare 2 strategie:
1. **Locking ottimistico**: assumiamo che tipicamente gli utenti lavorino su dati differenti. I record non vengono quindi bloccati ma gli viene aggiunto un numero di versione che verrà incrementato ad ogni modifica. Controllo dunque che il numero di versione non sia cambiato tra l'inizio e la fine della business transaction.
2. **Locking pessimistico**: Non permettiamo alle business transaction di lavorare su dati utilizzati da altre business transiction.

**Politiche di notifica** Chi notifica l'UoW che un dato viene modificato:
1. Caller registration: chi modifica il dato avverte l'UoW.
2. Object registration: lo stesso oggetto modificato avverte l'UoW.

**Identity Map**: Si evita che uno stesso oggetto venga caricato in memoria più volte. Viene controllato la presenza di un oggetto in memoria prima di inserirlo nuovamente.

**Lazy Load**: Potrebbe esser necessario caricare solo una parte dei record in memoria (molto utile se alcuni campi risultano essere molto pesanti). Quando viene creato l'oggetto setto solo gli attributi necessari, gli altri attributi verranno caricati solo quando utilizzati.

**Value Holder**: implementazione del concetto di Lazy Load attraverso un oggetto specifico (il Value Holder) che ha la funzione di riferimento ad un attributo: permette di separare la logica di dominio da quella di Lazy Load.

**Identity Field**: Bisogna sincronizzare i riferimenti agli oggetti in memoria con le chiavi primarie della base di dati. Con identity field la chiave primaria viene memorizzata come attributo dell'oggetto. Per generare tale ID posso:
1. Farlo generare al DB.
2. Farlo scegliere all'applicazione con table scan(scorri la tabella per trovare il prossimo id da usare) o usando una tabella apposita (key table).

**Embedded Value**: oggetti "embedded" all'interno di una tabella invece di creare una propria tabella inutile in quanto non identificabile. Esempio: gli attributi di un oggetto di classe Address direttamente inseriti nella tabella Person senza usare una reference di tipo Address.

### Enterprise Java Beans
Obiettivo: lavorare con componenti indipendenti per evitare la dipendenza statica.
2 Metodi:
1. **Inversion of control**(dependency injection): i campi vengono popolati indipendentemente dal fatto che venga richiesto. Un componente esterno chiamato **assembler** popola il campo con la versione corretta. L'iniezione viene fatta quando l'oggetto viene creato e può essere fatta tramite costruttore oppure usando setter/getter oppure tramite un'interfaccia. L'assembler viene solitamente fornito dai framework e viene configurato tramite annotazionio.
2. **Service locator**(dependecy look-up): un servizio conosce la giusta implementazione, il client richiede la giusta versione al servizio che ne ritorna un riferimento. Il riferimento al service locator può essere impostato tramite dependency injection.

#### Component Model EJB 3.0
Esistono 3 tipi di beans:
1. **Entity bean**: jpa.
2. **Session bean**: gestiscono le operazioni sincrone ed utilizzano la annotazioni.
3. **Message-driven bean**: operazioni asincrone.

Sia i session bean sia i message drive bean implementano operazioni server side, possono modificare il db ma non sono persistenti.

**Session bean**: classe che implemente un'interfaccia locale `@javax.ejb.Local` e/o un'interfaccia remota `@javax.ejb.Remote` e/o un endpoint interface `@javax.jws.WebService`. I session bean possono esseria sia stateless `@javax.ejb.Stateless` sia stateful `@javax.ejb.Stateful`.

**Message-driven bean**: classe che implementa un'interfaccia per ricevere messaggi in modo asincrono, annotati con ` @javax.ejb.MessageDriven`.
**Accesso ai bean**: 
Il container cattura le richieste e le gestisce. Ogni vendor ha una propria implementazione dei container. EJB supporta sia dependency injection sia service locator.
**Gestione delle risorse**: Le applicazioni possono avere migliaia di utenti che creano milioni di oggetti, dunque tali oggetti devono essere gestiti in modo efficiente.
- **Instance pooling**: riduce il numero di oggetti necessari: il client non interagisce mai direttamente con il bean ma con il container. Solitamente non è necessario il mapping 1 richiesta = 1 oggetto. 

**Activation/Passivation**: Se le sessioni sono stateful allora non posso fare instance pooling ma posso attuare un processo di attivazione e passivazione: controllo la frequenza degli accessi ai bean in memoria, se un bean non è usato allora viene passivato(spostato sulla memoria secondaria), nel momento in cui deve essere utilizzato viene attivato nuovamente(spostato sulla memoria principale).
**Concorrenza**:
1. Session bean: ho un session bean per client: non ho concorrenza.
2. Entity bean: ho un entity bean per ogni transazione, quindi non ho problemi di concorrenza nell'applicazione ma devo gestire gli accessi al db (vedi locking del capitolo precedente).
3. Message-driven bean: un bean per ogni messaggio: non ho concorrenza.

**Sicurezza**: Nativamente EJB supporta 3 livelli di discurezza: autenticazione, autorizzazione, e comunicazioni sicure.

**Transazioni**: le transazioni possono essere create dichiarativamente tramite annotazioni. Posso usare diverse annotazioni per esprimere il contest transazionale di un metodo:
- **notSupported**: a prescindere dal contesto transazionale del chiamante il bean non ne fa parte.
- **Supports::** il bean segue il contesto transazionale del chiamante.
- **Required**: se il chiamante ha aperto una transazione allora il bean ne fa parte, altrimenti viene aperta una transazione apposita.
- **RequiresNew**: Indipendentemente dal contesto del chiamante viene creata una nuova transazione.
- **Mandatory**: La responsabilità di aver creato una transazine è del chiamante, in caso non sia stato fatto viene sollevata un'eccezione.
- **Never**: L'operazione non deve avvenire in una transazione, se il chiamante ne fa parte allora viene sollevata un'eccezione.

**Isolamento e database locking**:
3 Possibili problemi:
1. Dirty reads: Una transazione legge dati modificati da una transazione non conclusa.
2. Unreapetable reads: 2 reads nella stessa transazione hanno risultati differenti.
3. Phantom record: Una transazione legge dati generati dopo l'inizio della transazione stessa.