Teoria Flashcards
(161 cards)
1
Q
Quali sono le caratteristiche essenziali per un software di qualità?
A
1) Manutenibilità
2)Fidatezza
3) Efficienza
4) Accettabilità
Include, oltre al/ai programma/i, documentazione, test, manutenzione e aggiornamenti
2
Q
Cosa descrive un processo software?
A
Descrive chi fa che ose e quando per raggiungere un certo obiettivo. Descrive un approccio disciplinato alla costruzione, al rilascio ed eventualmente alla manutenzione del software
3
Q
Quali sono le 4 attività di processo comuni?
A
1) specifiche del software(= specifica dei requisiti)
2) sviluppo del software
3) convalida del software
4) evoluzione del software
4
Q
Parla ed elenca le fasi principali della fase “specifica dei requisiti”
A
Attività per definire quali sono i requisiti richiesti dal sistema e identificarne i vincoli. Le fasi principali sono:
1)Deduzione ed analisi dei requisiti
2)Specifica dei requisiti
3)Convalida dei requisiti
5
Q
Parla ed elenca le fasi principali della fase “sviluppo del software”
A
Attività di conversione delle specifiche del software in un sistema da consegnare al cliente. (nelle metodologie agili…)
Le fasi principali:
1) Progettazione dell’architettura
2) Progettazione del db
3)Progettazione dell’interfaccia
4)Progettazione e scelta dei componenti
6
Q
Parla dell’attività di verifica e convalida del software
A
Serve a dimostrare che un sistema sia conforme alle specifiche e soddisfi le esigenze del cliente. Questa attività richiede controllo, ispezione e revisione ad ogni stadio dello sviluppo. I test sono di tre tipi:
1)test di unità
2)test del sistema
3) test del cliente
7
Q
Parla dell’attività di evoluzione del sistema.
A
Attività di modifica durante o dopo lo sviluppo di un sistema software. (distinzione sviluppo e manutenzione??)
Per ridurre i costi di rilavorazione si:
1)anticipazione dei cambiamenti
2)tolleranza dei cambiamenti
due modi x far fronte ai cambiamenti:
1)prototipazione del sistema
2) consegna incrementale
8
Q
Quale meccanismo è ottimo per supportare la tolleranza ai cambiamenti?
A
Il refactoring
9
Q
Cos’è il refactoring?
A
processo che consiste nel ristrutturare il codice senza modificarne il comportamento esterno. mira a migliorare la struttura interna del software al fine di renderlo più comprensibile, manutenibile ed efficiente, senza alterare la funzionalità visibile dall’esterno
10
Q
Cos’è un modello di processo software? Fai degli esempi
A
E’ una rappresentazione semplificata di un processo software Sono strutture di un processo da estendere e adattare per soddisfare le esigenze specifiche di un progetto.
11
Q
Esiste un modello di processo software universale? Motiva risposta
A
No, non esiste un modello universale ma la scelta dipende dai requisiti del cliente (fai esempi)
12
Q
Cos’è il modello a cascata?
A
Modello di sviluppo sw in cui le fasi di sviluppo sono viste come fasi distinte e non sovrapposte.
13
Q
Fasi del modello a cascata?
A
1)All’inizio si definiscono i requisiti;
1)All’inizio si definisce un piano temporale;
2)Si progetta e modella il sistema;
3)Si crea un progetto completo del software;
4)Si inizia la programmazione del sistema;
5)Si testa il sistema, si rilascia e si prosegue con la manutenzione.
14
Q
In che cosa il modello a cascata si contrappone ai modelli incrementali?
A
Nei modelli incrementali le fasi di sviluppo sono sovrapposte e iterate mentre nel modello a cascata le fasi sono viste come distinte e non sovrapposte
15
Q
Cos’è il modello incrementale?
A
è un modello di processo software in cui il sistema viene sviluppato in incrementi
(o iterazioni). Si effettuano feedback veloci e rilasci
16
Q
Lo sviluppo incrementale può essere un approccio di che tipo?
A
1) plan-driven: si pianificano in anticipo gli incrementi;
2)agile: si identificano gli incrementi iniziali ma si dà priorità al rilascio di incrementi che soddisfano i requisiti più importanti
3)una combinazione delle due
17
Q
Aspetti positivi del modello incrementale?
A
1) costo di implementazione di modifiche ridotto
2) è facile ottenere un feedback dal cliente
18
Q
Cosa sai dirmi sul riutilizzo del software? Quali sono le sue fasi?
A
Pratica che si diffonde dagli anni 2000.
Le fasi principali sono:
1) Specifica dei requisiti;
2)Ricerca e valutazione del software: se esiste un software che soddisfa i requisiti;
3) Perfezionamento dei requisiti: utilizzando le informazioni trovate nella ricerca;
4) Configurazione del sistema di applicazioni;
5) Adattamento e integrazione: si integra il sistema con i componenti riutilizzabili.
19
Q
Vantaggi e svantaggi del riutilizzo del sw?
A
Vantaggi: riduce la quantità di software da sviluppare, riducendo i costi e i rischi
Svantaggi: bisogna
scendere a compromessi con i requisiti e si perde il controllo sull’evoluzione del sistema
20
Q
Il modello di riutilizzo del sw di che tipo è?
A
1)Incrementale: si incrementa il codice man mano che si sviluppa;
2)Iterativo: si sviluppa il software in cicli (iterazioni);
3)Evolutivo: si sviluppa il software in modo che possa evolvere a ogni iterazione richiedendo un feedback.
21
Q
Cosa sai dirmi sull’approccio iterativo?
A
Nell’approccio iterativo:
- lo sviluppo è organizzato in mini-progetti brevi (le iterazioni);
- il risultato di ogni iterazione è un sistema parzialmente funzionante (testato e integrato);
- ogni iterazione dura poche settimane a e comprende le proprie attività di analisi, sviluppo, etc.;
- si ottiene un feedback a ogni iterazione.
22
Q
Cos’è lo sviluppo agile?
A
E’ un insieme di metodi di sviluppo software
23
Q
Quali sono i principi dello sviluppo agile?
A
Lo scopo della modellazione (UML) è principalmente quello di comprendere e di agevolare la comunicazione,
non di documentare.
1) Adottare un metodo agile non significa evitare del tutto la modellazione;
2) La modellazione non va fatta da soli ma in coppie o in gruppo;
24
Q
Quali sono le pratiche innovative dello sviluppo agile?
A
1)Storie utente: scenari d’uso in cui potrebbe trovarsi un utente. Il cliente lavora a stretto contatto con il
team di sviluppo e discute di possibili scenari;
2)Refactoring: il codice va costantemente rifattorizzato per proteggerlo dal deterioramento causato dallo
sviluppo incrementale;
3)Sviluppo con test iniziali: lo sviluppo non può procedere finchè tutti i test non sono stati superati;
4)Programmazione a coppie: i programmatori lavorano a coppie nella stessa postazione per sviluppare il
software.
25
Cosa sai dirmi su XP?
eXtreame Programming (XP) è un metodo di sviluppo software che si basa su valori e principi di base:
1)sviluppo incrementale attraverso piccole e frequenti release;
2)il cliente è parte attiva dello sviluppo;
3) il progetto è supportato da test, refactoring e integrazione continua;
4) si punta a mantenere la semplicità.
26
Cosa sai dirmi su Scrum?
è un metodo di sviluppo sw che offre un framework per organizzare progetti agili e fornire una visibilità esterna su ciò che sta
accadendo, ossia si occupa dell’organizzazione del lavoro e della gestione dei progetti.
Scrum è un approccio iterativo e incrementale in cui ciascuna iterazione ha una durata fissata denominata
Sprint
27
Quali sono i tre ruoli presenti in uno sviluppo scrum?
1)Product Owner: rappresenta il cliente, definisce i requisiti e specifica le priorità attraverso il Product Backlog4;
2) Development Team: le persone che sviluppano il software;
3) Scrum Master: garantisce che il team segua le regole di Scrum.
28
Come avviene la gestione agile della progettazione in scrum?
Il Development Team seleziona dal Product Backlog un insieme di voci da sviluppare durante quell’iterazione
(Sprint Goal), compila lo Sprint Backlog (ossia i compiti dettagliati per raggiungere il goal);
Il risultato di ciascuno Sprint è un prodotto software funzionante chiamato "incremento di prodotto potenzialmente
rilasciabile" (integrato, verificato e documentato);
Nello Sprint Review il Product Owner e il Development Team presentano le parti coinvolte dall’incremento,
ne fanno la dimostrazione, ottengono un feedback e decidono cosa fare nello Sprint successivo;
Si dà enfasi all’adozione di Team auto-organizzati e auto-gestiti.
29
Cos'è un framework?
Struttura di lavoro che fornisce una guida o una base per lo svolgimento di una specifica attività
30
Cosa intendiamo per OOA e OOD?
1)OOA (Object Oriented Analysis): studio dei requisiti e delle specifiche del sistema;
2)OOD (Object Oriented Design): progettazione del sistema.
31
Cosa si usa per studiare OOA e OOD?
Per studiare OOA/D si utilizza Unified Process, un processo di sviluppo software orientato agli oggetti.
32
Cosa si intende per UP?
Unified Process è un processo iterativo ed evolutivo (incrementale) per lo sviluppo del software per la
costruzione di sistemi orientati agli oggetti. Le iterazioni iniziali sono guidate dal rischio, dal cliente e
dall’architettura.
33
Quali sono esempi di approcci ai quali può essere applicato up?
Sono approcci agili come scrum o xp
34
UML descrive software?
NO, uml descrive concetti
35
UP che linguaggio di modellazione usa?
UML e solo uml
36
Cos'è UML?
UML è un progetto che serve per aiutare la comprensione nei team di sviluppo.
UML è un linguaggio visuale per la specifica, la costruzione e la documentazione degli elaborati di un
sistema software.
UML è uno standard per la notazione di diagrammi per disegnare o rappresentare figure relative al software
(specialmente OO).
37
Quando e come usiamo UML?
1)Punto di vista concettuale: modello di dominio, per visualizzare concetti del mondo reale;
2)Punto di vista software: diagramma delle classi di progetto, utilizzata per visualizzare elementi software.
38
Cosa sono i pattern?
I pattern sono euristiche, best practice, che aiutano a codificare principi di soluzioni.
39
Da che cosa è guidata OOD?
Dalle responsabilità, ecco perchè è correlata all'analisi dei requisiti:
1) casi d'uso
2) storie utente
grazie a loro possiamo delineare i requisiti del sistema
40
Quali processi di sviluppo comprendono lo svolgimento dell'analisi dei requisiti e dell'OOA/OOD?
1)sviluppo iterativo
2)approccio agile
3)up
(quindi non un processo di sviluppo a cascata x esempio)
41
Che cosa sono i requisiti?
Un requisito è una capacità o una condizione a cui il sistema deve essere conforme.
42
Un processo up cosa comprende?
1)Un’organizzazione del piano di progetto per fasi sequenziali;
2) Indicazioni sulle attività da svolgere nell’ambito di discipline e sulle loro inter-relazioni;
3)Un insieme di ruoli predefiniti;
4) Un insieme di artefatti da produrre
43
Quali sono le quattro fasi in cui è organizzato un progetto up? Descrivile.
1)ideazione -> milestone: obiettivi
2)elaborazione ->milestone: architetturale
3)costruzione->milestone: capacità operazionale
4)transazione-> milestone: rilascio di prodotto
44
Ma ideazione e elaborazione (in up) sono fasi di requisiti? motiva la risposta
NO!
1)L’Ideazione non è una fase di requisiti, ma di fattibilità;
2)L’Elaborazione non è una fase di requisiti o di progettazione, ma una fase in cui si implementa in
modo iterativo l’architettura del sistema e vengono ridotti i rischi maggiori.
45
Cosa si intende per discipline?
Una disciplina è un insieme di attività e dei relativi elaborati in una determinata area, come le attività
relative all’analisi dei requisiti.
46
Cosa intendiamo per elaborato?
Un elaborato (artefatto o work product) è il termine generico che indica un qualsiasi prodotto di lavoro:
codice, schemi di basi di dati, documenti di testo, diagrammi, modelli, etc.
47
Discipline principali e di supporto di up?
Principali:
1)Modellazione del business: attività che modellano il dominio del problema e il suo ambito;
2) Requisiti: attività di raccolta dei requisiti;
3)Progettazione (analysis and design): attività di analisi dei requisiti e progetto architetturale;
4)Implementazione: attività di progetto dettagliato e codifica del sistema, test sui componenti;
5) Test: attività di controllo di qualità, test di integrazione e di sistema;
6) Rilascio: attività di consegna e messa in opera.
Di supporto:
1)Gestione delle configurazioni e del cambiamento: attività di manutenzione durante il progetto;
2) Gestione progetto: attività di pianificazione e governo del progetto;
3)Infrastruttura (enviroment): attività che supportano il team di progetto, riguardo ai processi e strumenti
utilizzati.
48
Differenza in up tra discipline e fasi?
Nonostante le fasi siano sequenziali, le discipline non lo sono (perchè si eseguono in ogni iterazione). Il numero
di iterazioni dipende dal Project Manager.
49
Quali sono le sorgenti dei requisiti? DI che tipo possono essere i requisiti?
I requisiti derivano da richieste degli utenti del sistema per risolvere dei problemi e raggiungere degli obiettivi.
Possono essere:
1) Requisiti funzionali: descrivono il comportamento del sistema in termini di funzionalità offerte;
2) Requisiti non funzionali: le proprietà del sistema nel suo complesso (sicurezza, prestazioni, etc.).
50
Cos'è il modello FURPS+?
⇒Funzionali (F): requisiti funzionali e di sicurezza;
⇒ Usabilità (U): facilità d’uso del sistema;
⇒ Affidabilità (R - Reliability): disponibilità del sistema, capacità di tollerare guasti o di essere ripristinato;
⇒ Prestazioni (P): tempi di risposta, throughput, capacità e uso delle risorse;
⇒ Sostenibilità (S): facilità di modifica per riparazioni e miglioramenti, adattabilità, manutenibilità, localizzazione,
configurazione, compatibilità;
⇒ +: vincoli di progetto, interoperabilità, operazionali, fisici, legali, etc.
51
Quali sono gli elaborati prodotti dalla fase di analisi dei requisiti?
⇒ Modello dei Casi d’Uso: scenari tipi dell’utilizzo di un sistema;
⇒ Specifiche supplementari: ciò che non rientra nei Casi d’Uso, requisiti non funzionali o funzionali non
esprimibili attraverso i Casi d’Uso;
⇒ Glossario: termini significativi, dizionario dei dati;
⇒ Visione: riassume i requisiti di alto livello, un documento sintetico per apprendere rapidamente le idee
principali del progetto;
⇒ Regole di Business: regole di dominio, i requisiti o le politiche che trascendono un unico progetto software
e a cui un sistema deve conformarsi.
52
Che cos'è l'ideazione? Qual è il suo obiettivo?
l’ideazione permette di stabilire una visione completa e la portata del progetto (studio di fattibilità).
Lo scopo dell’Ideazione non è di raccogliere tutti i requisiti, né di generare una stima o un piano di progetto affidabile. Durante l’ideazione si cerca di capire se il progetto è fattibile e se ha senso.
Ha durata breve. Si prepara l'ambiente di sviluppo.
53
Cosa produce la fase di ideazione?
La fase di ideazione produce molti artefatti che:
1)non sono definitivi
2) non sono importanti come documento in sè ma è importante il lavoro di pensiero e studio che c'è dietro
54
Cosa intendiamo per l'elaborato di specifiche supplementari?
Le specifiche supplementari raccolgono altri requisiti, informazioni e vincoli che non sono espressi nei Casi
d’Uso o nel Glossario. Si deve mettere anche la cronologia delle versioni.
55
Cosa intendiamo per l'elaborato di visione?
Il documento Visione riassume alcune informazioni contenute nel modello dei Casi d’Uso e nelle Specifiche
supplementari. Inoltre descrive brevemente il progetto ai partecipanti per stabilire una visione comune.
⇒ Obiettivi e problemi fondamentali ad alto livello;
⇒ Riepilogo delle caratteristiche di sistema.
56
Cosa intendiamo per l'elaborato del glossario?
Il Glossario è un documento che definisce i termini significativi del dominio e le relazioni tra di essi. Si
devono eliminare eventuali discrepanze per ridurre problemi di comunicazione e di ambiguità.
In UP il Glossario svolge anche il ruolo di dizionario dei dati: un documento di dati che si riferiscono ad
altri dati, per esempio le regole di validazione.
57
Cos'è la disciplina dei requisiti?
La disciplina dei requisiti è il processo per scoprire cosa deve essere costruito e orientare lo sviluppo verso
il sistema corretto.
58
Cosa sono i requisiti di sistema?
I requisiti di sistema sono le capacità e le condizioni a cui il sistema deve essere conforme.
Sono scritti nel linguaggio del cliente
59
Cos'è la lista dei requisiti?
La lista dei requisiti è usata per stimare la taglia del progetto e per decidere come suddividere il lavoro in
sequenze di iterazioni.
60
Quali sono le caratteristiche che caratterizzano ogni requisito?
⇒ Breve descrizione;
⇒ Stato (proposto, approvato, incorporato, validato);
⇒ Costi di implementazione stimati;
⇒ Priorità;
⇒ Rischio associato per la sua implementazione.
61
Quali sono i modi per capire il contesto del sistema?
⇒ Modello di dominio: descrive i concetti significativi del sistema come oggetti del dominio e relaziona i
concetti con associazioni (usa UML);
⇒ Modello di business: un super-insieme del modello di dominio, descrive i processi di business. È un prodotto
dell’ingegneria del business e ha lo scopo di migliorare i processi di business.
62
Come catturiamo i requisiti funzionali?
⇒ In UP vengono usati i Casi d’Uso;
⇒ Un Caso d’Uso rappresenta un possibile utilizzo del sistema da parte di un utente;
⇒ Sono descrizioni testuali
63
Come catturiamo i requisiti non funzionali?
⇒ Si utilizzano le Specifiche supplementari;
⇒ Possono anche essere catturati nei Casi d’Uso.
64
I casi d'uso sono diagrammi?
No, sono documenti di testo
65
Cosa significa dire che up è una metodologia use-case-driven?
Significa che il processo UP è guidato dall'analisi dei casi d'uso (use case):
⇒ I Casi d’Uso si usano per pianificare le iterazioni;
⇒ L’analisi e la progettazione si basano sui Casi d’Uso;
⇒ I Casi d’Uso sono usati per definire i test;
⇒ I Casi d’Uso influiscono nella redazione dei manuali utente e della Visione;
66
Definisci caso d'uso, scenario e attori
1)insieme di scenari che descrivono un attore che usa il sistema per raggiungere un obiettivo
specifico.
-possono essere di successo o fallimento
sono utili per -rappresentare i requisiti come OOA/OOD.
-I casi d'uso definiscono i contratti in relaizone al comportamento del sistema
2)(istanza di Caso d’Uso): sequenza specifica di azioni e interazioni tra l sistema e alcuni attori.
Descrive una particolare storia;
3)qualcosa o qualcuno dotato di comportamento.
il sistema stesso è considerato un attore
67
cos'è un modello dei casi d'uso?
Il modello dei Casi d’Uso è un modello delle funzionalità del sistema. Include un diagramma UML dei
Casi d’Uso che funge da modello di contesto del sistema e da indice dei nomi di Caso d’Uso.
68
Quali sono i tipi di attori?
Gli attori sono ruoli svolti da persone, organizzazioni, software e macchine:
⇒ Attore primario:
– Raggiunge gli obiettivi utente utilizzando il sistema;
– Utile per trovare gli obiettivi utente.
⇒ Attore di supporto:
– Offre un servizio al sistema;
– Utile per chiarire le interfacce esterne e i protocolli.
⇒ Fuori scena:
– Ha un interesse nel comportamento del Caso d’Uso;
– Utile per garantire che tutti gli interessi necessari vengano soddisfatti.
69
Quali sono i tre formati che può avere un caso d'uso?
⇒ Breve: un paragrafo, relativo allo scenario principale di successo. Serve a capire rapidamente l’argomento
e la portata;
⇒ Informale: più paragrafi, scritti in modo informale, relativi a vari scenari. Si ha un maggior livello di
dettaglio;
⇒ Dettagliato: tutti i passi e le variazioni sono scritti in dettaglio, include pre-condizioni e garanzie di successo.
Si scrivono a partire da un formato breve o informale.
70
Quando si scrive un caso d'uso quali sono le cose da scrivere?
1)sezioni del caso d'uso
2)caratteristiche
3)passi
4)estensioni
5)formato
71
quali sono le sezioni dei casi d'uso?
⇒ Portata: descrive i confini del sistema;
⇒ Livello: "obiettivo utente" o "sottofunzione";
⇒ Attore finale, attore primario: l’attore finale è l’attore che vuole raggiungere un obiettivo e questo richiede
l’esecuzione dei servizi del sistema. L’attore primario è l’attore che usa direttamente il sistema. Spesso
coincidono;
⇒ Parti interessate: chiunque abbia un interesse nel comportamento del Caso d’Uso;
⇒ Pre-condizioni: lo stato del sistema prima che il Caso d’Uso inizi. Non vengono verificate all’interno del
Caso d’Uso;
⇒ Garanzie di successo (post-condizioni): ciò che deve essere vero se il Caso d’Uso viene completato con
successo.
72
Quali sono i tre tipi di passi dei casi d'uso?
⇒ Un’interazione tra attori:
– Un attore chiede qualcosa al sistema o inserisce dei dati;
– Il sistema interagisce con l’attore, rispondendo o comunicando dei dati;
– Il sistema interagisce con altri sistemi.
⇒ Un cambiamento di stato da parte del sistema;
⇒ Una validazione: normalmente fatta dal sistema.
Note:-
Il primo passo indica l’evento trigger che scatena l’esecuzione dello scenario.
73
Differenza tra passo principale ed estensioni?
Un passo dello scenario principale descrive un’azione generica o astratta, mentre le estensioni descrivono
azioni specifiche o concrete.
74
Quali sono i tre test utili nell'analisi dei requisiti?
⇒ Il test del capo: il capo sarà felice?
⇒ Il test EBP (Elementary Business Process): un processo di Business è un’attività che aggiunge un valore;
⇒ Il test della dimensione: un Caso d’Uso raramente richiede una singola azione o passo. Normalmente, nella
forma dettagliata, richiede dalle 3 alle 10 pagine.
75
Che cos'è la fase di elaborazione?
L’elaborazione è la serie iniziale di iterazioni durante le quali il team esegue un’indagine seria, implementa
il nucleo dell’architettura, chiarisce la maggior parte dei requisiti e affronta le problematiche più rischiose.
76
Quali sono gli artefatti dell'elaborazione?
1) modello di dominio
2)modello di progetto
3) documento dell'architettura sw
4)modello dei dati
5) prototipi ui
77
Cos'è il modello di dominio? in che fase di sviluppo si inserisce?
Si inserisce nella fase di ideazione di UP. Il Modello di Dominio è una rappresentazione visuale delle classi concettuali (oggetti del dominio). Include:
- Oggetti di dominio.
- Associazioni tra classi concettuali.
- Attributi di classi concettuali.
il modello di dominio non è un modello di dati!
78
Cosa sono le classi concettuali?
Una classe concettuale rappresenta un concetto del mondo reale o del dominio di interesse di un sistema
che si sta modellando.
⇒ Il simbolo è una parola o un’immagine usata per rappresentare la classe concettuale;
⇒ L’intensione è la definizione della classe concettuale;
⇒ L’estensione è l’insieme di oggetti che la classe concettuale rappresenta.
79
Cosa sono le associazioni?
Un’associazione è una relazione tra istanze di classi che indica una connessione significativa e interessante
80
Cos'è un attributo?
Un attributo è un valore logico degli oggetti di una classe.
81
Cos'è una classe descrizione?
Una classe descrizione contiene informazioni che descrivono qualcos’altro. È utile avere un’associazione
che collega la classe descrizione alla classe descritta
82
Quali sono i passi per creare un modello di dominio?
⇒ Trovare le classi concettuali;
⇒ Disegnarle come classi in UML;
⇒ Aggiungere le associazioni;
⇒ Aggiungere gli attributi.
83
Parlami delle associazioni? Quali sono le loro caratteristiche?
⇒ Associazioni la cui conoscenza della relazione deve essere mantenuta dal sistema;
⇒ Associazioni derivate dall’elenco di associazioni comuni.
Note:-
Un’associazione è per natura bidirezionale.
Le caratteristiche delle associazioni sono:
1) nome significativo
2)molteplicità e direzione di lettura
84
Cosa si intende per molteplicità?
La molteplicità di un ruolo definisce quante istanze di una classe possono essere associate a un’istanza
dell’altra classe.
85
Cosa si intende per composizione?
La composizione, o aggregazione composta, è un tipo forte di aggregazione intero-parte:
⇒ Ciascuna istanza della parte appartiene a una sola istanza del composto alla volta;
⇒ La parte non può esistere senza il composto;
⇒ La vita delle parti è limitata a quella del composto.
86
Cos'è una generalizzazione?
La generalizzazione è un’astrazione basata sull’identificazione di caratteristiche comuni tra concetti, che
porta a definire un concetto più generale (superclasse) e concetti più specifici (sottoclassi). Vale il principio
di sostituibilità.
87
Cos'è l'SSD?
Il Diagramma di Sequenza del Sistema è un elaborato della disciplina dei requisitiche illustra eventi di
input e di output relativi ai sistemi in discussione.
È una figura che mostra, per un particolare Caso d’Uso, gli eventi generati dagli attori esterni al sistema,
il loro ordine e gli eventi inter-sistema.
Note:-
Di solito si usa un SSD per ogni Caso d’Uso.
88
Cosa sono gli eventi di sistema?
Un evento di sistema è un evento esterno al sistema generato da un attore per interagire con il sistema.
Un sistema reagisce a:
⇒ Eventi esterni: generati da attori umani o sistemi informatici;
⇒ Eventi temporali;
⇒ Guasti o eccezioni.
Note:-
Il software deve essere progettato per gestire questi eventi.
89
Cosa mostra un ssd?
Un SSD mostra:
⇒ L’attore primario del Caso d’Uso;
⇒ Il sistema in discussione;
⇒ I passi che rappresentano le interazioni tra il sistema e l’attore.
90
cosa sono i contratti?
I contratti usano pre-condizioni e post-condizioni per descrivere nel dettaglio i cambiamenti agli oggetti
in un Modello di Dominio.
Template di un contratto:
⇒ Operazione: Nome e parametri dell’operazione;
⇒ Riferimenti: Casi d’Uso in cui può verificarsi l’operazione;
⇒ Pre-condizioni: Stato del sistema prima dell’operazione. Sono ipotesi non banali;
⇒ Post-condizioni: Stato del sistema dopo l’operazione
91
Cosa sono le post-condizioni?
Le post-condizioni descrivono i cambiamenti nello stato degli oggetti del Modello di Dominio. I cambiamenti
comprendono:
⇒ Oggetti creati;
⇒ Collegamenti formati;
⇒ Collegamenti rotti;
⇒ Attributi modificati.
Un’operazione ha post-condizioni solo se è di trasformazione, mentre non le ha se è di interrogazione.
92
Cosa sono le pre-condizioni?
Le pre-condizioni sono ipotesi sullo stato del sistema prima dell’operazione. Sono condizioni che devono
essere vere prima che l’operazione possa essere eseguita.
93
Quali sono le due componenti delle operazioni?
Ogni operazione può avere una componente di:
⇒ Trasformazione: modifica lo stato del sistema;
⇒ Interrogazione: non modifica lo stato del sistema, vengono restituiti valori.
93
Bisogna scrivere un contratto per ogni evento di sistema trovato nel SSD?
Non è necessario, si considerano solo quelli più complessi.
94
Se si scoprono nuove classi, attributi, si possono aggiungere nel modello di dominio?
Sì, UP è incrementale
95
Le post-condizioni devono essere in ogni momento le più complete possibili?
Non è necessario.
96
Come definiamo l'architettura?
La progettazione OO è basata su diversi strati architetturali, come uno strati UI, uno strato di logica
applicativa (o "del dominio") e così via.
Note:
L’architettura può essere mostrata sotto forma di diagrammi UML.
97
Cos'è l'architettura logica?
L’architettura logica di un sistema software è la macro-organizzazione su larga scala delle classi in package
(o namespace), sottoinsiemi e strati.
98
Cosa si intende per platform indipendent architecture?
Non vengono prese decisioni su come gli elementi sono distribuiti sui processi o sui vari computer fisici di una
rete
99
Cos'è un layer/strato? Che cosa comprendono?
Un layer è un gruppo di classi software, packages, sottosistemi con responsabilità condivisa su un aspetto
importante del sistema.
Gli strati comprendono:
⇒ UI (User Interface): strato che si occupa dell’interazione con l’utente;
⇒ Application logic (o "domain object"): oggetti software che rappresentano concetti di dominio;
⇒ Technical services: oggetti e sottosistemi che forniscono servizi tecnici (es. persistenza, sicurezza, ecc.);
100
Cosa si intende per architettura a strati?
L’obiettivo di un’architettura a strati è la suddivisione di un sistema complesso in un insieme di elementi
software che possano essere sviluppati e modificati in modo indipendente
101
Cosa si intende per separation of concerns?
La separazione degli interessi:
⇒ Riduce l’accoppiamento e le dipendenze;
⇒ Aumenta la possibilità di riuso;
⇒ Facilita la manutenzione e l’evoluzione del sistema;
⇒ Aumenta la chiarezza.
102
Cosa si intende per alta coesione?
In uno strato le responsabilità degli oggetti devono essere fortemente collegate tra loro, ma non essere
mischiate con quelle di altri strati.
103
Come va progettata la logica applicativa con gli oggetti?
Si creano oggetti software con nomi e informazioni simili al Dominio del mondo reale e assegnare a
essi le responsabilità della logica applicativa.
104
cos'è un oggetto del dominio?
(nello strato del dominio)
Un oggetto del dominio è un oggetto software che rappresenta un concetto del dominio del problema.
Ha una logica applicativa o di business correlata.
105
differenza tra modello di dominio e strato di dominio
-modello di dominio: fornisce una rappresentazione concettuale del dominio dell'app
-strato di dominio: implementa la logica di business e le regole del dominio nel codice dell'app. Rappresenta una parte dell'architettura dell'app che si occupa della business logic e dell'implementazione delle regole di dominio.
si implementa prima il modello di dominio che poi ispira lo strato
106
cosa si intende per separazione modello vista?
è un approccio architetturale che serve a separare le componenti e le annesse responsabilità. Migliora la scalabilità, manutenibilità e comprensibilità. I concetti principali sono:
-modello (gestisce i dati e la logica di business) : è lo strato degli oggetti di dominio
-vista (interagisce con gli utenti): è lo strato UI
-controller(intermediario)
⇒ Le classi di dominio incapsulano le informazioni e il comportamento della logica applicativa;
⇒ Le classi della vista sono leggere, sono responsabili dell’inpute e dell’output, ma non mantengono dati.
107
Come si progetta a oggetti?
Disegno, poi codifica: si disegnano i diagrammi UML e poi si codifica;
108
Cosa si intende per modellazione dinamica e statica?
Modelli dinamici:
Rappresentano il comportamento del sistema, la collaborazione tra oggetti per realizzare dei Casi d’Uso.
Di solito si utilizzano i diagrammi di interazione UML.
⇒ Per la modellazione dinamica si fa riferimento ai principi GRASP
Modelli statici:
Servono per definire package, nomi delle classi, attributi e firme di operazioni. Di solito si utilizzano i
diagrammi delle classi UML.
Solitamente si creano in parallelo sia i modelli dinamici che statici.
109
Cos'è un'interazione?
Un’interazione è una specifica di come alcuni oggetti si scambiano messaggi nel tempo per eseguire un
compito nell’ambito di un certo contesto.
110
Quali sono i due tipi di diagrammi di interazione?
Il termine diagramma di interazione si riferisce a due tipi di diagrammi:
⇒ Diagrammi di sequenza;
⇒ Diagrammi di comunicazione.
In questo corso ci concentreremo sui diagrammi di sequenza.
111
Vantaggi e svantaggi dei diagrammi di sequenza?
-Mostrano chiaramente la sequenza dell’ordinamento temporale dei messaggi.
- Costringono a estendersi verso destra quando si aggiungono nuovi oggetti.
112
Cos'è un dsd?
Un diagramma di sequenza di progetto è un diagramma di sequenza utilizzato da un punto di vista software
o di progetto.
In UP l’insieme di tutti i DSD fa parte del modello di progetto.
113
cos'è un singleton?
Un singleton è un pattern nel quale da una classe viene istanziata una sola istanza. In particolare:
Un singleton è un design pattern creazionale che garantisce che una classe abbia una sola istanza e fornisce un punto di accesso globale a quella istanza.
114
cos'è un dcd?
Un diagramma delle classi di progetto è un diagramma delle classi utilizzato da un punto di vista software
o di progetto.
In UP l’insieme di tutti i DCD fa parte del modello di progetto.
115
cosa si intende per sterotipi?
Gli stereotipi sono un raffinamento di un concetto di modellazione esistente.
116
cos'è una generalizzazione?
La generalizzazione è una relazione tassonomica tra una classe più generale e una classe più specifica. Ogni istanza della classe specifica è anche un’istanza della classe generale.
Note:-
La generalizzazione implica ereditarietà nei linguaggi OO.
117
Cos'è una linea di dipendenza?
Una linea di dipendenza è una relazione tra due classi che indica che un cambiamento nella classe dipendente
può influenzare la classe dipendente.
È importante mantenere un basso accoppiamento tra le classi.
Esistono varie tipologie di dipendenze:
⇒ Avere un attributo del tipo del fornitore;
⇒ Inviare un messaggio al fornitore;
⇒ Ricevere un parametro del tipo del fornitore;
⇒ Il fornitore è una superclasse o un’interfaccia implementata.
118
Cos'è un'interfaccia?
Un’interfaccia è un contratto tra un fornitore e un cliente. Un cliente può invocare i metodi definiti
nell’interfaccia. Si hanno due notazioni:
⇒ Notazione a pallina (lollipop), indica che una classe X implementa (fornisce) un’interfaccia Y;
⇒ Notazione a semicerchio (socket), indica che una classe X richiede (usa) un’interfaccia Y.
119
Cosa intendiamo per responsabilità?
Per responsabilità si intende un’astrazione di ciò che fa o rappresenta un oggetto o un componente software.
Le responsabilità sono di due tipi:
⇒ Di fare;
⇒ Di conoscere.
In UML la responsabilità è un contratto o un obbligo di un oggetto
120
Quali sono i tipi di responsabilità?
Le responsabilità di fare comprendono:
✓ un oggetto fa qualcosa per sè stesso;
✓ un oggetto chiede ad altri oggetti di fare qualcosa;
✓ un oggetto controlla e coordina le attività di altri oggetti.
Le responsabilità di conoscere comprendono:
✓ un oggetto conosce i propri dati privati;
✓ un oggetto conosce le informazioni di oggetti correlati;
✓ un oggetto conosce informazioni che può ricavare o calcolare.
57
121
Elenca i passaggi di progettazione guidata dalle responsabilità
La progettazione guidata dalle responsabilità:
1. Identificare le responsabilità, considerandole una alla volta;
2. Decidere a quali oggetti assegnare le responsabilità. Potrebbero essere oggetti già esistenti o nuovi oggetti;
3. Capire come fa un oggetto a soddisfare le proprie responsabilità. Potrebbe farlo da solo o collaborando con
altri oggetti.
122
Definisci pattern GRASP
I principi e gli idiomi se codificati in un linguaggio strutturato, che descrive il problema e la soluzione e a
cui è assegnato un nome, diventano un pattern.
Un pattern è una coppia problema/soluzione ben conosciuta che può essere applicata in nuovi contesti con
compromessi, implementazioni, variazioni, etc.
123
Cosa si intende per LGR?
Quando si progetta vale LRG: si cerca di ridurre il divario tra il mondo reale e il mondo del software.
124
Cosa si intende per GRASP?
GRASP è l’acronimo di General Responsibility Assignment Software Patterns. Si tratta di un insieme di
linee guida per la progettazione orientata agli oggetti. I pattern GRASP sono dei principi generali che
possono essere applicati in modo flessibile e adattato a seconda del contesto. Sono un aiuto per acquisire
padronanza dell’OOD.
In totale i pattern grasp sono 9
125
Cosa si intende per progettazione modulare?
La progettazione modulare è un principio di progettazione che garantisce comprensibilità, modificabilità, impatto nei cambiamenti basso, flessibilità, riuso, semplicità: il software viene diviso in moduli coesi (High Cohesion) e
debolmente accoppiati (Low Coupling).
126
Pattern CREATOR? Da che esigenza nasce?
Problema: Chi crea un oggetto A? Chi deve essere responsabile della creazione di una nuova istanza di
una classe?
Soluzione: Assegnare alla classe B la responsabilità di creare un’istanza della classe A se una delle
seguenti condizioni è vera:
⇒ B aggrega o contiene A;
⇒ B registra Aa;
⇒ B utilizza strettamente A;
⇒ B ha i dati necessari per inizializzare A
(più condizioni sono vere meglio è)
Creator è correlato a Low Coupling. Creator favorisce il basso accoppiamento, riduce le dipendenze
e favorisce il riuso. Solitamente la classe creata deve essere già visibile a chi la crea.
127
Pattern INFORMATION EXPERT? Da che esigenze nasce?
Problema: Qual è un principio di base, generale, per l’assegnazione delle responsabilità agli oggetti?
Soluzione: Assegnare la responsabilità a un oggetto che ha le informazioni necessarie per soddisfarla.
⇒ Si individuano informazioni parziali di cui diverse classi sono esperte: queste classi possono collaborare
per soddisfare la responsabilità;
⇒ Gli oggetti software, a differenza degli oggetti reali, hanno la responsabilità di compiere azioni sulle
cose che conoscono
128
Pattern LOW COUPLING? A che esigenze risponde?
Problema: Come ridurre l’impatto dei cambiamenti? Come sostenere una dipendenza bassa, un impatto
dei cambiamenti basso e una maggiore opportunità di riuso?
Soluzione: Assegnare le responsabilità in modo tale che l’accoppiamento (non necessario) rimanga basso.
- low coupling è un pattern valutativo
- le classi generiche devono avere un accoppiamento basso
- una sottoclasse è fortemente accoppiata alla sua superclasse
- il problema è l'accoppiamento alto con classi instabili
129
Quali sono le classi più comuni di accoppiamento da un tipo x ad un tipo y?
⇒ La classe X ha un attributo di tipo Y o referenzia un’istanza di tipo Y o una collezione di oggetti Y;
⇒ Un oggetto di tipo X chiama un metodo di un oggetto Y;
⇒ Un oggetto di tipo X crea un oggetto di tipo Y;
⇒ Il tipo X ha un metodo che contiene un elemento di tipo Y o che referenzia un oggetto di tipo Y;
⇒ Una classe X è sottoclasse (diretta o indiretta) di una classe Y;
⇒ Y è un’interfaccia implementata da X.
130
cosa definiamo per accoppiamento?
L'accoppiamento è il grado di dipendenza o interdipendenza tra le diverse componenti di un sistema software. Indica quanto le classi, i moduli o i componenti di un sistema dipendano l'uno dall'altro per il corretto funzionamento dell'intero sistema
131
Pattern HIGH COESION? A che esigenze risponde?
Problema: Come mantenere gli oggetti focalizzati, comprensibili e gestibili e, come effetto collaterale,
sostenere Low Coupling?
Soluzione: Assegnare le responsabilità in modo tale che la coesione rimanga alta.
- high coesion è un pattern valutativo
-Un elemento con responsabilità altamente correlate che non esegue una quantità eccessiva di compiti
è altamente coeso;
132
Quali sono i tipi di coesione?
⇒ Coesione di dati: una classe implementa un tipo di dati (molto buona);
⇒ Coesione funzionale: gli elementi svolgono una singola funzione (buona o molto buona);
⇒ Coesione sequenziale: gli elementi sono raggruppati perchè usati nello stesso tempo (a volte buona,
a volte meno molto buona, dipende dall’utilizzoa);
⇒ Coesione per pura coincidenza: per esempio una classe che raggruppa tutti i metodi che iniziano con
una certa lettera dell’alfabeto (molto cattiva).
133
Quali sono i problemi legati alla bassa coesione? Quali sono i rari casi in cui è accettabile?
Problemi della bassa coesione:
⇒ Difficoltà di comprensione;
⇒ Difficoltà di manutenzione;
⇒ Difficoltà di riuso;
⇒ Continuamente cambiante.
In alcuni casi è accettabile avere bassa coesione:
⇒ Se per un compito di programmazione/manutenzione ci vuole un esperto;
⇒ Per gli oggetti distribuiti lato server
134
Pattern CONTROLLER? A che esigenze risponde?
Problema: Qual è il primo oggetto oltre lo strato UI che riceve e coordina (“controlla”) un’operazione
di sistema?
Soluzione: Assegnare le responsabilità a un oggetto che rappresenta una delle seguenti scelte:
⇒ Un oggetto che rappresenta il sistema (facede controller);
⇒ Un oggetto che rappresenta uno scenario di un Caso d’Uso (controller di Caso d’Uso o controller di
sessione).
- il controller è un pattern di delega
- il controller coordina le attività ma non le esegue
⇒ Si utilizza la classe controller per tutti gli eventi nello stesso scenario;
⇒ Una sessione è un’istanza di una conversazione con un attore. Generalmente una sessione corrisponde
a un’esecuzione di un Caso d’Uso;
⇒ Il controller conserva lo stato della sessione.
135
Controller grasp e controller mvc sono la stessa cosa?
Il Controller GRASP e il controller MVC sono due cose diverse. Il controller GRASP è un pattern di
progettazione orientato agli oggetti, mentre il controller MVC è un componente del pattern architetturale
MVC.
MVC:
⇒ Fa parte dell’UI e gestisce gli eventi dell’utente;
⇒ La sua implementazione dipende dalla tecnologia UI e della piattaforma.
GRASP:
⇒ Fa parte del dominio e gestisce le richieste del sistema;
⇒ Non dipende dall’UI utilizzata.
Generalmente il controller MVC delega le richieste dell’utente al controller GRASP.
136
Cosa sono i pattern gof?
I pattern GoF (Gang of Four) sono un insieme di 23 pattern di progettazione software, descritti nel libro
Design Patterns: Elements of Reusable Object-Oriented Software di Erich Gamma, Richard Helm, Ralph
Johnson e John Vlissides (vengono mostrati in C++, analizzando dei progetti di successo e delle soluzioni
a problemi ricorrenti). Si dividono in tre categorie:
-creazionali
-strutturali
-comportamentali
137
differenza tra pattern gof e grasp?
I pattern GoF sono degli "schemi di progettazione avanzata", mentre i pattern GRASP sono dei principi
di progettazione
138
definisci white e black box
-White-box, ossia la visibilità della superclasse è la visibilità della sottoclasse
-Black-box, ossia i dettagli interni non sono conosciuti
139
cosa risolvono i pattern creazionali? quali sono?
I pattern creazionali risolvono problematiche inerenti l’istanziamento degli oggetti.
Sono:
- abstract factory
-singleton
140
cosa risolvono i pattern strutturali? quali sono?
I pattern strutturali risolvono problematiche inerenti la struttura delle classi e degli oggetti.
sono:
- adapter
-composite
-decoraotr
141
cosa risolvono i pattern comportamentali? quali sono?
I pattern comportamentali risolvono problematiche inerenti riguardanti l’interazione tra oggetti.
Sono:
- observer
- state
- strategy
-visitor
142
Pattern ABSTRACT FACTORY? A che esigenze risponde?
Problema: Come creare famiglie di classi correlate che implementano un’interfaccia comune?
Soluzione: Definire un’interfaccia Factory (astratta). Definire una classe Factory concreta per
ogni famiglia di elementi da creare. Opzionalmente si può definire una classe astratta che implementi
l’interfaccia factory e fornisce servizi comuni alle factory che la estendono.
⇒ È possibile cambiare la famiglia di prodotti senza modificare il codice del cliente;
⇒ È possibile creare una classe AbstractFactory a cui si accede tramite un Singleton
143
Pattern SINGLETON? A che esigenze risponde?
Problema: È consentita (o richiesta) esattamente una sola istanza di una classe, ovvero un “singleton”.
Gli altri oggetti hanno bisogno di un punto di accesso globale e singolo a questo oggetto.
Soluzione: Si definisce un metodo statico della classe che restituisce l’istanza della classe stessa (Singleton).
⇒ Il Singleton definisce una classe della quale è possibile l’istanziazione di un unico oggetto tramite un
metodo statico incaricato di restituire l’istanza;
144
Quali sono i tre metodi implementativi in java dei singleton?
In JAVA ci sono tre possibili implementazioni del singleton:
⇒ Come classe statica: non è un vero Singleton, perchè si lavora con la classe e non con l’oggetto;
⇒ Creato da un metodo statico: la prima chiamata alla classe crea l’oggetto, le successive restituiscono
l’oggetto creato (inizializzazione pigra);
⇒ Multi-thread: versione a multi-thread della precedente.
Il Singleton creato da un metodo statico è preferibile al Singleton come classe statica perchè:
⇒ I metodi d’istanza consentono la ridefinizione nelle sottoclassi e il raffinamento;
⇒ La maggior parte dei meccanismi di comunicazione remota orientati agli oggetti supporta l’accesso
remoto solo a metodi d’istanza;
⇒ Una classe non è sempre un Singleton.
Struttura
145
Pattern ADAPTER? A che esigenze risponde?
Problema: Come gestire interfacce incompatibili o fornire un’interfaccia stabile a comportamenti simili
ma con interfacce diverse?
Soluzione: Si converte l’interfaccia originale di un componente in un’altra interfaccia attraverso un
adattatore intermedio.
- pattern spesso usato x incrementare la riusabilità del software
⇒ In una coppia client-server le interfacce sono incompatibili quando l’oggetto server offre servizi di
interesse per l’oggetto client, ma l’oggetto client vuole fruire di questi servizi in una modalità diversa
da quella offerta dall’oggetto server;
⇒ Ci sono più oggetti server che offrono servizi simili, che hanno interfacce simili, ma diverse. Un oggetto
client vuole fruire dei servizi di uno di questi oggetti server (componenti simili, ma con interfacce
diverse).
Generalmente:
1. Un adattatore riceve una richiesta da un client (nel formato del client);
2. L’adattatore converte la richiesta nel formato del server;
3. L’adattatore inoltra la richiesta al server;
4. Se il server fornisce una risposta lo fa nel suo formato;
5. L’adattatore converte la risposta nel formato del client e la restituisce al client
146
Pattern COMPOSITE ? A che esigenze risponde?
Problema: Come trattare un gruppo o una struttura composta di oggetti (polimorficamente) dello
stesso tipo nello stesso modo di un oggetto non composto (atomico)?
Soluzione: Si definiscono le classi per gli oggetti composti e atomici in modo che implementino la stessa
intefaccia.
Il pattern definisce una classe astratta componente che deve essere estesa in due sottoclassi:
⇒ Foglia: rappresenta un oggetto atomico;
⇒ Nodo: rappresenta un oggetto composto e si implementa come contenitore di componenti
147
Pattern DECORATOR ? A che esigenze risponde?
Problema: Come permettere l’assegnamento di una o più responsabilità a un oggetto in maniera dinamica
ed evitare il problema della relazione statica? Come provvedere un’alternativa più flessibile al
meccanismo di sottoclasse ed evitare il problema di avere una gerarchia di classi complessa?
Soluzione: Si ingloba l’oggetto all’interno di un altro che aggiunge le nuove funzionalità.
(simula l'extends)
- è anche chiamato wrapper
- evita l'esplosione delle sottoclassi (=la creazione di una classe per ogni combinazione di responsabilità)
-serve ad aggiungere responsabilità a oggetti individualmente, dinamicamente
148
Pattern OBSERVER ? A che esigenze risponde?
Problema:
Diversi tipi di oggetti subscriber desiderano reagire in modo personalizzato agli eventi del publisher, mantenendo un basso accoppiamento.
Soluzione:
Definire un'interfaccia subscriber o listener che gli oggetti subscriber implementano.
Il publisher registra dinamicamente i subscriber interessati ai suoi eventi e li notifica quando avvengono.
-definisce una dipendenza uno-a-molti
-L’oggetto che notifica il cambiamento di stato non fa nessuna assunzione sulla natura degli oggetti
notificati (sono disaccoppiati);
- Il numero degli oggetti affetti dal cambiamento di stato di un oggetto non è noto a priori;
149
Pattern STATE? A che esigenze risponde?
Problema: Il comportamento di un oggetto dipende dal suo stato e i suoi metodi contengono logica
condizionale per casi che riflette le azioni condizionali che dipendono dallo stato. C’è un’alternativa alla
logica condizionale?
Soluzione: Si creano delle classi stato per ciascuno stato che implementano un’interfaccia comune. Si
delegano le operazioni che dipendono dallo stato dell’oggetto contesto all’oggetto stato corrispondente. Si
assicura che l’oggetto contesto referenzi sempre un oggetto stato che riflette il suo stato corrente
permette ad un oggetto di modificare il suo comportamento quando il suo stato interno cambia
150
Pattern STRATEGY? A che esigenze risponde?
Problema: Come progettare per gestire un insieme di algoritmi o politiche variabili ma correlati? Come
progettare per consentire di modificare questi algoritmi o politiche?
Soluzione: Si definisce ciascun algoritmo/politica/strategia in una classe separata, con un’interfaccia
comune.
151
Definisci strategy e state
⇒ State si occupa di che cosa (stato o tipo) un oggetto è (al suo interno) e incapsula un comportamento
che dipende dallo stato;
⇒ Strategy si occupa di come un oggetto fa qualcosa e incapsula un algoritmo. Un’implementazione
diversa che realizza la stessa cosa, in modo che un’implementazione possa sostituire l’altra a seconda
della strategia richiesta
152
Pattern VISITOR ? A che esigenze risponde?
Problema: Come separare l’operazione applicata su un contenitore complesso dalla struttura dati cui
è applicata? Come poter aggiungere nuove operazioni e comportamenti senza dover modificare la struttura
stessa? Come attraversare il contenitore complesso i cui elementi sono eterogenei applicando azioni
dipendenti dal tipo degli elementi?
Soluzione: Si crea un oggetto (ConcreteVisitor) che è in grado di percorrere la collezione, e di applicare
un metodo proprio su un oggetto (Element) visitato nella collezione (avendo un riferimento a questi
ultimi come parametro). Ogni oggetto della collezione aderisce a un’interfaccia (Visitable) che consente al
ConcreteVisitor di essere accettato da parte di ogni Element. Il Visitor analizza il tipo di oggetto ricevuto,
fa l’invocazione alla particolare operazione che deve eseguire.
153
Cos'è un modello di implementazione?
Un modello di implementazione è costituito da tutti gli elaborati dell’implementazione, come il codice
sorgente, la definizione delle basi di dati, le pagine JSP/XML/HTML, etc.
⇒ L’implementazione è un processo di traduzione relativamente meccanico del progetto in co codice
154
Cos'è una collezione?
Una collezione è un contenitore di oggetti, che può essere usato per memorizzare, recuperare e manipolare
dati.
Note:-
Le relazioni uno a molti sono generalmente implementate tramite collezioni.
155
Cos'è un costruttore?
Un costruttore è un metodo speciale che viene invocato quando un oggetto viene creato.
⇒ I costruttori possono venir scritti per ispezione da un diagramma delle classi.
156
cosa si intende per pratica dei test? chi l'ha promossa?
l'ha promossa xp ed consiste nel scrivere i test prima di scrivere il codice
cioè si scrivono i test che si aspetta che il codice passi immaginando che il codice sorgente sia stato già scritto
157
quali sono i tipi di test?
⇒ Test unitari: testano singole unità di codice;
⇒ Test di integrazione: testano la comunicazione tra specifiche parti;
⇒ Test end-to-end: testano l’intero sistema;
⇒ Test di accettazione: testano il sistema, considerandolo a scatola nera, dal punto di vista dell’utente (con
riferimento ai Casi d’Uso).
158
Quali sono le fasi dei test unitari?
1. Preparazione: si ccrea l’oggetto (o il gruppo di oggetti) da testare (fixture) e si preparano altri oggetti e/o
risorse necessarie per i test;
2. Esecuzione: si fa fare qualcosa alla fixture, viene richiesto un comportamento specifico;
3. Verifica: si verifica che i risultati ottenuti siano quelli attesi;
4. Rilascio: si rilascia la fixture e si puliscono le risorse (per evitare la corruzione di altri test).
dopo ciascuna trasformazione si eseguono i test unitari x verificare che il refactoring non abbia provocato una regressione
158
Cos'è il refactoring? chi l'ha promosso?
Il refactoring è un metodo strutturato e disciplinato per scrivere o ristrutturare del codice esistente, senza
cambiarne il comportamento esterno. Si applicano piccoli passi di trasformazione in combinazione con i
test a ogni passo
l'ha promosso xp e consiste nella modifica del codice per renderlo più chiaro e semplice da capire, con meno duplicazioni.
159
quali sono gli obiettivi del refactoring?
Gli obiettivi del refactoring sono:
⇒ Migliorare la leggibilità del codice;
⇒ Eliminare il codice duplicato;
⇒ Eliminare l’uso dei letterali costanti hard-coded;
⇒ Abbreviare i metodi lunghi.
