modificabilità - luca cabibbocabibbo.dia.uniroma3.it/asw/pdf/asw230-modificabilita.pdf ·...
TRANSCRIPT
Architettura dei Sistemi
Software
Luca Cabibbo
Luca Cabibbo ASWLuca Cabibbo ASW
Modificabilità
dispensa asw230
marzo 2019
Modificabilità1
Everything changes and nothing stands still.
Heraclitus
Luca Cabibbo ASW
- Fonti
[SAP] Chapter 7, Modifiability
[SSA] Chapter 28, The Evolution Perspective
Parnas, D.L. On the Criteria To Be Used in Decomposing Systems into Modules. Communications of the ACM. 1972.
Bachmann, F., Bass, L., and Nord, R. Modifiability Tactics. Technical report CMU/SEI-2007-TR-002. 2007.
Martin, R.C. and Martin, M. Agile Principles, Patterns, and Practices in C#. Prentice Hall, 2007.
Modificabilità2
Luca Cabibbo ASW
- Obiettivi e argomenti
Obiettivi
presentare la qualità della modificabilità
illustrare alcune attività e tattiche per la progettazione per la modificabilità
Argomenti
modificabilità
progettare per la modificabilità
discussione
Modificabilità3
Luca Cabibbo ASW
* Modificabilità
Modificabilità (modifiability)
la capacità del sistema di essere flessibile a fronte di cambiamenti inevitabili dopo il suo rilascio iniziale, in modo bilanciato rispetto ai costi di fornire tale flessibilità
La modificabilità riguarda i cambiamenti e il costo per realizzare tali cambiamenti
la modificabilità misura la facilità con cui un sistema software può accomodare cambiamenti
una qualità spesso importante – poiché il successo di un sistema può dipendere da come quel sistema sostiene anche gli interessi futuri di un’organizzazione, e non solo quelli correnti
questa qualità riguarda dunque anche l’evoluzione (evolution) del sistema
Modificabilità4
Luca Cabibbo ASW
Modificabilità
I cambiamenti del software sono ubiqui e comuni
possono riguardare diversi aspetti
correggere difetti e migliorare alcune qualità
aggiungere, modificare o rimuovere funzionalità
migliorare l’esperienza d’uso del sistema
abbracciare nuove tecnologie, nuove piattaforme, nuovi protocolli e standard
far interoperare sistemi diversi – anche se non sono stati inizialmente progettati per farlo
possono avvenire in qualunque momento della vita di un sistema software
non solo durante lo sviluppo iniziale del sistema
ma anche e soprattutto dopo che il sistema è stato rilasciato
Modificabilità5
Luca Cabibbo ASW
Identificare gli scenari di modificabilità
Nella pianificazione per i cambiamenti, è necessario identificare i requisiti architetturalmente significativi di modificabilità
ciascun (tipo di) cambiamento atteso (rilevante, e che pertanto richiede un supporto architetturale) costituisce uno scenario di modificabilità del sistema – lo scenario include anche una specifica del costo previsto per modificare il sistema in modo da realizzare tale cambiamento
si tratta di solito di cambiamenti che devono essere gestiti in modo efficace per sostenere il business di un’organizzazione
A tal fine, è utile prendere in considerazione diverse domande
che cosa potrà cambiare?
qual è la probabilità del cambiamento?
quando sarà effettuato il cambiamento? e chi lo effettuerà?
come viene misurato il costo del cambiamento?
Modificabilità6
Luca Cabibbo ASW
Identificare gli scenari di modificabilità
Che cosa potrà cambiare?
ogni cambiamento può riguardare un certo aspetto del sistema – come una funzionalità, la piattaforma di esecuzione o un protocollo per comunicare con altri sistemi
qui ipotizziamo che l’unità di modifica sia una generica “responsabilità”
una responsabilità è un’azione, una decisione da prendere o una conoscenza da mantenere da parte di un sistema software o di un suo elemento
Qual è la probabilità del cambiamento?
poiché non è possibile progettare un sistema per essere facilmente modificabile a fronte di ogni possibile cambiamento, è necessario identificare i cambiamenti più significativi e più probabili
Modificabilità7
Luca Cabibbo ASW
Identificare gli scenari di modificabilità
Quando sarà effettuato il cambiamento? E chi lo effettuerà?
i cambiamenti possono essere fatti in momenti e modi diversi –e da persone differenti
dagli sviluppatori del sistema – nell’implementazione (cambiando il codice sorgente) o nella compilazione o costruzione (cambiando la scelta dei moduli o delle librerie)
dagli amministratori del sistema – nella configurazione o nel rilascio
dagli utenti finali del sistema – durante l’esecuzione
per ogni cambiamento atteso, bisogna capire quando gestirlo e chi dovrà gestirlo
in questa dispensa ci concentriamo soprattutto su cambiamenti che devono essere effettuati dagli sviluppatori
Modificabilità8
Luca Cabibbo ASW
Identificare gli scenari di modificabilità
Come viene misurato il costo del cambiamento?
il “costo” speso per un cambiamento in genere comprende il tempo e il costo richiesto per implementare, verificare e rilasciare il cambiamento
in questa dispensa ci concentriamo soprattutto sul costo per implementare un cambiamento (nel contesto di cambiamenti che devono essere effettuati dagli sviluppatori)
gli aspetti della verifica e del rilascio (che sono comunque importanti) verranno trattati in successive dispense
Modificabilità9
Luca Cabibbo ASW
- Considerazioni sulla modificabilità
Contributi principali al costo (atteso) richiesto per modificare una certa responsabilità R
costo (atteso) della modifica relativa direttamente alla singola responsabilità R
la modifica avverrà nell’ambito dell’elemento ER a cui è assegnata la responsabilità R
costo (atteso) della modifica di tutte le responsabilità Ri a cui la modifica va propagata
queste modifiche avverranno nell’ambito di elementi che dipendono (direttamente o indirettamente) da ER
questo costo va pesato rispetto alla probabilità che una modifica di R (ER) richieda anche una modifica di Ri (ERi)
costo della verifica della modifica
costo del rilascio della modifica
Modificabilità10
Luca Cabibbo ASW
Modificabilità, accoppiamento e coesione
La modificabilità di un sistema è correlata a misure/metriche come la coesione, l’accoppiamento e la dimensione degli elementi
la coesione è una misura della forza delle relazioni tra le responsabilità di uno specifico modulo
la coesione misura l’“unità dello scopo” del modulo
per questo, è anche una misura (diretta) della probabilità che uno scenario di cambiamento che ha impatto su una responsabilità di un modulo possa essere soddisfatta solo nell’ambito di quel modulo
volendo, è anche una misura (inversa) della probabilità che un cambiamento che ha impatto su una responsabilità di un modulo richieda anche il cambiamento di responsabilità differenti (di altri moduli)
Modificabilità11
Luca Cabibbo ASW
Modificabilità, accoppiamento e coesione
La modificabilità di un sistema è correlata a misure/metriche come la coesione, l’accoppiamento e la dimensione degli elementi
l’accoppiamento è una misura della forza delle dipendenze tra moduli
per questo, è anche una misura (diretta) della probabilità che un cambiamento che ha impatto su una responsabilità richieda anche il cambiamento di responsabilità differenti
l’accoppiamento si riduce quando le relazioni tra elementi che non appartengono allo stesso modulo sono ridotte o comunque deboli
Modificabilità12
Luca Cabibbo ASW
Modificabilità, accoppiamento e coesione
La modificabilità di un sistema è correlata a misure/metriche come la coesione, l’accoppiamento e la dimensione degli elementi
in pratica, anche la dimensione di un modulo può avere impatto sul costo per modificare il modulo
decomporre un modulo in più parti può ridurre il costo dei cambiamenti – ma solo nella misura in cui la decomposizione aumenta la coesione e diminuisce l’accoppiamento (o comunque non lo aumenta) – e, soprattutto, nella misura in cui la decomposizione riflette il tipo di cambiamenti che si possono verificare
Modificabilità13
Luca Cabibbo ASW
Modificabilità, accoppiamento e coesione
La modificabilità di un sistema è correlata a misure/metriche come la coesione, l’accoppiamento e la dimensione degli elementi
intuitivamente – e comunque solo in prima approssimazione
il costo della modifica della responsabilità R nell’ambito dell’elemento ER (a cui è assegnata la responsabilità R) è commisurato (in modo inverso) alla coesione di ER
il costo delle modifiche in altri elementi diversi da ER è commisurato (in modo diretto) all’accoppiamento degli altri elementi software verso ER
il costo della modifica di un elemento E è in genere commisurato (in modo inverso) anche alla dimensione di E
per questo, di solito la coesione del sistema deve essere alta e l’accoppiamento deve essere basso
Modificabilità14
Luca Cabibbo ASW
Forme di coesione
Alcune forme di coesione (OOP) – più o meno buone
coesione per pura coincidenza
coesione logica – gli elementi raggruppati in un modulo sono logicamente correlati, ma implementati in modo indipendente
coesione temporale – gli elementi sono usati all’incirca nello stesso tempo
coesione di comunicazione – gli elementi devono accedere agli stessi dati o dispositivi
coesione sequenziale – gli elementi sono usati in un ordine particolare
coesione funzionale – gli elementi contribuiscono a svolgere una singola funzione
coesione dei dati – un modulo implementa un tipo di dato
Modificabilità15
Luca Cabibbo ASW
Forme di accoppiamento
Alcune forme di accoppiamento (OOP) – più o meno cattive
accoppiamento di dati interni – un modulo accede e modifica direttamente i dati di un altro modulo
accoppiamento mediante dati globali – due o più moduli condividono dati globali
accoppiamento di controllo – un modulo definisce delle operazioni, ma l’ordine in cui vanno eseguite è controllato altrove
accoppiamento di componenti – un modulo conosce altri moduli o gestisce istanze di altri moduli
accoppiamento mediante interfaccia e parametri – un modulo richiede l’esecuzione di operazioni ad altri moduli
accoppiamento per estensione – un modulo implementa un’interfaccia specificata da un altro modulo oppure estende le funzionalità di un altro modulo
Modificabilità16
Luca Cabibbo ASW
Forme di accoppiamento
Altre forme di accoppiamento (più specifiche per i sistemi distribuiti) – tra il client C di un componente o servizio S
accoppiamento di piattaforma – se il client C deve essere realizzato con la stessa tecnologia del componente o servizio S
accoppiamento temporale – se il client C deve accedere il componente o servizio S in modo sincrono
accoppiamento spaziale – se il client C deve conoscere la locazione del componente o servizio S
accoppiamento nel rilascio – se il rilascio di una nuova versione del componente o servizio S richiede anche il rilascio contestuale di una nuova versione del client C
accoppiamento tra i team di sviluppo – riguarda il coordinamento richiesto tra il team che sviluppa il client C e il team che sviluppa il componente o servizio S
Modificabilità17
Luca Cabibbo ASW
Forme di accoppiamento
Altre forme di accoppiamento – tra una coppia di elementi A e B
sintassi dei dati o dei servizi – ad es., B dipende dal prototipo di un’operazione di A, o dal formato dei messaggi scambiati con A
semantica dei dati o dei servizi – assunzioni (contratti) su messaggi e operazioni
identità dell’interfaccia – ad es., B dipende da (il nome di) un’interfaccia implementata da A
locazione – B dipende dalla locazione runtime di A
qualità del servizi/dei dati – B dipende dalla qualità del servizio/dei dati offerti da A
esistenza – B dipende dall’esistenza di A
Modificabilità18
Luca Cabibbo ASW
Modificabilità, verifica e rilascio
Altri contributi al costo di una modifica sono relativi ai costi per effettuare la verifica (test) e poi il rilascio (delivery) del sistema software aggiornato (ovvero, di una nuova versione)
il primo costo dipende dalla verificabilità del sistema – che esamineremo in una successiva dispensa
il costo del rilascio dipende sia dall’architettura di deployment(ambiente di esecuzione) del sistema sia dal modo in cui viene effettuata la delivery (manuale o automatizzata) – ma anche dallo specifico elemento che va modificato
ad es., la modifica di un componente server va rilasciata solo sul server – ma la modifica di un componente client potrebbe dover essere rilasciata su numerosi client
in generale, questo aspetto coinvolge anche la vista di Deployment e la vista Operational
torneremo su questi aspetti in dispense successive
Modificabilità19
Luca Cabibbo ASW
* Progettare per la modificabilità
Alcune attività nella progettazione per la modificabilità e l’evoluzione di un sistema [SSA]
identifica le necessità di evoluzione
identifica le tipologie di cambiamento atteso più significative per il sistema, e valuta il loro potenziale impatto e la loro probabilità
decidi quando dovrà essere gestito ciascun cambiamento, chi dovrà farlo e come
valuta la modificabilità corrente del sistema
“scegli le tue battaglie”
raffina l’architettura
Modificabilità20
Luca Cabibbo ASW
- Tattiche per la modificabilità
[SAP] propone tattiche per la modificabilità per controllare il tempo e il costo per implementare, testare e rilasciare un cambiamento atteso
si osservi che, nella progettazione dell’architettura
l’architetto non deve effettuare ora il cambiamento
piuttosto, deve garantire che certi tipi di cambiamenti attesipotranno essere gestiti facilmente in futuro
Modificabilità21
Luca Cabibbo ASW
Tattiche come trasformazioni
Nella progettazione, le responsabilità sono assegnate a elementi software e, in particolare, a moduli (unità di sviluppo e, pertanto, di modifica)
un aspetto fondamentale relativo alle tattiche per la modificabilità è la possibilità di riorganizzare responsabilità –“elimina, combina, riorganizza e semplifica”
una responsabilità può essere decomposta in più sotto-responsabilità separate
più responsabilità (o sotto-responsabilità) possono essere fuse
una responsabilità (o sotto-responsabilità) può essere mossa da un elemento (modulo) a un altro
l’obiettivo dell’applicazione delle tattiche per la modificabilità è identificare un insieme di elementi insieme ad un’assegnazione di responsabilità che minimizzino il costo dei cambiamenti attesi
Modificabilità22
Luca Cabibbo ASW
Categorie di tattiche per la modificabilità
Categorie principali di tattiche per la modificabilità
reduce size of a module
per ridurre il costo di modificare una singola responsabilità
increase cohesion
per ridurre il costo dei cambiamenti intervenendo sulla coesione del sistema
reduce coupling
per ridurre il costo dei cambiamenti intervenendo sull’accoppiamento del sistema, per prevenire una propagazione a cascata delle modifiche
defer binding
per controllare il tempo e il modo in cui effettuare la modifica e il suo rilascio
Modificabilità23
Luca Cabibbo ASW
- Reduce the size of a module
Un approccio di base per ridurre il costo di una modifica (di una singola responsabilità) è separare le responsabilità in base ai cambiamenti previsti
Split module
sia R la responsabilità che è il target di una particolare modifica – ovvero, di uno specifico scenario di modificabilità – sia inoltre M il modulo a cui è assegnata la responsabilità R
se il modulo M comprende molte capacità/funzionalità (oltre a R), allora il costo della modifica sarà alto
se la modifica ha impatto solo su una porzione di M, allora è possibile ridurre il costo atteso della modifica decomponendo il modulo M in moduli più piccoli, e ripartendo le responsabilità iniziali di M a questi moduli
un criterio per separare responsabilità in modo efficace è che i moduli piccoli possano essere modificati separatamente
Modificabilità24
Luca Cabibbo ASW
Split module
Modificabilità25
AA1 A2
Luca Cabibbo ASW
Esempio: Split module
Esempio
il nostro sistema deve interagire con un altro sistema (ad es., esterno) per fruire di un servizio
cambiamento atteso: fruire il servizio da un sistema differente
questo cambiamento può essere gestito mediante un Adapter
il cambiamento atteso viene isolato utilizzando un’interfaccia e il polimorfismo
nel momento in cui è necessario fruire il servizio da un altro sistema esterno, è possibile definire un nuovo Adapter –scrivendo nuovo codice, ma senza modificare il codice esistente
si noti che, quando è possibile, talvolta è preferibile gestire i cambiamenti scrivendo nuovo codice, ma senza modificare il codice esistente
Modificabilità26
Luca Cabibbo ASW
- Increase cohesion
Le tattiche per aumentare la coesione hanno in genere l’obiettivo di ridurre il numero di moduli sui quali un certo cambiamento si ripercuote direttamente
ovvero, moduli le cui responsabilità vanno cambiate per realizzare il cambiamento richiesto
sebbene non ci sia necessariamente una relazione precisa tra il numero di moduli su cui si ripercuote un cambiamento e il costo di implementare il cambiamento, ridurre le modifiche a un piccolo insieme di moduli ha generalmente l’effetto di ridurre tale costo
lo scopo di queste tattiche è assegnare (durante la progettazione) responsabilità a moduli in modo che ciascuno dei cambiamenti previsti abbia una portata limitata
Una sola tattica in questa categoria
increase semantic coherenceModificabilità27
Luca Cabibbo ASW
Increase semantic coherence
Increase semantic coherence
la coerenza semantica si riferisce alle relazioni tra le responsabilità assegnate ad un modulo anche con riferimento a un insieme di cambiamenti attesi
scopo è garantire che tutte queste responsabilità lavorino insieme – senza far eccessivo affidamento ad altri moduli
questo è possibile scegliendo e assegnando responsabilità che hanno coerenza semantica
Modificabilità28
Luca Cabibbo ASW
Increase semantic coherence
Increase semantic coherence
le metriche di accoppiamento e coesione sono un tentativo di misurare la coerenza semantica
certamente è bene iniziare l’assegnazione di responsabilità sulla base di forme opportune di coesione e accoppiamento
tuttavia, queste metriche non prendono in considerazione il contesto dei cambiamenti previsti
viceversa, la coerenza semantica, rispetto alla coesione, è misurata anche rispetto a un insieme di cambiamenti previsti
Modificabilità29
Luca Cabibbo ASW
Increase semantic coherence
Si consideri il seguente esempio
siano A e B delle responsabilità che sono coese rispetto ad un qualche criterio, ad esempio funzionale
un cambiamento atteso da gestire si ripercuote su A’A e B’B
in questo caso, potrebbe essere utile
collocare in uno stesso elemento A’ e B’ – poiché hanno “coerenza semantica” (ovvero, sono responsabili di un cambiamento atteso e significativo nel sistema)
collocare A-A’ e B-B’ in elementi diversi
attenzione, questo è solo un esempio
Modificabilità30
Luca Cabibbo ASW
Increase semantic coherence
Modificabilità31
B B1B2AA1 A2
C
Attenzione, è solo un esempio dell’applicazione di increase semantic
coherence. Non sempre questa tattica si applica
così.
Luca Cabibbo ASW
Esempio: Increase semantic coherence
Esempio
protocolli di rete
cambiamenti attesi: definire nuovi protocolli applicativi, variare protocolli esistenti, fornire nuove implementazioni dei protocolli con riferimento a nuovi tipi di hardware
i protocolli di rete sono implementati distribuendo i diversi tipi di responsabilità in una pila di strati – e raggruppando le responsabilità in modo che abbiano qualche forma di coerenza semantica
ad esempio, responsabilità relative all’hardware sono allocate nello strato dei protocolli a livello fisico, e non nello strato dei protocolli applicativi
in genere, i cambiamenti attesi sono relativi a un singolo tipo di responsabilità – pertanto, ciascuno di questi cambiamenti potrà essere gestito nell’ambito di un singolo strato
Modificabilità32
Luca Cabibbo ASW
Un criterio per la decomposizione in moduli
Un celebre articolo di [Parnas] del 1972 suggerisce il seguente criterio per la decomposizione in moduli di un sistema
“we propose that one begins with a list of difficult design decisions or design decisions which are likely to change – each module is then designed to hide such a decision from the others”
in questo criterio è possibile trovare due contributi significativi
ciascuna decisione di progetto difficile oppure soggetta a cambiamento – in particolare, relativa a un cambiamento previsto – va assegnata a un modulo diverso – “increasesemantic coherence”
queste decisioni vanno nascoste ad altri moduli – è un suggerimento della tattica “encapsulate” (descritta più avanti)
Modificabilità33
Luca Cabibbo ASW
- Reduce coupling
Le tattiche per ridurre l’accoppiamento hanno in genere l’obiettivo di ridurre il numero di moduli sui quali un certo cambiamento atteso si ripercuote indirettamente
ovvero, moduli le cui responsabilità non vanno cambiate direttamente per realizzare quel cambiamento
ma si può doverne comunque cambiare l’implementazione per accomodare cambiamenti in altri moduli
Un ripple effect da una modifica è la necessità di effettuare un cambiamento a moduli su cui la modifica non si ripercuote direttamente
ad es., A viene modificato (a causa di un cambiamento richiesto M), ma anche B va modificato (non per il cambiamento M, ma a causa delle modifiche in A)
questo è in genere motivato da una qualche forma di accoppiamento/dipendenza di B da A
Modificabilità34
Luca Cabibbo ASW
Encapsulate
Encapsulate
l’incapsulamento di un elemento software separa in modo esplicito la sua interfaccia – pubblica e stabile – dalla sua implementazione – privata e soggetta ad evoluzioni e variazioni
l’interfaccia pubblica di un elemento rende disponibili le sue responsabilità e funzionalità agli altri elementi
ovvero, deve essere possibile interagire direttamente con un elemento software solo tramite l’interfaccia che espone, ed ignorando la sua implementazione
l’incapsulamento di un elemento A, basato su un’interfaccia stabile, ha lo scopo di ridurre la probabilità di propagazione dei cambiamenti nell’elemento A verso altri elementi
il criterio di decomposizione dell’incapsulamento è quello di isolare ciascun cambiamento atteso in un singolo modulo, per prevenire la propagazione dei cambiamenti ad altri moduli [Parnas]
Modificabilità35
Luca Cabibbo ASW
Encapsulate
Esempio
L’introduzione dell’interfaccia IA riduce l’accoppiamento tra C1 e C2 ed A
non cambiano solo le “dipendenze” – ma anche la loro “forza” – rappresentata dallo spessore delle frecce
protegge C1 e C2 da cambiamenti nell’implementazione di A
Modificabilità36
C2
C1
AIA
C2
C1
A
dopoprima
Luca Cabibbo ASW
Esempio: Encapsulate
Esempio
nella pila dei protocolli di rete, ogni protocollo è implementato sulla base di servizi offerti dallo strato inferiore
questi servizi sono fruiti sulla base di un’interfaccia – e sono indipendenti dalla specifica implementazione – questa indipendenza favorisce la modificabilità dei diversi servizi
l’accesso a una base di dati avviene sulla base di uno schema logico (tabelle, colonne, chiavi, ecc.) – che incapsula lo schema fisico della base di dati
è possibile intervenire sullo schema fisico della base di dati per ottimizzare l’accesso alla base di dati stessa – senza doverne cambiare lo schema logico – né le applicazioni che la accedono
Modificabilità37
Luca Cabibbo ASW
Dependency Inversion Principle
L’incapsulamento (l’uso di interfacce) è un’importante tattica di progettazione del software – esistono numerosi principi che specializzano questa tattica – eccone uno rilevante
Dependency Inversion Principle (DIP) [Martin]
i moduli di alto livello non dovrebbero dipendere dai moduli di basso livello – piuttosto, entrambi dovrebbero dipendere da opportune astrazioni
le astrazioni non dovrebbero dipendere dai dettagli –piuttosto, i dettagli dovrebbero dipendere dalle astrazioni
questo principio consente di trasformare una dipendenza AB in una dipendenza inversa AB (vedremo tra poco come)
in particolare, DIP suggerisce di applicare questa inversione quando l’indipendenza di A sia più importante dell’indipendenza di B – ovvero, quando A è di “alto livello” e B è di “basso livello”
Modificabilità38
Luca Cabibbo ASW
Esempio: Dependency Inversion Principle
Si consideri un componente A che deve richiedere dei servizi ad un altro componente B (A dipende da B), mediante la sua interfaccia IB si supponga che in realtà si voglia poter sviluppare, verificare e
far evolvere A in modo indipendente da B
DIP propone di invertire la dipendenza, usando un’interfaccia IAdi “proprietà” del componente A, ma implementata da B
infatti, l’implementazione di un’interfaccia dipende dall’interfaccia che implementa – ma un’interfaccia non dipende dalle sue implementazioni
Modificabilità39
dopoprima
A B
IB
A B
A B
IA
A B
Luca Cabibbo ASW
Use an intermediary
Use an intermediary
un intermediario è un elemento introdotto per rompere la dipendenza (indesiderata) tra un elemento A e un elemento B
all’intermediario viene assegnata proprio la responsabilità di gestire le attività associate con la dipendenza
il tipo di intermediario da utilizzare dipende dal tipo di dipendenza che si vuole rompere
ad es., se A produce messaggi e B li consuma, un canale di comunicazione può rimuovere la necessità che A debba conoscere che il consumatore dei suoi messaggi sia B
alcuni esempi di intermediari
un design pattern per ridurre la dipendenza dai servizi – ad es., facade, proxy, adapter, bridge, mediator, ...
un broker o un servizio di directory
una factory, per ridurre la dipendenza dall’esistenza Modificabilità40
Luca Cabibbo ASW
Esempio: Use an intermediary
Esempio
l’accesso a una base di dati da parte di un’applicazione avviene mediante il suo schema esterno (ovvero, un insieme di viste sullo schema logico) – lo schema esterno è un intermediario che fornisce una vista dei dati della base di dati specifica per l’applicazione
in alcuni casi, il cambiamento di un’applicazione può essere gestito ridefinendo il suo schema esterno – ma senza cambiare lo schema logico della base di dati
in casi più complessi, è necessario cambiare anche lo schema logico della base di dati – ma le altre applicazioni possono essere protette da questo cambiamento adeguando i loro schemi esterni (che è meno costoso che non cambiare le applicazioni)
Modificabilità41
Luca Cabibbo ASW
Restrict dependencies
Restrict dependencies
si tratta di un caso speciale dell’uso di un intermediario
questa tattica consiste nel rimuovere una dipendenza relativa a una necessità di comunicazione, riducendo l’insieme (ovvero, il numero) dei moduli con cui ciascun modulo può comunicare direttamente – questa comunicazione può essere poi incanalata e gestita da un intermediario
applicazioni di questa tattica si possono trovare, ad esempio, nell’architettura a strati stretta e nello stile pipes-and-filters
Esempio
Modificabilità42
dopoprima
A’ B’ C’ D’A B C D
Luca Cabibbo ASW
Refactor
Refactor
questa tattica generalizza la tecnica del refactoring (sviluppata nel contesto dei metodi agili) ad un contesto architetturale
in generale, l’obiettivo è ridurre duplicazioni nel codice (che sono una forma di accoppiamento)
ad esempio, un cambiamento atteso potrebbe avere impatto (con riferimento all’architettura corrente) su due moduli, perché questi moduli hanno delle responsabilità duplicate (almeno in modo parziale)
in questo caso, è possibile estrarre queste responsabilità dai due moduli e metterle a “fattor” comune – in modo che il cambiamento possa essere effettuato in un solo modulo, una sola volta
la co-locazione di responsabilità comuni riduce l’accoppiamento – dato che l’accoppiamento misura le dipendenze tra moduli differenti
Modificabilità43
Luca Cabibbo ASW
Refactor
Si consideri il seguente esempio
un modulo offre un servizio A’ – un altro modulo offre un altro servizio A’’, che è una variante di A’
allora può essere utile definire un servizio comune A più generale di A’ e A’’ – implementandolo una sola volta, in una forma leggermente più generale
ogni modifica del servizio A dovrà poi essere realizzata (e verificata) una sola volta anziché due volte
più in generale, il refactoring può essere applicato per generalizzare responsabilità simili
Modificabilità44
Luca Cabibbo ASW
Refactor
Modificabilità45
A2A1
A
Luca Cabibbo ASW
Abstract common services
Abstract common services
un modo per sostenere il riuso è realizzare moduli specializzati che forniscono servizi comuni ad altri moduli
se questi servizi comuni sono a un livello opportuno di astrazione (ovvero, implementati in una forma generale, più generale che non rispetto ai singoli utilizzi), allora è sostenuta anche la modificabilità
infatti, modifiche ai servizi comuni vanno realizzate solo una volta – piuttosto che in tutte le versioni specifiche dei servizi
un modo comune nel rendere un servizio più astratto è basato su una parametrizzazione delle sue attività
i clienti del servizio fanno richieste specificando parametri –spesso definiti in termini di un “linguaggio” opportuno
obiettivo è fare in modo che molti cambiamenti possano essere gestiti cambiando semplicemente la scelta dei parametri
Modificabilità46
Luca Cabibbo ASW
Esempio: Abstract common services
Esempio
una base di dati viene acceduta mediante istruzioni SQL – e non mediante operazioni procedurali di accesso ai dati
alcuni componenti offrono un’interfaccia a messaggi/documenti anziché un’interfaccia procedurale – l’accoppiamento con un componente che ha un’interfaccia a messaggi è considerato solitamente inferiore all’accoppiamento con un componente che ha un’interfaccia procedurale
Modificabilità47
Luca Cabibbo ASW
Esempio: Abstract common services
Esempio
un browser web – che supporta plug-in dedicati alla presentazione di contenuti specifici
cambiamenti attesi: cambiamenti (miglioramenti) nelle funzionalità base del browser devono poter essere fruite dai diversi plug-in – e non devono richiedere un loro aggiornamento
il browser può fornire ai suoi plug-in un insieme di servizi di base comuni – che i diversi plug-in possono utilizzare per realizzare funzionalità più complesse o specifiche
questo avverrà più facilmente se i servizi offerti dal browser sono effettivamente comuni e astratti, ovvero indipendenti da ogni specifico (plug-in) consumatore dei servizi
Modificabilità48
Luca Cabibbo ASW
- Defer binding
Il costo di una modifica dipende anche dal momento (nel ciclo di vita dello sviluppo) in cui è possibile effettuare quella modifica –questo porta a un’ulteriore categoria di tattiche per la modificabilità – che sono in parte trasversali alle precedenti
intuizione: finché c’è un’opportuna preparazione, più tardi nel ciclo di vita di un sistema si verifica una modifica, minore è il suo costo
la chiave è l’opportuna preparazione
esempio: se il software per una modifica è stato già sviluppato e verificato, allora quando verrà richiesta l’applicazione della modifica sarà sufficiente attivarla
questo è meno costoso (in termini di costo per effettuare il cambiamento, anche se non di costo per lo sviluppo iniziale del sistema) che non iniziare a sviluppare per la modifica solo quando questa verrà richiesta
Modificabilità49
Luca Cabibbo ASW
Defer binding
Le tattiche nella categoria Defer binding (rimanda/posticipa il collegamento/l’attivazione di una modifica)
richiedono che le specifiche modifiche siano note (più o meno bene) in anticipo
ad esempio, la modifica è nota con precisione, oppure è nota la “tipologia” della modifica
il loro scopo è controllare il tempo e il modo (e il costo) per effettuare una modifica e il suo rilascio
Modificabilità50
Luca Cabibbo ASW
Defer binding
Tattiche per effettuare modifiche al tempo della codifica
parametrizzare i moduli
un modulo è sufficientemente generale per gestire una varietà di attività, che possono essere selezionate usando opportuni parametri
usare il polimorfismo
il polimorfismo è basato sull’identificazione di responsabilità che sono comuni ad un insieme di servizi
consente di fare plug-and-play di elementi software che offrono tali servizi – senza ripercussioni sui loro client
usare la programmazione orientata agli aspetti (AOP)
l’AOP è basata sull’uso di aspetti, specifici per la gestione di alcune responsabilità, che sono mantenuti separati dal resto del codice
Modificabilità51
Luca Cabibbo ASW
Defer binding
Tattiche per effettuare modifiche al momento della compilazione
sostituzione di componenti
ad es., specificare la versione di un componente da usare nello script di build
Tattiche per effettuare modifiche al momento dell’installazione (deployment)
collegamento al momento della configurazione
i servizi da selezionare devono essere stati “astratti” e generalizzati
l’infrastruttura usata deve consentire di selezionare i servizi o componenti da utilizzare al momento dell’installazione
Modificabilità52
Luca Cabibbo ASW
Defer binding
Tattiche per effettuare modifiche al momento dell’avvio (initialization time)
file di risorse – ad es., un file di configurazione, che consente di scegliere i parametri di esecuzione per un modulo
collegamento al momento dello start-up – ad es., con parametri specificati al momento dell’avvio
Tattiche per effettuare modifiche a runtime
registrazione a runtime – di parametri e servizi, in un registry
lookup dinamico – di parametri e servizi, da un registry
interpretazione di parametri – in un modulo sufficientemente generale e parametrizzato
uso di plug-in
metadati e riflessione
Modificabilità53
Luca Cabibbo ASW
Tattiche per la modificabilità
Sintesi delle principali tattiche per la modificabilità di [SAP]
Modificabilità54
Modifiability
Reduce Sizeof a Module
IncreaseCohesion
Defer Binding
changearrives
changemade, tested, and deployed
within time and budget
Reducing Coupling
increasesemantic
coherence
encapsulatesplit module
use anintermediary
polymorphism
...
...
Luca Cabibbo ASW
- Discussione
Le tattiche per la modificabilità che sono state presentate
esemplificano l’idea di “tattica come trasformazione”
l’applicazione di una tattica può cambiare la scelta degli elementi, l’assegnazione di responsabilità agli elementi, la portata e i confini degli elementi e/o le relazioni tra gli elementi – con lo scopo di raggiungere un miglior controllo di un attributo di qualità
sono applicate in molti stili architetturali (come sarà discusso più avanti nel corso) – ad es., Layers, Pipes & Filters, Microkernel, Reflection, MVC, Broker, …
la modificabilità è una qualità importante, che va presa in considerazione fin dall’inizio della progettazione dell’architettura
per questo, in molti stili architetturali è possibile riconoscere l’applicazione di una o più di queste tattiche
Modificabilità55
Luca Cabibbo ASW
- Altre opzioni di progettazione per la modificabilità
La prospettiva dell’evoluzione di [SSA] propone alcuni suggerimenti, tattiche e opzioni di progettazione per la modificabilità
queste opzioni di progettazione di [SSA] sono di solito delle generalizzazioni delle tattiche di [SAP] oppure delle considerazioni di natura più generale
Modificabilità56
Luca Cabibbo ASW
Contieni (localizza) il cambiamento
increase semantic coherence, split module, encapsulate, use an intermediary, …
Crea interfacce estensibili
abstract common services
Applica tecniche di progettazione che facilitano il cambiamento
use an intermediary – ad es., collega elementi diversi mediante degli opportuni design pattern
Applica stili architetturali basati su meta-modelli
ad es., Reflection
Modificabilità57
Altre opzioni di progettazione per la modificabilità
Luca Cabibbo ASW
Altre opzioni di progettazioneper la modificabilità
Costruisci punti di variazione nel software
un punto di variazione è uno specifico posto del sistema in cui può avvenire un certo tipo di cambiamento – identifica questi punti di variazione e applica una decisione di progetto localizzata
Usa punti di estensioni standard
facilita le variazioni usando delle tecnologie (basate su standard) che consentono di farlo – ad es., tecnologie per adattatori e tecnologie per basi di dati relazionali
Cambia in modo affidabile
usa sistemi per la gestione dei cambiamenti, delle versioni e delle configurazioni – usa strumenti automatizzati di build, test e rilascio – usa meccanismi di rollback (in caso di problemi)
ad esempio, usa un approccio di Continuous Delivery
Modificabilità58
Luca Cabibbo ASW
* Discussione
La modificabilità riguarda la flessibilità con cui è possibile gestire cambiamenti in un sistema software dopo che questo è stato rilasciato
si tratta di una qualità importante in molti sistemi – poiché un sistema di successo deve essere in grado di soddisfare gli obiettivi di business di un’organizzazione – non solo quelli correnti, ma anche quelli futuri
i sistemi software devono essere flessibili, per abilitare – e non ostacolare – l’organizzazione nel cambiamento del proprio business
Modificabilità59