PROGETTO SCRS

Progetto Live-Club
Preparato per: Progetto Esame Sistemi Cooperativi e Reti Sociali
Preparato da: Dente Federico, Piacentini Matteo
23 luglio 2018
PROGETTO SCRS

INTRODUZIONE

Scopo
Con questo progetto si vuole utilizzare la tecnologia Hyperledger Composer per creare una rete di gestione
mediante Blockchain di Royalties dei diritti di brani musicali suonati live. Oggi un locale per permettersi musica
live, oltre ad ingaggiare dei professionisti, deve assicurarsi di pagare i diritti d’autore dei brani nella scaletta ai
rispettivi proprietari compilando un modulo presso il sito della SIAE (Società Italiana degli Autori ed Editori),
ente pubblico economico che si occupa di gestire e proteggere le proprietà intellettuali delle opere artistiche
(tra cui opere in ambito musicale) che funge da Autorità riconosciuta e regolamentata.

Obiettivi
Al giorno d’oggi il modulo viene compilato dopo l’esecuzione del concerto, perché la scaletta potrebbe subire
aggiunte di brani (il più delle volte si tratta di richieste da parte del pubblico), comunque da registrare presso la
SIAE.
Nella realtà dei fatti ad oggi, sebbene esista su carta, non c’è una vera e propria validazione costante sui brani
suonati durante il concerto, perché la spesa degli agenti SIAE sarebbe insostenibile.
La SIAE, almeno nel mondo dei piccoli locali come pub o ristoranti, agisce mediante stime del numero di
serate organizzate in un determinato locale e mediante controlli saltuari sui pagamenti medi mensili.

Soluzione
Utilizzando la tecnologia Blockchain possiamo risolvere questa lacuna: il ruolo degli agenti può essere
ricoperto dagli stessi artisti (Ricordiamo che la SIAE è alle spese del locale) e sfruttando la solidità del Ledger
distribuito per ufficializzare le serate e i rispettivi pagamenti.
PROGETTO SCRS

ANALISI DEI REQUISITI

2 GLI UTENTI
Gli utenti del sistema sono principalmente: Musicisti, Compositori e Proprietari di Locali

2.1 Profili

- Musicisti: Sono gli esecutori dei brani in un concerto, possono eseguire sia brani originali che cover (brani
composti da altri artisti)
- Compositori: Sono i proprietari dei brani riprodotti nelle serate, ogni volta che un loro brano viene eseguito,
se registrato sulla blockchain, prendono una piccola fee.
- Proprietari: Sono proprietari o amministratori dei locali, ingaggiano i musicisti e pagano un cachet stabilito in
precedenza e indipendente dai brani suonati. Oltre al cachet si occupano del pagamento dei diritti d’autore
dei brani suonati.

2.2. Contesto d’uso

Essendo il sistema basato su Blockchain, l’utilizzo di accesso e gestione tramite pagine web risulta essere la
soluzione più comoda, considerando anche la possibilità di navigare celermente anche tramite pagine web
adattate alla navigazione mobile.

2.3 Esigenze

Ciascuno degli utenti individuati ha varie esigenze da soddisfare.

- Aggiungere una serata
- Modificare la scaletta di un brano
- Pagare la serata
- Confermare la scaletta
PROGETTO SCRS

3 SISTEMA
Il sistema si basa si basa sul Framework Hyperledger Composer che permette di sviluppare applicazioni
blockchain in modo semplice. Hyperledger Composer supporta l’infrastruttura e la runtime di Hyperledger
Fabric Blockchain e permette di modellare il business network contenente gli asset e le associate transazioni.
Come parte del modello di business network, si possono definire le transazioni che interagiscono con gli asset
mediante logic function, inoltre il Business Model include la descrizione dei participant ovvero utenti identificati
da un codice univoco che interagiscono tra loro.

Nel modello di Business si possono trovare 3 principali componenti:

- Asset: beni che possono essere di qualsiasi tipo
- Participant: Utenti che interagiscono con e posseggono Asset
- Transactions: Operazioni che cambiano lo status degli elementi e che vengono registrati nella Blockchain.

I partecipanti hanno accesso più o meno ristretto alle transactions in base al loro ruolo, le regole di accesso
sono descritte in un apposito file.
PROGETTO SCRS

4 CASI D’USO
Di seguito il diagramma dei casi d’uso, gli attori sono l’Utente e il Proprietario.
PROGETTO SCRS

NOME USE CASE: Valida Scaletta

Attori: Utente

Precondizioni L’utente ha accesso alla scaletta della serata. La

scaletta è stata eseguita

Postcondizioni Il proprietario può procedere al Pagamento della

Serata (UC: PagaSerata)

Descrizione L’utente (Musicista o Proprietario) convalidano la

scaletta dei brani eseguiti nella serata.

Scenario Principale L'utente accede alla scaletta della serata, controlla

se i brani suonati sono stati immessi correttamente,
e convalida la scaletta mediante il checkbox
corrispondente.

Scenario Alternativo L’utente accede alla scaletta ma non la convalida,

torna indietro e la modifica.

NOME USE CASE: Controlla Saldo

Attori: Utente

Precondizioni L’utente ha effettuato l’accesso e si trova sul suo

profilo

Postcondizioni L’Utente ha controllato il saldo

Descrizione L’utente accede al proprio profilo e controlla il

proprio saldo

Scenario Principale L'utente accede al proprio profilo, clicca su saldo e

controlla il saldo attuale. Infine torna indietro

NOME USE CASE: Aggiungi Brano

Attori: Utente

Precondizioni L’utente ha accesso alla scaletta della serata. La

scaletta è stata eseguita

Postcondizioni La scaletta è stata modificata, è stato inserito un

nuovo brano

Descrizione L’utente (Musicista o Proprietario) decide di

aggiungere un brano alla scaletta dopo la serata.

Scenario Principale L'utente accede alla scaletta della serata, controlla

che il brano non sia già stato inserito, e lo aggiunge
alla scaletta

Scenario Alternativo L’utente accede alla scaletta ma il brano che vuole

inserire è già stato inserito. Annulla l’operazione.

NOME USE CASE: Rimuovi Brano

Attori: Utente

Precondizioni L’utente ha accesso alla scaletta della serata. La

scaletta è stata eseguita

Postcondizioni La scaletta è stata modificata, è stato eliminato un

brano
PROGETTO SCRS

Descrizione L’utente (Musicista o Proprietario) decide di eliminare

un brano alla scaletta dopo la serata.

Scenario Principale L'utente accede alla scaletta della serata, controlla

che il brano non sia già stato eliminato, e lo elimina
dalla scaletta

Scenario Alternativo L’utente accede alla scaletta ma il brano che vuole

eliminare è già stato eliminato. Annulla l’operazione.

NOME USE CASE: Assegna Serata

Attori: Utente

Precondizioni Il proprietario ha trovato il musicista che verrà

ingaggiato per esibirsi alla serata

Postcondizioni La serata viene assegnata al musicista

Descrizione il Proprietario assegna a un musicista una sua serata

Scenario Principale Il proprietario accede alle sue serate e assegna la

serata a un musicista tramite l’id del musicista.

Scenario Alternativo Il Musicista accede alle serate e si assegna la serata

NOME USE CASE: Paga Serata

Attori: Proprietario

Precondizioni Il Proprietario e il Musicista hanno convalidato la

scaletta della serata, la serata è stata assegnata al
musicista ed è stata eseguita.

Postcondizioni La Serata è stata processata, il Musicista ha ricevuto

il Cachet e gli autori dei brani della scaletta sono
stati pagati.

Descrizione Il proprietario paga la serata, il Musicista riceve il

Cachet e gli autori dei brani della scaletta le
royalties.

Scenario Principale Il Proprietario accede alla pagina della Serata e

clicca sul tasto “Paga”. Viene visualizzata al scaletta
e si procede al pagamento dopo il click sul tasto
“Conferma”.

Scenario Alternativo Il Proprietario accede alla pagina della Serata e

clicca sul tasto “Paga”. Viene visualizzata al scaletta
si accorge di un errore e annulla il pagamento.
PROGETTO SCRS

5 DIAGRAMMA DELLE CLASSI

PROGETTO SCRS

IMPLEMENTAZIONE

Di seguito vengono descritti gli elementi implementati utilizzando Hyperledger Composer.

BUSINESS MODEL
In questo paragrafo la descrizione degli elementi che compongono il Business Model descritto nel file
model.cto

Participant
I participant sono lo User generico, il Committente (il Proprietario del locale) e il Musicista. User è abstract,
infatti gli unici utenti concreti sono il Committente e il Musicista che estendono la definizione di User.

User
abstract participant User identified by user_id {
o String user_id
o String nome
o String cognome
o Double capitale
}

Committente
participant Committente extends User {
o Locale locale optional
}

Musicista
participant Musicista extends User {
o Boolean compositore optional
o String strumento optional
}

Assets
Gli asset implementati sono Brano che descrive un brano suonato in una serata e Serata che descrive la
serata.
PROGETTO SCRS

Brano
asset Brano identified by id_brano{
o String id_brano
o String nome
--> Musicista autore
}
Brano contiene, oltre all’id e al nome, un riferimento al Musicista che ne è proprietario (l’autore)

Serata
asset Serata identified by id_serata {
o String id_serata
o String data_serata optional
o Boolean confermata_musicista optional
o Boolean confermata_committente optional
o Double catchet
o Boolean pagata default false
--> Brano[] scaletta
--> Musicista musicista optional
--> Committente committente optional
}
L’asset serata, oltre ai campi più comuni, contiene un riferimento di tipo array che descrive la scaletta della
serata, ovvero una lista di riferimenti a diversi asset di Brano. L’array in questo caso è essenziale per poter
gestire la scaletta e le transazioni annesse.

Transactions
Le transazioni descritte sono quelle utili per eseguire le operazioni di Pagamento validazione della scaletta e
Assegnamento della serata, oltre alla modifica di una scaletta.

transaction PagaSerata {
--> Serata serata
--> Committente committente
}

transaction ValidaSerata {
--> Serata serata
--> User validator
}

transaction AssegnaSerata {
PROGETTO SCRS

--> Serata serata

--> User newOwner
}

transaction AggiungiBrano {
--> Brano brano
--> Serata serata
}

transaction RimuoviBrano {
--> Brano brano
--> Serata serata
}

TRANSACTION FUNCTIONS
Nel file lib/logic.js sono scritte le funzioni mediante linguaggio Javascript che definiscono la logica di una
transazione. Ogni transazione descritta nel paragrafo precedente ha una sua transaction function.

async function validaSerata(live)

La funzione validaSerata setta a True la validazione della scaletta della serata (live) da parte del proprietario o
del musicista a seconda di chi ha emesso la transazione. Descrive la logica della transazione validaSerata.

async function assegnaSerata(live)

Assegna la serata (live) a un musicista. Descrive la logica della transazione assegnaSerata.

async function pagaSerata(live)

la funzione, che descrive la transazione pagaSerata, controlla se la scaletta è stata validata da entrambe le
parti (Musicista e Committente) e dopo i dovuti controlli scorre la lista dei brani della serata (live) e aggiunge la
royalties al conto del proprietario di ogni brano, detraendo la stessa cifra dal conto del Committente. Dopo
aver gestito i diritti d’autore, si occupa di pagare il cachet al musicista che ha lavorato alla serata.

async function aggiungiBrano(arg)

async function rimuoviBrano(arg)
Le due funzioni permettono di modificare la scaletta della serata, aggiungendo e eliminando un brano (arg).
Descrivono la logica delle transazioni AggiungiBrano e RimuoviBrano rispettivamente. Se una delle due
transazioni viene eseguita, le eventuali validazioni precedenti vengono annullate.
PROGETTO SCRS
PROGETTO SCRS

ACCESS CONTROL

L'accesso alle operazioni sulla blockchain viene regolato dalle regole descritte sotto, i vincoli più importanti
sono che per modificare una serata bisogna esserne il musicista od il committente, l'unica eccezione è che
possibile modificarla per segnarsi in uno dei due ruoli nel caso sia libero, e che l'unica interazione di UPDATE
ammessa tra gli utenti è il pagamento da parte di un Committente a vantaggio di un Musicista all'interno della
transazione di pagamento.

rule UserReadRule {
description: "Tutti gli utenti possono leggere i dati"
participant: "org.live.User"
operation: READ
resource: "org.live.*"
action: ALLOW
}

rule UserSelfUpdateRule {
description: "Tutti gli utenti possono modificare i propri dati"
participant(m): "org.live.User"
operation: UPDATE
resource(v): "org.live.User"
condition: (v.user_id == m.user_id)
action: ALLOW
}

rule UserBranoRule {
description: "Tutti gli utenti possono creare brani"
participant: "org.live.User"
operation: CREATE
resource: "org.live.Brano"
action: ALLOW
}

rule MusicistaSerataCreateRule {
description: "Il musicista può creare una serata solo per se stesso"
participant(m): "org.live.Musicista"
operation: CREATE
resource(v): "org.live.Serata"
condition: (v.musicista.user_id == m.user_id)
action: ALLOW
PROGETTO SCRS

rule CommittenteSerataCreateRule {
description: "Il committente può creare una serata solo per se stesso"
participant(m): "org.live.Committente"
operation: CREATE
resource(v): "org.live.Serata"
condition: (v.committente.user_id == m.user_id)
action: ALLOW
}

rule MusicistaSerataUpdateRule {
description: "Il musicista può modificare una sua serata"
participant(m): "org.live.Musicista"
operation: UPDATE
resource(v): "org.live.Serata"
condition: (v.musicista.user_id == m.user_id)
action: ALLOW
}

rule CommittenteSerataUpdateRule {
description: "Il committente può modificare una sua serata"
participant(m): "org.live.Committente"
operation: UPDATE
resource(v): "org.live.Serata"
condition: (v.committente.user_id == m.user_id)
action: ALLOW
}

rule MusicistaSerataUpdateBisRule {
description: "Il musicista può cercare di assegnarsi una serata"
participant: "org.live.Musicista"
operation: UPDATE
resource: "org.live.Serata"
transaction: "org.live.AssegnaSerata"
action: ALLOW
}

rule CommittenteSerataUpdateBisRule {
description: "Il committente può cercare di assegnarsi una serata"
PROGETTO SCRS

participant: "org.live.Committente"
operation: UPDATE
resource: "org.live.Serata"
transaction: "org.live.AssegnaSerata"
action: ALLOW
}

rule CommittentePayRule {
description: "Il committente può modificare i musicisti solo con un pagamento"
participant: "org.live.Committente"
operation: UPDATE
resource: "org.live.Musicista"
transaction: "org.live.PagaSerata"
action: ALLOW
}

ESEMPI D’APPLICAZIONE
In questo paragrafo viene mostrato un esempio di applicazione utilizzando Hyperledger Playground.
Di seguito la creazione dei participant: un committente e quattro musicisti.
PROGETTO SCRS

Successivamente si creano gli asset: i Brani e la serata

La serata appena creata ha le conferme del musicista e del committente impostate entrambe su false.
Una volta creati gli asset e i participant si può procedere alle varie transazioni di impostazione della serata, tra
cui la conferma della scaletta e il pagamento.
Di seguito un esempio della transazione pagaSerata e delle conseguenze della transazione.

Dopo aver lanciato la transazione la serata e i participant hanno subito modifiche.

La serata ora ha il booleano “pagata” a true.

PROGETTO SCRS

Si noti come il committente ha il capitale scalato del costo della serata (il Cachet, 300) e del costo dei diritti
d’Autore dei Brani suonati (5 a brano) mentre il musicista che si è esibito ha il capitale aumentato del Cachet.

ESEMPI DI INTERFACCIA GRAFICA

Di seguito alcuni esempi di UI su Browser Web.

Pagina del profilo dove si possono modificare le informazioni di base

PROGETTO SCRS

Pagina delle serate, dove si possono visionare, confermare o modificare le scalette delle proprie serate.

SVILUPPI FUTURI
Si propone come possibile futuro del software uno scenario che potrebbe portare il presente progetto ad
essere non solo un gestore di diritti SIAE e di pagamento del cachet di una serata live ma anche un
interessante piattaforma di incontro tra musicisti e proprietari di locali. Mettendo a disposizione una bacheca
virtuale dove gli utenti possono pubblicare annunci di serate, un musicista potrebbe proporre e mettere in
vendita una possibile scaletta con un certo budget, e un proprietario di un locale potrebbe accettarla
(comprarla) o proporre a sua volta un’eventuale serata. In futuro l’applicazione potrebbe anche ottenere dati
interessanti utilizzabili a loro volta per scenari di Machine Learning e Intelligenza Artificiale, aprendo le porte a
eventuali sviluppi di sistemi di matching automatico di musicisti e serate.

CONCLUSIONI
Con questo progetto abbiamo sviluppato e avviato l’implementazione di un tipo di applicazione reale basata su
Blockchain, sebbene il lavoro sia stato fatto per essere presentato come progetto d’esame il tipo di sfida
presentata è stata interessante e formativa e ci ha portato a familiarizzare con il Framework Hyperledger
Composer, sistema attuale ed utilizzato anche al di fuori dei pure ambiti accademici. I task scelti in
collaborazione con il Professore sono stati portati a termine, ci riteniamo pertanto personalmente soddisfatti
del lavoro svolto.