modificabilità - luca cabibbocabibbo.dia.uniroma3.it/asw/pdf/asw230-modificabilita.pdf ·...

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


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


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


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



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



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



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


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


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


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



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


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


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

modificabilità - luca cabibbocabibbo.dia.uniroma3.it/asw/pdf/asw230-modificabilita.pdf ·...

Documents