Progetto Live-Club

Preparato per: Progetto Esame Sistemi Cooperativi e Reti Sociali

Preparato da: Dente Federico, Piacentini Matteo
23 luglio 2018
PROGETTO SCRSINTRODUZIONE
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 SCRSANALISI 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 SCRS3 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 SCRS4 CASI D�USO
Di seguito il diagramma dei casi d�uso, gli attori sono l�Utente e il Proprietario.
PROGETTO SCRSNOME 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 SCRSDescrizione 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 SCRS5 DIAGRAMMA DELLE CLASSI
PROGETTO SCRSIMPLEMENTAZIONE
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 SCRSBrano
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 SCRSPROGETTO SCRSACCESS 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 SCRSparticipant: "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 SCRSSuccessivamente 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 SCRSSi 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 SCRSPagina 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.
PROGETTO SCRS