Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi esistenti...

Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi

esistenti

WP1.2Chiara Francalanci – Politecnico di Milano

2

Obiettivi del secondo anno di attività

Obiettivi:

Studio di problemi relativi all’analisi costi-benefici ex ante, cioè precedente alla progettazione R.1.2.3

Studio di problemi relativi all’analisi costi-benefici ex post, cioè relativa alla gestione dei sistemi R.1.2.3

3

Criticità

L’analisi costi-benefici deve tenere conto delle caratteristiche di adattatività e multi-canalità dei servizi MAIS

Le caratteristiche di adattatività e multi-canalità causano notevoli cambiamenti rispetto alle tradizionali tecniche di analisi costi-benefici, quali:

• L’adattatività intesa come gestione delle eccezioni comporta costi di progettazione aggiuntivi?

• L’adattatività intesa come allocazione dinamica delle risorse comporta risparmi?

• L’adattatività intesa come sostituibilità dei servizi comporta una ridistribuzione dei ritorni?

4

Temi di approfondimento dell’analisi costi-benefici

Valutazione dei benefici derivante dall’allocazione dinamica delle risorse hardware di computazione (Ardagna et al. 2004)

Valutazione dell’aumento di complessità della progettazione e della gestione di software adattativo, per ora non monetizzato (Colombo, Francalanci, Pernici 2004)

Valutazione della relazione fra costi e parametri di qualità del servizio, per ora come modello di riferimento qualitativo (Cappiello, Francalanci, Pernici 2004)

Un modello di pricing dei servizi di rete in ambiente DiffServ (Comuzzi, Francalanci, Giacomazzi 2004)

5






Valutazione benefici dell’allocazione dinamica delle risorse hardware

Obiettivo: condividere le risorse da parte di più clienti

Condivisione:

• garantire il rispetto dei requisiti di QoS

• massimizzare i profitti derivanti dai contratti di Service Level Agreement (SLA)

Motivazioni: alta variabilità del carico dei sistemi Internet Componenti:

• Classificatore: identifica le richieste e le caratterizza in tempo reale in termini di effettivi requisiti di carico

• Predittore: previsione del carico applicativo che dovrà essere sostenuto nel breve termine (modelli ARMA e polinomial fitting)

• Controllore: alloca le risorse del sistema alle varie richieste con l’obiettivo di rispettare alcuni vincoli e criteri di ottimalità (configurazione dei server, allocazione delle applicazioni, routing e scheduling delle richieste)

Modello di costo e profitti derivanti dai contratti SLA

Costi associati all’uso dei server: energia elettrica, condizionamento, licenze software…

Solitamente si assume che il costo di un server sia proporzionale alla sua potenza di calcolo

Profitti derivanti dai contratti di SLA:

• Utility function (percentile, tempo di risposta medio,…)

• Contratti flat (vincoli di QoS stretti)

I profitti del Service Provider vengono valutati attraverso simulazione

L’uso di un controllore consente di migliorare i profitti anche di un ordine di grandezza rispetto al load balancing ed a politiche di scheduling tradizionali

Valutazione benefici dell’allocazione dinamica delle risorse hardware

9






Obiettivo

Descrizione di un modello di negoziazione automatica bilaterale

Il campo di applicazione del modello è una rete di tipo di DiffServ (vengono gestiti aggregati di traffico con QoS e non singoli flussi di traffico), gli attori della negoziazione sono ISP della rete

• Fornitore: gestore delle diverse classi di servizio

• Cliente: negozia le caratteristiche degli attributi dell’accesso alla rete

Il modello è adattabile al caso dell’erogazione di servizi multicanale

Modello di pricing

Modello di negoziazione per servizi di rete

Attributi di negoziazione

• Caratteristiche tecniche del servizio (frequenza media dei token bucket, profondità media dei token bucket, ritardo medio nella trasmissione dei pacchetti, probabilità di superare la soglia di ritardo)

• Prezzo

Ciascun partecipante possiede delle proprie quality function per ciascun attributo (Q(x): R [0,1])

La quality function totale è ottenuta come funzione (produttoria) delle quality function per le singole caratteristiche tecniche

Modello di pricing


I partecipanti definiscono una propria funzione di utilità V che tiene conto degli attributi e del prezzo, nel caso più semplice:

• Cliente: rapporto qualità prezzo V(X,p)=Q(X)/p

• Fornitore: prodotto qualità prezzo V(X,p)=Q(X)*p

Modello di pricing


Prezzo

• Il prezzo è un attributo particolare, ciascun partecipante ha un proprio modello per generare il prezzo da allegare a ciascun offerta

• Fornitore: ha un modello di prezzo esatto, che fornisce un valore per ogni combinazione delle caratteristiche tecniche negoziabili

• Cliente: non possiede un modello di prezzo esatto, ma riesce ad associare una fascia di prezzo ritenuta valida a ogni possibile combinazione delle caratteristiche tecniche negoziabili

Modello di pricing

Strategie di negoziazione

Esistono due principali strategie di negoziazione

• Compromesso: un partecipante tenta, in vari modi, di avvicinarsi all’offerta appena formulata dalla controparte

• Stima del prezzo: la contro-offerta è generata attraverso una stima del modello di prezzo dell’avversario (questa strategia è attuabile dal cliente, in quanto il fornitore ha un modello esatto per calcolare il prezzo), cercando di minimizzarlo a parità di qualità

Modello di pricing

Strategie di negoziazione: compromesso

x

P

C

)),(X()),(X( 1111

t

SCt

SCCt

SCt

SCC pQVpQV

p t

CSO

1t

SCO

1t

SCO

x

P

C

p t

CSO1t

SCO

1t

SCO

Mi avvicino alla controparte scegliendo l’offerta con utilità più alta in un intorno di raggio = (t) crescente nel tempo secondo un andamento esponenziale o polinomiale

,OO tgt tSC

tCSCC

1

1

1

max

,t

tkktg kt

t

etgln1

max,

Modello di pricing

Strategie di negoziazione: stima del prezzo

In un intorno si raggio crescente nel tempo, un partecipante tenta di scegliere l’offerta che minimizza la distanza tra la sua ultima offerta e la curva della stima del prezzo (lineare in figura)

Le funzioni utilizzate sono lo stesse della strategia precedente

t

CSO

x

C

xpp ˆˆ

A

p*OO

1t

SC

1t

SCO

x

C

xpp ˆˆ

A

p t

CSO

1t

SCO

1t

SCO

*O

Modello di pricing

Protocollo di negoziazione

1. Il fornitore fa la prima offerta (scegliendola tra una serie di offerte predefinite e massimizzando la propria V)

2. Il cliente risponde con una contro-offerta, inizia lo scambio reciproco di offerte

3. Condizione di uscita: un partecipante (es. il cliente) manda la propria offerta al tempo t+1 solo se vale la condizione Altrimenti accetta l’offerta della controparte al tempo t

)),(X()),(X( 11

t

SCt

SCCt

CStCSC pQVpQV

tCS

tCS

tCS p XO

Modelli di pricing

Simulazioni e risultati

E’ stata testata la strategia di tipo “compromesso”:

• L’algoritmo è progettato per convergere, il tempo di convergenza tende a saturare aumentando il timeout

• La natura dell’agreement dipende fortemente dai “pattern di concessione” dei partecipanti, chi concede di più tende ad allontanarsi di più dai valori auspicati dei parametri che meno impattano sulla funzione di utilità, diventano impredicibili

• Gli agenti tendono a non far decrescere la loro utilità, modificando le caratteristiche del canale e il prezzo

Modelli di pricing

Tempi di convergenza

Dipendono dal timeout associato al processo Aumentano se i comportamenti dei partecipanti

sono differenti (più o meno cooperativi)

20






Valutazione dell’aumento della complessità di progettazione SW

Requisiti non funzionali:

Flessibilità: “Capacità di un servizio (o di un insieme di servizi) di compensare a run-time violazioni dei vincoli di qualità”

Controllabilità: “Localizzazione delle attività di controllo sui vincoli di qualità”

Adattatività: “Capacità di un insieme di servizi di riorganizzare il flusso di interazione standard a fronte della continua violazione nel tempo dei vincoli di qualità”.

Costi di progettazione: La progettazione concettuale si complica in funzione dei

requisiti non-funzionali esaminati• analisi dei requisiti: estrazione dei requisiti, valutazione

degli scenari possibili, valutazione dei contenuti informativi fruibili in funzione del canale (o del dispositivo)…

• sviluppo: il costo di sviluppo cresce al crescere delle linee di codice da sviluppare (LOC)

Risparmi in termini di costi di integrazione • sistemi informativi restano eterogenei,• riduzione dei costi rispetto a EAI,• resta l’integrazione di processo (razionalizzazione del

procurement)


Costi di erogazione del servizio:

Risparmi in termini di costi da affrontare a fronte della mancata erogazione di un servizio

• è possibile rinegoziare il prezzo di erogazione invece di abortire la conversazione

• è possibile erogare su un canale diverso il servizio invece di interrompere la conversazione

Tanto più un ambiente è intrinsecamente incerto, tanto più il numero di violazioni è potenzialmente alto, tanto più l’adattatività fornisce benefici in termini di costi di erogazione


Costi di manutenzione:

Manutenzione potenzialmente più onerosa (conversazioni più complesse, più attori coinvolti)

Per mitigare l’onere della manutenzione:

• utilizzo modelli concettuali per supportare l’implementazione di nuove versioni che conservino tutte o una parte delle proprietà delle versione precedente (model checking, proprietà espresse attraverso formule LTL)

• utilizzo di pattern che formalizzano interazioni notevoli e che possano essere composti per ottenere interazioni più complesse (es. secondo modelli organizzativi) + pattern repository


Progettazione concettuale e requisiti funzionali e non funzionali

s

c

commit

provider

End(QoS_Control)[]|

Beg(Production)[Received(null, provider, order) (beav = 0)]|

End(Production)|

provider

s

c

user commit

abort

End(My_Control)[Achieved(QoS_goal) Done(Re-execute< null, provider, production>)]|

provider

Beg(Production)[Received(null, provider, order) (beav = 1)]|

End(Production)|End(My_control)[Achieved(QoS_goal) (Done(Re-execute< null, provider, production>)]|Re-execute< null, provider, production>

End(My_Control)[Achieved(QoS_goal)|

begin

begin

Counter(n)

End(My_Control)[Achieved(provider, QoS_goal)]|

End(My_Control)[Achieved(QoS_goal)]|Set(beav, 1)

End(abort)[ ]| End(commit)[ ]|

Conteggio eventi anomali

Adatta il comportamento per esercitare una funzione di controllo



Stimati dei costi di progettazione di una conversazione adattativa sulla base della complessità ciclomatica di McCabe.

In generale, la complessità ciclomatica viene calcolata sul flusso di controllo di un programma descritto attraverso un grafo orientato. Questo tipo di metrica è derivata dalla teoria dei grafi dove, per un grafo orientato e fortemente connesso, viene definito il numero ciclomatico:

v(g) = e-n+1, e: archi, n: nodiEsempio Complessità ciclomatica Descrizione

1 4-2+2 = 4

Servizio non flessibile, controllo di tipo “scatola

nera”

2

5-2+4 = 7

(i) Servizio flessibile: compensazione automatica,

ri-esecuzione, controllo delegato, decisione

centralizzata.

(ii) “s” e “p-s” fortemente connessi.

3 7-3+4 = 8

(i) Conversazione flessibile, compensazione partecipativa ed eventuale ri-esecuzione. (ii) “neg” e “p-s” fortemente connessi.

4

19-6+4 = 17

(i) Conversazione flessibile, controllabilità di tipo

“scatola grigia” – controllo ridondante.

(ii) “neg” e “p-s” fortemente connessi.

(iii) Aumento degli archi dovuti alla history.

27






Valutazione della relazione fra costi e parametri di QoS

Per lo studio della qualità del servizio nell’ambito del progetto MAIS è stata effettuata una analisi delle fonti, costituite dai deliverables MAIS dell’anno 2003/2004 + alcuni rapporti.

E’ stato costituito quello che si definisce Registry delle qualità in cui sono stati riportate le dimensioni MAIS. Dall’analisi bottom up dei deliverables del progetto MAIS emergono circa 225 dimensioni di qualità.

Le qualità sono state classificate in base ai diversi livelli definiti in MAIS:

• Architectural Model

• Functional Model

• Context Model

• Channel Model

• Piattaforma MAIS


Livello dei requisiti di qualità

Livello di qualità

Costo della qualità

Costo della non qualità

Costo totale della qualità = Costo della qualità +

Costo della non qualità


Si vogliono definire le relazioni tra il costo e le dimensioni di qualità nelle varie fasi di sviluppo e redesign dei servizi

Si vogliono definire i livelli accettabili della qualità considerando i costi implicati

Es. Availability


I costi della non qualità sono costi derivati dallo scostamento del servizio dai requisiti di qualità espressi dagli utenti. Sono suddivisi in:

• Costi diretti, legati all’insoddisfazione della clientela e corrispondente abbassamento dei ritorni

• Costi indiretti

I costi della non qualità indiretti sono classificati come:

• Tempo umano: ad esempio, scarsa qualità implica interventi extra sul sistema da parte del personale IT

• Risorse informatiche: ad esempio, il tempo di risorse impiegate nell’esecuzione di servizi inutili

33

Conclusioni

Nel terzo anno di attività si vuole:

• raffinare il modello di valutazione dei benefici dell’allocazione dinamica delle risorse hardware

• estendere il modello di negoziazione al caso molti-molti e multi-canale

• approfondire la relazione fra costi e parametri di qualità, arrivando, se possibile, alla definizione di un modello della non qualità

• verificare il modello della non qualità nel caso specifico della qualità dei dati

Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi esistenti...

Documents

Transcript of Analisi delle caratteristiche dei servizi multicanale e del loro utilizzo nei sistemi esistenti...